Как проектировать golden dataset для agent evaluation?

Краткий тезис

Golden dataset для agent evaluation — это размеченный эталонный набор примеров, который включает не только вход и ожидаемый ответ, но and полную траекторию действий агента (вызовы инструментов, рассуждения, промежуточные состояния). Проектирование такого датасета требует минимум 500 примеров (ради статистической значимости), структуры {input, expected_trajectory, expected_final, context} и высокого согласия между аннотаторами (agreement|inter-annotator agreement >0.85). Регулярное обновление каждые две недели с добавлением 50 новых примеров позволяет датасету «жить» вместе с эволюцией агента.

1. Термин: Golden dataset (золотой стандарт)

Golden dataset — это вручную или полуавтоматически размеченный набор данных, который считается истиной (ground truth) для оценки качества системы. В контексте AI-агентов он принципиально отличается от обычного тестового датасета для RAG: здесь критична не только корректность финального ответа, но и правильность последовательности шагов (trajectory), которые агент совершил, чтобы прийти к этому ответу.

Пример записи в golden dataset:

{
  "input": "Найди последний отчёт по продажам за Q3 и отправь его на почту Ивану.",
  "expected_trajectory": [
    "action: search_database(query='отчёт продажи Q3')",
    "action: get_file(file_id=12345)",
    "action: send_email(to='ivan@company.com', attachment=12345)"
  ],
  "expected_final": "Отчёт за Q3 отправлен Ивану на почту.",
  "context": "База документов: отчёты за 2023–2024 гг., контакты сотрудников."
}

2. Зачем нужен golden dataset для агентов?

• Объективная оценка качества — можно автоматически прогонять агента на датасете и считать метрики (accuracy, step accuracy, success rate).
• Регрессионное тестирование — после изменения промпта, fine-tuning или смены модели проверяем, не сломались ли старые сценарии.
• Выявление failure cases — анализируя примеры, где агент ошибается, мы улучшаем систему.
• Сбор данных для fine-tuning — golden dataset служит seed-датасетом для обучения модели с учителем (SFT) или для RLHF (через оценку траекторий).

3. Размер датасета: минимум 500 примеров

Почему 500

• Статистическая значимость — для метрик accuracy или success rate при доверительной вероятности 95% и погрешности ±3% требуется примерно 1068 примеров. 500 — компромисс между стоимостью разметки и достаточной уверенностью.
• Покрытие ветвлений — агенты имеют много состояний (tool calls, условия, циклы). 500 примеров позволяют охватить основные сценарии и десяток edge cases.
• Правило большого пальца — для первого релиза достаточно 300–500, для production — 1000+.

Факторы, влияющие на требуемый размер:

• Сложность агента (количество инструментов, шагов)
• Количество интентов пользователей
• Требуемая точность метрик (чем выше, тем больше примеров)

4. Структура записи {input, expected_trajectory, expected_final, context}

Дополнительные поля (опционально):

• difficulty — уровень сложности (easy/medium/hard)
• category — тип запроса (информационный, транзакционный, поддержка)
• tags — метки для фильтрации (например, «многошаговый», «требует внешнего API»)

5. Сбор данных: из production логов и синтез

Основной источник — production логи агента с положительным user feedback (пользователь поставил «лайк» или подтвердил решение). Но полагаться только на них опасно: они смещены (bias) — обычно туда попадают простые сценарии.

Дополнительные методы сбора

• Синтетическая генерация — с помощью LLM (GPT-4, Claude) генерируем запросы и соответствующие траектории, затем проверяем экспертом.
• Failure cases — собираем диалоги, где пользователь дал негативный фидбек или эскалация; размечаем их как «hard» примеры.
• Edge cases из чеклистов — специально создаём запросы с опечатками, неоднозначностями, конфликтами инструментов.

Фильтрация — отбрасываем примеры, где агент явно ошибался и пользователь пожаловался, но разметчик считает эту траекторию правильной? Нет, такие примеры можно использовать как failure cases, пометив их отдельно.

6. Разметка экспертами и Inter‑Annotator Agreement (IAA)

Процесс:

1. Подготовка гайдлайнов — детальные инструкции, что считать правильной траекторией, как разрешать неоднозначности.
2. Калибровка — первые 30 примеров размечаются всеми аннотаторами совместно, обсуждаются расхождения.
3. Основная разметка — каждый пример проверяют минимум 2–3 эксперта независимо.
4. Расчёт IAA — Cohen’s kappa (для двух аннотаторов) или Fleiss’ kappa (для трёх и более). Порог: >0.85 (почти идеальное согласие).
5. Консенсус — примеры с низким согласием (kappa <0.7) отправляются на пересмотр.

