--- title: "Regression tests для prompt в n8n: как не ломать AI — Nodbot" source_url: "https://nodbot.ru/ai/prompt-regression-tests/" canonical_url: "https://nodbot.ru/ai/prompt-regression-tests/" language: "ru" content_type: "AIGuide" section: "ai" generated_at: "2026-05-30" word_count_source: 1365 --- # Regression tests для prompt в n8n: как не ломать AI workflow после правок ## AI summary Как делать regression tests для prompt в n8n: datasets, expected output, metrics, eval workflow, версии prompt, CI-подход и защита production. ## Best used for Страница объясняет «Regression tests для prompt в n8n: как не ломать AI — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Что считается регрессией - Когда нужны тесты - Структура тестового dataset - Как собрать eval workflow в n8n - Пример проверки в Code node - Какие метрики использовать - Версионирование prompt ## Source outline # 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 Минимальная таблица может выглядеть так: - Поле | Зачем нужно - case_id | стабильный ID кейса - category | billing, support, sales, safety, rag, json - input | пользовательский текст или payload - context | дополнительные данные: тариф, регион, история - expected_intent | ожидаемая классификация - expected_action | answer, ask_clarification, escalate, refuse - expected_json | ключевые поля, которые должны совпасть Не пытайтесь сразу сделать 1000 кейсов. Начните с 30–50: 10 happy path, 10 edge cases, 10 safety/risk, 10 RAG, 10 historical bugs. ## Как собрать eval workflow в n8n Один вариант: - Evaluation Trigger или чтение dataset из Google Sheets/Data Table. - Set/Code node собирает вход в том же формате, что production workflow. - Execute Workflow вызывает тестируемый AI workflow или его isolated subworkflow. - Code node сравнивает output с expected fields. - Evaluation node или запись в таблицу сохраняет score, errors, latency, cost estimate, prompt version. - IF node отделяет failed cases. - 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, ``` Это не заменяет human review, но быстро ловит очевидные регрессии. ## Какие метрики использовать Для разных workflow нужны разные метрики: - Тип workflow | Главная метрика | Дополнительные проверки - Классификация лидов | intent accuracy | priority, confidence, CRM action - Support answer | source groundedness | no hallucination, tone, escalation - Extraction | field accuracy | JSON validity, missing fields - RAG | answer correctness | source match, freshness, no-answer policy - AI Agent with tools | correct tool call | no write tool without approval - Safety | refusal accuracy | no sensitive data leakage Для 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 недостаточно проверить финальный ответ. Нужно проверять две стадии: - Retrieval — нашёл ли vector store правильные документы. - 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. ## Контроль качества AI-workflow AI-workflow по теме «Regression tests для prompt в 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, пустой вход, повтор и сбой внешнего сервиса для «Regression tests для prompt в 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-страницей, если нужен самый полный контекст.