Long Context vs RAG: когда 1 миллион токенов лучше поиска

Цели урока

• Проследить эволюцию context windows от 4K до 10M токенов и понять что изменилось
• Разобраться с lost-in-the-middle эффектом и его практическими следствиями
• Применять матрицу решений для выбора между long context и RAG
• Реализовать hybrid pipeline: RAG для поиска, long context для анализа

В 2022 году RAG был не архитектурным выбором - он был единственным вариантом. 4K токенов. Один README не влезал. 2024: Gemini 1.5 Pro - 1 миллион токенов. Весь Android репозиторий в одном запросе. Теперь инженер должен решать: когда контекст, когда поиск, когда оба вместе. Это не очевидный выбор.

• Gemini 1.5 Pro (февраль 2024) - первая коммерческая модель с 1M контекстом. Google демонстрировала анализ всего Android кода в одном промпте
• Cursor IDE использует hybrid подход: RAG для поиска релевантных файлов, затем все найденные файлы целиком в контекст - не только chunks
• NotebookLM от Google (2024) - весь PDF-документ (до 500 страниц) в контекст без RAG. Работает для single-document Q&A
• Stanford 'Lost in the Middle' (2023) - исследование показало U-образную деградацию качества: до 40% потери при информации в середине 200K контекста

Как рос контекст и менялась архитектура

**2022**: GPT-3.5 - 4K токенов. RAG - единственный способ работать с документами. LangChain вырос из этой необходимости. **2023**: Claude 2 - 100K токенов. Первые эксперименты с full-document-in-context. RAG всё ещё выигрывает по стоимости. **Февраль 2024**: Gemini 1.5 Pro - 1M токенов с Multi-head attention через Mixture of Experts. Первый real benchmark: анализ 30K строк кода без потери качества. **Конец 2024**: Claude 3.5 Sonnet - 200K при лучшем recall, чем у предыдущих 1M-моделей. Качество vs размер - не линейная зависимость. **2025**: Gemini 2.5 Pro - 2M+. Cursor, Copilot, Windsurf переходят на hybrid: RAG + big context вместо pure RAG.

Предварительные знания

• RAG: Retrieval-Augmented Generation от теории до реализации
• Токены и Context Window: почему LLM забывает и как с этим жить

Эволюция context windows: от 4K до 10M токенов

GPT-3.5 в 2022 году: 4096 токенов. Чуть больше 3000 слов. Один хороший README не влезал целиком. RAG был не архитектурным выбором - он был единственным вариантом. Три года спустя - Gemini 2.0 Flash: 1 миллион токенов. Вся кодовая база среднего проекта влезает с запасом.

Что меняется фундаментально с контекстом 1M+:

• **Весь репозиторий в одном запросе** - агент видит все связи между файлами одновременно
• **Cross-document reasoning** - анализ противоречий между 50 документами без предварительного поиска
• **Zero-shot RAG** - вместо embedding-поиска по частям - просто весь документ в контекст
• **One-shot кодовая база** - Cursor, GitHub Copilot могут подать весь проект в один запрос

Gemini 1.5 Pro стал первой commercially available моделью с 1M контекстом (февраль 2024). Google использовала её внутренне для анализа всего кодового репозитория Android - 10+ млн строк - в одном запросе. Результат показал задачи, где RAG проигрывает: cross-file reasoning требует видеть все файлы одновременно.

Lost-in-the-middle: почему большой контекст не равно лучшее понимание

Исследование Stanford (Liu et al., 2023) - "Lost in the Middle: How Language Models Use Long Contexts". Результат противоречит интуиции: **модели хуже работают с информацией в середине длинного контекста**. Начало и конец - нормально. Середина - деградация до 20-40% качества.

Практический тест - "needle in a haystack". Один ключевой факт вставляется на разные позиции в длинный нерелевантный текст. Модель отвечает на вопрос об этом факте. Результат: чем ближе к середине - тем ниже recall.

Когда long context всё же работает хорошо - задачи, где вся информация одинаково важна и модель должна синтезировать всё сразу:

