«Lost in the middle»: почему модель теряет середину контекста

Термин lost in the middle закрепился после препринта Lost in the Middle: How Language Models Use Long Contexts, поданного на arXiv 6 июля 2023 года и вышедшего в TACL в феврале 2024 года. Суть наблюдения проста и неприятна для практики: модель с длинным контекстом не обязательно одинаково хорошо использует все части входа. В задачах, похожих на RAG, релевантный фрагмент часто лучше срабатывает в начале или в конце промпта, чем в середине. Последующие работы 2024 года уточнили: проблема не сводится к «маленькому окну» и не исчерпывается простыми тестами на поиск одной строки в длинном тексте.

Контекст: от длинного окна к проблеме середины

В 2023–2024 годах длинный контекст стал одной из главных линий развития LLM. Но на практике быстро выяснилось, что вопрос состоит не только в том, сколько токенов модель может принять, но и в том, как она ими пользуется. Именно этот разрыв и вскрыла работа Liu и соавторов.

Для RAG это особенно важно. Типичный пайплайн сначала ищет документы, потом склеивает найденные фрагменты в один prompt и просит модель ответить. Если качество ответа зависит от того, где именно в этой склейке лежит нужный кусок, то у вас появляется скрытая переменная: две системы с одинаковым retriever могут давать разный результат только из-за layout контекста.

Поздние бенчмарки 2024 года подтвердили, что «длинный контекст» нельзя оценивать одним числом. LongBench показал, что реальные длинные задачи разнообразны: от multi-document QA до суммаризации и кода. RULER отдельно подчеркнул, что классический needle-in-a-haystack проверяет лишь поверхностный случай — буквальное извлечение из длинного текста — и потому легко переоценивает реальные возможности модели.

Иными словами, историческое окно 2023–2024 годов дало важную развилку. До него длинный контекст часто понимали как увеличение лимита токенов. После него стало труднее игнорировать второй вопрос: умеет ли модель одинаково надёжно использовать начало, середину и конец этого контекста.

Метод: как измеряли эффект «lost in the middle»

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

Основной сценарий — multi-document question answering на NaturalQuestions-Open. В каждый prompt помещали один документ с ответом и набор distractor-документов без ответа. Затем релевантный документ переставляли: ближе к началу, в середину или к концу. Отдельно увеличивали число distractor-документов, то есть длину контекста, не меняя правильный ответ.

Второй сценарий — synthetic key-value retrieval. Здесь задача проще: модели дают сериализованный набор пар ключ–значение и спрашивают нужный ключ. Такой тест нужен, чтобы проверить минимальную способность извлечь точное соответствие без сложной семантики и без «настоящего» чтения нескольких документов.

В исторической конфигурации статьи сравнивались тогдашние открытые и закрытые модели, включая обычные и extended-context варианты. Это важно читать именно как снимок состояния на 2023 год, а не как сравнение актуальных API-моделей сегодня. Авторы также сделали абляции: decoder-only против encoder-decoder, влияние query-aware contextualization и влияние instruction fine-tuning.

Работа Found in the Middle в 2024 году добавила следующий слой: она уже не только наблюдала провал по позиции, но и пыталась связать его с внутренним распределением внимания. Авторы утверждают, что у моделей проявляется U-образный bias внимания: токены и документы у краёв получают повышенный вес независимо от реальной полезности.

Результаты: что показали эксперименты

Источник	Что проверялось	Устойчивый вывод	Практический смысл
Lost in the Middle	Multi-document QA с перестановкой релевантного документа	Качество обычно лучше у начала и конца контекста, а середина проседает	В RAG важно не только что retrieved, но и где это лежит в prompt
Lost in the Middle	Synthetic key-value retrieval	Даже более простое точное извлечение может деградировать в середине	Проблема не сводится только к сложному reasoning
LongBench	Разные реальные длинные задачи	Большой контекст и retrieval помогают, но не гарантируют устойчивого long-context understanding	Нельзя судить о качестве только по одному длинному тесту
RULER	Расширенные synthetic long-context задачи	Хороший результат на простом needle-in-a-haystack не означает устойчивость к шуму и усложнению задачи	Нужны более строгие evals для RAG и long-context QA
Found in the Middle	Анализ attention bias и калибровка внимания	Позиционный bias выглядит как отдельный фактор, который можно пытаться компенсировать	Порядок и позиционная инженерия — не косметика, а реальный рычаг качества
Long-Context LLMs Meet RAG	RAG с разным числом passages и reordering	При росте retrieved context качество может сначала расти, а затем падать; reordering помогает как training-free мера	Увеличение top-k без layout-политики может ухудшать ответ

Главный вывод Liu и соавторов — U-образная кривая по позиции. Если релевантный фрагмент поставить в начало или конец, ответ чаще оказывается лучше. Если тот же самый фрагмент закопать в середину, качество падает. Это наблюдалось не только на одном типе модели и не только на одном типе задачи.

Не менее важен второй вывод: extended-context версия модели не обязана лучше использовать контекст, если один и тот же prompt и так помещается в обычное окно. То есть увеличение лимита токенов само по себе не устраняет позиционный bias. Это хорошо согласуется и с более поздними оценками LongBench и RULER, где «способность вместить» и «способность понять» тоже расходятся.

Третий вывод — о границах простых тестов. В самой Lost in the Middle часть моделей неплохо справлялась с synthetic retrieval, но это почти не гарантировало такой же устойчивости на multi-document QA. RULER довёл эту мысль дальше: модели могут выглядеть сильными на буквальном поиске одной «иголки», а потом ломаться, когда появляется несколько distractors, tracing через длинный контекст или необходимость агрегировать разбросанную информацию.

