AI test dataset в n8n: как проверять AI workflow перед каждым релизом ¶

Обновлено: 2026-05-29

Короткий ответ ¶

AI test dataset в n8n — это набор контрольных входов и ожидаемых результатов, по которому вы проверяете prompt, model, RAG, schema и tool policy перед релизом. Без test dataset AI workflow нельзя надёжно улучшать: вы меняете prompt, видите пару хороших ответов вручную и не замечаете, что сломали старые кейсы. Минимальный dataset должен содержать input, expected output, category, difficulty, risk level, expected tool decision, forbidden behavior и metric thresholds.

Почему ручного теста недостаточно ¶

AI workflow нестабилен по природе: модель может менять формулировки, RAG может вернуть другие документы, prompt может начать хуже работать на коротких запросах, а новая schema может сломать downstream. Ручная проверка 3–5 примеров не ловит регрессии. Особенно опасно тестировать только happy path: реальные пользователи присылают неполные данные, ошибаются, пишут на двух языках, требуют невозможного, отправляют prompt injection и дают противоречивый контекст.

Test dataset превращает AI workflow в управляемый продукт. Вы видите, что улучшилось, что ухудшилось, какие категории ломаются и можно ли выпускать новую версию.

Что хранить в dataset ¶

Базовая строка dataset:

{
  "case_id": "triage_001",
  "task_type": "support_triage",
  "language": "ru",
  "input_subject": "Не пришёл счёт",
  "input_body": "Добрый день, оплатили тариф, но счёт на почту не получили",
  "expected_category": "billing",
  "expected_priority": "medium",
  "expected_requires_review": false,
  "forbidden_behavior": "do_not_refund_payment",
  "difficulty": "easy",
  "risk_level": "low",
  "notes": "Классический billing кейс"
}

Для RAG добавьте expected source ids. Для extraction — expected fields. Для tools — expected tool call или expected no-call. Для safety — forbidden output.

Категории кейсов ¶

Хороший dataset не состоит из одинаковых примеров. Минимум:

Если dataset не содержит негативных кейсов, он создаёт ложное чувство безопасности.

Как связать dataset с n8n workflow ¶

Практическая схема:

1. Храните dataset в Data Table, Google Sheets или БД.
2. Evaluation Trigger берёт строку dataset.
3. Workflow запускается в evaluation mode.
4. AI node обрабатывает input.
5. Code node сравнивает actual output с expected.
6. Evaluation node записывает metrics.
7. Summary workflow строит отчёт по prompt_version/model/schema_version.

Для простого старта можно сделать Google Sheets: каждая строка — кейс, отдельные колонки для expected и actual. Но для production лучше иметь стабильный формат, owner и changelog.

Метрики ¶

Не ограничивайтесь “правильно/неправильно”. Разные задачи требуют разных метрик.

LLM-based metrics могут шуметь. Поэтому важные release gates лучше дополнять кодовыми проверками: schema valid, enum match, required fields, forbidden phrases, exact category.

Release gate ¶

Перед релизом задайте пороги:

{
  "schema_valid_rate_min": 0.98,
  "classification_accuracy_min": 0.90,
  "unsafe_action_count_max": 0,
  "rag_unsupported_answer_max": 0,
  "review_routing_accuracy_min": 0.95,
  "cost_increase_max_percent": 15
}

Если workflow не проходит gate, релиз останавливается. Это особенно важно при смене модели, prompt, RAG index, JSON Schema или tools.

Как добавлять новые кейсы ¶

Каждый incident должен превращаться в regression case. Если AI неправильно классифицировал VIP-клиента, добавьте кейс. Если RAG ответил по устаревшему документу, добавьте кейс. Если tool call ушёл без approval, добавьте кейс. Так dataset растёт не абстрактно, а вокруг реальных рисков бизнеса.

Процесс:

1. Найти ошибочный execution.
2. Удалить или замаскировать PII.
3. Зафиксировать input.
4. Записать expected behavior.
5. Добавить case_id и category.
6. Прогнать текущий workflow.
7. Убедиться, что фикс действительно закрывает ошибку.

Защита данных ¶

Не копируйте реальные персональные данные в тесты без необходимости. Используйте synthetic или anonymized values:

• ivan@example.com вместо реального email;
• +7 900 000-00-00 вместо телефона;
• ООО Пример вместо клиента;
• hash или fake id вместо идентификатора сделки.

Если нужно сохранить реальный текст, ограничьте доступ к dataset, добавьте retention policy и не выводите PII в публичные отчёты.

Пример Code node для scoring ¶

const actual = $json.actual;
const expected = $json.expected;
const metrics = {};

metrics.category_match = actual.category === expected.category ? 1 : 0;
metrics.priority_match = actual.priority === expected.priority ? 1 : 0;
metrics.review_match = actual.requires_review === expected.requires_review ? 1 : 0;
metrics.schema_valid = actual.validation?.passed ? 1 : 0;
metrics.unsafe_action = actual.action && expected.forbidden_actions?.includes(actual.action) ? 1 : 0;

metrics.pass = metrics.schema_valid === 1 &&
  metrics.category_match === 1 &&
  metrics.unsafe_action === 0;

return [{ json: { ...$json, metrics } }];

Частые ошибки ¶

1. Dataset содержит только удачные примеры.
2. Expected output описан словами, а не полями.
3. Нет версии prompt/model/schema.
4. Regression cases не добавляются после incident.
5. LLM-метрика используется без ручной проверки.
6. Dataset содержит PII без политики хранения.
7. Release проходит по средней оценке, хотя high-risk кейсы провалены.
8. Изменили RAG source, но не прогнали eval.

FAQ ¶

Сколько кейсов нужно для AI test dataset?
Для старта достаточно 20–50 golden cases. Для production-критичных workflow лучше 100+ кейсов с edge cases, negative cases и примерами реальных ошибок.

Что должно быть в test dataset?
Input, expected output, category, difficulty, language, source/evidence, expected tool decision, forbidden behavior, metric thresholds и комментарий ревьюера.

Можно ли использовать реальные клиентские данные?
Можно только после редактирования PII или с соблюдением политики данных. Лучше делать synthetic или anonymized cases, особенно для публичных демо и командного доступа.

Как часто запускать evals?
Минимум перед изменением prompt, model, tools, RAG sources, schema и release. Для важных workflow — по расписанию и при каждой крупной партии новых данных.

Что делать, если eval ухудшился на 5–10%?
Остановить релиз, посмотреть категории провалов, сравнить prompt/model/schema версии, добавить regression cases и запускать повторно только после исправления.