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 Как это учитывать в агентах Любопытно, что некоторое время назад очень похожие идеи я встретил в parlant. Это агентский фреймворк с достаточно свежим взглядом на агентов, где привычный Flow/Finite State Machine можно задавать неявно с помощью регламентов и руководств на естественном языке, как бы вы передавали их обычному работнику-человеку. Я бы сказал это такой if/else на LLM стероидах. Так вот одна из задач, которую фреймворк перед собой ставит — сужать контекстное окно решаемой задачи для агентов, ограничивая его небольшим набором инструкций и сообщений. Свой подход они называют Attentive Reasoning Queries (ARQs). Таким образом обещается высокая точность выполнения задач. Разработчики в упомянутом выше блогпосте также ссылались на любопытную Curse of Instructions на ту же тему, но судя по Open Review, далеко статья не пошла. Интересно, что другой популярный практико-ориентированный совет для production LLM систем — максимальное переиспользовать и кешировать контекст. Как эти две идеи дружить друг с другом хз, will see. #Review #Paper #Agents Графики из статьи в комментариях