LangGraph Deep Research: Zitate verifizieren statt nur verlinken

Ein Link hinter einem Satz beweist noch nicht, dass die Quelle den Satz stützt. Er beweist nur, dass eine URL vorhanden ist. Für Abundance habe ich die stärkere Anforderung deshalb in Code übersetzt: Jeder Claim-Beleg-Verweis darf nur auf bereits zugelassene Belege zeigen, jedes prüfende Zitat muss wörtlich in genau diesem Beleg vorkommen, und die semantische Prüfung darf weder neue Quellen noch neue Claim-Beleg-Paare erfinden.

Das Ergebnis ist keine automatische Wahrheitsmaschine. Es ist eine kontrollierte Prüfstrecke zwischen Recherchebericht und Qualitätsmetriken. Dieser Beitrag zeigt die Laufzeitarchitektur. Der getrennte Beitrag zu LLM-Evals mit zwölf Referenzfällen erklärt, wie ich die semantische Komponente vor ihrer Freigabe gemessen habe.

Die drei Fragen hinter einem belastbaren Zitat

Bei einem automatisch erzeugten Recherchebericht müssen drei verschiedene Fragen beantwortet werden:

Diese Trennung ist wichtig. Eine echte URL kann irrelevant sein. Ein korrekt kopierter Satz kann einer Behauptung widersprechen. Und ein Beleg kann zum Thema passen, aber für die behauptete Kausalität oder Aktualität nicht ausreichen.

Der LangGraph setzt die Reihenfolge fest

Der öffentliche Workflow von Abundance besteht aus acht benannten Stufen:

1. scope_inquiry
2. create_plan
3. collect_evidence
4. review_evidence
5. assess_evidence
6. synthesize_report
7. verify_claims
8. publish_report

Der Graph entscheidet, welche Stufe läuft. Das Modell formuliert den Plan und den Bericht, wählt aber keine externen Fähigkeiten aus. Die Belegsuche läuft über vorher konfigurierte, nur lesende Adapter. Diese Entscheidung ist im öffentlichen Architekturentscheid zum deterministischen LangGraph-Workflow festgehalten.

Für die Zitatprüfung ist vor allem die Reihenfolge entscheidend: Erst entsteht ein strukturierter Bericht, danach wird er geprüft, anschließend wird derselbe Bericht veröffentlicht. Das Prüfergebnis fließt als Metrik in die Evaluation ein. Es wird nicht zurück in die Synthese gespeist.

Was im Code gebunden wird

Ein Report enthält strukturierte Claims und zugelassene Belege. Jeder Claim kann über evidence_ids auf einen oder mehrere dieser Belege zeigen. Aus dieser bereits bestehenden Struktur erzeugt die Anwendung die erlaubte Menge von Paaren:

expected_pairs = {
    (claim.id, evidence_id)
    for claim in report.claims
    for evidence_id in claim.evidence_ids
    if evidence_id in evidence
}

Der Verifier darf nur für diese Paare ein Ergebnis liefern. Die Anwendung verwirft ein Ergebnis, wenn das Paar nicht erwartet wird, wenn es doppelt vorkommt oder wenn die Fingerprints nicht zum aktuellen Claim und Beleg passen. Claim-Text und Beleginhalt werden dafür normalisiert und mit SHA-256 gebunden.

Auch ein vom Modell vorgeschlagenes Zitat wird nicht einfach übernommen. bind_exact_quote akzeptiert es nur, wenn die Zeichenfolge wörtlich im zugelassenen Exzerpt vorkommt. Die vollständige deterministische Aggregation steht in application/claim_verification.py; die Provider-Ausgabe wird zusätzlich in adapters/models.py gegen bekannte IDs und exakte Quotes abgesichert.

Damit schützt der Code gegen vier konkrete Fehler:

• eine erfundene Beleg-ID;
• ein Claim-Beleg-Paar, das im Bericht nie existierte;
• ein erfundenes oder paraphrasiertes „wörtliches“ Zitat;
• ein Prüfergebnis für eine ältere Version des Claim- oder Belegtexts.

Vier Verdicts statt „Quelle vorhanden“

Die semantische Komponente klassifiziert jedes erlaubte Paar als supports, contradicts, insufficient oder unverifiable.

• supports: Der zitierte Ausschnitt stützt die konkrete Behauptung.
• contradicts: Der Ausschnitt und die Behauptung können inhaltlich nicht gleichzeitig stimmen.
• insufficient: Der Beleg ist relevant, reicht für die Behauptung aber nicht aus – etwa weil Unabhängigkeit, Kausalität oder aktuelle Daten fehlen.
• unverifiable: Die Behauptung kann mit dem vorhandenen Material grundsätzlich nicht geprüft werden, zum Beispiel eine Prognose für einen Zeitraum, den die Quelle nicht abdeckt.

