Нейросеть читает заявку и определяет категорию

В предыдущем уроке заявки разделялись на ветки через узел IF: условие проверяло точное значение поля — например, priority равен «high» или нет. Это работает, когда данные строго структурированы. Но что делать, если нужно понять смысл свободного текста — «хочу купить прямо сейчас» или «просто интересуюсь»? Жёсткое условие здесь не поможет. Именно для таких случаев в n8n есть узел Text Classifier, который передаёт решение языковой модели.

Text Classifier и chat model: архитектура AI-классификации в n8n

Text Classifier — это узел из группы AI/Langchain в n8n. Его задача проста: взять текстовый item и отнести его к одной из заранее заданных категорий. Никакого кода, никаких регулярных выражений — узел передаёт текст языковой модели, и та решает, куда его направить.

Сам по себе Text Classifier не умеет ничего — у него нет встроенного интеллекта. Чтобы он заработал, к нему нужно подключить chat model. Это дочерний узел (sub-node), который появляется прямо под основным узлом на холсте — визуально как отдельный блок со своей точкой подключения. Chat model — это мост к конкретной языковой модели: OpenAI GPT, Anthropic Claude или любой другой совместимой.

Важно понимать разделение ответственности:

• Text Classifier отвечает за логику классификации: какие категории есть, что значит каждая, какое поле item читать.
• Chat model отвечает за подключение к API: какую модель использовать, какие credentials применить.

API-ключ задаётся именно в настройках sub-node chat model, а не в самом Text Classifier. Это не очевидно с первого взгляда — интерфейс выглядит как один рабочий блок, но под капотом это два отдельных узла с разными настройками.

Такая архитектура даёт гибкость: можно поменять модель (например, с GPT-4o на другую) прямо в sub-node, не трогая логику категорий в основном узле. Или наоборот — перенастроить категории, оставив подключение к API без изменений.

Text Classifier, chat model и выходы категорий.

Категории классификатора: как имя и описание управляют решением модели

Когда Text Classifier получает текст заявки, он не угадывает категорию — он опирается на то, что вы ему объяснили. Каждая категория задаётся двумя полями: Name и Description.

Name — это короткий идентификатор: «горячая», «обычная», «нецелевая». По нему называется выходной порт узла.

Description — это инструкция для модели. Именно её модель читает, когда решает, куда отправить конкретный текст. По сути, вы пишете модели: «вот как выглядит заявка этой категории».

Разница между полезным и бесполезным описанием очень конкретная. Возьмём категорию «горячая»:

❌ Плохо:

Важная заявка.

✅ Хорошо:

Клиент выражает готовность купить прямо сейчас, просит реквизиты или способ оплаты, использует слова «срочно», «как оплатить», «хочу сразу».

В первом случае модель не понимает, что значит «важная» — и начинает угадывать. Во втором у неё есть конкретные сигналы: поведение клиента, типичные формулировки, намерение.

Для трёх категорий этого урока описания могут выглядеть примерно так:

• горячая — клиент готов к покупке прямо сейчас, спрашивает про оплату, доставку или оформление заказа; в тексте есть явное намерение купить.
• обычная — клиент задаёт вопрос по продукту или функционалу, интересуется деталями, но не выражает срочности и готовности купить немедленно.
• нецелевая — текст не связан с продуктом или услугой: спам, случайные вопросы, нерелевантные запросы.

Если описания перекрываются или слишком размыты, модель начинает ошибаться на граничных случаях. Типичный симптом: контрольная заявка «Есть вопрос по функционалу, не срочно» попадает в порт «горячая», потому что в описании «горячей» было что-то вроде «клиент интересуется продуктом». Модель решила, что интерес = горячая заявка.

Фиксится это не перезапуском, а правкой Description: нужно сделать границы между категориями явными. Если две категории кажутся похожими, в описании каждой стоит написать, чем она отличается от соседней — это сильно помогает модели провести чёткую границу.

Выходные порты и маршрутизация: как Text Classifier разветвляет поток

После того как модель определила категорию, Text Classifier должен куда-то направить item. Для этого у узла есть выходные порты — по одному на каждую настроенную категорию.

Если вы добавили три категории — «горячая», «обычная», «нецелевая» — на холсте у узла появятся три выходных порта с соответствующими именами. Item уходит ровно в один из них: тот, который соответствует решению модели. Остальные порты в этом запуске остаются пустыми.

