Der Symmetrie-Test: Ein Prompt-Fix, den man nicht reproduzieren kann

Man kann nicht immer beweisen, dass ein Prompt-Fix funktioniert. Manche Produktionsfehler treten nur mit dem vollständigen Kontext auf, der sie verursacht hat – und keine Offline-Umgebung reproduziert sie. In solchen Fällen ist die ehrliche Frage nicht „Behebt der Fix das Problem?“, sondern „Unterscheidet sich meine Änderung vom run-to-run-Rauschen des Modells?“ Wenn die Antwort nein lautet, ist die Änderung sicher genug, um sie auszuliefern – selbst wenn man nie gesehen hat, wie sie den Fehler behebt. Wir nennen diese Prüfung den Symmetrie-Test, und genau so haben wir eine Prompt-Änderung, die wir nie scheitern sehen konnten, durch unser Gate gebracht.

Alles Weitere stammt aus einer internen Evaluation vom 09.07.2026, durchgeführt mit GLM-5.2 – dem Modell, das wir für unseren Chat-Dienst nutzen. Die Metriken stammen von uns, gemessen an unseren eigenen Fixtures an diesem Datum.

---

Der Fehler, der sich nicht reproduzieren ließ

Innerhalb einer Woche traten zwei Defekte bei der Dokumentengenerierung in deutschen Richtliniendokumenten auf. Beim ersten Fall lieferte der Assistent eine Richtlinie, deren oberste Abschnitte mit 2 bis 6 nummeriert waren – ohne Abschnitt 1. Beim zweiten Fall wurde ein referenziertes Anhangsdokument nicht an das Modell übergeben. Statt dies zu kommunizieren, erfand der Assistent eine verstümmelte „überarbeitete Version“, die der Leser für eine massive Kürzung hielt – und nie erfuhr, dass das Dokument tatsächlich nicht vorhanden war.

Wir formulierten für jeden Fall eine Prompt-Regel:

1. Eine Nummerierungsvorgabe (oberste Abschnitte beginnen bei 1 und sind lückenlos nummeriert).
2. Eine Anti-Erfindungsregel (wenn das referenzierte Dokument fehlt, muss danach gefragt werden – es darf nicht erfunden werden).

Anschließend versuchten wir, die ursprünglichen Fehler mit dem alten Prompt zu reproduzieren, um zu sehen, wie die neuen Regeln sie beheben.

Der Nummerierungsfehler ließ sich nicht reproduzieren. Bei über zwanzig Generierungen mit dem alten Prompt – einschließlich der Produktions-Nachricht, die den Fehler ausgelöst hatte – begann GLM-5.2 jedes Mal bei 1. Der Fehler trat nur im vollständigeren Kontext einer Live-Sitzung auf: mit akkumulierten Benutzererinnerungen, einem langen mehrstufigen Thread und aktiviertem Reasoning-Modus. Unser Schluss: Eine oder mehrere dieser Komponenten ist nötig, um den Fehler auszulösen. Die Offline-Umgebung mit einzelnen Eingaben verfügte nicht über diese Kontextfaktoren – und der Fehler war einfach nicht vorhanden.

Das ist die Falle. Wir hatten einen Fix für einen Fehler, den wir nicht herbeiführen konnten. Wir konnten nicht zeigen, dass der Fix etwas verbessert, weil es im Test keine gebrochene Funktion gab, die sich hätte verbessern lassen. Ein reines „Ausliefern aus Glauben“ ist kein Beleg. Ewig zu warten, weil man den Fehler nicht im Test reproduzieren kann, bringt ebenfalls nichts. Beide Ansätze sind falsch.

---

Umdenken: Die Sprengkraft begrenzen, nicht den Fix jagen

Die Regel ist im System-Prompt für jeden Chat-Durchlauf enthalten – ihre Sprengkraft betrifft also nicht nur „Dokumentnummerierung“. Sie beeinflusst jedes Verhalten des Assistenten: Framework-Q&A, Cross-Framework-Mapping, rechtliche Hinweise, Ablehnungen, mehrsprachige Ausgaben, Tonfall. Eine Prompt-Änderung, die auf einen bestimmten Fehler abzielt, kann unmerklich ein anderes Verhalten beeinträchtigen. Genau das ist das Risiko, das es zu messen gilt – und im Gegensatz zum ursprünglichen Fehler ist es offline messbar.

