У большой базы знаний есть неприятное свойство. Она хорошо отвечает на вопросы, которые в нее уже положили, и никак не сообщает о вопросах, которых в ней не хватает

Пользователь задает вопрос AI-агенту, RAG не находит подходящего материала, и диалог уходит специалисту. Оператор разбирается и пишет правильный ответ. Через несколько дней приходит другой пользователь с той же проблемой, но для Agent ничего не изменилось. Ответ уже существует внутри компании, просто он остался в истории поддержки

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

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

У нашего AI‑агента поддержки было десять метрик и ноль ответов на главный вопрос: какую долю обращений он решает?

Судья, который читал только текст диалога, ставил 18/20, а проверка по реальным вызовам инструментов давала 8/20. Текстовые проверки считали правдоподобный ответ верным и не могли отличить его от подтвержденного. Самодельный «процент фантомных эскалаций» оказался измерением того, насколько слова бота согласованы с его же внутренними флагами. Каждая метрика что‑то измеряла, и ничего продуктового

Тогда мы решили: оценка качества станет отдельным сервисом с собственным источником истины. В этой статье два переписывания формулы вердикта, несколько пойманных слепот и один эталонный набор, который учил нас доверять неправильным ошибкам.