RAG

Материал из MachineLearning.

Версия от 12:50, 26 июля 2026; Iaroslav Lyakhov (Обсуждение | вклад)
(разн.) ← Предыдущая | Текущая версия (разн.) | Следующая → (разн.)
Перейти к: навигация, поиск
Статья написана с использованием LLM Claude Opus 4.8 и проверена участником Iaroslav Lyakhov 16:50, 26 июля 2026 (MSD)


Содержание

RAG (англ. retrieval-augmented generation - генерация с дополнением извлечёнными знаниями) - архитектурный подход, при котором языковая модель перед формированием ответа извлекает релевантные документы из внешнего хранилища и использует их как контекст. RAG соединяет параметрическую память модели (знания, «зашитые» в её веса) с непараметрической (внешняя база, которую можно менять в любой момент). Такой подход повышает фактическую точность ответов, позволяет ссылаться на источники и заметно снижает галлюцинации. Термин введён в работе Facebook AI Research (Lewis et al., 2020).

Зачем нужен

Знания обычной LLM «заморожены» на момент обучения: их трудно обновлять, а проследить, откуда взялось конкретное утверждение, невозможно. RAG решает сразу несколько проблем:

  • Актуальность. Внешнюю базу можно обновлять без переобучения модели.
  • Достоверность. Ответ опирается на конкретные документы, которые можно процитировать и проверить.
  • Приватность и специализация. К модели подключают закрытые корпоративные или узкопредметные данные, не вливая их в обучающую выборку.
  • Экономичность. Не нужно дорогостоящее дообучение под каждую новую коллекцию знаний.

Как устроен

Типичный конвейер RAG состоит из двух фаз.

Индексация (офлайн)

  1. Документы нарезаются на фрагменты (chunking).
  2. Каждый фрагмент кодируется в векторное представление моделью-эмбеддером.
  3. Векторы складываются в векторную базу данных (FAISS, Milvus, Qdrant и др.), где по ним можно быстро искать ближайших соседей.

Извлечение и генерация (онлайн)

  1. Запрос пользователя кодируется в вектор тем же эмбеддером.
  2. По близости (обычно косинусной) находятся k наиболее релевантных фрагментов - это семантический поиск: ищут по смыслу, а не по точному совпадению слов.
  3. Найденные фрагменты добавляются в промпт вместе с вопросом.
  4. Модель генерирует ответ, опираясь на предоставленный контекст, и при необходимости приводит ссылки на источники.

Математическая постановка

Формально RAG вводит скрытую (латентную) переменную - извлечённый документ. Пусть x - запрос, y - ответ, а \mathcal{Z} - внешняя коллекция документов. Обычная модель задаёт распределение p_\theta(y\mid x) напрямую, а RAG маргинализует ответ по документам:

p(y\mid x) = \sum_{z \in \mathcal{Z}} p_\eta(z\mid x)\, p_\theta(y\mid z, x),

где p_\eta(z\mid x) - модель поиска (какой документ релевантен запросу), а p_\theta(y\mid z, x) - генератор, отвечающий по запросу и документу. Суммировать по всей коллекции нельзя (в ней бывают миллиарды записей), поэтому на практике берут только k самых релевантных документов \mathcal{R}_k(x):

p(y\mid x) \approx \sum_{z \in \mathcal{R}_k(x)} p_\eta(z\mid x)\, p_\theta(y\mid z, x).

Различают два режима. В RAG-Sequence один и тот же документ используется для всего ответа. В RAG-Token документ можно выбирать заново для каждого токена:

p(y\mid x) = \prod_{t} \sum_{z \in \mathcal{R}_k(x)} p_\eta(z\mid x)\, p_\theta(y_t\mid y_{<t}, z, x).

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

