Sieben Entscheidungskriterien

Jev oder LLM wie ChatGPT, Claude und Gemini

0:00 Wer heute eine KI-Funktion baut, greift fast reflexhaft zu einem großen Sprachmodell — zu ChatGPT, Claude oder Gemini. Das funktioniert, ist aber nicht immer die beste Wahl. Seit Mitte September gibt es mit Jev ein Modell, das bewusst keinen Text schreibt, sondern nur entscheidet: Welche Kategorie, welche Stufe, ja oder nein — mit Wahrscheinlichkeiten dazu.

0:21 Das wirft eine Architekturfrage auf, die über ein einzelnes Produkt hinausgeht: Wann gehört eine Entscheidung in festen Code, wann in klassisches Machine Learning, wann in ein Entscheidungsmodell wie Jev und wann in ein generatives LLM? Dieses Modul gibt keine pauschale Empfehlung. Es gibt Ihnen sieben Kriterien, mit denen Sie einen konkreten Entscheidungspunkt in Ihrer Anwendung nachvollziehbar einordnen.

Vier Ansätze, eine Architekturentscheidung

0:45 Bevor wir Jev bewerten, brauchen wir eine saubere Landkarte. Vier Ansätze konkurrieren um dieselben Aufgaben: fester Programmcode, klassisches Machine Learning, ein Entscheidungsmodell und ein generatives Sprachmodell. Jeder hat sein Terrain. Dieses erste Kapitel steckt die Grenzen ab — und zeigt, warum die Antwort selten nur einer der vier ist.

1:06 Schauen Sie einmal ehrlich auf die KI-Funktionen in Ihrer eigenen Anwendung. Erstaunlich viele davon schreiben gar nichts. Sie sortieren eine Anfrage einem Team zu, schätzen ein Risiko ein, entscheiden, ob eine Fundstelle zur Frage passt. Das Ergebnis ist ein Etikett, keine Prosa. Trotzdem läuft genau das oft über ein generatives Sprachmodell: Man schreibt einen Prompt, bekommt einen Satz zurück und zerlegt ihn mit einem Parser, der hoffentlich nie überrascht wird.

1:33 Das ist ein bisschen so, als würde man einen Romanautor beauftragen, Briefe in Fächer zu sortieren. Er kann das, aber er ist langsam, teuer und schreibt gelegentlich eine Anmerkung dazu, die niemand bestellt hat. Genau hier setzt Jev an. Das Modell stammt von der Firma TypeSafe und ist seit dem fünfzehnten September 2026 im Early Access.

1:54 Das Prinzip erinnert an ein Multiple-Choice-Formular: Die Anwendung legt den Sachverhalt hin, stellt vorab formulierte Fragen und gibt die möglichen Antworten vor. Jev kreuzt an und sagt dazu, wie sicher es sich ist. Freien Text gibt es nicht, also auch keinen Antwortsatz, der aus dem Format fällt. TypeSafe spricht von einem System One Model, angelehnt an das schnelle, intuitive Denken. Neutraler nennt man die Gattung ein Typed Decision Model.

2:20 Diesen Begriff sollten Sie sich merken, denn die Kriterien dieses Moduls gelten auch für künftige Modelle dieser Art. Drei Fragetypen decken erstaunlich viel ab. Choice wählt aus einer festen Liste, etwa das zuständige Team. Score ordnet auf einer Skala ein, etwa von gelassen bis sehr verärgert. Und Noul beurteilt eine einzelne Aussage — stimmt sie oder nicht?

2:42 Das Entscheidende steht in der rechten Spalte: Jede Antwort kommt mit Wahrscheinlichkeiten zurück, nicht nur mit einem Ergebnis. Ihr Code weiß also nicht nur, was das Modell meint, sondern auch, wie eindeutig es das meint. Und weil alle Fragen eines Aufrufs parallel und unabhängig gegen denselben Zustand laufen, kostet eine zusätzliche Frage kaum zusätzliche Zeit. Das wird gleich noch wichtig.