• **Рефакторинг всей кодовой базы** - нужно видеть все файлы одновременно для правильного rename
• **Анализ противоречий** - найти конфликты между 30 разными документами политики
• **Суммаризация длинного документа** - превратить 500-страничный отчёт в 2 страницы
• **Code review крупного PR** - все изменения в одном окне, нет риска потерять связи

Needle-in-a-haystack accuracy у Claude 3.5 Sonnet: ~95% при 50K токенах, ~85% при 100K, ~70% при 200K. Gemini 1.5 Pro показывает better recall at 1M, но всё равно не 100%. Для fact-retrieval задач RAG с хорошим embedding остаёт точнее.

Матрица решений: когда что использовать

Четыре ключевых измерения для выбора между long context и RAG: размер корпуса, частота обновлений, latency budget, чувствительность к стоимости.

Hybrid: RAG + Long Context в одном pipeline

Cursor и GitHub Copilot не выбирают между RAG и long context. Они используют оба: RAG для нахождения релевантных файлов, long context для глубокого анализа найденного. Это паттерн, который 2025-2026 стал стандартом для code intelligence продуктов.

Ключевой инсайт: RAG сокращает корпус с 1M до 50K - без потери нужной информации. Потом long context делает deep reasoning на этих 50K. Это лучше чем RAG один (нет cross-chunk reasoning) и лучше чем full context один (дёшево, быстро).

При сборке hybrid контекста - best-first порядок важен. Самые релевантные chunks должны быть в начале (борьба с lost-in-the-middle). Если нужно добавить полный документ для cross-document reasoning - добавлять его целиком после ranked chunks, не вперемешку.

Больше контекст = лучше понимание. 1M токенов - всегда лучше, чем RAG

Большой контекст дороже, медленнее и страдает от lost-in-the-middle. Для fact-retrieval RAG точнее

Подать 200K токенов в Claude 3.5 Sonnet стоит ~USD 0.60 за запрос. 1000 запросов в день - USD 600/день, USD 18K/месяц. RAG на тех же данных: ~USD 0.005/запрос = USD 150/месяц. 120x разница. Плюс latency: 200K контекст -> 10-30 сек, RAG -> 1-3 сек. И при этом recall в середине контекста хуже.

RAG устарел - long context заменяет его

RAG остаётся лучшим выбором для больших корпусов, частых обновлений и latency-чувствительных приложений

Корпус 10M токенов не влезает ни в одну модель 2025 года без огромных затрат. Базы знаний обновляются в real-time - long context требует полной переподачи всего корпуса. RAG индексирует инкрементально. Hybrid - не замена RAG, а дополнение: RAG делает поиск, long context делает анализ найденного.

Итоги

• Context window вырос от 4K (2022) до 2M+ (2025) - это качественное изменение возможностей
• Lost-in-the-middle: U-образная деградация качества - начало/конец хорошо, середина плохо
• Long context выигрывает при: малом корпусе (<200K), редких обновлениях, задачах синтеза
• RAG выигрывает при: большом корпусе (>500K), частых обновлениях, latency < 2 сек, fact-retrieval
• Hybrid (RAG + long context) - стандарт Cursor/GitHub Copilot: RAG сужает корпус, long context делает deep reasoning

Вопросы для размышления

• Для типичного корпоративного чатбота по внутренней документации (5000 документов, обновления ежедневно) - что предпочтительнее и почему?
• Если lost-in-the-middle снижает качество до 40% в середине контекста - как это влияет на дизайн hybrid pipeline?
• Cursor показывает файлы из всего репозитория, но не подаёт весь репозиторий в контекст. Как организован pipeline и почему именно так?

Что дальше

Контекст и поиск освоены. Следующий уровень - advanced техники RAG, которые поднимают accuracy с 60% до 90%.

• Advanced RAG — Hybrid search, re-ranking, HyDE - от naive RAG к production quality
• RAG: основы — Фундамент: naive RAG pipeline от индексации до генерации
• Токены и context window — Как считать токены и управлять размером контекста

Связанные уроки

• aie-12-rag-fundamentals
• aie-04-tokens-context-window
• aie-13-advanced-rag
• aie-07-structured-output
• aie-16-tool-calling