Startseite / Artikel / Eine Architektur gegen die Verstärkung von Halluzinationen in Agentengraphen

LLM Multi-agent systems RAG LangGraph AI reliability Prompt engineering

Eine Architektur gegen die Verstärkung von Halluzinationen in Agentengraphen

Erfahren Sie, wie man eine Steuerungsplattform-Architektur mit typisierten Werkzeugen, Zitatenverwaltungssystemen und Schematautomaten entwirft, die verhindert, dass Halluzinationen mehrerer Agenten-LLMs sich gegenseitig verstärken.

2832 Wörter

Der instinktive Ansatz besteht darin, einfach einen weiteren Kritiker-Agent hinzuzufügen. Genau so wird die Täuschung eher verstärkt anstatt behoben.

Falls Sie bereits einen Chatbot mit einem einzigen Agenten im Produktivbetrieb eingesetzt haben, erkennen Sie das Problem bereits: Das Modell antwortet auf etwas, was in den heruntergeladenen Dokumenten nie erwähnt wurde, und liefert diese Fälschung in demselben selbstsicheren Tonfall wie bei einer echten Zitierung.

In einem mehragentigen Pipeline-System wird derselbe Fehler verstärkt, denn es geht nicht mehr um die Ausgabe eines einzelnen Modells – es handelt sich vielmehr um ein ganzes Netzwerk solcher Modelle. Ein Planer entwickelt ein Teilziel. Ein Forscher erfindet eine Quelle, um dieses Ziel zu unterstützen. Ein Analyst zieht eine Zahl aus dieser erfundenen Quelle ab. Ein Autor wandelt diese Zahl in eine Empfehlung um. Anschließend führt ein Agent, der Tools aufruft, diese Empfehlung in Ihrem Abrechnungssystem aus. Bei jeder Übergabe besteht die Möglichkeit, dass eine Schätzung als etwas ausgegeben wird, das wie eine überprüfte Tatsache aussieht.

Teams, die LangGraph-ähnliche Mehr-Agenten-Systeme für Anwendungsfallbereiche in den Bereichen Recht, Finanzen und Betrieb entwickeln, stoßen auf ein wiederkehrendes Muster. Das Problem liegt nicht daran, dass das zugrundeliegende Modell unintelligent ist. Vielmehr fehlt im Workflow selbst ein epistemischer Vertrag. Nichts im Graphen zwingt einen Agenten dazu, mitzuteilen, wo eine Behauptung ihren Ursprung hat, welche Beweise sie widerlegen könnten oder was geschehen sollte, wenn solche Beweise einfach nicht vorhanden sind. Daher tut das System das, was Sprachmodelle immer tun, wenn es Lücken gibt: Es erzeugt etwas Plausibles, um diese zu füllen.

Was folgt, ist die Architektur, die es wert ist, verwendet zu werden, wenn die Ausgabe Geld bewegen, eine rechtliche Einreichung beeinflussen oder im Posteingang eines Kunden landen kann. Es handelt sich dabei nicht um einen schnellen Leitfaden, und wenn Sie auf eine einzige Paketinstallation hoffen, die Ihre Agenten vertrauenswürdig macht, werden Sie sie hier nicht finden.

Das sich verschärfende Problem, für das niemand Budget einplant

Jeder einzelne Aufruf einer großen Sprachmodelle weist eine gewisse Grundrate an unbegründeten Behauptungen auf – nennen wir sie p. Wenn man fünf Agentenschritte hintereinander verknüpft und jeder Schritt das Potenzial hat, unbegründete Behauptungen einzuführen oder zu verstärken, beträgt die tatsächliche Fehlerrate nicht mehr p. Sie wird zum Produkt von bedingten Wahrscheinlichkeiten, wobei ein weiteres Problem, das spezifisch für mehrere Agenten vorkommt, hinzukommt: die Übertragung der Autorität zwischen den Agenten.

Agent B betrachtet die Ausgabe von Agent A einfach als erwiesene Tatsache, nur weil sie als strukturiertes JSON-Objekt mit einem Label wie research_findings übermittelt wird. Das Schema wird validiert, die Feldtypen sind korrekt – doch der tatsächliche Inhalt ist erfunden. Die Bestätigung des Schemas bedeutet noch nicht, dass die Aussage wahr ist, dennoch kümmern sich die meisten Teams nur um die Einhaltung des Schemas.

