ОК или НеОК как мы строили LLM судью и дважды меняли формулу вердикта

У команды разработчиков был AI-агент поддержки, который оценивался по десяти разным метрикам, но ни одна из них не отвечала на главный вопрос: какую долю обращений бот действительно решает? Проблема обнаружилась при сравнении двух способов проверки. Судья, который читал только текст диалога, ставил агенту 18 баллов из 20, а проверка по реальным вызовам инструментов давала лишь 8 баллов. Текстовые проверки считали правдоподобный ответ верным и не умели отличать его от подтвержденного действия. Самодельный показатель «процент фантомных эскалаций» тоже оказался бесполезным: он измерял лишь то, насколько слова бота согласованы с его внутренними флагами, а не реальную пользу для пользователя.

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

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