Golden datasets from production traces

Публичные бенчмарки (MMLU, HumanEval, MT-Bench) отвечают на вопрос «какая модель сильнее в среднем», но молчат о главном: как система ведёт себя на входах ваших пользователей. Golden-датасет — это ваш собственный бенчмарк, и лучший источник для него — продакшен-трейсы: полные записи «вход → контекст → промежуточные вызовы → выход → фидбек». Поэтому первый инфраструктурный шаг — сквозной трейсинг (Langfuse, OpenTelemetry, свой лог): нельзя строить датасет из данных, которые не сохраняются.

Откуда брать кейсы. Самые ценные — трейсы с сигналом сбоя: явный негативный фидбек (палец вниз, низкая оценка), эскалация к живому оператору, повторная переформулировка вопроса (пользователь не получил ответ с первого раза), обрыв сессии сразу после ответа. Отдельно — кейсы из error analysis прошлого урока: каждая категория ошибки должна быть представлена в датасете. И обязательно happy path: без него датасет проверяет только патологии и не заметит, когда сломается основной сценарий.

Целевая структура: датасет отражает реальное распределение трафика по сегментам, но с перевзвешенными хвостами. Если billing-вопросы — 10% трафика, но 40% инцидентов, их доля в датасете должна быть ближе ко второй цифре. Golden-датасет — это не случайная выборка, а стратифицированный портрет того, что для продукта важно не сломать.

Практичный формат — JSONL: одна строка — один кейс, легко диффать в git и стримить в раннер. Минимальная схема:

{"id": "case-0142",
 "input": {"question": "Можно ли вернуть заказ через 40 дней?", "locale": "ru"},
 "expected": {"must_contain": ["30 дней"], "must_not": ["вернём деньги"], "reference": "Возврат возможен в течение 30 дней с момента доставки."},
 "metadata": {"source_trace": "tr_8a91f3", "segment": "billing", "difficulty": "edge", "added": "2026-07-01", "incident": "INC-217"}}

Поле expected намеренно составное: жёсткие ограничения для код-ассертов (must_contain, must_not) плюс reference для reference-based judge. Поле metadata.segment — ключ стратификации: pass rate считается и по датасету целиком, и по каждому сегменту, иначе усреднение спрячет провал целой категории.

Гигиена набора. Дедупликация: близкие переформулировки одного вопроса раздувают вес этого сценария — считайте эмбеддинги и склеивайте пары с косинусной близостью выше ~0.95. Размер: для старта достаточно 50–200 кейсов на задачу; важнее покрытие категорий ошибок, чем объём. И железное правило регрессионных кейсов: каждый продакшен-инцидент превращается в кейс с ссылкой на инцидент в metadata — такие кейсы обязаны проходить на 100%, это выученные ошибки, которые нельзя повторять.

Кейсы из трейсов приходят без эталонных меток — их создают люди, и здесь два системных решения. Первое: бинарные метки вместо шкал. Шкала «оцени от 1 до 10» кажется информативнее, но даёт низкое согласие между разметчиками: один ставит 6, другой 8 за тот же ответ, и никто не знает, где порог деплоя. Бинарный вопрос «приемлем ли ответ для отправки пользователю: да/нет» плюс обязательная категория ошибки при «нет» — быстрее, воспроизводимее и напрямую конвертируется в pass rate.

Второе: согласие нужно измерять, а не предполагать. Дайте двум разметчикам общую подвыборку в 30–50 кейсов и посчитайте каппу Коэна: κ = (p_o − p_e) / (1 − p_e), где p_o — наблюдаемая доля совпадений, p_e — ожидаемая при случайном угадывании с теми же частотами меток. Ориентиры: κ ≥ 0.8 — отличное согласие, 0.6–0.8 — рабочее, ниже 0.4 — метки фактически случайны. Низкая каппа почти всегда означает не «плохих разметчиков», а дырявые guidelines: люди по-разному понимают, что такое «приемлемо».

Лечение — итерация guidelines: разберите каждое расхождение, допишите в инструкцию явное правило с примером pass и fail, переразметьте спорную партию. Полезна роль «benevolent dictator» — один владелец качества (обычно PM или доменный эксперт), чьё слово решает спорные кейсы, чтобы дискуссии не блокировали датасет неделями.

Датасет — такой же артефакт, как код: он живёт в git или в датасет-хранилище (Langfuse datasets) с иммутабельными версиями, и каждый eval-отчёт фиксирует, на какой версии получен. Иначе числа несравнимы: «pass rate вырос с 82% до 91%» ничего не значит, если между прогонами в датасет добавили лёгких кейсов.

Две утечки, которые обесценивают эвал. Первая — прямая: примеры из few-shot секции промпта попадают в eval-сет, и система «сдаёт экзамен по шпаргалке». Проверяйте пересечение датасета с промптом автоматически. Вторая — тоньше: синтетические кейсы, сгенерированные той же моделью, которая работает judge, смещают оценку в её пользу — модель благосклонна к собственным формулировкам. Синтетику генерируйте другой моделью и обязательно прогоняйте через человеческое ревью.

Третья угроза — hill-climbing на тест-сете: если вы десятки раз подряд тюните промпт по одному и тому же датасету, вы постепенно переобучаетесь на него — метрика растёт, продакшен нет. Решение из классического ML: сплит dev/holdout. По dev-набору итерируетесь ежедневно, holdout прогоняете редко — перед релизом или сменой модели. Наконец, продакшен дрейфует: раз в квартал сверяйте распределение сегментов датасета с живым трафиком и пополняйте набор свежими трейсами, иначе golden set постепенно превращается в музей прошлогодних проблем.