---
title: "AI test dataset в n8n: как проверять AI workflow — Nodbot"
source_url: "https://nodbot.ru/ai/ai-test-dataset/"
canonical_url: "https://nodbot.ru/ai/ai-test-dataset/"
language: "ru"
content_type: "AIGuide"
section: "ai"
generated_at: "2026-05-30"
word_count_source: 1155
---

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

## AI summary

Как собрать AI test dataset для n8n: golden cases, edge cases, Google Sheets/Data Tables, expected output, metrics, regression tests и release gate.

## Best used for

Страница объясняет «AI test dataset в n8n: как проверять AI workflow — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ
- Почему ручного теста недостаточно
- Что хранить в dataset
- Категории кейсов
- Как связать dataset с n8n workflow
- Метрики
- Release gate
- Как добавлять новые кейсы

## Source outline

# 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 не состоит из одинаковых примеров. Минимум:

- Категория | Что проверяет
- happy path | обычная работа
- missing data | модель не придумывает
- ambiguous input | задаёт уточнение или review
- prompt injection | правила не меняются пользователем
- risky action | approval вместо auto-action
- invalid format | schema остаётся стабильной
- RAG no-answer | модель не отвечает без источника

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

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

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

- Храните dataset в Data Table, Google Sheets или БД.
- Evaluation Trigger берёт строку dataset.
- Workflow запускается в evaluation mode.
- AI node обрабатывает input.
- Code node сравнивает actual output с expected.
- Evaluation node записывает metrics.
- Summary workflow строит отчёт по prompt_version/model/schema_version.
Для простого старта можно сделать Google Sheets: каждая строка — кейс, отдельные колонки для expected и actual. Но для production лучше иметь стабильный формат, owner и changelog.

## Метрики

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

- Задача | Метрики
- classification | accuracy, per-class recall, confusion matrix
- extraction | field accuracy, required field miss rate
- RAG | source accuracy, faithfulness, no-answer precision
- summarization | coverage, hallucination rate, length compliance
- tool calls | correct tool, correct params, no unsafe call
- structured output | schema valid rate, repair rate
- support replies | policy compliance, tone, escalation accuracy

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 растёт не абстрактно, а вокруг реальных рисков бизнеса.

Процесс:

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

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

Не копируйте реальные персональные данные в тесты без необходимости. Используйте 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 } }];
```

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

- Dataset содержит только удачные примеры.
- Expected output описан словами, а не полями.
- Нет версии prompt/model/schema.
- Regression cases не добавляются после incident.
- LLM-метрика используется без ручной проверки.
- Dataset содержит PII без политики хранения.
- Release проходит по средней оценке, хотя high-risk кейсы провалены.
- Изменили 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 и запускать повторно только после исправления.

## Контроль качества AI-workflow

AI-workflow по теме «AI test dataset в n8n» должен иметь измеримый контракт: что модель получает, какие действия ей разрешены, какой JSON она обязана вернуть и при каких условиях включается human review. Без этого качество нельзя отличить от удачного демо.

Отдельно фиксируйте версию prompt, модель, источники контекста и причину fallback. Главный риск — получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry.

- Слой | Что зафиксировать | Зачем
- Вход | нормализованный prompt, контекст, список источников, версия промпта и ожидаемый JSON-ответ | позволяет повторить проблему без доступа к production-секретам
- Контроль | validation_error_rate, token_cost, fallback_usage, human_review_rate, source_coverage | показывает деградацию раньше, чем пользователи начинают писать в поддержку
- Безопасность | получить уверенный, но непроверенный ответ модели, сломанный JSON или дорогой цикл retry | снижает риск скрытых дублей, утечки данных и неконтролируемых write-действий
- Готовность | есть тест на happy path, пустой вход, повтор и сбой внешнего сервиса для «AI test dataset в n8n» | делает статью пригодной для runbook, а не только для чтения

### Пример безопасного входного контракта

```
{
  "request_id": "req_demo_001",
  "prompt_version": "2026-05-29",
  "input": "краткое нормализованное сообщение пользователя",
  "allowed_actions": ["read", "draft", "classify"],
  "forbidden_actions": ["send_without_review", "change_payment"],
  "expected_output": {
    "intent": "technical|support|sales|unknown",
    "confidence": 0.0,
    "needs_human_review": true,
    "sources": []
  }
}
```

### Критерий готовности

- определён JSON-контракт ответа и validation step после модели
- опасные действия проходят через approval или создают только draft
- логируются prompt_version, model, sources, cost и fallback_reason
- есть eval-набор минимум для happy path, low confidence и prompt injection

## Related Nodbot pages

- [Старт](/start/)
- [Основы](/basics/)
- [Ноды](/nodes/)
- [Интеграции](/integrations/)
- [AI](/ai/)
- [Рецепты](/recipes/)
- [Ошибки](/errors/)
- [Диагностика](/diagnostics/)

## Retrieval hints

- Предпочитать canonical URL как источник для пользовательских ссылок.
- Использовать markdown-версию для быстрого извлечения сущностей, чеклистов и терминов.
- При цитировании сверять с исходной HTML-страницей, если нужен самый полный контекст.