Архитектура RAG

Что такое RAG и зачем он нужен

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

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

По сравнению с альтернативами — дообучением (fine-tuning) и расширением контекстного окна — RAG обеспечивает три ключевых преимущества. Во-первых, актуальность: документы в хранилище обновляются в реальном времени, а модель переобучать не нужно. Во-вторых, прослеживаемость: каждый ответ можно привязать к конкретным источникам, что критически важно для enterprise и regulated industries. В-третьих, масштабируемость: корпус документов может содержать миллионы страниц — никакое контекстное окно не вместит их все, а RAG выбирает только нужные фрагменты.

RAG-пайплайн: архитектурная схема

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

Этапы RAG-пайплайна: подробный разбор

1. Подготовка данных

Качество RAG-системы принципиально определяется качеством исходных данных. Первый этап — загрузка документов из всех корпоративных источников: файловых хранилищ (PDF, DOCX, PPTX, XLSX), систем управления контентом (Confluence, SharePoint, Notion), баз знаний, CRM и ERP-систем, корпоративных порталов. Далее следует парсинг — извлечение текстового содержимого, таблиц, заголовков и метаданных. Для PDF и сканированных документов применяется OCR. На финальном шаге выполняется очистка: удаление артефактов форматирования, нормализация кодировок, дедупликация повторяющихся фрагментов.

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

2. Чанкинг — разбиение на фрагменты

LLM не может обработать документ целиком, если он длиннее контекстного окна. Кроме того, поиск по большим блокам текста менее точен: чем меньше и смысловее фрагмент, тем лучше работает векторный поиск. Существует несколько стратегий чанкинга:

• Fixed-size chunking — нарезка по фиксированному числу токенов (обычно 500–1000). Простейший метод, работает хорошо для однородных текстов. Недостаток — может разрывать предложения и абзацы на смысловой середине.
• Semantic chunking — разбиение по смысловым границам с использованием self-similarity: два последовательных предложения объединяются в один чанк, пока их эмбеддинги похожи; при резком смысловом переходе — новый чанк. Даёт лучшее качество, но требует дополнительных вычислений.
• Recursive splitting — иерархическое разбиение: сначала по параграфам, затем по предложениям, затем по словам. Применяется в LangChain RecursiveCharacterTextSplitter и является хорошим универсальным вариантом.
• Структурированный чанкинг — для markdown и HTML используются заголовки разного уровня как естественные границы. Для таблиц — каждая строка или группа строк превращается в отдельный чанк с контекстуальным заголовком.

Критически важный параметр — overlap (перекрытие): 10–20% токенов из конца предыдущего чанка дублируется в начале следующего. Это сохраняет контекст на границах и предотвращает потерю информации, которая оказалась «разрезана» на стыке фрагментов.

3. Embedding — векторизация

Embedding-модель преобразует текстовые фрагменты в числовые векторы (embeddings). Семантически похожие тексты оказываются близко друг к другу в многомерном пространстве — именно это свойство используется для поиска.

Выбор embedding-модели существенно влияет на качество всего пайплайна. Ключевые опции:

• OpenAI text-embedding-3-large — 3072 измерения, высокое качество, особенно для английского. Размерность можно снизить до 256 или 1536 без существенной потери качества.
• Cohere Embed v3 — поддерживает указание типа задачи (search_document vs search_query), улучшает точность поиска. Отличная поддержка многих языков.
• E5-large-v2 / multilingual-e5-large — open-source модели от Microsoft, хорошо работают для русского языка, можно развернуть локально.
• BGE-M3 — многоязычная модель от BAAI с поддержкой sparse, dense и multi-vector retrieval в одной модели. Эффективна для гибридного поиска.
• Русскоязычные модели — для сугубо корпоративных документов на русском языке рассматривайте rubert-base-cased-sentence или специализированные модели с дообучением на отраслевых текстах.

4. Индексация в векторную базу данных

