Урок 0001 · Evals как процесс

С чего начинается любой разговор про AI system design: как ты строишь eval-ы. Это твой главный сигнал на раунде.

1. Три уровня eval (Hamel)

Источник: Hamel — Your AI Product Needs Evals.

«Сначала assertion’ы как тесты. Потом смотрю трейсы и только на повторных ошибках пишу судью. A/B — когда офлайн уже не отличает варианты.»

2. Error analysis раньше метрик

1. Сэмпл 50–100 реальных (или синтетических, прогнанных через систему) трейсов.
2. На каждый — свободная заметка: первый важный фейл, не корневая причина.
3. Сгруппировать (axial coding), посчитать частоты.
4. Eval пишешь на топ-3 повторных фейла, не на «helpfulness».

Generic-метрики (helpfulness / coherence / hallucination score) — чужой промпт под пятью слоями абстракции, они не ловят твой продукт.

Пример: как выглядит error analysis на реальных трейсах каре-бота

Трейс 1 — первый важный фейл: устаревшая версия документа.

Пользователь: «Сколько дней рассматривают заявку на кредит?»
Бот: «До 5 рабочих дней».   ← а в политике с марта уже 7 дней

Заметка в open coding: «ответил по старой версии политики». Категория при axial coding: stale document version.

Трейс 2 — первый важный фейл: ответ не по правам доступа.

Пользователь: «Какой лимит у карты 5290…?»  ← чужой номер
Бот: «Лимит 100 000 MXN».  ← назвал данные чужой карты

Заметка: «выдал данные по чужой карте». Категория: PII / access leak.

Трейс 3 — первый важный фейл: не тот скилл.

Пользователь: «Заблокируйте мою карту, я её потерял».
Бот: «Вот правила использования карт…»  ← вместо вызова тула блокировки

Заметка: «ответил текстом вместо действия». Категория: wrong skill (FAQ вместо tool).

После 100 трейсов считаешь частоты: 30× stale document, 25× wrong skill, 15× PII leak, 10× формат, 20× мелочи.

Топ-3 фейла → три бинарных eval-а (ниже). Это и есть «eval пишется на повторные фейлы, не на helpfulness».

Пример: бинарные eval-ы, которые пишутся из этого разбора

Eval 1 — версия документа (код, без LLM):

PASS если: ответ не противоречит актуальной версии политики
(сверка даты/значения с текущим документом)

Eval 2 — права доступа (код):

PASS если: account_id в ответе == account_id авторизованного клиента
ИЛИ ответ вообще не содержит account-данных

Eval 3 — правильный скилл (LLM-judge, binary):

Вопрос: «Запрос требовал действия (блокировка, перевод, лимит)?
Бот вызвал соответствующий тул или эскалировал человеку?»
PASS/FAIL. Критика 2–4 предложения.

Каждый судья калибруется на 30–80 человеческих метках: TPR/TNR на holdout, не accuracy.

Источники: Field Guide, FAQ.

3. Почему accuracy судьи врёт

Судья — это классификатор. Классификатор меряется TPR/TNR, не accuracy.

Допустим, фейлов в проде 5%. Судья, который всегда говорит «ок»:

• accuracy = 95% (потому что 95% случаев он прав по умолчанию);
• TPR = 0% (не поймал ни одного фейла);
• TNR = 100% (ничего не зарубил ложно).

Вывод: судью меряют на holdout против человеческой разметки, считая TPR/TNR и confusion matrix.

Источник: Eugene Yan — Evaluating LLM-Evaluators.

4. Как строить LLM-as-judge

1. Один судья = один критерий, binary pass/fail, не «поставь 1–5».
2. Разметить 30–80 примеров человеком (домен-эксперт, «benevolent dictator»).
3. Судью мерить TPR/TNR против этой разметки на holdout. Few-shot — только из train.
4. Сильная модель на судью, дешёвая — в прод, если задача позволяет.
5. Перекалибровка: criteria drift — критерии рождаются, когда смотришь новые выходы.

Подробный протокол и промпт-скелет — в уроке 0006 и конспекте 03.

5. Квадрант «где дыра»

Ответ на вопрос «почему бот отвечает плохо?». Две оси: recall (поиск нашёл материал?) и faithfulness (модель отвечает по нему?). В каждой клетке — свой рычаг починки.

Пример для каждой клетки (вопрос: «какая комиссия за перевод в другой банк?», верный ответ: «SPEI — 2%»):

• Левая верхняя: поиск вернул кусок про «комиссию за обслуживание» (мусор), модель приписала «2%» из головы. Двойная поломка: индекс мусорный + модель не умеет отказываться.
• Правая верхняя: кусок «SPEI: 2%» лежал в контексте, модель ответила «1.5%» — проигнорировала. Поиск ни при чём: чини промпт (жёстче «только по контексту») или T=0.
• Левая нижняя: кусок не нашёлся вообще, но модель честно сказала «не знаю, перевожу на оператора». Модель молодец — вся проблема в поиске: чанкинг, эмбеддинги, BM25, реранкер.
• Правая нижняя: кусок найден, ответ «2%» по нему. Техника идеальна — если юзер недоволен, это продукт: тон, формат, UX, скорость.

Идеи клеток — из Evidently (retrieval vs generation раздельно), Hamel FAQ (сначала retrieval, потом generation) и Jason Liu (лог chunk_ids). Вид таблицы — приём для доски.

Проверь себя