RAG по базе знаний: как отвечать с опорой на документы
Практическая схема RAG для внутренней базы: подготовка документов, поиск фрагментов, ссылки на источник, оценка пропусков и контроль прав доступа при каждом вопросе.
RAG сначала находит относящиеся к вопросу фрагменты базы знаний, затем передаёт их модели для ответа. Польза появляется только если поиск приносит нужный документ, права доступа соблюдены, а ответ позволяет проверить конкретный источник.
Почему просто загрузить всю базу недостаточно
Справка продукта меняется: старые тарифы, новые правила возврата, разные инструкции для сотрудников и клиентов. Если отправить модели весь архив, она может смешать версии или выбрать устаревший абзац. RAG уменьшает контекст до найденных фрагментов, но добавляет собственный риск: нужный фрагмент может не попасть в выборку. Тогда даже очень сильная модель ответит по неполному основанию.
Представьте вопрос «Можно ли вернуть товар после вскрытия?» В базе есть общая политика, исключение для определённой категории и старая статья поддержки. Хороший поиск должен поднять действующие документы и показать версию. Если он возвращает только общую политику, красивый ответ модели будет неверен для исключения.
Подготовьте документы для поиска
Храните заголовок, раздел, версию, дату действия и уровень доступа вместе с текстом. Разбивайте материал по смысловым границам: правило и его исключение не стоит разводить в разные фрагменты без связи. Таблицы лучше превращать в читаемое представление с заголовками столбцов. Иначе поиск найдёт число, но потеряет, к чему оно относится.
Удалите дубликаты и явно пометьте устаревшие версии. Переиндексируйте документ после редакции и проверьте, что старая копия не остаётся первым результатом. Вопросы доступа решайте до передачи фрагментов модели: сотрудник без права видеть внутренний тариф не должен получить его через поисковую подсказку.
От найденного фрагмента к ответу
Векторные представления помогают находить близкие по смыслу тексты, а поиск по словам ловит точные коды и названия. Официальные руководства OpenAI описывают embeddings и retrieval как основу семантического поиска. Это возможный инструмент, а не обязательное свойство каждого LLM API. Если используете Kvantora для генерации, наличие конкретной операции embeddings проверяйте отдельно по текущему каталогу и документации.
Соберите вопросы с известными ответами и отметьте правильный документ для каждого. Измерьте, попал ли он в первые результаты. Если нет, правьте разбиение, метаданные и поиск. Настройка подсказки генератора не исправит отсутствие источника во входе. Сохраните и отрицательные вопросы, на которые база не отвечает.
Передайте найденные фрагменты с названием документа и указателем на раздел. Попросите ответить только по ним и вернуть ссылку на основание. Если сведения противоречат друг другу, ответ должен назвать конфликт и отправить вопрос человеку. Не просите модель заполнить пробел общими знаниями, если пользователю нужен официальный ответ вашей компании.
В интерфейсе показывайте проверяемую ссылку, вместо одного внутреннего номера фрагмента. Ссылка должна вести к версии, которую можно открыть с правами пользователя. Если документ позже изменится, полезно хранить использованную версию для расследования старого ответа.
Поиск обязан соблюдать права до генерации
Если сотрудник спрашивает о тарифе другого клиента, запрет должен сработать на стадии retrieval. Нельзя сначала вложить закрытый фрагмент в подсказку, а затем попросить модель «не разглашать». Доступный набор документов определяется подтверждённым пользователем и его ресурсами. Генератор получает только разрешённые фрагменты. Проверьте это отрицательным тестом с двумя похожими документами разных клиентов.
Ссылки в ответе тоже проходят проверку доступа. Даже если текст не раскрыт, заголовок закрытого документа может быть чувствительным. В журнале RAG сохраняйте идентификаторы разрешённых источников и версию индекса, чтобы расследовать неверный ответ, но не выводите скрытые фрагменты в общий лог. Так поиск остаётся полезным инструментом, а не обходным каналом к базе знаний.
Испытайте поиск и генерацию раздельно
Для каждого вопроса сначала посмотрите найденные фрагменты без модели. Есть ли там нужное правило и исключение? Затем оцените ответ на этих фрагментах. Такая двухступенчатая проверка позволяет понять источник ошибки: плохой поиск, смешение версий или неверное чтение текста. Общая метрика «ответ понравился» этой причины не покажет.
Добавьте вопросы с опечаткой, названием старого продукта, отсутствующим документом и конфликтом двух статей. Попросите человека из поддержки проверить, можно ли по приложенным ссылкам подтвердить ответ. Если нет, система пока годится для черновика, а не для автоматического утверждения клиенту.
Не все вопросы требуют векторного поиска. Если человек вводит точный номер документа или артикул, обычный поиск по идентификатору может быть надёжнее и дешевле. Смешивайте методы по наблюдаемым ошибкам, а не по моде на embeddings. В тестовом наборе держите и смысловые вопросы, и точные коды, чтобы улучшение одного типа не скрывало потерю другого.
Расход и обслуживание базы
Каждый найденный фрагмент увеличивает вход модели. Чем больше контекст, тем выше потенциальный расход и шум. Сравните качество при разном числе фрагментов и учитывайте стоимость обновления индекса. Длинное окно модели не отменяет поиска, если база большая, часто меняется или разделена правами.
После запуска следите за вопросами без ответа, ложными ссылками и устаревшими документами. RAG: не разовая загрузка файлов, а поддерживаемый информационный процесс. Владелец базы должен знать, когда правило меняется и кто отвечает за его публикацию. Модель не сможет сделать достоверным источник, который сама команда не поддерживает.