Observability для AI workflows в n8n: как видеть, почему AI ответил именно так ¶

Q: Нужно ли логировать prompt целиком?

Лучше логировать prompt_version и template ID. Сам prompt храните в Git или CMS. В execution можно хранить только hash assembled prompt и redacted preview.

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

Открыть мой план

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

Observability для AI workflows в n8n нужна, чтобы ответить на четыре вопроса: что вошло в модель, какой prompt/model/route использовался, какие источники и tools повлияли на ответ, почему результат прошёл или не прошёл проверку. Обычного статуса success недостаточно: AI workflow может успешно завершиться и при этом дать плохой, дорогой, устаревший или опасный ответ. Production observability должна логировать input hash, prompt version, model route, latency, tokens/cost, retrieved documents, tool calls, schema validation, fallback, human review и пользовательскую оценку.

Почему стандартных execution logs мало ¶

Execution log показывает, какие nodes выполнились и где произошла техническая ошибка. Но в AI-процессах самые важные сбои часто не технические:

ответ правдоподобный, но без источника;
JSON валиден, но поле category неверное;
RAG нашёл устаревший документ;
агент вызвал tool с неправильным параметром;
fallback сработал слишком часто;
расходы выросли из-за retry loop;
модель стала хуже после правки промпта;
оператор переписал 70% AI-черновиков.

Для таких случаев нужна отдельная AI observability layer.

Что считать событием observability ¶

Каждый AI workflow должен создавать структурированную запись ai_run. Она не обязана быть отдельной таблицей на старте, но должна существовать хотя бы как JSON в логах или базе.

{
  "ai_run_id": "airun_20260529_000123",
  "workflow_id": "support_bot_v4",
  "execution_id": "n8n_execution_id",
  "tenant_id": "acme",
  "task_type": "rag_answer",
  "input_hash": "sha256:...",
  "pii_state": "redacted",
  "prompt_version": "support_rag_v9",
  "schema_version": "answer_with_sources_v3",
  "model_route": "quality_rag",
  "model": "quality-long-context",
  "latency_ms": 6420,
  "tokens_in": 5300,
  "tokens_out": 410,
  "estimated_cost_usd": 0.038,
  "retrieved_sources": ["doc:billing:v12", "doc:refund:v7"],
  "tool_calls": [],
  "validation_status": "passed",
  "fallback_used": false,
  "human_review": "not_required",
  "user_feedback": null
}

Главное — не сохранять лишнюю персональную информацию. Для debugging обычно хватает hash, redacted excerpt, IDs источников и версий.

Пять уровней наблюдаемости ¶

1. Технический уровень ¶

Показывает, работает ли workflow: execution status, node errors, retries, timeouts, HTTP-коды, queue delays, worker errors. Это база для ops-команды.

2. Модельный уровень ¶

Показывает, как работала LLM: model, route, prompt version, temperature, tokens, latency, cost, fallback, parser errors.

3. Контекстный уровень ¶

Показывает, какие данные получила модель: RAG source IDs, chunk IDs, retrieval scores, metadata filters, context length, redaction status.

4. Tool/action уровень ¶

Показывает, какие действия хотел или успел выполнить агент: tool name, arguments hash, approval status, API response, idempotency key, side effect status.

5. Качественный уровень ¶

Показывает, был ли ответ хорошим: schema validation, eval score, user feedback, operator edit distance, escalation, refund/reopen/complaint.

Что логировать для разных типов AI workflow ¶

Workflow	Ключевые поля
Email classifier	input hash, class, confidence, route, manual correction
RAG bot	query, source IDs, retrieval score, answer confidence, no-answer policy
AI Agent	tool calls, arguments, approval status, side effects, rollback ID
JSON extraction	schema version, missing fields, parser errors, repair attempts
Summarization	source document IDs, compression ratio, omitted sections
Lead scoring	score, reasons, CRM fields used, human override
Support draft	AI draft, operator edit summary, final sent status

Как реализовать observability в n8n ¶

Минимальная схема:

В начале workflow создать request_id.
После pre-processing записать input_hash, pii_state, task_type.
Перед LLM записать prompt_version, model_route, schema_version.
После LLM записать latency, token/cost estimate, raw status.
После validation записать validation_status, errors, confidence.
После RAG записать source IDs и retrieval scores.
После tools записать tool name, arguments hash, approval, API status.
В конце записать final_status и user-visible response type.

Хранилище может быть Postgres, Google Sheets для раннего этапа, BigQuery, ClickHouse, ELK, OpenTelemetry pipeline или внутренний logging-сервис. Главное — не оставлять AI-решения только внутри canvas.

Пример Code node: стандартное AI-событие ¶

const crypto = require('crypto');

function hash(value) {
  return crypto.createHash('sha256').update(String(value || '')).digest('hex');
}

