Long Horizon Execution в LLM
...или как агенты тупеют во время разговора
Статья: https://arxiv.org/abs/2509.09677
Итак, проверяют как LLM работают на длинных горизонтах — выполнение задачи, состояние которой развивается и копится в контексте на протяжении большого количества turn («ходов» user/assistant). Замеряют на синтетической задачке, где LLM-ка должна трекать состояние цепочки арифметических операций. На мой вкус вполне репрезентативный тест, если даже на нём проявляется эффект.
TL/DR
При решении задачи модели работают тем хуже, чем длиннее контекст диалога они обрабатывают и/или, если в этом контексте возникали ошибки.
Тезисы
✦ Точность выполнения задач на одном turn (single instruction) зависит от размера модели, но быстро насыщается — модельки начиная с 32B обычно максимизируют эту метрику и дальше от размера идёт diminishing returns
✦ Но размер начинает играть ключевое значение при len(turns) > 1: чем больше моделька, тем бóльшую точность выполнения задачи она поддерживает, и тем медленее это качество решений деградирует
✦ Self-Conditioning: На «длинных» задачах модели деградируют, если в контексте возникают их собственные ошибки — когда, смотря на свои ошибки в прошлом, модель буквально тупеет и начинает их воспроизводить (или теряет мотивацию, я хз)
✦ Размер модели не играет роли в self-conditioning, даже напротив — более крупные модельки быстрее адаптируются под свои ошибки
✦ Thinking mode (обученный reasoning, не CoT) избавляет от self-conditioning и ошибки в прошлом перестают влиять на выполнение задач в будущем — авторы предполагают, что это следствие RL алаймента, где модель становится не просто автодополнятором текста, а task-oriented агентом, которому наоборот — чаще надо игнорировать свои прошлые неудачи
✦ CoT нужен, если в рамках одного turn нужно выполнить более одного действия (считай tool call) — тут хотя бы простое текстовое планирование требуется, иначе даже большие модельки не справляются с более чем одним действием за turn
Мои выводы
☁︎ Context Engineering критически важен! Для слабых моделек лучше убирать из контекста ошибочные вызовы и просто перезапускать их, быть может, отдельной моделькой добавляя не сами действия, а комментарии/подсказки — на что модельке-исполнителю обратить внимание в следующей попытке (очевидно, корректор должен быть сильнее или располагать бóльшим контекстом)
☁︎ Для случаев, когда не хочется заводить отдельную модель-корректора и городить мультиагентность, хотя бы включите Thinking Mode
☁︎ Есть предел шагов, которые модель может выполнить с адекватным качеством, далее оно существенно и быстро деградирует. Значит надо как-то находить точку этой деградации на своей задаче и иметь стратегию fallback/restart
Как это учитывать в агентах
Любопытно, что некоторое время назад очень похожие идеи я встретил в https://www.parlant.io/ Это агентский фреймворк с достаточно свежим взглядом на агентов, где привычный Flow/Finite State Machine можно задавать неявно с помощью https://www.parlant.io/docs/advanced/explainability/ на естественном языке, как бы вы передавали их обычному работнику-человеку. Я бы сказал это такой if/else на LLM стероидах.
Так вот одна из задач, которую фреймворк https://www.parlant.io/blog/how-parlant-guarantees-compliance — сужать контекстное окно решаемой задачи для агентов, ограничивая его небольшим набором инструкций и сообщений. Свой подход они называют https://arxiv.org/abs/2503.03669 (ARQs). Таким образом обещается высокая точность выполнения задач. Разработчики в упомянутом выше блогпосте также ссылались на любопытную https://openreview.net/forum?id=R6q67CDBCH на ту же тему, но судя по Open Review, далеко статья не пошла.
Интересно, что другой популярный практико-ориентированный совет для production LLM систем — максимальное переиспользовать и кешировать контекст. Как эти две идеи дружить друг с другом хз, will see.
#Review #Paper #Agents
Графики из статьи в комментариях
