СтатьяОткрытый материал

RAG-системы: как языковая модель отвечает на основе внешних данных

Подробно разбираем, что такое RAG-система, из каких компонентов она состоит, как документы превращаются в индекс, как работает поиск и как LLM формирует ответ на основе найденного контекста.

Команда Студии Ягуара 03 августа 2026 34 мин чтения 175 просмотров

AI и автоматизация #LLM #RAG #базы знаний #векторный поиск #искусственный интеллект #эмбеддинги

RAG-системы: как языковая модель отвечает на основе внешних данных

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

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

На этом принципе строится RAG.

Вопрос пользователя - поиск подходящих данных - добавление найденных данных в контекст - генерация ответа

RAG-система соединяет два разных механизма:

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

Главная мысль: RAG не записывает документы в знания модели. Система находит нужные данные во время запроса и временно передаёт их LLM.

Почему языковой модели недостаточно собственных знаний

Языковая модель формирует ответ на основе двух основных источников:

Параметры модели - закономерности, усвоенные во время обучения
Контекст запроса - текст и инструкции, переданные модели сейчас

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

Из этого следуют несколько ограничений.

Модель не знает закрытые данные

Общедоступная модель обычно не имеет доступа к:

внутренним инструкциям компании;
корпоративной базе знаний;
CRM;
истории обращений клиента;
закрытой технической документации;
договорам;
локальным файлам;
данным внутренних сервисов.

Даже если модель хорошо знает общую тему, она не может достоверно восстановить содержание документа, которого не видела.

Знания модели могут быть устаревшими

Между обучением модели и текущим запросом проходит время. За этот период могут измениться:

цены;
правила возврата;
тарифы;
законы;
версии программ;
структура компании;
характеристики продукта;
внутренние регламенты.

Модель не обновляет свои параметры после каждого изменения внешнего мира.

Модель может сформировать правдоподобный, но неверный ответ

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

Если точной информации не хватает, модель может:

дополнить пробел общими знаниями;
смешать несколько похожих фактов;
неверно интерпретировать вопрос;
придумать источник;
уверенно сформулировать ошибочный вывод.

Такое поведение называют галлюцинацией.

В контекст нельзя бесконечно добавлять документы

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

Даже если окно достаточно большое, передавать все документы целиком обычно невыгодно:

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

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

Что означает RAG

RAG расшифровывается как Retrieval-Augmented Generation.

Retrieval - поиск и извлечение информации
Augmented - дополнение запроса найденными данными
Generation - генерация ответа языковой моделью

По смыслу RAG можно перевести как генерацию, дополненную поиском.

Система работает в два этапа:

Retrieval - найти подходящие данные
Generation - сформировать ответ с учётом найденных данных

Слово Augmented связывает эти этапы. Найденные фрагменты не просто показываются пользователю как поисковая выдача, а добавляются в запрос к модели.

Простейший RAG-процесс выглядит так:

Пользователь задаёт вопрос
Система ищет подходящие фрагменты
Фрагменты добавляются в контекст LLM
LLM формирует ответ
Ответ возвращается пользователю

Что такое RAG-система

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

RAG не является отдельной нейросетью и не является специальным типом языковой модели.

LLM - генерирует текст
Retrieval - находит информацию
RAG-система - связывает поиск, контекст и генерацию в один процесс

Конкретная RAG-система может включать:

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

Не все компоненты обязательны. Минимальный вариант состоит из данных, поиска, формирования контекста и LLM.

Данные - источник фактов
Поиск - выбор подходящих фрагментов
Контекст - передача найденных данных модели
LLM - формирование ответа

RAG как принцип, архитектура и система

Термин используется на нескольких уровнях.

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

Например, принцип может быть одинаковым, но реализации отличаться:

одна система ищет по PDF-файлам;
другая получает данные из PostgreSQL;
третья объединяет документы, API и полнотекстовый поиск;
четвёртая выбирает источник динамически.

Что не является RAG

Не всякое использование LLM с документами является полноценной RAG-системой.

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

Если приложение только нашло документы и показало их пользователю, это поиск без генерации.

Если модель была дообучена на документах, но во время запроса ничего не ищет, это fine-tuning, а не RAG.

Документ вручную вставлен в prompt - контекстная генерация
Найдены документы без ответа LLM - информационный поиск
Изменены параметры модели - дообучение
Поиск выполнен во время запроса и результат передан LLM - RAG

Простой пример работы RAG

Пусть в базе знаний компании есть правило:

Товар надлежащего качества можно вернуть в течение 30 дней после покупки.

Пользователь спрашивает:

Можно ли вернуть товар через 20 дней?

Без внешнего источника модель может опираться на общие правила или предположить срок.

RAG-система выполняет последовательность:

1. Получает вопрос.
2. Ищет фрагменты о возврате товара.
3. Находит актуальное правило.
4. Добавляет правило в запрос к LLM.
5. Просит ответить на основании найденного контекста.
6. Возвращает ответ пользователю.