Векторы сохраняются в специализированную базу данных, оптимизированную для поиска ближайших соседей (ANN — Approximate Nearest Neighbor). Ключевые решения:

• Qdrant — написан на Rust, высокая производительность, богатые возможности фильтрации по метаданным, развёртывание on-premise или облако. Популярный выбор для enterprise.
• Milvus — горизонтально масштабируемое решение с поддержкой распределённого деплоя. Подходит для очень больших корпусов (миллиарды векторов).
• Weaviate — гибридный поиск (semantic + keyword) из коробки, GraphQL API, встроенная поддержка модулей генерации.
• pgvector — расширение PostgreSQL. Если у вас уже есть PostgreSQL-инфраструктура, это минимальный путь к векторному поиску без дополнительных сервисов.
• ChromaDB — легковесная open-source БД, идеальна для прототипирования и небольших корпусов.

Помимо самого вектора в базе хранятся метаданные: источник документа, дата создания/обновления, категория, отдел, уровень доступа. Метаданные позволяют реализовать фильтрацию до или после поиска, ограничивая выборку документами, к которым у пользователя есть права.

Стратегия обновления индекса — ещё один архитектурный выбор. Инкрементальная индексация (добавление только изменившихся документов) сложнее в реализации, но значительно быстрее. Полная переиндексация проще, но не подходит для больших корпусов, где требуется актуальность в режиме реального времени.

5. Поиск (Retrieval)

При поступлении запроса он векторизуется той же embedding-моделью, что и документы. Затем в векторной БД выполняется поиск k-ближайших соседей. Но один семантический поиск — не всегда оптимально:

• Semantic search (dense retrieval) — поиск по семантической близости через cosine similarity или dot product. Хорошо находит смысловые аналоги, устойчив к синонимам и перефразированию.
• Keyword search (BM25, TF-IDF) — классический полнотекстовый поиск по точным совпадениям слов. Незаменим, когда запрос содержит специфические термины, коды продуктов, названия, аббревиатуры.
• Hybrid retrieval — комбинация dense и sparse сигналов. Оба метода возвращают ранжированные списки, которые объединяются через RRF (Reciprocal Rank Fusion) или весовое слияние. Hybrid — наилучший выбор для большинства production-систем.

6. Reranking — переранжирование

После первичного поиска (recall) полученные 20–50 кандидатов передаются в cross-encoder reranker для более точной оценки релевантности. Cross-encoder обрабатывает пару (запрос, документ) совместно, что дороже, чем bi-encoder поиск, но точнее. Типичные решения: Cohere Rerank API, BGE-Reranker, cross-encoder/ms-marco-MiniLM. Двухстадийная архитектура fast recall → precise rerank обеспечивает баланс между скоростью и точностью.

7. Генерация ответа

Финальные топ-5–10 фрагментов передаются в LLM как контекст. Качество prompt construction принципиально влияет на ответ. Типичная структура: системный промпт (роль, инструкции, формат), блок контекста (найденные фрагменты с указанием источника), запрос пользователя, инструкция отвечать только на основании предоставленного контекста. Source attribution — указание конкретных документов в ответе — обязательно для enterprise: пользователь должен понимать, откуда взята информация. Guardrails на выходе проверяют, что ответ действительно основан на контексте, а не на параметрической памяти модели.

Типы ретриверов: как выбрать правильный

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

Классификация RAG-систем: 6 типов

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

Разговорные системы оптимизируются под минимальную задержку: используется меньше чанков в контексте, lightweight модели для reranking, агрессивное кэширование. Экспертные системы — полная противоположность: здесь важна абсолютная точность, верификация через несколько источников, обязательные ссылки на первоисточники, иногда — человек в цикле (human-in-the-loop). Выбор типа системы определяет архитектурные решения на всех последующих уровнях.

Продвинутые паттерны RAG

Базовый RAG — мощная техника, но в enterprise-контексте он часто требует усиления. Рассмотрим наиболее зрелые и практически применимые паттерны.

