Длинный контекст LLM в RAG-системах и не только (подробный обзор)

RAG представляет собой ключевую технологию повышения точности больших языковых моделей (LLM) за счет предоставления внешней информации. С появлением длинного контекста (LC) возрастает интерес к тому как хорошо он работает в задачах генерации, дополненной поиском (RAG). Надо ли RAG вообще? Лучше ли LC, чем RAG, или побеждает дружба? Ответы неоднозначны, попробуем разобраться с разных ракурсов.

Содержание:

Генерация, дополненная поиском (Retrieval-Augmented Generation, RAG) — это подход, при котором генерация ответа большой языковой модели (LLM) осуществляется на основе данных, полученных в результате поиска во внешних источниках: файлы, базы данных, таблицы, графики, Интернет, база вопросов и ответов, и любые другие наборы данных. (Кстати, эти статьи на Вики, на которые ссылаюсь были доработаны мною существенно, но еще в процессе редактирования).

Необходимость применения RAG возникает, когда объём данных превышает ёмкость контекстного окна LLM. Например, требуются ответы на основе текста объёмом 500 страниц, сотен договоров или технических спецификаций, а также интернет‑публикаций.

Еще пример. Набор данных может быть небольшим по объёму и помещаться в пределах допустимой длины контекста. Однако он хранится в базе данных с тысячами записей, поэтому необходима автоматическая релевантная выборка по запросу. RAG также применяется для создания персональной памяти в чат‑системах.

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

Существует множество архитектур построения RAG, базисная система состоит из трех этапов:

Другими словами, вместо передачи всей книги, RAG определяет, что релевантная информация по запросу содержится на 3-й, 40-й и 50-й страницах. Вместо 500 страниц RAG отправляет в LLM только три страницы. Теоретически это позволяет повысить скорость и точность генерации ответа. Однако на практике могут возникать нюансы.

В 2023–2024 годах большинство базовых моделей, особенно с открытым исходным кодом, поддерживали длину контекста в диапазоне 2–16 тыс. токенов. К 2025 году LLM обеспечивают рабочую контекстную длину на десятки и сотни страниц текста (32–128 тыс. токенов).

В последнее время наблюдается тренд на модели с контекстом 1–10 млн токенов: семейство Gemini 1.5 (до 10 млн), GPT‑4.1 (1 млн), Llama 4 Scout (10 млн), Qwen 2.5 (1 млн). Это естественно порождает дискуссии, а надо ли RAG.

Контекста на 1 млн слов может не хватить для работы с огромными массивами данных, либо модель при росте объема входящего текста начинает отвечать все хуже или очень долго (что в конечном счете еще и дороже). Если условное "долго" еще терпимо, то вот качество ответов может совсем не сойтись с ожиданиями.

Пока реальность такова, что небольшие модели (3–14 млрд параметров) плохо справляются с контекстом даже в диапазоне 2–4 тыс. токенов. Модели с большим числом параметров (20–400 млрд и выше) также не реализуют весь потенциал своих способностей по всей длине контекста.

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

В исследованиях ChatQA2 и LongBench v2 длинный контекст определяется как превышающий 32к и более 8к токенов соответственно. В других работах минимальным требованием для длинного контекста считается диапазон 8-16к токенов. OP-RAG рассматривает 128к токенов как длинный контекст.@

Пожалуй, соглашусь с предложенной классификацией в исследовании ChatQA2 и в этом документе будем ее придерживаться:

У коммерческих моделей архитектура редко раскрывается. У открытых LLM конфигурация архитектуры отображается в config.json, например на HF для Llama 3.

Какие параметры ключевые для определения контекста:

Так называемое контекстное окно (context window) это фактически синоним длины контекста и равно оно максимальной длине указанной в max_position_embeddings. Однако в некоторых архитектурах, например, в Mistral/Qwen есть еще параметр sliding_window - задаёт эффективное окно внимания, который снижает требования к памяти при длинном контексте. Такое окно может быть в несколько раз ниже максимальной длины контекста. Качество на задачах, где важны связи шире длины sliding_window, теоретически падает.

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

Обращайте также внимание на фактическую конфигурацию в конкретных движках инференса. Например, в Ollama оригинальная длина контекста модели указанная в max_position_embeddings может не поддерживаться в движке.

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

В таблице ниже отражена удивительная аномалия, как 1М контекста MiniMax превращается в тыкву - 158к для русского. Такие вот токенизаторы.

Во-первых - сложность разработки RAG

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