Запрос к модели может быть собран так:

Инструкция:
Ответь на вопрос только по предоставленному контексту.
Если контекста недостаточно, сообщи об этом.

Контекст:
Товар надлежащего качества можно вернуть в течение 30 дней после покупки.

Вопрос:
Можно ли вернуть товар через 20 дней?

Модель формирует ответ:

Да. Согласно предоставленному правилу, товар можно вернуть в течение 30 дней, поэтому срок в 20 дней допустим.

В этом примере модель не искала документ самостоятельно. Поиск выполнило приложение, а LLM получила уже выбранный фрагмент.

Что считается внешними данными

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

Внешними источниками могут быть:

PDF;
DOCX;
Markdown;
HTML-страницы;
Wiki;
база знаний;
PostgreSQL;
CRM;
файловое хранилище;
электронная почта;
сообщения поддержки;
документация;
API;
каталог товаров;
журналы событий;
расшифровки разговоров;
фрагменты программного кода.

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

Например, таблица заказов в той же инфраструктуре остаётся внешним источником для LLM, потому что её строки не хранятся внутри параметров модели.

База знаний и RAG-система

База знаний - организованный набор данных, в котором система может искать информацию.

RAG-система - весь процесс от вопроса до ответа.

База знаний - что можно найти
Поисковый механизм - как найти
Контекст - что передать модели
LLM - как сформировать ответ
Приложение - как связать этапы

Папка с документами сама по себе не является RAG-системой. В ней ещё нет механизма, который принимает вопрос, находит данные и формирует ответ.

Два процесса внутри RAG-системы

Работу RAG удобно разделить на два крупных процесса:

Индексация - подготовка данных для будущего поиска
Обработка запроса - поиск данных и генерация ответа

Они запускаются в разное время и решают разные задачи.

Индексация

Индексация выполняется при добавлении или обновлении данных.

Источник - извлечение текста - очистка - чанкинг - метаданные - индекс

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

Обработка запроса

Этот процесс выполняется при каждом вопросе пользователя.

Вопрос - подготовка поискового запроса - retrieval - отбор - контекст - LLM - ответ

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

Почему процессы нужно разделять

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

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

Документ индексируется при добавлении или изменении
Запрос обрабатывается при каждом обращении

Из каких компонентов состоит RAG-система

Полную архитектуру можно представить как несколько уровней.

Источники данных
└── подготовка и индексирование
    └── поисковый слой
        └── формирование контекста
            └── языковая модель
                └── ответ и проверка результата

Источники данных

Это исходная информация, которую система должна использовать.

Источник отвечает на вопрос:

Где находится знание до начала обработки?

Данные могут быть статическими и динамическими.

Статические данные - инструкции, статьи, документация
Динамические данные - заказы, остатки, статусы, события

Статический документ удобно заранее индексировать. Динамический остаток товара лучше получать напрямую из базы или API, потому что сохранённая копия быстро устареет.

Конвейер подготовки данных

Конвейер подготовки извлекает содержимое источников и приводит его к пригодному для поиска виду.

Он может:

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

Индекс

Индекс - структура, ускоряющая поиск.

Это не обязательно отдельная векторная база. Индексом может быть:

полнотекстовый индекс;
инвертированный индекс;
векторный индекс;
таблица с фильтрами;
поисковый движок;
сочетание нескольких структур.

Retriever

Retriever - компонент, который получает поисковый запрос и возвращает набор подходящих кандидатов.

Запрос retriever - вопрос или его преобразованная версия
Ответ retriever - список фрагментов с оценками релевантности

Retriever не обязан формировать окончательный ответ. Его задача - получить данные.

Reranker

Reranker повторно оценивает найденных кандидатов и переставляет их по релевантности.

Первичный поиск может быстро найти 30 фрагментов. Reranker анализирует их точнее и выбирает несколько лучших.

Retriever - широкий и быстрый отбор
Reranker - более точная переоценка кандидатов

Компонент формирования контекста

Он решает:

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

Языковая модель

LLM получает:

системную инструкцию;
вопрос;
найденные фрагменты;
при необходимости историю диалога;
правила формата ответа.

Модель преобразует этот контекст в связный текст.

Приложение

Приложение связывает компоненты и управляет процессом.

Оно отвечает за:

приём запроса;
права доступа;
выбор источников;
вызов поиска;
сборку prompt;
вызов LLM;
обработку ошибок;
сохранение логов;
возврат ответа;
сбор обратной связи.

Как данные подготавливаются для поиска

Качество RAG начинается до первого вопроса пользователя. Если документы плохо обработаны, более мощная LLM не исправит потерянные данные.

Загрузка источников

Система получает материалы из одного или нескольких источников.

Файлы - чтение из хранилища
Сайт - загрузка страниц
База данных - выполнение запроса
API - получение ответа
Wiki - обращение к разделам и страницам

На этом этапе важно сохранить происхождение данных:

имя документа;
URL;
идентификатор записи;
версию;
дату изменения;
владельца;
уровень доступа.