Drei spezifische Fehlermuster treten in realen Implementierungen häufiger auf, als in den meisten Beschreibungen angenommen wird:

Künstlich erzeugte Tool-Aufrufe. Das Modell gibt eine funktionsbezogene Aufrufstruktur aus, die syntaktisch korrekt erscheint – etwa search_matters(client_id=…) –, zielt aber auf ein nicht existierendes Tool ab oder verwendet Argumente, die fehlschlagen würden, wenn das Schema des Tools tatsächlich eingehalten würde. Orchestrierungsschichten, die unerkannt nicht übereinstimmende Datentypen zulassen oder das Modell dazu bringen, mit leicht geänderten Argumenten erneut zu versuchen, trainieren das System effektiv daran, Datenlücken zu übergehen anstatt sie offenzulegen.
Aufbereitung von Informationen über verschiedene Agenten. Der Forscher formuliert vage mit „laut der Dokumentation“. Der Analyst weiter unten öffnet diese Datei tatsächlich nie. Der Verfasser zitiert anschließend den Analysten als Quelle. Wenn schließlich ein Mensch die endgültige Zusammenfassung prüft, ist die ursprüngliche Einschränkung vollständig verschwunden. Genau so verwandelt sich ein vager Hinweis in eine zuverlässig behauptete, abrechenbare Tatsache.

Prüfagenten im Theater-Modell. Teams reagieren oft, indem sie einen „Kritiker“ oder „Prüfagenten“ hinzufügen, dessen einzige Aufgabe darin besteht, Halluzinationen aufzudecken. Das Problem ist, dass dieser Prüfagent selbst ein LLM ist, das auf demselben Kontext basiert – häufig aus derselben Modellfamilie – und durch die Gestaltung der Anfrage implizit dafür belohnt wird, zustimmend und hilfsbereit zu sein. Ein auf Hilfsbereitschaft optimierter Prüfagent neigt dazu, Dinge zu bestätigen anstatt in Frage zu stellen. Ein wirklich unabhängiger Prüfagent benötigt eine separate Informationsquelle, eine eigene Zielfunktion sowie einen Ablehnungsweg, der weniger kostspielig ist als einfach zuzustimmen. Nur sehr wenige Architekturen bieten das tatsächlich.

Retrieval-augmented Generation rettet einen nicht davor. Retrieval liefert lediglich einen Hintergrundwissen-Input. Wenn der Planungsagent niemals die richtige Abfrage formuliert hat oder wenn der Aufteilungsprozess den einzigen Absatz, der die Behauptung widerlegt hätte, in zwei separate Embeddings aufgeteilt hat, wird der Forschungsagent dennoch etwas finden, das flüssig klingt und thematisch nahe liegt. Thematische Nähe zum richtigen Antwort ist nicht dasselbe wie logische Folgerung daraus.

Was „grounded“ bedeuten muss – sonst bedeutet es nichts

„Grounded“ sollte kein vager Beschreibungsbegriff für Stimmung oder Ton sein. Eine Behauptung in einem Multi-Agenten-System gilt nur dann als grounded, wenn alle folgenden Bedingungen erfüllt sind:

Die Aussage weist einen expliziten Typ auf. Sie wird als Assertion, Conjecture, Quote oder ActionIntent gekennzeichnet. Die Vermischung dieser Kategorien in ein einziges, untypisiertes Textfeld führt genau dazu, dass Audit-Trail-Informationen unvollständig werden.
Jede Assertion verweist auf ein Herkunftsdatum – einen abgerufenen Abschnitt, die Ausgabe eines Tools oder eine direkt von einem Menschen bereitgestellte Tatsache. Dieser Verweis ist ein Inhaltshash, niemals eine von dem Modell selbst erfundene URL.
Eine deterministische, nicht auf LLMs basierende Überprüfung hat bestätigt, dass das referenzierte Herkunftsdatum tatsächlich irgendwo im Protokoll des Laufs existiert. Die Existenz zu bestätigen ist kostengünstig; die Folgerung daraus hingegen nicht. Beide Überprüfungen sind notwendig – und in dieser genauen Reihenfolge.

