RAG (Retrieval-Augmented Generation) — это архитектурный паттерн, в котором генеративная модель (обычно LLM) перед ответом извлекает релевантные факты из внешнего корпуса знаний и опирается на них при формировании финального текста. Идея проста: не заставлять модель «помнить» всё в своих весах и не стимулировать её «догадываться», а подставлять проверяемые источники из индекса документов. На практике это снижает «галлюцинации», улучшает объяснимость (цитирование), упрощает актуализацию знаний и помогает контролировать стоимость инференса.
RAG — это не продукт и не одна библиотека, а инженерный конвейер: данные → подготовка и индексация → извлечение (retrieval) → обогащение запроса → генерация → валидация и логирование. Он органично сочетается с векторными представлениями и поиском по эмбеддингам (Эмбеддинги), а для выбора движка хранения и поиска полезен обзор во векторной базе данных. В продакшн-окружении RAG часто становится «скелетом» ассистентов и инструментом для корпоративных баз знаний.
Зачем нужен RAG (Retrieval-Augmented Generation) и что он решает
Классический вызов LLM без опоры на источники страдает от двух системных ограничений:
- Стареющие знания: модель «застывает» на дате обучения; любое изменение фактов требует дообучения или специальной подгрузки.
- Вероятностная природа: при нехватке контекста LLM «додумывает» детали, создавая риск неточностей.
RAG решает оба пункта:
- Актуальность: документы обновляются в индексе без переподготовки модели.
- Проверяемость: ответ можно сопроводить цитатами и ссылками на источники, повышая доверие и управляемость.
В типичных сценариях RAG обеспечивает рост «faithfulness» (верности источникам), снижает долю «безцитатных» ответов и уменьшает стоимость (меньше необходимости в длинном контексте и «тяжёлых» моделях).
Архитектура RAG: полный путь от данных до ответа
RAG удобно представить как цепочку модулей. Ниже — подробный разбор и ключевые инженерные решения для каждого шага.
Подготовка данных и индексация
- Сбор и дедупликация. Источники: корпоративные документы, базы знаний, вики, инструктажи, тикеты, лог-сводки, код. Удаляем дубликаты, пустые страницы, версии «черновик».
- Нормализация. Преобразуем форматы к «строгому» тексту (PDF→текст, HTML→чистый контент), сохраняем структурные маркеры: заголовки, списки, табличные ячейки.
- Разбиение на фрагменты (chunking). Вопрос баланса: слишком мелкие чанки теряют контекст, слишком крупные — мешают точному матчинг-поиску и удешевлению. Популярные стратегии:
- фиксированная длина (например, 500–1200 токенов) с перекрытием 10–20%;
- структурное (по заголовкам/секции/параграфам);
- семантическое разбиение (порог похожести/тематические границы).
- Эмбеддинги. Для каждого чанка считаем векторное представление. Ключ: консистентная модель эмбеддингов для индексирования и запроса (см. Эмбеддинги).
- Индекс в векторной БД. Храним (vector, id, метаданные). Метаданные минимальны и функциональны: источник/версия/дата/автор/язык/тэги/раздел. Важна поддержка фильтров по метаданным и шардингу (см. Векторная база данных).
Извлечение (retrieval)
- Формирование запроса. Из пользовательского запроса строим вектор (можно применить переформулировку/расширение: query expansion).
- Поиск. Базовая стратегия — ANN-поиск (approximate nearest neighbors) в векторном индексе по косинусной близости/дот-продукту. В производстве почти всегда выигрывает гибрид: BM25/keyword + векторный поиск → слияние (fusion) по рангу/скорингу.
- Переранжирование (rerank). Кандидаты (например, top-50) прогоняются через компактную модель переранжирования либо через LLM-судью на выдержках. Это поднимает точность top-k, но увеличивает задержку.
- Фильтры. Ограничиваем домен, язык, свежесть (time-decay), доступность по ролям. Для многодоменных корпусов это критично.
Обогащение контекста и подготовка подсказки
- Сжатие фрагментов. Длинные куски режем/резюмируем до фактов, релевантных вопросу, чтобы экономить контекст.
- Агрегация top-k (напр., 3–8 фрагментов). Порядок — по релевантности и разнообразию.
- Формат подсказки. Инструкции модели: стиль ответа, формат, список выдержек с идентификаторами источников, требования «не выдумывать за пределами источников».
Генерация (generation)
- Стратегии декодирования. Greedy/beam давят разнообразие, но повышают устойчивость к вымыслам; top-p/top-k добавляют вариативность, однако требуют строже заданных рамок.
- Контроль формата. Для извлечения структурированных полей используем схемы (JSON/таблица) и валидаторы. Для объяснений — цитаты с id-ссылками на фрагменты.
Пост-валидация и логирование
- Проверка «faithfulness»: содержатся ли факты ответа в цитируемых фрагментах; не появились ли «новые» факты.
- Политики: фильтры токсичности и запретных тем, ограничение длины и тона.
- Логи: запрос, версия эмбеддингов, индекс, кандидаты, выбранные top-k, параметры декодирования, итоговый ответ, цитаты и стоимость.
В производстве RAG живёт рядом со стеком инференса (см. Стек инференса LLM) и часто становится частью общего AI-стека (см. AI-стек) для ассистентов и внутренних сервисов.
Где RAG сильнее fine-tuning, а где нет
| Сценарий | RAG лучше | Fine-tuning лучше | Комментарий |
| Часто меняющиеся факты | Да | Нет | Проще обновить индекс, чем переобучать модель |
| Корпоративные документы | Да | Иногда | RAG даёт цитаты и контроль доступа |
| Строгая стилистика/политика | Иногда | Да | Дообучение/инструкционное дообучение выравнивает стиль |
| Тесная терминология | Да (если есть корпус) | Иногда | RAG + глоссарий снижают «перевирания» терминов |
| Компрессия знаний «в весах» | Нет | Да | Когда офлайн-инференс без доступа к индексу |
Часто выбирают гибрид: лёгкий тюнинг под формат и политику + RAG для фактов.
Практические решения: chunking, top-k, rerank
| Компонент | Варианты/диапазоны | Что даёт | Риски |
| Chunking | 500–1200 токенов, перекрытие 10–20%; структурное/семантическое | Баланс точности и контекста | Слишком мелко — «шум», слишком крупно — размывание |
| top-k | 3–8 | Высокий recall релевантных фактов | Завал модели лишним контентом |
| Rerank | Компактная модель/LLM-судья | Повышает точность top-k | Цена и P95 задержка |
| Гибридный поиск | BM25 + векторный, score fusion | «Живучесть» к формулировкам | Требует настройки весов |
| Фильтры | По языку/времени/разделу/ролям | Меньше «мусора» в контексте | Риск отсечь полезное |
Совет: начинайте с простого (фиксированный chunk size, k=5, гибрид BM25+вектор) и постепенно добавляйте rerank и сжатие по данным экспериментов.
Метрики: как мерить качество RAG
| Класс | Метрики | Что показывает |
| Извлечение | Recall@k, Precision@k, NDCG@k, MRR | Способность находить нужные фрагменты |
| Верность источникам | Faithfulness / Attribution rate, Citation@k | Долю ответов, опирающихся на цитаты |
| Качество ответа | Human eval, полезность/корректность | Полезность в реальных задачах |
| Стоимость/производительность | Цена/1k токенов, P50/P95, cache hit | Экономику и SLA |
| Дифф-метрики | Срезы по доменам/языкам/датам | Где падает качество и почему |
Важно разводить офлайн-метрики (на эталонных наборах) и онлайн-качество (A/B на реальном трафике). Без A/B легко «переобучить» систему под тесты.
Стоимость и производительность: где прячутся токены
- Сжатие контекста. Резюмирование фрагментов до bullet-фактов сокращает токены без больших потерь качества.
- Кэширование. KV-кэш и кэш поисковых результатов для повторяющихся вопросов/паттернов запросов.
- Квантование и маршрутизация. Дорогое место — генерация: используйте компактные модели, а тяжёлую LLM включайте только при необходимости (см. Квантование).
- Лимиты. Обрезайте «длинные хвосты»: максимальный k, длина цитаты, длина ответа.
- Асинхронность вторичных шагов. Сложные операции (добавочные проверки) выносите из критического пути.
Варианты RAG: от «классики» к многошаговым цепочкам
- Классический RAG: один запрос → top-k документов → ответ. Подходит для FAQ и «локальных» вопросов.
- Многошаговый RAG: последовательность уточнений и дополнительных извлечений («расследование»). Полезен, когда первый top-k слишком общ.
- Ре-источники (re-sources): если источники противоречат друг другу, модель запрашивает дополнительные фрагменты и строит сравнительную таблицу.
- Цитатно-центричный RAG: приоритизируем выдержки, которые легко цитировать (прямые формулировки, таблицы, нормы).
- Доменные профили: отдельные индексы/веса для разных направлений (право/техника/поддержка).
Безопасность и управление рисками
- Политика источников. Индексируйте только санкционированные корпуса; исключайте «серые» источники и приватные данные без нужных прав.
- Prompt-injection. Не допускайте выполнения инструкций из документов-источников (чёткая граница между данными и командами).
- Фильтры содержания. Токсичность/PII-детекторы на документ-потоке до индекса и на финальном ответе.
- Цитирование. Каждому важному утверждению — id источника. Это дисциплинирует генерацию и упрощает аудит.
- Логи. Храните «карту решения»: какие документы и почему вошли в контекст.
Чек-лист внедрения RAG в продукт
- Определите узкие сценарии (FAQ, поиск норм, извлечение полей, справка по коду).
- Соберите санкционированный корпус: источники, лицензии, владельцы, SLA обновлений.
- Настройте pipeline подготовки: очистка, chunking, эмбеддинги, индекс.
- Запустите базовый retrieval: гибрид BM25+вектор, k=5, без rerank.
- Подключите генерацию с инструкциями и форматом цитирования.
- Введите валидацию: проверка фактов/схемы, фильтры и политики.
- Отстройте метрики и A/B: Recall@k, faithfulness, цена/1000 токенов, P95.
- Точечно добавляйте rerank и сжатие там, где это реально улучшает эффективность.
- Организуйте обновления индекса и контроль дрейфа корпуса (novelty/устаревание).
- Документируйте инциденты и процедуры отката; настройте наблюдаемость.
Таблица: стратегии извлечения и когда их применять
| Стратегия | Суть | Когда использовать | Плюсы | Минусы |
| Только векторный | ANN по эмбеддингам | Семантические запросы, синонимы | Хорош для перефразировок | «Промахи» по редким терминам |
| Только BM25 | Ключевые слова/фразы | Формальные названия/термины | Быстро и дёшево | Игнорирует семантику |
| Гибрид (fusion) | Слияние BM25 и ANN | Большинство задач | Стабильно к формулировкам | Нужна настройка весов |
| Rerank-модель | Дореранжирование top-N | Трудные/многословные документы | Улучшает точность top-k | Цена, задержка |
| Time-aware | Временные фильтры/веса | Новости, нормы, версии | Учитывает «свежесть» | Сложность метаданных |
Типовые анти-паттерны RAG
- Слишком «жирные» чанки: модель «тонет» в лишнем контенте, а поиск теряет точность.
- Одинаковая модель эмбеддингов для всего: мультиязычие/код/таблицы требуют выбора подходящих репрезентаций.
- Отсутствие гибридного поиска: векторный без BM25 «падает» на редких терминах.
- Нет переранжирования: топ выдачи содержит «почти релевантные» фрагменты.
- Нет цитирования: сложно проверять ответы и объяснять решения.
- Индекс без владения: непонятно, кто обновляет/чистит корпус и по какому SLA.
- Неучёт стоимости: k=20, длинные выдержки и «тяжёлые» LLM — и бюджет «горит».
Роль RAG в агентах и производственных системах
RAG — «пища» для агентов: он уменьшает риск «самоуверенных» ошибок и позволяет планировщику работать с фактами, а не с предположениями. В типичном агентном цикле (perception → plan → act → validate) retrieval повторяется несколько раз, а выводы снабжаются цитатами. Для устойчивости многошаговых сценариев полезно фиксировать граничные условия: лимиты на k, длину контекста и список разрешённых источников. См. также AI-агент.
FAQ
RAG — это библиотека или паттерн? Паттерн. Он описывает, как связать поиск и генерацию. Инструменты/библиотеки реализуют отдельные куски цепочки.
Обязательно ли использовать векторные базы? Для семантического поиска — практически да. Но в реальных системах лучше гибрид с ключевыми словами: так вы устойчивее к формулировкам запроса.
Нужен ли rerank? Если документы длинные и похожие — почти всегда да: rerank повышает долю действительно релевантных top-k и стабилизирует качество.
Как выбрать размер чанка? Стартуйте с 500–800 токенов и 10–20% перекрытия. Затем по A/B и Recall@k регулируйте под корпус и задачи.
Можно ли обойтись без цитирования? Технически — да, но для корпоративных сценариев цитаты резко повышают доверие и обнаруживаемость ошибок.
Что делать с таблицами и кодом? Извлекать структурно (ячейки, ключ-значение), хранить метаданные; для кода — учитывать «паддинги» и синтаксис при разбиении.
Когда лучше fine-tuning вместо RAG? Когда факты мало меняются, а критичен стилистический/поведенческий профиль ответов. Часто уместен компромисс: лёгкий тюнинг + RAG.
Словарь терминов
- RAG (Retrieval-Augmented Generation) — генерация с подстановкой фактов из внешнего индекса перед ответом.
- Chunking — стратегия разбиения документов на фрагменты для индексации/поиска.
- Эмбеддинг — плотное векторное представление текста/кода/таблиц для семантического поиска.
- Векторная база данных — хранилище/индекс эмбеддингов с быстрым ANN-поиском и фильтрами.
- Гибридный поиск — объединение keyword-методов (BM25) и векторного поиска.
- Rerank — доранжирование кандидатов более мощной моделью.
- Faithfulness — степень соответствия ответа извлечённым фрагментам.
- Citation@k — доля ответов, в которых присутствуют цитаты на источники из top-k.
- Top-k — число фрагментов, отобранных для генерации ответа.
- Query expansion — переформулировка/расширение запроса для лучшего извлечения.