Jev AI в LiteTMS: къде го въведохме в действие

Вградихме Jev, AI модел от TypeSafe AI, в няколко работни процеса в LiteTMS. Той помага за разпознаване на съобщения от шофьори, изискващи внимание, проверява дали две имена на населени места се отнасят за един и същи град, предлага как да се разчете файл за импортиране и спестява превода на съобщение, което вече е на езика на потребителя. Това са малки преценки вътре в системата за управление на транспорта, а не нов чат асистент за офиса.

Ако името не ви е познато, първата ни статия за Jev обяснява концепцията. AI моделите за генериране на текст създават отговор на даден въпрос. 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 точно за такива случаи при въвеждането на поръчки с помощта на AI и при проверката на населени места в CMR документи.

По време на въвеждане на поръчки това помага за избор между предложени населени места или оставя несигурното съвпадение за преглед. При проверка на CMR уверен положителен отговор за един и същ град може да изчисти несъответствието в имената на населените места (place-name mismatch), което иначе би било отбелязано като проблем. Отделна AI стъпка разчита документа, а 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 е достатъчен за предложение за колона, което се преглежда от човек, но не достига прага за пропускане на превод в чата. Всяко правило отразява последствията от съответното решение.