Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
LLM-агентам не обязательно заново выбирать действие на каждом ходу: повторяющиеся решения можно вычислить заранее и переиспользовать. В препринте Adarsh Vatsa и William Eiers точность Qwen3.8-27B на задачах telecom выросла с 29% до 96% при сокращении числа вызовов модели на 93%, хотя работу не рецензировали и все замеры провели сами авторы. Для процессов с ограниченным набором действий это меняет архитектуру агента: LLM остаётся для языка и новых ситуаций, а знакомые решения принимает отдельный контроллер.
Текст меняется, а состояния процесса повторяются
В службе поддержки ответы клиентам почти всегда сформулированы по-разному. Однако выбор следующего действия сводится к короткому списку: проверить учётную запись, уточнить настройку телефона, применить исправление, передать обращение человеку или завершить разговор.
Авторы описывают состояние как компактный набор фактов, от которых зависит этот выбор. Для telecom это тип проблемы, результат уже выполненных проверок, наличие препятствий для исправления и признаки того, что проблема решена. Формулировки клиента в состояние не входят, поэтому разные разговоры часто приводят агента к одной и той же комбинации фактов.
Метод Discretize, Then Decide начинает с журналов работы или специально собранных прогонов агента. Правила читают сообщения и результаты инструментов, превращают их в состояния, а затем оценивают стоимость каждого действия и вероятность его исходов. Сбор продолжается, пока новые состояния перестают появляться, а оценки стабилизируются.
Из этих данных строят марковский процесс принятия решений и вычисляют политику — лучшее действие для каждого известного состояния с учётом выбранной стоимости. Ею могут быть ходы клиента, доллары или токены. Получившуюся связку авторы называют Bellman language model (BLM).
Во время работы контроллер сам отправляет вызов инструмента или шаблонный ответ, если состояние однозначно задаёт действие. Незнакомое состояние уходит в LLM вместе с историей разговора. Модель не исчезает из системы, но перестаёт повторно решать уже рассчитанные задачи.
Контроллер убирает вызовы модели, а не удешевляет их
На τ2-bench telecom контроллер без LLM решил 79% задач. Он использовал фиксированные запросы там, где состояние не определяло следующий ход, поэтому этот результат показывает, какая доля работы относилась именно к выбору действия, а не к генерации текста.
Для Claude Opus 5.5 контроллер сократил число вызовов модели и стоимость одной задачи примерно на 98%, одновременно решив на две задачи больше. Простая запись рассчитанной политики в системную инструкцию тоже повышала точность, но не экономила вызовы: модель по-прежнему читала контекст и принимала решение на каждом ходу.
На InventoryBench политика работала без модели и обошла все опубликованные методы, с которыми её сравнили в работе. В разборе сбоев непрерывной интеграции преимущество оказалось слабее. На задачах SymPy контроллер почти не помог, потому что основную работу составляли поиск и написание кода, а не выбор из повторяющихся действий.
Проверка охватила telecom, управление запасами, разбор сбоев тестов и исправление задач SymPy на Qwen3.8-27B и Claude Opus 5.5. Самые строгие замеры относятся к telecom: контроллеры замораживали до случайного выбора тестовых задач, а генератор сочетал 19 типов неисправностей. Клиентов там изображали LLM, поэтому их поведение могло быть однообразнее реальных разговоров; в остальных доменах тестовые данные отделяли от разработки менее строго.
Командам стоит сначала измерить повторяемость решений
Работа не предлагает заменить агентный контур решателем целиком. Она предлагает разделить два вида работы: понимание и генерацию оставить LLM, а повторяющийся выбор действий вынести в проверяемую политику. Это применимо там, где можно перечислить допустимые ходы, наблюдать их исходы и назначить им стоимость.
Первый практический шаг — воспроизвести черновой контроллер на существующих журналах. Такой прогон покажет, какую долю ходов можно было выполнить без модели и совпали бы эти действия с действиями агента. Если журналы состоят преимущественно из уникального текста и новых способов решения, отдельный решатель мало что даст.
Экономика зависит от стоимости разработки правил, шаблонов и считывания состояний. В одном тесте с Opus контроллер экономил $0,48 на разговор; срок окупаемости равен стоимости сборки, разделённой на эту сумму. В отличие от тонкой настройки модели, изменение цены действия требует только пересчитать политику, а не заново обучать веса.
Главная инженерная задача — выбрать состав состояния. Если оставить слишком мало фактов, контроллер объединит ситуации, которым нужны разные действия. Если сохранить слишком много, состояния перестанут повторяться. Рассчитанная политика оптимальна только для выбранного представления и полученных оценок, поэтому незнакомые случаи должны по-прежнему переходить к LLM.
Для ограниченных процессов работа даёт основание пересмотреть план, в котором каждый ход обязательно проходит через модель, маршрутизатор или дообученный агент. Сначала можно проверить повторяемость по журналам, затем вынести устойчивые решения в контроллер и оставить модели только те ходы, где действительно нужны язык или новое действие.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
