Jev AI i LiteTMS: Hvor vi har satt den i arbeid

Vi har bygget inn Jev, en AI-modell fra TypeSafe AI, i flere arbeidsflyter i LiteTMS. Den kan hjelpe med å fange opp sjåførmeldinger som krever oppfølging, sjekke om to stedsnavn viser til samme by, foreslå hvordan en importfil skal tolkes og unngå å oversette meldinger som allerede er på mottakerens språk. Dette er små vurderinger inne i et transportstyringssystem, ikke en ny samtaleassistent for kontoret.

Hvis navnet er nytt for deg, forklarer vår første artikkel om Jev prinsippet. En tekstgenererende AI formulerer et svar på en instruks. Jev er utviklet for å svare på et mer avgrenset spørsmål, som «Krever denne meldingen et svar?» LiteTMS bruker deretter denne vurderingen i den aktuelle arbeidsflyten.

Sjåførmeldinger som krever ekstra oppmerksomhet

En sjåfør kan sende en rutinemessig oppdatering, stille et spørsmål eller melde fra om et problem. Kontoret bør slippe å behandle alle meldinger som like hastende. I sjåførchatten har vi lagt til en Jev-kontroll som sorterer innkommende meldinger etter emne og vurderer om transportlederen må gripe inn. Den fungerer både med tekstmeldinger og talemeldinger så snart talen er transkribert.

For eksempel er «Lastebilen har punktert» annerledes enn «Jeg er fremme». En melding som vurderes å kreve tiltak, kan vises i oppfølgingsvisningen, og et problem med kjøretøyet kan også utløse et hastevarsel. Kontoret kan fremdeles lese samtalen, svare og markere saken som håndtert. Jev sender ikke svar til sjåføren og avgjør ikke hvordan driftsstansen skal løses.

For en melding om punktering kan AI-vurderingen se slik ut i JSON:

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

LiteTMS leser kategorien og tiltaksscoren. Et kjøretøyproblem med en så høy score kan vises som et hastevarsel, slik at kontoret vet at de må respondere.

Stedsnavn i ordrer og transportdokumenter

Et dokument kan referere til «Köln», mens ordren oppgir «Cologne». En ren tekstsammenligning oppfatter dette som to ulike ord, selv om begge gjelder samme by. Vi har lagt til en Jev-kontroll for nettopp dette spørsmålet ved AI-assistert ordreopprettelse og ved stedskontroller i CMR-dokumenter.

Ved ordreopprettelse kan funksjonen hjelpe til med å velge blant foreslåtte steder, eller la et usikkert treff gå videre til manuell kontroll. Ved kontroll av en CMR kan et sikkert svar om at det gjelder samme by, oppheve et stedsnavnavvik som ellers ville blitt flagget. Et eget AI-steg leser dokumentet; Jev vurderer om stedsnavnene stemmer overens.

For de to bynavnene kan vurderingen se slik ut:

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

Den høye poengsummen for samme by kan oppheve stedsnavnavviket. Andre deler av CMR-kontrollen forblir separate.

Importfiler med ukjente kolonneoverskrifter

Overføring av data til et nytt system starter ofte med et regneark. Én fil har «registreringsnummer», en annen har «skilt», og en tredje har overskrifter som er vanskelige å tolke. LiteTMS bruker først vanlige regler for kobling. Der disse reglene ikke strekker til, kan Jev foreslå hva slags oppføringer filen inneholder, og hvilke kolonner som hører til hvilke felt.

Forslagene markeres som AI-assisterte, og personen som importerer filen kan kontrollere koblingen før postene opprettes. Vi har knyttet denne funksjonaliteten til den generelle importveiviseren, i tillegg til import av CRM-avtaler og gods. En beslektet kontroll kan gjenkjenne et selskap som allerede finnes i listen over oppdragstakere selv om skrivemåten varierer, noe som bidrar til å unngå duplikater når treffet er sikkert nok.

Tenk deg et importert regneark over bilparken som bruker «Unit ref.» for registreringsnumre og «Internal ID» for selskapets egne kjøretøykoder. Eksempelverdiene hjelper Jev med å skille de to fra hverandre. Når de vanlige reglene for overskrifter lar registreringsfeltet stå tomt, kan vurderingen se slik ut:

