Jev AI i LiteTMS: så använder vi det i praktiken

Vi har byggt in Jev, en AI-modell från TypeSafe AI, i flera arbetsflöden i LiteTMS. Den kan hjälpa till att upptäcka förarmeddelanden som kräver åtgärd, kontrollera om två ortnamn avser samma stad, föreslå hur en importfil ska tolkas och undvika att översätta meddelanden som redan är skrivna på mottagarens språk. Det handlar om små bedömningar inuti ett transportledningssystem, inte en ny chattassistent för kontoret.

Om namnet är nytt för dig förklarar vår första artikel om Jev konceptet. En textgenererande AI skriver svar på en prompt. Jev är utformad för att besvara en mer avgränsad fråga, till exempel ”Kräver det här meddelandet ett svar?” LiteTMS använder sedan den bedömningen i det berörda arbetsflödet.

Förarmeddelanden som kräver extra uppmärksamhet

En förare kan skicka en rutinmässig uppdatering, ställa en fråga eller rapportera ett problem. Kontoret ska inte behöva behandla alla meddelanden som lika brådskande. I förarchatten har vi lagt till en Jev-kontroll som sorterar inkommande meddelanden efter ämne och bedömer om transportledaren behöver agera. Den fungerar med både textmeddelanden och röstmeddelanden när talet väl har transkriberats.

Till exempel är ”Lastbilen har fått punktering” något helt annat än ”Jag har kommit fram.” Ett meddelande som bedöms kräva åtgärd kan visas i vyn för uppmärksamhet; ett fordonsproblem kan dessutom utlösa en brådskande avisering. Kontoret kan fortfarande läsa konversationen, svara och markera ärendet som hanterat. Jev skickar inget svar till föraren och avgör inte hur haveriet ska lösas.

För ett meddelande om punktering kan AI-bedömningen visas i JSON så här:

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

LiteTMS läser av kategorin och åtgärdspoängen. Ett fordonsproblem med en så hög poäng kan visas som brådskande, så att kontoret vet att de behöver agera.

Ortnamn i order och transportdokument

I ett dokument kan det stå ”Köln” medan ordern anger ”Cologne”. En bokstavlig textjämförelse ser två olika ord, även om båda avser samma stad. Vi har lagt till en Jev-kontroll för just den frågan vid AI-assisterad orderregistrering och vid platskontroller för CMR-dokument.

Vid orderregistrering kan den hjälpa till att välja mellan föreslagna orter eller lämna en osäker matchning för manuell granskning. Vid kontroll av en CMR-fraktsedel kan ett säkert svar om samma stad godkänna en ortnamnsavvikelse som annars skulle ha flaggats. Ett separat AI-steg läser av dokumentet; Jev bedömer om ortnamnen stämmer överens.

För de två stadsnamnen kan bedömningen se ut så här:

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

Den höga poängen för samma stad kan kvittera bort ortnamnsavvikelsen. Övriga delar av CMR-kontrollen förblir separata.

Importfiler med obekanta rubriker

Att flytta över information till ett nytt system börjar ofta med ett kalkylark. I en fil står det ”registreringsnummer”, i en annan ”regnr”, och en tredje har rubriker som är svåra att tyda. LiteTMS använder först vanliga matchningsregler. Där reglerna lämnar luckor kan Jev föreslå vilken typ av poster filen innehåller och vilka kolumner som hör till vilka fält.

Förslagen markeras som AI-assisterade, och personen som importerar filen kan granska fältmappningen innan posterna skapas. Vi har kopplat detta till den allmänna importguiden, liksom till import av CRM-affärer och laster. En liknande kontroll kan identifiera ett företag som redan finns i partnerlistan trots en annan stavning, vilket hjälper till att undvika dubbletter när träffsäkerheten är tillräckligt hög.

Antag att ett importerat kalkylark för fordonsflottan använder ”Unit ref.” för registreringsnummer och ”Internal ID” för företagets interna fordonskoder. Exempelvärdena hjälper Jev att skilja de två åt. När de vanliga rubrikreglerna lämnar registreringsfältet tomt kan bedömningen se ut så här:

