Jev AI i LiteTMS: Her har vi sat den i arbejde

Vi har integreret Jev, en AI-model fra TypeSafe AI, i flere arbejdsgange i LiteTMS. Den kan hjælpe med at opdage chaufførmeddelelser, der kræver handling, kontrollere om to stednavne henviser til samme by, foreslå hvordan en importfil skal læses, og forhindre oversættelse af en besked, der allerede er på modtagerens sprog. Der er tale om små vurderinger inde i et transportstyringssystem, ikke en ny chatassistent til kontoret.

Hvis navnet er nyt for dig, forklarer vores første artikel om Jev idéen bag. En tekstgenererende AI skriver et svar på en prompt. Jev er derimod designet til at besvare et mere afgrænset spørgsmål som f.eks. "Kræver denne besked et svar?". LiteTMS anvender derefter denne vurdering i den relevante arbejdsgang.

Chaufførbeskeder, der fortjener ekstra opmærksomhed

En chauffør kan sende en rutinemæssig statusopdatering, stille et spørgsmål eller rapportere et problem. Kontoret bør ikke behøve at behandle enhver besked som lige presserende. I chaufførchatten har vi tilføjet et Jev-tjek, der sorterer indgående beskeder efter emne og vurderer, om disponenten skal gribe ind. Det fungerer både med skrevne beskeder og stemmebeskeder, når talen er blevet transskriberet.

For eksempel er "Lastbilen er punkteret" noget andet end "Jeg er fremme". En besked, der vurderes at kræve handling, kan vises i oversigten over opmærksomhedskrævende sager, og et problem med køretøjet kan desuden udløse en hasteadvarsel. Kontoret kan fortsat læse samtalen, svare og markere sagen som håndteret. Jev sender ikke et svar til chaufføren og beslutter heller ikke, hvordan nedbruddet skal løses.

Ved en besked om en punktering kan AI-vurderingen vises i JSON som her:

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

LiteTMS læser kategorien og handlingsscoren. Et køretøjsproblem med så høj en score kan vises som en hastesag, så kontoret ved, at der skal reageres.

Stednavne i ordrer og transportdokumenter

Et dokument kan angive "Köln", mens der i ordren står "Cologne". En bogstavelig tekstsammenligning ser to forskellige ord, selvom begge betegner den samme by. Vi har tilføjet et Jev-tjek til netop det spørgsmål i den AI-assisterede ordreoprettelse og ved kontrol af stednavne på CMR-dokumenter.

Under ordreoprettelsen kan det hjælpe med at vælge mellem foreslåede steder eller efterlade et usikkert match til manuel gennemgang. Ved kontrol af en CMR kan et sikkert svar om, at der er tale om samme by, afkræfte et uoverensstemmende stednavn, som ellers ville være blevet markeret. Et særskilt AI-trin aflæser dokumentet, og Jev vurderer, om stednavnene stemmer overens.

For de to bynavne kan vurderingen se således ud:

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

Den høje score for samme by kan fjerne markeringen af uoverensstemmelse i stednavnet. De øvrige dele af CMR-kontrollen forbliver adskilte.

Importfiler med ukendte kolonneoverskrifter

Overførsel af oplysninger til et nyt system starter ofte med et regneark. Én fil angiver "registreringsnummer", en anden "nummerplade", og en tredje har overskrifter, der er svære at genkende. LiteTMS benytter først almindelige matchingsregler. Hvor disse regler kommer til kort, kan Jev foreslå, hvilken type data filen indeholder, og hvilke kolonner der hører til hvilke felter.

Forslagene markeres som AI-assisterede, og den bruger, der importerer filen, kan gennemgå felttilknytningen, før data oprettes. Vi har integreret denne funktion i den generelle importguide samt i import af CRM-aftaler og gods. Et tilsvarende tjek kan genkende en virksomhed, der allerede findes i partnerkartoteket, på trods af en afvigende stavemåde, hvilket forhindrer duplikerede poster, når matchet er tilstrækkelig sikkert.

