Startseite / Artikel / Welcher Schritt die Halluzination eingeführt hat: Herkunftsnachweis nach Art der Hadithe

Welcher Schritt die Halluzination eingeführt hat: Herkunftsnachweis nach Art der Hadithe

Warum LLM-Fehler beim ersten Schritt entstehen und wie eine Kette nach dem Vorbild des Isnad, ein Überlieferer-Register und eine Entscheidungsmatrix Multi-Agent-Pipelines Verantwortlichkeit pro Schritt geben.

1051 Wörter

Wer hat das dem Modell gesagt?

Angenommen, fünf Agenten haben eine Behauptung verarbeitet, bevor sie bei Ihnen ankam, und die Behauptung ist falsch. Welcher der fünf hat sie eingeführt? Welcher hat sie in etwas leicht anderes umformuliert? Wer ist verantwortlich? In den meisten Produktions-Pipelines lautet die ehrliche Antwort: Niemand weiß es.

Ein LLM liefert Ihnen eine Antwort, und die Frage ist, woher sie stammt. Nicht aus welchem Dokument, sondern aus welcher Transformation. Jede Modellausgabe ist eine Behauptung ohne Herkunft. Es gibt Logs, aber ein Log sagt, was passiert ist, nicht ob die Übermittlung Vertrauen verdient. Multi-Agent-Ketten verschlimmern das. Eine Behauptung, die fünf Übergaben überlebt, ist nicht verlässlicher, nur besser versteckt.

Wo Fehler wirklich entstehen