Это поведение аналогично узлу IF, с которым вы работали в прошлом уроке. Там условие ветвления было жёстким: поле priority равно high — item идёт в ветку True, иначе — в False. Text Classifier делает то же самое, но без формулы. Вместо проверки конкретного значения поля решение принимает языковая модель по смыслу текста.

Практически это означает, что вы подключаете следующие узлы прямо к выходным портам Text Classifier — по одному на каждую ветку. Например:

• к порту «горячая» — узел, который отправляет уведомление менеджеру;
• к порту «обычная» — узел, который записывает заявку в очередь;
• к порту «нецелевая» — узел, который архивирует или игнорирует запрос.

Главное отличие от IF: число веток не ограничено двумя. Хотите пять категорий — будет пять портов. IF на такое не способен без вложенных условий, а Text Classifier просто добавляет новую строку в список категорий.

Ещё один нюанс: при пакетной обработке разные items из одного запуска могут уйти в разные порты. Если вы запустили три контрольные заявки одновременно, каждая из них пройдёт классификацию независимо и окажется в своём порту. Это важно понимать при проверке результата: смотреть нужно не на общий вывод узла, а на содержимое каждого отдельного порта.

Пошаговая настройка и проверка на контрольных заявках

Теория разобрана — теперь собираем узел руками. Вот полная последовательность действий.

1. Добавить узел Text Classifier на холст

Откройте панель узлов, найдите Text Classifier в группе AI/Langchain и перетащите его на холст. Соедините входной порт узла с выходом предыдущего узла в вашем workflow — того, который передаёт заявки дальше по цепочке.

2. Указать поле с текстом заявки

Внутри настроек узла найдите поле Input Field. Сюда нужно вписать точное имя ключа из JSON-структуры item, в котором лежит текст заявки. Если предыдущий узел передаёт данные с ключом description — вписывайте именно description, без кавычек и без опечаток. Перед тем как вписать, откройте панель Input узла Text Classifier и в режиме JSON убедитесь, что ключ называется именно так.

3. Добавить три категории

В секции категорий добавьте три записи. Описания категорий разобраны в предыдущем разделе — используйте их как основу. Ключевые маркеры для каждой категории:

Name	Маркеры для Description
горячая	готовность купить прямо сейчас, вопросы про оплату и оформление заказа
обычная	вопрос по продукту или функционалу, без срочности и готовности купить немедленно
нецелевая	текст не связан с продуктом — спам, посторонние вопросы

Чем точнее Description, тем надёжнее классификация. Если на шаге 5 одна из заявок попадёт не в тот порт — вернитесь сюда и уточните описание.

4. Подключить sub-node chat model

Под блоком Text Classifier на холсте есть точка подключения для модели. Кликните по ней — появится список доступных типов chat model. Выберите нужный (например, OpenAI), задайте credentials с API-ключом. После подключения sub-node визуально появится под основным узлом как отдельный маленький блок.

5. Запустить тест на трёх контрольных заявках

Подайте на вход три заявки и проверьте, в каком выходном порту оказался каждый item:

• «Хочу купить прямо сейчас, подскажите как оплатить» → должна попасть в порт горячая.
• «Есть вопрос по функционалу, не срочно» → должна попасть в порт обычная.
• «Привет, хочу узнать рецепт борща» → должна попасть в порт нецелевая.

Смотреть нужно не на общий вывод узла, а кликать по каждому выходному порту отдельно — только так видно, куда ушёл конкретный item.

Диагностика: если классификатор читает не тот текст

Если все три заявки уходят в одну и ту же категорию, или узел возвращает ошибку — первым делом проверьте поле Input Field. Это самая частая причина сбоя: имя поля в настройках узла не совпадает с реальным ключом в JSON item.

Как проверить: кликните на узел Text Classifier, откройте вкладку Input и переключитесь в режим JSON. Найдите поле с текстом заявки и скопируйте его ключ дословно — именно его и нужно вставить в Input Field.

Распространённая ловушка: форма-триггер может передавать поле с пробелами или кириллицей в имени, например Описание проблемы. Если в Input Field стоит description, а реальный ключ — Описание проблемы, классификатор получает пустое значение и классифицирует «ничего».

После исправления Input Field перезапустите тест — три контрольные заявки должны разойтись по трём разным портам. Это и есть критерий корректной настройки.