На фоне обновлений в LLM-стеке за последний год, всё больше команд используют RAG (Retrieval-Augmented Generation) в продакшене. Ниже — практический обзор подходов, которые реально работают, с примерами и рекомендациями по применению.

Что такое RAG (если коротко)

RAG (Retrieval-Augmented Generation) — это подход, при котором LLM отвечает не на основе внутренних знаний, а используя контекст из внешней базы. Схема проста: «вопрос пользователя → поиск релевантных фрагментов → передача контекста LLM → генерация ответа со ссылками на источники».

Зачем это нужно? Модель не знает вашу документацию, тикеты, политики или свежие новости. RAG решает эту проблему без fine-tuning. Это дешевле, быстрее, проще обновлять и объяснять регуляторам. Далее — разбор подходов, чем они отличаются и когда какой использовать.

1. Basic / 2-step RAG

Это базовый подход, с которого начинают большинство. Представьте ассистента с доступом к папке документов. Он ищет по запросу, находит подходящие фрагменты и использует их как контекст для ответа.

Технически: вопрос → vector search → топ-N фрагментов → LLM генерирует ответ.

Этого достаточно для MVP. LangChain предлагает готовые туториалы: нарезаете документы, считаете эмбеддинги, кладёте в Chroma или FAISS, подключаете LLM. Собрать можно за день.

Основные минусы

• Размер чанка: слишком мал — теряется контекст; слишком велик — модель тонет в шуме. Универсального решения нет — нужно тестировать.
• Vector search не всегда точен: запрос про «версию 2.4» может вернуть фрагменты про 2.3 и 2.5 из-за семантической близости.
• Галлюцинации: если retrieval вернул нерелевантные фрагменты, LLM уверенно ответит на их основе.

Что важно подметить?

• Используйте Basic RAG для проверки гипотезы: решает ли RAG вашу задачу. Это дешёвый и быстрый способ (1–2 недели).
• Не задерживайтесь на нём. В продакшене это сырой бот с нестабильной работой. Улучшайте при первых жалобах.
• Логируйте, какие фрагменты попали в LLM. Это помогает понять: проблема в retrieval или в генерации.

2. Hybrid RAG или BM25 + Vector Search

Главный апгрейд после Basic RAG. Решает слабые стороны чисто семантического поиска.

Представьте двух библиотекарей: один (vector search) понимает смысл — спросите «как справиться с бессонницей», он найдёт книги про сон и медитацию. Второй (BM25) знает точные названия и коды — спросите «справочник Иванова 2023, глава 4» — найдёт мгновенно.

Vector search хорош для смысла, но слаб на точных терминах: версии, артикулы, имена. BM25 точен в словах, но не понимает синонимы. Hybrid RAG объединяет оба подхода и даёт прирост в сложных доменах.

Как это работает

Два поиска параллельно: семантический (vector) и точный (BM25). Результаты объединяют через:

• Взвешивание: alpha × vector_score + (1-alpha) × bm25_score
• Reciprocal Rank Fusion (RRF): комбинирует ранги без нормализации.

Pinecone поддерживает hybrid через sparse-dense vectors. Weaviate, Qdrant и OpenSearch тоже умеют.

Что важно подметить?

• Включайте hybrid сразу после MVP. Прирост качества ощутим, усилия — минимальны.
• Подбирайте alpha экспериментально. Базовое 0.5 редко оптимально. Если много кодов — сдвигайте к BM25 (0.3–0.4). Если смысловые запросы — к vector (0.6–0.7).
• Для русского языка делайте стемминг и лемматизацию. Без этого BM25 будет считать «запрос» и «запросы» разными словами.

3. Reranking RAG

Второе по важности улучшение после hybrid. Решает проблему грубого отбора на этапе retrieval.

Представьте отбор кандидатов: первый рекрутер быстро отбирает топ-30 по ключевым словам. Второй внимательно читает эти 30 и выбирает 5 лучших. Vector search — это первый рекрутер. Reranker — второй.

