QA-Gates in LLM-Pipelines: Welche Output-Sicherung wirklich hält

Es gibt eine ganze Gattung von Prompts, die mehr wollen, als nur etwas zu erzeugen – sie sollen sich beim Schreiben gleich selbst auf die Finger schauen, mit Markern für ungeprüfte Behauptungen, mit Validierungs-Rollen, mit Wartezuständen vor der Ausgabe, manche sogar mit einem ganzen Tribunal aus fünf simulierten Experten. Das Versprechen dahinter ist über alle Spielarten dasselbe: Am Ende kommt nichts Falsches raus. Ich baue solche Prüf-Prompts selbst, und genau deshalb lässt mich die unbequeme Frage nicht los, die unter dem Versprechen liegt – welcher dieser Prüfschritte sichert tatsächlich etwas ab, und welcher tut nur so?

Das ist keine akademische Spitzfindigkeit. Solche Prüfschritte heißen QA-Gates, und wer den Output einer Pipeline weiterverarbeitet, baut seine ganze Output-Sicherung auf sie. Wenn die Hälfte davon Theater ist, verlässt man sich auf Theater.

TL;DR

Ein QA-Gate ist jeder Prüfschritt zwischen Generierung und Export. Welcher davon wirklich sichert, hängt davon ab, wie weit er vom generierenden Modell wegsitzt.

• Theater-Gates: Das Modell prüft sich selbst und täuscht Kontrolle vor, die es nicht gibt.
• Weiche Gates: Selbstprüfung senkt die Fehlerquote, garantiert aber nichts.
• Harte Gates: laufen außerhalb des Modells und sichern verlässlich – aber nur die Form, nicht die Wahrheit.
• Faustregel: Je weiter ein Gate vom generierenden Modell wegrückt, desto mehr sichert es. Am Ende steht trotzdem ein Mensch.

Was ein Gate aus der Softwareentwicklung mitbringt

Der Begriff Quality Gate kommt nicht aus der KI-Welt, sondern aus der Softwareentwicklung, wo ein Werkzeug wie SonarQube in der CI/CD-Pipeline den Code gegen definierte Schwellen prüft und den Build abbricht, sobald eine davon reißt. Kein Durchkommen, keine Diskussion. Das Gate ist deterministisch: gleiche Eingabe, gleiches Urteil.

Übertragen auf eine LLM-Pipeline meint ein QA-Gate jeden Prüfschritt zwischen Generierung und Export. Klingt sauber, aber der Haken steckt im Wort „deterministisch“. Denn die wenigsten Gates, die in Prompts eingebaut werden, sind das auch.

Die Hierarchie: drei Sorten Gates

Die nützlichste Sortierung läuft nicht nach Funktion, sondern nach Abstand. Wie weit sitzt das Gate vom Modell weg, das den Text erzeugt hat?

Ganz nah dran sitzen die Theater-Gates – Prüfschritte, die im Prompt stehen und vom selben Modell ausgewertet werden, das gerade den Text produziert hat. Eine Stufe weiter liegen die weichen Gates, bei denen das Modell sich selbst prüft, was die Fehlerquote senkt, aber nichts garantiert. Und außerhalb des Modells, mit eigener Mechanik, sitzen die harten Gates. Nur die letzte Sorte verdient den Namen Gate im Sinne der Softwareentwicklung.

Theater-Gates – Kontrolle, die nur so aussieht

Hier beginnt der Hokuspokus, und er ist erstaunlich verbreitet.

Ein Prompt weist das Modell an, vor jeder Analyse zu prüfen, ob „mindestens 2.000 Tokens freier Kontext“ vorhanden sind, und andernfalls abzubrechen. Das liest sich wie eine Schutzvorrichtung, ist aber keine, denn ein Modell kann seinen eigenen Tokenstand gar nicht messen – das Bewusstsein für das eigene Kontextfenster fehlt ihm, und so quittiert es brav mit „Check bestanden“, schlicht weil der Prompt es verlangt. Inszenierte Kontrolle, mehr nicht.