{
  "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 då föreslå den första kolumnen för registreringsnummer. Kontoret granskar den mappningen innan posterna importeras. Om ingen kolumn passar kan Jev välja ”none”, vilket lämnar fältet till användaren att mappa manuellt i stället för att tvinga fram en matchning.

En liten kontroll före chattöversättning

Ibland är ett meddelande redan skrivet på samma språk som mottagaren läser på. Innan en fullständig chattöversättning körs kan LiteTMS be Jev att kontrollera detta. En säker matchning gör att systemet kan visa originalmeddelandet direkt, medan ett osäkert svar skickar det genom den vanliga översättningsprocessen. Det håller beslutet avgränsat: läsaren får fortfarande översättningen när systemet inte med säkerhet kan hoppa över den.

Tänk dig en förare som skriver ”Jestem na miejscu, czekam na załadunek”, vilket betyder ”Jag är på plats och väntar på lastning.” För en läsare som använder polska kan kontrollen ge följande bedömning:

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

Det identifierade språket matchar läsarens språk, så LiteTMS kan visa originalet. För en läsare som använder engelska behöver samma polska meddelande fortfarande översättas. Ett kort svar som ”OK” ger mindre information: när språket inte kan identifieras med säkerhet finns den vanliga översättningsvägen kvar.

Hur Jev-bedömningen passar in i LiteTMS

Jev ger LiteTMS en användbar signal, samtidigt som kontoret behåller full kontroll över arbetet. Integrationerna är inbyggda och körs när plattformens beslutsnivå är aktiverad, utifrån företagets inställningar. Om Jev inte är tillgängligt fortsätter de vanliga arbetsflödena för chatt, dokument och import som vanligt.

En teknisk genomgång: TypeSafe Jev, JSON och Java

För läsare som vill se vad som händer under huven är den fråga vi skickar en bra utgångspunkt. Som TypeSafes snabbstart visar innehåller en förfrågan state, alltså den information som ska bedömas, och questions, de bedömningar som ska göras. En noul-fråga returnerar ett tal mellan 0 och 1 som representerar sannolikheten för att ett påstående stämmer. En choice-fråga väljer mellan namngivna alternativ, vilket är hur vi frågar om ett meddelandes kategori.

Här är åtgärdsfrågan för sig, med den modellidentifierare som konfigurerats i vår 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 relevanta delen av svaret kan se ut så här:

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

Applikationen läser av answers.needs_action.noul och tillämpar en regel. LiteTMS använder ett tröskelvärde på 0.55 för åtgärdsbehov vid förarmeddelanden. Efter avkodning av JSON kan samma kontroll skrivas 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 kontrollerar att värdet är användbart innan det jämförs med tröskelvärdet. I LiteTMS utgör kategoribedömningen den andra delen av regeln: ett fordonsproblem som kräver åtgärd kvalificerar sig även för en brådskande avisering. Modellen bedömer meddelandet, applikationen definierar åtgärden. Om svaret saknas fortsätter det vanliga chattflödet.

Tröskelvärdet beror på vad som ska hända härnäst. För förslag på importkolumner accepterar LiteTMS en vald kolumn med en sannolikhet på minst 0.60. Att hoppa över översättning kräver att läsarens språk identifieras med minst 0.90. En poäng på 0.85 kan alltså räcka för ett kolumnförslag som granskas manuellt av en person, men det räcker inte för att hoppa över chattöversättning. Varje regel speglar konsekvensen av just det beslutet.

Vanliga frågor

Vem har utvecklat Jev AI?

TypeSafe AI utvecklade Jev som en System One-modell för strukturerade beslut. LiteTMS integrerar den i specifika arbetsflöden, till exempel bedömning av förarmeddelanden och matchning av ortnamn.

Vad används Jev AI till i LiteTMS?

Jev används för prioritering av förarmeddelanden, kontroller av samma stad vid orderregistrering och kontroll av CMR-orter, importförslag samt kontroll av samma språk före chattöversättning. Plattformens och företagets inställningar avgör om en enskild funktion är aktiv i en arbetsyta.

Svarar Jev till förare eller godkänner CMR-dokument?

Nej. Modellen kan flagga ett förarmeddelande för åtgärd och bedöma om två ortnamn avser samma stad. En person hanterar meddelandet, och ett resultat om samma stad godkänner inte hela CMR-dokumentet.

Vad händer om Jev är osäkert eller inte tillgängligt?

LiteTMS behåller det befintliga arbetsflödet. Till exempel skickar en osäker språkkontroll texten genom den vanliga vägen för chattöversättning, medan ett osäkert importförslag lämnar mappningen till en människa att granska.