Wenn eine Überprüfung fehlschlägt, zögert das System oder bittet um Klarstellung. Es überschreibt die Anfrage nicht heimlich, bis der Formulierungstext überzeugend genug erscheint, um zu bestehen.

Eine Architektur, die nicht in der Lage ist, eine Antwort abzulehnen, kann auch nicht zuverlässig wahrhaftig sein. Die Erstellung einer Antwort ist standardmäßig der Weg des geringsten Widerstands; das Zögern muss als expliziter, erstklassiger Zustand im Graphen implementiert werden – und es muss günstiger sein als ein einfacher Neversuch mit einer anderen Anfrage.

Das ist die gesamte Grundidee. Alles Weitere sind die ingenieurtechnischen Lösungen, die notwendig sind, damit diese vier Regeln gelten, sobald LangGraph, echte Aufrufe von Tools sowie ein Produktmanager eingeführt werden, der darauf besteht, dass die Demo stets eine Antwort liefert.

Das Steuerungsflugzeug, nicht die Anfrage

Betrachten Sie Ihre Agenten als unzuverlässigen Laufzeitumfeld und umgeben Sie sie mit einer Steuerungsplattform. Diese Plattform besteht aus sechs Komponenten. Wenn man eine davon weglässt, verschlechtern sich die übrigen stillschweigend.

1. Typisierte Tool-Verbindungsstelle

Jedes Tool erhält ein versioniertes JSON Schema für Eingabe und Ausgabe, das in einem Register gespeichert ist, das vom Modell nicht geändert werden darf. Das Modell kann einen Aufruf vorschlagen, doch ein deterministischer Validator muss ihn *vor* jeglicher Auswirkung entweder akzeptieren oder ablehnen. Es gibt keine Typumwandlung und auch keine „gut genug“-Kopplung zwischen einem Enum-Wert und dem, was das Modell erzeugt hat. Ist ein Aufruf ungültig, wird dieser als strukturierte Fehlermeldung an den Planer zurückgesendet – niemals als mündliche Rüge.

Das erscheint wie eine offensichtliche Anforderung, doch genau dies wird in den meisten CrewAI- oder AutoGen-Demos weggelassen, weil dort niemals ein Tool zum Einsatz kommt, das tatsächlich in ein dauerhaftes Protokoll schreibt.

Für jedes Tool mit unumkehrbaren Folgen – das Versenden von Inhalten, das Schreiben einer Datei, das Bereitstellen oder Aktualisieren eines Datensystems – sollte der Bus eine doppelte Kontrolle erfordern: einen bereits überprüften ClaimSet sowie entweder eine Genehmigung durch einen Menschen oder eine ausdrückliche Berechtigungsregel. Bei dieser Konstruktion erhält das Agentenprogramm niemals einen direkten Zugriff auf diese Tools.

2. Nur-einfügen-fähiges Zitierregister

Jedes Abrufergebnis, jeder Tool-Ausgabeinhalt sowie jede von einem Menschen bereitgestellte Information wird in einen nur-einfügen-fähigen Speicher geschrieben, der nach run_id und einem Inhaltshash indiziert ist. Agenten dürfen keine Quelle einfach in ihrem eigenen Notizbuch „speichern“ – stattdessen müssen sie Register-IDs zitieren.

Falls ein Schriftstelleragent einen Satz ohne angehängte Ledger-ID erzeugt, handelt es sich dabei überhaupt nicht um eine Aussage. Es handelt sich um unbeschrifteten Text, der auf keinen Fall durch ein Schema-Tor gelassen werden sollte. Dies ist vermutlich die wirksamste Lösung, die man auf ein bestehendes Agenten-Netzwerk anwenden kann: Man muss verhindern, dass freie Prosa in Form von Daten das System verlässt.

Auch Hashing ist hier wichtig. Ein Modell kann auf doc:matter-4421#p3 verweisen und dennoch falsch zitieren, was tatsächlich auf Seite 3 steht. Das Ledger muss den exakten Textabschnitt speichern – oder zumindest einen Verweis auf einen unveränderlichen Objektspeicher – damit der Prüfer gegen diese genauen Bytes prüft und nicht gegen das, was sich das Modell daran erinnert.

