RAG (Retrieval-Augmented Generation): архитектура, стек и применение

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

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

Что такое RAG

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

Термин и базовая концепция описаны в статье «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks», опубликованной исследователями Meta AI в 2020 году. После релиза ChatGPT в конце 2022 года RAG стал одним из наиболее популярных паттернов корпоративных AI-приложений.

На простом языке: RAG превращает LLM из «эксперта, который помнит, что читал когда-то» в «эксперта с открытой книгой» — модель в момент ответа имеет доступ к актуальным, проверенным, релевантным источникам.

Зачем нужен RAG

LLM «из коробки» имеют четыре серьёзных ограничения, каждое из которых RAG помогает решить.

Устаревшие знания

У модели есть cutoff date — момент, после которого её знания не обновлялись. Спросить у LLM «что нового в нашей индустрии за последний месяц» — получить либо устаревший ответ, либо «не знаю». RAG позволяет давать модели актуальную информацию в момент запроса.

Отсутствие специфики

Модель не знает деталей конкретной компании: её продуктов, цен, процессов, политик. RAG решает это: модель отвечает на основе документации, базы знаний, FAQ конкретной организации.

Галлюцинации

LLM иногда выдают уверенно звучащую, но неверную информацию. Прикреплённые документы в контексте снижают этот риск: модель отвечает на основе фактов, а не «вспоминает что-то похожее».

Невозможность переобучения

Fine-tuning модели на специфические данные стоит десятки тысяч долларов, требует ML-команды и занимает дни-недели. RAG даёт сравнимый по качеству результат за часы настройки и без переобучения.

Архитектура: query → retrieval → augment → generation

Базовый поток обработки запроса в RAG-системе.

1. Query. Пользователь задаёт вопрос: «Какова политика возврата товара в нашей компании?»
2. Retrieval. Система ищет в базе знаний документы, релевантные вопросу. Возвращаются топ-3–10 наиболее похожих фрагментов.
3. Augment. Найденные фрагменты вставляются в промпт к LLM как контекст: «Ответь на вопрос, используя следующую информацию: [фрагменты документов]. Вопрос: …»
4. Generation. LLM генерирует ответ на основе предоставленного контекста и общих знаний языка.

Каждый этап — отдельная техническая задача со своими сложностями. Качество финального ответа определяется качеством каждого из четырёх шагов: плохой поиск даст плохой контекст, и даже самая мощная LLM не сможет компенсировать это.

Компоненты RAG-системы

Embedding model

Модель, которая превращает текст в векторное представление (embedding) — массив чисел фиксированной длины, отражающий семантическое содержание текста. Близкие по смыслу тексты имеют близкие embedding’и.

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

Vector database (векторная база данных)

Специализированное хранилище, оптимизированное для быстрого поиска ближайших векторов в многомерном пространстве. Классические реляционные БД не подходят: они не умеют эффективно делать nearest neighbor search в пространстве из 768–3072 измерений.

Document loader и chunker

Перед загрузкой в базу документы разбиваются на фрагменты (chunks) — обычно по 200–1000 токенов. Каждый chunk превращается в embedding и сохраняется в векторную базу с метаданными (источник, дата, тип документа).

Качество чанкинга критично: слишком мелкие chunks теряют контекст, слишком крупные — превышают полезный размер для embedding’а. Стандартный размер — 500 токенов с overlap 50–100 токенов для сохранения связности между фрагментами.

LLM (Large Language Model)

Генеративная модель, которая создаёт финальный ответ на основе предоставленного контекста. Может быть API-моделью (GPT, Claude, Gemini) или self-hosted (Llama, Mistral, Qwen).

Orchestrator / framework

Программный слой, координирующий все компоненты: получает запрос пользователя, обращается к embedding-модели, делает поиск в векторной базе, формирует промпт, вызывает LLM, возвращает ответ. Популярные фреймворки: LangChain, LlamaIndex, Haystack.

Виды RAG: от naive до agentic

Naive RAG

Базовая реализация по шагам выше. Один поиск, один прогон через LLM, один ответ. Работает в простых случаях с понятными вопросами и качественными документами.

Слабости: не умеет работать с многоступенчатыми вопросами, плохо обрабатывает запросы, требующие синтеза информации из разных источников, чувствителен к качеству формулировки вопроса.

Advanced RAG

Добавление улучшений к базовой схеме:

• Query rewriting. LLM перефразирует запрос пользователя в более удачную формулировку для поиска.
• Multi-query retrieval. Один запрос превращается в несколько разных формулировок, и поиск делается по каждой.
• Reranking. Найденные фрагменты переоцениваются специализированной reranker-моделью для отбора наиболее релевантных.
• Hybrid search. Семантический поиск (по embedding’ам) сочетается с традиционным поиском по ключевым словам (BM25).
• Citation generation. Модель явно указывает, из какого источника взята каждая часть ответа.

