Warum ich bei AI-Reviews gezielt versuche, die eigene Lösung zu widerlegen

Ein AI-System kann sehr überzeugend begründen, warum seine Antwort richtig sei. Das ist kein besonders starkes Signal.

Sprachmodelle sind darauf optimiert, plausible Fortsetzungen zu erzeugen. Agentensysteme verstärken diesen Effekt häufig noch: Ein Plan erzeugt Zwischenergebnisse, diese Zwischenergebnisse werden als Evidenz gelesen, und am Ende bestätigt das System seine ursprüngliche Annahme mit Artefakten, die es selbst produziert hat.

In Reviews sehe ich deshalb eine wiederkehrende Schwäche: Teams fragen vor allem: Gibt es Hinweise, dass die Lösung funktioniert? Die wichtigere Frage lautet: Welche Beobachtung würde zeigen, dass unsere Erklärung falsch ist?

Das ist kein akademischer Zusatz. Es ist eine praktische Engineering-Methode für AI Evaluation, Agenten-Design und Release-Entscheidungen.

Plausibilität ist nicht Validität

Nehmen wir einen Support-Agenten, der behauptet, eine Rechnung sei korrekt klassifiziert worden. Er verweist auf Lieferantennamen, Betrag und eine extrahierte Bestellnummer. Das klingt zunächst nachvollziehbar.

Aber was wurde tatsächlich gezeigt?

• Die Felder passen zur gewählten Klasse.
• Das Modell kann eine plausible Begründung formulieren.
• Vielleicht hat ein nachgelagerter Checker dieselbe Einschätzung bestätigt.

Keiner dieser Punkte beweist, dass die Klassifikation robust ist. Der Lieferantenname kann mehrdeutig sein. Die Bestellnummer kann aus einem falschen Dokument stammen. Und wenn Generator und Checker auf ähnlichen Modellen, Prompts oder Kontexten beruhen, teilen sie möglicherweise denselben Fehler.

Das Problem ist Confirmation Bias im Systemdesign: Wir sammeln Belege, die zur Hypothese passen, und übersehen, dass viele dieser Belege nicht unabhängig sind.

Bei klassischen Softwarekomponenten fällt das oft schneller auf. Eine Funktion liefert entweder den erwarteten Rückgabewert oder nicht. Bei AI-Systemen ist die Grenze unschärfer: Antworten sind sprachlich überzeugend, Bewertungen probabilistisch, und Fehler können in einzelnen Schritten versteckt bleiben.

Darum genügt es nicht, positive Beispiele zu sammeln. Ein Review braucht gezielt konstruierte Fälle, an denen die behauptete Fähigkeit scheitern muss, wenn ihre Erklärung nicht stimmt.

Die Hypothese so formulieren, dass sie widerlegbar wird

Der erste Schritt ist erstaunlich oft der schwierigste: eine überprüfbare Aussage statt einer allgemeinen Qualitätsbehauptung formulieren.

Schlecht überprüfbar ist:

Der Agent recherchiert zuverlässig und gibt fundierte Empfehlungen.

Besser ist:

Der Agent empfiehlt nur Produkte, deren technische Mindestanforderungen durch eine zitierte Primärquelle belegt sind, und verweigert eine Empfehlung bei widersprüchlichen oder fehlenden Quellen.

Diese Formulierung erzeugt sofort überprüfbare Konsequenzen:

1. Die Quelle muss tatsächlich die relevante Behauptung stützen.
2. Sekundärquellen dürfen eine fehlende Primärquelle nicht unbemerkt ersetzen.
3. Widersprüche müssen sichtbar gemacht werden.
4. Bei unzureichender Evidenz ist Zurückhaltung das erwartete Verhalten.

Eine gute Review-Frage lautet dann nicht mehr: „Hat der Agent in vielen Fällen hilfreiche Empfehlungen abgegeben?“ Sondern beispielsweise:

Können wir einen Fall erzeugen, in dem eine überzeugende, aber unzureichend belegte Empfehlung durchrutscht?

Das ist die operative Form von Falsifikation.

Vier Bausteine eines falsifikationsbasierten Reviews

Ein belastbarer Review-Prozess kombiniert mehrere Arten von Gegenprüfungen. Keine einzelne Methode reicht aus.

1. Gegenbeispiele konstruieren

Ein Gegenbeispiel ist kein zufälliger Edge Case. Es ist ein Testfall, der eine konkrete Annahme angreift.

