Context rot: почему длинный контекст ухудшает ответы LLM

Context rot - это ухудшение качества ответов LLM по мере роста числа входных токенов, заметное задолго до заполнения контекстного окна. Сильнее всего оно проявляется, когда нужный факт не совпадает с вопросом по словам и рядом лежат похожие, но неверные фрагменты.

Окно в 1M токенов описывает, сколько модель принимает на вход, а не сколько она надёжно использует. В отчёте Chroma (июль 2025) качество падало с ростом входа у всех 18 проверенных моделей. В замере автора на Claude Haiku 5.5 доля верных ответов снизилась с 97% на ~1K токенов до 60% на ~95K, хотя вход занимал меньше 10% окна.

Статья о том, что известно о context rot из исследований 2023-2026 годов, почему стандартный тест needle-in-a-haystack завышает оценку, что показал небольшой воспроизводимый замер и что делать в агентах и long-context пайплайнах. Что такое окно, какого оно размера у разных моделей и что бывает при переполнении, разобрано в статье про контекстное окно.

Что такое context rot

Определение и происхождение термина

Термин закрепился после технического отчёта Chroma «Context Rot: How Increasing Input Tokens Impacts LLM Performance» от 14 июля 2025 года (авторы Kelly Hong, Anton Troynikov, Jeff Huber) и затем вошёл в лексикон вендоров. Кто первым употребил словосочетание, установить не удалось.

Anthropic в инженерном блоге от 29 сентября 2025 года описывает context rot так: по мере роста числа токенов в окне способность модели точно вспоминать информацию из него снижается. Явление есть у всех моделей, у части оно мягче. Отсюда метафора «бюджета внимания»: контекст надо расходовать как конечный ресурс с убывающей отдачей. В документации по контекстному окну та же мысль сформулирована короче: с ростом числа токенов точность и полнота извлечения падают, поэтому важно, что лежит в окне, а не только сколько там места.

Чем context rot отличается от переполнения и lost in the middle

Context rot - не переполнение окна. При переполнении API возвращает ошибку или приложение обрезает историю: модель просто не видит часть текста. При context rot весь текст на месте, но используется хуже.

Это и не «потеря в середине» целиком. Эффект позиции из работы Lost in the Middle описывает одну из причин промахов. Context rot шире: качество падает с ростом длины даже там, где позиция не меняется, и зависит от того, насколько вопрос похож на нужный фрагмент и сколько вокруг отвлекающих данных.

Что показывают исследования

Почти все работы ниже используют синтетические задачи и модели 2023-2025 годов. Переносить их цифры на текущие Opus 5.5, Sonnet 5.5, Haiku 5.5 или линейку GPT-6 нельзя: опубликованных сопоставимых таблиц для этих моделей найти не удалось.

Lost in the Middle: позиция

Liu и соавторы в 2023 году показали U-образную кривую: модели лучше используют информацию из начала и конца входа и хуже из середины. Работа стала фундаментом темы, но сделана на моделях 2023 года. На новых моделях и других задачах эффект бывает слабее или иным, поэтому совет «кладите важное по краям» не универсален, это уже разобрано в гайде по context engineering.

RULER и NoLiMa: эффективная длина короче заявленной

RULER (NVIDIA, 2024) проверил 17 моделей, которые заявляют окно от 32K токенов, на 13 синтетических задачах. Удовлетворительный результат на 32K сохранила лишь половина. Задачи там сложнее одиночного поиска: несколько иголок, цепочки переменных, агрегация.

NoLiMa (Adobe Research и LMU, ICML 2025) убрала главную подсказку классического теста: в иголке нет слов из вопроса, связь только через знание о мире. Из 13 моделей с заявленным окном от 128K у 11 на 32K результат опустился ниже 50% от их собственной базы на коротком входе. GPT-4o: 99,3% на коротком входе и 69,7% на 32K.

В README репозитория NoLiMa есть таблица эффективной длины: максимальной длины, на которой модель держит не меньше 85% своей короткой базы. Выдержка (данные прогонов 2025 года):

Заявленное окно больше эффективной длины в 16 раз у GPT-4o и примерно в 250 раз у Gemini 2.0 Flash. Это модели 2024-2025 годов, для поколения конца 2026 такой таблицы нет.

Chroma: дистракторы, близость, структура стога

Chroma проверила 18 моделей Anthropic, OpenAI, Google и Alibaba. Сложность задачи фиксировалась, менялась только длина входа. Ответы оценивал LLM-судья на GPT-4.1, согласие которого с разметкой людей авторы довели до уровня выше 0,99. Всего 194 480 вызовов. Конкретные проценты падения по моделям здесь не приводятся: они есть только на графиках отчёта и в данных репозитория, а пересказывать их по памяти не стоит.

