Маршрутизация писем и обращений с Jev: от демонстрации классификации до полноценного бизнес-процесса

Быстро разнести 500 писем по нескольким категориям — понятная демонстрация возможностей Jev.

Автор одного из примеров сообщества сообщил, что Jev способен пакетно классифицировать 500 писем за несколько секунд примерно за 0.035 доллара. Однако в этой демонстрации не раскрывались состав выборки, определения категорий, ручная разметка, точность и матрица ошибок. Поэтому ее разумнее воспринимать как иллюстрацию возможного способа вызова, а не как доказательство того, что такой подход уже способен заменить промышленную маршрутизацию обращений в поддержку.

В реальной системе электронной почты и тикетов сложность заключается не только в вопросе «в какой отдел отправить это письмо?».

Одно обращение может одновременно содержать сведения о двойном списании, требование возврата, угрозу чарджбэка и жалобу на неоднократно нерешенную проблему. Отнести его в очередь billing может быть формально правильно, но система все равно рискует пропустить сигналы, требующие наивысшего приоритета.

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

Письмо или обращение в поддержку
   ↓
Предобработка: извлечь тему, текст и необходимый контекст предыдущей переписки
   ↓
Jev: выбор очереди, выявление возврата, выявление рисков, оценка срочности
   ↓
Бизнес-правила: объединить вероятности, пороги, данные клиента и политику компании
   ↓
Автоматическая маршрутизация / ручная проверка / эскалация высокого риска / подготовка черновика ответа

Главное разделение ответственности здесь такое: Jev выполняет семантические оценки, код управляет потоком, а сотрудник поддержки или генеративная модель готовит окончательный ответ.

Почему Jev подходит для этого слоя решений

Jev — не чат-модель, ориентированная на создание длинного текста. Она получает state и отвечает на заранее определенные разработчиком typed questions. В основном используются три формы:

Тип	Подходящий вопрос	Результат
Choice	В какую очередь лучше всего направить это обращение?	Один вариант, вероятности всех вариантов и confidence
Noul	Пользователь прямо просит вернуть деньги?	Вероятность ответа «да» от 0 до 1
Score	К какому уровню срочности относится обращение?	Балл, вероятности уровней и confidence

Несколько вопросов можно оценить параллельно в одном запросе. Вместо того чтобы просить модель прочитать обращение, написать разбор, а затем заставлять программу извлекать смысл из этого текста, удобнее задать несколько атомарных вопросов, результаты которых сразу пригодны для последующего кода.

Однако типизированный ответ гарантирует только соответствие результата заранее заданному интерфейсу. Он не гарантирует правильность бизнес-решения. Системе по-прежнему нужны пороги, резервные сценарии, ручная проверка и офлайн-оценка.

Одно обращение нельзя сводить к одному вопросу

Предположим, пользователь отправил такое письмо:

После перехода на тариф Pro с меня дважды списали оплату. Я написал вам три дня назад, но проблему до сих пор никто не решил. Верните деньги сегодня, иначе я оспорю платеж через банк.

Если спросить только «к какому отделу относится это письмо?», ответ, вероятно, будет billing. Но промышленной системе необходимо знать как минимум еще четыре вещи:

Решение	Тип вопроса	Рекомендуемые варианты или критерии	Назначение
В какую основную очередь направить обращение?	Choice	billing / shipping / technical / account / sales / legal / none	Первичная маршрутизация
Есть ли требование возврата?	Noul	Явная просьба вернуть средства, отменить списание или возместить платеж считается ответом «да»	Запуск процесса возврата
Есть ли риск чарджбэка, обращения к регулятору или юридического спора?	Noul	Упоминание chargeback, жалобы в банк, регулятора или судебных действий	Эскалация высокого риска
Срочность	Score	Обычный вопрос без срока / проблема уже мешает пользоваться сервисом или пользователь обращался повторно / финансовый ущерб, чарджбэк либо явный срок	Приоритет в очереди
Требуется ли участие человека?	Noul	Деньги, юридические вопросы, повторно нерешенная жалоба или неуверенное решение модели	Решение о допустимости автоматической обработки

Эти вопросы связаны между собой, но их не следует объединять в один запрос вроде «определи в целом, как обработать это обращение».

Официальные рекомендации по проектированию Jev предлагают раскладывать сложную задачу на атомарные суждения. После разделения вопросов бизнес-код может независимо решить, куда направить обращение, нужно ли повысить приоритет, следует ли приостановить автоматический ответ и требуется ли уведомить дежурного сотрудника.

В Choice также стоит оставлять вариант none, other или unclear. Если правильного ответа нет среди вариантов, модель не сможет придумать новую очередь и будет вынуждена выбрать наиболее близкий из имеющихся.

Между ответом модели и бизнес-действием остается слой правил

Ниже приведен псевдокод управления потоком, показывающий разделение ответственности между Jev и окружающей системой. Это не дословный запрос официального SDK:

const decision = await evaluateTicket(ticket, ticketQuestions)

if (decision.transportFailed) {
  return moveToQueue("manual_triage", {
    reason: "decision_service_unavailable"
  })
}

if (
  decision.chargebackRisk >= T_CHARGEBACK ||
  decision.legalRisk >= T_LEGAL
) {
  return moveToQueue("risk_escalation", {
    priority: "highest",
    requireHuman: true
  })
}

if (
  decision.teamTopProbability < T_ROUTE ||
  decision.teamProbabilityMargin < T_MARGIN
) {
  return moveToQueue("manual_triage", {
    reason: "uncertain_route"
  })
}

moveToQueue(decision.team)

if (decision.refundIntent >= T_REFUND) {
  attachWorkflow("refund_review")
}

if (decision.urgency >= T_URGENCY_HIGH) {
  raisePriority()
}

Такие константы, как T_ROUTE и T_REFUND, не являются универсальными значениями Jev. Это бизнес-политика. Их нужно калибровать на собственных данных обращений, и они могут меняться в зависимости от уровня риска, языка, версии модели и определения очередей.

Для обычных запросов с низким риском система может использовать более мягкие пороги автоматической маршрутизации. Для возвратов, чарджбэков, блокировок аккаунта и юридических жалоб следует применять более строгие пороги и сохранять ручную проверку.

Пакетные вызовы подходят для маршрутизации, но высокорисковые шлюзы требуют осторожности

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

Это делает пакетную обработку удобной для массовой классификации писем с точки зрения архитектуры: по сравнению со схемой «один запрос на письмо и еще один запрос на каждый вопрос» объединение необходимых решений в минимальное количество вызовов обычно сокращает сетевые переходы и упрощает контроль пропускной способности.

При этом нельзя заранее предполагать эквивалентность вероятностей Noul в пакетном и одиночном режимах — это необходимо валидировать на собственных данных. Стабильная категориальная метка очереди не означает, что вероятности риска эквивалентны.

Поэтому более осторожная двухэтапная схема выглядит так:

1. На первом этапе пакетно выполнять низкорисковые оценки: основная очередь, тема и явный спам.
2. Обращения, связанные с возвратами, чарджбэками, юридическим риском или вероятностями в зоне неопределенности, валидировать и обрабатывать отдельно либо сразу направлять человеку.

Цель не в том, чтобы заставить модель голосовать несколько раз, а в том, чтобы дать высокорисковым действиям более ясный контекст и более строгий путь обработки.

Не считайте confidence «вероятностью правильности»

Choice и Score возвращают confidence, но это поле описывает концентрацию распределения вероятностей. Его нельзя напрямую трактовать как валидированную вероятность того, что ответ верен для вашего бизнеса.

Метрика confidence отражает степень концентрации распределения модели, а не подтвержденную вероятность безошибочности, поэтому этот показатель требует обязательной калибровки на собственных данных. По этой причине следующее правило небезопасно:

высокий confidence → выполнить автоматически

В реальной системе следует одновременно учитывать несколько сигналов:

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

Вопросы «в какую очередь направить?» и «можно ли обработать автоматически?» также лучше не решать одним Choice. Используйте Choice для выбора очереди, а отдельный Noul — для проверки условий автоматической обработки.

Формулировки вопросов нужно управлять как кодом

В рабочем процессе Jev формулировки вопросов — не обычный текст промпта, а часть бизнес-логики.

Если значения instructions и criteria противоречат друг другу, в определении вопроса возникает логический конфликт: модель может выдать семантически неверный результат, даже если формально ответ соответствует заданной структуре.

Поэтому проект маршрутизации писем должен как минимум применять к определениям вопросов следующие практики:

Область управления	Практика
Версионирование	Создавать новую версию при каждом изменении формулировки, вариантов или критериев
Ревью кода	Хранить определения вопросов и правила маршрутизации в репозитории для review, а не распределять их по текстовым полям административной панели
Тестовые примеры	Сохранять для каждого вопроса положительные, отрицательные, пограничные и многонамеренные обращения
Проверка на противоречия	Проверять, что instruction и true/false criteria направлены в одну семантическую сторону
Фиксация версии модели	После калибровки порогов закрепить конкретную версию вместо прямой зависимости от изменяющегося latest alias

Каждый уровень Score должен описывать наблюдаемую бизнес-ситуацию, а не просто «низкий, средний, высокий». Например, «пользователь только спрашивает цену» и «пользователь обращался неоднократно, а сервис недоступен» оцениваются стабильнее, чем «средняя срочность».

При сетевом сбое система должна знать, что делать

Неудачный ответ классификационной модели нельзя интерпретировать как «риска нет» или «разрешить по умолчанию».

При высокой нагрузке и параллельных запросах возможны транспортные сбои и увеличение задержек. Промышленная система не может реализовывать только идеальный путь.

Нужны как минимум четыре уровня защиты:

1. Повтор и задержка между повторами: предпочтительно использовать SDK с поддержкой повторов и retry-after, чтобы кратковременная сетевая ошибка не приводила к потере обращения.
2. Явная семантика резервного сценария: заранее решить, отправлять ли обращение на ручной разбор, откладывать ли обработку или выполнять только детерминированные правила при недоступности сервиса решений.
3. Идемпотентность и дедупликация: повторная доставка письма, повтор очереди или повтор после тайм-аута не должны создавать дубликаты тикетов.
4. Полное журналирование: записывать версию модели, версию вопросов, probabilities, задержку вызова, использование и окончательный результат ручной обработки.

Для финансовых, аккаунтных и юридических обращений наиболее безопасный резервный вариант обычно не «автоматически одобрить», а «приостановить автоматические действия и передать человеку».

Многоязычные очереди не могут использовать один набор порогов Score

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

Пороги Score и уровни confidence не следует считать универсальными: их нельзя переносить без проверки, а необходимо валидировать отдельно для каждого поддерживаемого языка, даже если базовая метка маршрутизации кажется одинаковой.

Поэтому многоязычная система поддержки должна как минимум:

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

Что оценивать перед запуском

Систему маршрутизации писем нельзя оценивать только по общей точности. Стоимость разных ошибок сильно различается. Отправка предпродажного вопроса в поддержку может привести лишь к одной дополнительной передаче; пропуск угрозы чарджбэка или юридической жалобы способен создать прямой финансовый и комплаенс-риск.

Как минимум следует отдельно отслеживать следующие показатели:

Показатель	На какой вопрос отвечает
Точность основной очереди	Попало ли обращение в правильную первую очередь обработки?
Полнота обнаружения высокого риска	Сколько обращений с чарджбэком, юридическими, регуляторными или аккаунтными рисками было пропущено?
Охват автоматической маршрутизацией	Какая доля обращений не потребовала ручной первичной сортировки?
Доля ошибочной автоматической обработки	Сколько обращений, требовавших человека, было автоматически пропущено?
Доля ручной проверки	Не слишком ли консервативны пороги, из-за чего ручная очередь теряет смысл?
Задержка и доля сбоев	Стабильна ли система при реальной параллельности, длине писем и сетевых условиях?
Полная стоимость на обращение	Остается ли процесс экономичным после учета решений, повторов, последующих моделей и ручной проверки?

При выборе базовой линии не сравнивайте Jev только с дорогими передовыми чат-моделями. Системы правил, Flash-модели со структурированным выводом, embeddings с классификатором и небольшие модели, обученные на собственных размеченных данных, также могут быть разумными альтернативами.

При наличии достаточного объема размеченных данных рекомендуется провести бенчмаркинг специализированного классификатора или компактной модели для конкретной задачи. Разумная траектория развития — использовать Jev на этапе холодного старта и при часто меняющихся метках, а после накопления достаточного объема разметки протестировать целесообразность перехода на специализированный классификатор для высокочастотных очередей.

Jev не пишет окончательный ответ клиенту

После маршрутизации системе может потребоваться кратко изложить проблему, найти заказ, проверить право на возврат или подготовить черновик ответа. Все эти задачи не следует отдавать Jev.

Более ясное разделение труда выглядит так:

Этап	Более подходящий исполнитель
Точный поиск заказа, расчет суммы и сравнение дат	Бизнес-код и базы данных
Определение очереди, риска, намерения и срочности	Jev или другая классификационная модель
Поиск по базе знаний	Поисковая и RAG-система
Черновик ответа, объяснение и естественно-языковая коммуникация	Генеративная LLM
Одобрение возврата, блокировка аккаунта и юридическая обработка	Люди и политика компании

Такая архитектура не превращает Jev в «автоматического сотрудника поддержки». Она лишь добавляет недорогой структурированный слой решений, который код может напрямую использовать до того, как письмо попадет к дорогой модели или в очередь человека.

Заключение: продуктом является не классификация, а управление потоком

Jev показывает полезное направление: если программному обеспечению нужна только очередь, вероятность или уровень, нет необходимости каждый раз вызывать генеративную модель, просить ее написать текст, а затем заставлять код угадывать смысл этого текста.

Но переход от демонстрации классификации писем к полноценному бизнес-процессу требует спроектировать управление после классификации: какие обращения можно направлять автоматически, какие сигналы следует выявлять отдельно, когда нужен человек, как система деградирует при сбое сервиса и как постоянно проверять пороги на реально размеченных данных.

Поэтому систему обработки тикетов с Jev не стоит оценивать только вопросом «насколько быстро она классифицировала 500 писем?». Более важный вопрос звучит так:

Стабильно ли она сокращает ненужные передачи, вызовы моделей и первичную ручную сортировку, не пропуская при этом обращения высокого риска?

Только когда на собственных бизнес-данных ответ на этот вопрос положителен, маршрутизация писем превращается из демонстрации модели в пригодный для работы бизнес-процесс.