RAG (Retrieval-Augmented Generation) — что это и как работает
Кратко. RAG (Retrieval-Augmented Generation) — архитектурный паттерн, при котором языковая модель (LLM) перед генерацией ответа получает релевантный контекст из внешней базы знаний. Это решает главную проблему LLM — галлюцинации и устаревшие данные. Вместо того чтобы полагаться только на обучающие данные, модель «читает» актуальные документы и отвечает на их основе. RAG используется в корпоративных чат-ботах, поисковых системах (Perplexity, Bing Chat) и системах поддержки.
Что такое RAG простыми словами
Представьте студента на экзамене. Обычная LLM — студент, который отвечает по памяти: иногда точно, иногда выдумывает. RAG — студент, которому разрешили открыть конспект: он ищет нужную страницу, читает и отвечает на основе прочитанного. Ответ точнее, потому что основан на источнике, а не на воспоминаниях.
Технически RAG состоит из трёх этапов:
- Retrieval (поиск) — система находит релевантные документы по запросу пользователя
- Augmentation (дополнение) — найденные документы добавляются в промпт к LLM как контекст
- Generation (генерация) — LLM генерирует ответ, опираясь на предоставленный контекст
Как работает RAG: архитектура
Этап 1: Индексация документов
До начала работы RAG необходимо подготовить базу знаний:
- Загрузка документов — PDF, HTML, Markdown, базы данных, API. Корпоративные RAG обычно работают с 10-100 тыс. документов
- Чанкинг (chunking) — разбиение документов на фрагменты по 200-500 токенов. Слишком большие чанки снижают релевантность, слишком маленькие теряют контекст
- Эмбеддинг (embedding) — каждый чанк превращается в числовой вектор (768-3072 измерений) через embedding-модель (OpenAI text-embedding-3-small, Cohere embed, E5, BGE)
- Сохранение в векторную БД — векторы индексируются для быстрого поиска по сходству. Популярные решения: Pinecone, Weaviate, Qdrant, ChromaDB, pgvector (PostgreSQL)
Этап 2: Поиск по запросу
Когда пользователь задаёт вопрос:
- Запрос превращается в вектор через ту же embedding-модель
- Векторная БД находит top-K ближайших чанков (cosine similarity, обычно K = 3-10)
- Опционально: reranker (Cohere Rerank, BGE-reranker) переоценивает top-K по смысловой релевантности
- Финальные чанки отдаются на следующий этап
Этап 3: Генерация ответа
Промпт для LLM формируется так:
Системный промпт: "Отвечай на основе предоставленного контекста.
Если ответа нет в контексте — скажи об этом."
Контекст:
[Чанк 1: текст из документа]
[Чанк 2: текст из документа]
[Чанк 3: текст из документа]
Вопрос пользователя: "..."LLM генерирует ответ, основанный на контексте, а не на обучающих данных. Это радикально снижает галлюцинации — модель отвечает тем, что «видит», а не тем, что «помнит».
Зачем RAG если можно дообучить модель?
| Подход | RAG | Fine-tuning | Длинный контекст (1M tokens) |
|---|---|---|---|
| Актуальность данных | Минуты (обновление БД) | Недели (переобучение) | Минуты (загрузка) |
| Стоимость | Низкая (только inference) | Высокая (GPU × часы) | Высокая (каждый запрос) |
| Прозрачность | Высокая (видно источники) | Низкая (чёрный ящик) | Средняя |
| Масштаб данных | Миллионы документов | Ограничен GPU RAM | Ограничен контекстным окном |
| Галлюцинации | Сильно снижены | Не решает | Не решает полностью |
Fine-tuning меняет знания модели. RAG меняет контекст — модель остаётся прежней, но видит нужные данные. Для корпоративных задач (где данные обновляются ежедневно) RAG почти всегда предпочтительнее.
Продвинутые техники RAG
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
- Корпоративные чат-боты — ответы по внутренней документации (Notion, Confluence, SharePoint). Пример: IT-support бот, обученный на 5000 тикетах
- Поисковые системы — Perplexity AI, Bing Chat, Google AI Overviews — все используют RAG-подход
- Юридические AI — поиск по базе законов и прецедентов
- Медицинские AI — ответы на основе клинических гайдлайнов
- Промышленность — RAG по технической документации оборудования. На ruaut.ru мы исследуем применение RAG для автоматизации: поиск по даташитам контроллеров, ГОСТам, проектной документации
AI-экспертный комментарий
Я использую 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%. — Павел Кияткин, AI-инженер
FAQ
RAG и fine-tuning — что выбрать?
RAG — если данные обновляются (документация, новости, тикеты). Fine-tuning — если нужно изменить стиль/тон модели или обучить на специфическом домене где RAG недостаточен. На практике: 80% корпоративных кейсов решается RAG, 15% — RAG + fine-tuning, 5% — только fine-tuning.
Какую векторную базу данных выбрать?
Для прототипа: ChromaDB (локальная, Python-native, 0 настройки). Для production: Qdrant (Rust, быстрый, self-hosted) или pgvector (если уже есть PostgreSQL). Для SaaS: Pinecone (managed, не нужно админить). Для enterprise: Weaviate (GraphQL API, multi-tenancy).
Сколько стоит RAG в production?
Основные расходы: (1) embedding при индексации — ~$0.02 на 1M токенов (OpenAI), (2) embedding при запросе — копейки, (3) LLM inference — $0.5-3 на 1000 запросов (GPT-4o). Для корпоративного бота с 1000 запросов/день: ~$50-150/мес на API. Self-hosted (Ollama + open-source LLM): только стоимость GPU-сервера.
Что такое галлюцинации и как RAG их решает?
Галлюцинация — когда LLM генерирует правдоподобный, но фактически неверный ответ. RAG снижает галлюцинации двумя способами: (1) модель отвечает на основе конкретных документов, а не памяти, (2) можно показать пользователю источники для верификации. RAG не устраняет галлюцинации на 100% — модель может неверно интерпретировать контекст. Но снижение — с 15-30% до 3-5% по исследованиям.
Связанные концепты
- Большие языковые модели (LLM) — базовая технология, которую RAG дополняет
- Embeddings — векторные представления текста, основа поиска в RAG
- Промпт-инженеринг — формирование запросов к LLM, включая контекст из RAG