AI bad output в n8n: runbook для JSON и качества ¶

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

Intent: runbook AI bad output: плохой ответ AI, невалидный JSON, hallucination, schema validation, eval set, fallback, human review
H1: AI bad output в n8n: как чинить невалидный JSON, галлюцинации и рискованные ответы
Schema: TechArticle, HowTo, FAQPage, BreadcrumbList
Old word count: 670
New word count: 758

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

Плохой AI-output в n8n нужно чинить не только prompt-ом. Сначала определите тип сбоя: невалидный JSON, неверная классификация, галлюцинация, потеря полей, опасное действие или ответ без источника. Затем добавьте schema validation, тестовый набор примеров, fallback path, human review для высокорисковых случаев и журнал ошибок по execution_id. Для production AI workflow результат модели должен проходить проверку до того, как он попадёт в CRM, email, платежи или клиентский чат.

Когда применять этот runbook ¶

Runbook нужен, если AI workflow “работает”, но выдаёт неправильный результат. В отличие от обычной ошибки HTTP 500, bad output часто выглядит как успешная execution: node зелёный, данные пошли дальше, а проблема обнаруживается клиентом, менеджером или downstream-системой.

Типичные случаи:

• модель вернула текст вместо JSON;
• JSON валиден, но поля не соответствуют контракту;
• классификация лида/тикета неверная;
• AI придумал факт или ссылку;
• агент вызвал не тот tool;
• RAG-ответ не опирается на найденные источники;
• email клиенту звучит уверенно, но содержит ошибку;
• workflow создал задачу, сделку или refund без достаточного основания.

Главная цель — превратить AI node из “чёрного ящика” в контролируемый компонент с контрактом входа, выхода и fallback.

1. Остановить risky path ¶

Если bad output может отправить клиенту письмо, изменить CRM, создать заказ, сделать refund или вызвать внешний API, сначала отключите side-effect ветку. Не обязательно выключать весь workflow: можно временно направить результат в review queue.

Пока причина не найдена, AI должен рекомендовать действие, а не выполнять его автоматически.

2. Разделить типы плохого ответа ¶

Не смешивайте все ошибки в “модель плохая”. У каждого типа свой фикс.

Для расследования сохраните: input, prompt version, model, output, validation error, expected output и downstream effect.

3. Ввести контракт результата ¶

Production AI node должен возвращать не “что-нибудь полезное”, а конкретный контракт.

Пример контракта для triage:

{
  "category": "billing|technical|sales|other",
  "priority": "low|normal|high|urgent",
  "confidence": 0.0,
  "summary": "string",
  "needs_human": true,
  "evidence": ["string"]
}

Если output не проходит validation, он не должен идти дальше в CRM или email. Направьте его в fallback: повтор с более строгим prompt, дешёвый repair step, ручную очередь или safe default.

4. Собрать eval set ¶

Без тестового набора вы будете чинить один пример и ломать другой.

Минимальный eval set:

• 10 обычных входов;
• 10 сложных/пограничных;
• 5 пустых или мусорных;
• 5 с персональными/чувствительными данными;
• 5 с конфликтующими инструкциями;
• 5 реальных ошибок из production.

Для каждого примера храните expected category, required fields, forbidden behavior и acceptable answer. После изменения prompt/model/schema прогоняйте набор до релиза.

5. Добавить confidence и human review ¶

Не все AI-результаты должны автоматически продолжать workflow.

Правила:

Confidence не должен быть единственной защитой: модель может быть уверенной и неправой. Используйте его вместе с validation и правилами риска.

6. Починить prompt и context ¶

Проверьте:

• ясны ли labels и критерии классификации;
• не конфликтуют ли system/user инструкции;
• не слишком ли длинный context;
• есть ли примеры плохих и хороших ответов;
• запрещены ли выдуманные факты;
• есть ли формат отказа;
• отделены ли данные пользователя от инструкций;
• не передаётся ли предыдущий output как новая инструкция.

Для RAG-ответов добавьте правило: если источника нет, отвечать “не найдено в базе”, а не дополнять из общих знаний.

FAQ ¶

Достаточно ли попросить модель “верни валидный JSON”?
Нет. Нужна schema validation и fallback, потому что даже хороший prompt не гарантирует корректный output во всех случаях.

Почему workflow зелёный, а результат плохой?
Потому что технически AI node выполнился успешно. Качество результата нужно проверять отдельной логикой.

Когда нужен human review?
Когда действие влияет на клиента, деньги, персональные данные, юридические формулировки или необратимые изменения во внешней системе.

Как понять, что prompt стал лучше?
Прогонять eval set до и после изменения и сравнивать ошибки, а не оценивать один удачный пример вручную.

{
  "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": []
  }
}