Wo ein Entscheidungsmodell tatsächlich hingehört

Jede Dokumenten-Pipeline beginnt mit der Entscheidung, was überhaupt eingegangen ist. Rechnung, Lieferschein, Vertragsnachtrag oder etwas Unlesbares, das einen Menschen braucht. Die meisten Teams lösen das mit einem kleinen Modellaufruf plus JSON-Schema und härten anschließend wochenlang den Parser.

Eine typisierte Auswahl mit Konfidenzwert eliminiert das Parsing-Problem vollständig, weil die Ausgabe nie Text war. Der Schwellenwert, ab dem ein Fall an einen Menschen geht, wird damit zu einer eingestellten Größe statt zu einer Heuristik im Code.

Bei Retrieval Augmented Generation ist nicht der fehlende Textabschnitt der teure Fehler, sondern der irrelevante, der zu einer selbstbewusst falschen Antwort synthetisiert wird. Jeden Kandidaten vor der Synthese auf tatsächliche Relevanz zu bewerten ist der wirksamste Guardrail der Pipeline und wird am häufigsten weggelassen, weil ein Sprachmodell dafür einen zusätzlichen Aufruf pro Abschnitt bedeutet.

Im Sub-Cent-Bereich bewertet man alle, und zwar nicht nur auf Relevanz: ob der Abschnitt die Antwort überhaupt stützt, ob er der Frage widerspricht, ob er eine eingeschleuste Anweisung enthält. Das sind vier Nouls auf demselben Zustand. Wie dieselbe Schicht in der Praxis eingesetzt wird, zeigt Was Entwickler mit Jev tatsächlich bauen.

Agentische Systeme verbringen einen überraschend großen Teil ihres Latenzbudgets mit der Entscheidung, welches Werkzeug als Nächstes aufgerufen wird. Diese Entscheidung ist eine Auswahl aus einer festen Menge. Sie braucht keine Begründung, sie muss richtig und schnell sein.

Der belastbare Teil des Musters liegt in der Trennung der Achsen: Die Antwort sagt, was gewählt wurde, die Konfidenz sagt, wie sicher. Eine umkehrbare Aktion darf bei geringer Konfidenz laufen, eine unumkehrbare nicht. Damit wird aus einem Modellaufruf eine Freigabelogik, die im Code liegt und dort auch geprüft werden kann.

Nach der Extraktion eines Feldes muss etwas beurteilen, ob es vollständig und plausibel wirkt. Teams überspringen das, prüfen stichprobenartig oder leiten alles an einen Menschen weiter. Ein kalibrierter Score pro Feld macht daraus einen Schwellenwert, den man gegen ein reales Fehlerbudget einstellen kann statt gegen ein Bauchgefühl.

Policy-Prüfungen sind ebenfalls Klassifikationen. Üblicherweise laufen sie nur auf Anfragen, die jemand als riskant markiert hat, weil sie überall zu langsam und zu teuer waren. Diese Einschränkung entfällt weitgehend.

Einen Monat produktiver Klassifikationsaufrufe nehmen und erneut abspielen. Genauigkeit und p95-Latenz gegen den heutigen Stand vergleichen. Dann nicht den Gesamtscore ansehen, sondern die Abweichungen, denn die Abweichungen zeigen, ob die Aufgabe jemals eine Sprachaufgabe war. Der Test kostet weniger als das Meeting darüber, ob man ihn durchführt. Die Schnittstelle dafür liegt bereits in gängigen Werkzeugketten, etwa als evaluate-Aufruf im AI SDK.

Der größere operative Gewinn steckt nicht in der Inferenzersparnis. Die meisten B2B-KI-Pipelines haben dünne Observability, weil die Bewertung jedes Schritts einen weiteren Modellaufruf kostet und dafür niemand Budget einplant. Sinkt die Bewertung auf einen Rundungsfehler, lässt sich jeder Schritt jedes Laufs bewerten, die Verteilung festhalten und Drift erkennen, bevor ein Nutzer sie meldet.

Nicht geeignet ist das Muster für alles, was eine Begründung liefern, an einen Menschen schreiben oder über den übergebenen Zustand hinausgreifen muss. Ein Entscheidungsmodell hat kein Weltwissen und keine Begründung. Arbeit dieser Art dorthin zu geben ist der Weg, auf dem ein erster Pilot scheitert.