Для стоимости инференса на изменение нужен бизнес-порог

Низкая цена токена может повысить стоимость разработки. Дешёвая модель, которой нужны четыре попытки и сорок минут проверки и которая всё равно выпускает дефект в продакшен, обходится дороже сильной модели, которая выдаёт качественный результат с первой попытки. Для маршрутизации полезно считать стоимость инференса на принятое изменение, а не стоимость запроса, токена или сессии агента.

Порог должен отвечать на бизнес-вопрос: при какой ожидаемой полной стоимости задачу стоит передать более дешёвой модели, более сильной модели или человеку? Полная стоимость включает расходы на модель, стоимость повторных попыток, труд проверяющего, риск сбоя и ценность, которую создаёт правильно выполненное изменение. Если в правиле маршрутизации нет хотя бы одного из этих компонентов, команда оптимизирует одну строку счёта и теряет деньги в другом месте.

Единой суммы в долларах для всех задач не существует. Обновление зависимости, исправление неясной ошибки в биллинге и миграция производственной базы данных требуют разного объёма проверки и несут разную цену сбоя. Практичное решение - небольшая таблица маршрутов по классам задач, основанная на фактических данных о завершении и понятной всем формуле.

Считайте принятое изменение, а не попытку

Принятое изменение - минимальная единица, которая связывает расходы на ИИ с результатом разработки. Считайте весь инференс от первого запроса до момента, когда изменение проходит обязательные проверки и получает одобрение ревьюера. Затраты на брошенные попытки относятся к тому классу задач, в котором они возникли. Если их скрыть, слабые маршруты будут выглядеть эффективными.

Это различие важно: поставщики моделей продают инференс, а инженерные команды продают выполненную работу. Запрос может быть технически успешным, поскольку модель вернула код, но экономически провалиться, если код не собирается, не соответствует критериям приёмки или требует больше времени на проверку, чем ручное написание. Успех сессии и успех изменения - разные события.

До сбора данных определите границы. Я использую такие правила:

• Одно изменение соответствует одной задаче или одному результату, который можно проверить отдельно.
• Все обращения к модели для создания, тестирования, исправления или объяснения результата относятся к этому изменению.
• Проверка человеком заканчивается, когда ревьюер одобряет маршрут, отклоняет его или забирает работу себе.
• Изменение считается принятым только после прохождения обычных автоматических проверок.
• Более поздний производственный инцидент связывается с исходным изменением, если эту связь подтверждают факты.

Не делите крупную функцию на мелкие коммиты ради улучшения показателя. Используйте единицу, по которой ревьюер действительно может сказать «да» или «нет». Объединение коммитов не меняет единицу, её определяет приёмка.

Сохраняйте два знаменателя. Стоимость попытки изменения показывает спрос и долю отказов. Стоимость принятого изменения показывает эффективность поставки. Если в маршрут поступили десять задач, а приняты шесть, для показателя поставки счёт за инференс нужно делить на шесть, а не на десять. Четыре неудачи не исчезли из-за того, что на панели выбрали удобный знаменатель.

То же правило относится к ручной работе. Разработчик может попробовать два подхода, прежде чем исправит ошибку. Сравнивать одно обращение к ИИ только с последними минутами программирования разработчика бессмысленно. Сравнивайте полный путь до принятого результата с обеих сторон.

Сведите все расходы в одно уравнение

Порог маршрутизации становится полезным, когда каждый компонент выражен в деньгах на одно выполненное изменение. Формула может оставаться достаточно простой для электронной таблицы:

Expected total cost per merged change
  = (inference cost per attempt + review cost per attempt + retry handling cost)
    / probability of eventual merge
  + expected failure cost

Если маршрут включает несколько попыток, считайте числитель по фактическим итогам и не делайте вид, что все попытки одинаковы:

Route cost per merged change
  = (total inference spend
     + total review minutes × loaded reviewer rate per minute
     + total human repair minutes × loaded engineer rate per minute)
    / merged changes
  + incident cost attributed to the route / merged changes

Полная ставка должна учитывать расходы компании на время сотрудника, а не только зарплату. Если погоня за точностью грозит превратить расчёт в спор бухгалтеров, договоритесь об одной внутренней ставке. Стабильная и честная оценка направления лучше якобы точной ставки, которую никто не обновляет.