Он анализирует пару «запрос-документ» целиком, что делает его точнее, но дороже — нельзя предпосчитать, нужно считать на каждый запрос.

Схема: vector search → 30–100 кандидатов → reranker → топ-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 и Elastic описывают reranker как финальный шаг поверх любого retrieval — keyword, semantic или hybrid.

Сколько это стоит по latency

Reranking добавляет 200–400 мс. Для чат-ботов (общая задержка 2–3 сек) — норма. Для высоконагруженных API с требованием 200 мс — критично. Можно кешировать или пропускать для частых запросов.

Что важно подметить?

• Если низкий precision (много нерелевантных результатов) — ставьте reranker до смены embedding-модели.
• Логируйте до и после reranking. Иначе невозможно понять, помогает ли он или вредит.

4. Query Transformation RAG

Проблема большинства RAG-чатов — разговорные запросы: «А это как работает?», «Чё там с настройками?». Vector search по таким запросам возвращает мусор — «это» и «там» не несут смысла.

Query Transformation — это слой, который превращает разговорный запрос в поисковый. Делается через дополнительный вызов LLM перед retrieval.

Основные техники

• Query rewrite: переформулирует разговорный запрос в полноценный. Подходит для большинства чат-ботов.
• Standalone question: объединяет follow-up с историей в самостоятельный вопрос. Нужно при диалогах.
• Multi-query: генерирует 3–5 переформулировок, ищет по каждой. Для широких, неоднозначных запросов.
• RAG-Fusion: multi-query + объединение через RRF. Уменьшает дубли.
• Step-back prompting: сначала задаёт общий вопрос, потом точный. Для очень специфичных запросов.
• HyDE (Hypothetical Document Embeddings): LLM генерирует гипотетический ответ, по нему ищут. Даже если ответ неверен, его структура близка к реальным документам, поэтому поиск точнее. Полезно при коротких запросах в узких доменах (медицина, юриспруденция).

Что важно подметить?

• Standalone question — обязательно при диалогах. Без него retrieval ломается.
• Попробуйте HyDE в узких доменах с короткими запросами.
• Multi-query и RAG-Fusion — для широких запросов, но учитывайте стоимость.

5. Metadata / Structured RAG

Часто упускаемый, но мощный инструмент, особенно в B2B.

Представьте поиск на Amazon: сначала выбираете категорию, фильтруете по цене, бренду — и только потом смотрите товары. Так же и в RAG: вместо полного семантического поиска сначала фильтруем по метаданным.

Metadata RAG: фильтрация по полям (дата, тип документа, страна, версия) → семантический поиск в отфильтрованном подмножестве.

Простой пример

Запрос: «Покажи AML policy для США, актуальную после января 2025».

Чистый vector search может вернуть старую версию из США — эмбеддинги слабо различают даты и страны. Metadata RAG сначала фильтрует: country = "US" AND doc_type = "policy" AND effective_date > "2025-01-01", затем ищет внутри 5–10 документов. Точность резко растёт.

Основные минусы

• Слабая схема метаданных: если есть только filename и page — фильтровать не по чему. Нужно продумывать на этапе индексации.
• Метаданные не наследуются: 50 чанков из одного документа должны получить одинаковые метаданные (страна, тип, дата). Иначе фильтр не работает.
• Галлюцинации LLM: модель может придумать несуществующие поля. Фильтры нужно валидировать перед выполнением.

Что важно подметить?

• Проведите аудит: filename, дата создания, источник, тип документа — этого хватит для 80% фильтров.
• Большой retrieval требует продуманной схемы метаданных. Не спешите индексировать — подготовьтесь заранее.
• Учитывайте безопасность: в multi-tenant системах метаданные (например, tenant_id) критичны. Без них пользователь компании А может увидеть документы компании Б.

6. Conversational RAG / History-aware RAG

Частный случай query transformation, но настолько важный, что заслуживает отдельного места.

Пример диалога:

— Расскажи про trial offer.
— Вот что мы предлагаем: ...
— А почему он плохо конвертит?

