Привет, Хабр! Меня зовут Сергей Нотевский, я AI Platform Lead в Битрикс24.

Год назад индустрия жила лозунгом «Scale is all you need», перекладывая его на размер контекстного окна. 32k казались прорывом, 128k - стандартом, а Gemini с 1M+ токенов - убийцей RAG.

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

Давайте вооружимся свежими бенчмарками и разберемся, почему «поддерживаемый контекст» ≠ «рабочий контекст», что такое Context Rot (гниение контекста) и как с этим жить.

1. Маркетинг vs Физика Attention

Когда вендор пишет «Context Window: 1M», он имеет в виду техническую возможность: модель не упадет с OOM (Out Of Memory) и сможет обработать последовательность. Это заслуга инженерных оптимизаций:

• Ring Attention (Google) позволяет распараллелить обработку длинных последовательностей.

• MLA (Multi-Head Latent Attention) в DeepSeek V3/R1 драматически сжимает KV-кэш.

• PagedAttention в vLLM эффективно утилизирует память.

Но техническая способность «проглотить» токен не равна когнитивной способности его «осознать». С ростом длины контекста отношение сигнал/шум (SNR) падает.

Каждый лишний токен в промпте - это дополнительный дистрактор (отвлекающий фактор), который размывает веса внимания на действительно важных фрагментах.

2. Бенчмарки 2025: Смерть «Иголки в стоге сена»

Ранее стандартом был тест NIAH (Needle In A Haystack): вставляем случайный факт («пароль 12345») в середину «Войны и мира» и просим его найти.

В 2025 году этот тест бесполезен. Современные модели щелкают его на 100%. И даже тест на "2 иголки" считается простым.

А новая gpt-5.2 справляется и с 8 иголками до 256к контекста. Проблема в том, что NIAH проверяет способность к retrieval (поиску), а не к reasoning (рассуждению).

А в проде ломается не поиск факта, а связывание фактов, подавление шума, устойчивость к конфликтующим версиям и синтез ответа, когда в контексте одновременно есть и “правда”, и правдоподобные дистракторы.

LongBench v2 - многозадачное понимание и рассуждение на длинных входах. LongBench v2 прямо заточен под long-context reasoning в “реальных” форматах задач, длины там доходят до уровня long (128k–2M слов), и на лидерборде видны актуальные модели 2025 года. Важная деталь: результаты часто сильно зависят от режима с CoT (цепочкой рассуждений), то есть “длинный контекст” начинает упираться в reasoning-способности, а не в объём окна.

Этот бенч проверяет способность к многоходовому рассуждению, когда ответ зависит от связывания фактов А, Б и В, разбросанных по разным частям контекста.

NoLiMa: Семантический поиск

Бенчмарк NoLiMa построен так, чтобы убрать «легкий режим» (буквальные совпадения между вопросом и «иголкой») и заставить модель доставать нужное по смысловым связям. Итог жёсткий: на 32k у большинства моделей результаты падают ниже половины от короткого контекста; даже у сильных моделей заметная деградация.

То есть, если иголка не совпадает лексически с вопросом (нужен смысловой поиск), модели начинают «плыть» еще раньше.

Context Rot

Исследование Context Rot от Chroma показывает: производительность деградирует непредсказуемо. Токен в позиции 10 000 обрабатывается хуже, чем в позиции 100.

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

Топовые модели вроде Gemini 3 Pro научились справляться с эффектом Lost-in-the-Middle (когда середина контекста игнорируется) при поиске. Но для задач синтеза и обобщения эта проблема все еще актуальна. 

3. Context Engineering: Как не убить качество своими руками

Инженерная практика, когда мы начинаем рассматривать контекст как ограниченный ресурс (когнитивно, а не технически), в народе называется Context Engineering. И вот несколько выводов работы с контекстом, к которым мы пришли:

Парадокс пунктуации

В попытке сэкономить токены инженеры часто делают (и мы так пробовали) вырезание переносы строк, знаки препинания, стоп-слова - «чтобы влезло больше полезного».

Не делайте так.