Извлечение содержимого

Файл и текст внутри него - не одно и то же.

PDF может содержать:

текстовый слой;
таблицы;
изображения;
колонтитулы;
номера страниц;
несколько колонок;
сканированные страницы.

DOCX содержит абзацы, заголовки, таблицы и списки. HTML содержит навигацию, рекламу и служебные блоки.

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

Очистка

После извлечения могут остаться:

повторяющиеся колонтитулы;
номера страниц;
элементы меню;
лишние пробелы;
технические символы;
дубли;
пустые блоки;
повреждённые фрагменты.

Очистка уменьшает шум, но не должна удалять полезный контекст.

Нормализация

Нормализация приводит данные к согласованному формату.

Она может включать:

единое представление дат;
одинаковую кодировку;
нормализацию пробелов;
преобразование списков;
сохранение уровней заголовков;
унификацию идентификаторов;
приведение метаданных к общей схеме.

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

Что такое чанк

Чанк - отдельный фрагмент данных, который индексируется и может быть возвращён поиском.

Документ - исходная единица хранения
Чанк - единица поиска и передачи в контекст

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

Поэтому документ разделяют.

Документ
├── чанк 1
├── чанк 2
├── чанк 3
└── чанк 4

Чанк не обязательно равен абзацу

Чанком может быть:

один абзац;
несколько абзацев;
подраздел;
строка таблицы;
блок кода;
вопрос и ответ;
сообщение диалога;
описание одного объекта.

Размер и границы зависят от типа данных.

Слишком маленький чанк

Небольшой фрагмент может потерять необходимое окружение.

Срок составляет 30 дней.

Без заголовка или предыдущего предложения непонятно, к чему относится срок.

Слишком большой чанк

Большой фрагмент может содержать несколько тем.

Правила возврата + доставка + гарантия + программа лояльности

Он может находиться по одному слову, но передавать модели много лишней информации.

Перекрытие чанков

При фиксированном разбиении важное предложение может оказаться на границе двух фрагментов.

Чтобы часть контекста сохранялась, соседние чанки делают с перекрытием.

Чанк 1 - предложения 1-5
Чанк 2 - предложения 4-8

Общие предложения уменьшают риск потери связи, но увеличивают число дублей и объём индекса.

Структурный чанкинг

Вместо деления по количеству символов можно использовать структуру документа:

заголовки;
разделы;
абзацы;
элементы списка;
таблицы;
функции и классы в коде.

Структурный подход часто лучше сохраняет смысл.

Контекст чанка

Иногда найденному фрагменту добавляют сведения о его положении:

Документ - Регламент возвратов
Раздел - Возврат товара надлежащего качества
Подраздел - Срок возврата

Так короткий чанк становится понятнее без значительного увеличения размера.

Метаданные

Метаданные - данные о фрагменте, а не основной текст фрагмента.

Текст - содержание
Метаданные - происхождение, свойства и ограничения

Примеры:

document_id - идентификатор документа
title - название
section - раздел
source_url - адрес источника
version - версия
updated_at - дата изменения
language - язык
department - подразделение
access_level - уровень доступа

Зачем нужны метаданные

Они позволяют фильтровать поиск до или после оценки релевантности.

Например:

Искать только в документах отдела продаж
Использовать только последнюю версию
Исключить архивные материалы
Выбрать документы на русском языке
Показать данные, доступные текущему сотруднику

Векторная близость не решает эти задачи сама.

Фрагмент старой инструкции может быть очень близок к вопросу по смыслу, но его нельзя использовать, если существует новая версия.

Метаданные и безопасность

Права доступа должны проверяться до передачи контекста модели.

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

Пользователь - проверка прав - допустимые источники - поиск - контекст

Что такое эмбеддинг

Эмбеддинг - числовое представление объекта в виде вектора.

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

Упрощённо:

"Как изменить пароль?" - [0.12, -0.48, 0.73, ...]

Человек не читает этот вектор как текст. Он используется для вычислений.

Зачем текст превращают в вектор

Строковое сравнение хорошо работает, когда совпадают слова.

Но пользователь может сформулировать вопрос иначе:

Как изменить пароль?
Не могу войти в аккаунт
Где сбросить доступ?
Хочу восстановить учётную запись

Формулировки различаются, но относятся к одной теме.

Модель эмбеддингов стремится расположить семантически близкие тексты рядом в векторном пространстве.

Близкий смысл - близкие векторы
Разный смысл - более далёкие векторы

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

Эмбеддинг не является пересказом

Вектор:

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

Поэтому в индексе обычно сохраняют и вектор, и исходный текст.

Вектор - используется для поиска
Текст - передаётся LLM
Метаданные - используются для фильтрации и источников

Эмбеддинги документов и запроса

При индексации вычисляется вектор каждого чанка.

При вопросе вычисляется вектор запроса.

Чанк - модель эмбеддингов - вектор чанка
Вопрос - та же совместимая модель - вектор вопроса

