Jev AI in LiteTMS: Wo wir die KI im System einsetzen

Wir haben Jev, ein KI-Modell von TypeSafe AI, in mehrere Workflows von LiteTMS integriert. Es hilft dabei, dringende Fahrernachrichten zu erkennen, zu prüfen, ob zwei Ortsbezeichnungen dieselbe Stadt meinen, Importdateien richtig zuzuordnen und unnötige Übersetzungen von Nachrichten zu vermeiden, die ohnehin in der Sprache des Empfängers vorliegen. Es handelt sich um gezielte Bewertungen innerhalb eines Transport-Management-Systems, nicht um einen weiteren Chat-Assistenten für die Disposition.

Falls Ihnen der Name noch neu ist: Unser erster Artikel über Jev erklärt das Konzept. Eine textgenerierende KI formuliert Antworten auf Prompts. Jev hingegen beantwortet präzise Einzelfragen wie beispielsweise: „Erfordert diese Nachricht eine Antwort?“ LiteTMS nutzt diese Bewertung anschließend im jeweiligen Arbeitsschritt.

Fahrernachrichten, die Aufmerksamkeit erfordern

Ein Fahrer sendet Statusmeldungen, stellt Fragen oder meldet Probleme. Die Disposition muss dabei nicht jede Nachricht mit derselben Dringlichkeit behandeln. Im Fahrer-Chat haben wir eine Jev-Prüfung integriert, die eingehende Nachrichten nach Themen sortiert und einschätzt, ob der Disponent aktiv werden muss. Das funktioniert sowohl bei Textnachrichten als auch bei Sprachnachrichten, sobald diese transkribiert wurden.

Beispielsweise unterscheidet sich „Der Lkw hat einen Reifenschaden“ grundlegend von „Ich bin angekommen.“ Wird eine Nachricht als handlungsrelevant eingestuft, kann sie in einer gesonderten Übersicht hervorgehoben werden; bei einer Fahrzeugpanne lässt sich zudem eine dringende Benachrichtigung auslösen. Die Disposition kann den Verlauf wie gewohnt lesen, antworten und den Vorgang als erledigt markieren. Jev verschickt keine automatischen Antworten an den Fahrer und entscheidet nicht darüber, wie die Panne behoben wird.

Bei einer Nachricht über einen Reifenschaden sieht die KI-Bewertung im JSON-Format beispielsweise so aus:

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

LiteTMS liest Kategorie und Handlungswahrscheinlichkeit aus. Ein Fahrzeugproblem mit einem so hohen Wert wird direkt als dringlich markiert, sodass die Disposition sofort reagieren kann.

Ortsnamen in Aufträgen und Frachtdokumenten

In einem Frachtdokument steht womöglich „Köln“, während im Transportauftrag „Cologne“ angegeben ist. Ein reiner Textvergleich erkennt hier zwei unterschiedliche Wörter, obwohl dieselbe Stadt gemeint ist. Genau für diesen Fall haben wir eine Jev-Prüfung in die KI-gestützte Auftragserfassung sowie in die Ortsprüfung von CMR-Frachtbriefen eingebunden.

Bei der Auftragserfassung hilft das System, zwischen Ortsvorschlägen zu wählen oder unsichere Treffer zur manuellen Prüfung vorzulegen. Bei der CMR-Prüfung kann eine eindeutige Zuordnung zur selben Stadt eine vermeintliche Ortsabweichung auflösen, die sonst beanstandet worden wäre. Das Auslesen des Dokuments übernimmt ein separater KI-Schritt; Jev beurteilt lediglich, ob die Ortsnamen übereinstimmen.

Für die beiden Stadtnamen sieht die Bewertung beispielsweise so aus:

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

Der hohe Wahrscheinlichkeitswert für dieselbe Stadt löst die Unstimmigkeit beim Ortsnamen auf. Andere Prüfpunkte des CMR-Frachtbriefs bleiben davon unberührt.

Importdateien mit ungewohnten Spaltenüberschriften

Der Datenumzug in ein neues System beginnt häufig mit einer Excel-Tabelle. Eine Datei enthält die Spalte „Kennzeichen“, eine andere „Amtl. Kennz.“ und eine dritte Bezeichnungen, die kaum zuzuordnen sind. LiteTMS wendet zunächst standardmäßige Zuordnungsregeln an. Wo diese an ihre Grenzen stoßen, schlägt Jev vor, um welche Datensätze es sich handelt und welche Spalten zu welchen Feldern passen.

Die Vorschläge werden als KI-gestützt gekennzeichnet, und der Bearbeiter kann das Spalten-Mapping vor dem eigentlichen Import überprüfen. Wir haben diese Logik sowohl in den allgemeinen Importassistenten als auch in den Import von CRM-Geschäften und Frachtdaten integriert. Eine ähnliche Prüfung erkennt zudem Vertragspartner, die trotz leicht abweichender Schreibweise bereits im System vorhanden sind, und verhindert so zuverlässig Dubletten.