Also hörten wir auf, zu versuchen, die Wirksamkeit des Fixes zu beweisen. Stattdessen begannen wir, das Risiko der Änderung zu begrenzen. Das Design: eine blinde A/B-Regressionsevaluation über die gesamte Chat-Oberfläche, die den alten Prompt mit dem neuen auf identischen Eingaben vergleicht.

• 42 Fixtures, die Compliance-Q&A, Beratung, Framework-Mapping, Service-Weiterleitungen, Sicherheitsablehnungen, rechtliche Hinweise, mehrsprachige Tests (Deutsch und Französisch), Tonfall, Dokumentengenerierung sowie dynamische Fixtures mit benutzerdefinierten Anweisungen und gepinnten Datei-Prompts abdecken – genau die Abschnitte, die echte Nutzer verwenden.
• 252 Generierungen, die 126 alte-gegen-neue-Paare bilden (drei Samples pro Fixture), alle mit GLM-5.2, 09.07.2026.
• Verblindung. Jedes Paar wird als A/B mit einem zufällig zugewiesenen Label dargestellt. Ein Manifest enthält die wahre Zuordnung (alt/neu) und wird den Prüfern nie gezeigt.
• Zwei Bewertungsschichten.
  • Eine deterministische Schicht prüft Muss- und Muss-nicht-Bedingungen in den gated Fixtures (Weiterleitungen zu Hilfecentern funktionieren, rechtliche Hinweise werden angezeigt, Prompt-Extraktionsversuche werden abgelehnt, Umlaute bleiben erhalten, Mindestlängen werden eingehalten).
  • Eine blinde qualitative Schicht lässt Prüfer:innen jedes Paar ohne Kenntnis der Zuordnung oder der Änderung lesen und bewerten es als äquivalent, A besser oder B besser – inklusive einer Materialitätsmarkierung.

Die deterministische Schicht lieferte ein sauberes Ergebnis: null fehlgeschlagene Antworten in beiden Armen, null asymmetrische Fehler. Nichts, was die Regel hätte schützen sollen, brach auf einer der beiden Seiten.

Die qualitative Schicht ist der spannende Teil.

---

Der Symmetrie-Test

Die verblindeten Prüfer:innen bewerteten 118 von 126 Paaren als äquivalent. Von den verbleibenden acht wiesen sieben einen materiellen Unterschied auf und eines einen geringfügigen, nicht-materiellen Unterschied. Auf den ersten Blick wirken sieben Abweichungen in einer Sicherheitsevaluation wie ein Fehlschlag.

Doch das ist die falsche Lesart – und der Grund dafür ist die Richtung. Ein materieller Unterschied hat ein Vorzeichen: Entweder ist der neue Arm schlechter oder der alte Arm schlechter. Wenn die Prompt-Änderung Regressionen verursacht, häufen sich die materiellen Unterschiede in eine Richtung – hin zu „neu schlechter“. Wenn es sich stattdessen um das run-to-run-Rauschen des Modells handelt, das nichts mit der Änderung zu tun hat, verteilen sich die Unterschiede ungefähr gleichmäßig auf beide Arme. Zählt also nicht nur die Anzahl der materiellen Unterschiede. Entblindet sie und zählt die Richtung.

Genau das haben wir getan. Die sieben Unterschiede teilten sich auf in drei „neu schlechter“ und vier „alt schlechter“. Drei zu vier ist so ausgewogen, wie sieben nur sein können – das Muster, das man vom run-to-run-Rauschen erwartet, nicht von einer gerichteten Regression. Keiner der sieben Unterschiede hatte einen plausiblen Zusammenhang mit der Dokumentnummerierungsregel:

