Всем привет! В первой части мы разобрали теорию: почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются.

Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене?

Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного.

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

Каково состояние на текущий момент?

Ну хорошо, эффект lost in the middle обнаружили, позиционное смещение показали, даже наметили его основные причины. А дальше что? Кажется, что за прошедшие несколько лет уже должны были найти решение этой проблемы, но на практике всё гораздо менее однозначно.

Во‑первых, если говорить о мейнстримных авторегрессионных LLM, от каузального внимания сейчас никуда не уйти.

Практически все современные большие языковые модели обучаются на задаче предсказания следующего токена по предыдущим: каждый токен на каждом слое может смотреть только назад. Это базовый механизм трансформеров‑декодеров, обеспечивающий генерацию текста слева направо. Работы про attention sink и стриминговым моделям [1,2] показывают, что именно каузальная организация внимания и процесса обучения приводят к систематическому завышению вкладов первых токенов. Эти токены начинают получать непропорционально высокие веса внимания от последующих токенов, даже когда они почти не несут семантики. В итоге они превращаются в «раковины/поглотители внимания» (attention sinks), куда стекается значительная часть внимания, а остальным токенам остаётся лишь малая его доля.

Теоретически, можно уйти в совсем другие архитектуры (RetNet, Mamba, Hyena и так далее), где нет классического self‑attention, но это уже другие семейства моделей, которые пока в основном находятся в исследовательской фазе [3-5].

Во‑вторых, от RoPE сейчас тоже никто массово не отказывается.

Роторное позиционное кодирование (RoPE), предложенное в RoFormer [6], стало де‑факто стандартом: LLaMA, LLaMA-2/3, Mistral, Mixtral, Gemma, многие Qwen‑семейства и другие открытые SOTA‑модели используют именно RoPE или его модификации [7].

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

По сути, исследования ведутся в двух основных направлениях:

• Выравнивание внимания без дообучения моделей и изменения механизма внимания или позиционного кодирования: либо переинтерпретируют/калибруют уже вычисленные attention‑веса, либо управляют контекстом и позициями на этапе инференса [1, 8-10].

• Изменение механизма позиционного кодирования, в основном модификация RoPE для более сглаженного распределения весов по позициям токенов. Тут целью является изменить саму форму позиционного кодирования, чтобы ослабить long‑term decay (долгосрочный распад) для дальних токенов и сделать чувствительность по позициям более гладкой, без «провалов» в середине [11-14].

Таким образом, разработчики моделей всячески стараются справиться с этим ограничением LLM, но подтверждений о преодолении эффекта «потерянного в середине» и снижении влияния позиционного смещения нет. Каждый поставщик моделей всякий раз заявляет о расширении окна, о невероятных метриках работы с контекстом и все более успешном решении как теоретических, так и прикладных задач. Но на деле — мы до сих пор видим ухудшение качества работы моделей на длинных контекстах.

А сколько текста модель учитывает эффективно?

Предложены бенчмарки, которые помогают оценить возможности моделей извлекать полезную информацию из контекста. Один из первых и наиболее популярных — «иголка в стоге сена» (Needle‑in‑a-Haystack, NIAH). Это тест, ориентированный на проверку возможностей модели вытащить из длинного текста заранее вставленный туда «секретный» фрагмент. На сегодняшний день, современные модели практически идеально справляются с такой задачей.

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

RULER: как модель извлекает несколько фактов из контекста

Бенчмарк RULER [15] приближает задачу работы LLM к более прикладному использованию: модель должна извлекать несколько фактов или выбирать правильную «иглу» среди нескольких вставок релевантной информации в зашумлённый контекст.

Конфигурация и результаты эксперимента

В эксперименте авторы тестируют 17 длинноконтекстных LLM (15 open‑source и 2 закрытые: Gemini-1.5-Pro и GPT-4) разных размеров от 7B до 8×22B (MoE), с заявленным окном от 32k до 1M токенов. Все модели запускают в одинаковых условиях при длинах контекста от 4k до 128k. Ответ засчитывается, если правильный вывод присутствует в сгенерированном тексте.

В качестве порогового значения берут качество Llama2-7B на длине 4k (85.6%) и определяют эффективную длину контекста как максимальную длину, на которой средняя точность модели по всем задачам выше этого порога.

Таблица результатов демонстрирует явное расхождение между заявленным окном контекста и окном, в котором модель эффективно решает задачи извлечения информации:

Для контраста, можно посмотреть результаты моделей на стандартном наборе задач NIAH, где большинство моделей дают почти 100% точности даже на очень длинных контекстах, что подчёркивает: «найди дословную фразу» не является хорошим индикатором реальных способностей модели к работе с длинным контекстом.

Вывод по RULER

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

Это позволяет эмпирически оценить эффективную длину контекста: для топовых моделей она оказывается меньше половины заявленного окна, а для нишевых моделей – иногда на порядок ниже. Уже на этом этапе видно, что поддержка окна 128k–1M токенов не является гарантией способности надёжно извлекать и комбинировать факты на всей этой длине.

NoLiMa: как модель извлекает ассоциативную информацию из контекста

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

Этот пробел пытаются закрыть в работе NoLiMa: Long‑Context Evaluation Beyond Literal Matching [16]. Авторы формируют бенчмарк, в котором вопросы и «иглы» содержат ключевые слова, связанные ассоциативно (через знания о мире или здравый смысл), а прямых лексических совпадений почти нет.

В NoLiMa эксперимент устроен аналогично RULER. Оценивают 12 популярных моделей с заявленным окном ≥128k токенов на длинах 250 - 32k.

