Проблема текстовой оценки
При использовании ИИ-агента поддержки стандартные метрики не давали ответа на главный вопрос: какую долю обращений он решает на самом деле? Текстовый судья, анализирующий только диалог, ставил 18/20, в то время как проверка по реальным вызовам инструментов показывала лишь 8/20. Проблема заключалась в том, что текстовая проверка считала правдоподобный ответ верным, не имея возможности отличить его от подтвержденного фактами.
Первая попытка создать Judge заключалась в использовании модели, которая просто выдавала категорию исхода (решено, не решено, передано человеку и т. д.). Однако такой подход оказался нестабильным: модель не могла одинаково считать количество проблем в одном и том же диалоге, из-за чего процент решенных задач постоянно «плавал».
Переход к структурным сигналам
Чтобы сделать оценку объективной, разработчики перешли от модели «прочитай и скажи исход» к вычислению вердикта по формуле. Оценку разделили на два типа сигналов. Структурные сигналы (вызов инструмента, эскалация, запрос данных) считаются программным кодом. Семантические сигналы (подтверждение утверждений источниками, полнота ответа) оцениваются с помощью LLM. Формула над этими сигналами дает итоговый вердикт, а ошибки в проверках служат объяснением причин.
На этапе отладки выяснилось, что Judge не видел важных данных: вызовы инструментов и результаты их работы лежали в других каналах, не доступных модели. После объединения всех каналов данных (текст, вызовы инструментов, результаты и фрагменты базы) точность системы выросла. Коэффициент согласия (каппа Коэна) увеличился с отрицательных значений до 0,75 на эталонном наборе, что позволило полностью отказаться от использования «холистического» (целостного) судьи в пользу формулы.
Смена критериев: корректность вместо результата
Второй этап трансформации был вызван сменой бизнес-задачи. Оказалось, что вопрос «решена ли проблема пользователя» — плохой критерий для оценки агента, так как на результат влияет множество внешних факторов: ошибки бэкенда, молчание пользователя или необходимость перевода на человека. Вместо этого Judge стал оценивать не факт решения проблемы, а корректность действий агента согласно инструкции.
Это изменило логику вердиктов: теперь корректный запрос недостающих данных или оправданная передача оператору стали считаться положительным исходом. В итоге система научилась замечать критическую ошибку: когда агент сообщает о выполнении действия, но в системном трейсе отсутствует соответствующий вызов инструмента. После внедрения детерминированного сигнала на такие случаи точность совпадения с оценками операторов выросла с 44% до 69%.