Стоимость проверки нужно включать в формулу, даже если ревьюеры получают оклад и деньги уже ушли со счёта. У времени на проверку есть альтернативная стоимость. Тридцать минут, потраченные на распутывание патча агента, нельзя одновременно потратить на архитектуру, клиентский дефект или другое ревью. Если считать это время бесплатным, маршрутизация неизбежно отправит работу дешёвым моделям, которые создают дорогие очереди.

Для стоимости сбоя нужна ожидаемая величина, а не пугающий худший сценарий. Умножьте вероятность сбоя по вине маршрута на среднюю стоимость сбоя этого класса. В неё можно включить труд по восстановлению, время поддержки, компенсации за нарушение уровня сервиса, потерянные транзакции или консервативную внутреннюю оценку, если связать ущерб с выручкой невозможно.

Expected failure cost = route-caused failure rate × average failure impact

Сначала используйте грубую оценку. Разделите сбои на локальную доработку, дефект до выпуска, обратимый производственный инцидент и производственный инцидент с большим ущербом. Назначьте каждому классу согласованную стоимость. Задача состоит в последовательной маршрутизации, а не в расчёте ущерба с точностью для судебного процесса.

Ценность считают рядом со стоимостью, но не включают в уравнение стоимости. Рассчитайте ожидаемую чистую ценность:

Expected net value = probability of successful completion × change value
                     - expected total cost per merged change

Так вы избежите распространённой ошибки: отклонить маршрут за $40 для изменения стоимостью $20 000 и принять маршрут за $4 для уборки, которая стоит $3. Для работы с низкой ценностью контроль расходов должен быть строгим. Там, где задержка или сбой уничтожит гораздо больше ценности, допустимы более высокие расходы.

Повторы показывают настоящую цену модели

Частота повторных попыток часто полностью меняет решение о маршруте. Модель с ценой одной попытки в четыре раза ниже не становится дешевле, если ей нужны пять попыток и больше участия ревьюера. Учитывайте все повторы в стоимости маршрута, в том числе циклы автоматического исправления, которых пользователь не видит.

Разделяйте три вида повторов, потому что они требуют разных исправлений. Повтор генерации происходит, когда модель не создаёт пригодный патч. Повтор проверки следует за провалом теста, сборки, линтера или проверки правил. Повтор уточнения нужен, когда в задаче не хватало контекста или критериев приёмки. Смена модели может помочь в первых двух случаях. В третьем обычно дешевле улучшить подготовку задачи.

По вероятности успеха каждой попытки можно оценить ожидаемое число попыток. Если бы попытки были независимыми и имели постоянную вероятность успеха p, ожидаемое число составило бы 1/p. В реальности попытки зависимы. Во втором запросе часто уже есть ошибка теста, то есть модель получает больше информации, а серия неудач может показать, что маршрут застрял. Когда данных накопится достаточно, фактическое число попыток даст более точную оценку, чем геометрическая формула.

Установите ограничение на число повторов вместе с ограничением по стоимости. Если агент дважды провалил один критерий приёмки, ему обычно нужен другой маршрут, а не более замысловатый запрос. Продолжение работы увеличивает расходы и привязывает ревьюера к ошибочному подходу модели. В моей базовой политике рутинная задача получает одну попытку исправления, затем маршрут повышается. Для дешёвых детерминированных задач с сильной обратной связью от тестов лимит можно увеличить.

Сохраняйте причину повтора. Запишите короткий код, например build_failed, wrong_scope, missing_context, review_rejected или tool_error. Без кодов причин высокая доля повторов говорит лишь об утечке денег. С кодами можно понять, что менять: модель, пакет контекста, тестовую среду или постановку задачи.

Не награждайте маршрут за отсутствие повторов, если он создаёт огромные спекулятивные патчи. При сравнении групп учитывайте размер патча, затронутые компоненты и покрытие критериев приёмки. Иначе модель будет выглядеть успешной с первой попытки, хотя она просто переложила риск на ревьюера.

Время ревью может съесть экономию на инференсе