3:07 Diese Tabelle ist die Landkarte für den Rest des Moduls. Lesen Sie sie von oben nach unten als wachsende Offenheit des Ergebnisses. Fester Code ist unschlagbar, wenn sich die Regel vollständig aufschreiben lässt — schnell, billig, nachvollziehbar. Klassisches Machine Learning lohnt sich, wenn viele gelabelte Beispiele und ein stabiles Ziel vorhanden sind und Sie die Trainingsinfrastruktur tragen wollen.

3:31 Jev besetzt die Lücke dazwischen: Sprachverständnis ist nötig, das Ergebnis steht aber fest. Und die großen Sprachmodelle bleiben unersetzlich, sobald etwas Neues entstehen soll — eine Antwort, ein Konzept, Code. Keine Zeile ist besser als die andere. Sie beantworten nur verschiedene Fragen. In der Praxis endet das selten bei einem einzigen Ansatz. Denken Sie an eine gut organisierte Poststelle.

3:55 Einer sortiert die Eingänge, einer schreibt die Antworten, und am Ende zeichnet jemand ab, bevor Geld fließt. Genau so lässt sich eine Anwendung aufteilen: Jev sortiert und bewertet, das Sprachmodell formuliert, und fester Code rechnet, wendet die Schwellenwerte an, gibt frei und schreibt das Protokoll. TypeSafe selbst rät übrigens dazu, für Textaufgaben andere Modelle zu nehmen. Die eigentliche Architekturfrage lautet deshalb nicht: Welches Modell nehmen wir?

4:23 Sondern: Welche Teilentscheidung gehört wohin? Dafür kommen jetzt die sieben Kriterien.

Ergebnisraum, Regeln und atomare Fragen

4:28 Die ersten drei Kriterien klären, ob eine Entscheidung überhaupt in ein Modell wie Jev passt. Steht das Ergebnis vorher fest? Ist es Beurteilung oder schlicht Rechnung? Und lässt sich das Urteil in kleine, einzeln prüfbare Fragen zerlegen? Wer hier dreimal ja sagt, hat einen guten Kandidaten. Der Gegensatz auf dieser Folie ist schärfer, als er zunächst wirkt.

4:51 Links stehen Fragen, deren mögliche Antworten Sie heute schon aufschreiben können — eine Liste von Teams, eine Dringlichkeitsskala, ja oder nein. Rechts stehen Aufträge, deren Ergebnis erst beim Antworten entsteht. Eine hilfreiche Kundenantwort lässt sich nicht aus einer Liste auswählen, eine Fehlerursache auch nicht. Die Prüffrage ist deshalb ganz handfest: Können Sie alle zulässigen Ergebnisse festlegen, bevor die Anfrage überhaupt rausgeht?

5:18 Wenn ja, ist ein Entscheidungsmodell eine echte Option. Wenn nein, gehört die Aufgabe zu einem generativen Modell — und daran ändert auch der geschickteste Prompt nichts. Nicht alles, was nach Urteil klingt, braucht eine KI. Die Tabelle zeigt Pärchen, die auf den ersten Blick ähnlich wirken. Ob eine Nachricht dringend klingt, ist Sprachverständnis — da hilft ein Modell. Ob ein Termin weniger als achtundvierzig Stunden entfernt liegt, ist schlicht Rechnung.

5:46 Und hier wird die Dokumentation erfreulich offen: Jev ist ausdrücklich kein Taschenrechner. Es zählt nicht zuverlässig, rechnet nicht zuverlässig und vergleicht Datumswerte als Text statt als Zeitpunkte. Die Empfehlung lautet deshalb: Das Modell zieht die Angabe aus dem Text, Ihr Code rechnet damit. Eine saubere Arbeitsteilung, die nebenbei auch jede spätere Fehlersuche erleichtert.

