Как построить в команде систему оценки качества LLM-продукта?

Question

Accepted Answer

Оценка — инфраструктура, как тесты в CI. Набор примеров из реальных запросов и найденных ошибок, разбитый по сценариям; проверки по правилам там, где возможно, и калиброванный судья для свободного текста; прогон при каждом изменении промпта, модели, поиска с порогами, блокирующими выкатку; онлайн-метрики и регулярный ручной разбор, из которого набор пополняется. Метрики по сценариям, а не одна средняя — иначе регресс в редком сценарии не виден Судью калибруют по разметке людей и перепроверяют при смене модели судьи Владелец набора и правила его пополнения — иначе он устаревает Цель — скорость: команда меняет промпты и модели уверенно, потому что видит последствия Уровни: 1. Юнит-проверки: формат, вызов нужного инструмента, обязательные ссылки — детерминированно и дёшево. 2. Офлайн-набор: сотни примеров по сценариям, метрики поиска и ответа, сравнение с базовой версией. 3. Онлайн: сигналы пользователей, бизнес-метрики, A/B. 4. Разбор: еженедельный просмотр выборки и неудачных диалогов. Процесс: - каждый баг из продакшена превращается в пример набора; - отчёт прогона показывает изменения по сценариям и конкретные ухудшившиеся примеры; - пороги в CI: резкое падение метрики блокирует выкатку; - стоимость прогона учитывается: полный набор — по ночам, малый — на каждый PR. Ловушки: переобучение промпта под набор, утечка примеров набора в промпт, слепая вера судье, одна усреднённая метрика.

Как построить в команде систему оценки качества LLM-продукта?

Подробно

Что хотят услышать

Связанные вопросы

Подсказки на собеседовании — в реальном времени