В отличие от RULER, где порог качества фиксирован, здесь для каждой модели отдельно считают base score — среднюю максимальную точность на коротких длинах (250/500/1k). Эффективная длина определяют как максимальную длину контекста, на которой средняя точность остаётся ≥85% от этого base score.

Таблица результатов демонстрирует еще более драматичные цифры:

Lost in the middle и общий провал качества

В работе NoLiMa также исследуется эффект lost in the middle. В анализе глубины вставки иглы авторы двигают факт по всему окну (до 32k токенов) и получают классическую картинку: для простых «одношаговых» задач (one‑hop) качество заметно проваливается, когда нужный фрагмент оказывается в середине контекста, тогда как начало и конец держатся лучше.

Для более сложных двухшаговых ассоциаций (two‑hop) картина другая: при увеличении длины контекста просаживается уже вся кривая, включая края, то есть проблема выходит за рамки чисто позиционного эффекта. Чтобы разделить влияние позиции и общей нагрузки на внимание, авторы вводят режим «Last 2K», где игла всегда лежит в последних 2k токенов, а общий размер контекста растёт. В этом режиме относительная позиция факта и вопроса фиксирована, и становится видно, что для сложных задач деградация качества связана не только с «потерей середины», а с тем, что модели в принципе тяжело надёжно извлекать ассоциативную информацию на фоне очень длинного нерелевантного контекста.

Вывод по NoLiMa

Тест NoLiMa даёт гораздо менее оптимистичную картину работы моделей с длинными контекстами в сценариях, похожих на реальные задачи извлечения знаний. Эффективная длина окна здесь уже не превышает 8k токенов (для GPT-4o, при заявленных 128k), то есть примерно в 16 раз меньше обещанного, а для большинства моделей — всего порядка 2k токенов, что уже в 60+ раз меньше заявленного окна.

Таким образом, оба бенчмарка показывают схожую картину: несмотря на большие заявленные окна и успехи на «ванильном» NIAH, эффект lost in the middle и общая перегрузка внимания при росте контекста до сих пор не преодолены. Расширение контекстного окна означает, что модель способна технически принять на вход сотни тысяч токенов, но это не гарантирует, что она сможет надёжно проанализировать этот объём и сделать сложные (и даже не слишком сложные) аналитические выводы по всей длине контекста.

Основные рекомендации по архитектурным решениям LLM‑приложений для эффективного учёта контекста

С учётом обсуждённых выше эффектов потери в середине, позиционного смещения, долгосрочного распада (lost in the middle, positional bias, long‑term decay) и общей сложности ассоциативного связывания в длинных контекстах, архитектурные решения LLM‑приложений имеет смысл планировать с опорой на следующие принципы:

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

• Разделяйте «долгую память» и «рабочую память». Историю диалога, факты и прошлые ответы храните во внешнем хранилище (БД, векторное хранилище), а в промпт поднимайте короткую аннотацию (summary) и несколько действительно релевантных кусочков, вместо того чтобы каждый раз тащить всё.

• Используйте ретривер и ранжирование, а не «сырой слив» документов. Сначала отберите топ‑N кандидатов (BM25/векторный поиск), затем сузьте их до k самых полезных (re‑ranking отдельной моделью или самой LLM) — и только их подавайте в промпт.

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

• Используйте шаблоны и сигнатуры вместо «простыни» правил. Задайте 2–3 режима работы и формат ответа (JSON‑схема, пара примеров), вместо десятков частных «если/то», которые раздувают промпт и мешают модели увидеть нужный текст.

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

• Не дублируйте в промпте то, что модель и так знает. Общие знания (география, базовые определения, школьная математика) лучше оставить на совести LLM, а окно тратить на доменные, свежие и локальные факты.

• Контролируйте рост системного промпта и проверяйте «короткую версию». Если инструкции превратились в целую повесть, это сигнал к рефакторингу: вынесите часть логики в код/конфиг и обязательно сравните качество на коротком и длинном варианте промпта. Короткий промпт на практике часто работает не хуже длинного, а с учётом контекста даже лучше.

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

Если тема кажется вам интересной, я продолжаю разбирать подобные вещи у себя в Telegram короткими постами, экспериментами и примерами из практики: «надо разобраться | заставляем LLM работать».

Литература:

1. Efficient Streaming Language Models with Attention Sinks

2. When Attention Sink Emerges in Language Models: An Empirical View

3. Retentive Network: A Successor to Transformer for Large Language Models

4. Mamba: Linear‑Time Sequence Modeling with Selective State Spaces

5. Hyena Hierarchy: Towards Larger Convolutional Language Models

6. RoFormer: Enhanced Transformer with Rotary Position Embedding

7. RoPE: Rotary Positional Embedding

8. Found in the Middle: Calibrating Positional Attention Bias Improves Long Context Utilization

9. YaRN: Efficient Context Window Extension of Large Language Models

10. LongRoPE2: Near‑Lossless LLM Context Window Scaling

11. Found in the Middle: How Language Models Use Long Contexts Better via Plug‑and‑Play Positional Encoding

12. Understanding the RoPE Extensions of Long‑Context LLMs: An Attention Perspective

13. VRoPE: Rotary Position Embedding for Video Large Language Models

14. 3D‑RPE: Enhancing Long‑Context Modeling Through 3D Rotary Position Encoding

15. RULER: What's the Real Context Size of Your Long‑Context Language Models?

16. NoLiMa: Long-Context Evaluation Beyond Literal Matching