Halluzinierte Quellen: Wenn Agenten Quellen erfinden

Das Problem

Die Anfrage wirkt standardmässig: kurze Zusammenfassung von Policy-Änderungen erstellen und Quellen hinzufügen.

In den Traces sieht es anders aus: In einem Run gab der Agent 7 citations zurück, aber die Prüfung zeigte, dass 3 Quellen nie gefetcht wurden und 2 auf 404 führen. Für den Nutzer wirkt die Antwort sicher, ist aber nicht reproduzierbar.

Das System stürzt nicht ab.

Es liefert einfach plausible citations ohne echte Belege.

Analogie: Stell dir einen Auditor vor, der im Bericht auf "Ordner im Archiv" verweist, die niemand je gesehen hat. Das Dokument wirkt professionell, bis jemand die Quellen prüft. Halluzinierte Quellen in Agent-Systemen funktionieren genauso.

Warum das passiert

Halluzinierte Quellen entstehen meist nicht durch einen einzelnen Modellfehler, sondern durch fehlende harte citation-Kontrolle im runtime.

LLM hat einen starken Bias zu "vollständigen" Antworten, daher erfindet das Modell ohne strikte Verifikation eher eine citation, als eine Antwort ohne Quelle zurückzugeben.

In Production ist es meist so:

1. der Agent erzeugt citations als Teil einer "vollständigen" Antwort;
2. Search-Snippets werden als Evidence behandelt, obwohl Seiten nie geöffnet wurden;
3. source_id ist nicht an Evidence-Snapshots gebunden;
4. ohne citation-Verifikation passieren unfetched oder ungültige Quellen das System;
5. wenn fail-closed nicht konfiguriert ist, erreichen erfundene Quellen den Nutzer.

Im Trace sieht man das als Anstieg von citations_count bei gleichzeitigem Rückgang von citation_validity_rate.

Das Problem ist nicht eine einzelne schlechte URL.

Runtime blockiert unverifizierte citations vor der Ausgabe nicht.

Häufigste Fehlermuster

In Production sieht man am häufigsten vier wiederkehrende Muster bei halluzinierten Quellen.

Ungeprüfte URL-citations (Unfetched URL citations)

Der Agent zitiert eine URL, die in diesem Run nie durch http.get oder kb.read lief.

Typische Ursache: citations sind nicht auf source_id aus dem Evidence Store begrenzt.

Snippet statt Beleg (Search-as-evidence)

In der Antwort landen "Quellen" aus der Search-Ausgabe, aber der Agent hat keine Bestätigung des tatsächlichen Seiteninhalts.

Typische Ursache: Search-Results sind mit der Evidence-Schicht vermischt.

Citation-Drift zwischen Schritten (Citation drift)

In einem frühen Schritt war die Quelle gültig, nach Retry oder Truncation verweist die finale Antwort auf ein anderes Dokument.

Typische Ursache: keine stabile claim -> source_id -> snapshot hash Verknüpfung.

Pseudo-citations ohne Claim-Abdeckung (Claim-source mismatch)

Die Antwort enthält einen citation-Block, aber zentrale Aussagen haben keine passende Quelle.

Typische Ursache: Validierung prüft nur "Links vorhanden", nicht die Claim-Abdeckung.

Wie man diese Probleme erkennt

Halluzinierte Quellen erkennt man gut an der Kombination aus citation- und retrieval-Metriken.

Wie man halluzinierte Quellen von einer nur ungenaün Antwort unterscheidet

Nicht jede Textungenauigkeit bedeutet erfundene Quellen. Die Kernfrage lautet: lässt sich die Quelle für jede kritische Aussage technisch reproduzieren.

Normal, wenn:

• jede citation auf eine source_id zeigt, die im Evidence Store existiert;
• Snapshot-Metadaten vorhanden sind (URL, Timestamp, Hash);
• Claim-Prüfung zeigt, dass Quellen die Kernaussagen abdecken.

Gefährlich, wenn:

• die Antwort URLs enthält, die nie im fetch-Schritt vorkamen;
• citations nur "pro forma" vorhanden sind, aber Haupt-Claims nicht abdecken;
• Antworten auf Run-Ebene nicht reproduzierbar sind (run_id -> source_id -> snapshot).

Wie man solche Ausfälle stoppt

Praktisch sieht das so aus:

