ИИ для базы знаний компании: как проверить ответы

ИИ для базы знаний компании стоит проверять на вопросах, у которых заранее известны правильный ответ, действующий документ и права сотрудника. Убедительный текст со ссылкой ещё не означает, что помощник нашёл нужное правило, сохранил исключения и использовал актуальную редакцию. Для приёмки нужны отдельные проверки этих условий.

Что проверять в ответе по базе знаний

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

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

На приёмке задавайте пять вопросов:

1. Найден ли документ, который действительно отвечает на вопрос?
2. Подтверждает ли выбранный фрагмент каждое существенное утверждение?
3. Сохранены ли исключения, сроки и условия применения правила?
4. Действует ли эта редакция документа сейчас?
5. Разрешено ли этому сотруднику видеть документ и сведения из него?

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

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

Какие документы подготовить для проверки

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

Для каждого документа составьте короткую карточку:

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

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

Как собрать вопросы для приёмки

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

Предлагаем начать с таких групп. Это рабочая заготовка для пилота, без универсального требования к числу вопросов.

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

Полезная строка журнала выглядит так: вопрос → роль сотрудника → ожидаемый источник → найденный фрагмент → ответ → вердикт → причина ошибки. Сведения в журнале тоже могут быть закрытыми: доступ к нему должен соответствовать содержимому.

Пример: две редакции одного регламента

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

Редакция 1, отменена: «Закупку оборудования стоимостью до 50 000 рублей включительно согласует руководитель отдела».

Редакция 2, действует: «Закупку оборудования стоимостью до 30 000 рублей включительно согласует руководитель отдела. Свыше 30 000 рублей закупку согласует финансовый директор. Срочную закупку согласуют по тому же порядку».

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

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

Если помощник пишет «правила нет», спросите, что подтверждает этот вывод. Неудачный поиск означает лишь, что система не нашла ответ в доступных материалах. Формулировка «в доступных документах не нашёл срока; уточните у владельца регламента» точнее и не отменяет существование других источников.

Как проверить обновление документов и права доступа

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

Проверка новой редакции:

1. Сохраните ответ и ссылку до изменения документа.
2. Измените условное правило в тестовом источнике, отметьте прежнюю редакцию как отменённую.
3. Зафиксируйте время изменения и согласованный срок обновления поиска.
4. После этого срока повторите вопрос. Проверьте число, условия и ссылку на действующую редакцию.
5. Если ответ старый, зафиксируйте сбой обновления и верните его исполнителю до запуска этого сценария.

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

Проверка доступа:

1. Создайте безопасный тестовый документ с вымышленными сведениями и ограничьте его чтение выбранной ролью.
2. Задайте одинаковый вопрос пользователю с доступом и пользователю без доступа.
3. Проверьте текст ответа, цитаты, ссылки и заголовки документов: запрещённые сведения не должны раскрыться через них.
4. Отзовите доступ у первого пользователя и повторите проверку после предусмотренного срока обновления прав, включая новый разговор.
5. Согласуйте отдельно, что происходит с уже сохранённой историей переписки. Удаление права читать исходник не стирает автоматически сведения из старых ответов.

В Azure AI Search доступ может проверяться по метаданным разрешений в индексе. Документация отдельно указывает зависимость от синхронизации этих метаданных. Это пример устройства конкретного сервиса; механизм вашей системы нужно выяснить у исполнителя и проверить испытанием.

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

Как разбирать ошибки и принимать решение о запуске

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

В рекомендациях Anthropic по уменьшению выдуманных ответов есть два применимых приёма: разрешать модели признавать недостаток информации и проверять утверждения по подтверждающим цитатам. Эти меры снижают риск ошибки, но не устраняют его полностью.

Для пилота можно использовать такую инструкцию поведения:

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

Этот текст задаёт желаемое поведение. Он сам по себе не обеспечивает права доступа и не заменяет испытания.

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

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

Что передать подрядчику перед пилотом

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

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

Начните с одного подразделения и проверьте помощника на его вопросах. Если источник нельзя привести в порядок или никто не готов разбирать спорные ответы, запуск стоит отложить до решения этих задач. Общий состав проекта и ответственность сторон разобраны в статье о разработке ИИ-агентов.

Источники

• Microsoft Learn: раздельная оценка поиска и ответов RAG.
• Claude: указатели на фрагменты документов в ответах.
• Claude: приёмы уменьшения выдуманных ответов.
• Microsoft Learn: контроль доступа к документам при поиске.
• Microsoft Learn: актуальность данных и обновление индекса.

Документация проверена 12 октября 2026 года. Проверочный пример с закупками составлен для этой статьи; он не описывает внутренние правила или результаты клиентов ИНОБО.