Метрики и evals ИИ-функции: что измеряет дизайнер

HEART из статьи Роддена, Хатчинсон и Фу — это пять категорий:

• Happiness (отношение, например опрос по шкале 1–7);
• Engagement (глубина вовлечённости, например визитов на пользователя в неделю);
• Adoption (новые пользователи за период);
• Retention (доля вернувшихся);
• Task success (эффективность, результативность, доля ошибок).

Цепочка Goals → Signals → Metrics: сигналы должны быть чувствительны именно к цели. Метрики нормализуются, потому что «сырые числа растут вместе с базой». И «не всегда уместно брать метрики из каждой категории».

У ИИ-функции есть сигналы, которых нет у обычной: доля результатов, принятых без правок; доля правок и отмен на один результат; доля повторных генераций; доля брошенных после первого результата. Тереза Торрес называет это неявной обратной связью: перегенерация, правка, уточняющий вопрос. Явные оценки «палец вверх / палец вниз» Аман Хан называет очень редкими. Оговорка из DX: acceptance rate — «новые строки кода», годится только для сравнения инструментов и обязан идти в паре с пользой и стоимостью.

Хамел Хусейн и Шрейя Шанкар в Evals FAQ советуют прочитать минимум 100 трейсов и 30 разметить самому до того, как подключать агента. Размечает один эксперт домена как «доброжелательный диктатор». Порядок: открытое кодирование → осевое кодирование в таксономию сбоев → счёт по категориям. В одном кейсе Хусейна три категории объяснили больше 60% проблем.

Бинарная оценка «хорошо / плохо» с письменной критикой управляется лучше, чем баллы. У судьи-модели отдельно измеряются доля верных «плохо» и доля верных «хорошо». Это те же навыки, что в темах «Синтез интервью и качественных данных» и «Проверка гипотез и тест прототипа с ИИ». Коды, темы, счёт по участникам, только вместо интервью — логи.

Anthropic советует начинать с 20–50 задач из реальных сбоев, держать набор сбалансированным («односторонние evals дают одностороннюю оптимизацию»). Ещё — давать судье-модели вариант «не знаю» и читать транскрипты до того, как верить баллам.

Торрес различает четыре типа evals: золотой набор, проверка кодом (пробовать первой), судья-модель (бинарный, откалиброванный), обратная связь клиентов. Её правило: «не давайте вендору определять правильность для вашего продукта».

Готельф пишет, что evals становятся новым PRD, но 94% на evals значит лишь, что функция ведёт себя как задумано в 94% случаев. В определение готовности он добавляет порог, одно предложение на каждый eval о том, какое поведение пользователя он должен изменить, владельца разбора сбоев и дату обновления набора производственными данными. Формула промпта-судьи от Хана: роль судьи → контекст → цель с критерием прошёл / не прошёл → определения терминов. Измерения у него такие: выдумки (использует ли переданный контекст), тон, правильность, релевантность найденного, качество сводки, связность.

Пример из практики Торрес: Interview Coach даёт обратную связь на транскрипты интервью. Она разбирала ошибки по каждому письму; самый частый сбой, который она называет катастрофическим, — наводящие вопросы. Проверки по ключевым словам («обычно», «как правило») плюс судьи-модели на небольшом наборе транскриптов снизили долю общих вопросов примерно с одного из пяти до одного из двадцати пяти.

В проекте Vistaly первый судья ловил все плохие ответы, но больше половины хороших тоже помечал как плохие. Семь итераций правок промпта почти не помогли; помогло изменение оркестрации, а не формулировок. Её вывод: «Нужно сделать анализ ошибок, чтобы вообще понять, что измерять».

«Сплит» — вымышленное приложение из темы «Процесс с ИИ: Double Diamond и Design Sprint». Дизайнер «Сплита» накопил 30 трейсов из беты: фото чека, ответ модели, что сделал пользователь дальше. Второй промпт ниже после открытого и осевого кодирования вернул (пример условный):

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

