Деградация контекста: почему ИИ теряет точность в долгом чате

Деградация контекста, или context rot, может снижать точность работы агента, даже если входные данные помещаются в заявленное контекстное окно. Исследование Chroma, охватившее 18 языковых моделей, показало: надёжность ответов меняется с длиной входных данных. Практический подход — сохранять сведения, необходимые для следующего действия, и убирать из истории всё, что к нему не относится.

Что такое деградация контекста в ИИ?

Деградация контекста — это снижение надёжности ответов по мере роста объёма информации, которую получает языковая модель. Модель может упускать факты, неверно связывать сведения или переставать учитывать уже принятое решение. Она по-прежнему принимает длинную переписку, но точно использовать её содержимое становится сложнее.

Контекстное окно — рабочее пространство, доступное модели при обработке запроса. В него входят инструкции, история разговора, документы и результаты работы инструментов. Токен — единица содержимого, которую обрабатывает модель; часто это часть слова. Что именно занимает это пространство, разбираем в руководстве по контекстному окну.

Представьте комнату, где команда разбирает инцидент. На стене рядом с актуальным планом висят отвергнутые гипотезы, устаревшая хронология событий и старые логи. На стене побольше поместится больше материалов. Но сама по себе её площадь не подскажет следующему участнику, какое решение сейчас определяет ход работы.

Это различие важно при отладке агента. Если нужный факт был удалён до того, как модель получила запрос, проверяйте усечение данных или поиск по источникам. Если факт присутствовал, но модель его упустила или неверно использовала, разбирайтесь, как она обработала переданный контекст. Ни один из этих симптомов сам по себе не доказывает, что проблема связана с длиной.

Документация проверена 24 октября 2026 года: приведённые ниже рекомендации разработчика сверены с актуальной документацией Anthropic. Примеры рабочих процессов — предлагаемые схемы, а не результаты эксплуатации реальных систем.

Исследование context rot: что показывают данные

В отчёте Chroma, опубликованном 14 июля 2025 года, показано: при более сложном сопоставлении по смыслу и наличии отвлекающих фрагментов, похожих на релевантные, поиск нужных сведений в длинном вводе становился менее надёжным. Контролируемые задания дают полезные данные, но не заменяют проверку вашего агента. Оригинальное исследование.

В очищенной версии диалогового бенчмарка LongMemEval Chroma сравнила 306 промптов средней длиной около 113 000 токенов с сокращёнными вариантами, содержавшими только нужные сведения и в среднем около 300 токенов. На всех оцениваемых моделях такие варианты получили более высокие оценки. Существенная оговорка: короткие версии составили из размеченных релевантных фрагментов и доработали вручную. Их не получили с помощью автоматической системы поиска, качество которой проверялось в исследовании. Методика и результаты исследования.

Какие выводы нельзя сделать из исследования Chroma

Отчёт не устанавливает механизм, лежащий в основе эффекта, и не определяет универсальное безопасное число токенов. Кроме того, в эксперименте с повторяющимся текстом объём вывода растёт вместе с объёмом ввода, тогда как в тестах на поиск сведений ответы короткие. Ограничения исследования и описание заданий.

Для разработчика важнее другой вопрос: умеет ли система находить и сохранять необходимые подтверждающие сведения? График, на котором тщательно отобранные данные сравниваются с полной историей, ничего не говорит о том, правильно ли ваш поисковый индекс, фильтры или механизм суммаризации отберут эти данные. Качество отбора нужно оценивать отдельно.

Почему длинный контекст сложнее использовать

Нужные сведения должны чётко выделяться среди остальных. Старый план развёртывания может быть гораздо больше похож на текущий, чем документ на постороннюю тему. Риск не только в том, что модель не найдёт нужную фразу: она может применить к текущей ситуации совсем другую.

В рекомендациях по контекстной инженерии Anthropic называет среди причин трудностей с длинным контекстом ограничения архитектуры и обучение преимущественно на более коротких последовательностях. Речь идёт о постепенном снижении точности, а не о единственной границе, за которой способность работать с контекстом исчезает. Эти объяснения полезны для анализа, но не доказывают, что все причины уже установлены.