Modular RAG

Архитектура с настраиваемыми модулями. В отличие от advanced RAG с фиксированным pipeline, modular RAG позволяет динамически выбирать стратегию обработки в зависимости от типа запроса. Сложные вопросы проходят через rerank и multi-query, простые — через короткий путь.

Agentic RAG

Самый продвинутый паттерн. LLM сама решает, какие действия нужно выполнить для ответа на вопрос: возможно, нужно несколько поисков, использование инструментов (calculator, API внешних сервисов), уточняющие вопросы пользователю.

Пример. Запрос «Сравни наши финансовые результаты с конкурентом X за последний квартал». Agentic RAG разбирает запрос: нужно найти отчёт компании в внутренней базе, найти публичный отчёт конкурента, выполнить сравнение, сформировать вывод. Каждый шаг — отдельный «инструмент».

Этапы построения RAG-системы

1. Определение задачи. Какие именно вопросы должна закрывать система. Конкретный список use cases важнее «универсальной системы».
2. Подготовка данных. Сбор и очистка документов: PDF, веб-страницы, базы знаний, тикеты поддержки.
3. Chunking. Разбиение документов на фрагменты подходящего размера.
4. Выбор embedding-модели. Универсальная (OpenAI, Cohere) или специализированная под язык/домен.
5. Выбор векторной базы. Pinecone, Qdrant, Weaviate, ChromaDB — варианты по размеру данных и требованиям.
6. Создание векторных индексов. Embedding’и всех фрагментов сохраняются в базу.
7. Выбор LLM. Frontier-модель через API или self-hosted open-source.
8. Сборка pipeline. LangChain, LlamaIndex или собственная реализация.
9. Промпт-инжиниринг. Шаблоны промптов для разных типов запросов.
10. Тестирование. На реальных вопросах с известными правильными ответами.
11. Развёртывание. В продакшен с мониторингом качества.
12. Постоянная оптимизация. Анализ неуспешных запросов, обновление данных, улучшение промптов.

Технологический стек 2026

Для прототипа стандартный стек — LangChain или LlamaIndex + ChromaDB (локальная векторная база) + OpenAI или Claude через API. Для продакшена в малом масштабе — Qdrant + GPT-4o-mini или Claude Haiku. Для крупного продакшена — Pinecone/Weaviate + frontier-модели + reranker.

Векторные базы данных: ключевые игроки

Выбор зависит от масштаба, существующего стека, требований к latency, наличия SaaS vs self-hosted-предпочтения. Для небольших проектов — pgvector или ChromaDB. Для серьёзного продакшена — Pinecone или Qdrant.

Embedding-модели

Для русскоязычных проектов критична поддержка русского языка. Multilingual-модели (multilingual-e5, BGE-M3, OpenAI text-embedding-3) работают существенно лучше англоязычных на нелатинских языках. Для специализированных доменов (медицина, юриспруденция) имеет смысл fine-tuning embedding-модели на доменных данных.

Применения RAG

Внутренняя документация

Корпоративная база знаний с RAG-чатом: сотрудники задают вопросы и получают ответы на основе внутренних регламентов, инструкций, FAQ. Особенно полезно для крупных компаний с тысячами страниц документации.

Поддержка клиентов

RAG-бот первой линии поддержки отвечает на типовые вопросы из базы знаний продукта. Снижает нагрузку на операторов, повышает скорость ответа в нерабочее время.

Медицинские помощники

Системы, которые отвечают врачам на вопросы на основе медицинских guideline’ов, клинических протоколов, последних публикаций. Используются в качестве вспомогательного инструмента, не заменяющего врача.

Юридические ассистенты

RAG-системы для работы с законодательством, судебной практикой, корпоративными документами. Помогают юристам быстро находить релевантные нормы и прецеденты.

Технические ассистенты

RAG над технической документацией продукта: ответы разработчиков на вопросы по API, библиотекам, конфигурациям. GitHub Copilot, Cursor, документация Anthropic, Stripe — примеры публичных систем с элементами RAG.

E-commerce поиск

Семантический поиск товаров: «недорогой ноутбук для студента» возвращает релевантные модели даже без точного совпадения ключевых слов.

Финансовый анализ

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

Метрики качества RAG

Оценка RAG-системы — отдельная сложная задача. Стандартные метрики:

• Retrieval precision. Доля найденных документов, реально релевантных вопросу.
• Retrieval recall. Доля всех релевантных документов, которые были найдены.
• Faithfulness. Соответствует ли ответ предоставленному контексту (не добавлены ли галлюцинации).
• Answer relevance. Отвечает ли финальный ответ на вопрос пользователя.
• Context precision. Доля релевантной информации в предоставленном LLM контексте.
• Latency. Время от запроса до ответа.
• Cost per query. Стоимость одного запроса (embedding + LLM tokens).

Инструменты для автоматизированной оценки: Ragas (Python-библиотека), TruLens, LangSmith (от LangChain), Phoenix (Arize AI).

Типичные ошибки

• Плохой чанкинг. Слишком крупные или мелкие фрагменты. Разрыв документа в середине логического блока.
• Игнорирование метаданных. Привязывать фрагменты к источнику, дате, типу документа — это помогает фильтрации и атрибуции.
• Универсальная embedding-модель для специфического домена. На медицинских или юридических текстах общие модели работают хуже специализированных.
• Отсутствие reranking. Первый этап поиска — грубый. Reranker значительно повышает качество найденных фрагментов.
• Слепое доверие LLM. Даже с хорошим RAG модель может галлюцинировать. Нужны проверки, citation-механизмы.
• Игнорирование hybrid search. Чистый семантический поиск пропускает запросы с точными терминами, артикулами, кодами. BM25 + векторный поиск работают лучше.
• Отсутствие feedback loop. Без отслеживания неуспешных запросов система не улучшается. Логирование «не помогло» — обязательный механизм.
• Перегрузка контекста. Засунуть 50 фрагментов в контекст и ждать хорошего ответа — антипаттерн. LLM теряется в большом контексте. Оптимум — 3–7 наиболее релевантных фрагментов.
• Устаревшие данные. Векторная база не обновляется автоматически при изменении исходных документов. Нужны процессы синхронизации.
• Отсутствие eval’ов. RAG-систему оптимизировать невозможно без бенчмарка из вопросов и эталонных ответов. Без него любые «улучшения» — гадание.
• Игнорирование стоимости. Embedding каждого запроса + retrieval + большой LLM-контекст может стоить $0.05–0.20 за вопрос. На больших объёмах это серьёзные расходы.
• Privacy без должной защиты. Передача корпоративных данных в облачную LLM без enterprise-плана или self-hosted решения — риск утечки.

Часто задаваемые вопросы

Когда RAG лучше, чем fine-tuning?

Почти всегда, когда нужно работать с фактической информацией. RAG позволяет обновлять данные без переобучения, даёт прозрачную атрибуцию источников, дешевле во внедрении. Fine-tuning имеет смысл для изменения стиля ответов, специфических форматов вывода, доменных навыков, не сводящихся к фактам.

Можно ли построить RAG-систему без программирования?

Существуют no-code платформы (Voiceflow, Botpress, специализированные RAG-builder’ы), но они ограничены в гибкости. Серьёзный продакшен-проект требует кода, особенно для интеграций, обработки данных, тонкой настройки промптов.

Сколько стоит запуск RAG-системы?

MVP на open-source стеке (ChromaDB + Llama локально) — фактически бесплатно, не считая времени разработчика. Production со средней нагрузкой — $500–5000/мес: API LLM, hosted vector DB, инфраструктура. Enterprise с большим объёмом данных — десятки тысяч долларов в месяц.

Какой минимальный размер базы данных для RAG?

Технически — несколько документов. Практически — RAG имеет смысл, когда документов больше 50–100, и информация в них не может быть просто включена в промпт LLM. Меньше 50 — проще передать всё в контекст.

Что делать, если RAG выдаёт неверные ответы?

Систематическая отладка: проверить, находит ли retrieval нужные документы; если да — улучшать промпт; если нет — улучшать чанкинг, embedding-модель, использовать reranker. Логи неуспешных запросов — главный инструмент для оптимизации.

RAG заменяет поисковую систему?

Не заменяет, а дополняет. Поисковая система возвращает ссылки на документы; RAG возвращает готовый ответ с цитатами из документов. Для разных сценариев — разные инструменты. В корпоративной среде часто работают параллельно.

Заключение

RAG — практический стандарт работы LLM с корпоративными данными в 2026 году. Запустить базовую систему можно за дни, отполировать до production-качества — недели или месяцы. Главное препятствие — не технологическая сложность (стек зрелый, открытый, документированный), а дисциплина в подготовке данных и оценке качества. Команды, которые относятся к RAG как к проектируемой системе с метриками и итерациями, получают работающий инструмент. Команды, которые «слепили из туториала и поставили в продакшен», получают источник красиво звучащих галлюцинаций.