Üblicherweise nimmt man an, dass sich Halluzinationen mit der Tiefe aufschaukeln: längere Kette, mehr Drift. Ein Leaderboard, das diese Idee testen sollte (Issue #71 im Projekt-Repo, alles committet), fand etwas anderes. Bei bekannten Fakten lag die Halluzinationsrate bei 0%. Bei Fakten nach dem Trainingsstichtag des Modells lag sie zwischen 44% und 56%. Und sie blieb konstant, als die Kette tiefer wurde.

Der Fehler wächst also nicht unterwegs. Er entsteht bei Schritt 1, im Moment der Generierung aus dem Gedächtnis, wenn das Modell nach etwas greift, das es nicht hat. Danach kopiert die Staffel ihn getreu und fügt nichts hinzu. Das verschiebt, wohin die Instrumentierung gehört. Ein Drift-Detektor ist nicht das, was Sie brauchen. Sie müssen wissen, bei welchem Schritt die Behauptung entstand und ob dieser Überlieferer überhaupt befugt war, sie aufzustellen.

Eine Methode, die 1.400 Jahre alt ist

Islamische Gelehrte standen vor vierzehn Jahrhunderten vor demselben Problem mit menschlichen Behauptungen und bauten darum eine ganze Disziplin auf, die Hadithkritik. Sie besteht aus drei Schleifen, die bewusst getrennt bleiben:

  • Isnad ist die Kette: wer den Bericht an wen weitergab, in welcher Reihenfolge.
  • Ridschal betrifft die Überlieferer: ein Register, das die Zuverlässigkeit jedes Übermittlers nach Rolle bewertet, wobei die Bewertung mit dem Alter verfällt.
  • Matn ist der Inhalt: Widerspricht die Behauptung dem, was bereits feststeht?

Die Trennung ist wichtig, weil eine makellose Kette eine falsche Behauptung tragen kann und eine wahre Behauptung über eine gebrochene Kette ankommen kann. Das System presst das nicht in eine einzige Zahl, weil beides unterschiedliche Fragen beantwortet.

Die Bibliothek ISNAD bildet jede Schleife auf LLM-Infrastruktur ab:

  • Kette (Isnad): jede Transformation der Reihe nach, mit Hashes von Ein- und Ausgabe.
  • Register (Ridschal): Zuverlässigkeit der Überlieferer pro Rolle, nach Aktualität abgewertet.
  • Bewertung: Die Qualität der Kette richtet sich nach dem schwächsten Überlieferer.
  • Inhaltskritik (Matn): Behauptung gegen Beleg, so gebaut, dass sie an Ihren bestehenden Kritiker andockt.
  • Entscheidungsmatrix: Ergebnis ist ausliefern, mit Vorbehalt ausliefern, prüfen lassen oder in Quarantäne stellen.
  • Bestätigung: unabhängige Zeugen (Tawatur) und Erkennung von Fehlern, die sie gemeinsam haben.
  • Verankerung: auf die Kette beschränkt, also auf das, was diese Kette tatsächlich abgerufen hat.
  • Content-madar: erzeugt Fingerabdrücke von Fehlern, die sich scheinbar unabhängige Quellen teilen.

Jede Behauptung läuft durch eine 4×3-Tabelle aus Kettenqualität und Inhaltsurteil und verlässt sie mit genau einer Aktion: ausliefern, mit Vorbehalt ausliefern, zur Prüfung schicken oder in Quarantäne stellen. Das ist eine Aktion, kein Score, und eine Aktion lässt sich in eine Pipeline einbauen.

Sie wird als Bibliothek, REST-API und CLI ausgeliefert. Sie arbeitet neben LangChain, LlamaIndex, CrewAI, LangGraph und OpenTelemetry, statt sie zu ersetzen, sodass die Einführung keine Neuschreibung des Stacks bedeutet.

Was sie nicht leistet

Die meisten Zuverlässigkeitswerkzeuge überspringen diesen Teil, deshalb sei er klar benannt.

  • Sie bewertet das Wer, nicht das Ob. Eine Sahih-Kette sagt, dass die Übermittlung gut bezeugt ist. Sie sagt nie, dass die Behauptung wahr ist, und ISNAD tut auch nicht so.
  • Die Bewertungen sind ordinal: Sahih steht über Hasan, dann folgen Da'if und Maudu'. Es gibt keine "92,3% Konfidenz", weil keine ehrliche Methode eine solche Zahl liefert. Zwei Nachkommastellen bei einem Vertrauenswert sind Dekoration.
  • Sie lässt sich mit Kritikern kombinieren. ISNAD ist die Übermittlungsschicht und bewusst nicht der Richter über den Inhalt.
  • Alles ist gemessen, nicht behauptet. Jede Aussage im README führt zu einem committeten, reproduzierbaren Ergebnis, mit Negativkontrollen daneben.
  • Grenzen kommen zuerst. Der Kaltstart ist pro Rolle schlechter, Integrität gilt nur innerhalb einer Domäne, Unabhängigkeit lässt sich abwerten, aber nie beweisen, und der Kritiker bestimmt die Obergrenze der Abdeckung. Das steht im README gleich oben und nicht versteckt in einer Fußnote.

Was die Messungen zeigen

Fingerabdrücke per Content-madar senkten die Falsch-Positiv-Rate von 0,750 auf 0,375, bei einem Token-Recall von 1,0 und einer Erkennung knapper Treffer von 4 aus 4. In der Auswertung der Kettenverankerung blieb die Trennung zwischen belegten und unbelegten Behauptungen unter einem NLI-Kritiker bestehen, und ein Schutz gegen Degeneration verhindert, dass der Kritiker die Metrik austrickst.

Das unbequemste Ergebnis: Der Kritiker ist die Obergrenze. Ein stärkerer modellübergreifender Aufbau, bei dem deepseek-v4-pro deepseek-flash bewertete und die Belege direkt im Kontext hatte, übersah trotzdem bis zu 2 von 4 bis 5 Halluzinationen. Ein Kritiker ersetzt keine Urteilsfindung, und die ISNAD-Dokumentation sagt das offen, statt zu hoffen, dass Sie es nicht prüfen.

Für wen sie sich lohnt

  • Teams, die Multi-Agent-Pipelines ausliefern und Verantwortlichkeit pro Schritt statt eines Stacktraces wollen.
  • Medizin, Recht und Finanzen, überall dort, wo ein Prüfpfad mehr zählt als eine Logdatei.
  • Forschende, die einen präregistrierten, reproduzierbaren Weg suchen, Halluzination und Herkunft zu messen.
  • Alle, die "vertrauen Sie uns, das passt schon" satthaben und lieber lesen würden: "Hier ist, wer dafür gebürgt hat, und was diese Bürgschaft wert ist."

Installation:

pip install isnad          # Python ≥ 3.11, Apache-2.0
npm i isnad                # JS verifier — verifies audit records, grading stays in Python

Das Repo liegt unter github.com/alizahidraja/isnad. Es enthält eine Demo mit einem einzigen Befehl, das vollständige Benchmark-Gerüst und das ARCHITECTURE-Dokument, das die Begründung, die Grenzen und die noch offenen Probleme darlegt. Die Unabhängigkeit der Ketten bleibt das größte davon.

ISNAD bewertet die Übermittlung, nicht die Wahrheit. So funktionierte Verlässlichkeit, bevor es Maschinen gab, und jetzt wird es auf sie angewandt.