Модель LLM с ультра длинным контекстом (более 32 К токенов) способна «переварить» большие массивы текста в рамках одного запроса. Это теоретически повышает эффективность RAG‑системы, снижая зависимость от точного разбиения на фрагменты (chunking), от реранкинга результатов поиска и от прочих приёмов, призванных сжать поток данных.

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

На практике же LLM пока достаточно нестабильные и проявляют большое число разнообразных проблем при работе даже с коротким контекстом.

Во-вторых - от LLM хочется умного ответа

Объем объективно релевантной информации, получаемой с использованием RAG, часто достигает десятков или сотен тысяч токенов даже после применения фильтрации, повторного ранжирования и суммаризации. Более того, от LLM часто требуется не просто цифры и факты выписать из текста, но и обучиться на контексте новым знаниям и семантическим связям, и в конечном итоге выдавать "умный" и мудреный ответ. Поэтому без длинного контекста жить труднее.

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

Поскольку эффективность LLM в работе с длинным контекстом это базовый показатель, используется RAG или нет, остановимся более детально на этой теме. К тому же доступно больше исследований по LC, чем LC + RAG. Стоит сразу отметить, что не всякая модель даже с длинным контекстом подходит для RAG.

Есть множество способов оценки качества работы LLM по всей длине контекста. Один из простых и ставших стандартным методом это Needle In A Haystack - поиск "иголки в стоге сена". Современные модели уже очень хорошо умеют в поиск иголок. Но, как говорится, простота хуже воровства. Обольщаться таким измерениям не стоит.

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

Бенчмарк LongBench2 создан для оценки способности LLM обрабатывать задачи с длинным контекстом, требующие глубокого понимания и логических рассуждений в реалистичных многозадачных сценариях. Длина контекста: от 8 тыс. (8k) до 2 млн слов, преимущественно до 128 тыс. (128k). Сложность: достаточно высокий уровень, при котором даже эксперты с использованием поисковых инструментов в документе не могут дать правильный ответ за короткое время. Цифры говорят сами за себя:

Еще один интересный бенчмарк Fiction.LiveBench показывает как снижается качество от длины контекста. Llama 4 Scout имеющая рекордно длинный контекст - 10М выглядит пустышкой.

Если говорить про инференс локальных моделей: для длинного контекста потребуется дополнительная видеопамять, что достаточно дорогое удовольствие и является существенным ограничением для внедрения LLM.

На 2хA5000 (48ГБ) провели исследование использования памяти при разных механизмах внимания на модели meta-llama/Llama-3.1-8B-Instruct с 128К контекстом.

На графике отображено, как небольшая модель 8B с длиной контекста 128К легко пожирает 40Гб видеопамяти.

Отдельной проблемой остаются затраты и задержки (latency). Загрузка 1 миллиона токенов может занимать до 60 секунд и стоить от 0,50 до 20 долларов США. Одно из возможных решений связано с использованием KV Cache — механизма, который хранит ключи и значения, сгенерированные предыдущими токенами и повторно использует их при следующих генерациях. Однако такой подход требует значительных вычислительных ресурсов. По оценкам, хранение активаций для 1 миллиона токенов занимает около 100 гигабайт памяти GPU.

Кроме того, каждая активация формируется на основе всех предыдущих токенов, поэтому замена любого документа в KV Cache меняет всю последовательность последующих активаций. Это требует дополнительных алгоритмов управления кэшем при работе с крупными корпусами.

В целом, с увеличением длины контекста наблюдается закономерный рост времени до первого токена (TTFT) для всех рассмотренных методов. При малых длинах контекста TTFT остается на очень низком уровне, обеспечивая быструю генерацию ответа.

По мере увеличения числа токенов время отклика постепенно возрастает, причем наиболее заметный рост происходит при переходе к большим и очень большим контекстам (десятки тысяч токенов). Для экстремально длинных последовательностей рост TTFT становится более выраженным, однако сохраняет предсказуемый характер, что свидетельствует о масштабируемости современных решений.

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

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

По опыту замечал, что даже топовые модели генерируют ложные сведения или додумывает несуществующие в контексте цифры и факты. Например, если в промпте есть указание выписывать из контекста дату публикации, а в контекст отправлена статья которая не содержит никакой даты - он додумывает год публикации (вероятно даже на основе даты отсечения датасате в претрейна)

Исследование (Mert Yazan, 2024) показало как влияет квантизация на работу с длиной контекста:

Квантизация (например, переход от FP16 к INT4/INT8), сокращает кратно объём памяти, позволяя обрабатывать больше токенов за раз, что полезно для RAG-систем.

