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

Базовый вариант, Basic RAG, строится за 1–2 недели: документы нарезаются на чанки, по ним считаются эмбеддинги, результаты складываются в Chroma или FAISS, поверх подключается LLM. LangChain предоставляет готовые туториалы. Главные слабые места — размер чанка (слишком маленький обрезает контекст, слишком большой топит модель в шуме) и неточность векторного поиска: запрос про «версию 2.4» вернёт куски про 2.3 и 2.5, потому что семантически они близки. Если retrieval отдал нерелевантные фрагменты, модель уверенно ответит по ним — это классическая уверенная галлюцинация. С первого дня нужно логировать, какие чанки попали в LLM: без этого невозможно понять, где ломается система — в retrieval или в генерации.

ТехникаЧто делаетКогда использовать
Query rewriteПереписывает разговорный запрос в полноценный поисковыйБольшинство чат-ботов
Standalone questionСоединяет follow-up с историей чата в самостоятельный вопросЧат с историей
Multi-queryГенерирует 3–5 переформулировок, ищет по каждойШирокие, неоднозначные запросы
RAG-FusionMulti-query + объединение результатов через RRFКогда multi-query даёт overlap
Step-backСначала задаёт более общий вопрос, потом точныйОчень специфичные запросы
HyDELLM пишет гипотетический ответ, по нему ищет в базеКороткие запросы в специализированном домене

Hybrid RAG — первый обязательный апгрейд после MVP. Он объединяет семантический поиск (vector search на эмбеддингах) и BM25 — алгоритм точного совпадения по словам. Векторный поиск хорошо улавливает смысл, но проваливается на конкретике: версиях продуктов, артикулах, именах, кодах ошибок. BM25 справляется с точными совпадениями, но пропускает синонимы. Результаты двух поисков объединяются через взвешенную формулу (alpha × vector_score + (1-alpha) × bm25_score) или через Reciprocal Rank Fusion. Значение alpha подбирается экспериментально: 0.3–0.4 — если в базе много специфических терминов и кодов, 0.6–0.7 — если запросы преимущественно смысловые. Pinecone, Weaviate, Qdrant и OpenSearch поддерживают hybrid-режим. Для русского языка BM25 требует стемминга и лемматизации — без них «запрос» и «запросы» будут считаться разными словами.

Hybrid RAG объединяет семантический поиск и BM25, что даёт ощутимый прирост на запросах с версиями, артикулами и именами.

10 RAG-подходов для продакшена: от базового поиска до Query Transformation
· Источник: Habr AI

Reranking — второй по значимости апгрейд. Векторный поиск быстро отбирает 30–100 кандидатов из тысяч документов, но делает это грубо: он сравнивает векторы по отдельности. Reranker получает пару (запрос, документ) и оценивает их вместе, видя полный контекст. Из 30–100 кандидатов он отбирает топ-5, которые уходят в LLM. Среди готовых решений: Cohere Rerank 3.5/4.0 — production-grade с поддержкой 100+ языков, включая русский, интеграция через API; BAAI/bge-reranker-v2-m3 — open-source, multilingual, можно запускать локально; Jina Reranker — ещё одна open-source альтернатива. Reranking добавляет 200–400 мс к запросу. Для чат-бота с общей латентностью 2–3 секунды это приемлемо; для API с требованием в 200 мс придётся кешировать или отключать reranker для частых запросов. Если у системы низкий precision — reranker стоит поставить раньше, чем менять embedding-модель.

Query Transformation решает другую проблему: пользователи пишут как в мессенджере — «а это как работает?», «чё там с настройками?», «по второму пункту». Слова «это» и «там» в эмбеддинге почти ничего не значат, и векторный поиск возвращает мусор. Трансформация добавляет один LLM-вызов перед retrieval, который превращает разговорный запрос в полноценный поисковый. Существует несколько техник: Query rewrite переписывает запрос в поисковый формат; Standalone question соединяет follow-up с историей чата в самостоятельный вопрос — обязательный приём для многошаговых диалогов; Multi-query генерирует 3–5 переформулировок и ищет по каждой; RAG-Fusion добавляет к этому объединение результатов через RRF; Step-back сначала задаёт более общий вопрос, потом точный — помогает на очень специфичных запросах. Отдельно стоит HyDE (Hypothetical Document Embeddings): LLM генерирует гипотетический ответ на запрос — фактически неверный, но структурно похожий на реальный документ. Эмбеддинг такого ответа оказывается ближе к нужным документам базы, чем эмбеддинг короткого вопроса. Техника особенно эффективна для коротких запросов в специализированных доменах.