Пример расчёта Cohen’s kappa на Python:

from sklearn.metrics import cohen_kappa_score

# labels: 1 — корректная траектория, 0 — некорректная
annotator1 = [1, 0, 1, 1, 0]
annotator2 = [1, 0, 1, 0, 0]
kappa = cohen_kappa_score(annotator1, annotator2)
print(f"Cohen's kappa: {kappa:.3f}")

7. Покрытие: edge cases и failure cases

Golden dataset должен включать не только «счастливые пути», но и:

• Неожиданные запросы — «Сделай что угодно», «Игнорируй предыдущие инструкции».
• Неоднозначности — «Найди документ про Ивана» (какого Ивана?).
• Запросы без ответа — «Удали всю базу данных» (должен отказаться).
• Сценарии с ошибками API — внешний сервис недоступен, агент должен корректно обработать.
• Мультиязычные запросы — если агент поддерживает несколько языков.

Failure cases из истории ошибок — это самая ценная часть, так как они прямо указывают на слабые места системы.

Метрика покрытия — доля категорий из предопределённой таксономии (например, 20 типов запросов), которые представлены в датасете хотя бы 5 примерами. Хорошее покрытие — >80%.

8. Обновление: каждые 2 недели по 50 примеров

Почему 2 недели

• Промпты, модели и инструменты агента меняются часто.
• Новые сценарии появляются после релизов.
• Даёт ритм: одна неделя — сбор и разметка, вторая — включение в пайплайн оценки.

Процесс версионирования

• Храним датасет в Git-репозитории или в Hugging Face Datasets с тегом версии (golden_dataset_v0.9.0).
• Каждое обновление — новый коммит/загрузка.
• Для каждого прогона оценки фиксируем версию датасета, чтобы можно было воспроизводить результаты.

Правило «не выкидываем старые примеры» — старые примеры остаются, если они всё ещё релевантны. Устаревшие (например, связанные с изменённым инструментом) помечаются deprecated и не участвуют в основных метриках, но хранятся для ретроспективы.

9. Метрики качества самого датасета

10. Инструменты для работы с golden dataset

• Argilla — open-source платформа для разметки данных с поддержкой AI-агентских сценариев (отображение траекторий, сравнение).
• Label Studio — гибкая разметка с кастомными темплейтами.
• Hugging Face Datasets — хранение, версионирование и загрузка датасетов.
• scikit-learn — расчёт Cohen’s kappa, Fleiss’ kappa.
• DVC — версионирование больших датасетов в связке с Git.
• LangSmith / Weights & Biases — сбор логов агентов с автоматической аннотацией.

11. Чеклист качественного golden dataset для agent evaluation

• Размер ≥ 500 примеров (для production ≥ 1000)
• Структура: input, expected_trajectory, expected_final, context + опциональные поля
• Источники: production логи + синтетика + failure cases
• Разметка: 2–3 эксперта, гайдлайны, калибровка
• IAA (Cohen's kappa) > 0.85
• Покрытие edge cases и failure cases > 80%
• Регулярное обновление (каждые 2 недели)
• Версионирование (Hugging Face Datasets / DVC)
• Мониторинг качества датасета (баланс, утечки)

Пет-проект для закрепления

Задача Разработать golden dataset для customer support агента (помощник по документации продукта).

Инструменты

• Python, LangChain (симуляция агента)
• Argilla (разметка)
• Hugging Face Datasets (хранение)
• scikit-learn (IAA)

Шаги:

1. Симулировать агента на 2000 запросов (1000 простых, 500 средних, 500 сложных), записать все логи в JSONL.
2. Отфильтровать 600 лучших (по user feedback и успешности).
3. Сгенерировать 300 синтетических примеров с помощью LLM (GPT-4) и вручную проверить.
4. Разметить 500 примеров с тремя аннотаторами: для каждого указать корректность траектории (бинарно) и исправить, если нужно.
5. Рассчитать Fleiss’ kappa; добиться >0.85, переразметив конфликтные примеры.
6. Проанализировать покрытие: создать таксономию (10 категорий), подсчитать примеры в каждой, дополнить недостающие.
7. Загрузить датасет в Hugging Face Datasets с версией v1.0.0.
8. Написать скрипт оценки агента на этом датасете (метрики: success rate, avg step accuracy).

Ожидаемый результат Готовый golden dataset (500–800 примеров) в репозитории HF, отчёт с метриками качества датасета (kappa, coverage, balance) и baseline метрики агента.

Связь с другими вопросами

Навигация

• Предыдущий: 879
• Следующий: 881
• Индекс: 00. Индекс разборов