47 / QUALITY ENGINE / MEASURE SYSTEM BEHAVIOR ACROSS CONTROLLED TASKS

EVALS.

Evals — систематические оценки AI-системы — это набор задач, scorers и процедур сравнения, которые измеряют качество системы не на одном красивом примере, а на контролируемом распределении типичных, сложных, граничных и критичных кейсов.

00. ARCHITECTURAL STATUS

EVALS — ОСНОВА УПРАВЛЯЕМОГО РАЗВИТИЯ AI-СИСТЕМЫ

Evals не являются request-time reasoning-механизмом. Это преимущественно offline/design-time Quality Engine, который проверяет модели, prompts, routing, tools, RAG, memory, Skills и целую architecture.

TYPECOREНужен любой системе, которую планируется улучшать.

DEFAULTOFFLINEНе запускается целиком на каждом request.

ENABLE WHENCHANGE / RELEASE / FAILUREНовая версия, новая модель, regression, optimization experiment.

SEPARATE COMPONENTYESDataset + scorer + runner + results store.

LIVES INR08Quality Engine.

COMPLEXITYLOW → HIGHНачать с небольшого representative set.

IMPLEMENT: YES / EARLY

Минимум 80% ценности: 50–200 representative cases для ключевых task classes, deterministic scorers где возможно, небольшой regression set из production failures, baseline/candidate comparison и versioned results. Не нужен огромный benchmark center.

01A. ARCHITECTURE BOUNDARIES & OPERATIONS

EXPLICIT SYSTEM CONTRACT

Evals отвечают за controlled measurement of system behavior across versioned task sets.

A. BOUNDARY WITH NEIGHBORS

Evals измеряют систему; №40 Eval-Driven Optimization использует результаты Evals, чтобы выбирать и подтверждать изменения. №45 проверяет один request/result; Evals — набор задач. №46 фиксирует runtime telemetry; Evals запускают controlled cases и scorers. №48 задаёт policy boundaries; Evals проверяют их соблюдение. №92 измеряет marginal contribution; eval suite — среда измерения.

B. PREREQUISITES / CROSS-REFERENCES

Prerequisites: №40, №45, №46. Foundations: №23, №34, №39. Future references: №84, №92, №94 — implementation/detail references, не обязательные prerequisites.

C. PLANE PLACEMENT

REQUEST-TIME RUNTIME: NO. OFFLINE / DESIGN-TIME: YES, основное место. CONTROL PLANE: YES — release gates и сравнение экспериментов. DATA PLANE: INDIRECT — traces/cases могут питать datasets, runner не входит в критический request path. LIVES IN: R08 Quality Engine.

D. FAILURE & OPERATIONS CONTRACT

Success: воспроизводимый run, зафиксированные dataset/scorer/system versions, scores всех required cases, segment/regression results и объяснимое baseline-vs-candidate решение. Retryable: transient timeout, runner/worker или external dependency failure. Permanent: malformed case, broken scorer, missing artifact, incompatible schema/version, invalid dataset config.

Idempotency/state: stable eval_run_id/version отличает rerun; сохраняются dataset/scorer/system versions, case/segment results, errors, cost/latency и release decision. Metrics: duration, cost, segment pass/fail, scorer disagreement, regressions, flaky rate, failure reasons. Security: redaction/access/retention для production-derived data; secrets не хранятся в cases; adversarial cases — untrusted input.

E. WHAT THIS TOPIC DOES NOT OWN

Evals не владеют request-time verification (№45), production tracing (№46), optimization loop (№40), policy enforcement (№48), model serving (№70), business KPI framework (№84–94) или всей release infrastructure. Они отвечают за CONTROLLED MEASUREMENT OF SYSTEM BEHAVIOR ACROSS VERSIONED TASK SETS.

01. MASTER MAP

DATASET → RUNNER → SCORERS → SEGMENTS → DECISION

EVALSMEASURE SYSTEM BEHAVIOR

DATASETtasks / expected properties

RUNNERexecute baseline/candidate

SCORERSrules / tests / judge / human

DECISIONship / reject / investigate

REGRESSIONwhat got worse

SEGMENTStask / risk / domain / path

BASELINEcurrent known system

HOLDOUTunseen generalization check

Dataset

Контролируемый набор задач.Inputs, expected properties, metadata, segment labels.

Baseline

Текущая версия для сравнения.Без baseline delta неинформативна.

Runner

Воспроизводимо запускает configuration.Model/prompt/router/tool versions fixed.

Scorers