Затем система сравнивает вектор вопроса с векторами чанков.

Что такое векторный поиск

Векторный поиск выбирает объекты, чьи векторы наиболее близки к вектору запроса.

Последовательность:

Вопрос - эмбеддинг вопроса - сравнение с индексом - ближайшие чанки

Для оценки близости могут использоваться разные функции:

cosine similarity;
dot product;
Euclidean distance.

Конкретная функция должна соответствовать модели эмбеддингов и настройке индекса.

Cosine similarity

Косинусная близость сравнивает направление двух векторов.

Упрощённо:

Значение ближе к 1 - направления похожи
Значение ближе к 0 - слабая связь
Отрицательное значение - противоположное направление

Но числовой порог нельзя переносить между всеми моделями и задачами. Оценка 0.75 в одной системе не обязательно означает то же самое в другой.

Top-k

Поиск часто возвращает k наиболее близких фрагментов.

top_k = 5 - вернуть пять лучших кандидатов

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

Малое значение уменьшает объём, но может исключить важные данные.

top-k является только первым отбором, а не гарантией релевантности.

Обязательно ли использовать векторную базу

Нет. RAG определяется связкой поиска и генерации, а не конкретным хранилищем.

Можно использовать:

полнотекстовый поиск;
SQL;
фильтры;
поисковый движок;
граф;
API;
векторный индекс;
комбинацию подходов.

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

Она обычно хранит:

идентификатор;
вектор;
текст или ссылку на текст;
метаданные.

Но тот же принцип может быть реализован расширением PostgreSQL, специализированным поисковым движком или локальным индексом.

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

Полнотекстовый поиск

Полнотекстовый поиск сопоставляет слова и их формы.

Он полезен для:

точных терминов;
артикулов;
имён;
кодов ошибок;
названий функций;
юридических формулировок;
редких ключевых слов.

Например, запрос:

ERR_CONNECTION_RESET

может лучше обрабатываться полнотекстовым поиском, чем семантическим.

Сильные стороны

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

Ограничения

Если вопрос и документ используют разные слова, совпадение может не произойти.

Вопрос - как восстановить доступ
Документ - сброс пароля

Семантический поиск способен связать такие формулировки лучше.

Гибридный поиск

Гибридный поиск объединяет полнотекстовое и векторное ранжирование.

Полнотекстовый поиск - находит точные слова
Векторный поиск - находит смысловую близость
Гибридный поиск - объединяет результаты

Это полезно, когда запрос содержит одновременно:

предметный смысл;
точный идентификатор;
название продукта;
код ошибки;
специальный термин.

Например:

Как исправить ошибку AUTH_104 при входе?

Векторная часть понимает тему авторизации, а полнотекстовая точно находит AUTH_104.

Результаты двух поисков можно:

объединить;
нормализовать;
взвесить;
передать на reranking.

Что такое retrieval

Retrieval - процесс получения кандидатов из источников данных.

Это более широкое понятие, чем векторный поиск.

Retriever может:

искать по эмбеддингам;
выполнять SQL;
обращаться к API;
фильтровать документы;
запускать полнотекстовый поиск;
объединять несколько источников;
выбирать данные по времени;
получать соседние фрагменты.

Вход retriever:

Поисковый запрос + фильтры + права доступа

Выход:

Набор кандидатов + оценки + метаданные

Query transformation

Вопрос пользователя не всегда является хорошим поисковым запросом.

Например:

А что с ним делать после этого?

Вопрос зависит от истории диалога.

Система может преобразовать его в самостоятельный запрос:

Что делать с заказом после подтверждения оплаты?

Другие преобразования:

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

Преобразование должно сохранять намерение пользователя. Слишком свободная переформулировка может увести поиск в другую тему.

Multi-query retrieval

Один вопрос можно преобразовать в несколько вариантов.

Как восстановить пароль?
Сброс пароля пользователя
Восстановление доступа к аккаунту

Результаты объединяются, чтобы увеличить полноту поиска.

Это повышает шанс найти данные, но увеличивает число обращений и количество кандидатов.

Декомпозиция вопроса

Сложный вопрос может содержать несколько подзадач.

Какие документы нужны для возврата и сколько времени занимает выплата?

Система может искать отдельно:

Документы для возврата
Срок выплаты после возврата

После этого результаты объединяются в общий контекст.

Что такое reranking

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

Reranking - повторная оценка кандидатов более точной моделью или алгоритмом.

Индекс - 30 кандидатов - reranker - 5 лучших фрагментов

Чем reranker отличается от эмбеддингов

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

Reranker рассматривает запрос и каждый кандидат вместе.

Векторный поиск - быстро сравнивает отдельные представления
Reranker - точнее оценивает пару вопрос + фрагмент

Совместная обработка дороже, поэтому reranker применяют к ограниченному набору кандидатов.

Что может учитывать reranking

отвечает ли фрагмент на вопрос;
содержит ли конкретный факт;
относится ли он к нужному объекту;
совпадает ли временной контекст;
является ли документ актуальным;
есть ли в тексте отрицание;
достаточно ли фрагмент самодостаточен.

