RAG (retrieval-augmented generation) — это способ подключить языковую модель к живой базе знаний так, чтобы при каждом запросе она работала не только с тем, что запомнила во время обучения, но и с конкретными документами, которые система извлекла секунду назад. Термин ввели исследователи Meta AI в статье 2020 года; с тех пор паттерн стал стандартом для корпоративных приложений поверх LLM.

Почему обученной модели недостаточно

Большая языковая модель фиксирует знания на момент окончания обучения. GPT-4, обученный на данных до начала 2024 года, не знает, что произошло после этой даты — и никакие дообучения общего назначения это не исправят без колоссальных затрат. Помимо проблемы свежести данных, есть проблема приватных данных: внутренние регламенты компании, база клиентов, техническая документация — всё это никогда не попадёт в публичный датасет.

Когда модель не знает точного ответа, она его придумывает. Этот эффект называют галлюцинацией: модель генерирует синтаксически корректный, уверенно звучащий текст, который при этом фактически неверен. Для поискового ассистента, юридического инструмента или медицинской справочной системы такое поведение неприемлемо.

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

Как устроен пайплайн

Стандартный RAG-пайплайн состоит из двух фаз: индексирования (происходит заранее) и инференса (происходит в реальном времени при каждом запросе).

Фаза индексирования — подготовка базы знаний:

  • Загрузка документов: PDF, веб-страницы, базы данных, Confluence, Notion — любые источники превращаются в текст. LangChain и аналогичные фреймворки предоставляют загрузчики для десятков форматов.
  • Разбивка на чанки: большие документы делятся на фрагменты — обычно по 256–1024 токена с небольшим перекрытием. Размер чанка критически влияет на качество поиска: слишком маленькие фрагменты теряют контекст, слишком большие размывают сигнал.
  • Эмбеддинги: каждый чанк прогоняется через embedding-модель, которая превращает текст в числовой вектор — массив из сотен или тысяч чисел, описывающий семантику фрагмента. Популярные модели: OpenAI text-embedding-3-large, Cohere Embed v3, а также открытые варианты вроде intfloat/multilingual-e5-large с хорошей поддержкой русского языка.
  • Запись в векторную базу: векторы вместе с текстом оригинальных чанков и метаданными (источник, дата, раздел) сохраняются в векторную БД — Qdrant, Pinecone, Weaviate или pgvector в Postgres.

Фаза инференса — обработка запроса пользователя:

  • Эмбеддинг запроса: вопрос пользователя превращается в вектор той же embedding-моделью, что использовалась при индексировании.
  • Поиск по сходству: векторная база вычисляет косинусное сходство (или dot product) между вектором запроса и всеми сохранёнными векторами, возвращает top-k наиболее близких чанков — обычно от 3 до 10.
  • Формирование контекста: извлечённые фрагменты вставляются в системный промпт вместе с исходным вопросом. Типовая инструкция модели: «Отвечай только на основе предоставленных документов; если ответа нет — скажи об этом явно».
  • Генерация: LLM производит ответ, опираясь на переданный контекст. Некоторые реализации добавляют ссылки на источники — номера чанков или URL исходных документов.

Где применяется RAG

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

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

Code search и разработческие инструменты — отдельная область. Системы вроде Cursor или GitHub Copilot Workspace используют RAG-подобный поиск по кодовой базе: модель получает релевантные файлы и функции в контекст перед тем, как предложить правку.

Мультидокументный анализ в research и due diligence. Инвестиционный аналитик загружает 200 PDF с финансовой отчётностью и задаёт вопросы поперёк всего корпуса. Без RAG это невозможно технически — ни одна модель не уместит 200 PDF в контекстное окно одновременно.

Ограничения и где RAG не справляется

Качество RAG-системы жёстко ограничено качеством retrieval. Если поисковый запрос сформулирован иначе, чем текст в документе, эмбеддинговое сходство может не найти нужный чанк. Это называют проблемой vocabulary mismatch. Частичное решение — гибридный поиск: комбинация эмбеддингового (семантического) и BM25 (полнотекстового) поиска. Qdrant и Weaviate поддерживают гибридный режим нативно.

Разбивка на чанки ломает структуру. Таблица, разрезанная пополам, теряет смысл. Нумерованный список, у которого начало в одном чанке, а конец в другом, дезориентирует модель. Современные подходы — semantic chunking (разбивка по семантическим границам, а не по числу токенов) и late chunking (эмбеддинг на уровне всего документа, потом сегментация) — смягчают проблему, но не устраняют полностью.

Длинные ответы с опорой на много документов деградируют. Исследования показывают эффект lost in the middle: модели хуже усваивают информацию, расположенную в середине длинного контекста. Если top-k возвращает 10 чанков, самые важные данные лучше размещать в начале или конце переданного контекста.

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

Задержка (latency) — операционное ограничение. Каждый запрос требует: embedding inference, vector search, формирование промпта, LLM inference. На практике это 300–800 мс накладных расходов сверх времени генерации. Для интерактивных приложений это приемлемо; для систем с требованием ответа быстрее 100 мс — проблема, требующая кэширования или предвычисления.

Наконец, RAG не устраняет галлюцинации полностью. Если релевантный чанк не попал в top-k, модель всё равно попытается ответить на основе параметрических знаний. Практика «скажи, что не знаешь» снижает этот риск, но требует тщательной настройки системного промпта и оценки качества на реальных данных — без этого модель периодически будет игнорировать инструкцию.