Определяют quality.Deterministic first, semantic where necessary.

Segments

Разбивают average score.Risk, language, task family, modality, model route.

Regression

Показывает ухудшения.Critical segment can veto release.

Holdout

Проверяет generalization.Не оптимизировать бесконечно на одном наборе.

Decision

Результат eval влияет на release/optimization.Иначе eval — просто отчёт.

02. EVALS VS VERIFICATION

REQUEST-TIME QUALITY GATE И OFFLINE BENCHMARK — РАЗНЫЕ СЛОИ

VERIFICATION / #45

One result

candidate
  ↓
schema?
evidence?
constraints?
tool outcome?
  ↓
PASS / REVISE /
FAIL / UNCERTAIN

Работает внутри конкретного runtime.

EVALS / #47

Many controlled tasks

dataset
  ↓
system version A
system version B
  ↓
scores
segments
regressions
cost
  ↓
compare

Измеряет system behavior статистически/системно.

Verification — sensor одного результата. Evals — испытательный стенд всей системы.

03. EVAL DATASET

ХОРОШИЙ НАБОР — НЕ RANDOM СПИСОК PROMPTS

TYPICAL

Representative

Основной production traffic

Частые реальные task families и input shapes.

Должен отражать business distribution.

FAILURE

Regression Cases

Известные production failures

Каждая серьёзная исправленная ошибка становится тестом на будущее.

Самый ценный растущий слой.

EDGE

Boundary

Граничные условия

Empty, huge, contradictory, unusual formats, rare combinations.

Ищет brittle behavior.

HIGH-RISK

Critical

Редкие, но дорогие ошибки

Нарушение permissions, wrong side effect, unsupported material claim.

Может иметь release veto.

ADVERSARIAL

Stress

Провокационные и misleading cases

Conflicts, bad evidence, injection-like content, deceptive tool output.

Не должен вытеснять normal traffic cases.

NOVEL

Generalization

Новые комбинации

Проверяет способность не просто запомнить benchmark patterns.

Особенно важно после optimization/fine-tuning.

04. CASE RECORD

ЧТО ДОЛЖНО БЫТЬ В ОДНОМ EVAL CASE

Task

{
  "case_id": "EV47-118",
  "task_type": "claim_verification",
  "input": {...},
  "risk": "medium"
}

Expected

{
  "must_include": ["evidence_refs"],
  "must_not": ["unsupported_claim"],
  "expected_tool": "research"
}

Metadata

{
  "segment": ["research","pdf"],
  "source": "production_failure",
  "difficulty": 3,
  "created_at": "..."
}

Scorers

[
  "schema_pass",
  "evidence_coverage",
  "task_success",
  "cost"
]

Eval case должен содержать проверяемые ожидания, а не только «вот prompt, посмотрите ответ глазами».

05. SCORER STACK

КАК МЕРИТЬ КАЧЕСТВО

Scorer	Когда нужен	Надёжность
Exact match / parser	IDs, labels, exact fields	Очень высокая
Schema validator	Structured outputs/contracts	Очень высокая
Rule / constraint checker	Policies, business rules, invariants	Очень высокая при верной формализации
Code / unit tests	Executable outputs	Очень высокая
Evidence coverage	Research/factual answers	Высокая при хорошей claim mapping
LLM judge	Semantic quality, style, usefulness	Средняя, требует calibration
Human expert	Golden set/high-risk/calibration	Высокая, но дорого
Business outcome	Production effectiveness	Высокая ценность, сложная attribution

Не использовать LLM judge для того, что можно проверить детерминированно.

06. LLM-AS-JUDGE

ПОЛЕЗНЫЙ, НО НЕ БЕЗОШИБОЧНЫЙ ИЗМЕРИТЕЛЬ

Good use

clarity
completeness
semantic relevance
trade-off quality
style adherence

Weak use

exact arithmetic
schema validity
real tool success
current factual truth
formal constraints

Calibration

compare judge
against:
human labels
objective checks
known positives
known negatives

Bias control

randomize order
hide system identity
normalize verbosity
use clear rubric
track disagreement

LLM judge способен предпочитать более длинный или уверенный ответ. Поэтому rubric и calibration обязательны.

07. RUBRICS

SCORER ДОЛЖЕН ЗНАТЬ, ЧТО ИМЕННО СЧИТАЕТСЯ ХОРОШИМ

CORRECT

Correctness

Правильность содержания/действия.

COMPLETE

Coverage

Все ли required parts присутствуют.

GROUNDED

Evidence