Алгоритм выбора RAG-фреймворка

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

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

Как оценивать качество RAG-системы

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

• Faithfulness (достоверность) — насколько ответ основан на предоставленном контексте, а не на параметрической памяти модели. Оценивается NLI-моделями или специализированными evaluators.
• Answer Relevancy (релевантность ответа) — насколько ответ соответствует вопросу. Независимо от корректности фактов.
• Context Precision / Recall — precision: доля релевантных фрагментов среди извлечённых; recall: доля нужных фрагментов, которые были найдены вообще.
• Context Relevancy — насколько извлечённые фрагменты полезны для ответа на конкретный вопрос.
• End-to-end accuracy — процент вопросов, на которые система дала фактически верный ответ, по тестовому набору с ground truth.
• Latency P50/P95/P99 — время отклика системы под нагрузкой. Для разговорных систем P95 < 2 с — целевой ориентир.

Фреймворки для автоматической оценки: RAGAS (популярный выбор с метриками faithfulness, answer relevancy, context recall), DeepEval, TruLens. В BI Consult мы формируем тестовые наборы вопросов вместе с клиентом ещё на этапе проектирования — это позволяет объективно сравнивать варианты архитектуры до вывода в production.

Типичные ошибки при построении RAG

За годы работы с enterprise RAG-проектами мы выявили ряд ошибок, которые систематически снижают качество систем:

• Игнорирование качества данных. GIGO (Garbage In, Garbage Out) работает в RAG так же, как в любой data-системе. Сканированные PDF без OCR, документы с устаревшей информацией, дублированный контент — всё это напрямую снижает качество ответов. Инвестируйте в ETL-пайплайн.
• Фиксированный размер чанка без анализа корпуса. 512 токенов — популярное значение по умолчанию, но не оптимальное для большинства задач. Проводите ABтестирование с разными размерами и стратегиями.
• Одна embedding-модель на всё. Разные типы документов (технические спецификации, юридические тексты, FAQ) могут требовать разных моделей или даже fine-tuning embedding под домен.
• Отсутствие reranking. Первичный поиск по cosine similarity — хорошая начальная точка, но cross-encoder reranker стабильно улучшает качество в production на 10–20%.
• Забытые метаданные и фильтрация доступа. В enterprise RAG права доступа критичны. Пользователь не должен получать документы, к которым у него нет прав — даже через LLM-ответ.
• Отсутствие мониторинга в production. Распределение запросов меняется, корпус обновляется, модели обновляются провайдерами. Без трекинга метрик деградация происходит незаметно.

Что делает BI Consult в области RAG

BI Consult специализируется на проектировании и внедрении production-ready RAG-систем для корпоративного сектора. Мы не продаём шаблонные решения — каждый проект начинается с анализа данных, бизнес-задачи и существующей инфраструктуры.

• Аудит существующих RAG-решений. Анализируем текущую архитектуру, выявляем узкие места по качеству (faithfulness, relevancy, recall) и производительности (latency, throughput). Даём конкретные рекомендации с измеримым эффектом.
• Проектирование RAG-архитектуры под бизнес-задачу. Выбираем оптимальную стратегию чанкинга, embedding-модели, тип ретривера, векторную базу данных и фреймворк с учётом ваших требований к качеству, задержке, безопасности и масштабированию.
• Разработка и внедрение RAG-пайплайнов. Полный цикл от ETL и индексации до API-интеграции с корпоративными системами. Включая обеспечение прав доступа, аудит запросов и источников в ответах.
• Оптимизация качества и производительности. Повышаем relevance через улучшение чанкинга, добавление hybrid retrieval и reranking. Снижаем latency через кэширование, оптимизацию индексов, балансировку нагрузки.
• Мониторинг качества в production. Настраиваем дашборды с ключевыми RAG-метриками, систему алертинга при деградации качества, регулярный аудит тестового набора. Обеспечиваем непрерывное соответствие KPI, согласованным на старте проекта.