LLMs geben trotz expliziter Anweisungen strukturierte Ausgaben preis

Das Problem: LLM-Validierung gibt Erklärungen preis

Ein Entwickler, der ein Tool erstellt, das parallele API-Aufrufe an Claude durchführt und strukturierte Ausgaben pro Aufruf analysiert, stieß auf ein intermittierendes Problem. Jeder Aufruf gibt Inhalte innerhalb spezifischer Markierungen wie [COVER], [SLIDE 1], [CAPTION] usw. zurück. Ein zweiter LLM-Durchgang validiert die Ausgabe anhand von Regeln und schreibt alles um, was nicht den Vorgaben entspricht.

Die Validierungseingabeaufforderung weist explizit an: "geben Sie NUR den korrigierten Text im exakt gleichen Format zurück. Keine Kommentare. Keine Erklärungen. Keine Verstoßlisten."

Trotzdem gibt das Validierungsmodell gelegentlich seine Erklärungen vor dem korrigierten Inhalt aus. Beispiele umfassen: "Ich muss diesen Text auf Verstöße prüfen... Diese Sätze bilden ein dramatisches Paar, das rein zur Wirkung eingesetzt wird. Hier ist die Überarbeitung:" gefolgt vom tatsächlich korrigierten Text.

Folgewirkungen

Dieser Erklärungstext wird direkt an den Parser weitergegeben. Der Parser erwartet Inhalte, die bei [COVER] beginnen, erhält jedoch stattdessen Meta-Kommentare. Dies führt zu Feldverschiebungen in nachgelagerten Prozessen. In einem Fall landete der Erklärungstext des Validators in einem Bildaufforderungsfeld, weil der Parser die Erklärung als Hauptinhalt interpretierte und alles um einige Zeilen verschob.

Alleiniges Präzisieren der Eingabeaufforderung löste das Problem nicht. Explizitere Anweisungen, das Hinzufügen von "Ihre Ausgabe MUSS mit der ersten Inhaltsmarkierung beginnen" und "schließen Sie niemals Erklärungen ein" reduzierten die Häufigkeit, beseitigten es aber nicht. Das Modell ignoriert gelegentlich Anweisungen, insbesondere wenn es Verstöße zu beheben findet – es möchte seine Arbeitsweise zeigen.

Die Lösung: Zwei-Ebenen-Abwehr

Die funktionierende Lösung umfasste zwei Ebenen:

• Ebene 1: Präzisierung der Eingabeaufforderung. Immer noch sinnvoll, weil sie die Problemhäufigkeit reduziert.
• Ebene 2: Eine defensive Filterfunktion, die bei jeder Validierungsausgabe ausgeführt wird, bevor eine Analyse stattfindet. Für strukturierte Formate wird an der ersten erkannten Markierung verankert und alles davor verworfen. Für Klartextformate werden Zeilen entfernt, die bekannten Validatorkommentarmustern entsprechen (wie "Lassen Sie mich diesen Text prüfen" oder "Dies verstößt gegen die Vorgabe").

Die Reihenfolge "Filtern vor Analysieren" ist entscheidend. Jeder nachgelagerte Parser arbeitet mit bereits bereinigter Ausgabe. Dies vermeidet die Pflege von pro-Feld-Filterlogik oder das Bekämpfen neuer Erklärungsformate wie bei einem Whack-a-Mole-Spiel.

Implementierungsüberlegungen

Für Klartext-Filtermuster ist ein sorgfältiges Design erforderlich. Ein Regex, der "Dies ist ein Verstoß" erfasst, könnte auch "Dies ist ein häufiger Fehler" in legitimen Inhalten erfassen. Muster sollten so präzise sein, dass sie nur validatorspezifische Sprache erfassen, wie "Dies verstößt gegen die/eine Regel/Vorgabe" statt breiter Übereinstimmungen mit "Dies ist" oder "Dies verwendet". Jedes Muster muss vor dem Einsatz an echten Inhalten überprüft werden.

Wenn Sie strukturierte Ausgaben eines LLM analysieren, behandeln Sie Eingabeaufforderungsanweisungen als ersten bestmöglichen Durchgang und haben Sie immer eine codebasierte Abwehr vor dem Parser. Das Modell wird in 95 % der Fälle folgen, aber die 5 %, in denen es das nicht tut, werden nachgelagerte Logik auf schwer reproduzierbare Weise brechen, weil sie intermittierend auftreten.