Output-Validierungsmuster für Finance-KI

Output-Validierung ist der Code, den Sie zwischen ein Modell und einen Finanzprozess schalten, um schlechten Output abzufangen, bevor er eine Entscheidung oder einen Audit-Trail erreicht. Sie funktioniert in Schichten: Ein Schema prüft die Struktur, Business-Constraints kodieren Ihre Fachregeln, und ein Verifikationsschritt bindet jede bedeutsame Kennzahl an ein Quellsystem zurück. Jede Schicht fängt eine andere Art von Fehler ab, die die darunterliegende nicht sehen kann.

Der Fehlerfall, der tatsächlich wehtut, ist eine selbstbewusste, sauber formatierte Antwort mit einer falschen Zahl darin. Diese Antwort sieht fertig aus, also besteht sie die Prüfung durch müde Menschen und landet in einem Report. Ein holpriger Satz löst nie einen Vorfall aus. Ein sauberer Satz, der auf einer um den Faktor zehn danebenliegenden Zahl aufbaut, schon.

Die meisten Teams behandeln all das als ein einziges Problem und greifen zu JSON Schema. Ein Schema ist notwendig, und es ist die schwächste der drei Schichten, die Sie brauchen. Es belegt, dass die Form stimmt, und sagt nichts darüber, ob der Inhalt wahr ist. Im Finanzbereich ist der Inhalt der springende Punkt, also sitzt die eigentlich interessante Arbeit oberhalb des Schemas.

Ein striktes Schema ist das Fundament

Beginnen Sie mit einem strikten Schema bei jedem Modellaufruf, der in ein System einfließt. Pflichtfelder, typisierte Werte, Enums für alles Kategoriale, Formatvorgaben für Daten und Bezeichner. Eine Antwort, die nicht parst, gelangt gar nicht erst in die Pipeline. Allein das entfernt den Long Tail halb ausgegebener Objekte, den angehängten Kommentar, den das Modell an gültiges JSON anflanscht, und das gelegentlich erfundene Feld, weil der Prompt abgedriftet ist.

Es gibt zwei Wege, die Form richtig hinzubekommen, und sie sind nicht austauschbar:

• Constrained Decoding zwingt das Modell, nur Tokens auszugeben, die die Grammatik erlaubt, sodass ein Enum-Feld physisch nur eines seiner Mitglieder produzieren kann und eine Konto-ID bereits zur Generierungszeit ihrem Muster entspricht. Das ist das richtige Werkzeug für feste Vokabulare und starre Formate.
• Nachgelagerte Validierung lässt das Modell frei generieren und verwirft und repariert danach alles, was am Schema scheitert. Das ist das richtige Werkzeug für alles Lange oder Offene, wo eine Grammatik gegen das Modell arbeiten und Sie Latenz für wenig Gewinn kosten würde.

Setzen Sie Constrained Decoding bei den Feldern ein, deren Raum gültiger Antworten klein und bekannt ist. Setzen Sie Validieren-und-Wiederholen beim Fließtext ein. Beides pro Feld innerhalb einer Antwort zu mischen ist normal und meist genau das, was Sie wollen.

Was ein Schema nie leisten wird, ist Ihnen zu sagen, dass die Zahl korrekt ist. Ein Modell kann {"exposure": 4200000, "currency": "EUR"} zurückgeben, das jede Vorgabe erfüllt und dennoch um den Faktor zehn danebenliegt, weil es die falsche Zeile gelesen hat. Die Schema-Validierung winkt das durch. Das Fundament ist also wichtig, und es ist eben nur das Fundament.

Die Verifikationsschicht leistet die eigentliche Arbeit

Hier verdient sich eine Pipeline von Finanzqualität ihren Lohn. Jeder Wert, der Bedeutung trägt, wird gegen etwas geprüft, das nicht das Modell ist. Das Muster ist unabhängig von der Domäne dasselbe:

• Verankern Sie jede Kennzahl. Wenn das Modell einen Saldo, eine Covenant-Schwelle oder ein Kontrahentenexposure meldet, muss dieser Wert auf einen Quelldatensatz zurückführbar sein. Hängen Sie die Lineage an. Lässt er sich nicht zurückverfolgen, geht er nicht in Produktion.
• Reconciliation über Quellen hinweg. Wenn drei Systeme eine Kennzahl auf drei Weisen melden, legt der Verifikationsschritt die Diskrepanz offen, statt das Modell still eine davon wählen zu lassen. Die Reconciliation eskaliert den Konflikt zur Klärung durch einen Menschen; sie rät nie.
• Rechnen Sie alles Ableitbare neu. Verhältniszahlen, Summen, gewichtete Durchschnitte und Datumsarithmetik sollten im Code aus den verankerten Eingaben berechnet werden, nicht der modelleigenen Arithmetik vertraut. Modelle sind unzuverlässige Rechner, und es gibt keinen Grund, sie Summen bilden zu lassen, die Sie deterministisch selbst bilden können.
• Erzwingen Sie Point-in-Time-Korrektheit. Eine Kennzahl, die an einem Stichtag hängt, muss aus den Daten stammen, wie sie zu diesem Datum vorlagen. Genau hier schleicht sich Lookahead ein: Ein Modell zieht bereitwillig eine restatete Zahl oder einen Wert, der nach dem Stichtag entstanden ist, und der Output sieht in Ordnung aus, bis ein Prüfer fragt, warum ein Q2-Memo eine Zahl zitiert, die es erst in Q3 gab.

Die Verifikationsschicht ist deterministischer Code, der dem Modell nachgelagert ist. Sie weiß, dass das Schema bereits erfüllt ist, kann also die Struktur voraussetzen und sich ganz auf die Wahrheit konzentrieren. Scheitert eine Prüfung, wird das Element in eine menschliche Warteschlange geleitet, samt der fehlgeschlagenen Prüfung und den widersprüchlichen Quellwerten. Es wiederholt nicht still, denn ein stiller Retry, der irgendwann durchgeht, ist der Weg, auf dem eine falsche Zahl bis zum Straight-Through-Processing durchrutscht.

Constraints, die Ihre Geschäftsregeln kodieren

Zwischen Struktur und faktischer Verankerung liegt eine dritte Schicht, die Teams überspringen und später bereuen: Business-Constraints. Diese Regeln betreffen nicht die JSON-Form, und sie betreffen nicht einen einzelnen Quellwert. Sie beschreiben, was in Ihrer Domäne eine gültige Antwort überhaupt sein kann.

Beispiele, die ständig auftauchen:

• Feldübergreifende Konsistenz. Eine als inländisch markierte Transaktion darf ohne befülltes Erklärungsfeld keine ausländische Abwicklungswährung tragen. Ein Risk-Rating “low” ist unvereinbar mit einem Exposure oberhalb einer festgelegten Obergrenze.
• Grenzen und Plausibilität. Eine Wahrscheinlichkeit außerhalb von null und eins, ein negativer Personalbestand, ein Zinssatz jenseits eines plausiblen Bandes. Billig zu prüfen, und sie ertappen das Modell, wenn es selbstbewusst fabuliert.
• Referenzielle Integrität. Jede Entität, die der Output benennt, muss sich zu einem realen Datensatz auflösen lassen. Gescheiterte Entity-Resolution ist eine häufige und leise Quelle falschen Outputs, weil das Modell einen plausiblen Kontrahentennamen erfindet, den es in Ihren Büchern nicht gibt.

Kodieren Sie diese als explizite Prädikate, versionieren Sie sie und halten Sie sie neben dem Eval-Set. Wenn eine Aufsichtsbehörde oder ein interner Prüfer fragt, warum ein Output akzeptiert wurde, lautet die Antwort: die Liste der Prüfungen, die er bestanden hat, jede einzelne auditierbar. Unter SR 11-7 ist diese Nachvollziehbarkeit keine nette Zugabe; ein Modell in einem Entscheidungspfad muss erklärbar und überwacht sein, und eine Validierungssuite ist ein großer Teil dessen, wie Sie das belegen.

Eine letzte Disziplin bindet die Schichten zusammen. Jeder Fehlschlag, auf jeder Schicht, ist ein gelabeltes Beispiel. Eine Schema-Verletzung, ein Reconciliation-Mismatch, eine überschrittene Grenze, ein Mensch, der eine akzeptierte Antwort kippt: Jeder davon geht zurück in das Eval-Set und in Ihr Drift-Monitoring. Die Validierungsschichten leisten doppelte Arbeit. In Produktion regeln sie den Output. Über aufeinanderfolgende Quartalsabschlüsse hinweg verraten sie Ihnen auch, ob das Modell besser wird oder still schlechter, gemessen an den Fällen, die Ihnen wichtig sind.