Наконец, абляции Liu et al. показали, что некоторые интуитивные патчи помогают ограниченно. В конфигурации самой статьи query-aware contextualization заметно помогало на synthetic key-value retrieval, но почти не меняло общую картину в более реалистичном multi-document QA. Это важный анти-хайповый вывод: не каждый приём prompt layout одинаково переносится с игрушечного теста на рабочий сценарий.

Интерпретация

На уровне инженерного смысла lost in the middle лучше понимать не как «LLM не умеют в длинный контекст», а как сочетание двух эффектов: позиционной чувствительности и чувствительности к шуму. Чем длиннее prompt, тем выше шанс, что полезная информация окажется между двумя проблемами: её труднее выделить, и её легче перебьют ближайшие к краям distractors или более «громкие» фрагменты.

Работа Found in the Middle полезна тем, что предлагает правдоподобное объяснение: дело не только в retrieval, а в самом механизме распределения внимания. Если bias к краям есть независимо от релевантности, то naively склеенный RAG-контекст будет систематически подталкивать модель к ошибкам layout-а.

Наш комментарий

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

1. Измеряйте не только recall ретривера, но и чувствительность к позиции. Если ответ падает после перестановки чанков, узкое место может быть не в поиске, а в layout prompt.
2. Не закапывайте лучший чанк в середину по умолчанию. Гипотеза для A/B-теста: ставить самый сильный фрагмент ближе к краю контекста или рядом с вопросом. Это не универсальный закон, но в RAG такая проверка дешёвая и часто полезная.
3. Ограничивайте шум. Дубликаты, почти релевантные hard negatives и слишком длинные куски могут вредить сильнее, чем отсутствие ещё одного passage.
4. Разделяйте политику выбора и политику размещения. Ретривер отвечает за то, что выбрать; orchestration-слой — за то, как это упаковать в prompt.
5. Не верьте одному длинному benchmark. Если система хороша только на needle-style тесте, это ещё не доказательство устойчивого long-context reasoning.

Если задача требует использовать несколько разнесённых фрагментов сразу, имеет смысл проверять и более структурные меры: промежуточный отбор evidence, краткую компрессию перед ответом, либо двухшаговый режим «сначала найди важные места, потом отвечай». Именно к этому направлению логично ведут и Found in the Middle, и Long-Context LLMs Meet RAG.

Ограничения и критика

• Исторический срез. Базовая статья фиксирует состояние моделей 2023 года, а этот разбор сознательно держится рамки 2023–2024. Новые модели могли изменить масштаб эффекта, но это не отменяет исторического вывода о том, как сама проблема была обнаружена и формализована.
• Не все типы задач покрыты одинаково. В центре внимания — multi-document QA, synthetic retrieval и benchmark-задачи длинного чтения. Это не полный срез для кода, tool use, мультимодальности или долгих агентных траекторий.
• Причина эффекта до конца не закрыта. Работы 2024 года связывают его с U-образным bias внимания, но retrieval quality, chunking, template, hard negatives и близость вопроса к evidence тоже заметно влияют на результат.
• Не всякий production RAG ведёт себя как paper setup. Если у вас есть reranker, компрессия, iterative retrieval, цитирование passage IDs или отдельный шаг evidence selection, реальный ущерб от «середины» может быть меньше, чем в наивной схеме concatenate-and-ask.
• Простые mitigation-стратегии не универсальны. Reordering часто помогает, но может навредить там, где важен исходный порядок документа, временная последовательность или логика повествования.

Вывод

Lost in the middle — это не мем про «тупую модель на длинном контексте», а аккуратно зафиксированная инженерная проблема: модель может принять длинный prompt, но использовать его неравномерно. Для RAG это означает, что качество определяется не только retrieval и не только размером окна, а ещё и тем, как именно вы размещаете доказательства внутри контекста.

Если упростить до одной практической формулы, она звучит так: long context требует context engineering. Прежде чем увеличивать top-k или просто «впихивать больше текста», полезнее проверить порядок чанков, уровень шума и устойчивость системы к позиционным перестановкам.

Источники

• Lost in the Middle: How Language Models Use Long Contexts
• Lost in the Middle: How Language Models Use Long Contexts (arXiv)
• LongBench: A Bilingual, Multitask Benchmark for Long Context Understanding
• RULER: What’s the Real Context Size of Your Long-Context Language Models?
• Found in the Middle: Calibrating Positional Attention Bias Improves Long Context Utilization
• Long-Context LLMs Meet RAG: Overcoming Challenges for Long Inputs in RAG

FAQ

Значит ли это, что длинный контекст бесполезен?

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

Что проверять в RAG первым делом?

Обычно полезнее всего сделать A/B-тест по числу чанков и по их порядку, а затем вручную переставить gold-пассаж из края в середину. Если качество резко меняется, проблема может быть в context layout, а не в retriever.

Достаточно ли needle-in-a-haystack для оценки long-context модели?

Скорее нет. По RULER такие тесты ловят прежде всего буквальное извлечение. Для реальной системы нужны сценарии с distractors, несколькими опорными кусками, агрегацией и вопросами, где одного exact match недостаточно.

Читайте также

• Длинный контекст против RAG: кто побеждает на практике
• Gemini 1.5 и окно в 1–10 млн токенов: что это значило на практике
• Self-RAG и Corrective RAG: как работает самопроверка в RAG
• Три оси масштабирования LLM: данные, параметры и вычисления вывода