Как подготовить базу знаний для RAG и проверить ответы

Сначала определите вопросы и авторитетные документы

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

RAG не заменяет обучение модели и не исправляет качество исходных данных. В материале об обучении локальной нейросети показано, что fine-tuning нужен для повторяемого поведения и формата, тогда как поиск по базе подставляет актуальные сведения во время запроса. Сначала составьте перечень задач: например, ответы по гарантийным условиям, поиск требований к заявке и объяснение статусов заказа. Для каждой задачи запишите, какие документы считаются авторитетными, кто их обновляет, какая версия действует и что система должна делать при отсутствии ответа. Такой реестр превращает набор файлов в управляемый источник.

Очистите корпус и сохраните версии

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

Разделяйте документ по смыслу, а не вслепую

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

Добавьте метаданные для фильтров и проверки

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

Ограничьте выдачу релевантным контекстом

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

Рабочий пример: база правил магазина

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

Проверяйте поиск отдельно от генерации

Проверяйте конвейер по этапам. Сначала оцените retrieval: присутствует ли нужный фрагмент среди результатов, не вытеснен ли он похожим, но устаревшим текстом, соблюдены ли фильтры доступа. Затем оцените генерацию: основан ли каждый существенный вывод на найденном контексте, дан ли ответ на все части вопроса, нет ли лишних утверждений. Microsoft разделяет такие измерения на groundedness, completeness, utilization, relevance и correctness. Эти показатели нельзя сводить к одной красивой цифре: требования зависят от задачи, а один и тот же запрос может давать разные формулировки.

Диагностируйте уровень ошибки

Если ответ неверен, сначала найдите уровень ошибки. Нужный документ отсутствует — исправьте состав корпуса. Документ есть, но не найден — проверьте разбиение, метаданные, модель представления запроса и ранжирование. Фрагмент найден, но важное исключение потеряно — увеличьте смысловую целостность блока или свяжите соседние части. Контекст правильный, а вывод ошибочен — уточните инструкцию ответа и требование ссылаться на основание. Такой разбор полезнее бесконечной замены промпта, потому что отделяет проблему поиска от проблемы генерации.

Не превращайте документы в скрытые инструкции

Защита корпуса является частью качества. Не загружайте документы только потому, что к ним есть технический доступ: сначала проверьте права, конфиденциальность и аудиторию. Удалите секреты и лишние персональные сведения, настройте фильтры доступа до выдачи фрагментов. Содержимое документа нельзя автоматически считать инструкцией для модели: в нём могут оказаться встроенные команды или вредоносный текст. Microsoft рекомендует отделять данные от инструкций и учитывать атаки через индексируемый контент. Изменения базы должны журналироваться, чтобы ошибочную версию можно было обнаружить и исключить.

Зафиксируйте критерии готовности

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