Что такое «golden dataset» для агента и как его создавать?

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

Golden dataset для агента — это размеченный вручную или полуавтоматически набор примеров, содержащих входной запрос пользователя, ожидаемую траекторию агента (последовательность вызовов инструментов, промежуточные рассуждения) и финальный ответ. Такой датасет служит «золотым стандартом» для оценки качества агента, регрессионного тестирования при обновлениях и тонкой настройки (fine-tuning) компонентов (например, LLM или политики выбора инструментов). Создание требует сбора логов production с отфильтрованными успешными сессиями, ручной или LLM‑разметки, нормализации формата и циклического обновления.

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

Golden dataset — это эталонный набор данных, в котором для каждого входного примера известен правильный (идеальный) выход. В контексте AI‑агентов выход — это не просто строка ответа, а полная траектория: какие инструменты вызваны, в каком порядке, какие аргументы переданы, какой был промежуточный рассуждение (chain‑of‑thought) и какой финальный ответ дан пользователю.

Агенты отличаются от простых RAG‑систем тем, что они могут совершать многошаговые действия (call|вызов API, чтение нескольких документов, уточнение запроса). Поэтому golden dataset для агента должен фиксировать не только конечный результат, но и промежуточные шаги.

Основные компоненты golden‑примера:

• Prompt — запрос пользователя (с возможным контекстом, историей диалога).
• Expected trajectory — последовательность действий агента (например, search_knowledge_base → call_calculator → final_answer).
• Tool calls — аргументы и результаты каждого вызова инструмента (хотя бы ожидаемые инструменты и их входы).
• Final answer — идеальный ответ пользователю.
• Метаданные — идентификатор сессии, версия агента, сложность запроса.

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

• Оценка качества агента (offline) — прогон на golden dataset даёт объективные метрики: точность выбора инструмента, полнота траектории, правильность финального ответа.
• Регрессионное тестирование — при каждом изменении (обновление LLM, смена промпта, новый инструмент) датасет позволяет быстро выявить ухудшения.
• Fine‑tuning LLM‑компонента — размеченные траектории можно использовать для обучения модели правильно выбирать инструменты или генерировать рассуждения.
• Сравнение архитектур — при выборе между разными стратегиями (ReAct, Plan‑and‑Execute, Reflection) golden dataset даёт честную точку отсчёта.
• Документация и прозрачность — датасет фиксирует ожидаемое поведение агента, что особенно важно для compliance и аудита.

3. Сбор исходных данных: логи production

Первый этап — собрать достаточное количество реальных сессий работы агента или смоделировать репрезентативные запросы.

Рекомендуемая стратегия: начинать с логов production, отфильтровывая сессии, где пользователь поставил лайк или не было жалоб. Дополнить синтетическими кейсами для редких инструментов или граничных случаев.

4. Разметка траекторий

Самый сложный этап — превратить сырые логи в размеченные golden‑примеры. Требуется определить «идеальную» траекторию для данного запроса.

4.1 Ручная разметка экспертами

• Плюсы высокая точность, контроль качества.
• Минусы дорого, медленно, требует глубокого понимания домена.
• Процесс эксперт получает запрос и контекст (какие инструменты доступны, описание среды) и вручную записывает шаги, которые должен был выполнить идеальный агент.
• Масштаб обычно 100–500 примеров для начала, далее итеративно.

4.2 LLM‑ассистированная разметка

• Идея использовать сильную LLM (GPT‑4, Claude‑3.5) для генерации ожидаемой траектории на основе запроса и списка инструментов.
• Преимущества дешево, быстро, можно масштабировать до тысяч примеров.
• Недостатки LLM может «галлюцинировать» шаги или предлагать нереалистичные действия. Нужна валидация (через second‑pass человека или автоматические правила).
• Рекомендация сначала сгенерировать кандидаты LLM, затем эксперты выборочно проверяют и корректируют 10–20% выборки.

4.3 Гибридный подход

1. Автоматически собрать из логов production только те сессии, где финальный ответ получил высокую оценку пользователя.
2. Прогнать эти логи через LLM‑validator (например, «правильно ли агент выбрал инструмент?») — отсеять явные ошибки.
3. Оставшиеся примеры считать gold‑кандидатами.
4. Эксперты точечно правят траектории, особенно в сложных многошаговых случаях.

5. Структура golden‑примера

Рекомендуется хранить датасет в формате JSON или JSONL. Пример записи:

{
  "id": "gold_00042",
  "prompt": "Сколько будет 2+2, если умножить на 3?",
  "context": {
    "user_id": "anon_1",
    "history": [],
    "available_tools": ["calculator", "search", "translator"]
  },
  "expected_trajectory": [
    {
      "step": 1,
      "tool": "calculator",
      "arguments": {"expression": "2+2"},
      "expected_result": "4"
    },
    {
      "step": 2,
      "tool": "calculator",
      "arguments": {"expression": "4*3"},
      "expected_result": "12"
    }
  ],
  "final_answer": "12",
  "complexity": "low",
  "source": "production_log_123"
}

Ключевые поля:

• prompt — вход пользователя.
• context — метаданные: история диалога, список разрешённых инструментов.
• expected_trajectory — массив шагов, каждый с названием инструмента, аргументами и ожидаемым результатом.
• final_answer — итоговый ответ.
• complexity — метка сложности (low/medium/high) для стратификации оценок.
• source — происхождение примера.

6. Размер датасета и необходимый минимум

Черновик указывает 500–5000 примеров. Это разумный диапазон.

