Как проверять ответы помощника по базе знаний компании

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

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

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

Какие вопросы включить в проверочный набор?

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

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

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

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

Почему поиск и ответ проверяют отдельно?

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

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

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

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

По каким критериям оценивать готовый ответ?

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

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

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

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

Как проводить проверку на конкретном примере?

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

Затем ответ разбивают на утверждения: кто согласует документ, при каком условии меняется маршрут и что делать дальше. Каждое утверждение сверяют с источником. Если помощник правильно назвал согласующего, но пропустил условие о сумме, обоснованность может сохраниться, а полнота — нет.

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

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

Что делать с найденными ошибками?

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

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

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

Источники

• Retrieval-Augmented Generation evaluators — Microsoft
• Large language model end-to-end evaluation — Microsoft
• Use metrics to understand RAG system performance — Amazon Web Services