Рубрика по третьему промпту для измерения «итог сходится»:

• 5 — сумма совпадает с чеком до копейки;
• 3 — расходится на сервисный сбор, пользователь правит одну строку;
• 1 — расходится больше чем на 10% или позиция выдумана.

Флаг «блокирует релиз» — выдуманная позиция.

В HEART-таблице Task success — доля чеков, принятых без правок: целевое значение 70%, порог тревоги 50%. Второй сигнал — доля правок на один чек. Определение готовности по Готельфу: «Eval „итог сходится“ должен сократить долю чеков с правкой суммы с 23% до 10%». Владелец разбора — дизайнер, набор обновляется раз в месяц чеками из продакшена.

Дизайнер делает таксономию ошибок, рубрику качества с якорями, элементы обратной связи в интерфейсе (Изменить, Отменить, Повторить, Настроить из темы «UX-паттерны для ИИ-функций») и парные сравнения двух вариантов ответа. Он не пишет код судьи и не строит инфраструктуру прогонов.

ИИ вредит в четырёх случаях. Судья-модель запущен до того, как человек прочитал трейсы. Балл на evals подаётся как польза для пользователя. Единственная метрика — acceptance rate. Набор проверок не обновляется данными из продакшена.

На этом глава замыкается. Трейсы из продакшена — такой же сырой материал, как отзывы в теме «Рисерч по открытым источникам» и интервью в теме «Синтез интервью и качественных данных». Следующий раунд рисерча начинается с них.

Функция: [название и описание в одну строку]. Пользователи: [сегмент]. По HEART заполни таблицу Goals → Signals → Metrics для Happiness, Engagement, Adoption, Retention и Task success. Укажи, какие категории мы сознательно пропускаем и почему. Метрики только нормализованные: доли и средние на пользователя, не сырые числа. Добавь два сигнала для ИИ: доля правок и отмен на один результат и доля результатов, принятых без изменений. К каждой метрике — целевое значение и порог тревоги

Вход: [число] трейсов функции [название]; каждый трейс — ввод пользователя, переданный контекст, ответ модели, следующее действие пользователя (принял / правил / перегенерировал / ушёл). Фаза 1, открытое кодирование: к каждому трейсу одна-две фразы о том, что пошло не так с точки зрения пользователя. Суди результат, не механизм. Ставь только прошёл / не прошёл. Фаза 2, осевое кодирование: сгруппируй заметки о сбоях в 5–10 категорий; каждой — короткое название, определение, id примера, число. Фаза 3: таблица по убыванию числа с накопленной долей сбоев и столбчатый график кодом на Chart.js. Предложи, какие три категории поймает проверка кодом, а каким нужен судья-модель. Категорию из одного трейса не создавай, если сбой не серьёзный. Напиши, сколько трейсов не смог отнести

Напиши рубрику оценки для [ИИ-функция], которой будут пользоваться люди-рецензенты, а потом судья-модель. Измерения: [например: правильность, опора на переданный контекст, выполнение задачи, тон, соблюдение формата]. Для каждого измерения дай якоря: 5 — полностью соответствует, с конкретным описанием, что есть в ответе; 4 — одно мелкое упущение, которое не меняет следующий шаг пользователя; 3 — пригодно только после правки, укажи какой; 2 — вводит в заблуждение или неполно, пользователь переделывает; 1 — неверно, выдумано или небезопасно. Добавь отдельный флаг "блокирует релиз" со своими критериями (выдуманные факты, нарушение правил), независимый от балла. К каждому измерению — два коротких примера ответов на 5 и на 2. Добавь вариант "не могу оценить" и когда его ставить

Вот наш набор evals для функции [название] и текущий результат [X%]. Напиши определение готовности по Готельфу: порог соответствия в процентах; для каждого eval одно предложение, какое поведение пользователя он должен изменить; кто разбирает сбои; дата, когда набор обновляется данными из продакшена. Отдельно перечисли, чего результат X% не доказывает