Модели с миллионом токенов забывают середину — что делать

Вы вставляете в чат-бота двадцать страниц договора и просите найти пункт про неустойку. Модель отвечает уверенно и мимо: цитирует условие с первой страницы и игнорирует нужный абзац из середины. Это не галлюцинация в привычном смысле и не ошибка в вашем промпте. Это lost in the middle — систематический провал внимания к информации, которая оказалась не в начале и не в конце длинного контекста.

Явление описали исследователи из Стэнфорда, Беркли и Samaya AI в работе «Lost in the Middle: How Language Models Use Long Contexts» (Liu et al., 2023). Они проверяли, как точность ответа зависит от того, в каком месте длинного окна лежит нужный факт. Результат оказался неудобным для всей индустрии, которая как раз наращивала размеры контекста.

Что именно ломается

Авторы давали моделям набор документов и вопрос, ответ на который содержался ровно в одном из них. Меняли только позицию этого документа. Если релевантный фрагмент стоял первым или последним, точность была высокой. Если он оказывался в середине — падала, иногда до уровня, когда модель вообще не видела нужный документ.

Кривая точности по позиции получалась U-образной: высоко по краям, провал в центре. Причём эффект наблюдался и у моделей, специально заявленных как «длинноконтекстные». Расширенное окно¹ само по себе не гарантирует, что модель одинаково хорошо работает со всем его объёмом.

Размер контекстного окна говорит о том, сколько текста модель примет на вход. Он ничего не говорит о том, насколько ровно она этот текст прочитает.

С практической точки зрения это значит простую вещь. Заявление «контекст 1 000 000 токенов» — это про вместимость, а не про надёжность извлечения. Между «модель приняла ваш текст» и «модель нашла в нём нужное» лежит зазор, и середина длинного промпта — самое опасное место в этом зазоре.

Почему так происходит

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

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

Что из этого главная причина — вопрос открытый. Для практика важнее следствие: нельзя рассчитывать, что модель одинаково внимательна ко всему, что вы в неё загрузили.

Как это выглядит в реальных задачах

Эффект бьёт по сценариям, где вы намеренно кормите модель большим объёмом:

• Анализ документов. Договоры, отчёты, техзадания. Ключевое условие в середине файла модель может «не заметить».
• RAG-системы.² Вы достаёте из базы десять фрагментов и складываете в промпт. Если самый релевантный оказался пятым-шестым, ответ ухудшится, хотя нужный текст физически в контексте есть.
• Длинные диалоги. Инструкция, заданная в середине разговора, теряется сильнее, чем системный промпт в начале или последняя реплика.
• Сводка нескольких источников. Модель охотнее опирается на первый и последний из десятка приложенных материалов.

Как проверить, что вы столкнулись именно с этим

1. Возьмите задачу, где модель ошибается на длинном вводе.
2. Сократите ввод до одного нужного фрагмента и повторите запрос. Если ответ стал верным — дело не в понимании, а в позиции.
3. Переставьте нужный фрагмент в начало или конец промпта, не меняя формулировку вопроса. Если точность выросла — это lost in the middle.

Что с этим делать на практике

Полностью убрать эффект пользователь не может — это свойство модели. Но снизить его влияние реально почти бесплатно.

Управляйте позицией

Раз края читаются лучше — ставьте туда важное. Ключевую инструкцию или вопрос дублируйте в конце промпта, после всех данных. В RAG сортируйте извлечённые фрагменты так, чтобы самые релевантные оказались в начале и в конце списка, а не в середине.

Режьте объём

Меньше мусора в контексте — меньше поводов для разбавления внимания. Не грузите весь документ, если задача решается по трём абзацам. Лучше более точная выборка на входе, чем «загружу всё, модель разберётся».

Дробите и переспрашивайте

Разбейте большой документ на части, задайте вопрос по каждой отдельно, затем объедините ответы. Это дороже по числу запросов, но точнее. Отдельный приём — попросить модель сначала выписать все релевантные фрагменты, а потом отвечать только по ним.

Кому это важно, а кому можно не думать

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

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

Отдельно стоит держать в голове маркетинг вендоров. Числа вроде «128k», «200k», «1M токенов» — это верхняя граница вместимости. Насколько ровно модель работает на всём этом объёме, лучше проверять самому на своей задаче: составить тест, где нужный факт лежит в разных местах длинного ввода, и посмотреть, где точность падает. Публичные бенчмарки на длинный контекст существуют, но переносить их результат на вашу конкретную задачу без проверки не стоит.

¹ Контекстное окно — максимальный объём текста (в токенах), который модель принимает на вход за один запрос, включая ваш промпт и её ответ. Токен — примерно часть слова.

² RAG (retrieval-augmented generation) — подход, при котором система сначала ищет релевантные фрагменты в базе данных, а затем подставляет их в промпт модели, чтобы та отвечала по ним, а не только по «памяти».