AI classification pipeline в n8n: как распределять заявки, письма и события без хаоса ¶

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

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

AI classification pipeline нужен, когда входящий текст нужно отнести к одной или нескольким категориям: тип обращения, причина отказа, приоритет тикета, стадия лида, тема письма, риск платежа или направление маршрутизации. Надёжная классификация строится не на просьбе “определи категорию”, а на закрытом списке категорий, описаниях, примерах, negative examples, confidence, fallback и регулярных evals. Если классификатор ошибается, downstream workflow отправит тикет не той команде, поставит неправильный SLA или запустит не тот бизнес-процесс.

Где classification приносит пользу ¶

Классификация хорошо работает в операционной рутине: распределение обращений поддержки, сортировка писем, приоритизация лидов, определение intent в чат-боте, фильтрация отзывов, triage инцидентов, анализ причин churn, обработка заявок поставщиков. Главное отличие от extraction: classifier выбирает категорию, а не извлекает конкретные поля.

Примеры:

• письмо “Не могу войти, код не приходит” → account_access;
• тикет “после оплаты не пришёл чек” → billing_receipt;
• сообщение “интеграция упала после обновления” → technical_incident;
• лид “хотим автоматизировать отдел продаж” → sales_automation;
• отзыв “дорого, но удобно” → sentiment mixed + topic pricing.

Когда правила лучше AI ¶

Не используйте AI там, где есть точный признак. Если email отправителя billing@partner.ru, категория может быть задана правилом. Если сумма больше лимита, это rule-based priority. Если JSON event содержит event_type, не нужно классифицировать его моделью.

AI нужен, когда пользователь пишет свободно, неполно и разными словами. Часто лучший production-вариант — гибрид: сначала дешёвые правила, потом AI только для неоднозначных случаев.

Дизайн категорий ¶

Плохие категории — главная причина плохой классификации. Категории должны быть взаимно различимыми и полезными для маршрутизации. Не создавайте категории ради красоты. Если две категории ведут в один и тот же workflow, возможно, их не нужно разделять на первом этапе.

Плохой список:

• problem;
• issue;
• technical;
• other;
• user question;
• urgent.

Хороший список для поддержки:

• account_access — вход, пароль, 2FA, права;
• billing_payment — оплата, списание, чек, возврат;
• integration_error — API, webhook, OAuth, credentials;
• how_to — вопрос по настройке без явной поломки;
• feature_request — пожелание функциональности;
• incident — массовая проблема, недоступность сервиса;
• spam_or_irrelevant — нерелевантные обращения;
• unknown — недостаточно данных.

Категория unknown обязательна. Без неё модель будет принудительно выбирать неподходящую категорию.

Описания и examples ¶

Для каждой категории нужны positive и negative examples. Особенно важны negative examples для похожих классов.

Пример спецификации:

{
  "category": "billing_payment",
  "description": "Оплаты, чеки, возвраты, списания, счета, тарифы и документы по платежам.",
  "positive_examples": [
    "Не пришел чек после оплаты",
    "Списали два раза",
    "Как вернуть деньги за заказ?"
  ],
  "negative_examples": [
    "Не могу войти в аккаунт после оплаты — это account_access, если проблема во входе",
    "Webhook оплаты не доходит — это integration_error, если проблема техническая"
  ],
  "default_sla": "business_hours_4h"
}

Negative examples уменьшают путаницу между billing и integration. Пользователь может писать про оплату, но реальная проблема — webhook integration.

Схема workflow в n8n ¶

Production classification workflow:

1. Trigger: Email, Webhook, Chat, CRM, Telegram, Slack.
2. Normalize input: clean text, language, channel, user status, attachments.
3. Rule prefilter: spam, known senders, exact event_type, VIP, keywords критичных событий.
4. AI classification: Text Classifier или LLM со строгим JSON output.
5. Confidence scoring: модельный confidence + rule signals.
6. Tie-breaker: если две категории близки, применить priority rules.
7. Routing: команда, SLA, workflow, queue, tag.
8. Fallback: unknown, human review, уточняющий вопрос.
9. Audit log: input hash, category, confidence, model, prompt version, route.
10. Feedback loop: оператор исправляет категорию, dataset обновляется.

