Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Небольшую модель научили забирать у LLM рутинные решения агента и возвращать управление большой модели в сложных случаях. На задачах, похожих на обучающие, JevAgentHarness снизил стоимость агента на 81,1–89,0% и ускорил его до 2,5 раза при потере менее трёх пунктов успешности; работа пока не рецензирована, а числа получили сами авторы. Результат предлагает не заменять основную LLM целиком, а делить управление на отдельные решения и проверять каждое на траекториях собственного агента.
Порог уверенности решает, кто управляет следующим шагом
Работу выполнила группа из University of Illinois Urbana-Champaign, Princeton University и Google. Их JevAgentHarness встраивает модель решений между управляющей программой агента и основной LLM.
В каждом цикле агент принимает несколько разных решений: выбирает инструмент и его аргументы, решает, пора ли остановиться, стоит ли записать что-то в память или повторно обдумать неудачный шаг. Если варианты можно перечислить заранее, обвязка оформляет их как вопрос с несколькими ответами. Модель решений возвращает выбранный вариант и оценку своей уверенности.
Главный режим работы — каскад. При уверенности выше заданного порога ответ исполняется сразу, а при низкой уверенности тот же выбор делает LLM. Свободный текст тоже остаётся большой модели: малая модель выбирает только инструмент и те аргументы, которые можно взять из фиксированного списка или скопировать из контекста.
Порог нельзя переносить из общей проверки модели. JevAgentHarness сначала запускает агента на отдельных задачах, записывает ответы модели решений, но не исполняет их, а затем для каждого типа выбора сопоставляет сэкономленный вызов LLM с риском провалить всю задачу. Если безопасного порога найти не удаётся, решение остаётся у LLM.
На одном шаге агента поддержки Jev распределил уверенность между запросом уточнения и отменой заказа как 63% против 37%. Обвязка не приняла этот ответ и вызвала LLM. На следующем шаге Jev уже уверенно выбрал отмену, заказ и причину, поэтому агент выполнил действие без дополнительного вызова большой модели.
Одиночные вопросы не предсказывают работу агента
Для проверки авторы собрали AgentDecisionBench. Он последовательно измеряет качество на изолированных вопросах, на шагах записанных запусков и внутри работающего агента. Последний режим отличается принципиально: ошибочное действие меняет состояние среды, поэтому следующего вопроса из исходной записи уже не существует.
Лучшая модель на изолированных вопросах довела до конца только 69,5% задач при прямом управлении агентом. Передача выбора инструментов без подобранного порога снизила успешность на 19 пунктов. Значит, обычная точность на наборе вопросов не подходит ни для выбора модели, ни для решения о её выпуске в рабочий контур.
Особенно опасны необратимые действия. Модель может правильно выбирать инструменты почти на всей траектории, но один раз оформить возврат вместо запроса данных и лишить агента возможности исправиться. Поэтому обвязка оценивает не только долю правильных ответов, но и последствия ошибки для всей задачи.
Обученная AgentDecision-4B справилась с 91,5% задач, отличавшихся от обучающих, когда выбирала инструменты сама. Jev в тех же условиях получил 82,0%. Разрыв возник не из-за более высокого результата на обычных вопросах, а из-за обучения на состояниях, в которые агент действительно попадает во время работы.
Проверка охватила DecisionGym, задачи поддержки из τ2-bench и бытовую среду ALFWorld. Авторы также встроили перехватчики в программных и терминальных агентов. При этом наиболее убедительные замеры экономии относятся к повторяющимся задачам поддержки и бытовым сценариям, похожим на данные для настройки модели.
Командам нужен слой делегирования, а не полная замена LLM
AgentDecision-4B построена на Qwen3-4B. В обучающие данные включили состояния после неправильных действий: их доля составила 30,9%. Модель сначала училась повторять ответы Jev там, где учитель выбирал допустимый шаг, а затем работала внутри агента и получала награду за завершённую задачу, меньшее число вызовов LLM и отсутствие необратимых ошибок.
Эта деталь меняет требования к данным. Журналы успешных запусков показывают только удобную часть распределения состояний. Рабочая модель решений должна видеть сбившиеся траектории: повторный вызов инструмента, пропущенное уточнение, неверно изменённую запись и попытку восстановиться после такого шага.
Для команды внедрение начинается не с дообучения модели, а с разметки точек выбора. Нужно выделить решения с конечным набором вариантов, добавить теневую запись ответов, подобрать отдельный порог для каждого решения и оставить безусловный возврат к LLM при сбое. Порог придётся пересчитывать после смены основной модели, модели решений или правил среды.
Дообучение оправдано, когда агент многократно работает в одной предметной области и стоимость вызовов LLM уже заметна в бюджете. Для редких процессов или задач, где следующий шаг нельзя перечислить заранее, слой делегирования добавит вызов модели и задержку, но почти не снимет работу с LLM.
Практический вывод работы — считать единицей оптимизации не весь ответ агента, а конкретный выбор внутри его цикла. Тогда большая модель сохраняет контроль над неоднозначными и текстовыми шагами, а малая забирает только решения, для которых экономия подтверждена на собственных траекториях продукта.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
