Как проверить FAQ-бота на вопросы, которых нет в базе знаний

Обычный тест FAQ-бота часто состоит из десяти вопросов, ответы на которые уже лежат на первой странице базы знаний. Такой тест показывает, что система умеет находить очевидное. Он не отвечает на более важный вопрос: что произойдёт, когда клиент попросит то, чего в базе нет, перепутает два тарифа или потребует действие, на которое бот не уполномочен. Ниже — способ проверить именно границу знания. Он подходит и для простого поискового помощника, и для системы с генеративной моделью, но критерии успеха будут немного разными.

1. Сначала запишите область полномочий

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

Сохраните версию базы знаний и дату теста. Иначе после обновления статьи вы не сможете понять, почему вчерашний ответ отличался от сегодняшнего. Если материалы составлены из PDF и Markdown, сначала приведите их к стабильному виду. Порядок подготовки исходного документа есть в обзоре Pandoc; проверку ошибок извлечения текста удобно начать с обзора Tesseract.

2. Соберите неочевидную выборку

Возьмите по пять примеров из каждой группы. Первая — точный вопрос, ответ на который есть в базе. Вторая — разговорная формулировка того же смысла с опечаткой или сокращением. Третья — вопрос на стыке двух документов, где важна дата или версия тарифа. Четвёртая — вопрос, на который достоверного ответа вообще нет. Пятая — запрос на действие за пределами полномочий. В сумме получается 25 проверок; это не статистически исчерпывающая оценка, но хороший старт для ручного разбора.

Не подсказывайте модели правильный документ в тестовом запросе. Клиент не пишет «посмотри пункт 4.2 актуальной инструкции» — он спрашивает «если курьер не пришёл, куда писать?». Именно так и нужно формулировать часть выборки. Личные данные замените условными: номер заказа 000123, вымышленное имя, несуществующий адрес. Отдельно держите реальные инциденты, если политика вашей команды разрешает их использовать после обезличивания.

3. Оцените не только правдивость текста

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

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

4. Разберите причину, а не переписывайте все промпты

Ошибку полезно отнести к одному из четырёх источников. Документа нет вообще. Документ есть, но извлечён неверно. Поиск вернул не тот фрагмент. Модель получила правильный фрагмент, но сделала необоснованный вывод. Лечение у этих случаев разное. Добавить пример ответа в промпт не поможет, если тарифная таблица испорчена при OCR. Замена модели не исправит дубли двух противоречивых версий правил. Начинайте с исходного факта и маршрута его доставки в ответ.

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

FAQ

Сколько запросов достаточно для запуска?

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

Считать ли уточняющий вопрос ошибкой?

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

Что делать с вопросом вне базы?

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

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