# Wer prüft den Prüfer? Adversarische Faktentreue für KI-Texte > Warum naiver KI-Faktencheck versagt und wie ein adversarischer Review wirklich funktioniert — mit kopierbarem Prüf-Prompt, der Ground-Truth-Hierarchie und einem echten Fall, in dem sogar der Prüfer danebenlag. Source: https://www.jpkc.com/db/blog/faktentreue-review/ Ich wollte einen Blog-Artikel schreiben und hatte eine fremde Anleitung als Vorlage — technisch, detailliert, selbstbewusst formuliert. Genau die Sorte Text, der man glaubt. Statt ihr zu glauben, habe ich einen Prüf-Agenten darauf angesetzt, dessen einzige Aufgabe war, die Behauptungen zu **widerlegen**. Ergebnis: fünf handfeste Falschaussagen — erfundene Kommandos, eine nicht existierende Umgebungsvariable, ein Skript, das so nie funktioniert hätte. Und dann der Haken, der aus einer netten Anekdote eine Methode macht: **Der Prüfer selbst lag zweimal daneben.** Er behauptete, zwei Dinge gäbe es nicht — die es sehr wohl gibt. Gefangen habe ich das nur, weil ich sein Urteil gegen eine Quelle gehalten habe, der ich mehr vertraute als ihm. Das ist die Geschichte dieses Artikels, und mehr noch die Methode dahinter: Wie prüft man KI-Output auf Faktentreue, wenn der Prüfer dieselbe Schwäche haben kann wie das Geprüfte? Alles hier ist werkzeug-neutral — das Prüf-Muster funktioniert mit jedem Chatfenster. ## Plausibel ist nicht wahr Große Sprachmodelle erzeugen Text, der *klingt* wie Wissen. Das ist ihr Zweck und ihre Gefahr zugleich: Eine falsche Behauptung kommt mit derselben ruhigen Autorität daher wie eine richtige. Es gibt kein Zögern, kein „ich bin mir unsicher" an der Stelle, wo es zählt. Besonders tückisch wird es bei **schnelllebigen Fakten** — Software-Features, API-Verhalten, Versionsständen, Preisen. Das Modell hat einen Trainingsstand; die Welt ist weitergezogen. Und ausgerechnet dort, wo man es am wenigsten erwartet, irrt es am selbstsichersten: bei den eigenen Werkzeugen. In meiner Vorlage stand ein Kommando `/effort max`, das es schlicht nicht gibt, und eine Konfiguration über eine Umgebungsvariable `CLAUDE_CONFIG`, die frei erfunden war. Beides klang absolut stimmig. Beides hätte ich ungeprüft publiziert — und meine Leser hätten es kopiert. > **Merksatz:** Selbstsicherheit im Ton ist kein Signal für Korrektheit. Bei KI-Text ist sie überhaupt kein Signal — die Formulierung ist gleich souverän, ob die Aussage stimmt oder nicht. ## Warum der naive Faktencheck versagt Der intuitive Reflex ist, das Modell selbst zu fragen: „Stimmt das?" oder „Ist der Artikel korrekt?" Das ist der schlechteste mögliche Prüfauftrag, aus einem einzigen Grund: **Sykophantie**. Modelle sind darauf trainiert, zuzustimmen und zu gefallen. Fragst du „ist das richtig?", suchst du implizit nach Bestätigung — und bekommst sie. Der Prüfer und der Autor teilen dann nicht nur dasselbe Training, sondern auch dieselbe Richtung: bestätigen. Der Ausweg ist ein Wechsel der Beweislast. Nicht „bestätige, dass das stimmt", sondern **„versuche zu beweisen, dass das falsch ist"**. Ein Prüfer, der aktiv nach Widerlegung sucht, findet Fehler, die ein bestätigender Prüfer glatt überliest. Das ist keine KI-Eigenheit, sondern uraltes Handwerk: Ein guter Lektor liest gegen den Text, nicht mit ihm. Ein Sicherheitsteam nennt sich *Red Team*, nicht *Zustimmungs-Team*. ## Das adversarische Prüf-Muster Dieser Perspektivwechsel lässt sich in ein Prompt gießen, das du direkt übernehmen kannst. Der Kern ist, dem Prüfer drei Dinge aufzuzwingen: die Widerlegungs-Haltung, die Zweifels-Regel und die Quellenpflicht. ```text Prüfe die folgenden Behauptungen einzeln. Deine Aufgabe ist NICHT, sie zu bestätigen, sondern sie zu widerlegen. Für jede Behauptung: - Versuche aktiv, sie zu falsifizieren. - Im Zweifel lautet das Urteil FALSCH — nicht "vermutlich richtig". - Stütze dich ausschließlich auf die Primärquelle (offizielle Doku, Spezifikation, Quellcode), nicht auf dein Gedächtnis. Nenne die Quelle. - Gib die korrekte Fassung samt exakter Syntax an. Antworte pro Behauptung in diesem Format: VERDICT: WAHR | FALSCH | UNBELEGBAR BELEG: KORREKT: ``` Jede Zeile trägt Gewicht: - **„widerlegen, nicht bestätigen"** kehrt die Beweislast um und entschärft die Sykophantie. - **„im Zweifel FALSCH"** verhindert das bequeme „vermutlich richtig", das Fehler durchrutschen lässt. Ein UNBELEGBAR ist ein wertvolles Ergebnis — es markiert genau die Stellen, die du selbst nachschlagen musst. - **„Primärquelle, nicht Gedächtnis"** ist die wichtigste Zeile. Sie zwingt den Prüfer, tatsächlich nachzusehen, statt aus demselben Trainingsnebel zu schöpfen, aus dem die Fehler stammen. Ein Prüfer, der nur sein Gedächtnis abfragt, ist keine Verifikation — er ist eine zweite Meinung mit denselben blinden Flecken. - **Das Struktur-Format** zwingt zu einem klaren Urteil pro Behauptung und macht das Ergebnis auf einen Blick auswertbar, statt es in Fließtext zu verstecken. ## Der Prüfer darf nicht der Autor sein Ein Detail, das leicht untergeht: Wer prüft, ist genauso wichtig wie wie. Lässt du denselben Kontext prüfen, der den Text erzeugt hat, ist das Ergebnis kontaminiert — die Unterhaltung ist bereits auf „dieser Text ist gut" eingeschwungen, jede frühere Zustimmung färbt die nächste. Die Verifikation gehört deshalb in einen **frischen, unabhängigen Kontext**. Praktisch heißt das: ein zweites Chatfenster, eine neue Sitzung, gern ein anderes Modell. Wer mit einem agentischen Werkzeug arbeitet, hat es noch einfacher — ein Subagent läuft per Definition in eigenem Kontext und lässt sich gezielt als Prüfer gegen den Autor stellen; mehr dazu in meinem Beitrag zur [Claude-Code-Konfiguration](https://www.jpkc.com/db/blog/claude-code-konfiguration/). Das Prinzip bleibt aber werkzeug-unabhängig: **Trenne die Instanz, die behauptet, von der Instanz, die prüft.** ## Die Ground-Truth-Hierarchie Damit sind wir beim Herzstück — und beim Punkt, an dem mein eigener Review fast gescheitert wäre. „Prüfe gegen die Quelle" ist nur die halbe Regel, denn nicht alle Quellen sind gleich viel wert. Es gibt eine Rangordnung: 1. **Primärquelle** — die offizielle Dokumentation, die Spezifikation, der Quellcode selbst. Was hier steht, gilt. 2. **Eigene, bereits verifizierte Arbeit** — etwas, das du früher schon gegen eine Primärquelle geprüft und für richtig befunden hast. 3. **Modell-Gedächtnis** — die schwächste Stufe. Nützlich als Hinweisgeber, wertlos als Beweis. Diese Hierarchie ist kein akademisches Detail. In meinem Review meldete der Prüf-Agent, eine bestimmte Konfigurationsmöglichkeit „existiere laut Dokumentation nicht". Sein Urteil klang so souverän wie alles andere. Ich habe es trotzdem nicht übernommen — weil ich denselben Sachverhalt in einem *früheren, selbst recherchierten* Artikel bereits belegt hatte. Stufe 2 schlug Stufe 3. Ich habe den Prüfer overruled, und er lag falsch. > **Praxis:** Wenn zwei Quellen sich widersprechen, gewinnt nicht die selbstsicherere, sondern die höherrangige. Ein KI-Urteil aus dem Gedächtnis verliert gegen jede belegte Primärquelle — auch wenn das Urteil überzeugender formuliert ist. ## Wer prüft den Prüfer? Genau hier liegt die eigentliche Lektion. Mein Prüf-Agent lag nicht nur einmal daneben, sondern zweimal — beide Male, weil er aus seinem Gedächtnis antwortete statt aus einer Primärquelle. Er tat also exakt das, wogegen die Methode eigentlich schützen soll. Der Prüfer teilte die Schwäche des Geprüften. Daraus folgt zweierlei. Erstens: **Ein Prüfschritt ist kein Beweis, solange er nicht geerdet ist.** Verifikation ohne Quellenzugriff ist nur Wiederholung mit anderer Stimme. Zweitens: Gegen *zufällige* Fehler hilft Redundanz — mehrere Prüfer, ein Mehrheitsvotum, verschiedene Modelle. Gegen *systematische* Fehler hilft sie nicht: Wenn alle Prüfer denselben veralteten Trainingsstand teilen, stimmen sie einträchtig demselben falschen Fakt zu. Drei Modelle, die alle `CLAUDE_CONFIG` für real halten, ergeben keine Wahrheit, nur ein einstimmiges Missverständnis. Der einzige verlässliche Anker bleibt die Primärquelle. Mehrere Prüfer erhöhen die Trefferquote; sie ersetzen nicht den Blick in die Doku. Am Ende der Kette muss immer ein Mensch oder eine echte Quelle stehen — nicht bloß eine weitere Meinung. ## Wann sich der Aufwand lohnt — und wann nicht Adversarischer Review kostet Zeit und, bei KI-Prüfern, Tokens. Das lohnt sich nicht für jeden Satz. Es lohnt sich dort, wo es **eine überprüfbare Wahrheit gibt und ein Fehler teuer ist**: - Zahlen, Daten, Versionsstände, Preise - API- und Tool-Verhalten, Kommandos, exakte Syntax - Zitate, Namen, Quellenangaben - alles, was Leser kopieren und ausführen Und es nützt schlicht nichts, wo es keine Ground Truth gibt: Geschmacksfragen, Meinungen, Stil, Zukunftsprognosen. Einen adversarischen Prüfer auf „ist diese Formulierung schön?" anzusetzen, produziert nur selbstbewussten Unsinn in beide Richtungen. Und rechne mit **Fehlalarmen**: Ein Prüfer, der auf „im Zweifel FALSCH" getrimmt ist, wird auch korrekte Aussagen anzweifeln. Das ist kein Bug, sondern der Preis der Methode — jedes FALSCH ist ein Prüfauftrag an dich, kein Urteil. ## Nichts davon ist neu Wer genau hinsieht, erkennt in all dem kein KI-Verfahren, sondern altes Handwerk in neuem Gewand. Der gegenlesende Lektor, der Faktencheck in der Redaktion, das Vier-Augen-Prinzip, das Red-Teaming in der Sicherheit — die Idee, dass eine Behauptung erst durch eine unabhängige, skeptische, quellengestützte Prüfung Bestand gewinnt, ist Jahrhunderte alt. KI ändert daran nur die Geschwindigkeit und den Maßstab: Prüfen wird billig genug, um es *immer* zu tun, und nötig genug, um es nie zu vergessen. ## Fazit Faktentreue ist kein Nice-to-have, sondern die Währung, in der sich Glaubwürdigkeit bemisst — bei menschlichen Lesern und mehr denn je bei den KI-Systemen, die deine Inhalte zitieren und weiterverbreiten. Wer Falsches publiziert, wird nicht nur einmal falsch gelesen, sondern falsch *amplifiziert*. Der Aufwand eines adversarischen Reviews ist die Versicherung dagegen. Die Methode ist einfach: Kehr die Beweislast um, prüf in unabhängigem Kontext, und erde jedes Urteil an einer Primärquelle. Und behalt den einen Satz, der mir in dieser Session einen Fehler erspart hat: **Vertraue keinem Prüfer — auch keinem KI-Prüfer —, den du nicht gegen eine echte Quelle geerdet hast.** Wie ich denselben Trenn-Gedanken auf die Werkzeug-Ebene bringe, steht in den Beiträgen zur [Claude-Code-Konfiguration](https://www.jpkc.com/db/blog/claude-code-konfiguration/) und zu [Claude Code im Container](https://www.jpkc.com/db/blog/claude-code-container/).