Отсчёт времени проверки начинается, когда человек впервые открывает предложенное изменение, и заканчивается, когда он одобряет его, отклоняет или забирает работу себе. Включайте время на восстановление замысла, проверку подозрительного кода, ручной повтор тестов и объяснение исправлений агенту. Не включайте ожидание в очереди: оно показывает доступность сотрудников и расписание, а не объём работы ревьюера.

Измеряйте активную проверку, не превращая инженеров в хронометристов. Интерфейс ревью может фиксировать активные сессии, либо ревьюер выбирает грубый диапазон: менее 10 минут, от 10 до 30, от 30 до 60 или более 60. Даже грубых данных хватит, чтобы заметить маршрут, который экономит $8 на инференсе и добавляет полчаса работы старшего инженера.

Ставка ревьюера должна соответствовать тому человеку, чьё время маршрут действительно отнимает. Патч, меняющий логику авторизации, может потребовать участия ведущего инженера, поэтому считайте его полную ставку. Единая ставка младшего разработчика для всех ревью систематически занижает стоимость рискованной работы с ИИ.

У стоимости проверки есть нелинейная часть. Небольшие ревью помещаются между другими задачами. Долгие и непредсказуемые проверки прерывают запланированную работу и задерживают другие изменения. В первый день сложная модель очереди не нужна, но стоит добавить надбавку или повысить маршрут, если 90-й процентиль времени проверки превышает допустимое для команды окно.

Считайте минуты исправления отдельно от минут чтения. Долгое чтение может означать, что различия трудно понять. Долгое исправление означает, что маршрут не дал готовый результат. Оба показателя стоят денег, но требуют разных действий. Более ясные объяснения и меньшие патчи сокращают время чтения, а сильная модель или ручное выполнение могут сократить время исправления.

Частоту сбоев нужно связывать с узкой причиной

Производственный сбой должен влиять на маршрут модели только тогда, когда изменение внесло вклад в этот сбой. Если винить в каждом инциденте модель, которая последней коснулась репозитория, данные станут бесполезными. Полностью игнорировать инциденты из-за несовершенной атрибуции ещё хуже. Используйте тот же стандарт доказательств, что и при разборе инцидента: временную линию, различия в коде, тесты, журналы и фактический механизм сбоя.

Измеряйте как минимум два окна сбоев. Сбой до принятия включает отклонённые ревью и автоматические проверки, которые не удалось исправить в пределах лимита повторов. Сбой после принятия включает откаты, срочные исправления и инциденты, связанные с изменением в течение заданного периода наблюдения. Выбирайте период с учётом поведения системы. Проблема веб-развёртывания может проявиться за несколько дней, а ежемесячный сценарий биллинга требует более долгого наблюдения.

Не сравнивайте сырую частоту сбоев для несопоставимых задач. Модель, которой в основном поручают документацию и тестовые заготовки, обойдёт человека, исправляющего ошибки параллелизма в платежах. Сначала группируйте работу по классу и уровню риска, затем сравнивайте маршруты внутри групп. Полезные классы: механические рефакторинги, создание тестов, изолированные дефекты, межкомпонентные изменения, работа с безопасностью, миграции данных и неоднозначные продуктовые задачи.

Для редких тяжёлых сбоев историческое среднее может обмануть из-за маленькой выборки. До экономической формулы применяйте ограничитель риска. В некоторых задачах ответственность должна оставаться у человека независимо от текущей измеренной стоимости модели: разрушительные операции с данными, изменения контроля доступа без полных тестов, необратимые действия с инфраструктурой и работа без известного пути отката.

Это не запрет агентам работать с рискованным кодом. Агенты могут исследовать проблему, создавать черновики тестов, перечислять сценарии сбоя и готовить патч. Ограничитель определяет, кто отвечает за выполнение и одобрение. Исследовательская помощь модели отличается от передачи ей финального изменения. Команды смешивают эти режимы, а потом не понимают, почему их политика безопасности кажется произвольной.

Почти случившийся инцидент относится к данным ревью, даже если ущерба не было. Если ревьюер заметил пропущенный фильтр арендатора, отметьте изменение как review_rejected с причиной высокой тяжести. Производственные потери равны нулю, потому что контроль сработал, но маршрут всё равно показал опасный тип ошибки.

Ценность изменения задаёт предел расходов