3. Schema-Tor (nicht LLM)

Bevor irgendein Artefakt an das nächste Agenten-Element weitergeleitet wird – ein Forschungssummary, eine berechnete Zahl, eine vorgeschlagene Aktion – muss es einer Validierung gegen ein Schema unterzogen werden, das Folgendes umfasst:

eine claims[]-Array, wobei jedes Element über type, text, ledger_ids[] sowie einen confidence-Wert verfügt, der später kalibriert wird anstatt einfach vom Modell als „hoch“ angegeben zu werden
eine open_questions[]-Array, die vom Planer entweder gelöst oder ausdrücklich weitergeleitet werden muss
eine action_intents[]-Array, das auf ein benanntes Tool verweist und niemals einen vagen Satz wie „Wir sollten wohl...“ enthält

Dieser Mechanismus muss aus gewöhnlichem Code bestehen – Pydantic, JSON Schema, eine CEL- oder Rego-Policy, ganz nach Wahl. Es darf sich nicht um ein LLM handeln. Wenn man hier ein Sprachmodell verwendet, hat man im Grunde das „Critic-Agent-Theater“ nur auf einer niedrigeren Ebene wieder eingeführt.

4. Anspruch-Prüfer mit anderer Informationsstruktur

Hier liegt die eigentliche Kostenquelle. Nehmen Sie jede Assertion und teilen Sie sie in ihre kleinsten, überprüfbaren Bestandteile auf, sodass ein einzelner Bestandteil einen Subjekt, eine Beziehung oder Eigenschaft sowie einen Zeitpunkt bezeichnet. Für jeden dieser Bestandteile holen Sie die unterstützenden Beweise nur aus dem Protokoll ab – niemals aus einer Live-Websuche und auch nicht aus den eigenen Parametern des Modells.

Führen Sie anschließend eine Implikationsprüfung durch: Unterstützt der abgerufte Textabschnitt die Aussage, widerspricht er ihr oder sagt er überhaupt nichts dazu? Dies können Sie mit einem kleinen NLI-Modell, einem auf das Kopieren aus dem Textabschnitt beschränkten Dekoder oder einem menschlichen Prüfer umsetzen. Was Sie nicht tun können, ist diese Aufgabe demselben großen Chat-Modell zu übertragen, desselben Systemprompt zu verwenden und es zu fragen, ob die Behauptung „richtig erscheint“.

Wenn eine Anfrage abgelehnt wird, passt niemand heimlich die Formulierung an, damit sie beim nächsten Versuch durchgeht. Es wird stattdessen Unsupported{proposition, missing_evidence} angezeigt, und die Aufgabe des Planers besteht darin, weitere Beweise zu finden – nicht das Problem umzudichten.

Auch dieser Schritt erkennt feinere Fehler: Das Ersetzen einer vagen, nicht überprüfbaren Aussage durch eine, die nur streng klingt. Zu behaupten, eine Rechnung sei überhöht, ist an sich keine prüfbare Anmerkung. Nur wenn konkrete Zahlen genannt werden – der Postenname, die vertraglich festgelegte Obergrenze, der Betrag darüber sowie die Buchungseinträge, die all das belegen – wird daraus etwas, was ein Prüfer tatsächlich bestätigen oder ablehnen kann. Ein Schema, das die erste, vage Form akzeptiert, wird letztendlich den Tonfall statt der Fakten validieren.

5. Nutzen Sie Evaluierungswerkzeuge für konkrete Daten, nicht für subjektive Eindrücke

Man benötigt eine gefrorene Benchmark-Gruppe: Eingaben, Ledger-Snapshots, die erwarteten Behauptungen sowie die erwarteten Enthaltungen. Jede Änderung am Graphen – eine Anpassung der Eingabe, ein Wechsel des Modells, ein anderer Chunker, ein neues Tool – wird anhand folgender Kriterien bewertet:

Treue: Welcher Anteil der erzeugten Behauptungen wird tatsächlich vom Ledger gedeckt?
Absicherung: Welcher Anteil der erwarteten Behauptungen wird tatsächlich vom Graphen erzeugt, da auch Schweigen selbst ein Versagen sein kann?
Präzision bei Enthaltungen: Wenn das System sich weigerte zu antworten, war diese Weigerung tatsächlich gerechtfertigt?
Hygiene der Nebenwirkungen: Keine irreversible Tool-Aufrufe werden ohne gültige Genehmigung ausgeführt.