Noch schöner sind Prompts mit eingebautem Pseudocode, der suggeriert, der Output werde fünfmal analysiert und daraus per Standardabweichung und Mittelwert ein Konfidenz-Level berechnet. In einem einzigen Completion-Durchlauf passiert keine dieser Rechnungen, das Modell nennt am Ende einfach eine plausibel klingende Zahl mit einem Label daneben. Konfabulierte Präzision in Reinform.

Und dann der Klassiker: ein „Warte auf Go“-Zustand, beschrieben wie eine State-Machine, durchgesetzt vom selben Modell, das den Text erzeugt. Eine echte State-Machine hält an, weil ihr Code sie anhält; ein Modell dagegen hält an, weil es gerade so kommt – oder eben nicht. Ein Soft-Constraint mit Schranken-Cosplay.

Was diese drei Beispiele eint, ist derselbe Trick: Sie verlagern eine Kontrolle, die mechanisch und damit überprüfbar wäre, in die Selbstauskunft des Modells. Und Selbstauskunft ist genau das, worauf man sich am wenigsten verlassen kann.

Weiche Gates – senken die Quote, garantieren nichts

Zwischen Theater und echter Schranke liegt ein Feld, das tatsächlich etwas bringt, nur eben weniger, als draufsteht. Selbst vergebene Marker für ungeprüfte Behauptungen, ein Critique-Durchgang, ein „prüfe deine Antwort noch einmal“ – solche Schritte verschieben die Wahrscheinlichkeit in Richtung weniger Fehler. Ein Garant sind sie nicht.

Die Forschung ist hier ungewöhnlich eindeutig. Eine vielzitierte Untersuchung von Huang und Kollegen zeigt, dass intrinsische Selbstkorrektur ohne externes Feedback das Reasoning nicht verlässlich verbessert, und dass in etlichen Fällen das Ergebnis nach der Selbstkorrektur sogar schlechter ausfällt als davor. Das Modell redet sich seine richtige Antwort kaputt.

Der eigentliche Knackpunkt liegt eine Ebene tiefer. Tyen und Co fanden heraus, dass Modelle einen Fehler durchaus beheben können, sobald man ihnen die Fehlerstelle nennt, ihn aber selbst kaum finden. Übersetzt auf Gates heißt das, dass die Abwesenheit eines [PRÜFEN]-Markers kein Beleg für Fehlerfreiheit ist – das Modell hat den Fehler vielleicht schlicht nicht gesehen. Strukturierte Denk-Anstöße im Prompt helfen da nur begrenzt, und auch das nur bei bestimmten Aufgaben.

Besonders fragwürdig wird es, wenn das weiche Gate als „zweiter Experte“ im selben Prompt auftritt, gespeist vom selben Modell, das schon den Text geschrieben hat. Dann greift der Self-Preference Bias: Modelle bewerten ihre eigenen Ausgaben systematisch zu gut, auch wenn die Quelle anonymisiert ist. Ein Prüfer, der sich selbst prüft, ist ein milder Prüfer. Und die zugewiesene Experten-Rolle ändert daran nichts, weil sie Stil verschiebt, nicht Kompetenz – ein „Du bist strenger Fakten-Prüfer“ macht das Modell nicht zu einem, es färbt nur den Ton seiner Selbstbestätigung.

Harte Gates – außerhalb des Modells

Jetzt die Sorte, die hält. Gemeinsamer Nenner: Sie laufen nicht im Kopf des generierenden Modells, sondern daneben.

Das simpelste harte Gate ist eine Verbotsliste per Regex, die ein Stück Code den Export blockieren lässt, sobald ein Begriff auftaucht, der nicht raus darf – stumpf, aber zuverlässig, weil deterministisch.

Eine Stufe darüber stehen Structured Outputs über Constrained Decoding, bei denen der Decoder nicht das Modell höflich um valides JSON bittet, sondern bei jedem Token alle Optionen wegmaskiert, die das Schema verletzen würden. Das garantiert Schema-Konformität per Konstruktion, nicht „meistens“, sondern immer. OpenAI bietet das seit August 2024 als Strict Mode, Anthropic seit November 2025, lokal liefern Outlines , XGrammar und Guidance dasselbe. Welches Format am Ende sinnvoll ist, hängt am Anwendungsfall, dazu habe ich die gängigen LLM-Datenformate an anderer Stelle gegeneinandergestellt.