Качественные выводы отчёта:

• Близость вопроса и иголки. Её мерили косинусом эмбеддингов (как это устроено, разобрано в статье про эмбеддинги), усредняя по пяти моделям. Чем ниже близость, тем быстрее результат падает с длиной. На коротком входе даже далёкие пары решаются хорошо.
• Дистракторы. Даже один похожий, но неверный фрагмент снижает результат относительно базы, четыре снижают сильнее. Влияние разных дистракторов неодинаково.
• Режим отказа зависит от семейства. Модели Claude реже всех галлюцинировали и чаще отвечали, что ответа нет. Модели GPT чаще давали уверенный неверный ответ.
• Структура стога. Перемешанный стог дал результат лучше связного у всех 18 моделей. Почему, авторы не установили.
• Сфокусированный вход. На LongMemEval (306 вопросов) все проверенные модели отвечали лучше на сфокусированном промпте около 300 токенов, чем на полном около 113 тыс. У Claude разрыв оказался самым большим, в основном из-за отказов отвечать при неоднозначности.
• Схожесть иголки со стогом дала непоследовательный эффект; авторы сами пишут, что двух тем мало для обобщения.

Агентный поиск 2026: преждевременная остановка

Xia, Wang, Huang и Liu в работе «Diagnosing and Mitigating Context Rot in Long-horizon Search» (июнь 2026) изучили агентов глубокого поиска на четырёх флагманских моделях и трёх бенчмарках. Главный режим отказа: модель сдаётся или выдаёт неуверенный неверный ответ задолго до заполнения окна, причём даже на лёгких и средних запросах. Авторы сравнили семь методов управления контекстом и описывают их как способы снизить пиковую длину контекста, после чего модель чаще продолжает поиск вместо остановки.

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

Почему needle-in-a-haystack переоценивает модели

Классический тест needle-in-a-haystack (Greg Kamradt, ноябрь 2023) прячет один факт в длинный текст и строит сетку «длина × глубина». Сетка «зелёная на всём окне» относится к простому варианту задачи. Из источников выше следует пять причин, почему такой результат не переносится на реальную работу:

1. Лексическое совпадение. Если вопрос повторяет слова иголки, модель находит фрагмент почти как поиском по строке. Без совпадения результат на длине падает заметно быстрее: в NoLiMa GPT-4o опустился с 99,3% до 69,7% на 32K, у Chroma падение тем круче, чем ниже близость вопроса и иголки.
2. Чужеродная иголка. Факт про одно в тексте про другое выделяется сам по себе. Chroma проверила этот фактор и устойчивого эффекта на двух темах не нашла, так что это гипотеза, а не установленный факт.
3. Нет дистракторов. В реальных данных рядом с ответом лежат похожие неверные фрагменты. У Chroma один дистрактор уже снижает результат.
4. Один факт вместо синтеза. RULER, Michelangelo и MRCR добавляют агрегацию, скрытую структуру и различение одинаковых фрагментов. На таких задачах результаты хуже, чем на одиночной иголке: в HELM Long Context лучший результат на MRCR 0,256 при лучшей средней по пяти задачам 0,588.
5. Вывод из 1-4, а не цитата вендора: «100% на всей сетке» означает, что модель умеет находить строку, похожую на вопрос. О надёжности на задаче с перефразированием, дистракторами и синтезом это говорит мало.

Что известно о механизмах и что нет

Исследования выше описывают поведение, а не устройство. Подтверждено следующее:

• Длина. Качество падает с ростом входа при фиксированной сложности задачи (Chroma, RULER, NoLiMa).
• Позиция. U-образная кривая у моделей 2023 года (Lost in the Middle); у новых моделей эффект слабее или иной.
• Близость вопроса и ответа. Длина усиливает зависимость от того, насколько вопрос похож на нужный фрагмент (NoLiMa, Chroma).
• Дистракторы. Похожие неверные фрагменты снижают результат (Chroma), а семейства моделей ошибаются по-разному: воздерживаются или галлюцинируют. Это разные режимы отказа, а не «лучше» или «хуже».
• Рассуждение. В LongBench v2 модель с длинным рассуждением обошла и прямые ответы, и людей. В агентном поиске (Xia и др.) длинный контекст, наоборот, подталкивает к ранней остановке. Формулировка «рассуждение лечит context rot» источниками не подтверждена; корректнее «помогает на части задач».