Возьмём агента поддержки, в истории которого есть первоначальный диагноз, неудачное обходное решение и позднее подтверждённое исправление. Если следующий вызов инструмента вернёт старую версию руководства по устранению неполадок, для ответа придётся учитывать и хронологию, и приоритет источников. Текста стало больше, решение усложнилось, хотя вопрос пользователя остался прежним.

Явно зафиксируйте, как соотносятся эти сведения: укажите текущее состояние, пометьте прежний диагноз как отвергнутый и сохраните источник, подтверждающий принятое исправление. Цель — достаточные данные с понятным статусом, а не минимальная длина промпта.

Что в первую очередь проверить разработчикам и тем, кто эксплуатирует агента

Прежде чем винить модель, сравните, как она принимает одно и то же решение при разном контексте. Разработчикам для этого нужно сохранить фактический запрос, собранный приложением. В видимой переписке могут отсутствовать системные инструкции, результаты поиска или ответы инструментов, которые модель получила.

При эксплуатации начните с конкретного пропущенного требования или ошибочного действия. Жалобу «чат стал работать хуже» трудно исследовать. Формулировка «агент предложил обходное решение, уже отвергнутое в записи об инциденте» даёт случай, который можно воспроизвести.

Разберите сохранённый пример в следующем порядке:

1. 1

   Зафиксируйте условия решения

   Не меняйте вопрос, конфигурацию модели и требуемый результат. Сохраните исходный ввод и достоверные сведения, на которые должен опираться ответ. При повторном запуске отключите выполнение внешних действий, чтобы сравнение не изменило саму ситуацию.

2. 2

   Убедитесь, что нужные сведения дошли до модели

   Найдите необходимый фрагмент в фактическом запросе. Если его нет, сначала исправьте поиск, усечение данных или загрузку состояния. Если вместо него пришёл устаревший источник, исправьте отбор источников и проверку их актуальности.

3. 3

   Подготовьте вариант только с нужными данными

   Сохраните те же инструкции по задаче и все сведения, необходимые для ответа, убрав постороннюю историю и устаревшие результаты инструментов. Не подставляйте ожидаемый ответ и не упрощайте задачу. На репрезентативных повторных запусках сравните правильность ответа, использование источников и соблюдение ограничений.

4. 4

   Выберите исправление по характеру ошибки

   Если отбор нужных данных помогает, разбирайтесь с отбором и организацией контекста. Если оба варианта дают сбой, проверьте задачу, инструкции, качество исходных сведений и возможности модели. Если ошибки начинаются после суммаризации, выясните, что потерялось в сводке.

Такое сравнение помогает диагностике, но не доказывает, что ошибку вызвала именно длина: удаляя материалы, вы меняете и их состав. Для более строгой проверки влияния длины контролируйте необходимые сведения и их расположение, добавляя посторонний материал. Не делайте общих выводов по одному удачному повторному запуску.

Если рост истории регулярно сопровождается предотвратимыми ошибками, команде пора принимать меры. Короткий процесс с чёткими границами, который проходит проверки корректности, может сохранить простую архитектуру. Добавляйте оркестрацию, когда понятен конкретный сбой, который она должна устранить.

Как уменьшить деградацию контекста у агента

Выбирайте меру под тот материал, который создаёт проблему. Сжатие управляет накопленной историей; поиск отбирает нужные сведения; субагенты изолируют исследовательскую работу; порядок подачи проясняет задачу; краткие ответы инструментов сокращают лишний ввод. Эти меры дополняют друг друга, и у каждой свои риски.

Сжимайте историю, сохраняя рабочее состояние

Сжатие контекста заменяет старые фрагменты разговора более короткой записью, достаточной для продолжения работы. В актуальной документации Anthropic по сжатию объясняется, почему важно ограничивать активный контекст: «качество ответов снижается по мере роста разговора». API поддерживает сжатие как по запросу приложения, так и при достижении настроенного порога токенов.

Составляйте запись для продолжения работы исходя из требований следующего действия. В примере с инцидентом сохраните текущую цель, подтверждённую причину, отвергнутое обходное решение и причину отказа от него, оставшуюся неопределённость, расположение источников и следующее действие. Если корректность зависит от точных идентификаторов или формулировок, сохраняйте их без изменений.