Поддержаны ли factual claims.

SAFE

Constraints

Нет ли hard violations.

USEFUL

Task Value

Решает ли output реальную исходную задачу.

Одна vague инструкция «оцени от 1 до 10» даёт слабую воспроизводимость. Лучше несколько конкретных критериев.

08. SEGMENTATION

СРЕДНЕЕ ЗНАЧЕНИЕ МОЖЕТ СКРЫТЬ КРИТИЧЕСКИЙ REGRESSION

Global

baseline:
0.87

candidate:
0.89

looks better

Segments

simple:    +0.04
research:  +0.03
tool-use:  +0.02
high-risk: -0.11

Decision

global ↑
but high-risk ↓

release:
BLOCK
or narrow rollout

Useful segments

task_type
risk
language
modality
model_route
tool_path
context_size
source_type

Для зрелой системы segment score часто важнее общего average.

10. REGRESSION SUITE

КАЖДАЯ СЕРЬЁЗНАЯ ОШИБКА ДОЛЖНА УСЛОЖНЯТЬ ЕЁ ПОВТОРЕНИЕ

INCIDENT

Production failure

agent ignored
one hard constraint

root cause:
state field omitted
from context

REGRESSION

Permanent eval case

case:
same failure pattern
+ variants

expected:
constraint never violated

future releases:
must pass

Так система превращает ошибки в durable quality memory, даже без fine-tuning.

11. EVALS FOR AGENT TRAJECTORIES

ОЦЕНИВАТЬ НУЖНО НЕ ТОЛЬКО FINAL ANSWER

Что оценивать	Пример	Почему важно
Final task success	Задача реально выполнена	Главный end-to-end outcome
Tool selection	SQL выбран вместо calculator	Wrong path может случайно дать plausible answer
Evidence path	Использованы релевантные источники	Нужна groundedness
Replans/retries	Не было бессмысленных loops	Efficiency/reliability
Escalation	Strong model вызван только когда нужен	Adaptive cost
Side effects	Action выполнен один раз и с approval	Operational safety
State consistency	Runtime state соответствует фактам	Long-horizon reliability

Для agent systems часто нужен trajectory eval + outcome eval, а не только оценка текста в конце.

12. OFFLINE VS ONLINE EVALS

LAB И PRODUCTION ДАЮТ РАЗНЫЕ СИГНАЛЫ

OFFLINE

Controlled

fixed cases
reproducible runs
known scorers
baseline comparison
cheap iteration

Лучший слой для release gates и experiments.

ONLINE

Production

real traffic
real latency
real users
business outcome
unexpected cases

Нужен для проверки distribution shift и реальной ценности.

Offline eval не заменяет production telemetry; online outcome не заменяет контролируемый regression suite.

13. EVALS VS NEIGHBORS

ЧТО НЕ НУЖНО ПУТАТЬ

Пара	Evals	Соседнее понятие
Evals ↔ Verification	Dataset-level measurement across system versions	Request-time check одного result
Evals ↔ Observability	Controlled quality measurement	Telemetry реальных runs
Evals ↔ Eval-Driven Optimization	Измерительный механизм	№40 использует evals, чтобы менять систему
Evals ↔ Benchmark	Может быть internal, dynamic, task-specific	Benchmark часто фиксированный публичный набор
Evals ↔ Feedback	Заранее заданные/curated test signals	Feedback приходит из interaction/outcome
Evals ↔ Metrics Dashboard	Генерирует quality results	Dashboard визуализирует metrics/results

14. BENCHMARK OVERFIT

ЧЕМ ЧАЩЕ СМОТРИШЬ НА ОДИН НАБОР, ТЕМ МЕНЬШЕ ОН ПОХОЖ НА TEST

Problem

same 100 cases
used for:
prompt tuning
router tuning
model selection
skill changes
every week

Result

dev score ↑

production score:
flat

because:
system adapted
to benchmark

Controls

dev set
holdout
fresh samples
production failures
periodic refresh
synthetic variants

Rule

do not optimize
forever
against
the same visible
test set

Eval dataset — измерительный прибор. Его тоже нужно защищать от overfitting.

15. MINIMUM VIABLE IMPLEMENTATION

80% ПОЛЬЗЫ БЕЗ EVAL PLATFORM

1 — start small

50–200
important cases

not:
10,000 random prompts

2 — mix

typical
known failures
edge
critical
small adversarial set

3 — score

objective scorers
first

semantic judge
only where needed

4 — compare

baseline
candidate
segments
cost
regressions
decision

