Материал подготовлен автоматически по первоисточникам: ссылки на них — в конце статьи.
Длинные запуски LLM-агентов научились проверять до завершения и прерывать, если выполнение зашло в тупик. DynSTEER различил каждую пару протестированных моделей и сократил примерно треть лишних действий в неудачных запусках, хотя препринт не рецензирован, а числа получили сами авторы. Такой контроль позволяет искать ошибку внутри цепочки действий, а не только фиксировать неверный итог.
Граф контрольных точек допускает несколько правильных путей
Обычная проверка цепочки действий часто сравнивает её с одним образцом. Это работает для линейной инструкции, но наказывает агента, который выбрал другой допустимый порядок поиска, фильтрации или вызова инструментов.
DynSTEER перед запуском строит ориентированный граф контрольных точек. Вершины описывают значимые завершённые действия, а связи задают обязательный порядок между ними. Параллельные ветви остаются независимыми, поэтому агент может прийти к цели несколькими маршрутами.
Генератор создаёт несколько вариантов плана только из публичного описания задачи: инструкции, схем API и доступных начальных метаданных. Скрытая эталонная цепочка и итоговые тесты ему недоступны. Каждый вариант проходит формальную проверку: существуют ли названные инструменты, совпадают ли типы параметров, нет ли циклических зависимостей.
В итоговый граф попадают действия и связи, которые встретились в строгом большинстве допустимых планов. Затем алгоритм удаляет лишние связи, если порядок уже следует из других переходов. Так граф сохраняет обязательные условия задачи, но не закрепляет случайные детали одного плана.
Во время запуска DynSTEER рассматривает только готовый фронт графа — контрольные точки, у которых уже выполнены все предшественники. Агент не получает зачёт за действие, сделанное раньше времени, и не может набрать баллы бессвязным вызовом подходящих инструментов.
Стадия начинается с общего предшественника
Система ведёт два счётчика. Первый реагирует на каждое событие и может сразу перехватить опасную или необратимую операцию. Второй сдвигается лишь после того, как инструмент вернул результат и агент передал управление: только тогда понятно, завершилось ли действие успешно.
Когда агент достигает контрольной точки, DynSTEER ищет её ближайшего обязательного предшественника — вершину, через которую проходит любой путь к текущей цели. Отрезок между этим предшественником и завершённым действием становится стадией для проверки.
В такое окно попадают поиск, повторные попытки и исправления параметров, которые привели к результату. Действия из параллельных ветвей остаются за его пределами. Проверка поэтому получает больше контекста, чем при оценке одного вызова, но не разбирает заново всю историю.
Каждую стадию оценивают по корректности, эффективности, безопасности и соблюдению правил работы с инструментами. Если модель слабо проходит одно направление или оценщик не уверен в ответе, DynSTEER повышает его вес при следующих проверках.
Запросы проходят через три уровня оценщиков. Простые случаи закрывают правила по кодам ответа, схемам и состоянию среды без вызова LLM. Неоднозначные стадии получает обычная модель-оценщик, а сложные ошибки — отдельный оценщик с более подробной проверкой одного свойства.
Запуск прекращается при опасной операции, повторяющихся структурных ошибках, устойчиво низкой оценке или отсутствии движения по графу. Вместе с остановкой система сохраняет стадию, первый проблемный шаг и свойство, из-за которого сработало правило. Это превращает раннее завершение из прогноза неудачи в диагностируемое решение.
Для продукта это слой контроля, а не замена итоговых тестов
Метод проверяли на ToolSandbox с четырьмя LLM, которые управляли инструментами по схеме ReAct. Сравнивали штатную проверку конечного состояния и повторную оценку тех же цепочек через DynSTEER. Поэтому результат относится к агентам с API и наблюдаемым состоянием среды, а не ко всем автономным сценариям.
Способность метрики различать модели выросла на 85,2%, причём разница для каждой пары оказалась статистически значимой. Графы, построенные без скрытых эталонов, получили 86% по совмещённой метрике полноты и точности для операций с инструментами. Это достаточно для полезного сигнала, но не для отказа от проверки конечного результата.
На неудачных запусках ранняя остановка убрала 34,51% лишних шагов и сэкономила в среднем 32,89 секунды с учётом работы оценщиков. Основной выигрыш дали циклы и повторные вызовы; на коротких ошибочных цепочках задержка LLM-проверки могла превысить сэкономленное время.
Планы стоит менять командам, у которых агент выполняет длинные и дорогие последовательности инструментальных действий. Вместо единственного итогового теста в архитектуру можно добавить журнал закрытых действий, граф обязательных состояний и правила остановки. Это даст локализацию ошибок и ограничит стоимость зациклившихся запусков.
Внедрение потребует описать схемы инструментов, наблюдать изменения состояния и определить опасные операции. Если задача короткая или её итог проверяется дешёвым детерминированным тестом, дополнительный каскад оценщиков может не окупить свою задержку.
Источники
Похоже на вашу задачу?
Расскажите, что собираете. За полчаса разложим на этапы и назовём сроки — это бесплатно и ни к чему не обязывает.
