Eval как release-критерий: как ловить agent drift до прода, а не после

Проблема

AI-фича, которая работает на демо, ломается в проде непредсказуемо и необъяснимо. Большинство команд узнают это после релиза. Причина — «demo grade»: eval, который одобрил фичу, использовал те же входы, что и питч. Курированный датасет, контролируемые условия. Длинный хвост реального трафика никогда не прогонялся.

Методика

Минимальный eval при релизе — три слоя.

Layer 1 — Regression (non-negotiable). Фиксированный набор reference-кейсов с известным ожидаемым выводом: edge-кейсы прошлых инцидентов, кейсы из демо (которым одобряли фичу), минимум один adversarial-вход на тип вывода (prompt injection, пустой, malformed). Любой новый фейл блокирует релиз.
Пример regression-кейса:
```
# cases/rag-stale-corpus.yaml
id: rag-stale-corpus
origin: incident-2026-03   # RAG галлюцинировал на полном корпусе
input:
  query: "действующая ставка по тарифу X"
expected:
  must_contain:
    - "актуальный документ"
  must_not_contain:
    - "status: archived"
  retrieved_chunks:
    min_count: 1
    must_contain:
      - "active"
    must_not_contain:
      - "archived"
pass_criteria:
  - no_archived_docs
  - answer_grounded
```
Кейс рождается из инцидента (origin) — это и отличает regression set от demo-датасета: входы взяты из того, что уже ломалось в проде.
Layer 2 — Distribution check (RAG/классификаторы). 20–50 свежих реальных входов через новую версию. Проверка не на «идеал», а на diff против снапшота прошлого релиза: распределение длины/формата, изменение retrieved-чанков, сдвиг confidence (сдвиг к краям = хрупкость).
Layer 3 — Human spot-check. Обязателен перед первым проддеплоем нового вида вывода: доменный человек читает 10–20 реальных выводов с конкретными вопросами (нет ли данных, к которым модель не должна иметь доступ; счёл бы эксперт это корректным; нет ли adversarial-эксплуатации).
Owner. Один человек подписывает sign-off. Если перед релизом нельзя назвать владельца — это уже первый тревожный признак.

Артефакт

Минимальный harness под этот чеклист: Python-скрипт, который прогоняет regression set против snapshot и сравнивает distribution (Layer 1 + Layer 2).

github.com/dobryakov/eval-harness — regression + distribution check, adapter interface, demo-кейс из инцидента

Подпись серии

Где ломается

Eval-датасет = demo-датасет — самый частый антипаттерн: «eval» оказывается стейкхолдерским демо, а не измерением.
Pass criteria определены после прогона — «выглядит разумно» вместо конкретного измеримого порога.
Нет owner — sign-off делегируется в «в стейджинге выглядело нормально».
Реальные failure modes, давшие эту методику: RAG корректен на курированном корпусе и галлюцинирует на полном; классификатор тихо деградирует после смены входной схемы upstream; AI-код проходит автотесты, но вносит security-паттерн, который тесты не покрывали.

Для кого и почему

Если вы выпускаете AI-фичи в прод и ещё не выстроили release-gate — это минимальная рабочая методика: три слоя, один owner, sign-off до релиза. Замыкает цепочку после Spec Kit (#12) и cursor rules (#7) — eval проверяет то, что уже ушло в релиз.

Хотите построить eval-процесс для AI-фич в вашей команде?

Постановка eval как release gate: от regression set и distribution check до sign-off процесса. Не теория — воспроизводимая практика с checklists и harness.

Написать на почту

Другие разборы

Серия инженерных разборов: реальная задача → методика → работающий артефакт → честный разбор, где он ломается.

К серии →