Wenn ein RAG-System behauptet, nur auf Basis bereitgestellter Dokumente zu antworten, gehören mindestens diese Fälle in die Evaluation:

• Plausible Falschaussage: Ein Dokument enthält eine absichtlich falsche, aber glaubwürdige Information. Übernimmt das System sie kritiklos oder erkennt es den Konflikt mit anderen Quellen?
• Nahe Verwechslung: Zwei Produkte, Verträge oder APIs haben fast identische Namen, aber unterschiedliche Eigenschaften. Wird die richtige Entität verwendet?
• Unvollständige Evidenz: Die Antwort wäre naheliegend, aber die relevante Stelle fehlt im Kontext. Kennzeichnet das System die Unsicherheit oder ergänzt es aus Weltwissen?
• Widersprüchliche Evidenz: Zwei Dokumente behaupten Verschiedenes. Wird der Widerspruch benannt, priorisiert oder stillschweigend geglättet?
• Irrelevanter Köder: Im Kontext steht eine detaillierte, aber nicht zur Frage passende Information. Lässt sich das System davon ablenken?

Wichtig ist die Verbindung zwischen Testfall und Hypothese. Ein Testfall ist erst dann wertvoll, wenn klar ist, welchen möglichen Fehlermechanismus er sichtbar machen soll.

2. Negativkontrollen einbauen

Negativkontrollen stammen aus der experimentellen Arbeit: Man führt bewusst eine Bedingung ein, unter der kein positiver Effekt auftreten darf. Wenn das System trotzdem ein positives Ergebnis meldet, ist das Messverfahren oder die Pipeline verdächtig.

Für AI-Systeme sind Negativkontrollen besonders nützlich, weil viele Evaluatoren zu großzügig bewerten.

Beispiele:

Behauptete Fähigkeit	Negativkontrolle	Erwartetes Verhalten
Zitiergestützte Beantwortung	Die relevante Quelle wird entfernt	Keine definitive Behauptung; fehlende Evidenz wird benannt
Tool-Nutzung bei aktuellen Daten	Das Tool liefert einen absichtlich leeren oder fehlerhaften Datensatz	Fehler wird erkannt oder Ergebnis wird als unvollständig markiert
Extraktion aus Dokumenten	Ein Feld enthält einen syntaktisch validen, aber semantisch falschen Wert	Kein blindes Übernehmen ohne Abgleich
Policy-Entscheidung	Ein Fall ähnelt erlaubten Beispielen, verletzt aber eine harte Regel	Ablehnung oder Eskalation statt Analogieentscheidung

Eine sehr einfache Negativkontrolle für RAG lautet: Stellen Sie eine Frage, deren Antwort im Index nicht enthalten ist, aber die das Modell wahrscheinlich aus seinem Trainingswissen kennt. Wenn das System dennoch mit hoher Sicherheit antwortet, messen Sie nicht Groundedness, sondern allgemeine Sprachkompetenz.

Das kann für manche Produkte akzeptabel sein. Dann sollte es aber eine bewusste Produktentscheidung sein und kein unbeabsichtigter Effekt.

3. Messung und Kandidat entkoppeln

Ein häufiger Fehler in Agentensystemen ist der Einsatz eines einzelnen Modells in mehreren Rollen: Es plant, führt aus, erklärt sein Ergebnis und bewertet anschließend die eigene Arbeit.

Das ist günstig und schnell. Es ist aber keine unabhängige Prüfung.

Wenn Kandidat und Evaluator dieselben blinden Flecken teilen, entsteht eine Scheinsicherheit. Besonders problematisch wird es bei identischen Modellfamilien, ähnlichen Prompts und gleichem Kontext. Der Evaluator erkennt dann oft dieselben plausiblen, aber falschen Muster als akzeptabel.

Unabhängigkeit ist nicht absolut, sondern abgestuft. Sinnvolle Maßnahmen sind:

• andere Modellfamilie oder zumindest anderes Modell für kritische Bewertungen,
• getrennte Prompts und getrennte Kontextaufbereitung,
• regelbasierte Checks für objektiv prüfbare Eigenschaften,
• Vergleich mit externen Systemen oder einer kuratierten Referenz,
• menschliche Prüfung einer geschichteten Stichprobe,
• Blindbewertung, bei der der Reviewer nicht weiß, welches System die Antwort erzeugt hat.