Falls ein Rückgang der Treue um zwei Punkte eine Bereitstellung nicht verhindern kann, hat man kein Kontrollflächen-System – man hat nur ein Dashboard, das beruhigend aussieht.

Egal was Sie tun – erstellen Sie diese Bewertungsmenge auf keinen Fall aus den eigenen früheren Ausgaben des Modells. Dadurch wird lediglich das aktuelle Halluzinationsmuster als wahr angesehen. Die Gold-Referenzen sollten aus den zugrunde liegenden Quelldokumenten sowie dem tatsächlichen System stammen, wobei das Graph dann unabhängig davon überprüft werden sollte. Auf diese Weise ist die Erstellung zwar langsamer, doch es handelt sich dabei um die einzige Version der Metrik, die tatsächlich eine Bedeutung hat.

6. HITL am unumkehrbaren Punkt

Ein menschlicher Prüfer dient nicht dazu, die Agenten intelligenter zu machen. Seine Aufgabe besteht darin, genau dort zu sein, wo das System gerade einen E-Mail versenden, ein Dokument speichern oder in ein Register schreiben will. Die Überprüfungsinterface sollte die jeweiligen Behauptungen, die relevanten Buchungsbereiche sowie den ausstehenden Tool-Aufruf anzeigen – nicht eine endlose Liste an Chatverläufen. Wenn jemand erst nachvollziehen muss, warum ein Agent einer bestimmten Tatsache Glauben schenkte, dann hat das Design bereits versagt.

Bei Hochdurchsatzprozessen – die Prüfung von Rechnungen ist ein gutes Beispiel – sollte die menschliche Überprüfung stichprobenartig erfolgen und nur bei Ausnahmen ausgelöst werden, anstatt auf alles angewandt zu werden. Lassen Sie das System automatisch zustimmen, wenn alle Angaben vollständig abgedeckt sind und die finanziellen Abweichungen innerhalb eines akzeptablen Bereichs liegen. Alles andere wird markiert, und nur die konkreten nicht unterstützten Ansprüche werden angezeigt, nicht das gesamte Dokument.

Ein Überblick über den Vertrag, nicht die Implementierung

So sollte das Objekt aussehen, das zwischen den Agenten übertragen wird. Die Orchestrierungslogik, der NLI-Verifizierungsstack, die Speicherschicht des Buchhaltungssystems sowie der Komponente, die Genehmigungen erteilt, werden absichtlich weggelassen – sie sind implementierungsbezogen und gehören in den Produktionscode, nicht in einen Blogbeitrag.

{
  "run_id": "run_7f3c",
  "from_agent": "analyst",
  "claims": [
    {
      "id": "c_19",
      "type": "Assertion",
      "text": "Line item 14 exceeds the engagement-letter hourly cap.",
      "propositions": [
        {
          "id": "p_19a",
          "pred": "exceeds_cap",
          "args": {"line_id": "14", "cap_source": "engagement_letter"},
          "ledger_ids": ["led_aa12", "led_bb90"],
          "entailment": null
        }
      ]
    }
  ],
  "open_questions": [],
  "action_intents": [
    {
      "tool": "flag_invoice_line",
      "args": {"invoice_id": "INV-4421", "line_id": "14"},
      "requires_grant": true,
      "depends_on": ["c_19"]
    }
  ]
}

Achten Sie darauf, was fehlt: Es gibt kein summary-Feld, das vom nächsten Agenten direkt zitiert werden könnte. In Zusammenfassungen gehen genau die Qualifikationen und Einschränkungen verloren. Wenn ein nachgelagerter Agent Prosa benötigt, muss er diese Erzählung ausschließlich aus überprüften Behauptungen erstellen, und solange ein Mensch sie nicht als Kundentext freigibt, wird sie als Conjecture gekennzeichnet.

Achten Sie außerdem darauf, dass entailment auf null gesetzt ist. Der Agent, der die Behauptung verfasst hat, darf dieses Feld nicht selbst ausfüllen – nur der Überprüfer kann das. Es ist, als würde ein Unternehmen seine eigene Konformitätsprüfung durchführen und diese als unabhängige Überwachung bezeichnen.