{
  "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 kan deretter foreslå den første kolonnen for registreringsnummer. Kontoret kontrollerer tilordningen før dataene importeres. Dersom ingen kolonne passer, kan Jev velge «none», slik at feltet overlates til manuell kobling av brukeren i stedet for at et feilaktig treff tvinges gjennom.

En enkel kontroll før oversettelse i chatten

Noen ganger er en melding allerede skrevet på samme språk som mottakeren bruker. Før det kjøres en full oversettelse i chatten, kan LiteTMS be Jev om å sjekke dette. Et sikkert treff lar systemet vise originalmeldingen, mens et usikkert svar sender meldingen gjennom den vanlige oversettelsesrutinen. Dette begrenser beslutningsrommet: leseren får likevel oversettelsen dersom systemet ikke er sikkert nok til å hoppe over den.

Tenk deg en sjåfør som skriver «Jestem na miejscu, czekam na załadunek», som betyr «Jeg har kommet frem og venter på lasting». For en mottaker som bruker polsk, kan sjekken gi denne vurderingen:

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

Det oppdagede språket stemmer overens med mottakerens språk, og LiteTMS kan dermed vise originalen. For en mottaker som bruker engelsk, må den samme polske meldingen fremdeles oversettes. Et kort svar som «OK» gir mindre informasjon: når språket ikke kan identifiseres med tilstrekkelig sikkerhet, beholdes den vanlige oversettelsesflyten.

Hvordan Jev-vurderingen passer inn i LiteTMS

Jev gir LiteTMS et nyttig signal, mens kontoret beholder full kontroll over arbeidet. Integrasjonene er innebygd og kjører når beslutningslaget på plattformen er aktivert, avhengig av bedriftens innstillinger. Dersom Jev ikke er tilgjengelig, fortsetter de vanlige arbeidsflytene for chat, dokumenter og import som før.

Et teknisk blikk: TypeSafe Jev, JSON og Java

For lesere som ønsker å se hva som skjer bak kulissene, er forespørselen vi sender et godt utgangspunkt. Som TypeSafes hurtigstartguide viser, inneholder en forespørsel state, som er informasjonen som skal vurderes, og questions, som er vurderingene som skal gjøres. Et noul-spørsmål returnerer et tall mellom 0 og 1 som representerer sannsynligheten for at en påstand stemmer. Et choice-spørsmål velger blant navngitte alternativer, og det er slik vi spør om meldingskategori.

Her er handlingsspørsmålet alene, med modellidentifikatoren som er konfigurert i vår OpenRouter-integrasjon:

{
  "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."
    }
  }
}

Den relevante delen av svaret kan se slik ut:

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

Applikasjonen leser answers.needs_action.noul og anvender en regel. LiteTMS bruker en handlingsterskel på 0.55 for meldinger fra sjåfører som krever oppfølging. Etter dekoding av JSON kan den samme sjekken skrives i 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");
}

Koden kontrollerer at verdien er gyldig før den sammenlignes med terskelen. I LiteTMS gir kategorivurderingen den andre delen av regelen: et kjøretøyproblem som krever oppfølging, kvalifiserer også til et hastevarsel. Modellen vurderer meldingen, mens applikasjonen definerer handlingen. Dersom svaret mangler, fortsetter den vanlige arbeidsflyten i chatten.

Terskelverdien avhenger av hva som skjer videre. For forslag til importkolonner godtar LiteTMS en valgt kolonne med en sannsynlighet på minst 0.60. Å hoppe over oversettelse krever derimot at mottakerens språk er valgt med minst 0.90. En poengsum på 0.85 kan derfor støtte et kolonneforslag som en person går gjennom manuelt, men det er ikke nok til å hoppe over chat-oversettelse. Hver regel gjenspeiler konsekvensen av den aktuelle beslutningen.

Ofte stilte spørsmål

Hvem har utviklet Jev AI?

TypeSafe AI utviklet Jev som en System One-modell for strukturerte beslutninger. LiteTMS integrerer modellen i spesifikke arbeidsflyter som vurdering av sjåførmeldinger og matching av stedsnavn.

Hva brukes Jev AI til i LiteTMS?

Jev er koblet til prioritering av sjåførmeldinger, steds- og bysjekk ved ordreregistrering og kontroll av CMR-steder, forslag ved import og en sjekk av felles språk før oversettelse i chat. Plattform- og bedriftsinnstillinger avgjør om en enkeltfunksjon er aktiv i et arbeidsområde.

Svarer Jev til sjåfører eller godkjenner CMR-dokumenter?

Nei. Modellen kan flagge en sjåførmelding som krever oppfølging, og vurdere om to stedsnavn refererer til samme by. Et menneske håndterer meldingen, og en bekreftelse på at det gjelder samme by validerer ikke hele CMR-dokumentet.

Hva skjer dersom Jev er usikker eller utilgjengelig?

LiteTMS beholder den eksisterende arbeidsflyten. En usikker språksjekk bruker for eksempel den vanlige oversettelsesflyten i chatten, mens et usikkert importforslag overlater koblingen til manuell gjennomgang.