|
Professor Seleznov
|
почему 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.
-
Ссылки
-Это вторая статья на Хабре. Первая была про Cursor и компактинг. Если тема интересна - продолжу копать.-Источник
|
