Авторский разбор. Ссылки на материалы, использованные при подготовке, приведены в конце.
В n8n можно поставить HTTP Request между вебхуком и Switch. Обычно сценарий упирается в следующий узел: что делать со свободным ответом модели? Строку «похоже, это вопрос об оплате» снова приходится разбирать. Jev вызывается через HTTP Request и возвращает вариант из заданного списка, вероятности и confidence. Switch сравнивает поле choice, а код отдельно решает, можно ли продолжать сценарий.
Этот подход подходит для места, где вход остаётся неструктурированным, а выход уже должен иметь известную форму: определить очередь обращения, проверить срочность, оценить тон сообщения. n8n держит вебхук, расписание, ветки и интеграции. Jev отвечает на короткий вопрос по тексту. Отмена заказа, письмо клиенту и изменение записи остаются отдельными узлами сценария.
Что уходит в HTTP Request
Jev принимает state и объект questions на POST https://api.typesafe.ai/v1/systemone. Вопросы из одного запроса видят одинаковое состояние, но не используют ответы друг друга. Для обращения в поддержку можно одновременно выбрать очередь, проверить срочность и оценить раздражение клиента.
{
"state": {
"ticket": {
"subject": "Деньги списались дважды",
"message": "В выписке два одинаковых списания. Проверьте, пожалуйста.",
"plan": "business"
}
},
"model": "jev-latest",
"questions": {
"department": {
"type": "choice",
"instructions": "Какая очередь должна обработать `ticket`?",
"criteria": {
"billing": "Оплата, списание, возврат или подписка.",
"technical": "Ошибка продукта, интеграция или доступ.",
"sales": "Тариф, условия или покупка.",
"manual_review": "Очередь неясна или ни один вариант не подходит."
}
},
"urgency": {
"type": "noul",
"instructions": "В `ticket.subject` или `ticket.message` есть срочность, из-за которой ответ нельзя откладывать?"
},
"frustration": {
"type": "score",
"instructions": "Насколько клиент раздражён в `ticket.message`?",
"criteria": [
"Спокойно описывает ситуацию.",
"Недоволен, но пишет нейтрально.",
"Сильно раздражён или использует резкие формулировки."
]
}
}
}
У Choice в ответе есть выбранный ключ, распределение вероятностей и confidence. Score добавляет номер уровня и легенду. Noul возвращает вероятность «да» без отдельного confidence. Код должен учитывать эту разницу, а не сводить все ответы к одному общему числу.
Файлы для импорта
Маршрутизация обращения запускается вручную. Она формирует тестовое сообщение, вызывает Jev, собирает решение в Code и разводит его через Switch. Ветка manual_review срабатывает при низкой уверенности или срочном обращении. Остальные ветки заканчиваются No Operation. После проверки на своих данных к ним можно подключить систему поддержки.
Проверка намерения через вебхук принимает POST с orderId, orderStatus и message. В ответ вызывающий сервис получает JSON с decision, intent, confidence и reason. Запрос на отмену или возврат приводит к confirm_or_review. Экспорт не меняет заказ и не вызывает внешнюю систему.
В обоих файлах HTTP Request собирает тело из state и questions выражением n8n. Код перед запросом держит тестовые данные и вопросы в одном месте. Код после ответа читает поля из answers и применяет явное условие.
Ключ и данные не должны жить в экспорте
В заголовке HTTP Request указан Bearer REPLACE_WITH_YOUR_TYPESAFE_API_KEY. Это плейсхолдер. После импорта лучше создать в n8n отдельную credential типа Header Auth со значением Authorization: Bearer <ваш ключ>, подключить её к HTTP Request и убрать строку из узла. Тогда ключ не окажется в Git, истории экспорта или на скриншоте сценария.
Текст из state уходит во внешний API TypeSafe. Перед передачей письма клиента, договора или записи разговора стоит проверить, допускают ли это правила компании и требования к хранению. Сам способ запуска n8n не делает такой маршрут локальным.
Confidence не даёт разрешения на действие
В файле с маршрутизацией порог 0.70 показывает механизм, а не готовую политику. При меньшем значении обращение попадает на ручную проверку. Для Choice confidence строится из распределения вероятностей по вариантам. У Noul отдельного confidence нет, а значение около 0.5 означает неопределённость ответа «да». Число 0.70 не обещает, что семь решений из десяти окажутся верными.
Порог зависит от последствия ошибки. Ошибочная очередь обычно обратима. Отмена заказа, изменение тарифа или раскрытие данных требуют другой границы. Поэтому сценарий с вебхуком автоматически разрешает только показ статуса при intent: status и confidence не ниже 0.85. Возврат и отмена остаются на подтверждении даже при высоком значении.
Перед автоматической веткой нужен собственный набор размеченных обращений. На нём можно увидеть случаи, похожие словами, но разные по последствиям: «я хочу вернуть товар» и «покажите, как оформить возврат». Модель может уверенно отнести оба сообщения к теме возврата, хотя продукту для них нужны разные действия.
Когда запрос стоит разделить
Очередь, срочность и тон зависят от исходного текста, поэтому их можно передать в Jev одним запросом. n8n получит независимые ответы и выберет, какие поля использовать в ветке.
Дополнительный вызов появляется, когда сценарий получает новый факт для следующего решения. Например, Jev выбирает тип обращения, n8n по нему запрашивает в CRM историю платежей, и только потом спрашивает о возможности возврата. Здесь между вызовами изменилось состояние. Если новых данных нет, ещё один запрос только удлинит сценарий и усложнит отладку.
Jev даёт n8n типизированный сигнал там, где обычного правила недостаточно. Условия, пороги, подтверждение и побочное действие остаются читаемыми узлами сценария. Их можно проверить и изменить, не пытаясь извлечь решение из абзаца модели.