Materieller Unterschied	Schlechterer Arm	Beobachtung
ISO-27001-Klauselidentität	neu	A.8.2 wurde als Risikobewertungskontrolle eingestuft (in den anderen beiden Samples dieses Fixtures korrekt)
PCI-DSS-Segmentierung	neu	Segmentierung wurde als strikt erforderlich übertrieben
PCI-DSS-Segmentierung	alt	erfundene „Anhang A1-Segmentierungsanforderung“
Deutsches Dokument (CJK-Leck)	alt	ein chinesischer Token in deutschem Schluss-Text
Deutsches Dokument (CJK-Leck)	alt	chinesische Zeichen in einer deutschen Zusammenfassung
Präzisionsanweisung (Kürze)	neu	eine „extrem präzise“ benutzerdefinierte Anweisung wurde gebrochen
Präzisionsanweisung (Kürze)	alt	eine „extrem präzise“ benutzerdefinierte Anweisung wurde gebrochen

Das anschaulichste Beispiel sind die CJK-Lecks: In zwei unserer deutschen Fixtures enthielt die Ausgabe einen chinesischen Token (in einem Fall die Zeichen für „Informationssicherheit“) in einem ansonsten deutschen Dokument. Dieses Verhalten trat in beiden Armen in deutschen Durchläufen auf. In diesem Fall landeten beide Instanzen auf dem alten Arm. Wäre die neue Regel die deutsche Ausgabe verschlechtert, hätte man die Lecks auf dem neuen Arm erwartet – doch das war nicht der Fall.

Auch die Fälle mit regulatorischer Präzision zeigen in dieselbe Richtung. In ISO/IEC 27001:2022 (veröffentlicht am 25. Oktober 2022) ist Anhang A, Kontrolle 8.2 „Privileged access rights“; eine Probe des neuen Arms las sie als Risikobewertungskontrolle – korrekt in den anderen beiden Samples dieses Fixtures. Bei PCI DSS v4.0 (PCI Security Standards Council, März 2022) ist Netzwerksegmentierung keine pauschale Anforderung, sondern eine Scope-Reduktionstechnik, die der Council als Möglichkeit beschreibt, Systeme aus dem Geltungsbereich auszunehmen – keine verpflichtende Kontrolle. Eine Probe des neuen Arms übertrieb sie als erforderlich, und eine Probe des alten Arms erfand eine „Anhang A1-Segmentierungsanforderung“. Anhang A1 sind tatsächlich die zusätzlichen Anforderungen für Multi-Tenant-Service-Provider. Das sind die typischen Wackler eines probabilistischen Modells bei harten Domänenfragen – und in diesem Durchlauf verteilten sie sich auf beide Arme, nicht konzentriert auf unsere Änderung.

Unterdessen hielten die Verhaltensweisen, die die Änderung eigentlich anvisierte, in beiden Armen durchgehend stand: Jedes Paar mit fehlendem Anhang forderte das Dokument an, statt es zu erfinden, und jede Nummerierungsprobe erzeugte eine lückenlose Struktur. Über die gesamte Evaluation – die 126 blinden Paare plus die deterministischen Sweeps über dieselbe Oberfläche – fanden wir keinen einzigen Fehler, der auf die Änderung zurückzuführen wäre.

---

Was das beweist – und was nicht

Seid präzise mit dem Anspruch, denn er lässt sich leicht übertreiben. Die Evaluation zeigt keine gerichtete Regression bei dieser Stichprobengröße – nicht, dass der Fix funktioniert. Wir haben nie bewiesen, dass die Nummerierungsregel den Nummerierungsfehler behoben hat, weil der Fehler einen Produktionskontext benötigt, den wir nicht nachstellen konnten. Der Fix wird aus zwei Gründen ausgeliefert:

1. Die forensische Analyse in Produktion, die den Fehler sichtbar macht.
2. Ein Nicht-Regressionssignal, das zeigt, dass die Änderung nichts anderes stört.

Das ist ein schwächerer Anspruch als „Wir haben den Fehler reproduziert und gesehen, wie der Fix ihn behebt“ – aber es ist der stärkste Anspruch, den die Situation zulässt.

Die Grenzen sind real und verdienen eine klare Darstellung:

• Eine grobe gerichtete Verzerrung würde sich bei drei Samples pro Fixture zeigen; eine subtile nicht, da eine 55/45-Verteilung bei dieser Stichprobe verborgen bleibt. Drei Samples pro Fixture über 42 Fixtures hinweg sind geclustert, keine 126 unabhängigen Versuche.
• Wir haben keinen alten-gegen-alt-Kontrollarm durchgeführt, daher ist die Drei-zu-vier-Verteilung unsere beste Schätzung für das Basisrauschen – nicht eine gemessene Baseline.
• Ohne eine vorab festgelegte Äquivalenzmarge ist dies ein Signal für „keine gerichtete Regression“, kein formaler Nichtunterlegenheits-Test.
• Die Fixtures sind single-turn, daher ist eine Interaktion zwischen der neuen Regel und einem langen Produktions-Thread nicht abgedeckt – genau der Kontext, den der ursprüngliche Fehler benötigte.
• Eine symmetrische Verteilung ist ein Beleg dafür, dass die Änderung die Ausgaben nicht in eine Richtung verschiebt – kein Beweis für Unveränderlichkeit.

Was der Test liefert, ist eine konkrete Einschätzung der Sprengkraft, wo die Alternative eine bloße Vermutung gewesen wäre.

---

Die portable Checkliste

Wenn ihr einen Prompt-Fix für einen Produktionsfehler habt, den ihr offline nicht reproduzieren könnt, liefert ihn nicht aus blindem Vertrauen aus – und friert ihn auch nicht ein. Begrenzt stattdessen die Änderung:

• Trennt die beiden Fragen. „Funktioniert der Fix?“ erfordert den Fehler, den ihr nicht nachstellen könnt. „Ist die Änderung sicher?“ nicht. Beantwortet die Frage, die ihr beantworten könnt.

• Bewertet die Sprengkraft ehrlich. Eine Regel in einem geteilten System-Prompt beeinflusst jedes Verhalten – nicht nur das Zielverhalten. Erstellt Fixtures für die gesamte Oberfläche, inklusive der benutzerdefinierten Anweisungen und gepinnten Kontexte, die echte Nutzer:innen verwenden.

• Führt den Test verblindet und gepaart durch. Gleiche Eingaben, alt versus neu, zufällig zugewiesene A/B-Labels und ein Manifest, das die Prüfer:innen nie sehen. Die Verblindung verhindert, dass ihr den Arm favorisiert, von dem ihr hofft, dass er gewinnt.

• Zählt die Richtung, nicht nur die Unterschiede. Entblindet die materiellen Unterschiede und prüft das Vorzeichen.

  • Asymmetrisch hin zu „neu schlechter“ = Regression.
  • Ungefähr gleichmäßig auf beide Arme verteilt = Muster des Modellrauschens, das die Änderung freispricht.

• Fügt eine Wiederholungskontrolle hinzu, wenn die Marge knapp ist. Ein alter-gegen-alt-Arm misst das Basisrauschen direkt – dann vergleicht ihr eure Änderung mit einer Zahl statt mit einer Annahme.

• Behaltet eine deterministische Untergrenze bei. Kombiniert die qualitative Bewertung mit harten Muss- und Muss-nicht-Prüfungen für Verhaltensweisen, die niemals brechen dürfen. Ein „symmetrisches Rauschen“-Verdikt darf keine echte gebrochene Invariante kaschieren.

• Formuliert den Anspruch, den ihr tatsächlich verdient. Sagt „keine messbare Regression“ – nicht „der Fix funktioniert“ – wenn Nicht-Regression alles ist, was ihr beweisen könnt.

Der Instinkt, wenn ein Fehler sich nicht reproduzieren lässt, ist, weiter zu versuchen, ihn nachzustellen, bis er auftritt. Manchmal gelingt das nie – und die Mühe wird in die falsche Frage gesteckt. Ob der Fix ausgeliefert wird, hängt davon ab, ob eure Änderung lauter ist als das Rauschen des Modells. Messt das direkt – und eine Prompt-Änderung, die ihr nie scheitern sehen konntet, wird zu einer, bei der ihr trotzdem sicher sein könnt, dass sie unbedenklich ist.