почему 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. Сжатие контекста: как и почему мы теряем информацию

Два механизма компактинга

Есть два принципиально разных способа сжать контекст:

1. Truncation - просто отрезать часть контекста (обычно середину или начало). Дешёво, грубо, предсказуемо.

2. 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) следует прямой вывод: если контекст не добавляет релевантной информации, а просто увеличивает длину входа - он вредит.

Эффект "меньше = лучше" работает когда:

1. У модели уже есть необходимая информация (в весах или в коротком промпте)

2. Добавление контекста увеличивает длину, но не добавляет полезных токенов

3. Лишние токены размазывают внимание

Пример: задача из 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-агентов:

1. Контекст - это ресурс, не безлимитный. Каждый токен отнимает внимание у других. Прежде чем добавить что-то, спросите: «этот токен нужен прямо сейчас?»

2. CoT - не трассировка, а нарратив. Проверяйте результат, а не рассуждение.

3. Recite before solve. Длинный контекст → сначала перескажите ключевое коротко, потом отвечайте.

4. Компактинг - lossy compression. После компактинга проверяйте не только наличие фактов, но и целостность логических цепочек.

   Пункты со звездочкой

5. Чините обвязку, а не модель. Модели делают одни и те же 4-5 ошибок. Научите обвязку их прощать - validate-then-repair.

6. Relational defaults. Там, где repair не помогает - учите функцию угадывать намерение и возвращать решение.

7. Телеметрия ошибок. Смотрите, на каких (модель, инструмент) парах чаще срабатывает repair.

---

Ссылки

1. Liu et al. (2023) «Lost in the Middle: How Language Models Use Long Contexts» - arxiv.org/abs/2307.03172

2. Hsieh et al. (2024) «Found in the Middle: Calibrating Positional Attention Bias» - arxiv.org/abs/2406.16008

3. Baker et al. (2024) «Lost in the Middle, and In-Between» - arxiv.org/abs/2412.10079

4. Du et al. (2024) «Context Length Alone Hurts LLM Performance Despite Perfect Retrieval» - arxiv.org/abs/2510.05381

5. Turpin et al. (2023) «Faithful Chain-of-Thought Reasoning?» - arxiv.org/abs/2303.06968

6. Sharma et al. (2023) - arxiv.org/abs/2307.15983

7. Lanham et al. (2023) - arxiv.org/abs/2309.15500

8. Kadavath et al. (2022, Anthropic) - arxiv.org/abs/2207.05221

9. Xiong et al. (2023) - arxiv.org/abs/2211.11559

10. Гусев Н. «Cursor всё сломал, но виноват не Cursor» - habr.com/ru/articles/1030946/

---

Это вторая статья на Хабре. Первая была про Cursor и компактинг. Если тема интересна - продолжу копать.