Бот техподдержки отвечает сотрудникам сам, а качество его ответов проверяет вторая нейросеть. Она сверяет каждый ответ с эталонной таблицей примерно из 100 вопросов, выставляет оценку по весам и ловит просадку раньше, чем её заметят люди. Так качество держится на уровне 93%, а обновление модели или базы знаний перестаёт быть рулеткой.
Мы собрали такого бота для крупной инженерной компании из промышленной автоматизации и энергетики, с потоком в тысячи обращений в месяц. Бот живёт в коробочном Битрикс24 внутри контура клиента, отвечает из базы знаний, заводит заявки. И у него есть отдельный контролёр качества, который тоже работает на локальной модели.
Почему ответам бота нельзя верить на слово
Языковая модель не даёт одинаковый ответ на один и тот же вопрос дважды. Пока бот отвечает на пару десятков запросов, за ним можно приглядывать вручную. На тысячах обращений в месяц это невозможно: никто не будет читать выборку ответов каждый день и решать, стал бот отвечать хуже или нет.
Проседать качество может незаметно. Поменяли базовую модель на более свежую - и она вдруг хуже понимает внутренние формулировки. Обновили статью в базе знаний - и бот начал доставать из неё не тот кусок. Снаружи всё выглядит рабочим: бот бодро отвечает, ссылки на задачи отдаёт. А доля неверных ответов тихо растёт, и первым это чувствует сотрудник, которому бот дал ерунду.
Ручное тестирование эту дыру не закрывает. Прогнать полтора десятка вопросов после каждого изменения руками - долго и субъективно. Один инженер сегодня оценит ответ как приемлемый, завтра как слабый. Нужна проверка, которая идёт сама и по одним и тем же правилам.
Нейросеть-судья: ИИ, который проверяет ИИ
Рядом с ботом мы поставили вторую модель - судью. У неё одна работа: оценивать, насколько хорошо бот ответил. Судья берёт эталонную таблицу примерно из 100 пар "вопрос - правильный ответ", прогоняет через бота вопросы и сравнивает то, что он выдал, с эталоном.
Оценка идёт по весам. Не все вопросы одинаково важны: где-то критично попасть в точную формулировку регламента, где-то достаточно верного смысла. Веса задают, что важнее, и итоговая оценка складывается из них, а не из простого числа совпадений. На выходе - понятная цифра качества, которую можно смотреть после каждого изменения.
Эта цифра держится на уровне 93%. Это не разовый замер для презентации - судья пересчитывает оценку регулярно и показывает просадку сразу.
Что это заменяет и от чего страхует
Первое - судья снимает ручное тестирование. Раньше проверку качества делали бы люди: сидели и читали ответы. Теперь это делает модель, по фиксированному набору вопросов и по одним правилам. Оценка воспроизводимая: прогнали до изменения, прогнали после, сравнили две цифры.
Второе - судья страхует от деградации при обновлениях. Смена базовой модели и правка базы знаний становятся безопасными: перед тем как выкатить изменение в работу, мы прогоняем эталонную таблицу и смотрим, не упала ли оценка. Упала - откатываемся или разбираемся, что именно сломалось. База знаний у клиента синхронизируется автоматически, статьи меняются часто, и без такого контроля каждое обновление было бы риском вслепую.
Живая обратная связь поверх судьи
Судья ловит системные просадки, но у бота есть и второй слой контроля - от самих людей. На ответ бота можно поставить реакцию: палец вверх или палец вниз. Реакции ставит доверенный круг сотрудников, и каждая уходит в лог на доработку.
Слои ловят разное. Судья видит, что оценка по таблице просела - повод разбираться с моделью или базой. Живые реакции показывают конкретные ответы, которые не понравились людям на реальных вопросах, которых в эталоне может и не быть. Лог накапливает такие случаи, и по нему видно, какие темы стоит докрутить или добавить в эталонную таблицу.
Отдельно бот собирает оценки за закрытые заявки. После того как задачу закрыли, он просит поставить оценку до 5 звёзд и по желанию оставить комментарий. Средняя оценка сотрудников - 4,5 из 5, и её можно смотреть по исполнителю, шаблону заявки или периоду.
Зачем это нужно бизнесу
Бот берёт на себя тысячи обращений в месяц: 40% вопросов закрываются прямо из базы знаний, без заявки, а первый ответ приходит мгновенно вместо прежнего ожидания до 10 часов. Когда объём такой, доверять качеству на глаз нельзя - один незамеченный сбой в модели бьёт сразу по многим сотрудникам.
Судья превращает качество ответов из "вроде работает" в измеримую цифру, за которой можно следить и которую можно защищать при каждом обновлении. Это и есть снятый риск: бот меняется и учится, а планка качества остаётся под контролем.
Если вы думаете про бота техподдержки или другого ИИ-помощника внутри компании, начните с вопроса, кто и как будет проверять его качество на потоке. Мы разберём вашу задачу и покажем, как выстроить такую проверку в вашем контуре - оставьте заявку на диагностику.