Чего мы не знаем. Архитектурная причина в собранных источниках на уровне причинности не доказана. Объяснения вроде «внимание размазывается по токенам» или «затухают позиционные кодировки» правдоподобны, но в этих работах не измерены. «Бюджет внимания» у Anthropic метафора, а не измерение. Почему связный текст мешает сильнее перемешанного, неизвестно. Корректно говорить о наблюдаемом поведении, а не о механизме.

Замер автора: context rot на Claude Haiku 5.5

Чтобы проверить эффект на текущей модели, автор 8 ноября 2026 года прогнал небольшую синтетическую задачу по образцу NoLiMa и Chroma на Claude Haiku 5.5 (вышла в октябре 2026, окно 1M токенов) через OpenRouter. Это иллюстрация, не бенчмарк.

Постановка

• Стог. Три романа из Project Gutenberg: «Гордость и предубеждение», «Эмма», «Мидлмарч». Заголовки и лицензионный блок срезаны. На токенизаторе Haiku 5.5 вышло 3,04 знака на токен.
• Иголки. Пять своих фраз, где вопрос не повторяет ни одного слова иголки, а связь идёт только через знание о достопримечательности. Пример: иголка «Marta’s flat is two minutes’ walk from the Sagrada Familia.», вопрос «Which person in the document has a connection to Barcelona?». Скрипт проверяет, что имён из иголок нет в романах.
• Дистракторы. Такие же фразы с другими именами и другими городами (Rijksmuseum, Charles Bridge и т. д.): 0 или 4 штуки в случайных местах.
• Сетка. Целевые длины 1K, 8K, 32K, 64K и 96K токенов, позиция иголки 10, 50 и 90% стога, 0 или 4 дистрактора, 5 иголок. Итого 150 запросов, 0 ошибок API.
• Параметры. Рассуждение выключено (reasoning: {enabled: false}), max_tokens 30, температура не передавалась: Haiku 5.5 её не принимает. Документ в тегах стоит выше вопроса, как рекомендует Anthropic. Кэш не использовался. Фактическую длину брали из usage.prompt_tokens: от 1 056 до 95 017 токенов, все запросы ниже порога 100K, после которого у Haiku 5.5 вход дороже в 5 раз.
• Оценка. Без LLM-судьи: имя из иголки в ответе считается верным, «NOT FOUND» считается отказом, всё остальное ошибкой.

Ядро скрипта (полная версия добавляет загрузку текстов, проверку иголок и параллельный запуск; chat и summary - обёртка над POST /api/v1/chat/completions OpenRouter и разбор ответа):

def build(chars, pos, needle, n_distr, rng):
    out, size = [], 0
    for p in PARAS:  # абзацы романов по порядку
        if size + len(p) > chars and out: break
        out.append(p); size += len(p) + 2
    out.insert(int(pos * len(out)), needle[1])
    distr = [p for p in POOL if p[2] != needle[2]]  # другие города
    for d in rng.sample(distr, n_distr):
        out.insert(rng.randrange(len(out) + 1), d[1])
    return "\n\n".join(out)

def ask(doc, city):
    prompt = (f"<document>\n{doc}\n</document>\n\n"
              f"Which person in the document has a connection to {city}? "
              "Landmarks count as evidence. Answer with the name only, or NOT FOUND.")
    return summary(*chat(model="anthropic/claude-haiku-5.5", max_tokens=30,
                         reasoning={"enabled": False},
                         messages=[{"role": "user", "content": prompt}]))

def grade(ans, name):
    a = (ans or "").lower()
    if name.lower() in a: return "ok"
    if "not found" in a: return "abstain"
    return "wrong"

Результат

Доля верных ответов по длине, все позиции и оба условия вместе (N = 30 на длину, 95% интервал Уилсона):

Доля верных падает с ростом длины с 97% до 60%, хотя самый длинный вход занимает меньше 10% окна модели. Интервалы на ~1K и ~95K не пересекаются, так что тренд не случайный. При такой выборке точным процентам доверять не стоит, направлению можно.

Почти все промахи оказались отказом, а не выдумкой: 117 верных ответов, 32 «NOT FOUND», 0 явно неверных имён и 1 неоднозначный ответ. Неоднозначный на ~95K с дистракторами: модель начала цитировать фразу-дистрактор про Rijksmuseum, и ответ обрезался на max_tokens. Это совпадает с наблюдением Chroma, что модели Claude чаще воздерживаются, чем галлюцинируют, но одна модель на одной задаче такую закономерность не проверяет.