Forestil dig et importeret flåderegneark, der anvender "Unit ref." for nummerplader og "Internal ID" for virksomhedens egne vognkoder. Eksempelværdierne hjælper Jev med at skelne mellem de to. Når de sædvanlige regler for kolonneoverskrifter efterlader registreringsfeltet tomt, kan vurderingen se således ud:

{
  "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 derefter foreslå den første kolonne til registreringsnumre. Kontoret gennemgår denne tilknytning, før posterne importeres. Hvis ingen kolonne passer, kan Jev vælge "none", så feltet overlades til brugeren frem for at gennemtvinge et match.

Et lille tjek før chatoversættelse

Nogle gange er en besked allerede skrevet på det sprog, modtageren læser. Før LiteTMS kører en komplet chatoversættelse, kan systemet bede Jev om at kontrollere dette. Et sikkert match gør det muligt at vise den oprindelige besked, mens et usikkert svar sender den ad den sædvanlige oversættelsesvej. Det holder beslutningen snæver: Læseren får stadig oversættelsen, når systemet ikke med sikkerhed kan springe den over.

Tag for eksempel en chauffør, der skriver ”Jestem na miejscu, czekam na załadunek”, hvilket betyder ”Jeg er fremme og venter på læsning”. For en bruger, der læser polsk, kan kontrollen give denne vurdering:

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

Det registrerede sprog matcher læserens sprog, så LiteTMS kan vise originalen. For en læser, der bruger engelsk, skal den samme polske besked stadig oversættes. Et kort svar som ”OK” giver færre oplysninger: Når sproget ikke kan identificeres med sikkerhed, forbliver den sædvanlige oversættelsesvej tilgængelig.

Sådan passer Jev-vurderingen ind i LiteTMS

Jev giver LiteTMS et nyttigt signal, mens kontoret bevarer kontrollen over arbejdet. Integrationerne er indbyggede og kører, når platformens beslutningslag aktiveres, afhængigt af virksomhedens indstillinger. Hvis Jev ikke er tilgængelig, fortsætter de sædvanlige arbejdsgange for chat, dokumenter og import.

Et teknisk kig: TypeSafe Jev, JSON og Java

For læsere, der ønsker at se, hvad der sker under motorhjelmen, er det mest oplagte udgangspunkt den forespørgsel, vi sender. Som TypeSafes quickstart viser, indeholder en anmodning state, de oplysninger der skal vurderes, og questions, de vurderinger der skal foretages. Et noul-spørgsmål returnerer et tal mellem 0 og 1, som repræsenterer sandsynligheden for, at et udsagn er sandt. Et choice-spørgsmål vælger mellem navngivne svarmuligheder, og det er sådan, vi spørger ind til en beskeds kategori.

Her er handlingsspørgsmålet alene, med model-id'et konfigureret i vores OpenRouter-integration:

{
  "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 del af svaret kan se således ud:

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

Applikationen læser answers.needs_action.noul og anvender en regel. LiteTMS bruger en handlingstærskel på 0.55 for chaufførbeskeder, der kræver opmærksomhed. Efter afkodning af JSON kan det samme tjek 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 værdien er gyldig, før den sammenlignes med tærskelværdien. I LiteTMS leverer kategorivurderingen den anden del af reglen: Et problem med køretøjet, der kræver handling, udløser også en hasteadvarsel. Modellen vurderer beskeden; applikationen definerer handlingen. Hvis svaret udebliver, fortsætter den normale chatarbejdsgang.

Tærskelværdien afhænger af, hvad der skal ske efterfølgende. Ved forslag til importkolonner accepterer LiteTMS en valgt kolonne med en sandsynlighed på mindst 0.60, mens det at springe oversættelse over kræver, at læserens sprog er valgt med mindst 0.90. En score på 0.85 kan derfor understøtte et kolonneforslag, som gennemgås af et menneske, men den er ikke høj nok til at springe chatoversættelse over. Hver regel afspejler konsekvensen af den konkrete beslutning.