6:10 Breite Fragen sind bequem, aber trügerisch. Wie kritisch ist dieses Ticket? Hinter dieser einen Frage verstecken sich mindestens vier: Ist etwas ausgefallen? Sind viele betroffen? Entsteht Schaden? Gibt es einen Umweg? Stellt man sie einzeln, gewinnt man dreierlei. Ein Fehler lässt sich einer konkreten Frage zuordnen. Die fachliche Gewichtung steht sichtbar im Code, statt irgendwo im Modell zu verschwimmen. Und jedes Kriterium lässt sich unabhängig testen und ändern.

6:39 Die Dokumentation empfiehlt genau dieses Vorgehen. Und weil die Fragen parallel laufen, kostet die Zerlegung praktisch keine zusätzliche Antwortzeit. So sieht das konkret aus. ServicePilot ist unser Beispiel für dieses Modul, eine B2B-Softwareplattform mit mehreren Tausend Support-Nachrichten am Tag. Der Ausschnitt zeigt den Teil einer Anfrage an Jev, in dem die Fragen stehen.

7:03 Vier Noul-Fragen, jede mit einer kurzen, eindeutigen Aussage: Kernfunktion ausgefallen, mehrere Benutzer betroffen, Schaden erkennbar, Workaround vorhanden. Achten Sie auf das, was fehlt. Nirgends steht eine Gewichtung, nirgends die Frage nach der Gesamtpriorität. Die setzt Ihr Code aus den vier Wahrscheinlichkeiten zusammen.

7:23 So bleibt die fachliche Logik dort, wo Sie sie lesen, testen und versionieren können. Jetzt die Kehrseite, und auch hier ist die Herstellerdokumentation bemerkenswert ehrlich. Jev nimmt Fragen wörtlich. Es beantwortet die Frage, die Sie geschrieben haben, nicht die, die Sie gemeint haben. Doppelte Verneinungen und Umwege über drei Ecken mag es nicht.

7:44 Ein aufgeblähter Zustand mit vielen irrelevanten Feldern senkt die Genauigkeit — filtern Sie also vorher im Code. Und ein Klassiker aus der Praxis: Fehlt in einer Kategorienliste die Option unklar, muss das Modell sich trotzdem für etwas entscheiden. Das Ergebnis sieht dann sicher aus und ist es nicht. Eine ehrliche Ausweichkategorie kostet nichts und erspart viel Ärger.

Confidence, Schwellenwerte und Wirtschaftlichkeit

8:07 Ein Entscheidungsmodell liefert Wahrscheinlichkeiten. Was Ihre Software daraus macht, entscheiden Sie. In diesem Kapitel geht es um zwei Fragen: Wie wird aus einer Zahl eine Handlung? Und lohnt sich ein weiterer Baustein in der Architektur überhaupt — oder reicht das, was schon läuft? Eine Wahrscheinlichkeit ist eine Auskunft, kein Befehl. Bei Choice und Score rechnet Jev eine Confidence aus, eine einzelne Zahl zwischen null und eins.

8:33 Eins heißt: Die ganze Wahrscheinlichkeit liegt auf einer Antwort. Null heißt: Das Modell hat keine Präferenz. Bei Noul gibt es nur die Wahrscheinlichkeit selbst, und die Sicherheit liest man am Abstand zur Mitte ab. Ein Wert von null Komma fünf ist dort ein Achselzucken. Daraus folgt eine Aufgabe, die kein Modell Ihnen abnimmt: festlegen, ab wann automatisch gehandelt wird, wann nachgefragt wird, wann ein Mensch übernimmt — und welche Aktionen grundsätzlich nie automatisch laufen.

9:02 Diese paar Zeilen enthalten die wichtigste Architekturentscheidung des Moduls, und die Reihenfolge ist kein Zufall. Ganz oben steht das Risiko, nicht die Sicherheit. Geht es um eine heikle Kategorie, etwa eine Vertragsänderung, wird freigegeben — egal, wie sicher sich das Modell ist. Erst danach greifen die Schwellenwerte: hohe Confidence, automatisch weiterleiten; mittlere, beim Kunden nachfragen; sonst ein Mensch.

