Курация golden dataset для evals

Тебе нужно собрать golden dataset для агента {{agent_purpose}}. Уже есть {{current_size}} кейсов. Цель — не «больше тестов», а репрезентативный набор, по которому можно принимать решения о релизе.

1. Что такое «golden» и чем не является

Golden dataset — это набор пар (input, expected), которые:

• Зафиксированы вручную (или человеком проверены)
• Хранятся под версионным контролем
• Используются как арбитр при изменениях промта / модели / tools

Это не:

• Логи продакшен-сессий без чистки (там шум, PII, дубли)
• «Тестовый сценарий пользователя» (это integration test)
• Набор случайных запросов (нерепрезентативно)

Golden = «вот эти случаи мы обязаны проходить».

2. Категории (что должно быть)

Сбалансированный dataset включает 5 категорий. Соотношение примерно 40/25/20/10/5 по категориям ниже:

Happy path (40%)

Самые частые типичные запросы. Если они ломаются — пользователи это сразу видят.

• Простые случаи в основной зоне применения
• Понятный input, понятный expected output

Edge cases (25%)

Граница допустимого:

• Пустой input
• Очень длинный input (10x от типичного)
• Спецсимволы, не-ASCII, RTL, эмодзи
• Несколько форматов одного и того же (даты, числа, валюты)
• Многоязычный input (если поддерживается)

Regression cases (20%)

Конкретные баги которые когда-то были — и не должны вернуться.

• Каждый поступивший в продакшен инцидент → 1 кейс
• Имя кейса включает ссылку на incident-id

Antagonistic / adversarial (10%)

Намеренно сложные:

• Двусмысленные формулировки
• Попытки prompt injection (для safety-агентов)
• Противоречащие требования
• Запросы вне зоны (агент должен сказать «не моя задача»)

Future-fit (5%)

Случаи, которые мы хотим уметь через 1-2 квартала. Сейчас они могут проваливаться — это ОК, фиксируем как «aspirational».

3. Формат хранения

Один файл — один кейс. Каталог в репо:

evals/
  golden/
    happy/
      001-summarize-short-article.yaml
      002-extract-action-items.yaml
    edge/
    regression/
      042-incident-2026-04-18-pii-leak.yaml
    antagonistic/
    aspirational/

Каждый файл:

id: 042
category: regression
linked_incident: INC-2026-04-18
created: 2026-04-19
updated: 2026-05-12
input:
  prompt: |
    ...
  context_files: [optional]
expected:
  must_include: ["X", "Y"]
  must_not_include: ["secret_key", "<script>"]
  format: json
  schema_ref: schemas/summary.v2.json
grading:
  type: rubric | exact | judge
  rubric:
    - "Содержит main_topic"
    - "Не больше 3 bullet"
    - "Без ссылок на личные данные"
  weight: 1.0
notes: |
  Был баг где агент включал email в summary.

YAML потому что:

• читается git-diff
• хорошо мержится
• человеку видно в PR

4. Версионирование через git

• Dataset живёт в репо рядом с промтом
• Каждое изменение dataset — отдельный PR
• В PR — обязательно объяснение «почему этот кейс добавлен / изменён»
• Tag релиза: evals-v2026.05.17 — фиксирует версию для воспроизводимости

Принцип: dataset версионирован отдельно от промта. Иначе нельзя ответить «промт стал лучше или хуже» — менялись оба.

5. Метрики (что мерить)

Минимальный набор на каждый прогон:

Регрессия = pass rate упал ≥ 2 п.п. по сравнению с baseline.

6. Grading — три варианта

Правило: сначала exact, потом rubric, judge — последнее средство.

Если используешь judge — фиксируй модель и промт судьи (тоже в git). И прогоняй judge-calibration: 50 кейсов с human-grade и judge-grade, считай korreлацию ≥ 0.85.

7. Как обновлять без подгонки

Самый частый провал: команда подгоняет dataset под промт, чтобы pass rate был высокий. Так нельзя.

Правила:

• Меняешь промт → запускаешь старый dataset. Не подгоняешь dataset.
• Новый кейс добавляется когда: реальный инцидент в проде / реальный edge / новая фича. Не «потому что промт его не прошёл».
• Старый кейс удаляется ТОЛЬКО если: фича удалена / поведение намеренно изменено (с записью в CHANGELOG dataset).
• Любое изменение existing кейса → PR с объяснением и старая версия в git history.
• Раз в квартал — «freeze test»: прогон случайной выборки 30 кейсов вручную, чтобы убедиться что grading не разъехался с реальностью.

8. Объём и плотность

Грубо:

• Старт — 30-50 кейсов (хватает чтобы ловить очевидные регрессии)
• Зрелый — 200-500 кейсов (баланс между сигналом и стоимостью прогона)
• Свыше 500 — дробление на suite (smoke / full / nightly), иначе прогон становится узким горлом

Если один прогон стоит > $10 — введи smoke set (50 кейсов) для каждого PR и full nightly.

9. Анти-паттерны

• ❌ Dataset из логов прода без чистки и согласия — PII + смещение к частым кейсам
• ❌ 90% happy path, 10% всего остального — pass rate растёт, ценность падает
• ❌ Менять и dataset, и промт в одном PR — нельзя оценить влияние
• ❌ Использовать judge без calibration и без фиксированного промта судьи
• ❌ Удалять «упавший» кейс чтобы pass rate был зелёным
• ❌ Кейс без явного expected — невозможно автоматизировать grading
• ❌ Hold-out нет — модель «зубрит» dataset, в проде проваливается
• ❌ Игнорировать flake rate — 5-10% флакающих кейсов отравляют все решения
• ❌ Dataset вне git — не воспроизвести историю
• ❌ Пара десятков фичей, пара десятков кейсов — недостаточно для статистики

На выходе

• Структура каталога evals/golden/...
• 30-50 стартовых кейсов с распределением по 5 категориям
• Документ «политика изменения dataset» (10-15 строк)
• Конфиг прогона + 6 метрик
• Если judge — calibration-отчёт