Если retrieval смотрит только на последнее сообщение, он не понимает, что «он» — это trial offer. Нужно преобразовать: «Почему trial offer плохо конвертит?»

Альтернатива, которая не работает

Многие просто добавляют всю историю в prompt. Это работает 5–10 реплик, потом:

• Контекстное окно заполняется быстро (5–10K токенов).
• Retrieval всё равно ищет по последнему сообщению — проблема не решена.
• Стоимость растёт линейно с длиной диалога.

Standalone-question rewrite решает всё: один маленький LLM-вызов, дешевле, надёжнее.

Что важно подметить

• Включайте всегда, если у вас чат (не просто Q&A).
• Передавайте в rewrite только последние 4–6 сообщений. Полная история не нужна — только нагрузка.

7. Agentic RAG

Здесь RAG превращается в агента, который сам решает, что делать.

Как детектив: получил зацепку — решает, к кому идти (свидетель, архив), какой вопрос задать, что делать, если ответ нерелевантен.

Agentic RAG:

• Решает, нужно ли искать.
• Выбирает источник (документы, SQL, Slack, веб).
• Оценивает релевантность.
• Решает, искать дальше или отвечать.

LangChain называет это подходом с пошаговым рассуждением. LangGraph позволяет строить такие графы решений.

Что важно подметить

Каждое решение — вызов LLM. Один запрос может стоить 4–7 вызовов вместо одного. Это умножает стоимость и задержку.

Для продукта с высокой нагрузкой это может увеличить расходы с $500 до $2–3K в день. Считайте перед внедрением.

Когда agentic оправдан?

• Несколько источников: Docs + SQL + Slack + GitHub.
• Нужно не только найти, но и выполнить действие (создать тикет, обновить запись).
• Динамическое расширение поиска: если первый поиск пуст — пробует другую формулировку или источник.

Когда не оправдан?

Если у вас один источник, фиксированные запросы, узкий домен — не применяйте. Простой if-else в коде будет дешевле, быстрее и предсказуемее.

8. Self-corrective / Corrective RAG

Идея: перед ответом проверить, достаточно ли данных.

Как студент на экзамене: сильный перечитывает ответ — «А я точно ответил на вопрос? Аргументы подтверждают?» — и, если нет, переписывает.

Corrective RAG (CRAG):

1. Retrieval.
2. Оценка релевантности (judge — LLM или модель).
3. Если да — отвечаем.
4. Если нет — переписываем запрос, ищем снова или говорим «не знаю».

CRAG предлагает три действия: Correct (использовать), Incorrect (перейти в веб), Ambiguous (объединить local + web).

Self-RAG идёт дальше: модель сама генерирует сигналы вроде «нужен retrieval», «релевантен ли фрагмент». Требует fine-tuning, поэтому редко в продакшене.

Практичный минимум

Многие делают так:

1. Retrieve.
2. LLM-grader проверяет: «достаточно ли чанков для ответа? да/нет, почему».
3. Если да — генерируем ответ.
4. Если нет — переписываем запрос (с учётом причины), ищем ещё раз. Один retry.
5. Если опять нет — отвечаем: «недостаточно данных».

Это даёт 80% пользы Self-RAG за 20% сложности. Главное — честно отказываться, а не выдавать уверенные неправильные ответы.

Что важно подметить?

• Включайте в рисковых доменах: медицина, юриспруденция, финансы, compliance. «Уверенный неправильный ответ» хуже, чем «не знаю».
• В consumer-продуктах часто избыточно: пользователи быстрее поправят бота, чем вы окупите дополнительный вызов LLM.
• Добавьте fallback: если similarity очень низкий — лучше отказаться, чем отвечать.

9. GraphRAG

Полезен для своих задач, но бесполезен для большинства.

Представьте доску с подозреваемыми и нитками: «работал с ним», «бывшая жена». Это knowledge graph — связи между сущностями.

GraphRAG: на этапе индексации LLM извлекает сущности (люди, компании) и связи. Строится граф + summaries для кластеров (communities).