9:27 Die Werte null Komma sechs und null Komma acht fünf stammen aus einem Beispiel der Dokumentation. Für Ihre Anwendung sind sie nur ein Platzhalter. Ihre eigenen Schwellen ermitteln Sie mit eigenen Testdaten, und jemand im Team muss sie verantworten. Jetzt wird es wirtschaftlich. Ein spezialisiertes Modell spielt seine Stärken dort aus, wo dieselbe Art von Entscheidung sehr oft fällt: Tausende Tickets am Tag, Modell-Routing in einem Agenten, der bei jedem Schritt neu wählt, die Bewertung Dutzender Fundstellen in einer RAG-Abfrage oder Guardrails, die jede Ein- und Ausgabe eines Sprachmodells prüfen.

10:02 Bei ein paar Dutzend Entscheidungen am Tag sieht die Rechnung anders aus. Dann ist das vorhandene Sprachmodell oft gut genug, und eine weitere API mit eigenem Vertrag, Monitoring und Ausfallplan kostet mehr, als sie spart. Die ehrliche Frage lautet also: Haben wir ein Mengenproblem, oder suchen wir eines? Hier die nackten Zahlen, so wie TypeSafe sie heute nennt. Bemerkenswert ist vor allem der Preis: ein Bruchteil eines Cents je Million Eingabetokens, die Ausgabe kostet gar nichts.

10:30 Dazu Antwortzeiten im Bereich weniger hundert Millisekunden. Lesen Sie die Tabelle trotzdem mit einer gesunden Portion Skepsis. Es sind Herstellerangaben, und TypeSafe räumt selbst ein, dass die besonders eindrucksvollen Faktoren für Tempo und Kosten am oberen Ende realer Gewinne liegen. Außerdem verarbeitet Jev nur Text. Bilder, Audio oder Video müssen Sie vorher selbst in Text übersetzen.

10:53 Prüfen Sie diese Angaben vor einer Entscheidung noch einmal — in einem drei Wochen alten Produkt ändert sich vieles schnell.

Evaluation, Governance und bekannte Grenzen

11:01 Die letzten beiden Kriterien entscheiden, ob aus einem vielversprechenden Versuch ein verlässlicher Betrieb wird. Kann man die Qualität der Entscheidungen belegen? Und passt ein gehosteter Dienst zu Datenschutz, Betrieb und Verantwortung im eigenen Haus? Hier scheitern Projekte erfahrungsgemäß häufiger als an der Technik.

11:20 Ein Modell kann sehr sicher und trotzdem falsch sein. Deshalb ersetzt keine Confidence eine echte Prüfung. Was Sie brauchen, ist im Grunde das, was jede gute Klausur braucht: Aufgaben, die den Ernstfall abbilden, und einen Lösungsbogen, den Fachleute bestätigt haben. Häufige Fälle gehören hinein, aber auch seltene, Grenzfälle und Nachrichten, in denen Angaben fehlen oder sich widersprechen.

11:42 Gemessen wird dann nicht nur die Trefferquote, sondern getrennt nach falschen Alarmen und übersehenen Fällen — denn die kosten meist sehr unterschiedlich viel. Und diese Klausur schreibt das Modell nicht einmal, sondern nach jedem Versionswechsel wieder. Diese Liste stammt nicht von Kritikern, sondern aus der Dokumentation des Herstellers selbst — und das spricht für TypeSafe.

12:04 Zu jeder Schwäche gibt es ein Gegenmittel, und fast immer heißt es: Arbeit gehört in den Code oder in die Formulierung. Zwei Zeilen verdienen besondere Aufmerksamkeit. Die Neigung zur ersten Antwortoption bei Choice: Hier kam eine frühe unabhängige Studie zu einem anderen Ergebnis, aber die Doku rät zum Umstellen und Gegenprüfen, und das kostet wenig.

