Jev AI у LiteTMS: де ми залучили його до роботи

Ми інтегрували Jev, модель штучного інтелекту від TypeSafe AI, у кілька робочих процесів LiteTMS. Вона допомагає виявляти повідомлення від водіїв, які потребують уваги, перевіряти, чи позначають дві назви одне й те саме місто, підказувати структуру імпортованого файлу та уникати перекладу повідомлень, які вже написані мовою користувача. Це точкові оцінки всередині системи управління транспортом, а не черговий чат-асистент для офісу.

Якщо ця назва вам незнайома, наша перша стаття про 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 може підтримати пропозицію колонки, яку переглядає людина, але її недостатньо для пропуску перекладу в чаті. Кожне правило відображає наслідки конкретного рішення.