Guardrails против hallucinations в n8n: источники, отказ, проверки и безопасные ответы ¶

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

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

Hallucination guardrails — это набор правил и проверок, которые не позволяют AI workflow уверенно отвечать без основания. В n8n guardrails строятся вокруг RAG-источников, no-answer policy, проверки цитат, structured output, confidence threshold, human review и логов. Цель не в том, чтобы модель “никогда не ошибалась”, а в том, чтобы workflow умел распознать риск и безопасно отказать, уточнить вопрос или передать человеку.

Почему hallucinations опасны в automation ¶

В чате ошибка модели неприятна. В workflow ошибка модели может стать действием: CRM обновится неверно, клиент получит неправильную инструкцию, оператор увидит ложный summary, база знаний начнёт распространять устаревшее правило. Поэтому guardrails должны проверять не только текст ответа, но и последствия.

Слабый AI workflow отвечает всегда. Хороший AI workflow отвечает только тогда, когда есть достаточный контекст, понятный источник и допустимое действие. Если данных нет, он говорит “не найдено”, задаёт уточнение или создаёт задачу человеку.

Типы hallucinations ¶

Тип	Пример	Как ловить
Фактическая выдумка	модель придумала политику возврата	citations + source existence check
Устаревший ответ	использована старая инструкция	metadata freshness + version filter
Смешение клиентов	ответ по данным другого пользователя	tenant_id/session filters
Неверный tool result	агент неправильно интерпретировал API	output schema + Code validation
Overconfident answer	нет данных, но ответ уверенный	no-answer policy + confidence threshold
Prompt injection	документ просит игнорировать правила	isolate instructions from retrieved content

Базовая схема guardrails workflow ¶

User question приходит через Chat Trigger, Telegram или Webhook.
Pre-check определяет тему, язык, tenant, user role и риск.
Retrieval ищет документы только в разрешённом scope.
Source filter проверяет freshness, tenant_id, document_status.
AI step формирует ответ с обязательными citations.
Validation проверяет: есть ли источники, относятся ли они к вопросу, нет ли запрещённых утверждений.
Если confidence низкая — ответ не отправляется, включается fallback.
Если тема high-risk — human review.
Audit log сохраняет question_hash, retrieved_sources, answer_status, fallback_reason.

No-answer policy ¶

No-answer policy — это инструкция и логика, которая разрешает модели не отвечать. Без неё модель почти всегда пытается быть полезной, даже если данных нет. Для бизнеса лучше честный отказ, чем уверенная выдумка.

Пример политики:

Если в предоставленных источниках нет ответа, не придумывай. Верни JSON:
{
  "answer_status": "no_answer",
  "reason": "source_not_found",
  "clarifying_question": "...",
  "safe_to_send": true
}

Но одного prompt мало. После модели Code node должен проверить, что answer_status = answered невозможен без sources.

const hasSources = Array.isArray($json.sources) && $json.sources.length > 0;
const answered = $json.answer_status === 'answered';
if (answered && !hasSources) {
  return [{ json: { ...$json, answer_status: 'review', guardrail_error: 'answer_without_sources' } }];
}
return [{ json: $json }];

Проверка источников ¶

RAG-ответ должен ссылаться на документы, которые реально были retrieved. Не позволяйте модели придумывать “источник: внутренняя документация”. Сохраняйте массив retrieved documents отдельно и сравнивайте citations с ним.

Минимальная структура:

{
  "answer": "...",
  "sources": [
    {"doc_id": "refund_policy_v3", "chunk_id": "ch_12", "title": "Правила возврата", "updated_at": "2026-05-01"}
  ],
  "confidence": 0.81,
  "answer_status": "answered"
}

Если источник старше допустимого срока или имеет status = draft, ответ должен идти в review или no-answer.

Guardrails для разных типов страниц ¶

Для support bot guardrails отвечают за точность и тон. Для legal/finance — за отказ от неподтверждённых утверждений. Для sales assistant — за запрет обещать скидки или условия, которых нет в CRM. Для internal knowledge assistant — за source freshness и role-based access. Для AI Agent с tools — за то, чтобы ответ не превращался в опасное действие.

Поэтому guardrails нельзя копировать один-в-один. Они должны соответствовать риску страницы или workflow.

Anti-patterns ¶

“Ответь только по источникам” без проверки sources.
Один общий RAG index для всех клиентов без metadata filters.
Удаление фразы “я не знаю” из prompt, потому что “бот должен отвечать”.
Автоматическая отправка ответа клиенту без confidence и review.
Отсутствие dataset с вопросами, на которые бот должен отказаться отвечать.
Хранение retrieved chunks в логах без маскировки sensitive data.

Evaluation dataset ¶

Для hallucination guardrails нужен отдельный dataset. Включите:

вопросы с ответом в источниках;
вопросы без ответа;
вопросы по устаревшим документам;
prompt injection в тексте вопроса;
вопрос с двумя похожими клиентами;
вопрос, где нужен отказ по policy;
вопрос, где источник есть, но не содержит нужного факта;
вопрос, где требуется уточнение.

Метрики: source accuracy, answer faithfulness, no-answer precision, no-answer recall, unsafe answer rate, review rate. Если bot отвечает на no-answer кейсы, guardrails не готовы.

Production-мониторинг ¶

Логируйте не только текст ответа, а статус:

{
  "trace_id": "rag_001",
  "question_hash": "sha256:...",
  "retrieved_count": 4,
  "used_source_count": 2,
  "answer_status": "answered",
  "confidence": 0.78,
  "guardrail_flags": [],
  "fallback_reason": null,
  "review_required": false
}

Отдельно отслеживайте ответы без sources, рост no-answer, частые prompt injection flags, снижение confidence после обновления базы знаний и расхождения между retrieved source и final answer.

Когда отправлять в human review ¶

Review нужен, если тема high-risk, sources противоречат друг другу, confidence ниже порога, пользователь просит юридическую/финансовую гарантию, tool action может изменить данные, обнаружена prompt injection или ответ влияет на клиента напрямую. Review — это не провал автоматизации, а safety layer.

Итоговая формула ¶

Надёжный anti-hallucination workflow в n8n выглядит так: retrieval with metadata → source verification → answer with citations → structured status → validation → no-answer/fallback → review for risk → audit log → evaluations. Если убрать любую часть, останется просто prompt с надеждой, что модель будет осторожной.

FAQ ¶

Можно ли полностью убрать hallucinations?
Нет. Можно сильно снизить риск и не допускать опасные ответы в production: sources, no-answer policy, validation, review и evaluations.

Что важнее: RAG или prompt?
RAG даёт основу, prompt задаёт поведение, но guardrails должны проверять sources и статус ответа после модели.

Что такое no-answer policy?
Это правило, которое разрешает модели не отвечать, если источников недостаточно. В production оно должно проверяться кодом, а не только prompt-инструкцией.

Нужно ли требовать citations?
Да, если ответ основан на базе знаний. Citations помогают проверить, что ответ связан с retrieved documents, а не придуман.

Какая метрика главная?
Unsafe answer rate и no-answer precision/recall. Лучше чаще отправить в review, чем уверенно ответить без источника.