Эффективность конкретной реализации квантизации зависит от модели и задачи: исследования показывают сохранение 99% точности FP16 на длинных контекстах для 7B/8B моделей при использовании INT4, если базовая модель изначально эффективна, но на ультра длинном контексте (128K токенов) деградация наблюдается у всех вариантов квантизации.

Есть множество сценариев, когда так или иначе приходится делать выбор между тем, чтобы городить RAG или положится на длинный контекст модели (LC).

Исследование посвященное методу Self-Route показало, что суммарная точность LC достигает 56,3%, тогда как RAG даёт верные ответы в 49,0% случаев. При этом LC корректно решает свыше 2000 вопросов, недоступных для RAG, в то время как RAG справляется примерно с 1300 вопросами, на которые LC не даёт правильного ответа. В рамках более гибкого формата оценки (loose evaluation) LC превосходит RAG по 3433 вопросам, тогда как RAG показывает лучшие ответы по 1843 вопросам. Расхождение с показателями строгой проверки (strict evaluation) увеличивается, что указывает на высокую эффективность моделей с расширенным контекстом при необходимости формулировать развернутые ответы.

На отдельных наборах данных выявляются различные тенденции. Например, в корпусе MultiDoc2Dial RAG демонстрирует лучшие результаты по строгому критерию (29 правильных ответов против 5 у LC), однако при более свободной оценке LC достигает 65 успешных ответов, а RAG — 58.

В NarrativeQA и QuaLITY LC заметно опережает RAG не только по общей точности, но и по числу вопросов, где качество ответа оценивается выше. Таким образом, оба подхода обладают специфическими преимуществами и ограничениями.

Несмотря на превосходство LC по итоговым показателям, почти 10% вопросов (из 13 628) решаются верно исключительно методами RAG, что свидетельствует о сохранении значимости механизмов поиска и невозможности полной замены retrieval-подходов за счёт одной лишь модели с длинным контекстом. Данный факт побуждает к дополнительному анализу видов вопросов и контекстов, в которых только один из двух методов обеспечивает корректный ответ.

LC превосходят RAG по качеству понимания длинных контекстов, однако RAG обладает значительно большей экономической эффективностью. Предложенный исследователями метод Self-Route, сочетающий подходы RAG и LC, обеспечивает сопоставимую с LC производительность при существенно меньших затратах.

Результаты указывают на необходимость предварительного анализа характера запросов и структуры контекста для оптимального выбора метода.

Пока мало увидел исследований, основной целью которых было выявление эффективности длинного контекста в RAG.

В исследованиях, связанных с длинными текстами, обычно выделяют две основные категории наборов данных:

Проведённое Quinn Leng в ноябре 2024 года исследование оценивает влияние увеличения длины контекста на резул��таты RAG для 20 популярных открытых и коммерческих языковых моделей. В методике использовались три корпуса вопросов и ответов: Databricks DocsQA, FinanceBench и Natural Questions.

На этапе извлечения информации применяется единая эмбеддинг-модель OpenAI text-embedding-3-large с размером окна 512 токенов и шагом 256 токенов; векторное индексирование осуществляется с помощью FAISS (IndexFlatL2).

На этапе генерации размер контекстного окна варьируется от 2 000 до 128 000 токенов, а при наличии технической возможности — до 2 миллионов токенов. Температура генерации установлена на 0,0, максимальная длина ответа составляет 1 024 токена. Для всех промптов используется единая структура шаблона.

Несмотря на расширение контекста, улучшение производительности RAG не является универсальным. Коммерческие модели, такие как o1-mini, o1-preview, GPT-4o, Claude 3.5 Sonnet и Claude 3 Opus, демонстрируют стабильный рост точности при увеличении длины контекста до 100 000 токенов. Эти модели характеризуются в основном монотонным поведением: даже после достижения пиковых результатов их производительность существенно не ухудшается. Особенно выделяются модели o1, которые превосходят GPT-4 и GPT-4o по совокупной точности.

В отличие от них, большинство открытых моделей достигают максимальной эффективности на ограниченных интервалах. Например, Qwen 2 70B сохраняет стабильную точность до 64 000 токенов, а Llama 3.1 405B и GPT-4-0125-preview демонстрируют спад производительности после 32 000 и 64 000 токенов соответственно. Лишь немногие открытые модели обеспечивают устойчивую работу RAG на всем диапазоне контекстов.

