Оценка LLM: практичный плейбук для продакшен-агентов

Каждая команда, с которой мы говорим, в какой-то форме прогоняет LLM-evals. Большинство делает это неправильно. Обычно проблема не в модели — проблема в измерении. Вот плейбук оценки LLM, который мы гоняем на каждом продакшен-агенте — без частей, которые красиво звучат на конференциях.

Начни с golden-сета, не с метрики

Первый артефакт любой LLM-оценки — 40 вручную отобранных примеров, представляющих форму вашего трафика. Не 400, не 4 000 — 40. Мало, чтобы человек мог реально прочитать их, достаточно, чтобы ловить регрессии категории. Каждый всплывающий в продакшене баг уходит в golden-сет.

Сорок примеров помещаются в один вечер чтения. В этом и ограничение, и смысл: набор, который никто не читает, перестаёт описывать продукт и превращается в число на дашборде.

Кто владеет eval-харнессом

Харнесс принадлежит инженерам, которые выкатывают агента, а не отдельной команде качества. Ролик ниже — студия, где эта работа и живёт.

Трёхслойная модель скоринга для LLM-агентов

Мы оцениваем каждый ответ агента в три слоя. Жёсткие ограничения — вызвал ли нужный tool, валиден ли output по схеме. Корректность — для проверяемых задач, действительно ли ответ правильный. Суждение — оценила ли вторая модель ответ как usable. Слои не взвешиваются: провал на любом — это провал.

Когда прекратить eval и начать слушать продакшен

Больше eval — не всегда лучше. Когда агент проходит golden-сет >95%, следующая регрессия почти наверняка придёт из категории, которую вы не предсказали. Это точка, в которой надо перестать добавлять покрытие и начать добавлять телеметрию из продакшена.