Reranking не исправляет отсутствие данных

Если нужный документ не попал в кандидаты, reranker не сможет его восстановить.

Retrieval отвечает за полноту кандидатов
Reranking отвечает за порядок и точность отбора

Как формируется контекст

После поиска система должна собрать текст, который получит LLM.

Это не простое объединение всех результатов.

Контекст может включать:

найденные чанки;
названия документов;
номера разделов;
даты;
ссылки;
идентификаторы источников;
инструкции по ответу;
историю диалога;
данные из API.

Бюджет контекста

Общий запрос должен поместиться в контекстное окно модели.

В него входят:

Системная инструкция
История диалога
Вопрос пользователя
Найденные фрагменты
Служебные данные
Будущий ответ

Если найденного текста слишком много, нужно:

уменьшить число чанков;
удалить дубли;
выбрать лучшие результаты;
сократить историю;
объединить соседние фрагменты;
использовать предварительное сжатие;
разбить задачу на этапы.

Порядок фрагментов

Порядок влияет на восприятие контекста.

Возможные стратегии:

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

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

Контекст и источник

Фрагмент полезно передавать с идентификатором:

[Источник 1]
Документ: Регламент возвратов
Раздел: Сроки
Текст: ...

[Источник 2]
Документ: Правила выплаты
Раздел: Возврат средств
Текст: ...

Так модель может ссылаться на материалы, а приложение - сопоставить ответ с документами.

Сжатие контекста

Иногда найденный чанк содержит полезное предложение и много лишнего текста.

Контекстное сжатие оставляет только части, связанные с вопросом.

Но дополнительная модель может случайно удалить важное условие или изменить смысл. Поэтому сжатие нужно оценивать отдельно.

Что такое prompt в RAG

Prompt - полный набор инструкций и данных, переданный языковой модели.

Он может состоять из нескольких уровней:

Системная инструкция - общие правила поведения
Контекст - найденные данные
История - предыдущие сообщения
Вопрос - текущий запрос пользователя
Формат ответа - требования к результату

Пример:

Ты отвечаешь на вопросы по внутренней базе знаний.

Правила:
- Используй только предоставленный контекст.
- Не придумывай отсутствующие факты.
- Если ответа нет, прямо сообщи об этом.
- Указывай номера источников.

Контекст:
[1] ...
[2] ...

Вопрос:
...

Почему инструкция не гарантирует правильность

Фраза «отвечай только по контексту» снижает риск, но не превращает модель в детерминированный механизм проверки фактов.

LLM может:

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

Поэтому prompt является одним из уровней защиты, а не полной гарантией.

Как LLM формирует ответ

После получения prompt модель генерирует текст последовательно.

На этом этапе она должна:

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

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

Без RAG - вопрос + знания модели
С RAG - вопрос + найденные данные + знания модели

В зависимости от инструкции система может разрешать или запрещать использование внутренних знаний LLM.

Grounded answer

Grounded answer - ответ, утверждения которого опираются на предоставленные источники.

У такого ответа можно проверить:

найден ли соответствующий фрагмент;
действительно ли он подтверждает утверждение;
не добавила ли модель лишний вывод;
актуален ли источник.

Ответ при недостатке данных

Хорошая RAG-система должна уметь не отвечать.

В базе знаний нет достаточной информации для ответа.

Это лучше, чем уверенная догадка.

Для этого недостаточно одной инструкции. Нужны:

оценка релевантности;
минимальные пороги;
проверка наличия подтверждения;
сценарий отказа;
тесты на вопросы без ответа.

Цитирование источников

RAG может возвращать не только текст ответа, но и ссылки на материалы.

Система должна различать:

Retrieval source - документ, найденный поиском
Citation - конкретный источник, подтверждающий утверждение

Не каждый найденный фрагмент обязательно использован в ответе.

Надёжное цитирование требует сопоставить утверждения с фрагментами. Простая просьба модели «добавь ссылки» может привести к формальным или неверным ссылкам.

Для каждого источника полезно хранить:

идентификатор;
название;
URL;
раздел;
страницу;
версию;
дату обновления.

Полный путь документа

Теперь можно собрать процесс индексации целиком.

Источник данных - загрузка - извлечение содержимого - очистка - нормализация - разделение на чанки - добавление метаданных - создание эмбеддингов - запись в индекс

1. Источник появляется в системе

Это может быть новый файл, изменённая страница или запись базы данных.

2. Система извлекает данные

Формат источника преобразуется в текст и структуру.

3. Данные очищаются

Удаляется технический шум, но сохраняется смысловая структура.

4. Документ разделяется

Создаются фрагменты подходящего размера.

5. Добавляются метаданные

Каждый чанк получает сведения о происхождении, версии и доступе.

6. Создаются эмбеддинги

Модель преобразует текст каждого чанка в вектор.

7. Данные записываются в индекс