Обычный Python runner + JSON/CSV/PostgreSQL уже достаточен. Ценность создаёт quality discipline, а не интерфейс платформы.

16. PRACTICAL RESULT RECORD

КАК ХРАНИТЬ EVAL RUN

Run

{
  "eval_run": "ER47-88",
  "dataset": "core-agent-v12",
  "system_version": "runtime-v31",
  "baseline": "runtime-v30"
}

Scores

{
  "task_success": 0.918,
  "schema_pass": 0.992,
  "evidence_score": 0.903,
  "cost_per_success": 1.41
}

Segments

{
  "research": +0.04,
  "tool_use": +0.01,
  "high_risk": -0.02
}

Decision

{
  "status": "BLOCKED",
  "reason":
    "high_risk regression",
  "next":
    "investigate segment"
}

17. FAILURE MODES

КАК EVALS ЛОМАЮТСЯ

FAIL 01

Demo Set

Eval состоит из красивых примеров, где система заведомо сильна.

FAIL 02

Judge Everything

Все критерии отданы одному LLM judge, даже когда возможны objective checks.

FAIL 03

No Segments

Global average скрывает critical regression.

FAIL 04

Train/Test Leakage

Cases, на которых оптимизировали prompt/model, считаются независимым test.

FAIL 05

No Versioning

Непонятно, какой dataset/scorer/system config породил score.

FAIL 06

Metric Theater

Score публикуется, но не влияет на release, rollback или optimization decisions.

18. METRICS FOR THE EVAL SYSTEM

КАК ИЗМЕРЯТЬ САМИ EVALS

Метрика	Что показывает	Желаемый эффект
Production Correlation	Связан ли eval score с реальным production quality	Высокая
Regression Detection Rate	Ловит ли suite реальные regressions до release	Растёт
Scorer Agreement	Совпадает ли automated scorer с trusted human/objective labels	Высокое
Coverage by Task Segment	Какие важные зоны представлены	Без критичных gaps
Fresh Case Rate	Добавляются ли новые production failures/distribution shifts	Стабильно
False Release Rate	Сколько releases прошли eval, но ухудшили production	Снижается
Eval Cost	Цена полного suite	Контролируется через tiers/sampling

19. DESIGN RULES

ПРАВИЛА ДЛЯ EVAL ARCHITECTURE

Новая production ошибка

После root-cause fix добавить её family в regression suite.

FAILURE → TEST

Можно проверить formal rule

Deterministic scorer, не LLM judge.

OBJECTIVE FIRST

Average score растёт

Проверить task/risk/model/tool segments отдельно.

SEGMENT

Один eval set используется слишком долго

Holdout + fresh production samples + periodic refresh.

ANTI-OVERFIT

Candidate лучше на 1%

Сравнить стоимость, latency, critical violations и practical significance.

WHOLE FRONTIER

Eval score ни на что не влияет

Связать suite с release/rollback/optimization gates.

ACTIONABLE

20. FINAL SUMMARY

ГЛАВНАЯ МЫСЛЬ

EVALS
НЕ ОЗНАЧАЮТ:

"У НАС ЕСТЬ
100 PROMPTS
И СРЕДНИЙ SCORE"

ОНИ ОЗНАЧАЮТ:

REAL SYSTEM GOALS
      ↓
TASK DISTRIBUTION
      ↓
BUILD DATASET:
  TYPICAL
  FAILURES
  EDGE
  HIGH-RISK
  ADVERSARIAL
  NOVEL
      ↓
DEFINE
EXPECTED PROPERTIES
      ↓
CHOOSE SCORERS:
  EXACT
  SCHEMA
  RULES
  TESTS
  EVIDENCE
  LLM JUDGE
  HUMAN
  BUSINESS OUTCOME
      ↓
FREEZE VERSIONS
      ↓
RUN BASELINE
      ↓
RUN CANDIDATE
      ↓
COMPARE:
  QUALITY
  HARD VIOLATIONS
  COST
  LATENCY
  TRAJECTORY
      ↓
SEGMENT:
  TASK
  RISK
  LANGUAGE
  MODALITY
  MODEL ROUTE
  TOOL PATH
      ↓
REGRESSION?
  ├─ YES → BLOCK / INVESTIGATE
  └─ NO
      ↓
   HOLDOUT?
      ├─ FAIL → OVERFIT
      └─ PASS
          ↓
       RELEASE DECISION
          ↓
       PRODUCTION
          ↓
       NEW FAILURES
          ↓
       ADD REGRESSION CASES
          ↺

