Миф: чем длиннее контекст, тем лучше ответ модели

MAATRIX

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

Откуда взялся миф про размер контекста

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

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

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

Эффект "потери в середине" (lost in the middle)

Одна из наиболее изученных и воспроизводимых проблем длинного контекста получила название lost in the middle — потеря в середине. Суть в следующем: если релевантный фрагмент информации находится в начале или в конце длинного контекста, модель извлекает и использует его заметно надёжнее, чем если тот же фрагмент помещён в середину. Форма зависимости у разных моделей и задач выглядит по-разному, но общая закономерность — просадка именно в средней части контекста — воспроизводится достаточно устойчиво, чтобы считаться реальным, а не случайным эффектом.

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

Практические выводы для сборки промпта:

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

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

Разбавление внимания нерелевантным контекстом

Второй механизм, из-за которого «больше контекста» не равно «лучше ответ», — это разбавление внимания (attention dilution). Механизм внимания в трансформере распределяет «вес» между всеми токенами контекста при формировании каждого следующего токена ответа. Когда в контекст добавляется большой объём информации, не относящейся напрямую к вопросу, модели приходится буквально «просеивать» весь этот объём, чтобы найти релевантные фрагменты — и часть внимания неизбежно уходит на нерелевантные токены просто по факту их присутствия в контексте.

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

Характерные ситуации, где разбавление внимания проявляется особенно заметно:

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

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

Стоимость и задержка растут быстрее, чем качество

Даже если бы длинный контекст не терял в качестве, у него есть отдельная, чисто инженерная цена — и она растёт быстрее, чем линейно. Обработка контекста (этап prefill — предварительный проход по всему входному контексту до начала генерации ответа) требует вычислений, объём которых растёт с длиной контекста нелинейно из-за механизма self-attention, где каждый токен потенциально связан с каждым. На практике это означает: удвоение длины контекста увеличивает время и стоимость обработки не в два раза, а заметно больше.

Помимо вычислений на этапе prefill, растёт и память: KV-кеш (сохранённые промежуточные представления по каждому токену контекста, нужные для генерации) линейно растёт с длиной контекста и занимает видеопамять на протяжении всего запроса. Механика KV-кеша подробно разобрана в статье контекст на 128 тысяч токенов: цена в памяти и в скорости — там же приведён реальный случай, когда рост контекста диалога привёл к деградации времени ответа, разобранный в статье контекст вырос до 100 тысяч токенов, и ответы стали по четыре минуты.

Практическая цена «пихнуть в контекст всё, что есть» складывается из нескольких статей:

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

Итог: длинный контекст — не бесплатная опция «на всякий случай», а осознанный компромисс, где вы платите временем и деньгами за каждый добавленный токен, вне зависимости от того, помогает он ответу или нет.

Качество отбора важнее объёма: что делать вместо "пихать всё"

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

• Релевантный поиск вместо полного дампа данных. Если источник ответа — база документов, используйте векторный поиск или RAG, чтобы отобрать только релевантные фрагменты под конкретный вопрос, вместо того чтобы вставлять в контекст весь корпус. О том, что реально происходит внутри такого поиска между вопросом и ответом, разобрано в статье что происходит внутри RAG между вопросом и ответом.
• Реранкинг найденных фрагментов. Первичный поиск обычно отдаёт кандидатов «примерно по теме»; отдельная модель-реранкер пересортирует и отсекает наименее релевантные из них перед отправкой в контекст, повышая долю полезной информации на единицу объёма.
• Суммаризация истории вместо полного лога. В диалоговых агентах старую часть истории имеет смысл сжимать в краткое резюме, а не таскать дословно в каждом запросе — управление контекстным окном для агентных сценариев отдельно разобрано в статье контекстное окно для ИИ-агентов: как им управлять.
• Явная структура вместо «простыни текста». Разделяйте несколько источников явными маркерами (заголовками, метками источника) — это облегчает модели разбор структуры входа и снижает риск смешения фактов.
• Ограничение top-k под конкретную задачу. Вместо фиксированного «всегда берём топ-20» подбирайте число возвращаемых фрагментов эмпирически — часто оптимум лежит заметно ниже, чем кажется интуитивно, особенно с реранкером.

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

Когда действительно нужен длинный контекст

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

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

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

Как проверить, помогает ли вам расширение контекста

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

1. Соберите 20-30 реальных вопросов из вашего сценария использования
2. Прогоните их через минимальный, тщательно отобранный контекст
   (только релевантные фрагменты, без избыточности)
3. Прогоните те же вопросы через расширенный контекст
   (больше источников, меньше фильтрации)
4. Сравните качество ответов вручную или через LLM-as-judge,
   а не только по субъективному ощущению "выглядит подробнее"
5. Сравните разницу в задержке и стоимости между вариантами
6. Если расширенный контекст не даёт измеримого выигрыша
   в качестве — оставляйте минимальный вариант

Методика автоматизированной оценки качества ответов без ручной проверки каждого разобрана в статье как оценить качество RAG-ответов без ручной проверки — тот же подход применим и вне RAG-систем, если нужно сравнить два варианта сборки контекста между собой.

Такая проверка избавляет от ситуации, когда система месяцами тратит лишние деньги и секунды ожидания на контекст, который не приносит дополнительного качества — а иногда и снижает его.

Частые вопросы