Jev AI в LiteTMS: где и как мы применили его в работе

Мы интегрировали Jev, модель ИИ от TypeSafe AI, в ряд рабочих процессов LiteTMS. Она помогает выделять сообщения водителей, требующие внимания, проверять, относятся ли два географических названия к одному городу, подсказывать структуру файлов импорта и избегать перевода сообщений, если они уже написаны на языке пользователя. Это точечные оценки внутри системы управления транспортом (TMS), а не очередной чат-бот для сотрудников офиса.

Если вы слышите это название впервые, в нашей первой статье о Jev подробно изложена суть технологии. Генеративный ИИ пишет развернутые ответы на запросы. Модель Jev создана для решения более узких задач, например: «Требуется ли ответ на это сообщение?» Затем LiteTMS использует эту оценку в соответствующем рабочем процессе.

Сообщения водителей, требующие особого внимания

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

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

Для сообщения о пробитом колесе оценка ИИ в формате JSON выглядит следующим образом:

{
  "input": { "driver_message": "I have a flat tyre and cannot continue." },
  "jev_assessment": {
    "category": "vehicle_problem",
    "needs_action_probability": 0.94
  }
}

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

Названия населенных пунктов в заказах и транспортных документах

В документе может быть указано «Köln», а в заказе - «Cologne». При прямом посимвольном сравнении система сочтет их разными словами, хотя оба обозначают один и тот же город. Мы добавили проверку через Jev именно для таких ситуаций: при обработке заказов с помощью ИИ и при верификации населенных пунктов в накладных CMR.

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

Для двух названий городов оценка может выглядеть так:

{
  "input": { "document_place": "Köln", "order_city": "Cologne" },
  "jev_assessment": { "same_city_probability": 0.92 }
}

Высокая вероятность совпадения снимает предупреждение о расхождении в названиях. Остальные этапы проверки CMR выполняются независимо.

Файлы импорта с нестандартными заголовками

Перенос данных в новую систему часто начинается с электронных таблиц. В одном файле столбец называется «регистрационный номер», в другом - «госномер», а в третьем заголовки и вовсе трудно опознать. LiteTMS сначала применяет стандартные правила сопоставления. Если они не дают результата, Jev определяет характер записей в файле и подсказывает, каким полям соответствуют те или иные столбцы.

Подсказки отмечаются как сформированные с помощью ИИ, и пользователь может проверить сопоставление полей перед созданием записей. Мы подключили эту логику к общему мастеру импорта, а также к импорту сделок CRM и грузов. Похожая проверка позволяет распознать контрагента, уже внесенного в базу, даже если его наименование написано иначе, что предотвращает появление дубликатов при высокой степени уверенности модели.

Предположим, в импортируемой таблице по автопарку для регистрационных номеров используется заголовок «Unit ref.», а для внутренних кодов тягачей - «Internal ID». Примеры значений помогают Jev различить эти данные. Если стандартные правила для заголовков не смогли определить поле регистрационного номера, оценка выглядит следующим образом:

{
  "input": {
    "columns": {
      "col_0": { "header": "Unit ref.", "examples": ["WX 4821A", "PO 7619K"] },
      "col_1": { "header": "Internal ID", "examples": ["FLEET-17", "FLEET-42"] }
    },
    "field_to_match": "registration_number"
  },
  "jev_assessment": { "column": "col_0", "probability": 0.93 }
}

После этого LiteTMS предлагает использовать первый столбец в качестве регистрационных номеров. Пользователь проверяет это сопоставление перед импортом данных. Если ни один столбец не подходит, Jev выбирает вариант «none» и оставляет поле неназначенным для ручной настройки, не навязывая ошибочных совпадений.

Быстрая проверка перед переводом сообщений в чате

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

Возьмем пример, когда водитель пишет: «Jestem na miejscu, czekam na załadunek» («Я на месте, жду погрузку»). Для пользователя с польским интерфейсом проверка может дать такую оценку:

{
  "input": {
    "message": "Jestem na miejscu, czekam na załadunek.",
    "reader_language": "pl"
  },
  "jev_assessment": { "language": "pl", "probability": 0.96 }
}

Определенный язык совпадает с языком пользователя, поэтому LiteTMS может показать оригинал. Для англоязычного пользователя то же сообщение на польском все еще нужно перевести. Короткий ответ вроде «OK» менее показателен: если язык не удается определить наверняка, система использует привычный маршрут перевода.

Как оценка Jev встроена в LiteTMS

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

Технический разбор: TypeSafe Jev, JSON и Java

Для тех, кто хочет заглянуть под капот, лучше всего начать с отправляемого запроса. Как показано в руководстве TypeSafe, запрос содержит state (информацию для анализа) и questions (сами вопросы для оценки). Вопрос типа noul возвращает число от 0 до 1, показывающее вероятность истинности утверждения. Вопрос типа choice выбирает один из заданных вариантов, именно так мы определяем категорию сообщения.

Вот отдельный вопрос о необходимости действий с идентификатором модели из нашей интеграции с OpenRouter:

{
  "model": "typesafe/jev-1.13",
  "state": {
    "driver_message": "I have a flat tyre and cannot continue."
  },
  "questions": {
    "needs_action": {
      "type": "noul",
      "instructions": "The dispatcher must act on driver_message today: reply, give instructions, inform the customer or arrange help. Routine updates and thanks need no action."
    }
  }
}

Соответствующая часть ответа может выглядеть так:

{
  "answers": {
    "needs_action": {
      "type": "noul",
      "noul": 0.94
    }
  }
}

Приложение считывает answers.needs_action.noul и применяет правило. Для привлечения внимания к сообщению водителя в LiteTMS задан порог 0.55. После декодирования JSON ту же проверку на Java можно записать следующим образом:

Double probability = 0.94; // Value from answers.needs_action.noul
boolean needsAttention = probability != null
    && Double.isFinite(probability)
    && probability >= 0.55
    && probability <= 1.0;

if (needsAttention) {
    System.out.println("Flag the message for dispatcher review");
}

Код проверяет корректность значения перед сравнением с порогом. В LiteTMS определение категории дополняет правило: неполадка с машиной, требующая вмешательства, также квалифицируется как срочное оповещение. Модель оценивает сообщение, а приложение определяет действие. Если ответ отсутствует, чат работает в обычном режиме.

Пороговое значение зависит от последующего шага. Для подсказки колонок при импорте LiteTMS принимает вариант с вероятностью не менее 0.60, тогда как для пропуска перевода совпадение языка пользователя должно быть подтверждено минимум на 0.90. Таким образом, оценка 0.85 достаточна для рекомендации колонки, которую затем проверит человек, но ее не хватит для отмены перевода в чате. Каждое правило учитывает последствия конкретного решения.