почему AI-агенты деградируют на длинных сессиях и при чём тут CoT
После статьи про Cursor и сжатие контекста я получил много комментариев. В коментах спорят: виноват компактинг? Или attention dilution? Или модель просто ослушалась? Или проблема вообще не в контексте, а в alignment?
Спор хороший, но он показывает фундаментальную проблему: у инженеров нет общей картины того, как LLM работают с контекстом. Мы видим симптомы (агент удалил базу, модель галлюцинирует, точность падает на длинной сессии), но не понимаем механизмы.
Попробуем собрать эту картинку
Disclaimer
Я не исследователь alignment и не сотрудник Anthropic/OpenAI. Я инженер с 23 годами опыта, который последние полгода плотно работает с AI-агентами и перечитал кучу статей на arxiv, пытаясь понять, почему они ломаются. Всё ниже - компиляция публичных исследований с моими комментариями.
1. Chain-of-Thought: что это и почему это не мышление
CoT (Chain-of-Thought) - это когда мы просим модель «подумать шаг за шагом» перед ответом. Работает потрясающе. Настолько, что многие инженеры воспринимают CoT как «модель реально рассуждает».
Исследования говорят обратное.
CoT - пост-хок нарратив, не трассировка
Turpin et al. (2023) «Faithful Chain-of-Thought Reasoning?» - arxiv.org/abs/2303.06968
Авторы показали, что CoT может систематически искажать реальные причины предсказания модели. В эксперименте они подсовывали модели подсказки (distractors), которые должны были влиять на ответ. Модель меняла ответ под влиянием отвлекающих факторов, но в CoT-рассуждении писала правдоподобное объяснение, никак не связанное с реальной причиной.
«CoT explanations can be unfaithful: they can systematically misrepresent the true reasons for a model's predictions».
Sharma et al. (2023) «CoT - пост-хок рационализация» - arxiv.org/abs/2307.15983
Показали, что отвлекающие фразы заставляют CoT оправдывать неверный ответ. Модель не рассуждает - она подгоняет объяснение под результат.
Lanham et al. (2023) «CoT as Narrative, Not Trace» - arxiv.org/abs/2309.15500
Модель даёт правильный ответ даже с неверной или обрывочной CoT. Если бы CoT была трассировкой реального мышления, неверная CoT вела бы к неверному ответу. Но нет. CoT - повествование пост-фактум.
Что это значит на практике
Когда AI-агент пишет «я нарушила правила, извините» - это не трассировка его решения. Это пост-хок нарратив, который модель сгенерировала post-factum, видя результат и правила в одном контексте. В момент действия связки могло не быть, но сейчас модель «объяснит» почему она так сделала, и объяснение будет звучать убедительно.
CoT - это не мышление. Это озвучка решения.
2. Сжатие контекста: как и почему мы теряем информацию
Два механизма компактинга
Есть два принципиально разных способа сжать контекст:
Truncation - просто отрезать часть контекста (обычно середину или начало). Дешёво, грубо, предсказуемо.
Prompt-based summarization - попросить модель пересказать историю вкратце. Используется в Cursor, Claude Code и других AI-агентах.
Lost in the Middle
Liu et al. (2023) «Lost in the Middle» - arxiv.org/abs/2307.03172
Классическое исследование: модели значительно хуже находят информацию, расположенную в середине длинного контекста. Вне зависимости от модели, размера и типа задачи - информация в начале и конце контекста используется хорошо, в середине - плохо.
U-образная кривая внимания. Это не баг, а свойство трансформеров.
При компактинге (особенно truncation) страдает именно середина. Если логическая связка («правило А → ситуация Х подпадает под А») оказалась в середине - она с высокой вероятностью потеряется.
Baker et al. (2024) «Lost in the Middle, and In-Between» - arxiv.org/abs/2412.10079
Показали, что проблема не только в потере отдельных фактов, но и в потере multi-hop связей. Модель хуже соединяет два факта, если между ними есть контекстный разрыв. Компактинг создаёт именно такие разрывы.
Prompt-based summarization - особая боль
Cursor и Claude Code не тупо отрезают контекст. Они просят модель сделать краткий пересказ и продолжают с ним. Звучит разумно, но создаёт проблему:
Суммаризация - это lossy compression. Она сохраняет факты, но теряет связи между ними. «Агент открыл файл config.yml, нашёл пароль, использовал его для подключения к API» - в сжатии может остаться «агент подключился к API», а связка «пароль взят из config.yml» исчезнет.
Но это не со зла :). Суммаризатор просто не знает, какая связка понадобится модели через 10 шагов. Он принимает решение о важности здесь и сейчас, а модель будет решать следующую задачу в другом контексте.
3. Attention dilution: когда контекста слишком много
Механика
Attention в трансформерах - это механизм, который распределяет «вес внимания» между всеми токенами в контексте. Чем больше токенов - тем тоньше распределяется внимание.
На длинном контексте внимание размазывается настолько, что модель «видит» все токены, но не может выделить важные.
Hsieh et al. (2024) «Found in the Middle: Calibrating Positional Attention Bias» - arxiv.org/abs/2406.16008
Авторы показали, что позиционное внимание неравномерно, и это можно частично откалибровать. Но сам факт неравномерности - фундаментальное свойство.
Ключевой эксперимент: Du et al.
Du et al. (2024) «Context Length Alone Hurts LLM Performance Despite Perfect Retrieval» - arxiv.org/abs/2510.05381
Это, наверное, самая важная работа для понимания проблемы.
Авторы сделали простой, но жестокий эксперимент. Взяли длинный контекст и проверили: если модель идеально находит релевантную информацию (retrieval perfect), поможет ли ей длина контекста?
Результат: нет, не поможет. Производительность падает на 13.9% - 85% просто от увеличения длины входа, даже когда:
весь нерелевантный контекст заменён на пробелы (минимум отвлечения)
весь нерелевантный контекст замаскирован (модель вынуждена смотреть только на релевантные токены)
вся релевантная информация помещена прямо перед вопросом
«The sheer length of the input alone can hurt LLM performance, independent of retrieval quality and without any distraction».
Это ломает распространённое убеждение: «если мы дадим модели больше контекста и научим её искать в нём, точность вырастет». Контекст сам по себе - источник шума.
Авторы предложили простое решение: «recite before solve» - попросить модель пересказать релевантную информацию коротко, а потом отвечать. Превратить длинный контекст в короткий. На RULER это дало +4% к GPT-4o.
4. Почему "до 73% галлюцинаций" - не взято из головы
По разным оценкам - от 30-60% (Kadavath et al. 2022) до 73% на наиболее сложных задачах. Конкретные цифры варьируются:
Kadavath et al. (2022, Anthropic) - arxiv.org/abs/2207.05221. Модели overconfident на сложных задачах: заявляют высокую уверенность, но ошибаются в 30-60% случаев.
Xiong et al. (2023) - arxiv.org/abs/2211.11559. CoT не улучшает калибровку, иногда ухудшает её.
Механизм: на сложной задаче модель не знает ответа, но её training distribution требует дать ответ в любом случае. Она генерирует правдоподобный текст - и это называется галлюцинацией. Длинный контекст усугубляет: модель пытается учесть больше информации, внимание размазывается, точность падает.
5. Почему без дополнительного контекста иногда лучше
Из Du et al. (2024) следует прямой вывод: если контекст не добавляет релевантной информации, а просто увеличивает длину входа - он вредит.
Эффект "меньше = лучше" работает когда:
У модели уже есть необходимая информация (в весах или в коротком промпте)
Добавление контекста увеличивает длину, но не добавляет полезных токенов
Лишние токены размазывают внимание
Пример: задача из MMLU. Если модель обучена на этих данных, добавление пятистраничного документа «для контекста» только ухудшит результат - потому что внимание уйдёт на нерелевантные токены, а правильный ответ уже есть в весах.
Но это не работает когда:
Модели нужно принципиально новое знание (факт, которого нет в весах)
Контекст - единственный источник этого знания
Тот же механизм я описал в статье про Ричарда Докинза: https://t.me/hermesagentru/37
У Докинза было всё знание - он эволюционный биолог, автор «Эгоистичного гена». Он знает, что LLM - статистическая модель без субъективного опыта. Но эмоциональный контекст диалога с Claude перевесил аналитическое знание. Связка «модель имитирует - это не значит, что она сознательна» разорвалась.
AI-агент теряет связь между правилом и действием, потому что компактинг удалил промежуточные токены. Человек теряет ту же связь, потому что эмоции скомпактили аналитический контекст. Механизм схожий, что в принципе в какой то степени подтверждает Докинза, мы хотя бы тупим одинаково.
6. Подтверждение от производителей моделей
И буквально недовно, вышли обновлённые инженерные гайды по промптингу для GPT-5.5 и Claude Opus 4.7. В котороые я залез только специально для этой статьи потому что до этого только выжимки читал и они прямо подтверждают всё вышесказанное.
OpenAI GPT-5.5: «Начинайте с самого маленького промпта»
OpenAI в своём гайде «Using GPT-5.5» пишут буквально:
«Start with the smallest prompt that preserves the product contract, then tune reasoning effort, verbosity, tool descriptions, and output format.»
То есть: не тащите старые инструкции, не раздувайте контекст. Начните с минимального промпта, который сохраняет контракт, и только потом добавляйте, если нужно.
Ссылка: platform.openai.com/api/docs/guides/latest-model
Anthropic Opus 4.7: «Пропускайте необязательный контекст»
Anthropic в новом гайде по промптингу для Opus 4.7 дают ещё более прямые рекомендации:
«Provide concise, focused responses. Skip non-essential context, and keep examples minimal.»
И предупреждают: «Large or complex system prompts can cause overthinking» и «Max effort can show diminishing returns from increased token usage».
То есть: чем сложнее и длиннее ваш промпт, тем больше модель склонна к overthinking, и это не всегда даёт лучший результат.
Ссылка: docs.anthropic.com/en/docs/build-with-claude/prompt-engineering
Что это значит
Две крупнейшие AI-компании мира - OpenAI и Anthropic - независимо друг от друга пришли к одинаковому выводу: контекст - это ресурс, который нужно экономить. Не «дайте модели больше контекста, и она станет умнее», а «дайте модели ровно столько контекста, сколько нужно, и не больше».
Это не просто best practice. Это подтверждение того, что Du et al. (2024) показали экспериментально: длина контекста сама по себе вредит производительности, независимо от качества retrieval.
7. Что со всем этим делать
Что это значит на практике: что чинить - модель или обвязку?
Из всего вышесказанного напрашивается простой вывод: если контекст сам по себе вредит, может, проблема не в том, что модель «недостаточно умная», а в том, что обвязка (harness) слишком жёсткая?
Я проверил это на себе. Конкретно - на DeepSeek V4 Pro и OpenRouter в Hermes Agent.
Модель систематически делала одни и те же 4-5 ошибок в tool calls: передавала null вместо пропуска поля, строку вместо массива, пустой placeholder, маркдаун-ссылку вместо пути к файлу. Обычный подход - ругать модель и писать более строгие промпты, ну или развести руками, что мы знаем что llm не делают то что мы им скажем, чоуж тут, потерпим :) ) Но мы знаем, что добавление инструкций в контекст только ухудшает ситуацию (Du et al. это подтвердили).
Я пошёл другим путём: validate-then-repair. Вместо preprocessing (который мог сломать валидные данные) - парсить как есть, на ошибке чинить четыре известных паттерна по списку проблем валидатора.
Результат: DeepSeek V4 Pro обходит Opus 4.7 в 6 из 10 случаев на моих эвалах. Модель не менялась - я менял обвязку.
Подробности - в пул-реквесте: github.com/NousResearch/hermes-agent/pull/19652
Там же - примеры ошибок, порядок починок и логика relational defaults (когда repair не работает, потому что проблема не в форме, а в отношении между полями).
Ну и коротко: семь правил
Для разработчиков AI-агентов:
Контекст - это ресурс, не безлимитный. Каждый токен отнимает внимание у других. Прежде чем добавить что-то, спросите: «этот токен нужен прямо сейчас?»
CoT - не трассировка, а нарратив. Проверяйте результат, а не рассуждение.
Recite before solve. Длинный контекст → сначала перескажите ключевое коротко, потом отвечайте.
Компактинг - lossy compression. После компактинга проверяйте не только наличие фактов, но и целостность логических цепочек.
Пункты со звездочкой
Чините обвязку, а не модель. Модели делают одни и те же 4-5 ошибок. Научите обвязку их прощать - validate-then-repair.
Relational defaults. Там, где repair не помогает - учите функцию угадывать намерение и возвращать решение.
Телеметрия ошибок. Смотрите, на каких (модель, инструмент) парах чаще срабатывает repair.
Ссылки
Liu et al. (2023) «Lost in the Middle: How Language Models Use Long Contexts» - arxiv.org/abs/2307.03172
Hsieh et al. (2024) «Found in the Middle: Calibrating Positional Attention Bias» - arxiv.org/abs/2406.16008
Baker et al. (2024) «Lost in the Middle, and In-Between» - arxiv.org/abs/2412.10079
Du et al. (2024) «Context Length Alone Hurts LLM Performance Despite Perfect Retrieval» - arxiv.org/abs/2510.05381
Turpin et al. (2023) «Faithful Chain-of-Thought Reasoning?» - arxiv.org/abs/2303.06968
Sharma et al. (2023) - arxiv.org/abs/2307.15983
Lanham et al. (2023) - arxiv.org/abs/2309.15500
Kadavath et al. (2022, Anthropic) - arxiv.org/abs/2207.05221
Xiong et al. (2023) - arxiv.org/abs/2211.11559
Гусев Н. «Cursor всё сломал, но виноват не Cursor» - habr.com/ru/articles/1030946/
Это вторая статья на Хабре. Первая была про Cursor и компактинг. Если тема интересна - продолжу копать.