Сохраняются векторы, тексты, идентификаторы и метаданные.

8. Индекс обновляется

При изменении документа старые фрагменты нужно заменить или пометить неактуальными.

Без корректного обновления система может одновременно находить несколько версий одного правила.

Полный путь пользовательского запроса

Процесс запроса выглядит иначе.

Вопрос пользователя - проверка пользователя и прав - подготовка поискового запроса - поиск кандидатов - фильтрация - reranking - сборка контекста - вызов LLM - проверка и оформление ответа

1. Приложение принимает вопрос

Дополнительно оно может получить:

историю диалога;
данные пользователя;
выбранный проект;
язык;
фильтры;
режим ответа.

2. Проверяются права

Определяется, какие источники доступны пользователю.

3. Вопрос подготавливается

Он может быть преобразован в самостоятельный поисковый запрос.

4. Retriever получает кандидатов

Поиск выполняется по одному или нескольким индексам.

5. Результаты фильтруются

Удаляются:

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

6. Reranker уточняет порядок

Кандидаты оцениваются относительно конкретного вопроса.

7. Формируется контекст

Выбирается ограниченное число фрагментов и добавляются источники.

8. LLM генерирует ответ

Модель получает инструкции, вопрос и контекст.

9. Приложение обрабатывает результат

Оно может:

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

Почему RAG может ошибаться

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

Нужных данных нет в источниках

Если правило не загружено, поиск не сможет его найти.

Нет данных - нет надёжного основания для ответа

LLM может компенсировать пробел собственными знаниями, но это уже не ответ по базе знаний.

Источник не был проиндексирован

Документ существует, но:

загрузка завершилась ошибкой;
извлечение текста не сработало;
обновление индекса не запускалось;
файл имеет неподдерживаемый формат;
запись была пропущена фильтром.

Текст извлечён неправильно

В PDF может нарушиться порядок колонок. Таблица может превратиться в бессвязный текст. Скан может распознаться с ошибками.

Поиск работает уже по искажённым данным.

Неправильно выбраны чанки

Слишком маленький чанк теряет условия. Слишком большой смешивает темы.

Особенно опасно отделять:

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

Поиск не нашёл релевантный фрагмент

Причины:

неудачная формулировка вопроса;
слабая модель эмбеддингов;
другой язык;
неправильный индекс;
слишком маленький top-k;
отсутствие точного поиска;
некорректные фильтры.

Найден похожий, но неправильный документ

Например, система нашла правило для юридических лиц вместо правила для физических лиц.

Смысл близок, но область применения отличается.

Найдена устаревшая версия

Если версии не отслеживаются, старая инструкция может иметь высокую релевантность и попасть в контекст.

Релевантный фрагмент потерян после retrieval

Нужный чанк мог попасть в 30 кандидатов, но:

reranker поставил его низко;
фильтр исключил его;
он не поместился в контекст;
дедупликация сочла его повтором.

Контекст содержит противоречие

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

Система должна понимать:

какой документ новее;
какой имеет больший приоритет;
к какой группе относится пользователь;
не является ли один материал архивным.

LLM сама не обязана правильно определить юридический или организационный приоритет.

Модель неверно использовала правильный контекст

Даже при идеальном поиске модель может:

пропустить отрицание;
перепутать числа;
неверно объединить условия;
сделать лишний вывод;
не соблюсти формат;
добавить неподтверждённую информацию.

Ответ выглядит хорошо, но не подтверждается источниками

Связность и уверенный стиль не являются показателями достоверности.

Поэтому качество ответа нужно оценивать отдельно от качества текста.

Как оценивать RAG-систему

Нельзя оценивать систему только вопросом «нравится ли ответ».

Нужно разделять этапы.

Качество данных - есть ли правильная информация
Качество retrieval - найдена ли она
Качество контекста - передана ли она модели
Качество генерации - правильно ли сформирован ответ

Оценка данных

Проверяется:

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

Оценка retrieval

Для тестовых вопросов заранее определяют релевантные фрагменты.

Можно измерять:

Recall@k - попал ли нужный фрагмент в первые k результатов
Precision@k - сколько из первых k результатов действительно релевантны
MRR - насколько высоко находится первый релевантный результат
nDCG - насколько правильно упорядочены результаты с разной релевантностью

Для вводной оценки достаточно понимать различие:

Recall - не потеряли ли нужное
Precision - не принесли ли слишком много лишнего

Оценка контекста

Проверяется:

есть ли в контексте ответ;
нет ли критически лишних данных;
сохранились ли условия и исключения;
не попали ли закрытые данные;
правильно ли обозначены источники;
не конфликтуют ли версии.

Оценка ответа

Ответ оценивают по нескольким критериям:

Correctness - правильность
Faithfulness - соответствие источникам
Relevance - соответствие вопросу
Completeness - полнота
Citation accuracy - корректность ссылок
Abstention - способность отказаться при отсутствии данных

Набор тестовых вопросов

Нужны разные типы запросов:

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

Обратная связь пользователей

