В 2024 году спор «длинный контекст против RAG» перестал быть теоретическим. После выхода Gemini 1.5 и серии сравнительных работ стало ясно, что большие окна контекста действительно снимают часть старых ограничений, но не делают retrieval ненужным автоматически. Если держаться именно среза 2024 года, а более поздние материалы использовать только как проверку выводов, ответ получается не бинарный: единого победителя нет, потому что long context и RAG лучше решают разные режимы работы с данными.
Коротко
- По работам 2024 года длинный контекст часто выигрывает там, где ответ спрятан в одном или нескольких самодостаточных, связных документах и модель может прочитать их почти целиком.
- RAG остаётся сильнее там, где корпус большой, часто обновляется, требует явной привязки к источникам или содержит разрозненные фрагменты вместо одной связной истории.
- Ключевая проблема не в «размере окна» как таковом, а в отборе релевантной информации: и длинный контекст, и RAG деградируют, когда в prompt попадает слишком много шума.
- Практический вывод 2024 года — не «заменить RAG», а улучшить его: длиннее retrieval units, сохранять порядок, добавлять reranking и при необходимости маршрутизировать запросы между RAG и full-context.
- Лучший общий ответ для продакшена — гибрид: retrieval по умолчанию, длинный контекст как эскалация для сложных или плохо локализуемых запросов.
Контекст: почему спор вообще возник
RAG как идея старше нынешней волны long-context LLM. В работе Patrick Lewis и соавторов Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks модель совмещала параметрическую память с внешней непараметрической памятью и тем самым получала два важных свойства: обновляемость знаний и более явную привязку ответа к извлечённым источникам.
Перелом случился в 2024 году, когда крупные модели начали уверенно работать с очень длинными входами. Google 15 февраля 2024 года представила Gemini 1.5, а затем в мае расширила публичную историю модели до контекстов уровня миллионов токенов; OpenAI ещё в ноябре 2023 года вывела GPT-4 Turbo с длинным окном, а Anthropic 4 марта 2024 года выпустила Claude 3 с длинным контекстом. На этом фоне и возник естественный вопрос: если модель может «прочитать всё», нужен ли вообще retrieval?
Но здесь есть ловушка. Как показали Goldman и соавторы в работе Is It Really Long Context if All You Need Is Retrieval?, под зонтиком «long context» часто смешиваются очень разные задачи: поиск одного факта, агрегация сведений, суммаризация, multi-hop reasoning, работа с диалоговой историей. Отсюда и путаница в выводах: методы сравнивают не на одном типе сложности, а на разных.
Метод: что именно мы сравниваем
Длинный контекст
Под «длинным контекстом» в этой статье я имею в виду режим, где LLM получает весь документ или очень большой его кусок прямо в prompt и сама ищет релевантные фрагменты внутри входа. Сильная сторона такого подхода — сохранение глобальной структуры текста: модели проще видеть соседние абзацы, разделы, переходы и внутреннюю логику документа.
Слабая сторона — шум. Когда полезная информация растворена в длинном входе, модель должна не только «уметь вместить» текст, но и правильно выделить важное. Старое наблюдение Lost in the Middle здесь никуда не делось: позиция и распределение фактов по входу всё ещё влияют на качество.
RAG
RAG разбивает корпус на части, индексирует их, а при запросе подбирает top-k фрагментов и только их передаёт генератору. Его сила — экономия токенов, работа с большими и меняющимися базами, а также более удобная трассировка ответа к источнику. Его слабость — потеря глобального контекста при chunking и риск, что retriever вернёт формально похожие, но фактически мешающие куски.
Гибриды
Именно гибриды стали главным сюжетом 2024 года. Li и соавторы предложили Self-Route, где модель выбирает между RAG и full-context. Zhao и соавторы в LongRAG увеличили сами retrieval units, чтобы вернуть RAG часть глобальной структуры документа. Anthropic в engineering-заметке про Contextual Retrieval показала другой путь: не отказываться от retrieval, а улучшить качество извлечения за счёт contextualized chunks, BM25 и reranking.
Результаты: что показали работы 2024 года
Важно: таблицу ниже нельзя читать как единый лидерборд. Работы использовали разные модели, retriever-ы, объёмы входа, датасеты и метрики. Поэтому это не «кто объективно номер один», а карта того, в каких условиях выводы расходятся.
| Работа | Что сравнивали | Ключевой результат | Что это значит |
|---|---|---|---|
| Li et al., Retrieval Augmented Generation or Long-Context LLMs?, препринт от 23 июля 2024, EMNLP Industry 2024 | LC, RAG и Self-Route на Gemini-1.5-Pro, GPT-4o и GPT-3.5-Turbo | По данным одного исследования с Contriever: средний score для Gemini-1.5-Pro составил 49.70 у LC против 37.33 у RAG и 46.41 у Self-Route; для GPT-4o — 48.67 против 32.60 и 48.89; для GPT-3.5-Turbo — 32.07 против 30.33 и 35.32. | Если ресурсов достаточно и задача допускает прямое чтение длинного входа, full-context часто выигрывает по среднему качеству. Но routing уже в 2024 году показал, что часть этого качества можно сохранить дешевле. |
| Yu et al., In Defense of RAG in the Era of Long-Context Language Models, 3 сентября 2024 | Long-context без retrieval, Self-Route и order-preserve RAG | По данным одного исследования: на EN.QA OP-RAG-48K на Llama3.1-70B получил 47.25 F1 при 48K входных токенов, тогда как long-context без RAG на той же модели дал 34.26 при 117K; на EN.MC OP-RAG-24K показал 88.65 против 85.57 у Gemini-1.5-Pro без RAG при 188K. | Хорошо настроенный retrieval может бить brute-force long context и по качеству, и по токенам. Важен не сам факт retrieval, а то, как именно вы ранжируете и упорядочиваете найденные куски. |
| Zhao et al., LongRAG, EMNLP 2024 | Гибрид с длинными retrieval units против LC, advanced RAG и vanilla RAG | По данным одного исследования на трёх multi-hop datasets: LongRAG опередил long-context LLMs на 6.94%, advanced RAG на 6.16% и vanilla RAG на 17.25%. | Классический компромисс «либо retrieval, либо глобальный контекст» оказался слишком грубым. Если retrieval unit сделать длиннее, RAG перестаёт терять столько структуры. |
| Laban et al., Summary of a Haystack, подано 1 июля 2024 | Long-context LLMs и 50 RAG-систем на задаче суммаризации с обязательными ссылками на источники | По данным одного benchmark paper: человеческий joint score составил 56.1, лучший системный результат — 44.6; без retriever long-context модели вроде GPT-4o и Claude 3 Opus набирали ниже 20% на SummHay. | Ни long context, ни RAG не «закрыли» сложную агрегацию и цитирование. Простое умение вместить длинный вход ещё не означает умение собрать корректный, проверяемый синтез. |
Если вынести из этих работ не отдельные цифры, а повторяющиеся паттерны, получится четыре наблюдения.
- Связный документ благоприятен для long context. В revisit от 27 декабря 2024 прямо сказано: LC обычно выигрывает на self-contained информации вроде историй и Wikipedia-based QA, где полезно читать документ как целое.
- Фрагментированные и диалоговые данные оставляют RAG сильные позиции. Та же revisit-работа отмечает преимущества RAG на dialogue-based и general question queries.
- Больше retrieved chunks — не всегда лучше. И Yu et al., и Jin et al. показали, что рост объёма извлечённого контекста даёт не монотонный выигрыш: сначала помогает recall, потом начинается деградация из-за hard negatives и шума.
- Лучшие практические решения 2024 года — гибридные. Self-Route, LongRAG, Contextual Retrieval и OP-RAG по-разному приходят к одной мысли: retrieval не исчезает, а становится умнее и ближе к long-context reading.
Интерпретация
Наш комментарий
На наш взгляд, вопрос стоит формулировать не как «что сильнее вообще», а как «где находится неопределённость — в поиске или в рассуждении». Если вы уже знаете, какой документ нужен, и внутри него важно синтезировать много удалённых друг от друга фрагментов, длинный контекст обычно логичнее. Если же неизвестно, где лежит ответ, или корпус постоянно меняется, retrieval остаётся первым шагом по умолчанию.
Отсюда и практическое правило:
- Один или несколько самодостаточных документов: сначала пробуйте long context.
- Большая база знаний, обновляемый корпус, требование к provenance: сначала пробуйте RAG.
- Сложные multi-hop вопросы: не ограничивайтесь мелкими чанками; используйте длинные retrieval units, reranking или графовые варианты retrieval.
- Высокая цена ошибки: делайте адаптивную систему, где retrieval — дефолт, а full-context — эскалация для трудных случаев.
Отдельно важно, что engineering-практика 2024 года не подтверждает тезис «чем больше окно, тем меньше нужен retrieval». Anthropic в заметке про Contextual Retrieval прямо показывает обратную интуицию: retrieval может становиться сильнее не за счёт роста top-k, а за счёт лучшего контекста внутри каждого chunk и более аккуратного reranking.
Ограничения и критика
Во-первых, большая часть сравнений 2024 года — это текстовые QA- и summarization-задачи. По ним нельзя автоматически делать выводы про агентные workflows, IDE, мультимодальные пайплайны или production-search.
Во-вторых, часть старых benchmark’ов завышала впечатление от long context, потому что вопрос можно было решить без внешнего контекста или потому что задача по сути сводилась к поиску одной иглы в стоге. Именно поэтому revisit от 27 декабря 2024 отдельно фильтрует вопросы, на которые модель отвечает за счёт своей параметрической памяти, а Goldman et al. критикуют смешение retrieval-like и genuinely long-context задач.
В-третьих, headline-демонстрации long context не равны сложному пониманию. В материалах о Gemini 1.5 Google показывала почти идеальный поиск «needle in a haystack», но более трудные тесты вроде SummHay требуют уже не найти иголку, а собрать многодокументный, проверяемый синтез с правильными ссылками. Это разные способности.
В-четвёртых, экономику нельзя читать напрямую из academic papers. Стоимость зависит от конкретного провайдера, prompt caching, длины ответа, частоты запросов и того, можно ли переиспользовать промежуточные представления. Поэтому фраза «RAG дешевле» в среднем верна по нескольким источникам, но точный порог перехода всегда нужно проверять на собственной нагрузке.
Вывод
Длинный контекст не «убил» RAG в 2024 году. Он поднял планку: теперь retrieval должен не просто приносить куски текста, а приносить их в правильной форме, порядке и объёме. Если нужна короткая формула для практики, она такая: long context для связных досье, RAG для больших и живых корпусов, гибрид — как рабочий стандарт.
Источники
- Patrick Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Google — Introducing Gemini 1.5, Google’s next-generation AI model
- Reid et al. — Gemini 1.5: Unlocking multimodal understanding across millions of tokens of context
- OpenAI — New models and developer products announced at DevDay
- Anthropic — Introducing the next generation of Claude
- Zhuowan Li et al. — Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach
- Philippe Laban et al. — Summary of a Haystack: A Challenge to Long-Context LLMs and RAG Systems
- Dan Goldman et al. — Is It Really Long Context if All You Need Is Retrieval? Towards Genuinely Difficult Long Context NLP
- Qingfei Zhao et al. — LongRAG: A Dual-Perspective Retrieval-Augmented Generation Paradigm for Long-Context Question Answering
- Anthropic Engineering — Introducing Contextual Retrieval
- Tan Yu et al. — In Defense of RAG in the Era of Long-Context Language Models
- Xinze Li et al. — Long Context vs. RAG for LLMs: An Evaluation and Revisits
FAQ
Может ли длинный контекст заменить RAG?
Не универсально. Для связных документов — часто да. Для больших, обновляемых и разрозненных корпусов — обычно нет.
Когда long context почти всегда стоит попробовать первым?
Когда у вас один большой документ, книга, отчёт, кодовая база или набор тесно связанных файлов, и задача требует синтеза по всей структуре, а не точечного поиска.
Когда RAG остаётся предпочтительным?
Когда нужен provenance, экономия токенов, работа с постоянно меняющимися данными и быстрый поиск по большому числу документов.
Какой компромисс выглядит самым здоровым по состоянию на материалы 2024 года?
Адаптивный гибрид: хороший retriever, длиннее retrieval units, reranking и fallback в full-context для сложных запросов.