Wenn ein Claim mehrere Belege zitiert, aggregiert der Code konservativ: Ein Widerspruch hat Vorrang vor Unterstützung, Unterstützung vor „unzureichend“. Fehlt für einen Claim jede gültige Prüfung, bleibt er unverifizierbar. Zusätzlich zählt die Evaluation hoch-konfidente Claims, die keine Unterstützung erhalten haben.

Diese Regeln sind kein Prompt-Trick. Sie stehen in der deterministischen Zusammenfassung und werden durch Komponententests geprüft – einschließlich erfundener Paare, falscher Hashes, erfundener Quotes und doppelter Ergebnisse.

Warum die Prüfung im Schattenmodus läuft

Die Verifikation sitzt zwischen Synthese und Veröffentlichung, darf den Bericht aber nicht umschreiben. Das ist eine bewusste Sicherheitsgrenze.

Würde derselbe neue Prüfer sofort Text löschen, Konfidenzen ändern oder Claims neu formulieren, wäre ein Fehler in dieser Komponente direkt ein Produktfehler. Im Schattenmodus passiert stattdessen Folgendes:

1. Der Bericht wird fertiggestellt und gegen den deterministischen Report-Vertrag geprüft.
2. Der Verifier bewertet nur die vorhandenen Claim-Beleg-Paare.
3. Die Anwendung bindet IDs, Hashes und Quotes erneut im Code.
4. Die Qualitätszusammenfassung wird neben dem unveränderten Bericht veröffentlicht.
5. Ist der Provider nicht verfügbar, wird der Status als unavailable ausgewiesen; der Bericht wird nicht heimlich als verifiziert behandelt.

Der Graph-Code beschreibt diese Stufe ausdrücklich als Messung semantischer Unterstützung „without rewriting the report“. Erst wenn eine Komponente wiederholt ein separates Eval-Gate besteht, kann man überhaupt darüber entscheiden, ob und wie sie später Einfluss auf den Bericht bekommen soll.

Ein konkretes Beispiel

Angenommen, der Claim lautet: „Die Studie hat einen kausalen Behandlungseffekt bewiesen.“ Der zugelassene Beleg sagt dagegen, dass nach Kontrolle von Ausgangsgesundheit und Einkommen kein statistisch unterscheidbarer Zusammenhang blieb und das Beobachtungsdesign keine Kausalität zeigen kann.

Eine reine Linkprüfung sieht nur: Claim hat Beleg-ID – bestanden. Die Abundance-Prüfstrecke verlangt mehr:

• Das Paar aus Claim-ID und Beleg-ID muss im Bericht existieren.
• Das Zitat muss exakt aus dem Beleg stammen.
• Das Verdict muss contradicts lauten.
• Die Fingerprints müssen zur geprüften Textversion passen.

Dieser Fall ist Teil des öffentlich versionierten Claim-Verifikationsdatensatzes. Er prüft nicht, ob das System „wissenschaftlich intelligent“ ist. Er prüft eine enge, aber produktrelevante Verhaltensgrenze.

Was diese Architektur nicht beweist

Die Grenzen sind genauso wichtig wie die Mechanik:

• Ein wörtliches Zitat beweist nicht, dass die Quelle seriös oder die Aussage wahr ist.
• Geprüft wird gegen den zugelassenen Belegtext beziehungsweise das gespeicherte Exzerpt, nicht automatisch gegen jede Passage des Originaldokuments.
• Ein supports-Verdict beweist weder Vollständigkeit der Recherche noch, dass kein stärkerer Gegenbeleg existiert.
• Hashes sichern die Bindung an Textversionen; sie bestätigen keine externe Herkunft.
• Shadow-Metriken verbessern einen konkreten Bericht noch nicht. Sie machen Fehler erst messbar.

Die Architektur löst damit ein klar abgegrenztes Problem: Zwischen „der Bericht enthält Links“ und „jede geprüfte Behauptung ist an einen bekannten Beleg und ein echtes Zitat gebunden“ entsteht eine maschinell kontrollierbare Kette.

Primärquellen und Versionsstand

Die Analyse bezieht sich auf den öffentlichen Abundance-Stand des Commits b4fc4c3, in dem die evaluierte Claim-Verifikation hinzugefügt wurde. Der Tag v1.0.0 vom selben Tag dokumentiert den vorherigen produktionsreifen Kern, enthält diese spätere Verifikationskomponente aber noch nicht. Dadurch bleiben Release-Kern und nachgelieferte Qualitätsstufe sauber unterscheidbar.

Die vollständige Produktarchitektur, die Oberfläche und die übrigen Qualitätsgrenzen sind in der verlinkten Academic-DeepSearch-Case-Study zusammengefasst.

Zur Case StudyAcademic DeepSearch→