12:23 Und die Sprache: Englisch funktioniert am besten. Für deutschsprachige Supportnachrichten heißt das, Sie brauchen eine eigene Evaluation, bevor Sie sich auf die Zahlen verlassen. Wenige Tage nach dem Start erschienen bereits die ersten unabhängigen Untersuchungen. Das Bild ist differenziert. Bei klassischen Klassifikationsaufgaben schneidet Jev gut ab, und die Wahrscheinlichkeiten bei Choice sind ordentlich kalibriert.

12:48 Schwieriger wird es bei feinen oder unsauberen Kategorien und bei Qualitätsurteilen nach einer Rubrik. Bei Ja-Nein-Fragen sortieren die Wahrscheinlichkeiten gut, liegen aber oft ungünstig zur Grenze von null Komma fünf — ein weiterer Grund, Schwellen selbst zu kalibrieren. Eine Übersichtsarbeit über achtundzwanzig frühe Studien fasst zusammen: Der Vorteil liegt bei Tempo und Kosten, nicht bei der Genauigkeit.

13:12 Das ist kein Makel, aber eine wichtige Einordnung. Und alles davon ist vorläufig. Jev ist kein Modell, das Sie bei sich installieren, sondern ein gehosteter Dienst eines jungen Anbieters. Damit stellen sich die vertrauten Fragen. Welche Daten verlassen das Haus, auf welcher Vertragsgrundlage, wo werden sie verarbeitet? TypeSafe sagt, Kundenanfragen nicht fürs Training zu nutzen.

13:34 Zero Data Retention gibt es aber nur als Enterprise-Option. Ein zweiter Punkt wird gern übersehen: Der Alias jev-latest kann bei einem neuen Release auf eine andere Version zeigen, und dann ändern sich Ihre Entscheidungen über Nacht, ohne dass jemand eine Zeile Code angefasst hat. Produktiv gehört deshalb eine feste Version hinein, dazu ein Plan für den Ausfall und ein Name für die Verantwortung.

13:57 Diese Matrix fasst die sieben Kriterien zusammen, und zwar als Tendenz, nicht als Gesetz. Lesen Sie sie wie einen Wegweiser an einer Kreuzung. Er sagt, wohin eine Straße meistens führt, nicht, dass Sie dort ankommen müssen. Interessant sind vor allem die unteren Zeilen. Hohes Risiko ohne Testdaten heißt: gar nicht automatisch entscheiden, egal mit welchem Modell. Deutsche Inhalte ohne eigene Evaluation heißt: erst ein Pilot.

14:23 Und die letzte Zeile ist vielleicht die ehrlichste des ganzen Moduls: Läuft eine Lösung bei wenigen Aufrufen ohne Kosten- und Latenzprobleme, dann gibt es keinen Grund, sie anzufassen. Neu ist kein Argument. So sieht die Arbeitsteilung bei ServicePilot aus, wenn man alle sieben Kriterien anwendet. Auffällig ist, wie wenig davon tatsächlich bei Jev landet: drei Zeilen von neun.

14:47 Die Kategorie, die Dringlichkeit, die Erstattungsabsicht — genau die Fragen, bei denen Sprachverständnis gefragt ist und das Ergebnis feststeht. Die Reaktionsfrist rechnet der Code, die Antwort formuliert ein Sprachmodell, und bei Geld oder Verträgen entscheidet ein Mensch. Das ist die eigentliche Botschaft dieser Folie.

15:06 Ein Entscheidungsmodell ersetzt weder die Anwendung noch das Sprachmodell. Es übernimmt eng umrissene Teilentscheidungen in einem Ablauf, den Sie kontrollieren. Zum Abschluss des Kapitels vier Fallen, die in der Praxis immer wieder auftauchen. Die erste ist sprachlich: TypeSafe wirbt damit, dass Jev nicht halluziniert. Gemeint ist, dass die Antwort immer in das vorgegebene Format passt. Eine falsche Entscheidung im richtigen Format bleibt trotzdem falsch.

