Self-healing-Metriken: Wenn eine grüne Bewertung eine echte Regression verbirgt
Bei unserer Multi-Dokument-Tiefenbewertung (2026-06-04, GLM-4.7) erzielte eine Klausel-Zuordnungsmetrik fast perfekte 1,0, während die pro-Dokument-Analyse auf etwa ein Drittel ihrer eigenständigen Tiefe sank. Die offensichtliche Metrik war diejenige, die log.
Die gefährlichste Zahl in einer Bewertung ist die, die grün bleibt, während das Produkt versagt. Wir hatten eine solche. Bei genau dem Lauf, bei dem die pro-Dokument-Ausgabe unseres Modells auf etwa ein Drittel seiner eigenständigen Tiefe sank, erzielte eine Paritätsmetrik fast perfekte 1,0. Die Metrik war weder verrauscht noch falsch kalibriert. Sie maß das Falsche – auf eine Weise, die das Modell erfüllen konnte, ohne die eigentliche Arbeit zu leisten. Wir nennen das eine Self-healing-Metrik, und ihre Entdeckung war in dieser Woche die nützlichste Erkenntnis unserer Evaluierungs-Suite.
Was wir testeten
Eine häufige Aufgabe in unserem Produkt ist die Multi-Dokument-Analyse: Ein Nutzer lädt mehrere Richtliniendokumente gleichzeitig hoch und bittet den Assistenten, jedes davon gegen die Klauseln eines Frameworks zuzuordnen, z. B. die Annex-A-Kontrollen von ISO/IEC 27001:2022. Ein Kunde teilte uns mit, dass die Analyse mehrerer Dokumente in einer einzigen Anfrage dünnere Ergebnisse lieferte als die Analyse jedes Dokuments einzeln. Bevor wir etwas änderten, erstellten wir eine Evaluierung, um diese Lücke zu reproduzieren und zu messen (interner Ticket ISM-549, Baseline-Lauf 2026-06-04).
Das Setup war bewusst produktionstreu. Modell: GLM-4.7, über OpenRouter bereitgestellt, entsprechend dem evaluierten Anfragepfad. Testdaten: sieben synthetische, anonymisierte Richtlinien (keine Kundendaten), gestaltet wie das reale Szenario, das die Beschwerde auslöste. Die einfache Frage der Evaluierung lautete: Erhält jedes Dokument dieselbe analytische Tiefe, wenn sieben gemeinsam analysiert werden, wie wenn jedes einzeln analysiert wird?
Die erste Metrik – und warum sie sich selbst heilte
Der naheliegende Weg, zu bewerten, ob „jedes Dokument analysiert wurde“, besteht darin, die Anzahl der Klausel-Zuordnungszeilen zu zählen. Eine eigenständige Analyse erzeugt eine Tabelle mit einer Zeile pro Klausel, sodass eine gruppenweise Analyse ebenfalls eine solche Tabelle erzeugen sollte. Genau das versuchten wir zunächst.
Die Zeilenparität lag bei etwa 1,0. Bei expliziten nummerierten Klauseln und der Anweisung, „jede Klausel zuzuordnen“, hält GLM-4.7 gewissenhaft eine Tabellenzeile pro Klausel ein, selbst wenn man ihm sieben Dokumente auf einmal übergibt. Nach dieser Metrik war alles in Ordnung. Die Evaluierung war bereit, bestanden zu werden.
Das Produkt war jedoch sichtbar schlechter. Die Zeilen waren vorhanden; die Analyse dahinter fehlte. Bei eigenständiger Analyse enthielt jede Klauselzeile eine Erklärung, die Stärken, die Lücken und eine kurze Zusammenfassung. Bei gruppenweiser Analyse behielt das Modell das Skelett und entfernte die Muskulatur: dieselbe Tabellenform, aber weit weniger der pro-Klausel-Analyse. Die Metrik hatte sich selbst geheilt. Die Ausgabe erfüllte „eine Zeile pro Klausel“, während der Großteil der pro-Klausel-Analyse entfiel – und eine Zeilenzählung kann eine vollständige Analyse nicht von einer hohlen unterscheiden.
Was eine bessere Metrik zeigte
Also hörten wir auf, die Struktur zu bewerten, und begannen, den Inhalt zu messen. Die primäre Metrik wurde zur Inhaltsvolumen-Parität: gruppierte Ausgabzeichen geteilt durch die Summe der eigenständigen Ausgabzeichen, mit einer Bestehensschwelle bei 0,6. Beim Baseline-Lauf 2026-06-04 (GLM-4.7, zwei Samples):
| Maßnahme | Sample 1 | Sample 2 |
|---|---|---|
| Inhaltsvolumen-Parität | 0,34 | 0,35 |
| Eigenständige Zeichen | 48.263 | 47.651 |
| Gruppierte Zeichen | 16.201 | 16.609 |
| Klausel-Zuordnungszeilen-Parität | 1,00 | 0,98 |
| LLM-Richter: Dokumente nicht verdünnt bewertet | 0 von 7 | 0 von 7 |
Beim selben Baseline-Lauf 2026-06-04 erzählte ein tokenbasierter Tiefenproxy dieselbe Geschichte: etwa 2.747 Ausgabetokens für ein einzelnes Dokument gegenüber etwa 595 Tokens pro Dokument bei gruppenweiser Analyse – ein pro-Dokument-Verhältnis von 0,22.
Drei Details sind hier entscheidend. Die Inhaltsvolumen-Parität lag bei 0,34, deutlich unter der Schwelle von 0,6. Ein unabhängiger LLM-Richter, der nur gefragt wurde, die Analyse jedes Dokuments als verdünnt oder nicht zu bewerten, stufte in beiden Samples 0 von 7 Dokumenten als nicht verdünnt ein. Die Zeilenparität, die Metrik, die wir fast hinter verschlossenen Türen eingesetzt hätten, lag im Durchschnitt bei 0,99 über die beiden Samples (0,98 bis 1,00). Die drei inhaltlichen Signale wiesen alle in dieselbe Richtung: Inhaltsvolumen-Parität bei etwa einem Drittel, der Token-Proxy noch niedriger bei 0,22 pro Dokument und der Richter bewertete jedes gruppenweise Dokument als verdünnt. Das einzige Instrument, das widersprach, war die strukturelle Zeilenzählung.
Warum es passiert – und die Grenzen unseres Wissens
Unsere Interpretation der Daten legt nahe, dass GLM-4.7 seinen Aufwand über die Dokumente in einer einzigen Decodierung selbst aufteilt: Wird es aufgefordert, sieben Analysen in einer einzigen Antwort durchzuführen, verteilt es ein etwa festes Budget dünn, statt sieben vollständige Analysen zu erstellen. Wir haben die internen Abläufe des Modells nicht instrumentiert, daher ist dies eine Beschreibung des Verhaltens, das wir gemessen haben, nicht ein nachgewiesener Mechanismus – und es ist spezifisch für dieses Modell und die untersuchte Anfrageform. Zwei Rahmenbedingungen sind dabei entscheidend. Die Regression tritt erst bei Produktionsskalierung auf: Sie zeigt sich bei sieben Dokumenten, nicht bei zwei, sodass ein Smoke-Test mit einer kleinen Eingabe bestanden hätte. Und sie ließ sich nicht reproduzieren, als wir dieselben Testdaten mit einem Frontier-Modell über eine direkte API ausführten. Die Regression trat nur beim exakten Modell und Anfragepfad auf, den wir evaluieren und einsetzen – genau das ist das Argument dafür, den Pfad zu evaluieren, den man tatsächlich nutzt, statt einen bequemen Ersatz zu verwenden.
Warum dies im Compliance-Bereich schlimmer ist als anderswo
In den meisten Produkten ist „dünnere Ausgabe“ ein kosmetisches Problem. In unseren Compliance-Workflows ist es das nicht: Eine Kontroll-Zuordnungstabelle mit allen Zeilen vorhanden, aber ohne Analyse wirkt in einem Screenshot vollständig, liefert einem Prüfer jedoch keine der pro-Klausel-Analysen, die dieser für eine Vertrauensbasis benötigen würde. Genau das macht eine Self-healing-Metrik in unserem Bereich so gefährlich. Sie war nicht nur unpräzise. Sie war grün bei genau dem Ausfallmodus, der in unserem Bereich am wichtigsten ist: ein scheinbar vollständiges Lieferergebnis, bei dem der Inhalt stillschweigend entfernt wurde.
Die folgende Korrektur, die sich aus dieser Erkenntnis ergibt, besteht darin, jedem Dokument einen eigenen vollständigen Tiefen-Durchlauf zu ermöglichen, statt alle sieben in eine einzige Decodierung zu packen – und die Evaluierung schlägt dann mit einem Bestehen zu. Doch die Korrektur ist der einfache Teil. Wir hätten sie nicht umsetzen können, solange unsere Hauptmetrik darauf bestand, dass nichts kaputt war. Die Änderung der Metrik musste zuerst kommen, denn man kann nicht reparieren, was man nicht sieht.
Wie man eine Self-healing-Metrik erkennt
Eine Self-healing-Metrik ist jede Metrik, die ein Modell erfüllen kann, ohne die eigentliche Arbeit zu leisten. Strukturelle Metriken sind dafür am anfälligsten: Zeilenzählungen, Elementzählungen, „gültiges JSON“, „alle erforderlichen Felder vorhanden“, Abschnittsüberschriften. Sie sind günstig zu berechnen und günstig zu manipulieren, oft durch das Modell selbst. Bevor man einer solchen Metrik vertraut, sollte man folgende Prüfungen durchführen:
- Bewerte den Inhalt, nicht nur die Form. Wenn eine Metrik nur die Struktur prüft (Zeilen, Felder, Überschriften), sollte man sie mit einer Metrik kombinieren, die den Inhalt bewertet (Zeichen, Tokens oder eine Richterbewertung der Gründlichkeit). Die Form ist notwendig, aber niemals ausreichend.
- Füge ein unabhängiges Instrument hinzu. Ein günstiger LLM-Richter, der die Qualität bewertet und nicht mit der Hauptmetrik übereinstimmt, ist das Signal, das man sucht. Übereinstimmung ist eine Bestätigung; eine Abweichung bedeutet, dass die strukturelle Metrik sich wahrscheinlich selbst heilt.
- Teste mit Produktionsskalierung. Eine Regression, die erst bei sieben Dokumenten auftritt, wird bei zwei Dokumenten bestehen. Dimensioniere deine Testdaten wie die echte Eingabe, nicht wie einen Unit-Test.
- Teste das Modell und den Pfad, den du einsetzt. Unsere Verdünnung ließ sich nicht mit einem anderen Modell oder einer direkten API reproduzieren. Ein Proxy, der einfacher zu nutzen ist, ist ein Proxy, der den Fehler übersehen kann, der nur in deinem Produktionspfad auftritt.
- Frage dich, wie die günstigste bestandene Ausgabe aussieht. Wenn ein Modell deine Metrik erfüllen kann, während es fast keine der eigentlichen Arbeit leistet, gehe davon aus, dass es dies irgendwann tun wird. Gestalte die Metrik so, dass der günstigste Weg zum Bestehen darin besteht, die Aufgabe tatsächlich auszuführen.
Die Evaluierung hat letztlich ihren Zweck erfüllt, aber erst nachdem wir aufgehört hatten, der schmeichelhaften Zahl zu vertrauen. Wenn eine Metrik grün ist, ist die nützlichere Frage nicht „bestehen wir?“, sondern „könnte das Modell diese Metrik erfüllen, ohne die Arbeit zu leisten?“. Wenn die Antwort ja lautet, heilt sich die Metrik selbst – und sie wird dies weiterhin tun, bis es ein Kunde bemerkt.
Die oben stehenden Zahlen stammen aus unserer internen Multi-Dokument-Tiefenparitäts-Bewertung, Lauf 2026-06-04 mit GLM-4.7 über OpenRouter, und sind zum Zeitpunkt dieses Datums aktuell. Rahmenbedingungen: ISO/IEC 27001:2022, Annex A.