RAG в 2026: зачем, если есть long context

Модели второго поколения Claude 4 и GPT-5 работают с контекстом в миллион токенов. Книга целиком помещается в один запрос. Возникает логичный вопрос: зачем тогда RAG, зачем эмбеддинги, векторные базы, chunk-стратегии?

Отвечаю как тот, кто строит и то, и другое.

Где long context реально убивает RAG

Задачи на одном документе — свалил целиком в контекст, задал вопрос, получил ответ. Раньше нужно было нарезать на куски, считать эмбеддинги, делать hybrid search, переранжировать, собирать контекст. Сейчас: просто отправил PDF.

Это работает для договоров, статей, книг, кодовой базы до ~500K токенов. Качество выше, чем у RAG, потому что модель видит всё сразу — не теряет связи между частями.

Где RAG остался незаменимым

Три случая.

Первый: корпус больше контекстного окна. Миллион токенов — это около 700 страниц. База знаний компании, архив поддержки, вся документация крупного API — легко больше. Запихнуть нельзя, приходится выбирать релевантное.

Второй: стоимость. Запрос с миллионом входных токенов к Claude — это около $3. Если пользователей тысячи в день, и каждому нужен свежий контекст — экономика ломается. RAG режет вход в 100 раз.

Третий: свежесть. В RAG вы обновляете только изменившиеся документы. Перестраивать контекст из миллиона токенов на каждый запрос — дорого и медленно.

Гибрид, который я применяю

На практике почти всегда используется связка.

Эмбеддинг-поиск выбирает топ-20 кандидатов.
Reranker (обычно bge-reranker или Cohere Rerank) сужает до топ-5.
Выбранные фрагменты + системный промпт + вопрос идут в Claude.

Получается: высокая точность поиска, разумная стоимость, модель видит достаточно контекста для качественного ответа.

Что изменилось в самих стратегиях нарезки

Раньше делили по 512 токенов с overlap 50. Сейчас — семантически, через специальные splitter'ы. Хорошо работает langchain.SemanticChunker или нарезка по структуре markdown.

Ещё тренд — parent-child retrieval. Ищем по мелким чанкам (точность), подставляем в контекст крупные родительские блоки (полнота). Это часто даёт +15% качества на тех же данных.

Когда вообще не нужен ни RAG, ни long context

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

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

Что стало хуже

Инфраструктура эмбеддингов устарела. Pinecone, Weaviate, Qdrant — все хороши, но сложность деплоя и поддержки выросла, а задач у них всё меньше. Для малых проектов достаточно SQLite с pgvector-расширением или даже просто JSON-файл с numpy — не нужно тащить инфраструктурную машину.

Итог

RAG не умер, но перестал быть дефолтом. Дефолт теперь — закинуть документ в контекст. RAG включается, когда: корпус больше лимита, нужна экономия, нужна свежесть. И даже в этих случаях — не чистый vector search, а гибрид с reranker'ом.

Если у вас есть задача с документами и вы не знаете с чего начать — начните с long context. Если упёрлись в лимиты или стоимость — добавьте retrieval. Обратный путь (сразу строить RAG) почти всегда оказывается overengineering.

Нужна помощь с архитектурой работы с документами? Напишите.