VERIFICATION:
IS THIS RESULT ACCEPTABLE?

EVALS:
HOW DOES THIS SYSTEM
BEHAVE ACROSS TASKS?

OBSERVABILITY:
WHAT ACTUALLY HAPPENED
IN PRODUCTION?

EVAL-DRIVEN OPTIMIZATION:
WHAT SHOULD WE CHANGE
BASED ON THE RESULTS?

THE CORE PRINCIPLE:

YOU CANNOT
SYSTEMATICALLY IMPROVE
WHAT YOU CANNOT
RELIABLY MEASURE.

GOOD EVALS
TURN AI DEVELOPMENT
FROM
"SEEMS BETTER"
INTO
"MEASURABLY BETTER,
ON THESE TASKS,
AT THIS COST,
WITH THESE RISKS."

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION

Scope: Evals remain the deterministic evidence gate for skills, memory, instincts, hooks, adapters and optional cognitive mechanisms. Context is a bounded cache; durable evidence lives in registries/artifacts.

Hooks/contracts: use POST_MODEL, POST_TOOL, TASK_COMPLETED, FAILURE and MEMORY_CONSOLIDATION; schemas are illustrative and provider-neutral.

Security/task profiles: host-side enforcement, scoped memory, feature flags and MINIMAL/STANDARD/STRICT enforcement remain independent from FAST/STANDARD/DEEP modes. No learned rule bypasses policy or evals.

Ablation: every optional mechanism is tested WITH/WITHOUT and measured by quality, acceptance, correction, cost, latency, escalation and severe errors. See the ECC retrofit specifications.

EVALS.

EVALS — ОСНОВА УПРАВЛЯЕМОГО РАЗВИТИЯ AI-СИСТЕМЫ

EXPLICIT SYSTEM CONTRACT

DATASET → RUNNER → SCORERS → SEGMENTS → DECISION

REQUEST-TIME QUALITY GATE И OFFLINE BENCHMARK — РАЗНЫЕ СЛОИ

One result

Many controlled tasks

ХОРОШИЙ НАБОР — НЕ RANDOM СПИСОК PROMPTS

Representative

Regression Cases

Boundary

Critical

Stress

Generalization

ЧТО ДОЛЖНО БЫТЬ В ОДНОМ EVAL CASE

Task

Expected

Metadata

Scorers

КАК МЕРИТЬ КАЧЕСТВО

ПОЛЕЗНЫЙ, НО НЕ БЕЗОШИБОЧНЫЙ ИЗМЕРИТЕЛЬ

Good use

Weak use

Calibration

Bias control

SCORER ДОЛЖЕН ЗНАТЬ, ЧТО ИМЕННО СЧИТАЕТСЯ ХОРОШИМ

Correctness

Coverage

Evidence

Constraints

Task Value

СРЕДНЕЕ ЗНАЧЕНИЕ МОЖЕТ СКРЫТЬ КРИТИЧЕСКИЙ REGRESSION

Global

Segments

Decision

Useful segments

ПРАВИЛЬНАЯ СХЕМА СРАВНЕНИЯ

КАЖДАЯ СЕРЬЁЗНАЯ ОШИБКА ДОЛЖНА УСЛОЖНЯТЬ ЕЁ ПОВТОРЕНИЕ

Production failure

Permanent eval case

ОЦЕНИВАТЬ НУЖНО НЕ ТОЛЬКО FINAL ANSWER

LAB И PRODUCTION ДАЮТ РАЗНЫЕ СИГНАЛЫ

Controlled

Production

ЧТО НЕ НУЖНО ПУТАТЬ

ЧЕМ ЧАЩЕ СМОТРИШЬ НА ОДИН НАБОР, ТЕМ МЕНЬШЕ ОН ПОХОЖ НА TEST

Problem

Result

Controls

Rule

80% ПОЛЬЗЫ БЕЗ EVAL PLATFORM

1 — start small

2 — mix

3 — score

4 — compare

КАК ХРАНИТЬ EVAL RUN

Run

Scores

Segments

Decision

КАК EVALS ЛОМАЮТСЯ

Demo Set

Judge Everything

No Segments

Train/Test Leakage

No Versioning

Metric Theater

КАК ИЗМЕРЯТЬ САМИ EVALS

ПРАВИЛА ДЛЯ EVAL ARCHITECTURE

ГЛАВНАЯ МЫСЛЬ

ECC RETROFIT / PRACTICAL HARNESS INTEGRATION