AI-классификатор писем в n8n: категории, приоритет, confidence и безопасная маршрутизация ¶

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

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

AI-классификатор писем в n8n нужен, чтобы присвоить входящему письму категорию, приоритет и дополнительные теги для маршрутизации. В отличие от полного email triage, classifier не обязан извлекать все сущности и писать ответ: он должен точно решить, куда направить письмо и насколько уверен в решении. Надёжная схема: очистка письма → taxonomy → Text Classifier или LLM JSON → confidence threshold → fallback для сомнительных писем → routing → human correction log. Главный риск — слишком много категорий и отсутствие тестового dataset.

Когда classifier лучше полного triage ¶

Classifier подходит, если вам нужно быстро разложить письма по очередям: support, sales, billing, vendor, spam, internal, legal, partnership. Это проще, дешевле и стабильнее, чем строить полноценный triage с extraction, scoring и reply generation. Если ваша боль — “письма попадают не тем людям”, начните с classifier.

Полный triage нужен позже, когда вы хотите не только направить письмо, но и извлечь order_id, создать тикет, рассчитать SLA, подготовить ответ и обновить CRM. Classifier — первый слой. Он должен быть узким и проверяемым.

Как спроектировать taxonomy ¶

Taxonomy — это список классов. Самая частая ошибка — взять все возможные темы компании и сделать 40 категорий. Модель начнёт путать близкие классы, оператор не поймёт разницу, а тестирование станет дорогим. Начните с рабочих очередей, а не с красивой онтологии.

Хорошая первая taxonomy:

Не делайте отдельные категории “срочно”, “VIP”, “счёт с проблемой”. Это лучше теги или priority, а не primary category.

Primary category и tags ¶

Разделяйте основную категорию и теги. Primary category выбирает очередь. Tags добавляют контекст.

{
  "primary_category": "support_issue",
  "tags": ["urgent", "webhook", "existing_customer"],
  "priority": "high",
  "confidence": 0.86,
  "reason": "Письмо от текущего клиента сообщает, что заявки перестали попадать в CRM после изменения webhook."
}

Если сделать multi-label без primary category, workflow не поймёт, куда отправлять письмо. Например, письмо может быть одновременно billing, complaint и existing_customer. Primary category решает действие, tags помогают внутри очереди.

Как собрать workflow ¶

1. Email Trigger — получает письмо.
2. Clean text — удаляет HTML, цитаты, подписи, tracking.
3. Pre-rules — ловит очевидный spam, auto-replies, bounce, unsubscribe.
4. Classifier — Text Classifier или LLM с JSON Schema.
5. Confidence gate — проверяет уверенность.
6. Priority rules — добавляет urgent/high/normal/low.
7. Router — отправляет в нужную очередь.
8. Label/writeback — ставит Gmail label, создаёт тикет или CRM task.
9. Human correction — оператор может изменить category.
10. Dataset update — сохраняет ошибку для оценки.

Pre-rules важны. Не тратьте LLM на автоответы “out of office”, bounce notifications и очевидный spam, если их можно поймать регулярками.

Prompt и JSON output ¶

Даже если вы используете Text Classifier node, полезно иметь строгий контракт результата. Если используете LLM напрямую, обязательно требуйте JSON.

{
  "primary_category": "sales_inquiry | support_issue | billing_payment | existing_customer_request | complaint_escalation | partnership | vendor_offer | spam_or_noise | internal_forward | unknown_review",
  "tags": ["urgent", "vip", "refund", "technical", "crm", "webhook"],
  "priority": "urgent | high | normal | low",
  "confidence": 0.0,
  "reason": "короткое объяснение на русском"
}

В prompt укажите правила разграничения. Например: если письмо содержит жалобу и вопрос оплаты, но эмоционально негативное и требует эскалации, primary category = complaint_escalation, tag = billing_payment. Если письмо от подрядчика предлагает SEO, это vendor_offer, не sales_inquiry.

Confidence threshold ¶

Confidence нужен не для красоты, а для маршрутизации риска. Пример:

Не используйте confidence как абсолютную истину. Модели могут быть уверены и ошибаться. Но threshold помогает не делать опасные автоматические действия на сомнительных письмах.

Как делать priority отдельно от category ¶

Priority должен учитывать бизнес-правила:

• текущий клиент > новый vendor;
• enterprise/VIP > free;
• production down > общий вопрос;
• payment/refund > информационный запрос;
• negative sentiment + churn words > escalation;
• дедлайн сегодня > обычный запрос.

Пример Code node:

let priority = 'normal';
const tags = new Set($json.tags || []);
if (tags.has('urgent') || tags.has('vip')) priority = 'high';
if ($json.primary_category === 'complaint_escalation') priority = 'high';
if (/не работает|лежит|потеряли|суд|претензия/i.test($json.clean_email_text || '')) priority = 'urgent';
return [{ json: { ...$json, priority } }];

Категория “support_issue” может быть normal или urgent. Не смешивайте эти измерения.

Как тестировать classifier ¶

Соберите dataset из реальных писем. Для каждого письма human label должен включать primary category, tags и priority. Удалите персональные данные или замените их токенами. Разделите набор: development cases и evaluation cases. Не тестируйте только на примерах, по которым писали prompt.

Метрики:

• overall accuracy;
• per-category precision/recall;
• confusion matrix;
• urgent recall;
• false escalation rate;
• unknown_review rate;
• manual correction rate;
• cost per 1000 emails;
• latency per email.

Особенно смотрите confusion matrix. Если sales_inquiry часто путается с partnership, возможно, categories плохо описаны. Если billing_payment путается с support_issue, добавьте правила priority/tags.

Как улучшать качество ¶

Не переписывайте prompt после каждой ошибки. Сначала классифицируйте ошибку:

Хороший classifier улучшается через dataset и taxonomy, а не через бесконечные “будь внимательнее”.

Что логировать ¶

Сохраняйте:

• email id/thread id;
• clean text hash;
• model/prompt/schema version;
• category/tags/priority/confidence;
• route;
• human corrected category;
• time to route;
• downstream outcome;
• source mailbox.

Если оператор поменял категорию, сохраняйте both predicted and final. Это главный источник улучшений.

Типовые ошибки ¶

1. Слишком много категорий. Качество падает, а поддерживать сложно.
2. Нет unknown_review. Модель вынуждена выбирать неверный класс.
3. Нет разделения primary category и tags. Маршрутизация становится хаотичной.
4. Priority внутри prompt без правил. Модель переоценивает эмоциональные слова.
5. Нет dataset. Нельзя понять, стало лучше или хуже.
6. Classifier создаёт внешние ответы. Это уже triage/assistant, нужен другой контроль.