Сложность сильно зависела от того, насколько далека ассоциация. Sagrada Familia → Barcelona и Brandenburg Gate → Berlin дали по 28 верных из 30, Alfama → Lisbon только 14 из 30, причём на ~8K эта иголка давала отказ в половине случаев. Название района Лиссабона связано с городом слабее, чем самые узнаваемые достопримечательности, и ломается раньше. Это тот же эффект близости вопроса и ответа, что у NoLiMa и Chroma, на другом материале.

Что не подтвердилось

Гипотеза до прогона была такой: с дистракторами точность падает с длиной быстрее, а позиция влияет слабее длины. Подтвердилась только вторая часть.

Дистракторы устойчивого эффекта не дали: на ~32K с ними даже лучше (13 против 11), на ~95K хуже (8 против 10). При N = 15 на ячейку такая разница в пределах шума. Результат Chroma о дистракторах этот замер не подтверждает и не опровергает: выборка слишком мала, а дистракторы здесь про другие города и не отвечают на вопрос даже частично.

Позиция иголки на длинах от 32K тоже заметного эффекта не дала: 23 из 30 при вставке на 10% стога, по 19 из 30 на 50% и 90%.

Методический урок первого прогона

Первый прогон на той же сетке пришлось отбросить. Вопрос звучал как «Which character has been to Barcelona?», и на ~1K без дистракторов модель нашла ответ в 1 случае из 15, остальное были отказы. Неверных имён не было: модель просто не делала вывод «живёт у Саграда Фамилии, значит, была в Барселоне» при такой формулировке. Отладка на коротком входе показала, что формулировка «has a connection to… Landmarks count as evidence» даёт 15 из 15.

Вывод для любых синтетических тестов: сначала проверьте базовую точность на коротком входе. Если на 1K модель не решает задачу, падение на длине покажет качество формулировки вопроса, а не context rot.

Ограничения замера

• Одна модель, одно семейство задач: поиск одного факта через ассоциацию. Не агентная сессия и не реальный RAG.
• Пять иголок, написанных автором, разной сложности; N = 30 на длину и 15 на ячейку, интервалы широкие.
• Один домен и язык стога: английская проза XIX века. Модель могла видеть эти романы при обучении. На коде и таблицах результат может отличаться.
• Рассуждение выключено. С включённым результат может быть другим, LongBench v2 намекает на выгоду рассуждения.
• Температуру у Haiku 5.5 задать нельзя, ответы недетерминированы. Все 150 запросов обслужил один провайдер OpenRouter, у другого поведение может отличаться.
• Длины даны в токенах Haiku 5.5. Тот же текст у другой модели даст другое число токенов, подробнее в статье про токены.
• Позиция вставки считается по абзацам, а не по токенам. Контрольного прогона без иголки в замере не было.

Стоимость основного прогона $0,60, отброшенного столько же.

Что делать с context rot

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

Держать контекст коротким

Лучше всего данными подтверждён сфокусированный вход: в эксперименте Chroma на LongMemEval все проверенные модели отвечали лучше на ~300 токенах, чем на ~113 тыс. Практические варианты:

• Retrieval вместо загрузки всего. Когда нужный фрагмент можно найти заранее, лучше передать его, чем весь корпус. Когда что выбирать, разобрано в сравнении context engineering и RAG.
• Подгрузка по требованию. Anthropic называет это just-in-time retrieval: агент держит лёгкие ссылки (пути к файлам, сохранённые запросы) и загружает данные инструментами, когда они нужны. Claude Code так и работает: CLAUDE.md грузится сразу, остальные файлы через glob и grep.
• Очистка результатов инструментов. Старые результаты вызовов редко нужны повторно. Anthropic называет их очистку одной из самых безопасных и лёгких форм компакции, в API это context editing.
• Описания инструментов. В агенте окно заполняют ещё и схемы инструментов. Сколько места занимают MCP-серверы и как их проредить, есть в отдельном разборе.

Документы сверху, вопрос в конце

Для входов от 20K токенов документация Anthropic советует ставить длинные документы в начало промпта, выше инструкций, примеров и вопроса. По тестам вендора вопрос в конце улучшает качество ответа до 30%, особенно на сложных многодокументных входах. Там же совет просить модель сначала выписать релевантные цитаты из документа, а потом отвечать по ним.

Порядок не лечит деградацию полностью. В замере выше документ стоял сверху, а вопрос в конце, и доля верных ответов всё равно упала с 97% до 60%.

Субагенты и заметки вне окна

