Всем привет, на фоне обновлений в LLM-стеке за последний год, решил собрать практический список RAG-подходов, которые реально используются в продакшене на основе моего опыта и того что я изучал в других кейсах.
Что такое RAG (если коротко)
RAG (Retrieval-Augmented Generation) - это подход, в котором LLM отвечает не из своих весов, а по контексту, который мы даем из внешней базы знаний под конкретный запрос. Схема в одну строку:
"вопрос пользователя → найти релевантные куски в базе → отдать LLM как контекст → получить ответ со ссылками на источники"
Зачем это нужно? Модель сама по себе не знает вашу документацию, ваши тикеты, ваши policy и вчерашние новости. RAG это чинит без fine-tuning и это дешевле, быстрее, легче обновлять, проще объяснить регулятору.
Дальше - про то, чем разные RAG отличаются и какой выбирать.
1. Basic / 2-step RAG
Это базовый подход, с которого обычно начинают работу с RAG. Представьте ассистента, у которого есть доступ к папке с нужными материалами. Когда вы задаёте вопрос, он сначала ищет в этой папке подходящие фрагменты, затем использует их как контекст и формирует ответ.
В технической формулировке, схема такая:
вопрос -> vector search по базе документов -> топ-N кусков отдаются LLM как контекст -> LLM генерирует ответ
Это всё, что нужно знать, чтобы собрать уже первый MVP. LangChain даёт готовые туториалы, которые можно собрать буквально за день, нарезаете документы на чанки, считаете эмбеддинги, складываете в Chroma или FAISS, прикручиваете LLM поверх.
Основные минусы
Размер чанка - он может быть слишком маленьким, тогда вы теряете контекст, ответ обрезанный. Если слишком большой то модель тонет в шуме. Универсального ответа нет, нужно постоянно измерять
Vector search не всегда различает - например запрос про "версию 2.4" вернёт куски про версии 2.3 и 2.5 так как они семантически близкие
Уверенные галлюцинации - если retrieval отдал нерелевантные чанки, она уверенно ответит по тому мусору, который ей дали
Что важно подметить?
Используйте Basic RAG для проверки гипотезы, что в задаче вообще есть проблема, которую RAG может решить. Это 1-2 недели работы и дешевле.
Не задерживайтесь на нём. В проде Basic RAG это всего лишь сырой бот, который работает не стабильно. Через время стоит улучшать подход до первых жалоб от пользователей.
Сразу с первого дня логируйте, какие чанки попали в LLM. Без этого нельзя понять, проблема в retrieval или в модели.
2. Hybrid RAG или BM25 + Vector Search
Главный апгрейд после Basic, как раз решает те самые проблемы что были на предыдущем подходе.
Представьте библиотеку с двумя библиотекарями. Один (vector search) шарит за смыслы, спросите про «как мне справиться с бессонницей», он найдёт книги про сон, тревожность, медитацию. Второй (BM25) помнит точные названия, номера ISBN, конкретные слова. Спросите его «справочник Иванова 2023 года, глава 4» и вам найдёт за секунду.
По факту вам нужны оба и вы можете их применять. Как ранее подмечали, vector search умеет смысл благодаря embeddings, но проваливается на конкретике, например: версии продуктов, артикулы, имена, коды ошибок. BM25 умеет точные совпадения, но пропускает синонимы. Hybrid берёт лучшее из двух и в production это приносит ощутимый прирост на сложных доменных запросах.
Как это работает на пальцах
Вы делаете два поиска параллельно: один по векторам (semantic), один по словам (BM25). Получаете два списка результатов. Дальше их нужно объединить - обычно через формулу взвешивания (alpha × vector_score + (1-alpha) × bm25_score) или через Reciprocal Rank Fusion, который комбинирует ранки без необходимости приводить скоры к общему масштабу.
Pinecone поддерживает hybrid из коробки через sparse-dense vectors. Weaviate предлагает hybrid query параметром. Qdrant и OpenSearch тоже умеют.
Что важно подметить?
Включите hybrid с самого начала, как только переходите от MVP к чему-то серьёзному. Прирост качества обычно ощутимый, не требуется больших инженерных усилий
Подбирайте alpha value экспериментально - базово 0.5 это middle ground, который не оптимален почти ни для какого домена. Если у вас много специфических терминов и кодов, сдвигайте в сторону BM25 (alpha 0.3-0.4). Если в основном смысловые запросы в сторону vector (0.6-0.7)
Не забывайте про препроцессинг для русского языка - BM25 без стемминга и лемматизации будет считать «запрос» и «запросы» разными словами
3. Reranking RAG
Если hybrid это главное улучшение, то reranking второе по важности. И вот зачем оно нужно.
Представьте найм в компанию. У вас 200 резюме от кандидатов. Первый рекрутер пробегает по ним за час и оставляет топ-30 по ключевым словам. Это быстро, но грубо так как он не вникает в каждое. Второй рекрутер берёт эти 30 и читает их внимательно, сравнивает каждое с конкретной вакансией, понимает нюансы. На выходе получается 5 лучших кандидатов на финал.
Vector search это по сути первый рекрутер. Он работает быстро (один раз посчитал вектор документа, дальше всё через cosine similarity), но грубовато. Reranker как раз второй рекрутер. Берёт пару (запрос, документ) и пропускает через модель целиком, видя их вместе. Поэтому он точнее, но дороже так как нельзя предпосчитать заранее, нужно считать на каждый запрос.
Схема такая:
vector search достаёт 30-100 кандидатов из тысяч -> reranker отбирает топ-5 -> дальше эти топ -5 идут в LLM
Какие reranker'ы использовать
Cohere Rerank 3.5/4.0 - production-grade, поддерживает 100+ языков (включая русский), быстрая интеграция через API.
BGE Reranker (
BAAI/bge-reranker-v2-m3) - open-source, хороший multilingual, можно гонять локально.Jina Reranker - open-source альтернатива.
Cohere показывает в своём блоге, как Embed + Rerank + Chat собираются в end-to-end RAG. Elastic описывает reranker как финальный шаг поверх любого retrieval - keyword, semantic или hybrid.
Сколько это стоит по latency
Reranking добавляет 200-400 мс к запросу. Для чат-ботов, где общая латентность 2-3 секунды (в основном из-за генерации LLM), это норма. Для высоко-спросных API с requirements в 200 мс уже критично, придётся кешировать или пропускать reranker для частых запросов.
Что важно подметить?
Если у вас низкий precision (это когда нашли не-то) - ставьте обязательно reranker раньше, чем меняете embedding-модель.
Не используйте reranker без логирования - вы должны видеть до/после и какие чанки были на топе после vector search и как их переранжировал reranker. Иначе непонятно, помогает он или тупо вредит.
4. Query Transformation RAG
Главная боль большинства RAG-чатботов это когда пользователи пишут как с другом. «А это как работает?», «А по второму пункту?», «Чё там с настройками?». Vector search по таким запросам выдаёт мусор «это» и «там» в эмбеддинге ничего по сути не значат.
Как раз Query Transformation это слой, который превращает кривой пользовательский запрос в нормальный поисковый. Делается одним дополнительным LLM-вызовом перед retrieval.
Основные техники
Подход | Что делает | Когда использовать |
|---|---|---|
Query rewrite | переписывает разговорный запрос в полноценный поисковый | большинство chatbot-ов |
Standalone question | соединяет follow-up с историей чата в самостоятельный вопрос | чат с историей |
Multi-query | генерирует 3-5 переформулировок, ищет по каждой | широкие, неоднозначные запросы |
RAG-Fusion | multi-query + объединение результатов через RRF | когда multi-query даёт overlap |
Step-back | сначала задаёт более общий вопрос, потом точный | очень специфичные запросы |
HyDE | LLM пишет «гипотетический ответ», по нему ищет в базе | короткие запросы в специализированном домене |
HyDE - это одна из популярных техник, например вместо того чтобы искать по короткому запросу пользователя, мы сначала просим LLM сгенерировать гипотетический ответ на этот запрос. Этот ответ может быть фактически неверным но это не важно. Важно, что он структурно похож на реальный документ из базы. И поэтому его эмбеддинг лежит ближе к нужным документам, чем эмбеддинг короткого вопроса.
Что важно подметить?
Standalone-question rewrite - обязательно, если у вас чат с многошаговыми диалогами. Без него retrieval будет ломаться и работать некорректно.
Попробуйте HyDe, если у вас узкий домен - где короткие запросы, но расширенные ответы, например: med/legal/fintech документы.
Multi-query и RAG-Fusion берите для широких запросов - но учитывайте всегда стоимость затрат, не забывайте про экономику.
5. Metadata / Structured RAG
Часто упускаемая возможность, особенно в B2B.
Вспомните, как ищете товар на Amazon. Сначала вы выбираете категорию, потом фильтруете по цене, рейтингу, бренду и только в этом отфильтрованном множестве смотрите карточки. Никто не ищет холодильник, вбивая в поиск «холодильник» и проматывая 10000 результатов.
Metadata RAG - это как раз то же самое для документов. Вместо того чтобы делать semantic search по всей базе, вы сначала отфильтровываете по структурным полям (дата, тип документа, страна, версия, департамент, уровень доступа), потом ищете внутри отфильтрованного.
Простой пример
Запрос: «Покажи AML policy для США, актуальную после января 2025».
Чистый vector search вернёт «похожие документы» - там может оказаться старая версия из США, потому что эмбеддинги плохо различают страны и даты. Metadata RAG сначала отфильтрует: country = "US" AND doc_type = "policy" AND effective_date > "2025-01-01", и только потом сделает semantic search внутри 5-10 оставшихся документов. Точность очень хорошо вырастает.
Основные минусы
Слабая схема метаданных - если в индексе только
filenameиpage, фильтровать будет сложно так как отсутствует. Метаданные нужно продумывать заранее, на этапе индексации.Метаданные не наследуются от документа к чанкам - документ из 50 чанков должен передать каждому из них свои
country,doc_type,date. Иначе фильтр работает только на верхнем уровне.LLM-генерируемые фильтры галлюцинируют - иногда модель придумывает несуществующие поля или enum-значения. Обязательно валидируйте фильтр перед выполнением.
Что важно подметить?
Аудит того, какие метаданные у вас уже есть - filename, дата создания, источник, тип документа например этого уже хватит для 80% фильтров в B2B.
Большой retrieval = продуманная схема метаданных - не спешите индексировать, сперва важно все подготовить заранее.
Не забывайте про безопасность - учитывайте что для multi-tenant систем metadata-фильтр критичен. Например, без
tenant_idв фильтре пользователь компании А может увидеть документы компании Б.
6. Conversational RAG / History-aware RAG
Это, по сути, частный случай query transformation о котором говорили выше, но настолько важный, что заслуживает отдельного раздела. Проблема простая, например пользователь общается с ботом не одиночными вопросами, а диалогом.
— Расскажи про trial offer пожалуйста
— Хорошо, вот что мы предлагаем: ... (ответ от LLM)
— А почему он плохо конвертит?
Если retrieval смотрит только на последнее сообщение ,«А почему он плохо конвертит?» — он понятия не имеет, про что речь. «Он» в эмбеддинге не значит ничего конкретного.
Поэтому нужен слой, который превращает follow-up + историю в самостоятельный вопрос: «Почему trial offer плохо конвертит?»
Альтернатива, которая обычно не работает
Многие команды просто пихают всю историю чата в финальный prompt LLM, надеясь, что модель «сама разберётся». Это работает 5-10 реплик, потом начинаются проблемы:
Контекст-окно заполняется быстро, на запрос уходит 5-10К токенов.
Retrieval всё равно ищет по последнему сообщению то есть основная проблема не решена.
Стоимость растёт линейно с длиной истории.
Standalone-question rewrite решает обе проблемы за один маленький LLM-вызов + это дешевле, надёжнее и работает.
Что важно подметить
Включайте всегда этот подход, если у вас не просто Q&A, а полноценный чат.
Историю передавайте в rewrite в обрезанном виде - последние 4-6 сообщений достаточно. Полная история не нужна, она только нагружает контекст.
7. Agentic RAG
Здесь начинается момент, где RAG перестаёт быть фиксированным pipeline и становится агентом, который сам решает, что делать.
Например детектив ведёт расследование. Получив зацепку, он не идёт по определенному скрипту - он сам решает, к кому пойти первым (свидетель? архив? полицейская база?), какой вопрос задать, что делать, если ответ нерелевантен (пойти к другому источнику, переформулировать вопрос, копнуть глубже). Каждый шаг это решение, основанное на том, что он уже узнал.
Agentic RAG по сути работает так же. На каждом шаге агент решает:
нужно ли искать -> если да, в каком источнике (docs, SQL, Slack, web) -> насколько найденное релевантно -> искать ещё или достаточно -> отвечать или признать что ничего не знает
LangChain описывает Agentic RAG как подход, где агент рассуждает step-by-step. LangGraph даёт фреймворк для построения таких графов решений.
Что важно подметить?
Каждое решение агента - это вызов LLM. Простой запрос, на который Basic RAG ответил бы за 1 LLM-вызов, у agentic'а легко превращается в 4-7 вызовов: «нужен ли retrieval», «какой tool», «релевантно ли», «искать ещё или нет», «финальный ответ». Это умножает стоимость и latency в 4-7 раз.
Для consumer-продукта с большим объёмом запросов это превращает $500/день затрат на LLM в $2-3K. Считайте до того, как внедрять.
Когда agentic реально оправдан?
Несколько разнотипных источников - Docs + SQL + Slack + GitHub Issues когда нельзя сделать фиксированный pipeline, agentic подойдет как одно из удобных решений.
Tool-use поверх retrieval - когда нужно не только найти, но и выполнить (создать тикет, обновить запись).
Динамическое расширение поиска - если первый поиск пуст, агент пробует другую формулировку или другой источник.
Когда не оправдан?
Если у вас один источник, фиксированный паттерн запросов, узкий домен вас не обязательно применять agentic подход. Простой if-else в коде сработает дешевле, быстрее и предсказуемее.
8. Self-corrective / Corrective RAG
Идея очень простая и человеческая, прежде чем уверенно отвечать, перепроверь, что ты вообще нашёл то, что нужно.
К примеру студент на экзамене. Слабый студент пишет первое, что вспомнил. Сильный пишет, потом перечитывает: «А я точно ответил на тот вопрос? А мои аргументы это подтверждают? А может, я перепутал темы?». Если что-то не так, он переписывает.
Corrective RAG (CRAG) делает то же самое для retrieval. Pipeline такой:
Делаем retrieval.
Отдельный judge (LLM или специализированная модель) оценивает: релевантны ли найденные чанки?
Если да - отвечаем по ним.
Если нет - переписываем запрос и ищем заново. Или идём в web search. Или честно говорим что не смогли найти.
Оригинальная статья CRAG предлагает три действия evaluator'а: Correct (используем как есть), Incorrect (отбрасываем local retrieval, идём в web), Ambiguous (объединяем local + web).
Self-RAG идёт дальше - учит саму модель генерировать reflection-токены, сигналы вроде «нужен ли retrieval», «релевантен ли passage», «полностью ли поддержан мой ответ». Это требует fine-tuning, поэтому в продакшене встречается реже.
Практичный минимум
Не обязательно внедрять Self-RAG с fine-tuning. Многие команды делают так:
Retrieve.
LLM-grader проверяет: «эти чанки достаточны для ответа? да/нет, и почему».
Если да - генерируем ответ.
Если нет - переписываем запрос (учитывая reason от grader'а), retrieve ещё раз. Один retry.
Если опять нет, отвечаем честно: «недостаточно данных».
Это даёт 80% пользы Self-RAG за 20% сложности. Главное это не забыть честно отказываться, когда данных нет, а не выдавать confident bullshit.
Что важно подметить?
Включайте в доменах где большие риски - например медицина, юриспруденция, finance, compliance, enterprise support. Так как «уверенный неправильный ответ» хуже, чем «не знаю».
В consumer-продуктах часто избыточно - пользователи быстрее сами поправят бот, чем вы окупите дополнительный LLM-вызов на каждом запросе.
Добавляйте в last resort fallback - если retrieval вернул чанки с очень низким similarity score, лучше отказать, чем пытаться отвечать.
9. GraphRAG
Честно, полезный для своих задач, но бесполезный для большинства.
Если дать аналогию, то вспомните детективные фильмы, где следователь стоит у доски с фотографиями подозреваемых, соединёнными нитками. На каждой нитке подпись: «работал с ним», «бывшая жена», «делил счёт в банке». Эта доска - knowledge graph. Она показывает не отдельные факты, а связи между фактами. И когда вопрос звучит как «кто из этих людей был связан с компанией X в 2022?», то легко найти ответ в доске.
GraphRAG делает то же самое для текстовых корпусов. На этапе индексации LLM прогоняется по всем документам и извлекает: сущности (люди, компании, события) и связи между ними. Дальше всё это собирается в граф, плюс LLM пишет summaries для кластеров (communities) - групп тесно связанных сущностей.
На запросе можно ходить двумя способами:
Local query: про конкретную сущность («что мы знаем про X?»). Пробегаем по графу от X, собираем соседей, отвечаем.
Global query: про весь корпус («какие основные темы?»). Используем заранее посчитанные community summaries.
Microsoft Research показала, что GraphRAG обыгрывает обычный baseline RAG на global-вопросах с win rate 70-80%. Open-source реализация доступна на microsoft.github.io/graphrag.
Что важно подметить?
GraphRAG очень дорогой, не забывайте про экономику
Индексация - это когда прогонка LLM по всему корпусу несколько раз. Для корпуса в 100 МБ текста это легко $50-200 на одну индексацию через GPT-4o, и кучу потраченного времени. Microsoft в документации прямо предупреждает: «индексация может быть дорогой операцией, начинайте с малого».
Поддержка - при изменении документов нужно пересчитывать затронутые куски графа. Это нетривиально и легко может сломаться.
Когда стоит брать?
Вопросы про связи: «Какие компании связаны с этим человеком?», «Как менялась стратегия проекта за год?», «Какие скрытые зависимости между департаментами?»
Анализ больших корпусов целиком: «Какие recurring themes в 500 интервью пользователей?»
Расследования и compliance, где важно reconstruct сеть участников/событий.
Когда НЕ брать
Для обычного FAQ или бота по docs. Если у вас 30 страниц документации не надо строить граф. Hybrid + reranker + metadata закроют 95% задач при цене в 100 раз ниже.
10. Multimodal RAG
Если ваш запрос содержит не просто текст, а PDF с таблицами, презентации со слайдами, скриншоты UI или отчёты с графиками, то обычный text-only RAG теряет половину смысла. Multimodal RAG это чинит.
Представьте аналитика, который читает квартальный отчёт. Половина важной информации сидит в графиках выручки и таблицах с метриками. Если бы он читал только текст вокруг, он понял бы только обёртку - «выручка выросла», но не на сколько, в каких регионах. Графики и таблицы это полезные данные, и они должны быть проиндексированы.
Два основных паттерна
Паттерн 1: Image embeddings (true multimodal) - используется multimodal embedding-модель (CLIP, Cohere Embed v4, Voyage Multimodal), которая кодирует и текст, и картинки в единое векторное пространство. На запрос «график выручки за Q3» можно найти и текстовое описание, и сам график. Простой архитектурно, но качество multimodal embedders пока отстаёт от лучших text-only моделей.
Паттерн 2: Image-to-text summaries - извлекаем картинки, прогоняем через vision LLM (GPT-4o, Claude), генерируем текстовое описание, индексируем описание как обычный текст. На retrieval отдаём LLM и описание, и саму картинку. Дороже на индексации, зато можно использовать ваши обычные text embedders, и качество описаний у современных vision-моделей очень хорошее.
На практике для PDF с таблицами и графиками паттерн 2 обычно работает лучше, потому что text embedders зрелее. Но это медленнее и дороже на этапе индексации корпуса.
IBM описывает multimodal RAG как расширение для разных типов данных. LlamaIndex/LlamaParse даёт готовый pipeline для индексации сложных PDF с таблицами и картинками.
Что важно подметить?
Если ваш корпус это в основном PDF с таблицами и графиками (отчёты, презентации, regulatory docs) - без multimodal вы теряете 30-50% смысла. Попробуйте включать.
Если корпус текстовый (markdown, support tickets, code) - отложите. Это не ваша проблема.
Начните с паттерна 2 - он надёжнее и сразу даёт результат. К multimodal embeddings вернётесь, когда они дозреют.
Практичный путь к production обычно выглядит так:
Начните с Basic RAG, чтобы проверить саму проблему.
Добавьте hybrid search, чтобы улучшить покрытие retrieval.
Добавьте reranking, чтобы повысить точность.
Добавьте metadata filtering для структурированных и enterprise-сценариев.
Добавьте query rewriting, если у вас полноценный чат, а не просто Q&A.
Добавляйте corrective, agentic, graph или multimodal-подходы только тогда, когда продукту они действительно нужны.
Самая большая ошибка - не в том, что вы выбрали неправильный RAG-фреймворк.Самая большая ошибка - строить сложную архитектуру до того, как вы измерили, где именно система ломается.
Большинство RAG-систем проваливаются потому, что никто не логировал найденные чанки, никто не измерял качество retrieval, и никто не проверял, можно ли вообще ответить на вопрос пользователя на основе доступных данных.
Если вам понравилась эта статья, буду благодарен за вашу поддержку.
Email: akzhankalimatov@gmail.com