Запросы:

• Local: про сущность («что знаем про X?») — идём по связям.
• Global: про весь корпус («какие темы?») — используем summaries.

Microsoft Research показала: GraphRAG обыгрывает обычный RAG на global-вопросах (70–80% win rate). Реализация: microsoft.github.io/graphrag.

Что важно подметить?

GraphRAG очень дорогой:

• Индексация: прогонка LLM по всему корпусу. Для 100 МБ текста — $50–200 через GPT-4o.
• Поддержка: при изменении документов нужно пересчитывать части графа. Это сложно и легко сломать.

Когда стоит брать?

• Вопросы про связи: «Какие компании связаны с этим человеком?»
• Анализ больших корпусов: «Какие темы в 500 интервью?»
• Расследования, compliance — когда нужно восстановить сеть.

Когда НЕ брать?

Для FAQ или бота по документации. Если 30 страниц — не стройте граф. Hybrid + reranker + metadata решат 95% задач за 1/100 стоимости.

10. Multimodal RAG

Если в вашем корпусе PDF с таблицами, презентации, скриншоты — обычный text-only RAG теряет смысл. Multimodal RAG это исправляет.

Представьте аналитика, читающего отчёт. Половина информации — в графиках и таблицах. Без них он поймёт только «выручка выросла», но не на сколько и где.

Два основных паттерна

Паттерн 1: Image embeddings (true multimodal)
Используются multimodal модели (CLIP, Cohere Embed v4, Voyage Multimodal), кодирующие текст и изображения в одно векторное пространство. На запрос «график выручки за Q3» можно найти и описание, и сам график. Просто, но качество пока уступает text-only моделям.

Паттерн 2: Image-to-text summaries
Извлекаем изображения, прогоняем через vision LLM (GPT-4o, Claude), генерируем текстовое описание, индексируем как обычный текст. Дороже, но надёжнее — можно использовать зрелые text embedders.

Для PDF с таблицами и графиками паттерн 2 обычно лучше. Но медленнее и дороже на индексацию.

IBM описывает multimodal RAG как расширение для разных данных. LlamaIndex/LlamaParse даёт готовый pipeline для сложных PDF.

Что важно подметить?

• Если корпус — PDF с таблицами и графиками (отчёты, презентации), без multimodal вы теряете 30–50% смысла. Включайте.
• Если корпус текстовый (markdown, тикеты, код) — отложите. Это не ваша проблема.
• Начните с паттерна 2 — он надёжнее. К multimodal embeddings вернётесь, когда они дозреют.

Всем привет, на фоне обновлений в 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

сначала задаёт более общий вопрос, потом точный

очень специфичные запросы

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 такой:

1. Делаем retrieval.
2. Отдельный judge (LLM или специализированная модель) оценивает: релевантны ли найденные чанки?
3. Если да - отвечаем по ним.
4. Если нет - переписываем запрос и ищем заново. Или идём в web search. Или честно говорим что не смогли найти.

Оригинальная статья CRAGпредлагает три действия evaluator'а:Correct(используем как есть),Incorrect(отбрасываем local retrieval, идём в web),Ambiguous(объединяем local + web).

Self-RAGидёт дальше - учит саму модель генерировать reflection-токены, сигналы вроде «нужен ли retrieval», «релевантен ли passage», «полностью ли поддержан мой ответ». Это требует fine-tuning, поэтому в продакшене встречается реже.

Практичный минимум

Не обязательно внедрять Self-RAG с fine-tuning. Многие команды делают так:

1. Retrieve.
2. LLM-grader проверяет: «эти чанки достаточны для ответа? да/нет, и почему».
3. Если да - генерируем ответ.
4. Если нет - переписываем запрос (учитывая reason от grader'а), retrieve ещё раз. Один retry.
5. Если опять нет, отвечаем честно: «недостаточно данных».

Это даёт 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 вернётесь, когда они дозреют.

Если вам понравилась эта статья, буду благодарен за вашу поддержку.

Email:akzhankalimatov@gmail.com