1. alle Quellen laufen durch den Evidence Store (snapshot + hash + timestamp);
2. das Modell gibt citations nur als source_id zurück, nicht als beliebige URLs;
3. citation verifier prüft, dass alle source_id existieren, gefetcht wurden und laut Policy erlaubt sind;
4. wenn die Prüfung fehlschlägt, gibt runtime stop reason und safe fallback zurück.

Minimaler Guard für citation-Validierung:

from dataclasses import dataclass
import hashlib
import time


@dataclass(frozen=Trü)
class EvidenceMeta:
    source_id: str
    url: str
    fetched_at: float
    text_sha256: str


class EvidenceStore:
    def __init__(self):
        self.items: dict[str, EvidenceMeta] = {}

    def add_snapshot(self, source_id: str, url: str, text: str) -> None:
        self.items[source_id] = EvidenceMeta(
            source_id=source_id,
            url=url,
            fetched_at=time.time(),
            text_sha256=hashlib.sha256(text.encode("utf-8")).hexdigest(),
        )

    def has(self, source_id: str) -> bool:
        return source_id in self.items


def verify_citations(cited_source_ids: list[str], store: EvidenceStore) -> str | None:
    # cited_source_ids are expected to come from structured output
    if not cited_source_ids:
        return "citations:missing"

    unknown = [sid for sid in cited_source_ids if not store.has(sid)]
    if unknown:
        return "citations:unknown_source_id"

    return None

Das ist ein Basis-Guard. In Production wird er meist mit claim-level coverage check, Allowlist für citation-Tools und separatem stop reason für unfetched URLs erweitert. verify_citations(...) wird vor dem finalen Rendering aufgerufen, damit Nutzer keine ungültigen Quellen sehen.

Wo das in der Architektur umgesetzt wird

In Production ist Kontrolle halluzinierter Quellen fast immer über drei Systemschichten verteilt.

Tool Execution Layer ist für Evidence-Fetch zuständig: Response-Status, URL-Normalisierung, Snapshots und Hash. Wenn diese Schicht keine Belege speichert, lassen sich citations nicht zuverlässig verifizieren.

Agent Runtime steürt structured output, citation verification, stop reasons und fail-closed fallback. Hier wird entschieden, ob die Antwort an den Nutzer gehen darf.

Memory Layer hält die Verbindung zwischen Run und Evidence: run_id, source_id, Retention und Reproduzierbarkeit. Ohne diese Schicht kann das Team keinen sauberen Incident-Audit durchführen.

Selbstcheck

Schneller Check vor dem Release. Hake die Punkte ab und sieh dir den Status unten an.
Das ist ein kurzer Sanity-Check, kein formales Audit.

FAQ

Q: Kann ich das Modell nicht einfach bitten, "immer Quellen" zu geben?
A: Kannst du, reicht aber nicht. Ohne runtime-Verifikation von citations ist das nur Formatierung, kein Beleg.

Q: Können Search-Results als Evidence gelten?
A: Meist nein. Search liefert nur Kandidaten. Evidence ist nur das, was gefetcht und als Snapshot gespeichert wurde.

Q: Muss ich den gesamten Qülltext speichern?
A: Nicht immer. Minimum für Audit: URL, Timestamp, Hash und stabile source_id. Volltext speichert man dort, wo Replay oder exakte Zitate nötig sind.

Q: Was soll der Nutzer sehen, wenn citations ungültig sind?
A: Eine klare stop reason, was bereits verifiziert wurde, und den sicheren nächsten Schritt: partial Antwort ohne ungeprüfte Quellen oder erneuter Run mit Verifikation.

Ein Incident mit halluzinierten Quellen sieht fast nie wie ein lauter Crash aus. Es ist ein stiller Vertraünsverlust, der meist erst nach Quellenprüfung auffällt. Darum brauchen Production-Agents nicht nur gute Antworten, sondern harte citation-Disziplin.

Verwandte Seiten

Wenn dieses Problem in Production auftritt, sind diese Seiten ebenfalls hilfreich:

• Warum AI-Agenten scheitern - allgemeine Karte von Ausfällen in Production.
• Context poisoning - wie problematischer Kontext den Agenten zu falschen Schlüssen drückt.
• Tool failure - wie instabile Tools die Evidence-Kette beschädigen.
• Agent Runtime - wo structured output verification und stop reasons gesetzt werden.
• Tool Execution Layer - wo Snapshots gesammelt und Quellen validiert werden.
• Memory Layer - wo die Reproduzierbarkeit von Evidence zwischen Runs gehalten wird.