Warum „einfach Quellen hinzufügen“ immer noch nicht funktioniert

Der häufigste falsche Schutzmechanismus ist eine Ausgabe, die nur so aussieht, als sei sie zitiert. Das Modell fügt ein [1] oder [2] hinzu, manchmal sogar auf einen tatsächlich abgerufenen Textabschnitt verweisend. Wenn man diesen Abschnitt dann öffnet, stellt man fest, dass er die behauptete Aussage tatsächlich nicht stützt.

Ein Zitat für sich allein beweist nichts. Ein echter Beweis sieht so aus: dieser spezifische Textabschnitt, diese genaue Bytesammlung, die einer bestimmten Aussage zugeordnet ist, mit einem Implikationslabel versehen und durch eine klare Richtlinie geregelt, was passiert, wenn dieses Label neutral ist. Ohne diese vollständige Kette ist eine „Zitation“ lediglich eine als Beweis getarnte Formatierungswahl.

Der zweite falsche Schutzmechanismus besteht darin, die Temperatur auf 0 zu setzen. Das macht die Ausgabe nicht wahrheitsgetreuer – es sorgt lediglich dafür, dass eine falsche Antwort konsistent bleibt. Eine stabile Halluzination wird bei jedem Snapshot-Test bestehen, aber in einem ordnungsgemäß gepflegten Protokoll nicht überleben.

Was das ehrlich gesagt kostet

Es dauert nur wenige Tage, um eine Demo-Pipeline in einer Plattform wie LangGraph zum Laufen zu bringen. Doch der Aufbau des eigentlichen Steuerungssystems dahinter – ein Tool-Register, ein Zitierverzeichnis, Schema-Prüfmechanismen, ein auf NLI basierender Überprüfer, Gold-Trace-Bewertungen, menschliche Prüfung jeder schreibbaren Aktion sowie Logs, die detailliert genug sind, damit ein Anwalt sie nachvollziehen kann – ist es, was einen funktionsfähigen Prototyp von einem System unterscheidet, dem man echte Geschäftsentscheidungen anvertrauen kann.

Es gibt keine einheitliche Zahl, die für alle Fälle gilt. Die tatsächlichen Kosten hängen davon ab, wie viele Ihrer Tools Nebeneffekte verursachen, ob Ihre Quelle der Wahrheit bereits strukturiert und abfragbar ist sowie wie teuer eine nicht unterstützte Behauptung in Ihrem spezifischen Bereich tatsächlich ist. Rechtliche Abrechnungen und finanzielle Berichterstattung gehören zum Bereich mit hohen Kosten und großen Risiken. Ein Brainstorming-Tool, das aus einer Gruppe von Agenten besteht, befindet sich am anderen Ende dieses Spektrums – es wäre übertrieben, es mit so viel Infrastruktur auszustatten.

Die Frage, die man zuerst stellen sollte, ist nicht, auf welchem Framework man aufbauen soll – sondern herauszufinden, wo sich Ihr eigener Arbeitsablauf in diesem Spektrum befindet.

Falls dies tatsächlich Ihr Problem ist

Diese Art von Steuerungsplattform ist besonders wichtig für Teams, die keine Antworten ertragen können, die selbstbewusst klingen, aber falsch sind – insbesondere in rechtlichen Bereichen, der Finanzbranche sowie bei prozessintensiven Tätigkeiten mit vielen Dokumenten. Das bedeutet Graphen für Agenten, die mit Tools wie LangGraph erstellt werden, Abrufpipelines, die tatsächlich überprüft und nicht einfach als funktionsfähig vorausgesetzt werden, sowie Extraktionsysteme, die einer Prüfung standhalten müssen.

Falls Ihr eigener Graph in einer Demo überzeugend funktioniert, aber nach dem Go-Live falsche Angaben liefert, lässt sich der Fehler fast immer auf einen der hier beschriebenen sechs Komponenten zurückführen – und herauszufinden, welche es ist sowie ob sich die ingenieurtechnische Anstrengung lohnt, ihn zu beheben, ist der eigentliche Ausgangspunkt für die Planung der Arbeiten.