Слабая запись выглядит так: «Исследовали проблему, есть прогресс». Полезная — так: «Обходное решение отвергнуто, поскольку нарушает требуемое поведение; принятое исправление зафиксировано в документе об инциденте; проверка ещё не завершена». Вторая позволяет продолжить работу без пересказа всего расследования.

Ограничение: сводка может отбросить деталь, которая понадобится позже. Сохраните доступ к исходной записи и проверьте, способен ли агент после возобновления работы отвечать на вопросы, для которых она нужна. Долговременное хранение состояния и выбор того, что загрузить снова, — разные задачи. Подробнее об этом — в разборе памяти ИИ-агентов.

Подгружайте сведения, когда они нужны для задачи

Храните ссылки на объёмные источники и загружайте нужные части по запросу. Anthropic называет этот подход just-in-time context: агент может сохранять пути к файлам, поисковые запросы или ссылки, а сами материалы получать по мере необходимости. Рекомендации по поиску и загрузке контекста.

Для агента, разбирающего инцидент, начните с текущей записи об инциденте и относящейся к нему документации сервиса. Загружайте сведения о старом инциденте, когда этого требует диагностика. Вместе с каждым фрагментом возвращайте источник, версию или дату, если они доступны, и достаточно окружающего текста, чтобы правильно понять исключения.

Ограничение: поиск может пропустить решающую оговорку или вернуть подходящее на вид, но устаревшее совпадение. Прежде чем измерять качество ответа, проверяйте наличие необходимых сведений. Дайте агенту возможность расширить поиск или прочитать источник целиком, если по отрывку нельзя сделать вывод.

Небольшая подборка результатов полезна лишь тогда, когда сохраняет всё необходимое для решения. «Находить нужное вместо загрузки всего подряд» — принцип отбора, а не повод скрывать неудобный контекст.

Давайте субагентам ограниченные задачи и чистый контекст

Выделяйте отдельный контекст для исследования, если основному агенту не нужны все его промежуточные результаты. В документации Anthropic по субагентам Claude Code описаны исполнители, которые работают в собственных контекстных окнах и возвращают результаты в основной разговор.

Исполнителю, который изучает лог, можно передать конкретный вопрос, нужные сведения о сервисе и путь к логу. Попросите вернуть вывод, место в источнике, которое его подтверждает, степень неопределённости и нерешённые зависимости. Основной агент сможет использовать результат, не сохраняя всю историю поиска.

Ограничение: изоляция лишает исполнителя части общих знаний. Передавайте необходимые ему ограничения и требуйте подтверждений вместе с выводом. Проверьте, что именно ваша система оркестрации передаёт исполнителю: копирование всей истории основного агента сведёт разделение на нет. Если затем вставить в основной разговор полную переписку каждого исполнителя, лишний контекст накопится снова.

Используйте этот подход для исследований, которые можно отделить от остальной работы. Решение, тесно связанное с общей записью, может быть проще принять в основном контексте, подгружая нужные сведения адресно.

Продумывайте порядок документов и текущего вопроса

Текущая задача должна чётко отличаться от вспомогательных материалов. В рекомендациях Anthropic по промптам с длинным контекстом предлагается размещать длинные документы ближе к началу промпта, явно указывать их источники, а вопрос ставить после них. Также рекомендуется сначала находить подходящие цитаты и только затем отвечать на вопросы по документам.

В приложении храните управляющие инструкции в предназначенном для них канале. В данных задачи отдельно обозначьте актуальную запись об инциденте и исторические заметки, затем ясно сформулируйте вопрос и требования к результату. Перемещение найденного текста не должно превращать его в управляющие инструкции.

Ограничение: перестановка не вернёт сведения, которые не были загружены, и ни один порядок не гарантирует результат для всех моделей и задач. Сравнивайте варианты на собственных примерах. Не повторяйте целый свод правил на каждом шаге, если достаточно краткой актуальной формулировки задачи.

Отбирайте вывод инструментов и сохраняйте доступ к полной версии

Возвращайте результат, необходимый для следующего решения, и способ открыть полный материал. В рекомендациях Anthropic по проектированию инструментов предлагается делать ответы содержательными и предусматривать фильтрацию, постраничную выдачу и усечение. В документации по редактированию контекста отдельно описано удаление старых результатов инструментов из истории разговора.