Уникальный случай представляют модели Gemini 1.5 от Google: несмотря на более низкую общую точность по сравнению с o1 и GPT-4o, они сохраняют стабильную производительность на экстремально длинных контекстах до 2 000 000 токенов, что подчеркивает потенциал будущих языковых моделей в работе с расширенными контекстами.

Экспериментальные результаты решения задачи BABILong демонстрируют принципиальные различия методов тонкой настройки LLM и RAG. При использовании RAG с поиском по фрагментам (RAG-C, 512 токенов) не наблюдается улучшения производительности GPT-4 и Llama-3 в задачах на длинном контексте, тогда как поиск по предложениям (RAG-S) показывает лучшие результаты, однако увеличение количества извлекаемых предложений с 5 до 20 не даёт преимуществ.

Напротив, специфическое дообучение моделей демонстрирует высокую эффективность: архитектура Mamba после тонкой настройки превосходит RAG-модели, хотя обработка последовательностей свыше 128k токенов сталкивается с техническими ограничениями скорости, тогда как метод RMT сохраняет точность на уровне 10M токенов.

Критическим недостатком RAG в задачах QA2 и QA3 становится неспособность извлекать множественные взаимосвязанные факты (например, для ответа "Где находится молоко?" требуется последовательное извлечение фактов "Мэри взяла молоко" и "Мэри переместилась в прихожую"), что обусловлено ограничениями алгоритмов сходства и отсутствием учёта временных зависимостей. Эти результаты подчёркивают необходимость разработки специализированных методов поиска - тот самый случай скрытой сложности, о котором писал выше.

Результаты исследования BABILong выявили ограничения популярных открытых языковых моделей (LLM), включая GPT-4 и подход RAG, в эффективном использовании длинного контекста: их производительность существенно зависит от первых 5-25% входных данных, что подчёркивает необходимость совершенствования механизмов обработки контекста.

Эксперименты с тонкой настройкой демонстрируют, что задачи из набора BABILong решаемы даже относительно небольшими моделями — RMT с архитектурой GPT-2 (137 млн параметров) и Mamba (130 млн). Тонкая настройка улучшает показатели GPT-3.5-Turbo и Mistral-7B, однако их максимальная длина контекста остаётся ограниченной (16K и 32K токенов соответственно). Среди оценённых моделей Mamba (130M) и RMT (137M) достигают наивысших результатов, при этом Mamba испытывает трудности с обработкой последовательностей длиннее 128K токенов, тогда как RMT позволяет работать с контекстами до 11 миллионов токенов.

В томе же исследовании Quinn Leng, анализ RAG в задачах с длинным контекстом выявляет характерные типы сбоев у различных LLM. На наборе данных Natural Questions (NQ) модель Claude 3 Sonnet (Claude 3 Sonnet) часто отказывает в ответах из-за предполагаемых нарушений авторских прав, особенно при увеличении длины контекста. Gemini 1.5 Pro (Gemini 1.5 Pro) демонстрирует стабильную работу при экстремально больших объёмах информации (до 2 миллионов токенов), однако при значительном увеличении контекста возрастает число ошибок из-за повышенной чувствительности защитных фильтров.

Среди открытых моделей Llama 3.1 405B сохраняет сопоставимые показатели до 64к токенов, в то время как Mixtral-8x7B сталкивается с повторяющимся или случайным содержанием при росте объёма данных. Модель DBRX при контексте более 16к токенов нередко вместо точных ответов выдаёт обобщающие пересказы. Отдельно отмечается высокий уровень точности у Gemini 1.5 Pro и Flash при контекстах до 2 миллионов токенов, где доля верных ответов превышает 0.85.

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

Исследователи выполнили поэтапный анализ образцов моделей при различных длинах контекста, провели ручную верификацию результатов и на основе полученных данных выделили основные категории ошибок:

Следует отметить, что выявленные паттерны характерны для конкретных датасетов и могут варьироваться в зависимости от настроек генерации и формата промптов. Репрезентативные примеры ошибок приводятся в специально отведённом разделе исследования.

На мой взгляд, длинный контекст, что в RAG, что без, один из самых зыбких и ненадежных аспектов в работе LLM. Рассчитывать не стоит, что модель переварит весь текстовый бред, который в нее накидывают. Но постепенные улучшения происходят, главное в RAG и в LLM - это заручиться надежными тестами в своем сегменте задач.

На этом, пожалуй, выдохну и пойду пилить какой-нибудь RAG. Если что еще нарою - дополню. Заглядывайте на мой ТГ-канал, черкану может там чего еще полезного.