Важно не общее число
Годовой расход в шесть знаков на токены для одного оператора — не повод для праздника. Это сигнал, что система выросла за пределы, где её можно осмыслить по средневзвешенному показателю. Когда нагрузка достигает такого масштаба, интересный инженерный вопрос уже не в том, сколько автономии у агентов. А в том, какая доля трафика направляется на правильный уровень модели и измеряется ли эта доля или предполагается.
Представьте, как выглядит флот агентов одного пользователя при таком уровне расходов. Большинство вызовов дешёвые: короткие шаги классификации, построение аргументов для вызова инструментов, переранжирование при поиске, суммирование ответа инструмента, который будет отброшен. Небольшой хвост дорогой: долгосрочное планирование, исправление кода по падающему тесту, синтез по нескольким документам, где модель должна удерживать противоречивые доказательства в контексте. Соотношение между этими двумя популяциями — это переменная проектирования. Если дешёвые вызовы отправляются на дорогой уровень, бюджет раздувается без соответствующего выигрыша в качестве. Если дорогие вызовы отправляются на дешёвый уровень, бюджет выглядит здоровым, а сложные задачи тихо проваливаются.
Средневзвешенное скрывает оба провала. Средняя стоимость запроса ничего не говорит о том, не избыточно ли ресурсов у флота, потому что небольшое число очень дорогих правильных вызовов и большое число очень дорогих ненужных вызовов дают одинаковое среднее. Вам нужно распределение стоимости по задачам: форма расходов по завершённым задачам с разбивкой по классам задач. Распределение с тонкой головой и тяжёлым хвостом — это система, делающая свою работу: дешёвая работа на дешёвых моделях, сложная — с эскалацией. Распределение без хвоста вообще подозрительно. Обычно это значит, что сложные задачи не решаются дёшево; их бросают, обрезают или прерывают до завершения, а кривая расходов учитывает только вызовы, которые вернулись.
Именно на этом различии — завершено против попытки — спотыкается большинство дашбордов токенов. Они показывают токены на запрос, потому что это возвращает API. Число, управляющее вашим бюджетом, — это токены на завершённую задачу, и разрыв между ними — это стоимость отказа.
Маршрутизация — это классификатор с бюджетом задержки
Каждый запрос в хорошо построенном флоте проходит через дешёвый предклассификатор, прежде чем начинается дорогой вызов. Этот классификатор отвечает на один вопрос: какой уровень модели нужен для этой задачи? Он работает на маленькой модели, слое правил или лёгком сравнении эмбеддингов с размеченным набором прошлых задач. Его задача — принять решение о маршрутизации достаточно дёшево, чтобы само решение не стало статьёй расходов.
У классификатора есть бюджет задержки, как и бюджет стоимости. Если предклассификация добавляет круговые задержки, которые пользователь чувствует, операторы отключают её и по умолчанию направляют всё на большую модель. Это самый распространённый способ, которым умирают политики маршрутизации: не из-за плохой классификации, а из-за задержки, сделавшей правильный путь слишком медленным, чтобы его сохранить.
Ошибки маршрутизации бывают двух направлений, и они не симметричны.
- Ошибка вверх — это событие стоимости. Задача, с которой справилась бы маленькая модель, уходит на большую. Качество в порядке; бюджет поглощает ошибку. Их дёшево обнаружить ретроспективно, прогнав задачу на более дешёвом уровне.
- Ошибка вниз — это событие качества. Задача, которой нужна была большая модель, получает от маленькой уверенный, правдоподобный, но неверный ответ. Их дорого обнаружить, потому что отказ беззвучен, и они усугубляются, когда агент действует по неверному выводу.
Эти два показателя нужно измерять отдельно. Единая цифра «точности маршрутизации» позволяет флоту, который никогда не эскалирует, выглядеть так же хорошо, как флоту, который эскалирует правильно. Отслеживайте долю ошибок вверх как коэффициент стоимости, а долю ошибок вниз как долю провалов задач, и никогда не усредняйте их в одно число.
Сам классификатор должен оцениваться на том же распределении задач, которое видят агенты. Именно эта часть деградирует. Классификатор, обученный на трафике прошлого квартала, дрейфует по мере изменения нагрузки — новые инструменты, новые типы документов, новые намерения пользователей. Дрейф невидим в совокупных расходах, потому что общая сумма продолжает меняться по другим причинам. Практическое решение — отложенный срез недавнего реального трафика, регулярно прогоняемый через классификатор, с сравнением решения о маршрутизации с тем, что выдал бы дорогой уровень. Этот прогон — единственная честная мера того, действует ли ещё политика. Работы по оценке агентов и развёртыванию с учётом стоимости продолжают подчёркивать тестирование на совпадающем распределении, а не на оценках бенчмарков, и это правильный инстинкт — бенчмарк говорит, что классификатор умеет классифицировать, а не что он классифицирует ваш трафик.
Что инструментировать
Инструментарий для флота такого масштаба имеет три обязательных пункта.
Логируйте токены на завершённую задачу, а не на запрос. Помечайте каждый запуск статусом завершения и агрегируйте расходы только по запускам, достигшим определённого терминального состояния. Незавершённые запуски — тайм-ауты, циклы инструментов, заброшенные планы — самые дорогие, и они исчезают из средних на запрос, потому что каждый отдельный вызов выглядел нормально. Запуск, сжёгший большой контекст за двенадцать шагов и затем провалившийся, — самый дорогой объект в системе, и большинство дашбордов его не видят.
Отслеживайте частоту эскалации. Как часто запуск переходит с маленькой модели на большую в середине задачи? Эскалация — это предохранительный клапан, делающий агрессивную маршрутизацию вниз оправданной. Низкая частота эскалации при высокой доле ошибок вниз означает, что клапан заклинило. Высокая частота эскалации означает, что предклассификатор занижает и флот платит за две попытки там, где хватило бы одной. Сама частота — сигнал здоровья маршрутизации, а не издержка, которую нужно минимизировать.
Считайте долю попаданий в кэш входным параметром маршрутизации. Кэширование промптов обычно относят к инфраструктурной оптимизации, отдельно от выбора модели. Это неверно. Если у класса задач высокая доля попаданий в кэш на его стабильном префиксе, эффективная стоимость большой модели падает, и порог маршрутизации должен сместиться. Политика, игнорирующая состояние кэша, будет перенаправлять на дешёвый уровень именно те нагрузки, где дорогой уровень уже удешевлён повторным использованием. Включайте долю попаданий в решение о маршрутизации, а не в ежемесячный отчёт.
Правило
Бюджет, который вы не можете разложить по классам задач, — это бюджет, который вы не можете защитить на ревью. Когда кто-то спрашивает, почему расходы такие, «агенты заняты» — не ответ. «Шестьдесят процентов завершённых задач относятся к классу B и выполняются на маленьком уровне со стабильной стоимостью; хвост — это планировочные запуски класса D, и вот частота эскалации и доля ошибок вниз на этом хвосте» — это ответ.
Операционное правило коротко: маршрутизируй по классу задачи, отбирай по завершению, проверяй хвост ежемесячно.
- Маршрутизируй по классу задачи. Определите классы явно, сопоставьте каждый с уровнем и держите классификатор оценённым на недавнем трафике.
- Отбирай по завершению. Считайте расходы только по завершённым запускам. Стоимость отказа — сигнал маршрутизации, а не накладные расходы.
- Проверяй хвост ежемесячно. Прогоняйте самые дорогие завершённые задачи на более дешёвом уровне. Каждая задача, выжившая в прогоне, — ошибка вверх, а их совокупность — размер доступной вам коррекции.
Честный компромисс в том, что эта машинерия стоит инженерного времени и добавляет компонент с задержкой перед каждым вызовом. Команда, направляющая всё на одну большую модель, выпустит быстрее и при малых нагрузках потратит меньше внимания. Этот компромисс перестаёт быть оправданным примерно там, где расходы одного оператора достигают шести знаков — не потому, что деньги велики в абсолютном выражении, а потому, что при таком масштабе у системы достаточно разнообразия задач, чтобы один уровень был доказуемо неверным для большей их части. Бюджет — не хвастовство. Это политика, а политики можно проверять.