Ausgabeverifizierung und menschliche Inspektion

Gewinne:

• Möglichkeit, schema- und regelbasierte Ausgabevalidierungsebenen einzurichten
• Fähigkeit, bei Entscheidungen mit großer Auswirkung sinnvollerweise den Menschen als Beobachter einzubeziehen
• Möglichkeit, mit dem zweiten Modell ein auf Verifizierung und Vertrauensschwellenwerten basierendes Routing zu entwerfen

Ein Sprachmodell erzeugt flüssige, überzeugende und oft genaue Ergebnisse – aber „überzeugend“ ist nicht dasselbe wie „richtig“. Das Modell kann stillschweigend einen Betrag, ein Datum oder ein JSON-Feld anpassen. Dies nennt man Halluzination (das Modell produziert selbstbewusst Informationen, die in der Realität nicht existieren). Wenn diese Ausgabe in einem Unternehmenssystem zum nächsten Schritt fließt – einer Zahlung, einer E-Mail, einem Datenbankschreibvorgang –, greift der Fehler auf die reale Welt über. In dieser Einheit lernen wir, die Ausgabe mit Verifizierungsebenen zu filtern, bevor sie in das System gelangt, und bei Entscheidungen mit großer Auswirkung den Einsatz von Human-in-the-Loop zu erlernen.

Warum ist eine Ausgabevalidierung erforderlich?

Die Modellausgabe kann hauptsächlich auf zwei Arten beschädigt werden: Format (entspricht nicht dem erwarteten JSON-Schema, Feld fehlt/überzählig) und Inhalt (das Format ist korrekt, aber der Wert ist falsch – ein nicht vorhandener Produktcode, ein unlogisches Datum). In Bezug auf die Sicherheit gibt es eine dritte Dimension: böswillige Ausgabe (ein böswilliger Befehl, der als Ergebnis einer Injektion oder eines Lecks erzeugt wird). Ein solides System stoppt alle drei an der Tür.

Achtung: „Modell im Allgemeinen genau“ ist kein Produktionskriterium. In einem System ohne Verifizierung bedeutet bereits ein Fehler von tausend 100 fehlerhafte Transaktionen pro Tag bei 100.000 Anfragen pro Tag.

Authentifizierungsebenen: Schritt für Schritt

1. Schemavalidierung. Überprüfen Sie mit der Maschine, ob die Ausgabe der erwarteten Struktur entspricht: Sind die Felder vorhanden, sind ihre Typen korrekt, sind die erforderlichen Felder ausgefüllt?
2. Validierung von Regeln/Geschäftslogik. Stimmen die Werte mit den Geschäftsregeln überein? (Menge > 0, Datum liegt nicht in der Zukunft, Produktcode gehört zum Katalog.)
3. Referenz-/Quellcodeverwaltung. Wenn das Modell eine Behauptung erzeugt, kann diese mit der Quelle verknüpft werden? (Ist das RAG-Zitat tatsächlich im Dokument enthalten?)
4. Validierung mit dem zweiten Modell (LLM-as-judge). Ein unabhängiges Modell bewertet die Ausgabe als „richtig/unvollständig/riskant“.
5. Vertrauensschwelle und Orientierung. Wenn das Modell oder der Validator ein geringes Vertrauen meldet, wird die Ausgabe nicht automatisch bestanden; richtet sich an den Menschen.
6. Menschliche Kontrolle. Ein hochwirksames oder wenig sicheres Ergebnis hängt von der Zustimmung eines Experten ab.

Vier kopierbare Vorlagen

Schema + „Nachholen, wenn Sie es nicht wissen“ zusammen:

Geben Sie die Antwort NUR im folgenden JSON-Schema zurück: Schreiben Sie „low“. Schreiben Sie NIEMALS einen Kostenvoranschlag, als wäre dieser exakt.

Überprüfung mit zweitem Modell (Richteraufforderung):

