Обновление промпта или новая версия модели часто приводят к скрытой регрессии. Публичные бенчмарки вроде MMLU измеряют общую эрудицию, но не показывают, как модель справляется с вашим конкретным трафиком. Golden Eval Dataset (золотой набор для оценки) закрывает этот пробел: это курируемая выборка реальных запросов пользователей с проверенными ожидаемыми ответами, которая запускается перед каждым деплоем.
В отличие от A/B тестов, которые измеряют бизнес-метрики, Golden Set проверяет безопасность изменений. Это регрессионный тест для поведения модели, где ожидаемый результат — это не просто строка, а экспертная оценка качества.
01Почему продакшен-данные лучше синтетики
Синтетические данные создаются на основе того, что разработчики предполагают, спросят пользователи. Реальные данные отражают то, что они спрашивают на самом деле. Использование продакшен-трафика дает три ключевых преимущества:
- Правильное распределение: Если 70% ваших обращений касаются цен, 70% датасета должны составлять примеры по ценам. Синтетика часто искажает этот баланс, фокусируясь на «краевых случаях», которые редко встречаются.
- Реальные режимы отказа: Пользователи генерируют сложные запросы: смешение языков, вставка полных логов ошибок, ссылки на устаревшие функции. Синтетика редко воспроизводит такие специфичные сценарии без глубокого понимания контекста.
- Отслеживание эволюции продукта: Бот поддержки, который полгода назад решал только вопросы сброса паролей, сегодня обрабатывает возвраты и скриншоты конкурентов. Golden Set, собранный из актуальных логов, фиксирует этот дрейф. Статичная синтетика устаревает сразу после создания.
02Процесс создания: 5 шагов
Шаг 1: Сбор и анонимизация трафика
Начните с выборки логов за 1-2 недели. Если функционал сезонный, увеличьте окно. Важно логгировать все метаданные: intent (намерение), feature area, сегмент пользователя, версию модели и промпта. Восстановить их позже будет невозможно.
Обязательно пропустите данные через пайплайн очистки PII (Personally Identifiable Information). Соблюдайте Terms of Service и логируйте этапы трансформации данных для воспроизводимости.
Шаг 2: Дедупликация и кластеризация
Продакшен-данные часто повторяются. Вопрос «как сбросить пароль» может приходить сотни раз в разной формулировке. Вам нужен один репрезентативный пример, а не пятьдесят.
- Точное совпадение: Удалите дубликаты по нормализованному тексту.
- Эмбеддинг-симулярность: Используйте векторное сравнение для выявления парафразов, которые не ловятся точечным сравнением.
- Взвешенная выборка: Сохраните пропорции долей интентов, но добавьте вес редким, но критичным сценариям отказа.
Шаг 3: Создание ожидаемых ответов (Rubric)
Для каждого входа нужен «правильный» ответ. Это может быть эталонная строка или, что чаще, рубрикатор (rubric). Используйте аналитические рубрики, где каждый критерий оценивается отдельно (MET/UNMET), а не одна общая оценка. Это позволяет точно локализовать, что именно ухудшилось.
Проведите независимую аннотацию двумя экспертами. Расхождения указывают на неоднозначность рубрикатора, а не на ошибку аннотаторов. Уточняйте критерии до достижения согласия.
Шаг 4: Первичная оценка и очистка
Запустите текущую продакшен-модель против набора. Разделите ошибки на три категории:
- Реальные ошибки модели: Модель ошиблась, рубрикатор верен. Оставляем.
- Проблемы рубрикатора: Модель дала разумный ответ, который не был учтен в эталоне. Исправляем эталон.
- Неоднозначные примеры: Не могут быть оценены ни одним разумным рубрикатором. Исключаем из набора.
Ожидайте, что часть набора будет отброшена на этом этапе. Это нормальный процесс «настройки» датасета.
Шаг 5: Интеграция в CI/CD
Разделите набор на две части:
- PR Gate (10-100 примеров): Быстрый запуск при каждом Pull Request. Должен выполняться за секунды.
- Full Regression (100-1000+ примеров): Полное тестирование на ветках релизов или ночных билдах.
03Кросс-модельное сравнение через единый API
Главное преимущество готового Golden Set — возможность сравнить разных провайдеров на ваших данных. Вместо того чтобы полагаться на лидерборды, вы запускаете один и тот же набор запросов через единый API (например, OpenRouter) к разным моделям.
Это позволяет выбрать модель на основе доказательств из вашего трафика, а не абстрактных метрик. Если модель A лучше справляется с вашими специфичными запросами, чем модель B, даже если B выше в MMLU, выбор очевиден для вашего продукта.
04Кому подойдёт / что запустится
Этот подход критически важен для команд, выпускающих LLM-продукты в продакшен. Он подходит для:
- Customer Support Bots: Где важна точность фактов и тон общения.
- Code Assistants: Где регрессия в генерации кода может сломать сборку.
- Контентные генераторы: Где важна структура и соблюдение гайдлайнов бренда.
Для запуска потребуется инфраструктура для хранения логов, инструмент для эмбеддингов (например, Langchain или LlamaIndex) и система оценки (LLM-as-a-judge или rule-based проверки). Начните с малого: 50-100 тщательно аннотированных примеров из вашего реального трафика дадут больше пользы, чем 10 000 синтетических вопросов.
Источник: OpenRouter ↗