10 RAG approaches that actually work in production: from basic to GraphRAG

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

Откуда все начинают Naive RAG — отправная точка большинства проектов.

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

Гибридный поиск и reranking Гибридный поиск — первый апгрейд, который окупается почти всегда.

Совмещение dense-векторов (семантический поиск) с BM25 (поиск по ключевым словам) стабильно даёт +15–30% к точности по сравнению с одним только embedding-поиском. Плотные векторы улавливают смысловое сходство, разреженные — точные совпадения по терминам, аббревиатурам и именам. Добавление cross-encoder reranker поверх топ-20 результатов ещё поднимает качество на 10–15%. Reranker — более тяжёлая модель, но работает только с финальным набором кандидатов, так что задержка остаётся приемлемой для продакшена.

Техники на уровне запроса

Часть RAG-проблем эффективнее решать до поиска — переформулировкой или расширением запроса. HyDE — LLM генерирует гипотетический документ-ответ, его вектор используется для поиска. Особенно помогает, когда стиль вопроса и стиль документов сильно отличаются. Multi-query — из одного вопроса генерируется 3–5 перефразировок, поиск идёт параллельно по всем. Снижает зависимость от точной формулировки пользователя. Step-back prompting — перед поиском LLM обобщает запрос до более высокого уровня абстракции. Полезно, когда конкретный вопрос слишком нишевый для хорошего retrieval. Parent Document Retriever — индексируются мелкие чанки (высокая точность), а в контекст передаётся родительский документ целиком. Хороший баланс между precision и coverage. * Contextual compression — LLM выжимает из найденного чанка только релевантную часть. Экономит токены и снижает шум в контексте.

Тяжёлая артиллерия

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

Хорошо работает на длинных документах — технических руководствах, финансовых отчётах, книгах с разной степенью детализации. GraphRAG от Microsoft строит граф знаний: извлекает сущности и связи из текста, создаёт community summaries для разных тематических кластеров. Уверенно выигрывает у стандартного RAG на аналитических и сравнительных вопросах — "как X связано с Y", "что изменилось с момента A" — и на задачах, требующих синтеза по всему корпусу.

Self-RAG и Corrective RAG переводят систему в агентный режим: модель сама решает, нужен ли поиск, оценивает релевантность найденного и при необходимости переформулирует запрос. Добавляет latency и сложность, но заметно поднимает качество на многошаговых и неоднозначных задачах.

Что это значит

Практический путь: начать с гибридного поиска плюс reranking — это закрывает большинство проблем с минимальными затратами. Затем добавить multi-query или HyDE для разнообразных запросов. GraphRAG и Self-RAG подключать только когда более простые техники не справляются: они требуют значительных затрат на разработку и поддержку. Для большинства B2B-продуктов первых двух шагов достаточно.