Ключевые компоненты

  • Ретривер (retriever) отвечает за поиск. Разреженный ретривер (например, BM25) ищет по совпадению ключевых слов; плотный (dense) - по близости эмбеддингов и находит смысловые совпадения даже при разных формулировках; на практике часто комбинируют оба (гибридный поиск). Плотный ретривер обычно устроен как два кодировщика (dual encoder): один переводит запрос в вектор \mathbf{q} = E_Q(x), другой - документ в вектор \mathbf{d} = E_D(z), а релевантность оценивают их скалярным произведением \mathrm{sim}(x, z) = \mathbf{q}^\top \mathbf{d}. Классический пример такого ретривера - DPR (Dense Passage Retrieval); для быстрого поиска по миллионам векторов используют библиотеки приближённого поиска ближайших соседей вроде FAISS или ScaNN.
  • Реранкер (re-ranker) переупорядочивает найденных кандидатов более точной, но дорогой моделью, чтобы наверх попали действительно релевантные фрагменты.
  • Генератор - собственно LLM, которая формирует итоговый ответ. Это может быть модель типа энкодер-декодер (T5, BART) или decoder-only (GPT, LLaMA).

Нарезка и качество поиска

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

Обучение

Компоненты RAG можно обучать по-разному.

  • Сквозное обучение (end-to-end): ретривер и генератор настраивают вместе. Выбор документа из коллекции недифференцируем, поэтому градиент проводят через маргинальное правдоподобие \log p(y\mid x), взвешивая вклад каждого документа его вероятностью p_\eta(z\mid x). Так обучались исходные RAG и REALM.
  • Замороженный ретривер (frozen retriever): берут готовый поисковый модуль (например, DPR или BM25) и дообучают только генератор на извлечённых документах. Это дешевле и проще масштабируется; так устроен Atlas, где индекс лишь периодически пересчитывают.
  • Многоэтапное обучение: сначала отдельно обучают ретривер на парах «запрос-документ», затем генератор на расширенных контекстах, и при необходимости слегка дообучают всё вместе.

При росте базы важно поддерживать актуальность индекса: по мере изменения энкодера документы асинхронно переиндексируют.

Проблемы

  • Ответ ограничен качеством поиска: пропущенный или нерелевантный фрагмент портит результат.
  • Чувствительность к способу нарезки и размеру фрагментов.
  • Ограничение длины контекста: в промпт помещается лишь несколько фрагментов.
  • Модель может проигнорировать переданный контекст и ответить «из памяти».
  • Задержка: поиск по большой коллекции добавляет заметное время ответа; спасают кэширование и приближённый поиск.
  • Конфликт знаний: сведения из внешних документов могут противоречить тому, что модель «помнит» из обучения, и ответы становятся непоследовательными.
  • Обслуживание индекса: базу нужно обновлять, чистить от дубликатов и держать свежей - это отдельная инженерная работа.

Развитие

Исходные RAG и REALM (2020) появились почти одновременно и задали направление. Дальше выросло целое семейство подходов:

  • RETRO (2022) встраивает поиск прямо в архитектуру трансформера через блоки chunked cross-attention и работает с базой в триллионы токенов.
  • FiD (Fusion-in-Decoder) обрабатывает каждый документ отдельно в энкодере, а объединяет их уже в декодере, что позволяет учесть десятки фрагментов сразу.
  • Atlas показал сильное обучение по немногим примерам за счёт поиска.
  • Self-RAG учит модель саму решать, когда обращаться к поиску, и критически оценивать найденное и собственный ответ с помощью специальных токенов-рефлексий.
  • REPLUG применяет RAG к закрытым (black-box) моделям, дообучая только лёгкий ретривер.

Из более прикладных направлений: agentic RAG (модель сама решает, что и когда искать, и делает несколько итераций поиска), GraphRAG (поиск по графу знаний, а не только по отдельным фрагментам), итеративное и многошаговое извлечение для сложных вопросов, а также мультимодальный RAG для изображений и видео.

RAG или дообучение

RAG и дообучение (fine-tuning) решают разные задачи: дообучение меняет поведение и стиль модели, а RAG снабжает её свежими фактами. На практике подходы дополняют друг друга: модель дообучают под формат и тон ответов, а актуальные знания подают через RAG.

См. также

Литература

Источник — «http://poligon.machinelearning.ru/wiki/index.php?title=RAG»
Личные инструменты