Regression tests для prompt в n8n: как не ломать AI workflow после правок ¶

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

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

Prompt regression tests нужны, чтобы правка prompt, модели, RAG, schema или tool descriptions не ухудшила AI workflow незаметно. В n8n это можно организовать через набор тестовых кейсов, Evaluation Trigger, Google Sheets/Data Tables, метрики качества и отдельный workflow для сравнения результатов. Тест должен проверять не “нравится ли ответ”, а конкретные свойства: правильный intent, валидный JSON, наличие источника, refusal в опасных кейсах, отсутствие лишнего tool call, стоимость и latency. Без regression tests AI workflow деградирует тихо: вчера он правильно классифицировал лиды, сегодня начал отправлять VIP-клиентов в общий поток.

Что считается регрессией ¶

Регрессия — это любое ухудшение поведения после изменения. В AI workflow ухудшение не всегда выглядит как ошибка execution. Workflow может успешно завершиться, но:

• выбрать не тот intent;
• вернуть валидный JSON с неверным полем;
• повысить priority без причины;
• не сослаться на источник;
• вызвать write-tool вместо read-tool;
• ответить уверенно при пустом RAG;
• потратить в три раза больше токенов;
• перестать отказывать на небезопасный запрос;
• начать писать слишком длинные ответы;
• нарушить тон бренда.

Поэтому prompt regression tests должны смотреть на результат как на поведение продукта, а не только как на техническое завершение workflow.

Когда нужны тесты ¶

Тесты обязательны, если AI workflow влияет на клиентов, деньги, CRM, поддержку, продажи, юридические тексты, доступы, персональные данные или публичные ответы. Для внутреннего черновика можно начать с ручных тестов. Для production — нужен dataset, ожидаемые ответы и регулярный запуск после изменений.

Отдельно тесты нужны при любом изменении:

• system prompt;
• user prompt template;
• tool descriptions;
• schema output;
• модели или temperature;
• RAG chunking/metadata;
• vector store;
• memory strategy;
• fallback logic;
• PII redaction.

Структура тестового dataset ¶

Минимальная таблица может выглядеть так:

Не пытайтесь сразу сделать 1000 кейсов. Начните с 30–50: 10 happy path, 10 edge cases, 10 safety/risk, 10 RAG, 10 historical bugs.

Как собрать eval workflow в n8n ¶

Один вариант:

1. Evaluation Trigger или чтение dataset из Google Sheets/Data Table.
2. Set/Code node собирает вход в том же формате, что production workflow.
3. Execute Workflow вызывает тестируемый AI workflow или его isolated subworkflow.
4. Code node сравнивает output с expected fields.
5. Evaluation node или запись в таблицу сохраняет score, errors, latency, cost estimate, prompt version.
6. IF node отделяет failed cases.
7. Slack/Telegram/GitHub issue получает отчёт, если quality gate не пройден.

Важный принцип: eval должен запускать почти тот же код, что production. Если тестовый workflow использует другой prompt или другую schema, он проверяет не то, что работает у пользователей.

Пример проверки в Code node ¶

const actual = $json.actual;
const expected = $json.expected;
const errors = [];

if (actual.intent !== expected.expected_intent) {
  errors.push(`intent: expected ${expected.expected_intent}, got ${actual.intent}`);
}

if (expected.expected_action && actual.action !== expected.expected_action) {
  errors.push(`action: expected ${expected.expected_action}, got ${actual.action}`);
}

for (const phrase of expected.must_include || []) {
  if (!String(actual.answer || '').toLowerCase().includes(String(phrase).toLowerCase())) {
    errors.push(`missing phrase: ${phrase}`);
  }
}

for (const phrase of expected.must_not_include || []) {
  if (String(actual.answer || '').toLowerCase().includes(String(phrase).toLowerCase())) {
    errors.push(`forbidden phrase: ${phrase}`);
  }
}

if (actual.json_valid !== true) errors.push('invalid_json');
if (actual.needs_source && !actual.sources?.length) errors.push('missing_sources');

