Evaluation and data

После главы вы сможете построить eval harness, который отличает хороший текст от правильного trajectory и фактического business outcome.

Evals — центральный feedback loop

Без eval set любое изменение prompt/model/tool — демонстрация, а не эксперимент. Evals одновременно открывают путь в Applied ML: dataset design, splits, leakage, precision/recall, calibration и drift.

Словарь eval

Термин	Значение
Task/case	Input, environment и expected properties
Trial	Один stochastic run системы на task
Transcript	Наблюдаемая последовательность messages/actions
Trajectory	Структурированные decisions/tools/events
Outcome	Финальное состояние environment
Grader	Функция/модель/человек, ставящий score
Harness	Запускает trials, изолирует environment, собирает evidence
Suite	Versioned набор cases и rubrics

Anthropic использует похожее разделение transcript/outcome/harness и подчёркивает комбинацию code-, model- и human-graders. Это provider guidance, совпадающее с общей testing methodology: Demystifying evals for AI agents.

Почему final text недостаточен

Agent пишет: «Возврат выполнен». Возможны три случая:

1. refund_escrow успешно изменил ledger — outcome правильный.
2. Tool не вызван — hallucinated success.
3. Tool вызван с другим account/amount — убедительная, но опасная ошибка.

Helios OutcomeGrader требует terminal reason, expected text property и успешный required tool outcome. TraceGrader отдельно проверяет order событий.

Grader taxonomy

Code-based

Schema, exact field, DB state, unit test, policy invariant. Дёшево и воспроизводимо; плохо оценивает open-ended communication.

Model-based judge

Rubric-based relevance, empathy, completeness. Масштабируется, но имеет собственные bias, variance и prompt/model drift.

Human

Gold standard не появляется автоматически: annotators расходятся, устают и интерпретируют rubric по-разному. Нужны training examples, adjudication и agreement measurement.

Обычно outcome проверяется кодом, UX/semantic quality — calibrated judge/human, security invariants — code/policy/red-team suite.

Multiple trials

Один удачный run скрывает stochastic failures. Запускайте N trials и сообщайте:

• pass rate и число cases/trials;
• confidence/uncertainty;
• distribution latency/cost;
• worst-case и failure taxonomy;
• seed/model/prompt/tool versions;
• per-case результаты, а не только average.

pass@k и majority voting отвечают другим вопросам, чем pass rate одного production attempt. Не выбирайте метрику только потому, что она выше.

Judge calibration

1. Соберите human-labeled calibration set.
2. Зафиксируйте rubric с positive/negative examples.
3. Сравните judge с human labels: confusion matrix, precision/recall по важному failure class.
4. Разберите systematic disagreement.
5. Введите abstain/manual review для uncertain cases.
6. Версионируйте judge model/prompt.

Высокая agreement на easy cases не доказывает качество на редких safety failures.

Dataset sampling

Production sample должен покрывать:

• обычные высокочастотные cases;
• high-risk rare cases;
• разные channels/languages/tenants;
• tool failures/timeouts;
• approval/rejection;
• adversarial/injection cases;
• regressions из incident history.

Random sample оценивает среднюю частоту. Stratified/risk sample помогает найти редкие ошибки, но его score нельзя выдавать за production prevalence без weighting.

Leakage и contamination

• Один user/entity не должен попадать одновременно в train и test.
• Prompt/tool developer не должен оптимизироваться на hidden benchmark labels.
• Judge не должен видеть expected answer в input по ошибке.
• Synthetic variants одного template не создают независимые cases.
• Production feedback после релиза отделяется от frozen regression set.

Для ML lab используются group/entity splits и fixed seed.

Regression, benchmark, online monitoring

Suite	Цель	Как меняется
Regression	Не вернуть известную ошибку	Добавляется после incidents
Capability benchmark	Сравнить системы на стабильной шкале	Редко, versioned
Safety/adversarial	Найти violation boundary	Обновляется вместе с threats
Online monitoring	Обнаружить drift/incident	Continuous sampled signals

Не превращайте regression suite в training set, где система запомнила exact phrases и не обобщает.

Data flywheel

trace/outcome → failure taxonomy → sampled case → de-identification
→ human label → offline eval → targeted change → shadow/canary
→ monitored outcome → new hard cases

В regulated support назначьте data purpose, access и retention до выгрузки. PHI/PII не должен копироваться в local fixtures; de-identification не исключает re-identification risk.

Варианты

Решение	Выигрыш	Цена	Когда плохо
End-to-end only	Реалистичный outcome	Трудно локализовать	Быстрый component iteration
Component evals	Диагностика	Не ловят interactions	Release gate в одиночку
LLM judge only	Быстро для semantics	Bias/variance/cost	Money/safety outcome
Human only	Богатый judgment	Медленно/дорого	Каждый commit
Layered graders	Coverage и диагностика	Harness complexity	Самый ранний prototype

Helios fixtures

В capstone три cases: order status, escrow refund, restricted cargo. JSON fixture независимо задаёт tenant/thread/budget, точный model script, optional approval, ожидаемый final answer и domain outcome. Каждый trial получает новый store, registry, policy и domain fixture, проходит настоящий DurableExecution, а grader читает реальные events и структурированный outcome, возвращённый domain repository через tool. Поэтому убедительный заранее записанный ответ без refund_escrow тест не проходит. Для production money-flow этого всё ещё мало: там отдельный grader должен перечитать ledger/source of truth после run, а не доверять одному tool response.

npm run test:course:pattern -- "eval case|domain outcome"

Self-check

• Какой environment outcome считается успехом?
• Сколько trials нужно для решения и почему?
• Где judge откалиброван на human labels?
• Есть ли entity leakage?
• Как sampling влияет на интерпретацию score?
• Разделены ли frozen benchmark и growing regressions?
• Какие traces можно безопасно превратить в dataset?