Современные LLM обучались на естественных текстах. Пунктуация, отступы и переносы строк для них - это сильнейшие фичи (features), кодирующие семантические границы. Превращая текст в «токенный суп» вроде youreAIassistanthelpsmanageTelegramaccountsregularbloggergoaloffercontentideasreflectrealhumaninterestsdailyliferatherfocusingsolelytrendsmarketingstrategies, вы ломаете внутренние паттерны внимания. Экономия 5% токенов может стоить 15% качества генерации. Это подтверждено исследованием, где доказано что удаление «мелких» токенов (включая запятые, стоп-слова и т.п.) стабильно ухудшает результаты на задачах вроде MMLU и long-context-reasoning.

Структура важнее хаоса (но есть нюанс)

Для инструкций структура критична. Google и OpenAI в своих гайдах 2025 года прямо говорят: используйте XML-теги или Markdown-заголовки.

# Context ...

#Role ...

#Task ...

Это работает как «якоря» для внимания LLM.

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

Саммаризация vs «Сырые данные»

Для задач рассуждения лучше давать сырые данные, но мало. Для задач вроде чатов лучше давать саммари и можно в больших объемах.

Если вы просите модель «подумать» над 100k токенов сырых логов, она скорее всего потеряется в деталях. Лучшая стратегия - иерархическая саммаризация (Map-Reduce) до того, как данные попадут в промпт.

«Умные ножницы»: вырезайте то, что превращается в дистракторы

Самые токсичные токены в продовых системах:

• старые tool-calls и их подробные результаты,

• промежуточные рассуждения «как я думал»,

• устаревшие правила («раньше мы отвечали так»),

• длинная болтовня из истории диалога.

Если это оставлять как есть, вы сами наращиваете context rot.

Хороший паттерн: после каждого шага обновлять «память» не полным логом, а сжатыми фактами:

• что пользователь хотел,

• какие факты установлены,

• какие решения приняты, что устарело/переписано.

4. Экономика длинного контекста и Context Caching

Даже если качество вас устраивает, есть вопрос денег и латентности (Time To First Token).
Обработка 1M токенов на вход - это секунды (или десятки секунд) префилла (Prefill Phase), которые убивают интерактивность.

Лучшее решение - Context Caching.
Anthropic, Google, DeepSeek и локальные движки вроде vLLM поддерживают кэширование префикса.
Как это работает: Если первые 900k токенов вашего промпта (системный промпт + база знаний + примеры) не меняются, их KV-состояния сохраняются в памяти GPU/CPU. Профит: Следующий запрос платит только за «дельту» (новые 100 токенов). Цена падает на 90%, скорость префилла растет в 10-50 раз.

Практический совет: Проектируйте промпты так, чтобы статическая часть всегда была в начале.
[Static System Prompt] + [Static RAG Knowledge] + [Dynamic User Query] - Хорошо.
[System Prompt] + [Dynamic User Query] + [Static RAG] - Плохо (кэш инвалидируется из-за динамической вставки в середине).

5. Итог: Убьет ли 10M токенов RAG?

Нет.
Тут мне нравиться позиция Nikolay Savinov (co-lead Gemini Long Context) в недавнем интервью: 10M токенов работают, но требуют огромного железа и стоят дорого. Надежные 100M требуют нового архитектурного прорыва.
В ближайшие годы мы будем жить в гибридной парадигме:
- RAG для поиска и первичной фильтрации (снижаем энтропию входа).
- Большой контекст - для загрузки отфильтрованного «жирного» куска данных (десятки-сотни тысяч токенов), чтобы модель могла связать факты.

Чек-лист для инженера в 2025:

• Считайте эффективный контекст, а не маркетинговый. Тестируйте модель на ваших данных с разной длиной.

• Используйте Context Caching для статики - это лучшая практика для снижения стоимости и задержки ответов.

• Не удаляйте пунктуацию и разметку ради экономии токенов.

• Внедряйте «Умные ножницы»: вырезайте из контекста отработанные вызовы инструментов и старые промежуточные рассуждения, чтобы избежать context rot.

В своем tg-канале я веду рубрику #300tps, где разбираю именно инженерную сторону: бенчмарки vLLM, замеры latency и оптимизацию инференса. Заходите, если вам тоже важно, что под капотом, а не в пресс-релизе.