--- title: "AI-классификатор писем в n8n: категории, приоритет — Nodbot" source_url: "https://nodbot.ru/ai/email-classifier/" canonical_url: "https://nodbot.ru/ai/email-classifier/" language: "ru" content_type: "AIGuide" section: "ai" generated_at: "2026-05-30" word_count_source: 1198 --- # AI-классификатор писем в n8n: категории, приоритет, confidence и безопасная маршрутизация ## AI summary Как собрать AI-классификатор писем в n8n: taxonomy, primary category, tags, priority, confidence threshold, fallback, dataset, тесты и маршрутизация. ## Best used for Страница объясняет «AI-классификатор писем в n8n: категории, приоритет — Nodbot» в контексте n8n/Nodbot: когда применять, как проверить внедрение и какие ошибки исключить. ## Key topics - Короткий ответ - Когда classifier лучше полного triage - Как спроектировать taxonomy - Primary category и tags - Как собрать workflow - Prompt и JSON output - Confidence threshold - Как делать priority отдельно от category ## Source outline # 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: - Category | Когда использовать | Кому отправлять - sales_inquiry | новый запрос на покупку, консультацию, демо | sales - support_issue | проблема с продуктом, ошибка, не работает | support - billing_payment | счёт, чек, оплата, возврат | finance/support - existing_customer_request | вопрос текущего клиента без аварии | account/support - complaint_escalation | жалоба, негатив, угроза оттока | senior support - partnership | партнёрство, интеграция, совместный проект | partnerships - vendor_offer | подрядчик предлагает услуги | procurement/general Не делайте отдельные категории “срочно”, “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 - Email Trigger — получает письмо. - Clean text — удаляет HTML, цитаты, подписи, tracking. - Pre-rules — ловит очевидный spam, auto-replies, bounce, unsubscribe. - Classifier — Text Classifier или LLM с JSON Schema. - Confidence gate — проверяет уверенность. - Priority rules — добавляет urgent/high/normal/low. - Router — отправляет в нужную очередь. - Label/writeback — ставит Gmail label, создаёт тикет или CRM task. - Human correction — оператор может изменить category. - 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 | Действие - ≥ 0.85 | автоматическая маршрутизация - 0.70–0.84 | маршрутизация + пометка review optional - 0.55–0.69 | general inbox/manual review - < 0.55 | unknown_review, не выполнять действия Не используйте 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 после каждой ошибки. Сначала классифицируйте ошибку: - Ошибка | Исправление - Плохая очистка письма | улучшить clean text - Категории пересекаются | уточнить taxonomy - Мало примеров класса | добавить dataset - Модель не видит контекст клиента | добавить CRM lookup - Письмо реально двусмысленное | отправлять в review - Ошибка в priority | вынести priority в правила Хороший 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. Это главный источник улучшений. ## Типовые ошибки - Слишком много категорий. Качество падает, а поддерживать сложно. - Нет unknown_review. Модель вынуждена выбирать неверный класс. - Нет разделения primary category и tags. Маршрутизация становится хаотичной. - Priority внутри prompt без правил. Модель переоценивает эмоциональные слова. - Нет dataset. Нельзя понять, стало лучше или хуже. - Classifier создаёт внешние ответы. Это уже triage/assistant, нужен другой контроль. ## Контроль качества AI-workflow AI-workflow по теме «AI-классификатор писем в 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-классификатор писем в 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-страницей, если нужен самый полный контекст.