return [{
  json: {
    event_type: 'ai_run_completed',
    request_id: $json.request_id,
    workflow_key: $json.workflow_key,
    execution_id: $execution.id,
    task_type: $json.task_type,
    input_hash: hash($json.redacted_input || $json.input),
    prompt_version: $json.prompt_version,
    schema_version: $json.schema_version,
    model_route: $json.model_route,
    model_name: $json.model_name,
    latency_ms: $json.latency_ms,
    tokens_in: $json.tokens_in,
    tokens_out: $json.tokens_out,
    estimated_cost_usd: $json.estimated_cost_usd,
    validation_status: $json.validation_status,
    fallback_used: Boolean($json.fallback_used),
    human_review_status: $json.human_review_status || 'not_required',
    retrieved_sources: $json.retrieved_sources || [],
    created_at: new Date().toISOString()
  }
}];

Как анализировать плохой ответ ¶

Когда пользователь жалуется, нужно пройти цепочку:

Найти request_id или execution.
Проверить raw input и redacted input.
Проверить route: правильная ли модель была выбрана.
Проверить prompt/schema versions.
Проверить RAG: какие документы попали в context.
Проверить tool calls: какие параметры ушли во внешние системы.
Проверить validation: почему ответ считался passed.
Проверить fallback: не был ли это degraded answer.
Проверить user feedback и operator edit.
Исправить не только промпт, но и тестовый набор.

Плохой ответ редко чинится одной фразой в prompt. Часто причина в retrieval, route, stale document, отсутствующем schema field или слишком широких tool permissions.

Метрики, которые нужны каждую неделю ¶

Метрика	Что показывает
`ai_success_rate`	технически успешные AI runs
`validated_output_rate`	сколько ответов прошли schema/quality gate
`fallback_rate`	насколько часто primary path не справляется
`human_review_rate`	сколько решений требует человека
`operator_edit_rate`	насколько AI-черновики переписываются
`cost_per_success`	цена одного валидного результата
`p95_latency_ms`	UX и SLA
`rag_no_answer_rate`	качество retrieval/coverage
`tool_denied_rate`	насколько часто human отклоняет tool call
`stale_source_rate`	проблемы freshness в RAG

Не смотрите только на среднее. В AI workflow важны p95/p99 latency, худшие категории и дорогие outliers.

Evals как часть observability ¶

Observability показывает, что произошло в production. Evaluations показывают, сломается ли workflow после изменения. Нужно связать их:

каждый prompt version имеет evaluation dataset;
каждый model route проходит тесты до релиза;
RAG changes проверяются на golden questions;
schema changes проверяются на parser errors;
fallback changes проверяются на искусственных 429/timeout/invalid JSON.

Если production feedback ухудшился, добавьте эти реальные кейсы в evaluation dataset. Так система учится не повторять старые ошибки.

Privacy: что нельзя логировать ¶

Нельзя бездумно сохранять:

raw prompt с персональными данными;
access tokens и API keys;
cookie/session headers;
полные CRM-профили;
документы клиентов;
банковские реквизиты;
medical/legal sensitive data;
private chat history.

Безопаснее хранить hash, redacted excerpt, IDs объектов и версии источников. Для incident analysis можно иметь ограниченный secure storage с коротким retention, но он должен быть отделён от обычных логов.

Alerting ¶

Настройте alerts на:

fallback rate выше порога;
cost spike за час/день;
p95 latency выше SLA;
parser error rate выше нормы;
рост human review deny rate;
RAG retrieval score ниже порога;
резкий рост no-answer;
tool call failures;
повторяющиеся safety refusals;
cache stale hits.

Alert должен вести не просто в execution, а в runbook: что проверить, какие графики открыть, какие routes отключить.

FAQ ¶

Достаточно ли n8n executions для AI observability? ¶

Для отладки node-level ошибок — да. Для анализа качества, стоимости, RAG-источников, model routing и tool decisions — нет. Нужна структурированная запись AI-событий.

Нужно ли хранить raw output модели? ¶

На staging — полезно. В production — зависит от данных. Если в output может быть PII, храните redacted output, hash и secure reference с коротким retention.

Как считать стоимость, если node не отдаёт tokens? ¶

Можно оценивать по длине текста и известным тарифам модели, но помечать как estimate. Для точного учёта используйте провайдера/API, который возвращает usage, или отдельный billing log.

Что важнее: logs или evals? ¶

Оба. Logs показывают реальные сбои. Evals предотвращают повторение и проверяют изменения до релиза.

Как observability помогает SEO/LLM-сайту? ¶

Если сайт использует AI-бота или генерацию ответов, observability позволяет видеть, какие вопросы пользователи задают, где RAG не находит источник, какие темы нужно закрыть статьями и где контент устарел.

Нужно ли логировать prompt целиком? ¶

Лучше логировать prompt_version и template ID. Сам prompt храните в Git или CMS. В execution можно хранить только hash assembled prompt и redacted preview.

Как отследить hallucination? ¶

Через сочетание source coverage, eval score, user feedback, operator corrections и no-source answer detection. Просто искать слово «не знаю» недостаточно.

Что делать с жалобой пользователя? ¶

Превратить её в test case. Найдите execution, классифицируйте причину, исправьте workflow и добавьте пример в eval dataset.