Не отправляйте весь HTML email в classifier. Он должен видеть чистый текст, тему письма, канал и ключевые признаки.

Пример output schema ¶

{
  "type": "object",
  "required": ["primary_category", "confidence", "reason", "routing_key"],
  "properties": {
    "primary_category": {
      "type": "string",
      "enum": [
        "account_access",
        "billing_payment",
        "integration_error",
        "how_to",
        "feature_request",
        "incident",
        "spam_or_irrelevant",
        "unknown"
      ]
    },
    "secondary_categories": {
      "type": "array",
      "items": { "type": "string" }
    },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
    "urgency": { "type": "string", "enum": ["low", "normal", "high", "critical"] },
    "reason": { "type": "string" },
    "routing_key": { "type": "string" }
  }
}

reason нужен не для пользователя, а для оператора и debug. Он должен объяснять, какие признаки повлияли на классификацию.

Confidence и fallback ¶

Не все категории одинаково рискованные. Для spam_or_irrelevant можно принять lower confidence, если есть дополнительные сигналы. Для incident или billing_payment threshold должен быть выше.

Пример правил:

Confidence не должен быть единственным критерием. Если пользователь VIP или сообщение содержит “данные клиентов утекли”, лучше эскалировать даже при средней уверенности.

Иерархическая классификация ¶

Если категорий много, разделите процесс на два шага. Сначала крупная группа, потом подкатегория. Например:

1. support, sales, billing, security, spam, unknown.
2. Если support, выбрать account_access, integration_error, how_to, bug_report.

Так модель меньше путается, а routing становится прозрачнее. Для каждого уровня можно использовать разные thresholds и разные prompts.

Multi-label classification ¶

Иногда сообщение относится к нескольким категориям. Например: “после оплаты не сработал webhook и сделка не создалась”. Primary category может быть integration_error, secondary — billing_payment. Downstream workflow должен знать, какая категория главная.

Правило:

• primary — команда, которая должна решить проблему;
• secondary — теги, контекст и дополнительные уведомления;
• urgency — отдельное поле, не категория.

Не смешивайте urgency и category. “Срочно” может относиться к любой теме.

Ошибки classification pipeline ¶

Evaluation: как измерять качество ¶

Для classifier недостаточно смотреть “вроде работает”. Нужны метрики:

• accuracy overall;
• precision/recall по каждой категории;
• confusion matrix;
• unknown rate;
• human override rate;
• false negative для critical/incident;
• средняя стоимость на item;
• latency per item;
• routing error rate.

Confusion matrix особенно полезна. Если billing_payment часто путается с integration_error, нужно не “добавить ещё один пример”, а пересмотреть определения категорий.

Пример eval case:

{
  "case_id": "payment_webhook_failed",
  "text": "Клиент оплатил, но сделка в CRM не создалась. В ЮKassa платеж успешен.",
  "expected_primary_category": "integration_error",
  "allowed_secondary": ["billing_payment"],
  "must_not_route_to": "billing_documents"
}

Логирование ¶

Логируйте:

• message_id;
• input_hash;
• clean_text_length;
• category_schema_version;
• model;
• prompt_version;
• primary_category;
• secondary_categories;
• confidence;
• routing_key;
• human_override;
• final_category.

Так вы сможете понять, изменилось ли качество после обновления prompt или модели.

Production checklist ¶

• [ ] Категории ведут к реальным actions.
• [ ] Есть unknown.
• [ ] Для каждой категории есть positive/negative examples.
• [ ] Urgency отделён от topic.
• [ ] Low confidence не маршрутизируется опасно.
• [ ] Есть human review для критичных классов.
• [ ] Есть eval dataset и confusion matrix.
• [ ] Есть feedback loop из правок операторов.
• [ ] Логируется final_category, а не только AI category.
• [ ] Есть versioning category schema.