Ценность завершённого изменения определяет допустимые расходы и задержку. Оценивайте её диапазонами, не изображая знание точной суммы. Основатель, владелец продукта или руководитель разработки может определить класс изменения по предотвращённым потерям, ожидаемой марже, сэкономленному времени, зависимости контракта или знаниям для стратегии.

Используйте четыре диапазона ценности с чёткими локальными определениями. Изменение с низкой ценностью - необязательная уборка или удобство без текущего влияния на клиентов. Обычное изменение поддерживает плановую разработку или обслуживание. Изменение высокой ценности защищает заметную выручку, снимает блокировку выпуска или устраняет дорогую операционную проблему. Срочное изменение останавливает текущие потери или восстанавливает обязательный сервис.

Ценность не равна числу изменённых строк, сюжетным баллам или должности заказчика. Исправление одной строки конфигурации может восстановить оплату. Переписывание длиной в месяц может не дать измеримой отдачи. Спросите, что станет возможным, какие потери прекратятся и что произойдёт, если отложить изменение на неделю.

Стоимость задержки относится к оценке ценности. Если человек завершит работу завтра, а самый дешёвый маршрут модели будет ходить по циклу ревью три дня, маршрут израсходует два дня ценности. Когда срок имеет значение, добавьте простой компонент задержки:

Delay cost = value lost per day × expected extra days to merge

Ценность изменения также ограничивает разумный объём экспериментов. Для работы с низкой ценностью остановитесь, когда ожидаемая стоимость поставки приблизится к ценности. Для работы с высокой ценностью стоит больше потратить на сильную модель, глубокую проверку или прямое ручное выполнение, если это повышает вероятность безопасного и своевременного завершения.

Не позволяйте заказчикам помечать всё как срочное. Для высокого и срочного диапазона требуйте одно предложение с доказательством: заблокированный контракт, текущий объём ошибок, упущенная выручка или конкретная зависимость выпуска. Доказательство может быть качественным. Оно делает компромисс видимым и оставляет материал для последующей проверки.

У некоторых изменений есть учебная ценность, даже если немедленная финансовая отдача мала. Небольшой прототип может показать, возможна ли интеграция. Запишите ожидаемую ценность решения отдельно. Иначе маршрутизация по стоимости убьёт полезные эксперименты, потому что их результатом будут знания, а не принятый производственный код.

Порог должен направлять следующий доллар

При выборе маршрута сравнивайте ожидаемую полную стоимость и ожидаемую чистую ценность доступных способов выполнения. Не спрашивайте, дёшево ли стоит модель сама по себе. Спрашивайте, какой маршрут должен получить следующий доллар для этого класса изменений.

Рассмотрим условную группу из 40 изолированных исправлений серверной части. Цифры ниже даны для примера и не описывают отраслевые нормы. Более дешёвая модель тратит $6 на попытку, в среднем делает 1,8 попытки на принятое изменение, требует 28 минут проверки и создаёт ожидаемые потери от связанных с маршрутом сбоев в размере $18 на изменение. Сильная модель тратит $18 на попытку, в среднем делает 1,15 попытки, требует 12 минут проверки и несёт $7 ожидаемых потерь от сбоя. Полная ставка ревьюера равна $2 в минуту.

Cheaper route = $6 × 1.8 + 28 × $2 + $18 = $84.80 per merge
Stronger route = $18 × 1.15 + 12 × $2 + $7 = $51.70 per merge

Сильная модель выигрывает, хотя цена её попытки втрое выше. Если оба маршрута дают одинаковую ценность и скорость цикла, более дорогой инференс экономит $33,10 на каждом принятом изменении. Панель с расходом токенов порекомендовала бы не ту модель.

Теперь заменим класс задач на детерминированные исправления форматирования. Допустим, дешёвому маршруту в среднем нужно 1,05 попытки и четыре минуты ревью, а ожидаемая стоимость сбоя пренебрежимо мала, потому что результат полностью покрывают точные проверки. Стоимость его маршрута окажется гораздо ниже. Правильная политика отправит форматирование дешёвой модели, а изолированные исправления серверной части - сильной.

Порог можно выразить как максимальный дополнительный расход на инференс, который оправдан экономией человеческого труда и снижением риска:

Maximum extra inference spend
  = review cost saved
  + repair cost saved
  + expected failure cost saved
  + delay cost saved