Субагент получает чистое окно, тратит в нём десятки тысяч токенов и возвращает сжатую сводку, по описанию Anthropic часто 1-2 тыс. токенов. У этого есть цена: в замерах про субагентов Claude Code стартовый контекст субагента в тяжёлой конфигурации около 55-58 тыс. токенов. В задаче на 1-3 вызова инструментов это не окупается, в длинной задаче окупается.

Структурированные заметки вне окна (файл NOTES.md, список задач, memory tool) позволяют вернуть в контекст только нужное состояние вместо всей истории. Как спроектировать такую память, чтобы она не превратилась в свалку, разобрано в статье про память агента.

Как проверить на своей задаче

1. Соберите 10-30 примеров реальной задачи с известным ответом.
2. Убедитесь, что на коротком входе модель отвечает верно почти всегда. Если нет, исправьте формулировку, прежде чем мерить длину.
3. Наращивайте объём правдоподобного, но нерелевантного текста вокруг нужного фрагмента: 1K, 8K, 32K и дальше, до длин, которые реально встречаются в продукте.
4. Считайте отдельно верные ответы, отказы и ошибки: отказ и уверенная ошибка требуют разной обработки.
5. Длину берите из usage ответа API, а не из числа символов.
6. Добавьте похожие неверные фрагменты, если они встречаются в ваших данных, и сравните результат.

Как ломается компакция

Что делает компакция

По описанию Anthropic, компакция сжимает разговор, подошедший к лимиту окна, в сводку и продолжает работу с ней в новом окне. Claude Code при этом сохраняет архитектурные решения и нерешённые баги и выбрасывает избыточные результаты инструментов. В API есть серверная компакция (бета для моделей 4.6 и новее), в Claude Code команда /compact. Самая лёгкая форма - очистка старых результатов инструментов.

Компакция укорачивает вход и поэтому работает против context rot. Но сжатие с потерями добавляет собственные режимы отказа. Прямых измерений отказов компакции в собранных источниках нет, поэтому у каждого пункта указано, откуда он известен.

Что сохранять в сводке на контрольной точке, перечислено в гайде по context engineering.

Когда начинать с чистого окна

Документация Anthropic для задач на несколько окон предлагает рассмотреть новое окно вместо компакции: свежие модели хорошо восстанавливают состояние из файловой системы. Условие: состояние лежит в файлах (прогресс, тесты, git log), а стартовый промпт прямо говорит, что прочитать первым делом. Тогда новое окно начинается с короткого точного контекста, а не со сводки, которая могла потерять детали.

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

Ограничения и что мы не знаем

• Почти все данные о context rot получены на моделях 2023-2025 годов. Для Opus 5.5, Sonnet 5.5, Haiku 5.5 и GPT-6 опубликованных long-context измерений в первичных источниках найти не удалось, есть только агрегаторы.
• Цифры падения по моделям у Chroma здесь не приведены: они доступны только на графиках и в данных репозитория отчёта.
• Механизм деградации не установлен, известна только феноменология.
• Отказы компакции описаны по определению и косвенным данным, прямых измерений нет.
• Замер автора: одна модель, одна задача, малая выборка, все оговорки выше.
• Рекомендация Anthropic «до 30%» взята со страницы документации без даты правки и может измениться.

Первоисточники

• Hong, Troynikov, Huber. Context Rot: How Increasing Input Tokens Impacts LLM Performance. Chroma, 14 июля 2025. Код.
• Anthropic. Effective context engineering for AI agents, 29 сентября 2025.
• Anthropic docs. Context windows, Prompting best practices, Pricing, снимок 8 ноября 2026.
• Liu и др. Lost in the Middle: How Language Models Use Long Contexts. TACL, arXiv 6 июля 2023.
• Hsieh и др. RULER: What’s the Real Context Size of Your Long-Context Language Models? COLM 2024, arXiv 9 апреля 2024.
• Vodrahalli и др. Michelangelo: Long Context Evaluations Beyond Haystacks via Latent Structure Queries. arXiv 19 сентября 2024.
• Bai и др. LongBench v2. arXiv 19 декабря 2024.
• Modarressi и др. NoLiMa: Long-Context Evaluation Beyond Literal Matching. ICML 2025, arXiv 7 февраля 2025. Репозиторий с таблицей эффективной длины.
• OpenAI. MRCR, 12 апреля 2025, исправление 5 декабря 2025.
• Stanford CRFM. HELM Long Context, сентябрь 2025.
• Xia, Wang, Huang, Liu. Diagnosing and Mitigating Context Rot in Long-horizon Search. arXiv 29 июня 2026.
• Kamradt. LLMTest_NeedleInAHaystack, ноябрь 2023.