Если проверка не прошла, возвращайте сведения о сбое, относящийся к нему фрагмент ошибки и расположение сохранённого отчёта. Для поиска — релевантные фрагменты и их источники. Для успешной операции — статус и идентификаторы, необходимые для продолжения. Не включайте отчёт целиком только потому, что инструмент его создал.

Ограничение: слепое усечение может удалить решающую ошибку или оговорку. Явно обозначайте пропуски и позволяйте агенту запросить продолжение. Если полный вывод понадобится для проверки, сохраняйте его за пределами активного контекста.

Эти решения принимаются на уровне сборки запроса. В более общем руководстве по контекстной инженерии объясняется, как связаны инструкции, память, инструменты и найденные материалы.

Что в разговорах о context rot преувеличивают?

Не существует универсального числа сообщений или процента заполнения окна, при котором любому агенту пора сбрасывать контекст. Порог, защищающий от слишком большого запроса, — это настройка вместимости. Момент, когда конкретный процесс теряет надёжность, нужно определять на его реальных задачах.

Не каждый плохой ответ в длинном чате свидетельствует о деградации контекста. Недостающие сведения, противоречивые инструкции, неисправный инструмент или задача, которую система не поддерживает, могут давать похожие симптомы. Полезный отчёт об инциденте указывает, какое решение оказалось неверным, и фиксирует, что получила модель.

Сжатие не гарантирует сохранения всех данных, а внешняя память не гарантирует их релевантности. Рассматривайте оба механизма как компоненты, результаты которых нужно проверять. Если эффективнее сохранять неверный вывод, процесс может начать ошибаться стабильно.

Наконец, кеширование решает другую задачу. KV-кеш повторно использует вычисления механизма внимания; он не определяет, какой документ важен, и не удаляет устаревшую историю. Даже запрос, для которого хорошо работает кеширование, может содержать неподходящие данные для следующего решения.

Короткий чек-лист на эту неделю

Примените его к агенту, у которого регулярно повторяется ошибка:

• Сохраните фактический ввод в момент ошибочного решения и определите, какие сведения были необходимы.
• Повторите задачу с отобранными нужными данными и прежними требованиями; сравните корректность на репрезентативных случаях.
• Замените ответ инструмента с наибольшим количеством лишних данных на релевантный фрагмент и ссылку на полный материал.
• Определите формат записи после сжатия: она должна сохранять решения, отвергнутые подходы, ограничения, источники и незавершённую работу.
• Если лишний контекст накапливается при исследовании, выделите его отделимую часть исполнителю с чистым контекстом.
• Внедряйте изменение, только если после возобновления процесс сохраняет нужные факты и лучше справляется с целевой ошибкой; оставьте возможность вернуть прежнее поведение.

Начните с ошибки, которую можете воспроизвести. Тогда у изменения будет чёткий критерий приёмки, а успех не сведётся к сокращению контекста.

Частые вопросы о деградации контекста

Деградация контекста всё ещё актуальна?

В актуальной документации Anthropic по сжатию по-прежнему прямо говорится о снижении качества ответов по мере роста разговора. Это подтверждает необходимость управлять контекстом, но не показывает, как ведёт себя каждая современная модель. Проверяйте ту модель и тот процесс, которые используете.

Как избежать деградации контекста?

Сохраняйте актуальные инструкции и необходимые сведения, убирайте устаревшие и дублирующиеся материалы, аккуратно сжимайте историю и подгружайте детали по мере необходимости. При необходимости изолируйте побочные задачи, создающие много лишнего контекста. Проверяйте, что каждое изменение сохраняет факты, нужные для следующего действия.

Почему возникает деградация контекста?

На надёжность могут влиять длина контекста, релевантность окружающих материалов и способ подачи информации. Исходное исследование не устанавливает единого механизма, лежащего в основе эффекта. Прежде чем выбирать исправление для агента, проверьте переданные ему сведения и рабочее состояние.

Подпишитесь на рассылку, чтобы получать практические руководства по созданию и эксплуатации рабочих процессов с ИИ.