Das härteste Urteils-Gate ist ein separater Judge mit einem anderen Modell, denn sobald Generierung und Bewertung auseinanderfallen, schrumpft der Self-Preference-Bias. Eine Warnung bleibt: Teilen sich beide Modelle dieselbe Trainingslinie, ist die Selbstbevorzugung systematisch über den ganzen Pool und innerhalb des Pools nicht erkennbar. Ein Judge aus derselben Modellfamilie ist also nur ein halbes Gate.

In dieselbe Kategorie gehört echtes Self-Consistency, das oft mit dem Theater-Pendant verwechselt wird, obwohl es etwas grundlegend anderes tut. Die Methode von Wang und Kollegen erzeugt mehrere getrennte Reasoning-Pfade per Sampling und aggregiert sie extern per Mehrheitsvotum, und der entscheidende Unterschied liegt genau hier: getrennte Generierungen plus ein externer Aggregationsschritt, nicht „bewerte dich im selben Prompt fünfmal“. Es greift nur, wenn die Aufgabe eine aggregierbare Antwort hat, und es fängt zufällige Ausrutscher, keinen systematischen Fehler, der in allen Pfaden gleich auftritt. Wer beim Sampling ohnehin an der Diversität der Pfade dreht, kennt die Mechanik schon.

Ein Detail noch, das die harte Schiene relativiert. Ein Constraint kann das Modell von seinen bevorzugten Tokens wegzwingen, und dann leidet manchmal die Output-Qualität – das Gate hält die Form, kostet aber gelegentlich Substanz. Genau wie bei Constraint-Based Prompting hängt der Nutzen am Modell und am Einsatzszenario, nicht an einer pauschalen Regel.

Was Output-Sicherung tatsächlich bringt

Hier ist die Stelle, an der man ehrlich sein muss. Selbst das härteste Gate sichert die Form, nicht die Wahrheit. Ein per Constrained Decoding erzwungenes JSON ist garantiert schema-konform und kann trotzdem inhaltlich falsche oder schlechte Werte enthalten, weil die Schranke nur prüft, ob das Feld da ist, und nicht, ob der Wert stimmt.

Output-Sicherung leistet also zwei Dinge und ein drittes nicht: Sie verschiebt Wahrscheinlichkeit, was die weichen Gates übernehmen, und sie sichert Form, was die Aufgabe der harten ist – Korrektheit aber garantiert keines von beiden. Wer das verinnerlicht, hört auf, Gates als Wahrheitsmaschine zu lesen, und fängt an, sie als das zu bauen, was sie sind: gestaffelte Filter mit unterschiedlicher Maschenweite.

Und genau deshalb gehört die Sicherung nicht in den Prompt, sondern in die Architektur, denn ein Marker im Systemprompt skaliert nicht, ein Schema-Check in der Pipeline schon. Das ist dieselbe Verschiebung, die Spec-Driven Generation vom Prompt-Trick zum Architektur-Pattern gemacht hat, und sie ist Teil dessen, was man heute Context Engineering nennt. Die Frage ist nicht mehr, wie man das Modell höflich um Sorgfalt bittet, sondern welcher Schritt außerhalb des Modells den Output abfängt, bevor er Schaden anrichtet.

Mein Take

Das beste Gate ist das, das das generierende Modell nicht selbst auswertet. Alles, was im Prompt steht und vom selben Modell abgenickt wird, ist bestenfalls ein Wahrscheinlichkeits-Schubser und schlimmstenfalls Bühnennebel, während die deterministischen Schranken daneben immerhin die Form sichern: dass das Feld da ist, dass kein Verbotswort durchrutscht, dass das JSON parst. An die Wahrheit kommt keine davon. Das kann nur ein urteilsfähiger Prüfer, ein anderes Modell als Judge oder der Mensch am Ende, und auch der irrt – er ist nur die einzige Instanz, die überhaupt die richtige Frage stellt, nämlich nicht „ist die Form korrekt“, sondern „stimmt das hier“. Wer mehr verspricht, verkauft Hokuspokus mit Pseudocode-Garnierung.