Кнопки «полезно» и «неполезно» дают сигнал, но сами по себе не объясняют причину.

Полезно сохранять:

вопрос;
найденные кандидаты;
выбранный контекст;
ответ;
источники;
оценку;
комментарий пользователя;
версию конвейера.

Тогда можно определить, где произошла ошибка.

RAG и fine-tuning

RAG и fine-tuning решают разные задачи.

RAG - добавляет внешние данные во время запроса
Fine-tuning - изменяет параметры модели во время обучения

Когда полезен RAG

знания часто обновляются;
нужны закрытые документы;
требуется показывать источники;
нужно быстро добавлять материалы;
информация слишком объёмна;
данные различаются между пользователями.

Когда полезен fine-tuning

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

Fine-tuning не является удобной заменой постоянно обновляемой базе знаний.

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

Совместное использование

Дообученная модель может использоваться внутри RAG.

Fine-tuning - улучшает поведение модели
RAG - предоставляет фактический контекст

RAG и длинный контекст

Модель с большим контекстным окном может получить много документов целиком. Но длинный контекст не отменяет retrieval.

Передача всех документов

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

не нужно заранее выбирать фрагменты;
сохраняется структура документов;
проще прототипирование на небольшом объёме.

Недостатки:

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

Retrieval перед длинным контекстом

Даже при большом окне поиск помогает сократить данные и повысить их релевантность.

Длинный контекст - сколько модель может принять
Retrieval - что именно стоит ей передать

Эти подходы не исключают друг друга.

RAG и обычный поиск

Обычный поиск возвращает документы или фрагменты.

RAG использует их как материал для генерации ответа.

Поиск - выдаёт источники
RAG - выдаёт сгенерированный ответ на основе источников

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

RAG удобнее, когда нужно:

объединить несколько фрагментов;
сформулировать краткий ответ;
преобразовать данные;
объяснить материал;
заполнить структуру;
поддерживать диалог.

Но генерация добавляет риск искажения. Поэтому в критических задачах полезно возвращать и ответ, и первичные источники.

RAG и обращение к API

Не всякую информацию нужно индексировать.

Например, пользователь спрашивает:

Какой статус у моего заказа?

Статус постоянно меняется. Поиск по заранее созданному вектору может вернуть устаревшее значение.

Лучше выполнить точный запрос:

order_id - API или SQL - актуальный статус

RAG особенно полезен для неструктурированного текста. Для точных структурированных данных часто лучше использовать:

SQL;
API;
функции;
бизнес-правила.

Одна система может объединять оба подхода:

Регламент доставки - retrieval по документам
Текущий статус заказа - запрос к API
LLM - объединение данных в ответ

Виды RAG-систем

Разные названия описывают способы усложнить базовый процесс.

Простой RAG

Вопрос - один поиск - несколько чанков - один вызов LLM

Подходит для прототипа и небольшой базы знаний.

RAG с фильтрацией

Перед поиском применяются метаданные:

department = support
language = ru
version = current

Hybrid RAG

Использует векторный и полнотекстовый поиск.

RAG с reranking

Первичные кандидаты повторно оцениваются более точной моделью.

Multi-query RAG

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

Conversational RAG

Учитывает историю диалога и преобразует зависимые вопросы в самостоятельные.

Multi-source RAG

Объединяет несколько источников:

документы;
базы данных;
API;
поиск;
граф.

Agentic RAG

Модель или агент решает:

нужен ли поиск;
какой источник выбрать;
какие запросы выполнить;
достаточно ли найденных данных;
нужно ли повторить поиск.

Такой подход гибче, но сложнее контролировать, тестировать и прогнозировать по стоимости.

Когда RAG нужен

RAG подходит, если одновременно выполняются несколько условий:

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

Типичные задачи:

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

Когда RAG не нужен

RAG добавляет инфраструктуру и новые точки отказа. Его не стоит использовать автоматически для любой задачи с LLM.

Данных мало

Если один короткий документ всегда помещается в prompt, отдельный индекс может быть лишним.

Нужна точная структурированная выборка

Для вопроса:

Сколько заказов создано сегодня?

лучше выполнить SQL, чем искать похожий текст.

Задача не требует внешних знаний

Для перевода, изменения стиля или генерации шаблона retrieval может не дать пользы.

Ответ должен вычисляться

Если результат определяется формулой или бизнес-правилом, его нужно вычислить программно.

Нужна абсолютная детерминированность

LLM остаётся вероятностной. В критической операции она не должна заменять проверяемый алгоритм.

Нет качественной базы знаний

RAG не создаёт знания из отсутствующих или противоречивых данных.

Плохие источники - плохой retrieval - ненадёжный ответ

Как спроектировать минимальную RAG-систему

Для первого рабочего варианта достаточно ограниченной архитектуры.

1. Определить задачу

Нужно зафиксировать:

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

2. Подготовить небольшой качественный набор документов

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

3. Настроить извлечение и чанкинг

Проверить вручную:

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

