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

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

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

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

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

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

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

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

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

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

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

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