Angenommen, eine importierte Fuhrparkliste verwendet „Unit ref.“ für amtliche Kennzeichen und „Internal ID“ für interne Fahrzeugnummern. Die Beispielwerte helfen Jev, beides auseinanderzuhalten. Wenn die regulären Regeln anhand der Spaltenüberschrift kein Kennzeichen zuweisen können, sieht die Bewertung beispielsweise so aus:

{
  "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 schlägt daraufhin die erste Spalte für das Kennzeichen vor. Die Disposition oder Verwaltung prüft diese Zuordnung vor dem Import. Passt keine Spalte, wählt Jev „none“, sodass das Feld nicht fehlerhaft zugeordnet, sondern dem Nutzer zur manuellen Zuweisung überlassen wird.

Eine kurze Prüfung vor der Chat-Übersetzung

Manchmal ist eine Nachricht bereits in der Sprache der Person verfasst, die sie liest. Bevor eine vollständige Chat-Übersetzung ausgeführt wird, kann LiteTMS dies von Jev prüfen lassen. Eine eindeutige Übereinstimmung erlaubt es dem System, die Originalnachricht anzuzeigen; bei einer unsicheren Antwort durchläuft sie den regulären Übersetzungspfad. Das hält den Entscheidungsspielraum eng: Die lesende Person erhält die Übersetzung immer dann, wenn das System das Überspringen nicht sicher rechtfertigen kann.

Ein Fahrer schreibt beispielsweise „Jestem na miejscu, czekam na załadunek“, was „Ich bin vor Ort und warte auf die Beladung“ bedeutet. Für jemanden, der Polnisch nutzt, kann die Prüfung folgende Bewertung liefern:

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

Die erkannte Sprache stimmt mit der Sprache des Nutzers überein, sodass LiteTMS das Original anzeigen kann. Für jemanden, der Englisch verwendet, muss dieselbe polnische Nachricht weiterhin übersetzt werden. Eine kurze Antwort wie „OK“ liefert weniger Anhaltspunkte: Lässt sich die Sprache nicht zuverlässig bestimmen, bleibt der reguläre Übersetzungspfad aktiv.

Wie sich die Jev-Bewertung in LiteTMS einfügt

Jev liefert LiteTMS ein nützliches Signal, während die Disposition die Kontrolle über die Abläufe behält. Die Integrationen sind fest integriert und laufen, sobald die Entscheidungsebene der Plattform aktiviert ist, abhängig von den Unternehmenseinstellungen. Sollte Jev nicht verfügbar sein, laufen die gewohnten Workflows für Chat, Dokumente und Datenimporte unterbrechungsfrei weiter.

Ein technischer Blick: TypeSafe Jev, JSON und Java

Wer wissen möchte, was im Hintergrund geschieht, wirft am besten einen Blick auf die Anfrage, die wir versenden. Wie die Schnellstartanleitung von TypeSafe zeigt, enthält ein Request state, also die zu bewertenden Informationen, und questions, die gewünschten Bewertungen. Eine noul-Frage liefert eine Zahl zwischen 0 und 1 zurück, die angibt, mit welcher Wahrscheinlichkeit eine Aussage zutrifft. Eine choice-Frage wählt aus definierten Optionen aus, womit wir die Kategorie einer Nachricht ermitteln.

Hier ist die Aktionsfrage für sich allein, unter Verwendung des in unserer OpenRouter-Integration konfigurierten Modellbezeichners:

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

Der relevante Teil der Antwort kann so aussehen:

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

Die Anwendung liest answers.needs_action.noul aus und wendet eine Regel an. LiteTMS nutzt einen Schwellenwert von 0.55, ab dem Fahrernachrichten Aufmerksamkeit erfordern. Nach dem Dekodieren des JSON lässt sich dieselbe Prüfung in Java abbilden:

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");
}

Der Code prüft, ob der Wert verwertbar ist, bevor er mit dem Schwellenwert verglichen wird. In LiteTMS liefert die Kategoriebewertung den weiteren Teil der Regel: Ein Fahrzeugproblem, das Aufmerksamkeit erfordert, löst zusätzlich eine Dringlichkeitsmeldung aus. Das Modell bewertet die Nachricht; die Anwendung definiert die daraus folgende Aktion. Fehlt die Antwort, wird der reguläre Chat-Workflow fortgesetzt.

Welcher Schwellenwert gilt, hängt von den nachfolgenden Schritten ab. Für den Vorschlag einer Importspalte akzeptiert LiteTMS eine ausgewählte Spalte ab einer Wahrscheinlichkeit von mindestens 0.60. Das Überspringen einer Übersetzung setzt voraus, dass die Sprache des Lesers mit mindestens 0.90 erkannt wurde. Ein Wert von 0.85 reicht somit aus, um einen Spaltenvorschlag zur manuellen Prüfung vorzulegen, genügt jedoch nicht, um die Chat-Übersetzung zu überspringen. Jede Regel spiegelt die Tragweite der jeweiligen Entscheidung wider.