Sie sind ein unabhängiger Validator. Nachfolgend finden Sie einen <Quelle>-Text und einen <Anspruch>. Überprüfen Sie, ob JEDE Zahl und jedes Datum im Anspruch wörtlich in der Quelle vorkommt. Sagen Sie für jeden: „bestätigt | nicht in der Quelle | widerspricht der Quelle.“ Wenn auch nur einer davon „fehlt/widersprüchlich“ ist, markieren Sie das Ergebnis als „MENSCHLICHE ÜBERPRÜFUNG ERFORDERLICH“.<source>{{ text }}</source><claim>{{ model_output }}</claim>

Vertrauensschwellen-Routingregel:

Routing-Regel: – emin_misin = „hoch“ UND Betrag < 10.000 TL -> automatische Verarbeitung – emin_misin = „mittel“ ODER Betrag 10.000–100.000 TL -> zweite Modellüberprüfung – emin_misin = „niedrig“ ODER Betrag > 100.000 TL -> menschliche Genehmigung erforderlich

Zusammenfassungskarte für menschliches Audit (beschleunigt die Überprüfung):

Wenn Sie jemandem die Entscheidung überreichen, legen Sie diese Karte vor: Was wird vorgeschlagen? (ein Satz) – Auf welcher Quelle basiert es? (Artikel-/Dokumentreferenz) – Was sind die beiden schwächsten Annahmen? – Können sie rückgängig gemacht werden, wenn sie genehmigt werden? (ja/nein)

Schwache Eingabeaufforderung / Starke Eingabeaufforderung

schlechter Ansatz

Starker Ansatz

„Betrag von Rechnung abziehen“ (Freitext)

Striktes JSON-Schema + Null + Vertrauensfeld

Schreiben der Ausgabe direkt in das Zahlungssystem

Schema → Regel → menschliche Zustimmung (falls erforderlich)

Sagen Sie dem Model einfach: „Seien Sie sicher.“

Nummern-/Datumsvalidierung mit zweitem Modell

Verarbeiten Sie jede Ausgabe mit der gleichen Sicherheit

Routing basierend auf Einfluss und Vertrauen

Der starke Ansatz hofft nicht, dass das Modell korrekt ist; Es schafft eine Tür, die Sie auffängt, wenn Sie falsch liegen.

Drei Mini-Hüllen

Fall 1 – Die Regelung allein reichte nicht aus. Eine Buchhaltungsautomatisierung extrahierte den Betrag als JSON aus den Rechnungen. Das Schema stimmte, allerdings ergab das Modell auf einer Rechnung „125.000“ statt „1.250,00“ (Dezimalverschiebung). Der Plan konnte dies nicht erfassen; Die Regelüberprüfung („Der Betrag muss ±1 % mit der Summe der Rechnungspositionen übereinstimmen“) wurde abgefangen und eine fehlerhafte Erfassung von 112.500 TL verhindert.

Fall 2 – Das zweite Modell erfasste die Halluzination. „30 Tage Kündigungsfrist“, sagte ein Rechtsberater in der Vertragszusammenfassung; Im Vertrag standen jedoch 90 Tage. Als der unabhängige Richter das Modell als „im Widerspruch zur Quelle“ markierte, wurde die Ausgabe an den Menschen weitergeleitet und korrigiert. Wäre es automatisch, würde der Kunde die Stornierung mit dem falschen Datum mitteilen.

Fall 3 – Routing reduzierte die Last um 70 %. Ein Versicherungsanspruchssystem genehmigte automatisch Ansprüche mit geringem Betrag und hoher Sicherheit und schickte nur diejenigen über dem Schwellenwert/niedriger Sicherheit an den Sachverständigen. Von den 3.200 täglichen Forderungen entfielen nur 950 auf den Menschen; Experten widmeten ihre Zeit den wirklich riskanten 30 %, wobei die durchschnittliche Transaktionszeit von 4 Stunden auf 40 Minuten sank.

