Context Rot: почему LLM работает хуже на длинном контексте

· 1 мин чтения
context-engineering context-management llm benchmarks research
Context Rot: почему LLM работает хуже на длинном контексте

Проверять, умеет ли модель работать с длинным контекстом, обычно так: берут факт, прячут его в середине длинного текста и просят найти. Это тест Needle in a Haystack («иголка в стоге сена»). Модели с окном в миллион токенов дают на нём почти идеальный результат, и кажется, что вопрос снят.

Команда Chroma проверила 18 моделей — GPT-4.1, Claude 4, Gemini 2.5, Qwen3 — на более честных тестах и обнаружила, что качество падает по мере роста входного текста. Причём падает неравномерно: качество зависит не только от длины, но и от того, как именно устроен текст. Это и есть context rot — «гниение контекста».

И почему старый тест не работает

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

Есть и вторая проблема. В большинстве тестов длинный текст — это просто способ увеличить вход. Меняется объём, а вместе с ним меняется и сложность задачи. Из-за этого нельзя понять, что именно мешает: длина текста или сама задача стала труднее. Авторы выбрали другой подход: сложность задачи держится постоянной, меняется только длина входа.

Четыре эксперимента

Похожесть вопроса и факта. Сначала авторы брали пары «вопрос — факт» с похожими формулировками. Затем они измерили, насколько похожи тексты вопроса и факта, с помощью эмбеддингов (векторных представлений текста). Оказалось, что чем меньше эта похожесть, тем быстрее падает качество при росте входа. На коротком контексте модели справляются даже с непохожими парами. Разница появляется только на длинном. Позиция факта в тексте при этом роли не играла: авторы проверили 11 позиций и заметной разницы не нашли.

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

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

Похожесть факта на окружающий текст. Интуиция подсказывает, что спрятанный факт, похожий на остальной текст, найти труднее. Проверили и получили неожиданный результат. В тексте из эссе Пола Грэма факт про эссе находился лучше, чем факт про научные статьи: когда факт выбивается из общего контекста, его проще заметить. В тексте из статей arXiv разница между «своим» и «чужим» фактом была минимальной. Вывод авторов осторожный: двух тем недостаточно для общего правила, но зависимость результата от похожести факта и фона — реальная.

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

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

LongMemEval: чистый контекст против полного

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

Условия были такие. В первом в промпт попадали только те части истории, которые нужны для ответа, примерно 300 токенов — модели оставалось только рассуждать. Во втором использовался полный вход LongMemEval, около 113 тысяч токенов, где много постороннего текста и встречаются отвлекающие фрагменты, похожие на нужные. Из набора в 306 вопросов авторы убрали 38 слишком неоднозначных.

На укороченных промптах модели справляются хорошо. На полных результат падает у всех семейств — GPT, Gemini, Qwen, Claude. Разрыв больше всего у Claude, и он связан с отказами отвечать: модель не находит однозначного ответа и честно сообщает об этом, вместо того чтобы угадать.

Режим размышления (thinking) помогает на обоих типах входа, но разрыв между ними не закрывает.

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

Повторение слов: проверка на простой задаче

Здесь длина входа растёт вместе с длиной ответа. Модели дают последовательность из повторяющихся слов с одним уникальным словом и просят воспроизвести её дословно. Задача максимально простая, и в теории модель должна выполнять её идеально.

Результат: качество падает у всех. Чаще всего модель просто доходит до лимита ответа, не закончив последовательность. Точность позиции уникального слова выше, когда оно стоит в начале. Claude Sonnet 3.5 показывает лучший результат, пока длина ответа не превышает её лимит в 8192 токенов. Более новые Opus 4 и Sonnet 4 работают хуже.

Отдельная находка — модели отказываются выполнять задачу. Opus 4 отказывался в 2,89% случаев, GPT-4.1 — в 2,55%. Причём отказы бывают странными: Opus 4 решил, что это может быть авторский текст, и отказался воспроизводить его дословно. Gemini 2.5 Pro на длинных входах начинает выдавать случайные символы. GPT-4.1 nano в паре «San Francisco» / «sf» периодически выдаёт слово с маленькой буквы.

Что это значит для работы

Выводы отчёта сводятся к двум пунктам.

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

Второй: важно не только, есть ли нужная информация в контексте, но и то, как она подана. Отсюда практический вывод — контекст нужно собирать вручную, подбирая объём, порядок и структуру, а не просто скармливать модели всё подряд. Разница между 300 и 113 тысячами токенов в одном и том же тесте — это и есть цена лишнего контекста.

Полный код экспериментов лежит в репозитории: https://github.com/chroma-core/context-rot

Ограничения

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

Механизм падения отчёт не объясняет. Есть гипотеза о влиянии структуры входа на механизм внимания, но проверить её в рамках работы не получилось — это задача для более глубокого изучения того, как модели работают изнутри.

Источник: https://www.trychroma.com/research/context-rot