Проблема с итоговыми суммами
Большинство агентных платформ сообщают о стоимости так же, как финансовый отдел отчитывается о расходах на облако: итоговая сумма, отнесённая к запуску, предоставляется после завершения запуска. Эта сумма полезна для бухгалтерии и бесполезна для управления. К моменту, когда число появляется, все решения, которые его породили, уже приняты.
Рассмотрим задачу исследования с интенсивным поиском. Агент разрешает запрос, обращается к инструменту поиска, извлекает несколько документов и тратит большую часть своего бюджета на сборку контекста, прежде чем получит хотя бы один кандидатный ответ. На третьем шаге траектория израсходовала большую часть своего лимита. На тридцатом шаге, когда агенту следует проверить, действительно ли его ответ подтверждён, тратить уже нечего. Запуск не завершается с явной ошибкой. Он возвращает уверенный ответ без проверки, а отчёт о стоимости показывает комфортный, уложившийся в бюджет запуск.
Это ключевой изъян отношения к стоимости как к отчёту, а не как к сигналу. Стоимость запуска — не скаляр, накапливающийся в фоне; это кривая с формой, и форма говорит вам, что агент вот-вот не сможет себе позволить.
Почему лимиты на запуск не решают проблему
Очевидное исправление — лимит: остановить запуск, когда расходы пересекают порог. Лимиты — грубый инструмент по двум причинам.
Во-первых, они срабатывают поздно. Лимит — это ограничение на итог, а не на следующее действие. Агент, потративший свой лимит на поиск, упрётся в лимит во время проверки — именно на том шаге, который вы меньше всего хотите урезать. Лимит превращает проблему бюджета в проблему корректности.
Во-вторых, они оставляют бюджет неиспользованным. Запуск, завершившийся ниже своего лимита, не имеет механизма потратить остаток там, где это помогло бы — на дополнительный проход проверки, второй угол поиска или повторное чтение неоднозначной инструкции. Лимит одновременно слишком строг и слишком слаб, потому что управляет не той величиной.
Величина, которая имеет значение, — это предельная стоимость на ожидаемый прирост шага: сколько стоит следующее кандидатное действие и насколько оно, как ожидается, улучшит траекторию. Этот сигнал существует только во время выполнения, а значит, должен производиться средой выполнения, а не восстанавливаться после.
Превращение стоимости в полноценную переменную планирования
Предварительное условие — каждая ступень несёт цену. Не оценку в конце запуска, а вычислимую стоимость, привязанную к шагу в момент, когда оркестратор его рассматривает. На практике это означает пометку каждого шага как минимум четырьмя атрибутами:
- модель — какой класс модели вызовет шаг, поскольку маршрутизация и генерация различаются по стоимости на порядки;
- класс токенов — входные, выходные, кэшированные входные и токены рассуждения не взаимозаменяемы и не должны суммироваться в одно число;
- задержка инструмента — астрономическое время, потому что медленный инструмент потребляет бюджет времени запуска, даже когда он дёшев по токенам;
- цена инструмента — стоимость самого внешнего вызова, которая часто невидима в учёте токенов.
С этими тегами оркестратор может оценить следующее кандидатное действие, прежде чем брать на себя обязательство. Шаг больше не является непрозрачным вызовом функции; это статья расходов с предсказанной стоимостью и предсказанной выгодой.
# Sketch: pricing a candidate action before dispatch
def price(action, context):
return {
"model_cost": model_rates[action.model] * estimate_tokens(action, context),
"tool_cost": tool_rates.get(action.tool, 0),
"latency": tool_latency[action.tool] if action.tool else 0,
}
def should_run(action, budget, context):
cost = price(action, context)
gain = expected_gain(action, context) # from the same policy that ranks actions
return cost["model_cost"] + cost["tool_cost"] <= budget.remaining_for(action.kind)
Важна последняя строка: бюджет — не единый пул. Он разделён по типу шага, и это разделение — решение политики, а не эмерджентное свойство порядка выполнения.
Политики расходов по классам задач
Единая бюджетная политика для всех классов задач гарантирует, что какой-то класс будет обслужен плохо. Два шаблона покрывают большую часть пространства.
Задачи с интенсивным исследованием — открытое исследование, обнаружение, поиск в ширину — хотят затухающий бюджет. Ранние шаги дёшевы и многочисленны; оркестратор должен свободно тратить на поиск и генерацию кандидатов, а затем сокращать. Именно сокращение сохраняет бюджет для более поздних шагов, которые фактически выбирают и синтезируют.
Задачи с интенсивной проверкой — извлечение, проверки соответствия, всё, где неверный ответ дорог — хотят зарезервированный хвост. Фиксированная доля лимита запуска удерживается и не может быть адресована шагами поиска или генерации. Агент не может потратить бюджет проверки на дополнительный контекст, каким бы заманчивым контекст ни казался.
Это компромисс, и его следует заявить прямо: резервирование хвоста делает запуск менее способным во время исследования. Агент с зарезервированным бюджетом проверки иногда не сможет найти документ, который сделал бы проверку ненужной. Политика — это ставка на то, что проверка является более ценной предельной тратой, и для некоторых классов задач эта ставка неверна. Смысл в
Маршрутизируйте дёшево, эскалируйте осознанно
Планирование с учётом стоимости также подразумевает маршрутизацию моделей. Классификация, определение намерения, решения о маршрутизации и нормализация формата не нуждаются в вызовах передовых моделей. Им нужно быть корректными на узком распределении, и меньших моделей обычно достаточно. Резервирование вызовов передовых моделей для шагов, где траектория действительно неоднозначна — где выход дешёвой модели имеет низкую уверенность или кандидатные действия близки по ожидаемой выгоде — концентрирует дорогие вызовы там, где они меняют результат.
Механизм — это порог уверенности, а не фиксированное правило. Оркестратор сравнивает распределение выхода дешёвой модели с порогом; ниже него шаг перенаправляется передовой модели с выходом дешёвой модели в качестве контекста. Сам порог — это решение планирования, и он принадлежит тому же объекту политики, что и бюджет.
Режимы отказа, против которых нужно проектировать
Планирование с учётом стоимости вводит свои собственные режимы отказа, и они не тонки.
Голодание проверки. Планировщик, минимизирующий предельную стоимость, обнаружит, что проверка дорога и редко меняет ответ. Если не сдерживать, он пропустит проверку, и запуск дёшево вернёт непроверенный вывод — пока один из этих выводов не окажется неверным так, что это будет стоить гораздо дороже, чем стоила бы проверка. Зарезервированный хвост существует именно для того, чтобы сделать этот отказ невозможным по политике, а не по надежде.
Невидимая инфляция повторных попыток. Повторные попытки — самый распространённый источник дрейфа стоимости, потому что обычно они реализуются как поток управления, а не как шаги. Инструмент, который дал сбой и был повторён трижды, выполнил четыре шага, но записал один. Если повторные попытки не являются полноценными шагами с собственными записями стоимости, кривая, которую видит планировщик, расходится с кривой, которую запуск фактически производит. Считайте повторные попытки явно, назначайте им цену и позволяйте бюджетной политике их видеть.
Умножение при разветвлении. Многоагентные системы умножают кривую. Супервизор, который отправляет пять рабочих, каждый из которых отправляет три подзадачи, создал пятнадцать траекторий, стоимости которых коррелированы — они разделяют контекст, дублируют поиск и отказывают вместе, когда общая зависимость медленна. Бюджет на рабочего — не бюджет; это пятнадцать независимых бюджетов, сумма которых — то, чего никто не выбирал. Обеспечивайте соблюдение лимита на уровне роя, где супервизор распределяет из общего пула, а рабочие конкурируют за него.
Где место этому компромиссу
Аргумент не в том, что отчётность о стоимости не нужна. Финансам нужны итоги, а командам нужно понимать, что потребляют их системы. Аргумент в том, что отчётность — это нижестоящий потребитель сигнала, который должен производиться выше по потоку, внутри оркестратора, в момент рассмотрения каждого действия.
Как только у запуска есть кривая стоимости, планировщик может сделать то, чего не может дашборд: на каждом шаге осознанно выбирать между глубиной и затратами в рамках политики, выбранной человеком. Это задача планирования, и её место там, где происходит планирование.