15:33 Zweitens: Was sich nicht rückgängig machen lässt, braucht eine Freigabe, und zwar unabhängig von der Confidence. Drittens: Wer erst die Schwellenwerte festlegt und dann Testdaten sucht, findet erstaunlich oft genau die passenden. Und viertens: Auf jev-latest testen und später auf einer anderen Version produktiv gehen heißt, ein ungeprüftes Modell einzusetzen.

Übung

15:55 Kriterien entfalten ihren Wert erst, wenn man sie anwendet. In der Übung nehmen Sie deshalb einen echten Entscheidungspunkt aus Ihrer eigenen Anwendung und gehen ihn Schritt für Schritt durch — vom Ergebnisraum bis zur begründeten Wahl. Wer gerade keinen eigenen Fall zur Hand hat, nimmt ServicePilot. Die Ausgangslage dürfte vielen bekannt vorkommen: Ein generatives Sprachmodell klassifiziert jede Support-Nachricht per Prompt, gibt einen Satz zurück, und ein Parser versucht, daraus eine Kategorie zu machen.

16:24 Das läuft, aber es fühlt sich an wie ein Provisorium, das zu lange geblieben ist. Mehrere Tausend Nachrichten am Tag machen jede Sekunde Latenz und jeden Cent spürbar. Genau die richtige Situation, um die sieben Kriterien durchzugehen. Wichtig dabei: Das Ziel ist nicht, Jev einzuführen. Das Ziel ist eine begründete Entscheidung — und die kann auch lauten, alles so zu lassen.

16:47 Die fünf Schritte folgen dem Weg dieses Moduls. Zuerst legen Sie fest, welche Entscheidung eigentlich fällt und welche Ergebnisse zulässig sind — die Option unklar gehört dazu. Dann trennen Sie, was sich ausrechnen lässt, von dem, was Sprachverständnis braucht, und zerlegen den Rest in kleine Fragen. Für jede Frage wählen Sie den passenden Typ.

17:07 Der vierte Schritt ist der, den viele überspringen: Für hohe, mittlere und niedrige Sicherheit festlegen, was passiert und wer das verantwortet. Und zuletzt die Belege: Testbeispiele mit Grenzfällen und drei Größen, an denen Sie später messen, ob die Entscheidung trägt. Worum es bei dieser Aufgabe geht, ist eine Fähigkeit, nicht ein Dokument: einen Entscheidungspunkt so einordnen, dass Sie die Wahl einem Kollegen oder einer Architektin gegenüber begründen können.

17:34 Fertig sind Sie, wenn alles schriftlich vorliegt, von der präzisen Entscheidungsfrage über die Eskalationsmatrix bis zu drei Größen, die sich tatsächlich messen lassen. Das muss kein langes Papier sein, eine Seite genügt oft. Und noch ein Hinweis: Nichts davon ist an Jev gebunden. Die Kriterien gelten für jedes Typed Decision Model — auch für die, die in den nächsten Monaten mit Sicherheit noch erscheinen.

Und jetzt?

17:58 Was Sie aus diesem Modul mitnehmen, ist kein Modellwechsel, sondern ein Raster: sieben Kriterien, mit denen sich jede KI-Entscheidung in Ihrer Software einordnen lässt, egal, wie das nächste Modell heißt. Steht die Einordnung, geht es an die eigentliche Umsetzung — Architektur, Guardrails, Evaluation, Betrieb. Genau darum geht es im Seminar KI-Features im eigenen Produkt.

18:20 Besonders lohnt sich die Vertiefung, wenn bei Ihnen heute schon Sprachmodelle klassifizieren, routen oder bewerten und Sie den Verdacht haben, dass das schneller, günstiger und kontrollierbarer ginge. Alle Seminare und weitere Kurzmodule finden Sie auf learning-master.de. Danke fürs Zuhören.