Ein praktisches Beispiel: Die Aussage „Jede Antwort ist durch Quellen belegt“ sollte nicht nur von einem LLM-Judge bewertet werden. Prüfen Sie zusätzlich maschinell, ob Zitate existieren, auflösbar sind und zur behaupteten Quelle gehören. Für eine Stichprobe prüfen Menschen dann, ob die zitierte Passage die konkrete Aussage tatsächlich trägt.

LLM-as-a-Judge kann dabei sinnvoll sein. Aber ein Judge ist ein Messinstrument, kein Orakel. Er braucht Kalibrierung gegen menschliche Urteile, Fehlerraten nach Kategorie und regelmäßige Gegenproben.

4. Widerlegungsversuche als festen Review-Schritt behandeln

Der entscheidende Unterschied liegt im Prozess, nicht in einer einzelnen Testtechnik.

In einem guten Review hat jede zentrale Behauptung einen zugeordneten Widerlegungsversuch. Das kann als kleine Tabelle im Design-Dokument stehen:

Hypothese	Möglicher Bruch	Test	Abnahmekriterium
Der Agent nutzt nur freigegebene Quellen	Antwort wird aus Vorwissen ergänzt	Frage außerhalb des Korpus	Unsicherheit oder explizite Verweigerung
Der Agent erkennt Konflikte	Eine Quelle widerspricht einer anderen	Konstruierter Dokumentensatz	Konflikt wird genannt und begründet behandelt
Tool-Ergebnisse werden validiert	Tool liefert plausible Fehldaten	Simulierter Tool-Fehler	Keine ungeprüfte Übernahme
Der Evaluator misst Qualität korrekt	Gute und schlechte Antworten werden gleich bewertet	Gelabelte Kontrastpaare	Trennschärfe oberhalb definierter Schwelle

Das wirkt zunächst aufwendiger als ein Satz von Happy-Path-Beispielen. In der Praxis reduziert es spätere Diskussionen erheblich. Man streitet weniger über Eindrücke und kann genauer sagen, welche Annahme gebrochen ist: Retrieval, Tool-Vertrag, Prompt, Entscheidungslogik oder Messung.

Was Agenten besonders anfällig macht

Bei einzelnen Modellantworten ist der Fehler oft sichtbar: Eine Behauptung ist falsch oder unbelegt. Bei Agenten entstehen Fehlerketten.

Ein typisches Muster sieht so aus:

1. Der Planer interpretiert eine Aufgabe falsch.
2. Die Recherche sucht daraufhin in der falschen Richtung.
3. Ein Tool liefert Daten, die innerhalb dieser falschen Interpretation plausibel sind.
4. Der Synthese-Schritt formuliert eine schlüssige Empfehlung.
5. Der Evaluator belohnt Vollständigkeit und Stil statt fachlicher Korrektheit.

Am Ende gibt es mehrere Artefakte, die einander zu bestätigen scheinen. Tatsächlich gehen sie alle auf denselben ersten Fehler zurück.

Deshalb sollten Reviews nicht nur das Endergebnis bewerten. Für kritische Workflows braucht es Traces und prüfbare Zwischenartefakte:

• Welche Annahmen hat der Agent zu Beginn getroffen?
• Welche Quellen und Tool-Antworten haben eine Entscheidung beeinflusst?
• Welche Alternativen wurden verworfen – und warum?
• An welcher Stelle hätte der Agent stoppen oder eskalieren sollen?
• Welche Aussage im Endergebnis hängt von welchem Beleg ab?

Dabei geht es nicht darum, jedes interne Reasoning zu speichern oder zu bewerten. Es geht um beobachtbare Entscheidungsartefakte: Tool-Aufrufe, Quellen, strukturierte Zwischenresultate, Validierungsregeln und Statuswechsel.

Ein pragmatischer Ablauf für Teams

Für die meisten Projekte reicht zunächst ein schlanker Prozess in fünf Schritten.

1. Kritische Produktbehauptungen priorisieren

Nicht jede Eigenschaft braucht denselben Prüfaufwand. Priorisieren Sie nach Schaden bei Fehlern, Häufigkeit und Schwierigkeit der Erkennung.

Bei einem internen Schreibassistenten kann Stilqualität wichtig sein. Bei Vertragsprüfung, Support-Automatisierung, FinOps oder medizinisch nahen Prozessen sind belegte Fakten, Rechteprüfung und Eskalation meist kritischer.