return [{
  json: {
    ...$json,
    eval_result: {
      passed: errors.length === 0,
      score: errors.length === 0 ? 1 : 0,
      errors
    }
  }
}];

Это не заменяет human review, но быстро ловит очевидные регрессии.

Какие метрики использовать ¶

Для разных workflow нужны разные метрики:

Для production полезен quality gate: например, “не выпускать prompt, если overall pass rate < 95%, safety pass rate < 100%, JSON validity < 99% или median latency выросла на 40%”.

Версионирование prompt ¶

Каждый запуск должен знать, с какой версией prompt он работал. Добавьте в workflow поля:

{
  "prompt_version": "support_triage_v1.8.2",
  "schema_version": "ticket_schema_v3",
  "model_policy_version": "routing_2026_05",
  "rag_index_version": "kb_2026_05_29"
}

Когда тест падает, вы должны видеть: сломался prompt, schema, retrieval или модель. Без версий вы будете сравнивать разные системы как будто это одна система.

Как выбирать тест-кейсы ¶

Сильный dataset включает не только обычные вопросы. Добавьте:

• реальные прошлые ошибки;
• длинные письма;
• пустой контекст;
• конфликтные инструкции;
• prompt injection;
• неоднозначные запросы;
• вопросы вне базы знаний;
• VIP/enterprise случаи;
• PII и sensitive data;
• запросы, где нужен отказ;
• запросы, где нужен human review;
• кейсы с похожими intent;
• кейсы с устаревшими документами.

Каждый баг после production-инцидента должен превращаться в новый regression test. Это главный способ не чинить одну и ту же ошибку повторно.

Как тестировать RAG ¶

Для RAG недостаточно проверить финальный ответ. Нужно проверять две стадии:

1. Retrieval — нашёл ли vector store правильные документы.
2. Generation — использовала ли модель найденные документы корректно.

В dataset добавьте expected_source_id или expected_doc_slug. Если ответ правильный, но источник не тот, это потенциальная регрессия. Сегодня модель угадала, завтра ошибётся.

Как тестировать tools ¶

Для AI Agent с tools проверяйте:

• вызвал ли агент нужный tool;
• не вызвал ли write-tool без approval;
• передал ли правильные параметры;
• не повторил ли tool call в loop;
• корректно ли обработал tool error;
• сделал ли fallback при timeout.

В тестовом окружении write-tools лучше заменить mock-ноду: она возвращает предсказуемый ответ и пишет, какие параметры получила.

Human review и спорные кейсы ¶

Не все кейсы должны иметь бинарный ответ. Для тональности, качества summary, юридической осторожности и сложных RAG-ответов нужен human score. Но даже human review должен быть структурированным: correctness, completeness, tone, source_use, risk. Иначе оценка превращается в “мне нравится/не нравится”.

Как не переусложнить ¶

Начните с light evaluations: 30 кейсов, ручной просмотр output, несколько простых правил. Затем добавьте metric-based evaluations, если workflow стал критичным. Главное — запускать тесты регулярно: перед релизом prompt, после обновления модели, после изменения RAG index и после крупных правок tools.

FAQ ¶

Сколько тестов нужно для старта? ¶

30–50 хороших кейсов лучше, чем 500 случайных. Покройте happy path, edge cases, safety, RAG и прошлые баги.

Нужно ли тестировать каждый prompt отдельно? ¶

Да, если prompt отвечает за отдельное поведение. Но можно объединять кейсы по workflow: классификация, ответ, extraction, tool decision.

Что делать, если LLM-метрика шумит? ¶

Используйте несколько запусков, deterministic checks и human review для спорных кейсов. Не полагайтесь только на LLM-as-judge.

Как тестировать стоимость? ¶

Логируйте approximate input/output tokens, model, retry count и tool calls. Regression — это не только качество, но и резкий рост стоимости.

Можно ли запускать тесты вручную? ¶

На старте да. Но перед production-релизами лучше иметь обязательный eval workflow и quality gate.