Golden datasets для AI-агентів: стабільні набори для оцінювання

Ідея за 30 секунд

Golden dataset — це зафіксований набір тестових кейсів, на якому команда стабільно перевіряє поведінку агента.

Головна цінність у тому, що одна й та сама версія dataset дає порівнювані результати між candidate і baseline.

Проблема

Без golden dataset тестування швидко стає випадковим:

• сьогодні перевірили один набір запитів;
• завтра інший;
• післязавтра частину кейсів взагалі не запускали.

У такому режимі складно зрозуміти, що саме змінилося після релізу: поведінка агента чи просто сам набір сценаріїв.

Найчастіші наслідки:

• регресії знаходяться запізно;
• diff між версіями виглядає нестабільно;
• CI gate стає шумним і йому перестають довіряти.

Основна концепція / модель

Golden dataset — це не просто набір прикладів, а версіонований артефакт: чітка структура кейсів, правила розмітки і контрольована версія.

Чим стабільніші схема кейсів, розмітка і версія dataset, тим менше шансів, що різниця між прогонами пояснюється шумом, а не реальною зміною поведінки агента.

Як це працює

У практиці golden dataset оновлюють окремим процесом, а не разом із кожним релізом. Кожен новий кейс проходить однакові кроки до включення у версію dataset.

Golden dataset сам по собі не запускає тести: він дає стабільну основу для eval harness і regression-порівнянь.

Реалізація

На практиці golden dataset тримається на кількох простих правилах. Приклади нижче схематичні і не прив'язані до конкретного фреймворку.

1. Канонічна схема кейсу

expected_behavior може містити як жорсткі очікування для детермінованих перевірок, так і критерії для оцінки через LLM-as-a-judge.

case = {
    "id": "support_refund_partial_outage",
    "input": "Refund my order #8472",
    "expected_behavior": {
        "selected_tool": "payments_api",
        "allowed_stop_reasons": ["completed", "tool_error_handled"],
    },
    "checks": ["tool_selection", "valid_output_schema"],
    "tags": ["payments", "support", "partial-outage-risk"],
}

Чітка схема прибирає неоднозначність під час розбору проблемних кейсів.

2. Дедуплікація і фільтр шуму

def is_duplicate(case, seen_signatures):
    signature = f"{case['input']}|{case['expected_behavior']}"
    return signature in seen_signatures

def is_noisy(case):
    return len(case["input"].strip()) == 0

Краще мати менший, але стабільний dataset, ніж великий набір із дублями і шумом.

3. Розмітка очікуваної поведінки

def validate_case(case):
    required = ["id", "input", "expected_behavior", "checks"]
    for key in required:
        if key not in case:
            raise ValueError(f"missing_field:{key}")

Розмітка має бути перевіряною: якщо очікування не можна перевірити, кейс не готовий до golden dataset.

4. Версіонування dataset

dataset_version = "golden-v1.4"
metadata = {
    "dataset_version": dataset_version,
    "created_from": "incidents_2026_q1",
    "notes": "added outage and tool-fallback cases",
}

Dataset версіонують так само дисципліновано, як і код. Порівняння candidate і baseline має бути прив'язане до конкретної версії dataset.

Зміна кейсів без нової версії dataset фактично означає інший тестовий набір.

5. Інтеграція з eval harness

run_eval_suite(
    agent=candidate_agent,
    dataset_path="datasets/golden-v1.4.json",
    baseline_report="reports/baseline-golden-v1.4.json",
)

Одна версія dataset має використовуватись і для candidate, і для baseline, інакше diff втрачає сенс.

Нотатки для QA та автоматизації

QA-команди зазвичай будують автоматизовані regression suites саме на основі golden dataset: короткий smoke-набір для кожного PR і повний регресійний набір для планових прогонів.

Теги кейсів (payments, support, outage-risk) дають змогу стабільно формувати ці набори без ручного відбору і швидко локалізувати, у якому класі сценаріїв з'явилася регресія.

Типові помилки

Dataset змінюється між прогонами

Кейси додаються або редагуються без нової версії, тому результати двох запусків уже не порівнювані.

Типова причина: немає явного процесу версіонування dataset.

Тільки happy-path кейси

Dataset покриває лише "чисті" запити і не включає інциденти та edge cases.

Типова причина: кейси додаються вручну без аналізу production-трейсів.

Нечітка розмітка expected behavior

У кейсах є input, але немає перевіряного очікування, тому evaluators не можуть дати надійний verdict.

Типова причина: розмітка пишеться у вільній формі без схеми.

Нефіксовані умови прогону

Навіть коректні тести не дають порівнюваних результатів, якщо між прогонами змінюються модель, runtime або зовнішні залежності.

Типова причина: використовується alias моделі, плаваючі налаштування runtime або нестабільне середовище.

Немає тегів покриття

Команда не бачить, які класи ризиків уже покриті dataset, а які ще порожні.

Типова причина: кейси зберігаються без tags і групування за сценаріями.

Нестабільні кейси в golden dataset

Один і той самий кейс то проходить, то падає, і це засмічує сигнал регресій.

Типова причина: у кейс потрапляють нестабільні зовнішні залежності або неповністю контрольований runtime.

Коротко

FAQ

Q: Чим golden dataset відрізняється від звичайного набору тестів?
A: Це стабільна і версіонована база кейсів, на якій порівнюють поведінку агента між версіями.

Q: Як часто оновлювати golden dataset?
A: Зазвичай окремими версіями після накопичення нових інцидентів або важливих сценаріїв, а не перед кожним дрібним релізом.

Q: Чи можна включати синтетичні кейси?
A: Так, але основа має спиратися на реальні production-сценарії. Синтетика добре доповнює покриття edge cases.

Q: Що робити з нестабільними кейсами?
A: Або стабілізувати runtime і перевірки, або тимчасово прибрати кейс із golden dataset до нормалізації умов прогону.

Що далі

Після формування golden dataset підключіть його до Eval Harness, а зміни між версіями контролюйте через Regression Testing.

Для інцидентів у реальному середовищі додайте Replay and Debugging. Для повної картини тестування тримайте під рукою Стратегію тестування.