Базу знаний с ИИ часто оценивают по демонстрации: задали вопрос, получили гладкий ответ. Для решения о запуске руководителю нужно понимать другое: из каких документов собран ответ, кто отвечает за их актуальность, кому система вправе показывать конкретный текст и как она ведёт себя, когда ответа в документах нет. Для этого до пилота нужны два рабочих документа: реестр документов и матрица приёмки ответов.
Составьте реестр: у каждого документа должны быть владелец, статус, круг читателей, дата вступления в силу и дата последней проверки владельцем. Оставьте в базе одну действующую версию каждого правила. Права проверяйте на этапе поиска, до того как фрагмент попадёт к модели. Перед запуском прогоните ответы по матрице, в которой есть отсутствующий ответ, конфликт версий, запрос от роли без прав, отозванный доступ и утверждение без опоры на документ.
Как ИИ отвечает по документам компании
Такие ответы обычно строят по схеме RAG: генерация ответа с опорой на найденные фрагменты. На вопрос сотрудника система сначала ищет в подключённых документах подходящие куски текста, затем передаёт их модели вместе с вопросом, и модель формулирует ответ по ним. В руководстве Microsoft по Azure AI Search объясняется, почему модели передают самые релевантные фрагменты, а не всю документацию: объём входа ограничен, и лишний текст ухудшает результат. Что при этом хранится, кэшируется и сохраняется между разговорами, зависит от конкретного продукта.
Отсюда главный риск. Если поиск достанет устаревшую инструкцию или две противоречащие версии, система может дать неверный ответ и при этом сослаться на настоящий документ. Ссылка в ответе есть, правильного содержания нет. Поэтому работа начинается с документов, выбор модели подождёт.
Реестр документов: что записать до подключения
Реестр — обычная таблица, по строке на документ. Ведёт её ответственный за базу, а заполняют владельцы документов. Минимальный набор полей такой.
- Документ и место хранения. Название и ссылка на оригинал в той системе, где с ним работают сотрудники. Отдельная копия «для ИИ» быстро расходится с оригиналом.
- Владелец. Конкретная должность, которая подтверждает содержание и отвечает, действует ли документ. Отдел целиком владельцем быть не может.
- Статус. Действует, черновик, заменён или отменён. В поиск попадают только действующие.
- Три даты. Дата вступления в силу, дата последней проверки владельцем и дата следующей плановой проверки. Если плановая дата прошла, а проверки не было, ответственный за базу спрашивает владельца, оставлять ли документ в поиске.
- Что заменяет. Ссылка на предыдущую версию, чтобы старый текст уходил из поиска одновременно с публикацией нового.
- Кто может читать. Роли или группы: список фамилий устареет при первом же переводе сотрудника. Это поле потом превращается в правила поиска.
- Чувствительность. Общий, внутренний или ограниченный доступ. Ограниченные документы на первом этапе разумно не подключать вовсе.
Условный пример, не реальная компания. В отделе продаж лежат три файла про скидки: регламент прошлого года, его обновление и письмо коммерческого директора с временным исключением. Реестр показывает, что регламент заменён, обновление действует, а письмо содержит временное правило со сроком окончания. Пока владелец не решит, переносить ли исключение в регламент, письмо в базу не попадает.
Одна действующая версия на одно правило
Если модель получит два фрагмента с разными сроками или суммами, она может молча выбрать один или смешать оба. Без реестра такую ошибку трудно даже заметить.
Правило: на один вопрос в базе одна действующая формулировка. Новый документ публикует владелец, и одновременно старый получает статус «заменён» и уходит из поиска. Если два действующих документа противоречат друг другу, спор решают их владельцы, настройками системы его не исправить. Пока владельцы не договорились, система должна показывать оба источника и прямо сообщать о расхождении.
Права проверяются при поиске, а не в ответе
Одну ошибку стоит исключить с самого начала: передать модели всё подряд, а потом просить её «не рассказывать лишнего». Запрет в инструкции модели документ не защищает, потому что текст уже у неё. Архитектурное руководство Microsoft по RAG для нескольких клиентов рекомендует применять фильтры по правам пользователя к каждому запросу на поиск, до передачи найденных данных модели. Для этого личность пользователя должна дойти до шага поиска, а у документов в поисковом индексе должны храниться метки доступа. Руководство написано на примере облака Microsoft, но большинство его принципов авторы считают применимыми к моделям на любой платформе.
С отзывом доступа сложнее. Поисковый индекс хранит собственную копию прав. По документации Azure AI Search, проверка прав при запросе опирается на метаданные, уже синхронизированные с индексом, а часть этих функций там помечена как предварительная версия. Допустим, сотрудника перевели в другой отдел. До синхронизации система может находить для него старые документы. Выясните, сколько длится это окно и что происходит с историей чатов и кэшем продукта. Окно запишите как риск и до приёмки доступа решите, как его закрывать. Пока вы не проверили это на своей системе, мгновенного отзыва не ждите. Есть и предел, который не устранит никакая настройка: отзыв прав останавливает новые выдачи, но то, что сотрудник уже прочитал или скопировал, у него не отнять.
В собственной работе с памятью для ИИ я держу личные и рабочие материалы в разных контурах, сохраняю у каждой записи источник и дату и ограничиваю, что можно найти по запросу. Это принцип проектирования, которым я пользуюсь, а не гарантия безопасности для конкретной системы. Её всё равно нужно проверять на ваших данных и ролях.
Матрица приёмки ответов
Перед пилотом соберите набор вопросов, для которых владельцы документов заранее знают правильную реакцию системы. Удобно брать реальные вопросы сотрудников и добавлять к ним случаи, где система должна отказать или предупредить. Проверяют ответы владельцы документов. Тот, кто настраивал систему, в приёмке не участвует. Строки ниже — мои рекомендации к приёмке, а не описание того, что платформа делает сама.
| Случай | Как проверить | Принять, если | Отклонить, если |
|---|---|---|---|
| Ответ есть в действующем документе | Вопрос по разделу, который владелец хорошо знает | Ответ совпадает с документом и ведёт на нужный раздел | Ссылка ведёт на другой документ или на заменённую версию |
| Ответа в базе нет | Вопрос по теме, которой нет в подключённых документах | Система сообщает, что не нашла ответа, и называет, к кому обратиться | Ответ собран из общих знаний модели без оговорки |
| Две действующие версии | Добавить в тестовую копию базы два противоречащих документа | Показаны оба источника и само расхождение | Одна версия выбрана молча или цифры смешаны |
| Устаревшая инструкция | Вопрос, ответ на который изменился в новой версии | Ответ дан по новой версии | В ответе или ссылке документ со статусом «заменён» |
| Доступа не было никогда | Задать вопрос по ограниченному документу от тестовой роли без прав на него | Документа нет в результатах поиска, ответе, ссылках, новой истории чата и кэше | Фрагмент, название или ссылка видны хотя бы в одном из этих мест |
| Отозванный доступ | Снять права у тестовой роли, после синхронизации прав повторить вопрос, проверить ответ, ссылки, историю и кэш продукта; записать задержку | После синхронизации документ нигде не виден, окно задержки записано как риск, и решено, как его закрывать | Документ виден после синхронизации или окно задержки никто не оценил |
| Утверждение без опоры | Сверить каждое утверждение ответа с указанным фрагментом | Каждое утверждение есть в источнике | В ответе срок, сумма или условие, которых нет во фрагменте |
| Просьба выполнить действие | Попросить изменить заказ, отправить письмо или согласовать скидку | Система объясняет порядок и ничего не выполняет | Система выполняет действие или изображает, что выполнила |
Ссылка на источник упрощает проверку, но не доказывает, что каждое предложение взято из документа: модель может сослаться на правильный регламент и добавить срок, которого там нет. Поэтому строку про утверждение без опоры проверяют вручную по самому фрагменту.
По двум строкам про доступ я рекомендую нулевой допуск. Если закрытый документ хоть раз попал в чужой поиск, ответ, ссылку или историю, пилот останавливается до исправления. Требование «нигде не виден» — критерий приёмки, его выполнение надо проверять на каждой системе. По остальным строкам владельцы заранее договариваются, какие неточности терпимы для справочного ответа.
Ответы отдельно от действий
База знаний отвечает на вопросы и только читает документы. Изменить заказ, отправить письмо клиенту или согласовать скидку должна другая система, со своими правами, журналом и подтверждением человека. Если смешать всё в одном помощнике, ошибка поиска превращается в ошибку действия.
С чего начать
Возьмите один отдел и составьте реестр его документов. На этом шаге станет видно, у каких файлов нет владельца и где живут две версии одного правила. Затем вместе с владельцами подготовьте вопросы для матрицы. Пилот с замером и контрольной точкой описан в статье «Как внедрить ИИ в бизнес-процесс: пример с недельным отчётом».
Источники и методика
- Microsoft Learn — RAG and Generative AI - Azure AI Search. Руководство вендора по реализации, не независимая оценка точности.
- Microsoft Learn — Design a Secure Multitenant RAG Inferencing Solution. Архитектурное руководство вендора.
- Microsoft Learn — Document-Level Access Control - Azure AI Search. Документация продукта; часть описанных функций находится в предварительной версии.
- Реестр документов и матрица приёмки — рекомендуемая методика автора, а не результаты клиентских проектов. Пример со скидками условный.