Если сильная модель стоит на $12 дороже, но экономит $20 на ревью и $9 ожидаемых потерь от сбоев, запас для повышения составляет $17. Повышайте маршрут. Если она экономит только $5, оставьте дешёвый маршрут, если ценность завершения или ограничитель риска не меняют решение.

Сравнивайте ручное выполнение по той же схеме. Оцените полную стоимость создания, тестирования и проверки человеком, затем учтите вероятность успеха и время до принятия. Не считайте разработчика безошибочным, а агента - автономным. Во многих неоднозначных задачах человек победит, потому что выяснение намерений занимает больше времени, чем набор кода. В повторяемых задачах с хорошими тестами маршрут модели может выиграть с большим отрывом.

Таблица решений может оставаться компактной:

routes:
  mechanical_low_risk:
    default: cheap_model
    escalate_after_retries: 1
    max_expected_cost_share_of_value: 0.35
  isolated_product_code:
    default: strong_model
    escalate_after_retries: 1
    max_review_minutes: 25
  ambiguous_cross_component:
    default: human
    model_role: research_and_tests
  irreversible_or_access_control:
    default: human_owner
    model_role: draft_only

Доля стоимости - ограничитель, а не непреложный закон финансов. Компания со свободными инженерными ресурсами может принять другую долю, чем стартап с жёстким ограничением денег. Настройте её по своей экономике, затем пересматривайте на основе фактических результатов.

Дешёвые модели и люди ошибаются в разных местах

Передавайте задачу более дешёвой модели, когда у неё узкие требования, быстрые детерминированные проверки, малая зона поражения и недорогой откат. Подходящие примеры: форматирование, простое расширение тестов, известные миграции API с поддержкой компилятора и повторяемые изменения, для которых в репозитории уже есть правильный образец.

Передавайте задачу сильной модели, когда качество рассуждений сокращает повторы или время ревью: незнакомый код, несколько взаимодействующих ограничений, поиск тонкой ошибки или изменение, требующее согласованного плана для нескольких файлов. У сильного маршрута всё равно должен быть предел расходов. Если дорогие рассуждения ходят по кругу и не дают фактов, повышайте маршрут после исчерпания лимита повторов.

Передавайте работу человеку, когда она зависит от неразрешённых продуктовых намерений, договорённостей между командами, неявных знаний о системе или личной ответственности за необратимое действие. Человек нужен и тогда, когда проверка не отличает правдоподобный патч от правильного. Модели лучше всего работают в среде, способной вернуть конкретные доказательства.

Ручное выполнение не запрещает помощь модели. Ответственный сотрудник может поручить модели поиск по репозиторию, черновик тестов, проверку предположений или объяснение незнакомого кода. Запишите этот инференс в ручной маршрут. Так сравнение останется честным и не возникнет выдумки, будто современная ручная работа обходится без ИИ.

Не выбирайте маршрут только по репутации модели. Мощная в целом модель может плохо справляться с вашим монорепозиторием, инструментами или форматом запросов. Меньшая модель может отлично решить ограниченную задачу с хорошими примерами. Для порога нужны данные о конкретном маршруте в вашей системе.

Не используйте один глобальный порог вроде $20 на изменение. Он приведёт к лишним расходам на мелочи и недостаточным вложениям в важные исправления. В минимальной рабочей политике есть класс задачи, уровень риска и диапазон ценности. Модель выбирают после этих входных данных.

Собирайте факты без лишней бюрократии

Начните с данных, которые уже есть в процессе поставки. Журналы агентов содержат расходы на инференс и идентификаторы попыток. Система работы с кодом хранит события ревью и статус принятия. Непрерывная интеграция показывает провалы проверок. В записях об инцидентах есть результаты после выпуска. Свяжите всё идентификатором изменения и сохраните исходные события для аудита.

Минимальная запись выглядит так:

{
  "change_id": "chg_1842",
  "task_class": "isolated_product_code",
  "risk_tier": "medium",
  "value_band": "normal",
  "route": "strong_model",
  "inference_cost": 21.40,
  "attempts": 2,
  "review_minutes": 17,
  "repair_minutes": 6,
  "merged": true,
  "retry_reasons": ["build_failed"],
  "post_merge_outcome": "clean"
}

