RAG (Retrieval-Augmented Generation) — что это и как работает

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

Про «агентную экономику» и точность ответов ИИ говорят всё чаще, и RAG — одна из ключевых технологий за этими разговорами. Она используется в корпоративных чат-ботах, поисковых системах (Perplexity, Bing Chat) и системах поддержки. Этот материал — практическая карта: что такое RAG, из каких этапов состоит и где даёт результат.

Что такое RAG простыми словами

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

Технически RAG состоит из трёх этапов:

1. Retrieval (поиск) — система находит релевантные документы по запросу пользователя
2. Augmentation (дополнение) — найденные документы добавляются в промпт к LLM как контекст
3. Generation (генерация) — LLM генерирует ответ, опираясь на предоставленный контекст

Как работает RAG: архитектура

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

Этап 1: Индексация документов

До начала работы RAG необходимо подготовить базу знаний:

1. Загрузка документов — PDF, HTML, Markdown, базы данных, API. Корпоративные RAG обычно работают с 10-100 тыс. документов
2. Чанкинг (chunking) — разбиение документов на фрагменты по 200-500 токенов. Слишком большие чанки снижают релевантность, слишком маленькие теряют контекст
3. Эмбеддинг (embedding) — каждый чанк превращается в числовой вектор (768-3072 измерений) через embedding-модель (OpenAI text-embedding-3-small, Cohere embed, E5, BGE)
4. Сохранение в векторную БД — векторы индексируются для быстрого поиска по сходству. Популярные решения: Pinecone, Weaviate, Qdrant, ChromaDB, pgvector (PostgreSQL)

Этап 2: Поиск по запросу

Когда пользователь задаёт вопрос:

1. Запрос превращается в вектор через ту же embedding-модель
2. Векторная БД находит top-K ближайших чанков (cosine similarity, обычно K = 3-10)
3. Опционально: reranker (Cohere Rerank, BGE-reranker) переоценивает top-K по смысловой релевантности
4. Финальные чанки отдаются на следующий этап

Этап 3: Генерация ответа

Промпт для LLM формируется так:

Системный промпт: "Отвечай на основе предоставленного контекста.
Если ответа нет в контексте — скажи об этом."

Контекст:
[Чанк 1: текст из документа]
[Чанк 2: текст из документа]
[Чанк 3: текст из документа]

Вопрос пользователя: "..."

LLM генерирует ответ, основанный на контексте, а не на обучающих данных. Это радикально снижает галлюцинации — модель отвечает тем, что «видит», а не тем, что «помнит».

Зачем RAG если можно дообучить модель

RAG и дообучение (fine-tuning) решают разные задачи и часто работают вместе. Fine-tuning меняет поведение и стиль модели, но требует переобучения при каждом обновлении данных. RAG оставляет модель неизменной и подставляет свежий контекст из базы — обновить знания можно за минуты, не трогая веса. Для задач, где данные меняются часто, RAG обычно выгоднее. Сравнение по ключевым параметрам — в таблице ниже.

Fine-tuning меняет знания модели. RAG меняет контекст — модель остаётся прежней, но видит нужные данные. Для корпоративных задач (где данные обновляются ежедневно) RAG почти всегда предпочтительнее.

Продвинутые техники RAG

Базовый RAG — «один запрос, один поиск, один ответ» — покрывает простые случаи, но проседает на сложных вопросах и точных совпадениях. Продвинутые техники достраивают этот контур: гибридный поиск добавляет точность, multi-hop связывает несколько шагов рассуждения, агентный подход даёт модели самой решать, что и когда искать. Ниже три наиболее применимых на практике приёма.

Hybrid Search

Комбинация векторного поиска (semantic) с классическим полнотекстовым (BM25/TF-IDF). Векторный находит смысл, BM25 находит точные совпадения (номера документов, имена, коды). Результаты объединяются через reciprocal rank fusion.

Multi-hop RAG

Для сложных вопросов, требующих нескольких шагов рассуждения. Первый поиск находит промежуточные факты, которые используются для второго поиска. Пример: «Кто руководит компанией, которая выпустила GPT-4?» → поиск «кто выпустил GPT-4» → OpenAI → поиск «руководитель OpenAI» → Sam Altman.

Agentic RAG

LLM сама решает, когда и что искать. Вместо жёсткого pipeline «вопрос → поиск → ответ» агент может:

• Решить, нужен ли поиск или хватит собственных знаний
• Выбрать из нескольких источников (документы, API, БД)
• Переформулировать запрос если первый поиск не дал результатов
• Вызвать инструменты (калькулятор, код, API)

Где применяется RAG

RAG применяется везде, где ответ должен опираться на конкретную, часто обновляемую базу знаний, а не на общую память модели. Типичные сценарии — поддержка по внутренней документации, поиск с цитированием источников, работа с юридическими, медицинскими и техническими текстами. Объединяет их одно требование: ответ нужно подтвердить ссылкой на первоисточник. Конкретные направления — ниже.

• Корпоративные чат-боты — ответы по внутренней документации (Notion, Confluence, SharePoint). Пример: IT-support бот, обученный на 5000 тикетах
• Поисковые системы — Perplexity AI, Bing Chat, Google AI Overviews — все используют RAG-подход
• Юридические AI — поиск по базе законов и прецедентов
• Медицинские AI — ответы на основе клинических гайдлайнов
• Промышленность — RAG по технической документации оборудования. На ruaut.ru мы исследуем применение RAG для автоматизации: поиск по даташитам контроллеров, ГОСТам, проектной документации

AI-экспертный комментарий

RAG я применяю ежедневно в собственной системе обработки знаний — это даёт практический, а не теоретический взгляд на то, где технология реально выигрывает и обо что спотыкается на проде. Ниже — выводы из этой работы: что определяет качество ответов на практике и почему выбор модели влияет меньше, чем принято считать.

Я использую RAG ежедневно в работе с Metacortex Core — собственной системой обработки знаний. Pipeline: ingested документы → dual ASR → chunking → embeddings → SQLite store → query API. Ключевой инсайт из практики: качество RAG на 70% определяется качеством чанкинга, а не выбором LLM. Мы тестировали одни и те же запросы на GPT-4, Claude и Qwen 72B — разница в качестве ответов 5-10%. А замена наивного чанкинга (500 токенов, без overlap) на semantic chunking (по смыслу абзацев, с 10% overlap) дала прирост точности на 35%. — Павел Кияткин, архитектор ИИ-систем

Источники

1. Lewis P. et al. «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks». 2020. arxiv.org/abs/2005.11401
2. Gao Y. et al. «Retrieval-Augmented Generation for Large Language Models: A Survey». 2023. arxiv.org/abs/2312.10997

Связанные концепты

• Большие языковые модели (LLM) — базовая технология, которую RAG дополняет
• Embeddings — векторные представления текста, основа поиска в RAG
• Промпт-инженеринг — формирование запросов к LLM, включая контекст из RAG