Что такое RAG: как работает генерация с опорой на найденный контекст в нейросетях

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

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

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

Кому подходит: службам поддержки, внутренним справочным системам, e-commerce-консультантам, системам факт-чека и аналитики документов.

Что такое RAG простыми словами

В базовом виде RAG — это связка из двух ключевых компонентов:

• поисковый ретривер — компонент, который по текстовому запросу быстро находит и отбирает наиболее релевантные фрагменты из базы знаний или индекса;

• генератор — языковая модель, которая формирует ответ на основе вопроса и извлечённых фрагментов.

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

Простая схема:

Пример хорошего сценария: клиент спрашивает про условия возврата товара → ретривер находит соответствующий пункт регламента → генератор формирует ответ со ссылкой на документ.

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

Как работает RAG по шагам

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

Шаг 1. Индексация

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

Если используется dense retrieval, то есть векторный поиск по смыслу, чанки преобразуются в эмбеддинги — числовые векторы, которые отражают смысл текста. Процесс превращения текста в векторы называется векторизацией. Вектор — это набор чисел; близкие по смыслу тексты получают близкие векторы.

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

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

Шаг 2. Извлечение

По запросу выбираются наиболее релевантные фрагменты. Для этого могут использоваться:

• векторный поиск — ищет смысловые совпадения;

• ключевой поиск, например BM25 — ищет лексические совпадения по словам;

• гибридный поиск — комбинирует оба подхода.

Дополнительно может применяться переранжирование: после первичного поиска специальный модуль более точно отбирает лучшие фрагменты. Количество извлекаемых кандидатов — top-k — подбирается экспериментально. Top-k означает, сколько фрагментов система берёт для дальнейшей работы: например, top-5 или top-10.

Шаг 3. Подготовка промпта

В промпт аккуратно кладутся вопрос и короткие релевантные фрагменты в логичном порядке и с ограничением объёма. Чем меньше лишнего текста, тем проще модели опереться на нужные факты.

Шаг 4. Генерация

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

Шаг 5. Проверка и ссылки

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

Архитектура и компоненты

Базовая архитектура RAG включает ретривер, генератор и внешний источник или индекс знаний. В системах с dense retrieval для поиска часто используется векторное хранилище.

• Retriever и Generator: первый отвечает за поиск документов под запрос, второй — за связный ответ с опорой на найденные фрагменты.

• Dense, sparse, hybrid: dense retrieval — это векторный поиск по эмбеддингам; sparse retrieval — лексический поиск, например BM25; гибрид объединяет оба сигнала.

• Хранилище векторов: эмбеддинги документов размещаются в индексах, поддерживающих быстрый поиск ближайших соседей. Запрос также преобразуется в вектор при выполнении поиска.

Инструменты: для работы с векторами используют открытые и управляемые решения — pgvector, Qdrant, Milvus, Weaviate, библиотеки вроде FAISS, а также встроенные векторные возможности реляционных и аналитических СУБД. Для оркестрации пайплайна — фреймворки для сборки RAG-приложений.

Векторный и гибридный поиск: когда что использовать

Гибридный поиск объединяет семантику и лексику: векторный поиск находит смысловые совпадения, BM25 — лексические, а их комбинация во многих сценариях помогает повысить качество и устойчивость поиска.

Когда нужен BM25: для запросов с названиями, артикулом, точным термином и требованием жёсткого текстового совпадения. Примеры: «артикул 12345», «срок доставки до 5 дней».

Когда нужны векторы: для разговорных формулировок, перефразов и неоднозначных вопросов, где важнее смысл, а не точная форма слова. Примеры: «как вернуть товар», «что делать, если не пришёл заказ».

Почему используют гибрид: комбинирование семантики и лексики через объединение результатов и взвешивание — например, RRF или взвешенную сумму — может повысить точность и устойчивость поиска. RRF, reciprocal rank fusion, — это способ объединить несколько ранжированных списков результатов. При score fusion веса следует подбирать на валидационной выборке.

Метрики оценки поиска: recall@k, precision@k, MRR, nDCG@k. Простыми словами:

• recall@k — нашли ли нужный документ среди первых k результатов;

• precision@k — сколько среди первых k результатов действительно полезных;

• MRR — насколько высоко в выдаче стоит первый полезный результат;

• nDCG@k — насколько хорошо отсортированы полезные результаты в топе.

Целевые значения зависят от датасета, типа запросов и требований конкретной системы и определяются на собственной тестовой выборке.

Чанкование и токенизация

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

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

Практические советы:

• Слишком крупные фрагменты могут добавлять в контекст лишний текст, слишком мелкие — разрывать связанные факты.

• Оптимум подбирается экспериментально на метриках извлечения и качества ответа.

• В качестве стартовой точки можно тестировать чанки размером в несколько сотен токенов с небольшим перекрытием.

• Для юридических документов и регламентов — чанкование по структурным границам, например пунктам, статьям и разделам.

• Для длинных аналитических текстов — семантическое чанкование по границам тем.

• Для кода полезно учитывать естественные структурные границы: функции, классы и модули.

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

Преимущества и ограничения

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

Преимущества:

• актуализация знаний без дообучения;

• проверяемость через ссылки;

• возможность снизить риск «галлюцинаций»;

• более прозрачная логика происхождения ответа.

Издержки:

• дополнительная задержка за счёт поиска и ранжирования;

vстоимость расчёта эмбеддингов и хранения индексов при использовании векторного поиска;

• зависимость от качества базы знаний.

Критический фактор: качество ретривера и подготовленных данных существенно влияет на итоговое качество ответа. Размер чанка, модель эмбеддингов, параметр top-k и настройки переранжирования следует подбирать экспериментально.

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

Практические ограничения, которые важно учитывать:

• Актуальность базы. Если документы не обновляются, RAG будет уверенно отвечать по устаревшим данным.

• Права доступа. Пользователь не должен получать фрагменты, которые ему не разрешены. Проверка прав должна происходить на этапе поиска, а не после генерации.

• Конфиденциальность. Если база содержит чувствительные данные, внешние API и облачные сервисы могут быть неприемлемы. Тогда нужны локальные модели и хранилища.

• Умение отказаться от ответа. Хорошая RAG-система должна уметь сказать «в найденных источниках нет ответа» или «недостаточно данных», а не достраивать факты по догадке.

Варианты моделей RAG

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

• RAG-Sequence: один и тот же найденный документ используется при генерации всей выходной последовательности, а вероятность ответа агрегируется по найденным документам.

• RAG-Token: модель допускает использование разных найденных документов на разных шагах генерации токенов.

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

Сравнение подходов​