4. Создать индекс

Сохранить:

текст;
вектор;
источник;
раздел;
версию;
дату;
права доступа.

5. Реализовать retrieval

Начать можно с:

одного поискового запроса;
фильтра по актуальности;
небольшого top-k;
возврата оценок и источников.

6. Собрать prompt

Задать:

роль системы;
правила использования контекста;
поведение при недостатке данных;
формат цитирования;
желаемую структуру ответа.

7. Сохранять промежуточные результаты

Для каждого запроса полезно видеть:

Исходный вопрос
Преобразованный поисковый запрос
Найденные кандидаты
Контекст для LLM
Итоговый ответ

Без этого невозможно понять, где возникла ошибка.

8. Создать тестовый набор

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

9. Улучшать по узкому месту

Не найден нужный документ - улучшать retrieval
Найден, но стоит низко - добавлять reranking
Контекст правильный, ответ неверный - менять prompt или модель
Используется старая версия - улучшать метаданные и обновление
Слишком много лишнего - менять чанкинг и отбор

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

Частые ошибки при проектировании

Сразу загружать все данные

Большой объём не компенсирует отсутствие структуры и качества.

Выбирать чанки только по числу символов

Механическое разбиение может отделить условие от результата.

Использовать только векторный поиск

Он может плохо находить коды, номера, имена и точные термины.

Не хранить версии

Система начинает смешивать актуальные и архивные документы.

Не проверять права до retrieval

Закрытые данные могут попасть в контекст.

Передавать слишком много фрагментов

Больше контекста не всегда означает лучший ответ.

Оценивать только итоговый текст

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

Не тестировать вопросы без ответа

Система должна уметь сообщать о недостатке данных.

Считать RAG защитой от всех галлюцинаций

RAG уменьшает неопределённость, но не устраняет вероятность ошибки модели.

Практический алгоритм выбора архитектуры

Задайте несколько вопросов.

1. Где находится нужная информация?

Документы - retrieval
Таблицы - SQL
Внешний сервис - API
Вычисляемое значение - функция

2. Насколько быстро данные меняются?

Редко - можно индексировать
Часто - получать напрямую или регулярно обновлять
В реальном времени - обращаться к первичному источнику

3. Нужен ли поиск по смыслу?

Если пользователь и документ могут описывать одно понятие разными словами, полезен векторный поиск.

4. Есть ли точные термины?

Если важны коды, идентификаторы и названия, нужен полнотекстовый или точный поиск.

5. Требуется ли подтверждение ответа?

Если да, нужно хранить происхождение чанков и возвращать источники.

6. Есть ли разные уровни доступа?

Фильтрация прав должна быть частью retrieval.

7. Что делать при отсутствии ответа?

Сценарий отказа нужно определить заранее.

Частые вопросы

Является ли RAG отдельной моделью

Нет. RAG - архитектурный подход, объединяющий поиск и генерацию.

Обязательно ли использовать LLM

Для RAG в современном смысле генеративная модель является частью процесса. Без неё останется обычный поиск.

Обязательно ли использовать эмбеддинги

Нет. Retrieval может быть полнотекстовым, структурированным или комбинированным.

Обязательно ли использовать векторную базу

Нет. Векторы можно хранить в разных системах, а сам RAG может работать без векторного поиска.

Запоминает ли модель документы после запроса

Нет. Передача документа в контекст не изменяет параметры модели.

Может ли RAG работать с PostgreSQL

Да. PostgreSQL может быть источником структурированных данных, хранилищем метаданных или векторным индексом при наличии подходящего расширения.

Может ли RAG отвечать без найденных документов

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

Устраняет ли RAG галлюцинации

Нет. Он предоставляет модели более подходящие данные, но ошибки поиска и генерации остаются возможными.

Что важнее: модель или качество поиска

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

Сколько чанков нужно передавать

Универсального числа нет. Оно зависит от размера чанков, задачи, модели и качества ранжирования. Значение нужно выбирать по тестам.

Нужно ли хранить исходный текст

Да. Вектор используется для поиска, но LLM нужен текстовый фрагмент.

Итог

RAG-система состоит не из одной модели и не из одной векторной базы.

Её логика выглядит так:

Источники данных - подготовка - чанки и метаданные - индекс - retrieval - reranking и фильтрация - контекст - LLM - ответ

Главные правила:

RAG - генерация, дополненная найденными данными
Retrieval - поиск информации перед ответом
Чанк - единица индексирования и возврата
Эмбеддинг - числовое представление для сравнения смысла
Индекс - структура для быстрого поиска
Контекст - данные, переданные LLM в текущем запросе
Reranking - повторная оценка найденных кандидатов
Grounded answer - ответ, подтверждаемый предоставленными источниками

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

Качество системы зависит от всей цепочки:

Правильные данные - корректное извлечение - удачный чанкинг - точный поиск - правильный контекст - надёжная генерация

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

Обратная связь

Материал был полезен?

Нашли ошибку или неточность? Сообщить →