--- title: Jev AI en LiteTMS: kie ni utiligas ĝin description: Vidu kiel la AI-modelo Jev de TypeSafe helpas al LiteTMS taksi ŝoforajn mesaĝojn, lokojn kaj importojn, kun JSON- kaj Java-ekzemploj klarigantaj ĝian funkcion. slug: where-jev-helps-in-litetms locale: eo date: 2026-09-24 updated: 2026-09-25 category: technology tags: jev, ai, transport, driver-chat, data-import author: LiteTMS Team draft: false --- Ni integris Jev, AI-modelon de [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev?utm_source=litetms.eu), en plurajn laborfluojn de LiteTMS. Ĝi povas helpi rimarki ŝoforajn mesaĝojn bezonantajn atenton, kontroli ĉu du loknomoj rilatas al la sama urbo, sugesti kiel interpreti importitan dosieron kaj eviti tradukadon de mesaĝo, kiu jam estas en la lingvo de la leganto. Temas pri etaj taksoj ene de transportadministra sistemo, ne pri nova babilasistanto por la oficejo. Se la nomo estas nova por vi, [nia unua artikolo pri Jev](/en/blog/jev-ai-decisions-transport) klarigas la koncepton. Tekstogenera AI verkas respondon al instigo. Jev estas desegnita por respondi pli specifan demandon, kiel ekzemple „Ĉu ĉi tiu mesaĝo bezonas respondon?”. LiteTMS poste uzas tiun takson ene de la koncerna laborfluo. ## Ŝoforaj mesaĝoj, kiuj meritas pli atentan rigardon Ŝoforo povas sendi rutinan ĝisdatigon, fari demandon aŭ raporti problemon. La oficejo ne devus trakti ĉiun mesaĝon kiel egale urĝan. En la ŝofora babilo ni aldonis Jev-kontrolon, kiu ordigas envenantajn mesaĝojn laŭ temo kaj taksas, ĉu la dispeĉero devas agi. Ĝi povas funkcii kun skribitaj mesaĝoj kaj voĉnotoj, post kiam ties parolado estas transskribita. Ekzemple, „La kamiono havas trapikitan pneŭon” diferencas de „Mi alvenis.”. Mesaĝo taksita kiel postulanta agon povas aperi en la atentovido; veturila problemo krome povas ekigi urĝan sciigon. La oficejo povas daŭre legi la konversacion, respondi kaj marki la aferon traktita. Jev ne sendas respondon al la ŝoforo nek decidas, kiel la paneo estu solvita. Por mesaĝo pri trapikita pneŭo, la AI-takso povas aspekti en JSON tiel: ```json { "input": { "driver_message": "I have a flat tyre and cannot continue." }, "jev_assessment": { "category": "vehicle_problem", "needs_action_probability": 0.94 } } ``` LiteTMS legas la kategorion kaj agopoentaron. Veturila problemo kun tiel alta poentaro povas aperi kiel urĝa, por ke la oficejo sciu respondi. ## Loknomoj en mendoj kaj transportdokumentoj Dokumento eble indikas „Köln”, dum la mendo diras „Cologne”. Laŭvorta teksta komparo vidas du malsamajn vortojn, kvankam ambaŭ nomas la saman urbon. Ni aldonis Jev-kontrolon por tiu specifa demando en AI-subtenata mendoregistrado kaj en lokokontroloj por CMR-dokumentoj. Dum mendoregistrado, ĝi povas helpi elekti inter proponitaj lokoj aŭ lasi necertan kongruon por revizio. Dum kontrolo de CMR, certa respondo pri sama urbo povas forigi *malkongruon de loknomoj*, kiu alie estus markita. Aparta AI-paŝo legas la dokumenton; Jev juĝas, ĉu la loknomoj kongruas. Por la du urbonomoj, la takso povas aspekti tiel: ```json { "input": { "document_place": "Köln", "order_city": "Cologne" }, "jev_assessment": { "same_city_probability": 0.92 } } ``` La alta poentaro pri sama urbo povas forigi la malkongruon de loknomoj. Aliaj partoj de la CMR-kontrolo restas apartaj. ## Importataj dosieroj kun nekonataj kaplinioj Transigo de informoj en novan sistemon ofte komenciĝas per kalkultabelo. Unu dosiero diras „registra numero”, alia diras „matrikulo”, kaj tria havas malfacile rekoneblajn kapliniojn. LiteTMS unue uzas kutimajn kongruigajn regulojn. Kie tiuj reguloj lasas mankojn, Jev povas sugesti, kian specon de rikordoj la dosiero enhavas kaj kiuj kolumnoj apartenas al kiuj kampoj. La sugestoj estas markitaj kiel AI-subtenataj, kaj la persono importanta la dosieron povas revizii la kampan kongruigon antaŭ krei rikordojn. Ni ligis tiun ĉi aliron al la ĝenerala import-asistanto, same kiel al importado de CRM-interkonsentoj kaj kargoj. Rilata kontrolo povas rekoni entreprenon jam ekzistantan en la partnerlisto malgraŭ malsama literumo, helpante eviti duoblajn elementojn kiam la kongruo estas sufiĉe certa. Supozu, ke importata kalkultabelo de veturilaro uzas „Unit ref.” por registraj matrikuloj kaj „Internal ID” por la propraj veturilkodoj de la kompanio. La ekzemplaj valoroj helpas al Jev distingi inter ambaŭ. Kiam la kutimaj kapliniaj reguloj lasas la registran kampon malplena, la takso povas aspekti tiel: ```json { "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 povas tiam sugesti la unuan kolumnon por registraj numeroj. La oficejo revizias tiun kongruigon antaŭ importi la rikordojn. Se neniu kolumno taŭgas, Jev povas elekti „none”, lasante la kampon al la uzanto por mana kongruigo anstataŭ trudi kongruon. ## Eta kontrolo antaŭ babila tradukado Kelkfoje mesaĝo jam estas skribita en la lingvo de la persono, kiu legas ĝin. Antaŭ ol fari plenan babilan tradukadon, LiteTMS povas peti al Jev kontroli tion. Fidinda kongruo permesas al la sistemo montri la originalan mesaĝon; necerta respondo sendas ĝin tra la kutima traduka vojo. Tio tenas la decidon limigita: la leganto ankoraŭ ricevas la tradukon, kiam la sistemo ne povas certe preterpasi ĝin. Ekzemple, ŝoforo skribas „Jestem na miejscu, czekam na załadunek”, kio signifas „Mi estas surloke, mi atendas la ŝarĝadon”. Por leganto, kiu uzas la polan, la kontrolo povas doni jenan takson: ```json { "input": { "message": "Jestem na miejscu, czekam na załadunek.", "reader_language": "pl" }, "jev_assessment": { "language": "pl", "probability": 0.96 } } ``` La detektita lingvo kongruas kun la lingvo de la leganto, tial LiteTMS povas montri la originalon. Por leganto, kiu uzas la anglan, la sama pola mesaĝo ankoraŭ bezonas tradukadon. Mallonga respondo kiel „OK” estas malpli informa: kiam la lingvo ne povas esti certe identigita, la kutima traduka vojo restas disponebla. ## Kiel la takso de Jev integriĝas en LiteTMS Jev donas al LiteTMS utilan signalon, dum la oficejo konservas kontrolon pri la laboro. La integriĝoj estas enkonstruitaj kaj funkcias kiam la platforma decida tavolo estas aktivigita, laŭ la agordoj de la kompanio. Se Jev ne estas disponebla, la kutimaj laborfluoj por babilejo, dokumentoj kaj importado daŭras. ## Teknika rigardo: TypeSafe Jev, JSON kaj Java Por legantoj, kiuj volas vidi kio okazas interne, utila deirpunkto estas la demando, kiun ni sendas. Kiel montras la [rapida gvidilo de TypeSafe](https://docs.typesafe.ai/introduction/quickstart?utm_source=litetms.eu), peto enhavas `state`, nome la informojn taksotajn, kaj `questions`, la farotajn taksojn. Demando de tipo `noul` redonas nombron inter 0 kaj 1, kiu reprezentas la verŝajnecon, ke aserto veras. Demando de tipo `choice` elektas inter nomitaj opcioj, kio estas la maniero, kiel ni demandas pri la kategorio de mesaĝo. Jen la aga demando memstare, uzanta la modelan identigilon agorditan en nia integriĝo kun OpenRouter: ```json { "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." } } } ``` La koncerna parto de la respondo povas aspekti jene: ```json { "answers": { "needs_action": { "type": "noul", "noul": 0.94 } } } ``` La aplikaĵo legas `answers.needs_action.noul` kaj aplikas regulon. LiteTMS uzas agan sojlon de `0.55` por atentigo pri ŝoforaj mesaĝoj. Post malkodado de la JSON, la sama kontrolo povas esti skribita en Java: ```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"); } ``` La kodo kontrolas, ke la valoro estas uzebla, antaŭ ol kompari ĝin kun la sojlo. En LiteTMS, la takso de la kategorio provizas la alian parton de la regulo: veturila problemo, kiu bezonas atenton, ankaŭ kvalifikiĝas por urĝa alarmo. La modelo taksas la mesaĝon; la aplikaĵo difinas la agon. Se la respondo mankas, la normala babila laborfluo daŭras. La sojlo dependas de tio, kio sekvas. Por propono de importita kolumno, LiteTMS akceptas elektitan kolumnon kun verŝajneco de almenaŭ `0.60`; preterpasi tradukadon postulas, ke la lingvo de la leganto estu elektita kun almenaŭ `0.90`. Poentaro de `0.85` tial povas subteni kolumnan proponon, kiun persono revizias, sed ĝi ne sufiĉas por preterpasi babilan tradukadon. Ĉiu regulo spegulas la konsekvencon de tiu specifa decido. ## Oftaj demandoj ### Kiu disvolvis Jev AI? TypeSafe AI disvolvis Jev kiel modelon de tipo System One por strukturitaj decidoj. LiteTMS integras ĝin en specifajn laborfluojn, kiel ekzemple taksadon de ŝoforaj mesaĝoj kaj kongruigon de loknomoj. ### Por kio Jev AI estas uzata en LiteTMS? Jev estas konektita al ordigo de ŝoforaj mesaĝoj, kontroloj pri sama urbo dum mendoregistrado kaj CMR-lokkontroloj, importaj proponoj kaj samlingva kontrolo antaŭ babila tradukado. Platformaj kaj kompaniaj agordoj determinas, ĉu individua funkcio estas aktiva en laborspaco. ### Ĉu Jev respondas al ŝoforoj aŭ aprobas CMR-dokumentojn? Ne. Ĝi povas marki ŝoforan mesaĝon por atento kaj taksi, ĉu du loknomoj rilatas al la sama urbo. Homo traktas la mesaĝon, kaj rezulto pri sama urbo ne validigas la tutan CMR-dokumenton. ### Kio okazas se Jev estas necerta aŭ neatingebla? LiteTMS konservas la ekzistantan laborfluon. Ekzemple, necerta lingva kontrolo uzas la normalan babilan tradukvojon, dum necerta importa propono lasas la mapadon al revizio fare de homo.