• 500 примеров — минимальный набор для начала регрессионного тестирования. Покрывает основные сценарии, но может пропускать редкие.
• 2000–3000 примеров — хорошее покрытие для большинства коммерческих агентов. Позволяет заметить регрессии в 90% случаев.
• 5000+ примеров — необходимо, если датасет используется для fine‑tuning (дообучение LLM на траекториях).

Важно обеспечить сбалансированность:

• Разные инструменты должны быть представлены пропорционально их использованию.
• Примеры с разной сложностью (простые одношаговые vs. многошаговые с ветвлением).
• Граничные случаи (неоднозначные запросы, запросы вне зоны ответственности агента).

7. Обновление и регрессионный прогон

Golden dataset не статичен — он должен эволюционировать вместе с агентом.

• При каждом релизе (новые инструменты, изменённые промпты) нужно прогонять весь датасет и сравнивать метрики с baseline.
• Добавление новых примеров — когда в production появляются новые типы запросов или инструменты, следует расширять датасет.
• Удаление устаревших примеров — если инструмент удалён или изменился интерфейс, соответствующие тесты могут стать невалидными. Их нужно переразметить или исключить.
• Версионирование датасета — хранить историю изменений (например, в git‑lfs), чтобы можно было откатиться и понять, когда изменилась метрика.

Регрессионный прогон автоматизируют в CI/CD пайплайне. Пример скрипта:

import json
from agent_evaluator import evaluate_agent

with open("golden_dataset.jsonl") as f:
    golden = [json.loads(line) for line in f]

agent = load_agent(version="v2.1")
results = evaluate_agent(agent, golden)

# Вывод метрик
print(f"Tool accuracy: {results.tool_accuracy:.3f}")
print(f"Trajectory exact match: {results.trajectory_exact_match:.3f}")
print(f"Final answer accuracy: {results.final_answer_accuracy:.3f}")

# Сравнение с baseline
baseline = load_baseline("v2.0")
assert results.tool_accuracy >= baseline.tool_accuracy - 0.01, "Regression detected!"

8. Метрики качества на golden dataset

Оценка агента на golden датасете может включать несколько метрик:

Важно помнить, что golden dataset — это замкнутый мир: высокая точность на нём не гарантирует хорошего поведения в production, но низкая точность почти всегда сигнализирует о проблемах.

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

• LangSmith / LangFuse — платформы для трекинга агентов, позволяющие собирать логи и размечать их (labeling queues).
• Ragas / DeepEval — библиотеки для оценки RAG и агентов, могут использовать golden dataset как эталон.
• PromptLayer / Weights & Biases — инструменты для версионирования данных и экспериментов.
• dvc / git‑lfs — для хранения версий датасета.

Пример пайплайна сборки с использованием LangSmith:

1. Логи из production экспортируются через API.
2. Фильтр по feedback_score >= 0.9 (лайки).
3. LLM‑разметчик генерирует expected trajectory для каждой сессии.
4. Челвек‑валидатор проверяет случайную выборку (5–10%).
5. Валидированные примеры сохраняются в JSONL и добавляются в репозиторий.

10. Особенности для Agentic RAG

В контексте агентов, использующих RAG (Agentic RAG), golden dataset должен учитывать:

• Выбор источника агент может обращаться к нескольким базам знаний (разные индексы, веб‑поиск). В ожидаемой траектории нужно указывать, какой источник был правильным.
• Iterative retrieval агент может уточнять запрос и делать несколько вызовов retrieval. Траектория должна фиксировать каждый вызов и его результат.
• Самостоятельное размышление (reflection): если агент проверяет найденные документы на релевантность, это тоже шаг траектории.

Пример сложной траектории для Agentic RAG:

prompt: "Какая была погода в Москве 1 марта 2024 и какой курс доллара?"
шаги:
  1. tool=retrieve_docs(query="погода Москва 1 марта 2024") -> docs
  2. tool=refine_query(query="курс доллара 1 марта 2024") -> refined_query
  3. tool=web_search(query=refined_query) -> results
  4. tool=summarize(docs+results) -> summary
  5. final_answer: summary

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

Задача Создать golden dataset для простого агента-калькулятора, который умеет выполнять базовые арифметические операции и конвертацию валют (два инструмента). Используя логи синтетических сессий, построить датасет из 50 примеров и написать скрипт регрессионного тестирования.

Инструменты Python, LangChain (для эмуляции агента), библиотека jsonlines, Jupyter Notebook.

Шаги:

1. Определить инструменты calculator(expression), currency_converter(amount, from_currency, to_currency).
2. Сгенерировать синтетические запросы (10 простых, 10 с двумя шагами, 5 с конвертацией + расчёт и т.д.). Для каждого запроса вручную напишите ожидаемую траекторию.
3. Сохранить датасет в формате JSONL (каждая строка — пример с полями prompt, expected_trajectory, final_answer).
4. Реализовать агента (можно на базе LangChain ReAct агента с небольшим LLM, например, llama3.1:8b через Ollama).
5. Написать eval‑функцию, которая прогоняет агента по датасету и считает точность выбора инструмента и точность финального ответа.
6. Провести регрессионный тест изменить промпт агента (например, запретить прямой вызов калькулятора в пользу currency_converter) — убедиться, что метрика упала.

Ожидаемый результат Работающий пайплайн: golden dataset → eval → отчёт о регрессии. Вы научитесь отличать плохой рефакторинг от хорошего.

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

Навигация

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