---
title: "AI classification pipeline в n8n: как распределять — Nodbot"
source_url: "https://nodbot.ru/ai/ai-classification-pipeline/"
canonical_url: "https://nodbot.ru/ai/ai-classification-pipeline/"
language: "ru"
content_type: "AIGuide"
section: "ai"
generated_at: "2026-05-30"
word_count_source: 1304
---

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

## AI summary

AI-гайд для n8n: AI classification pipeline в n8n: как распределять заявки. Архитектура workflow, ограничения, проверки качества, безопасность и cost control.

## Best used for

Страница объясняет «AI classification pipeline в n8n: как распределять — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить.

## Key topics

- Короткий ответ
- Где classification приносит пользу
- Когда правила лучше AI
- Дизайн категорий
- Описания и examples
- Схема workflow в n8n
- Пример output schema
- Confidence и fallback

## Source outline

# 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 только для неоднозначных случаев.

- Ситуация | Подход
- Есть точный event_type | Rule
- Есть email/domain отправителя | Rule + lookup
- Свободный текст клиента | AI classification
- Нужно определить urgency по смыслу | AI + rules по VIP/SLA
- Категория влияет на деньги | AI + human review
- Категорий больше 30 | Иерархическая классификация

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

Плохие категории — главная причина плохой классификации. Категории должны быть взаимно различимыми и полезными для маршрутизации. Не создавайте категории ради красоты. Если две категории ведут в один и тот же 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:

- Trigger : Email, Webhook, Chat, CRM, Telegram, Slack.
- Normalize input : clean text, language, channel, user status, attachments.
- Rule prefilter : spam, known senders, exact event_type, VIP, keywords критичных событий.
- AI classification : Text Classifier или LLM со строгим JSON output.
- Confidence scoring : модельный confidence + rule signals.
- Tie-breaker : если две категории близки, применить priority rules.
- Routing : команда, SLA, workflow, queue, tag.
- Fallback : unknown, human review, уточняющий вопрос.
- Audit log : input hash, category, confidence, model, prompt version, route.
- 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 ≥ 0.85 | автоматический routing
- 0.65–0.84 | routing + пометка “AI uncertain”
- < 0.65 | human review или уточняющий вопрос
- category = incident и confidence < 0.9 | дублировать в on-call queue
- category = unknown | не запускать бизнес-действия

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

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

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

- support , sales , billing , security , spam , unknown .
- Если 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

- Ошибка | Что происходит | Как исправить
- Нет категории unknown | модель выбирает случайный класс | добавить unknown и правила fallback
- Категории пересекаются | billing путается с integration | negative examples и tie-breaker
- Слишком много классов | качество падает | иерархия категорий
- Нет feedback loop | ошибки повторяются | сохранять human corrections
- Категория = SLA | SLA считается неверно | urgency отдельно от topic
- Нет evals | правка prompt ломает routing | golden dataset и confusion matrix

## 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.

## Контроль качества AI-workflow

AI-workflow по теме «AI classification pipeline в 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, пустой вход, повтор и сбой внешнего сервиса для «AI classification pipeline в 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-страницей, если нужен самый полный контекст.