Как внедрить RAG-систему в компании: данные, доступы, качество и первый релиз

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

Если цель звучит как «добавить AI», невозможно определить качество и границу первой версии.

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

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

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

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

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

Так команда видит, какой компонент улучшать: разбиение документов, поиск, промпт или модель.

Начните с режима assist: пользователь видит ответ, источники и может сообщить об ошибке. Добавляйте автоматическое действие только после проверки качества и владельца процесса.

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

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

Определите, какие ответы запрещены, какие источники обязательны и что происходит при конфликте документов. Эти правила должны быть частью acceptance criteria, а не рекомендацией для промпта.

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

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

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

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

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

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

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

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

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

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

Система обязана уметь сказать «в источниках недостаточно данных» и показать, чего именно не хватает. Уверенный ответ без опоры опаснее пустого результата, особенно для внутренних регламентов и финансовых документов.

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

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

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

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

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

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