Tipp: Richten Sie die menschliche Kontrolle nicht so ein, dass „die Leute alles sehen können“ – das wird die Leute ermüden und die Zustimmung wird zum Stempel. Leiten Sie stattdessen nur Ergebnisse mit großer Wirkung und geringem Vertrauen an den Menschen weiter; Dadurch wird die Aufmerksamkeit auf das Wesentliche gelenkt.

Menschliche Kontrolle sinnvoll gestalten

Bei Human-in-the-Loop geht es nicht darum, ein Kontrollkästchen zu Papier zu bringen. Der Gutachter muss (1) den Kontext haben, um die Entscheidung zu verstehen, (2) Zugang zur Quelle und (3) die Autorität haben, „Nein“ zu sagen. Ansonsten bleibt die Kontrolle kosmetisch. Die Rezensionskarte (vierte Vorlage oben) soll genau diesen Kontext bieten.

Häufige Fehler

• Führen Sie einfach eine Schemavalidierung durch und überspringen Sie Inhalts-/Wertfehler.
• Denken Sie, dass Sie eine echte Überprüfung durchführen, indem Sie dem Modell sagen: „Stellen Sie sicher“.
• Setzen Sie wirkungsvolle, unumkehrbare Entscheidungen automatisch um.
• Übertragen Sie die menschliche Kontrolle auf jede Ausgabe und verwandeln Sie die Genehmigung in einen bedeutungslosen Stempel.
• Dem Rezensenten „Genehmigen“ sagen, ohne die Quelle und den Kontext anzugeben.
• Verarbeiten aller Ausgaben mit dem gleichen Risiko, ohne einen Vertrauensschwellenwert und Routing festzulegen.

Zusammenfassend

• Die Ausgabe ist auf drei Arten beschädigt: Form, Inhalt und böswillige Absicht; Ein solides System stoppt alle drei an der Tür.
• Ebenen: Schemavalidierung, Regel-/Geschäftslogik, Quellcodeverwaltung, zweites Modell (LLM-as-Judge) und Vertrauensschwellenwert-Routing.
• Bei Ausgängen mit hoher Auswirkung und geringer Sicherheit sollte die Einbindung von Menschen in die Schleife obligatorisch sein.
• Die menschliche Überprüfung muss sinnvoll sein: Der Prüfer muss über Kontext, Zugriff auf Ressourcen und die Befugnis verfügen, „Nein“ zu sagen.
• Sowohl Sicherheit als auch Effizienz werden dadurch erreicht, dass nur die riskanten Maßnahmen an den Menschen weitergeleitet werden, nicht jede Ausgabe.

Anwendungsaufgabe

Nehmen Sie ein Beispiel aus Ihrer eigenen KI-Ausgabe. Definieren Sie zunächst ein JSON-Schema und erzwingen Sie die Ausgabe dorthin. Schreiben Sie dann mindestens zwei Geschäftsregeln (z. B. „Betrag stimmt mit der Gesamtzahl der Artikel überein“). Richten Sie abschließend eine Routing-Tabelle ein: Welche Vertrauens-/Einflusskombination geht automatisch, welche geht an das zweite Modell, welche geht an den Menschen? Erzeugen Sie eine fehlerhafte Probe und beobachten Sie, wo jede Schicht sie erfasst.

Checkliste

• [ ] Ich definiere ein striktes Schema für die Ausgabe und überprüfe es mit der Maschine.
• [ ] Ich habe mindestens eine Geschäfts-/Regelvalidierung (Wertlogik) hinzugefügt.
• [ ] Ich kann die Behauptungen mit der Quelle verknüpfen und überprüfen.
• [ ] Zweites Modell oder menschliche Validierung verfügbar für Ergebnisse mit hoher Auswirkung/geringer Sicherheit.
• [ ] Routing-Regel basierend auf Vertrauen und Einfluss definiert.
• [ ] Dem Gutachter werden Kontext, Quelle und Befugnis zur Ablehnung mitgeteilt.