# 4. Retrieval-Augmented Generation (RAG)

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

## Постановка задачи и мотивация

В традиционной генерации модель отвечает, опираясь на знания, полученные на этапе предварительного обучения. Обновление фактов или доменных регламентов требует переобучения модели, что дорого и сложно. Кроме того, модель может «галлюцинировать» — генерировать ответы, не опираясь на реальные источники.

RAG вводит явный контур поиска по внешнему хранилищу знаний:

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

Архитектурно это приводит к разделению системы на контур подготовки и индексации знаний и контур онлайн-запросов.

## Базовая архитектура RAG-системы

Типичная RAG-система включает несколько ключевых подсистем.

1. **Источники знаний**. Файлы, базы данных, системы документооборота, вики, спецификации, логи. На этом слое решаются задачи подключения источников, инкрементальной загрузки и контроля доступа.
2. **Пайплайн подготовки корпуса**. Сырые документы нормализуются, очищаются, разбиваются на фрагменты (chunking), обогащаются метаданными (тип документа, актуальность, права доступа).
3. **Хранилище индексов**. Для подготовленных фрагментов строятся индексы: семантический (например, по векторным представлениям текстов) и, при необходимости, классический полнотекстовый. В индексе хранятся ссылки на исходные документы и метаданные.
4. **Контур запроса**. Пользовательский запрос преобразуется в форму, пригодную для поиска, запускается процедура retrieval, из найденных фрагментов формируется контекст, который подаётся в генеративную модель.
5. **Контур генерации и постобработки**. Модель формирует ответ, учитывая предоставленные фрагменты. Поверх этого выполняются фильтрация, переформатирование, добавление ссылок на источники.

Все эти подсистемы могут развёртываться и масштабироваться независимо, что важно при эксплуатации.

## Пайплайн индексации знаний

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

Основные шаги:

1. **Загрузка и нормализация**. Документы приводятся к единому внутреннему формату текста и метаданных. На этом шаге выполняется базовое извлечение структуры (заголовки, разделы, списки).
2. **Разбиение на фрагменты**. Длинные тексты делятся на логически или технически удобные фрагменты. Размер фрагментов подбирается так, чтобы с одной стороны помещаться в ограничение по контексту генеративной модели, с другой — сохранять достаточную связанность смысла.
3. **Построение представлений**. Для каждого фрагмента вычисляется представление, пригодное для быстрого поиска по смыслу. Параллельно могут строиться дополнительные индексы (например, по ключевым словам или структуре документа).
4. **Запись в индекс**. Фрагменты с представлениями и метаданными сохраняются в специализированное хранилище, поддерживающее эффективный поиск.

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

## Пайплайн обработки запроса

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

1. **Приём и нормализация запроса**. Запрос приводится к канонической форме, связывается с пользователем и его правами доступа, при необходимости дополняется контекстом (предыдущие реплики диалога, параметры сессии).
2. **Поиск релевантных фрагментов**. На основе запроса вычисляется внутреннее представление (например, вектор), по которому выполняется поиск ближайших фрагментов в индексе. Могут использоваться дополнительные фильтры по метаданным.
3. **Формирование контекста**. Из найденных фрагментов формируется контекст для модели: выбираются наиболее информативные, упорядочиваются, возможно, агрегируются или аннотируются.
4. **Генерация ответа**. Модель получает на вход инструкцию (что нужно сделать) и контекст (подобранные фрагменты) и формирует черновой ответ.
5. **Постобработка и обогащение**. К черновому ответу добавляются ссылки на источники, проводится проверка формата, при необходимости накладываются дополнительные правила.

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

## Архитектурные принципы RAG-систем

Архитектура RAG-систем должна учитывать несколько специфических принципов.

- **Разделение offline и online контуров**. Индексация и подготовка корпуса — тяжёлые операции, которые не должны влиять на латентность ответов. Они выполняются в отдельных пайплайнах с собственными SLA. Онлайн-контур запроса работает только с уже готовым индексом.
- **Явное управление релевантностью**. В отличие от «чёрного ящика» генеративной модели, в RAG есть возможность тонко управлять стратегией поиска и отбора фрагментов. Это следует выделять в отдельный слой с настраиваемыми политиками.
- **Соблюдение прав доступа**. Поскольку RAG опирается на внешние документы, важно гарантировать, что пользователь не увидит фрагменты, к которым у него нет прав доступа. Это требование должно быть реализовано как на уровне источников, так и на уровне индекса и контуров запроса.
- **Наблюдаемость поиска и генерации**. Для анализа качества необходимо логировать, какие фрагменты были подобраны для запроса, как они влияли на ответ, какие ошибки возникали. Это помогает улучшать как поиск, так и промптинг модели.

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