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 може да поддржи предлог за колона што ја прегледува човек, но не е доволен за прескокнување на преводот на разговорот. Секое правило ги одразува последиците од таа конкретна одлука.

ЧПП

Кој го разви Jev AI?

TypeSafe AI го разви Jev како модел од типот System One за структурирани одлуки. LiteTMS го интегрира во специфични работни процеси како што се процена на пораки од возачи и споредување на имиња на места.

За што се користи Jev AI во LiteTMS?

Jev е поврзан со тријажа на пораки од возачи, проверки за ист град при прием на налози и проверки на места во CMR, предлози при увоз и проверка за ист јазик пред превод на разговор. Поставките на платформата и компанијата одредуваат дали одредена функција е активна во работниот простор.

Дали Jev им одговара на возачите или одобрува CMR документи?

Не. Може да означи порака од возач за внимание и да оцени дали две имиња на места се однесуваат на ист град. Човек ја обработува пораката, а резултатот за ист град не го валидира целиот CMR документ.

Што се случува ако Jev е несигурен или недостапен?

LiteTMS го задржува постојниот работен процес. На пример, несигурна проверка на јазикот ја користи вообичаената патека за превод на разговор, додека несигурен предлог при увоз го остава мапирањето за преглед од страна на човек.