2. Pro Behauptung mindestens einen gezielten Bruchtest definieren

Fragen Sie: „Wie würde ich dieses System austricksen, wenn ich zeigen wollte, dass die Behauptung nur oberflächlich erfüllt ist?“

Das Ergebnis sollte nicht „mehr Testdaten“ sein, sondern ein konkret benannter Angriff auf eine Annahme.

3. Positive und negative Fälle gemeinsam auswerten

Ein Score ohne Fallgruppen ist wenig aussagekräftig. Trennen Sie mindestens:

• Standardfälle,
• Grenzfälle,
• Gegenbeispiele,
• Negativkontrollen,
• bekannte Produktionsfehler.

Ein System mit 90 Prozent Gesamtscore kann unbrauchbar sein, wenn es gerade bei Konfliktfällen oder fehlender Evidenz sicher halluziniert.

4. Fehlerursachen statt nur Fehlerquoten erfassen

„Falsch“ ist als Diagnose zu grob. Sinnvolle Kategorien sind etwa:

• Retrieval lieferte falschen oder unvollständigen Kontext,
• Tool-Ergebnis war fehlerhaft oder wurde falsch interpretiert,
• Regel wurde übergangen,
• Konflikt wurde nicht erkannt,
• Unsicherheit wurde nicht kommuniziert,
• Evaluator hat einen Fehler nicht erkannt.

Diese Einteilung macht aus einer Evaluation ein Engineering-Instrument. Sie zeigt, wo Architektur oder Prozess geändert werden müssen.

5. Widerlegungsfälle versionieren und nach Produktionsvorfällen ergänzen

Jeder relevante Produktionsfehler sollte prüfen lassen, ob ein Test fehlte oder ein vorhandener Test zu schwach war. Gute Evaluationssuiten wachsen nicht nur durch zusätzliche Beispiele. Sie wachsen durch bessere Angriffe auf die eigenen Annahmen.

Was dabei nicht funktioniert

Ein paar verbreitete Muster erzeugen Aktivität, aber wenig Erkenntnis.

„Wir lassen das Modell seine Antwort kritisch prüfen.“
Das kann helfen, ist aber keine unabhängige Validierung. Selbstkritik ist ein zusätzlicher Verarbeitungsschritt, kein Beweis gegen gemeinsame blinde Flecken.

„Wir haben einen LLM-Judge mit einer detaillierten Rubrik.“
Eine gute Rubrik verbessert die Messung. Sie ersetzt aber keine Kalibrierung. Prüfen Sie insbesondere, ob der Judge überzeugend formulierte Fehler systematisch zu positiv bewertet.

„Wir testen mit vielen realistischen Beispielen.“
Realismus ist wertvoll, reicht aber nicht. Produktionsdaten enthalten oft die Verteilung, die bisher funktioniert hat. Gegenbeispiele müssen gezielt die Stellen angreifen, an denen das System zu selbstsicher wird.

„Wir optimieren auf den Benchmark.“
Sobald ein Benchmark zum Ziel wird, verliert er als Messinstrument an Aussagekraft. Halten Sie einen Teil der Prüfungen zurück, rotieren Sie Varianten und ergänzen Sie neue Fälle aus realen Fehlern.

Die eigentliche Qualitätsfrage

Bei AI-Systemen ist die zentrale Frage nicht, ob eine Antwort plausibel wirkt. Auch nicht, ob sie im Durchschnitt eine hohe Bewertungszahl erreicht.

Die zentrale Frage lautet: Unter welchen Bedingungen wird das System falsch liegen, und merken wir das rechtzeitig?

Ein System, das seine Grenzen erkennt, Konflikte sichtbar macht und bei fehlender Evidenz stoppt, ist in vielen Unternehmenskontexten wertvoller als ein System, das auf jede Frage glatt und selbstsicher antwortet.

Deshalb versuche ich in AI-Reviews nicht zuerst, die Lösung zu bestätigen. Ich versuche, sie zu widerlegen.

Wenn sie gezielten Gegenbeispielen, Negativkontrollen und unabhängigen Messungen standhält, ist das Ergebnis deutlich belastbarer als eine Sammlung plausibler Demos. Und wenn sie daran scheitert, ist das kein Misserfolg des Reviews. Es ist der Moment, in dem aus einer überzeugenden Demo ein besseres System werden kann.