Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Повторяющиеся задания LLM-агента научились переносить в исполняемый процесс, где следующий шаг выбирает код. Работа Columbia University и Amazon показала ускорение в 130 раз на задачах поддержки, хотя препринт не рецензирован, а числа в нём получили сами авторы. Для стабильных и часто запускаемых процедур это позволяет вынести LLM-планировщик из рабочего контура.
Как объяснение агента становится условием перехода
ReTrace получает стандартную операционную процедуру (SOP) и несколько журналов успешных запусков агента. Каждый шаг журнала содержит объяснение агента, вызванный инструмент, его аргументы и результат.
Сам вызов инструмента обычно показывает, что сделал агент, но не объясняет причину. Например, после проверки заказа агент может передать обращение человеку. По вызовам нельзя понять, вызвал ли передачу статус доставки, тип клиента или другое условие. Объяснение перед вызовом часто содержит эту связь и иногда называет альтернативные действия для веток, которые не встретились в журналах.
Сначала ReTrace извлекает из каждого шага условие, действие и источники входных данных. Идентификатор конкретного клиента превращается в переменную, результат прошлого инструмента — в источник для следующего шага, а постоянное значение остаётся в правиле. Условие может опираться только на сведения, доступные до выполнения действия.
Затем система сопоставляет шаги с SOP, объединяет повторы и разбирает противоречия. Получается компактный документ с проверкой завершения и упорядоченным списком правил. Каждое правило связано с фрагментом процедуры или журнала, а ветки, упомянутые в объяснении, но не выполненные ни разу, помечаются отдельно.
На последнем этапе LLM переводит правила в Python или типизированный граф платформы. При запуске код сначала проверяет, завершена ли задача, а затем выполняет первое подходящее правило. Если ни одно условие не сработало, процесс останавливается как незавершённый и не обращается к LLM за решением.
Планировщика во время выполнения нет, но отдельные инструменты всё ещё могут использовать модели, например для классификации документа. Проверка перед развёртыванием подтверждает, что код загружается и не вызывает модель для выбора шага. Она не доказывает, что извлечённые условия верны.
Где процессы приблизились к исходному агенту
Метод проверили на 79 производственных процедурах, телекоммуникационной части τ2-bench и восьми процедурах SOP-Bench. Во всех случаях процессы запускали на новых входных данных для той же процедуры, а не переносили на ранее не встречавшиеся SOP.
На производственных задачах ReTrace отстал от исходного агента по доле завершённых запусков на 3 процентных пункта, причём разница оказалась в пределах погрешности. Средняя стоимость одной задачи снизилась на 24%. Прямая генерация процесса по нескольким журналам стоила меньше, но чаще не доводила задачу до конца.
На τ2-bench ReTrace показал лучший средний результат среди вариантов без LLM-планировщика, если не учитывать исправление по учебным ошибкам. После такого исправления процесс сравнялся с агентом по средней оценке. На SOP-Bench исходный вариант уступил генерации по нескольким примерам, а исправленный превзошёл средний результат агента.
Объяснения агента помогли на τ2-bench и производственных процедурах, но почти не изменили результат на коротких задачах SOP-Bench. Значит, извлекать рассуждения полезнее там, где вызовы инструментов сами по себе не раскрывают причины ветвления.
Результат зависит от того, какие ветки попали в журналы. Объяснение может быть ошибочным, а SOP при противоречии имеет приоритет над выполненным шагом. Кроме того, производственная метрика отражала флаг завершения платформы: он иногда засчитывал запуск, даже если инструмент не выполнил полезное действие.
Когда ReTrace меняет архитектурный план
Подход подходит процессам со стабильной процедурой, ограниченным набором инструментов и большим числом повторов. По оценке работы, разовая сборка окупается примерно после 75 запусков. Для редкой операции выигрыш может не покрыть стоимость получения журналов, извлечения правил и проверки кода.
Команде потребуется сохранять не только вызовы инструментов, но и объяснения перед ними, результаты и источники аргументов. Документ с правилами стоит отделить от генератора кода: тогда одну и ту же логику можно собирать для нескольких платформ оркестрации.
Перед заменой агента нужно проверить редкие ветки, условия завершения и поведение при отсутствии подходящего правила. Исправление по размеченным учебным ошибкам улучшило результаты, но меняло сгенерированный код, а не исходный документ правил. Такое расхождение усложняет аудит последующих версий.
ReTrace не отменяет LLM в задачах, где на каждом запуске нужно интерпретировать свободный текст. Модель можно оставить внутри фиксированного инструмента, не поручая ей маршрутизацию всего процесса. Если SOP или набор инструментов часто меняются, рабочий процесс придётся собирать заново.
Главное изменение в плане разработки — агент можно использовать как средство исследования процедуры, а не как постоянный исполнитель. После сбора показательных запусков его решения превращаются в проверяемые условия и код, который дешевле запускать и проще ограничивать.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