Не заставляйте инженеров заполнять двадцать полей. Получайте автоматически всё, что знают инструменты, и спрашивайте людей только о классе задачи, диапазоне ценности, диапазоне активного времени ревью и необычных результатах. Если поле никогда не влияет на решение, удалите его.

Проверяйте таблицу после содержательной группы изменений, а не после каждого неожиданного результата. Маленькие выборки сильно колеблются, особенно для инцидентов. Пока у маршрута не накопилось достаточно примеров, используйте консервативное исходное допущение: стоимость проверки и сбоев не будет ниже, чем у проверенного маршрута. Новые модели получают больше работы после того, как подтверждают результат фактами.

Для обычных расходов и времени проверки используйте медианы, но показывайте и хвостовые процентили. Маршрут, который обычно стоит $10, а иногда сжигает $300, способен повредить бюджету и срокам поставки. Установите порог ожидаемой стоимости и предел потерь на одно изменение.

Там, где риск позволяет, проводите контролируемые сравнения. Отправляйте похожие задачи с низким риском по двум маршрутам, сохраняйте одинаковые критерии приёмки и сравнивайте принятые результаты. Не выбирайте для любимой модели только простые задачи. Если случайное распределение невозможно, запишите различия между задачами и не делайте чрезмерных выводов.

В Team & AI Audit команда Oleg.is использует такие рабочие данные, чтобы определить, где маршрутизация моделей, труд ревьюеров и устройство команды действительно сокращают расходы на разработку. Полезный результат - правило решений, привязанное к вашему репозиторию и ставкам сотрудников, а не общий рейтинг моделей.

Пересчитывайте порог вместе с изменением работы

Пороги маршрутизации устаревают. Меняются цены и поведение моделей, в репозиториях появляются лучшие тесты, а ревьюеры учатся работать с агентами. Пересчитывайте пороги по расписанию и после существенного изменения инструмента или процесса. Сохраняйте старую политику и её данные, чтобы более дешёвый счёт не приняли по ошибке за лучший результат.

Ограничение бюджета и порог маршрутизации решают разные задачи. Бюджет ограничивает общие расходы за неделю или месяц. Порог определяет, подходит ли конкретный маршрут для следующего изменения. Команда может уложиться в бюджет и при этом терять деньги на слабых маршрутах. Она может превысить маленький бюджет, потому что поступила работа высокой ценности. Сохраняйте оба ограничения, но не считайте остаток месячного бюджета доказательством выгодности ещё одной попытки.

При каждом пересмотре проверяйте пороги на альтернативном сценарии. Оцените, сколько то же изменение стоило бы на проверенном маршруте и как выбранный маршрут повлиял на ревью, задержку и риск сбоя. Точно узнать альтернативный результат нельзя, но такая оценка мешает объявлять экономией каждую завершённую задачу ИИ. Завершение доказывает поставку. Экономию подтверждает только сравнение.

Назначьте одного владельца показателя. Не оценивайте его работу только по сокращению расходов на инференс, потому что проще всего добиться этого, переложив стоимость на время инженеров. Поставьте сбалансированную цель: снизить ожидаемую полную стоимость принятого изменения, сохранив ограничения по сбоям и времени поставки.

Правило остановки важнее ещё одного знака после запятой в формуле. Каждый маршрут должен описывать момент повышения: число повторов, предел минут ревью, предел потерь, провал проверки безопасности или отсутствие способа подтвердить результат. Агенты умеют продолжать работу. Бизнесу нужно, чтобы они останавливались, когда ожидаемая следующая попытка стоит больше, чем может вернуть.

Запись о решении для маршрута должна помещаться в короткую таблицу: класс задачи, уровень риска, диапазон ценности, ожидаемые расходы маршрутов, выбранный ответственный и причина. Этого достаточно, чтобы основатель или технический директор мог оспорить допущения. Если никто не способен объяснить, почему обращение к модели за $30 отклонили, а час ревью старшего инженера приняли, политика измеряет не то.

Установите первые пороги на неполных данных, обозначьте неопределённость и используйте следующие двадцать изменений для улучшения оценки. Цель состоит не в минимальном счёте за инференс. Покупайте завершённые и правильные изменения по цене, которая оставляет место для создаваемой ими ценности.