MARCH -- Multi-Agent-Selbstpruefung gegen Halluzinationen in RAG-Systemen
Zhuo Li, Yupeng Zhang, Pengyu Cheng und Kollegen vom Qwen-Team (Alibaba) sowie der Chinese University of Hong Kong haben am 25. Maerz 2026 MARCH vorgestellt -- ein Framework, das Halluzinationen in Retrieval-Augmented-Generation-Systemen durch ein Multi-Agenten-Design mit bewusster Informationsasymmetrie bekaempft. Ein 8B-Parameter-Modell erreicht damit Leistungen, die mit GPT-4o vergleichbar oder besser sind.
Kernaussagen
Das zentrale Problem bestehender Verifikationsmethoden ist Bestaetigungsfehler (Confirmation Bias): Wenn ein Pruefer gleichzeitig die generierte Antwort und die Quellen sieht, reproduziert er haeufig die Fehler des Generators, statt sie aufzudecken. MARCH loest das durch architektonische Trennung -- der Pruefer sieht die urspruengliche Antwort nie.
Die Ergebnisse sind erheblich: Auf RAGTruth/FaithBench steigt die Faktentreue um 20 Prozentpunkte (von 55,2% auf 75,2%). Auf dem Facts-Grounding-Benchmark erreicht MARCH 80,1% gegenueber 57,1% der Baseline. Auf HotpotQA uebertrifft das 8B-Modell mit 73,6% sogar GPT-4o RAG (64,0%). Diese Gewinne sind konsistent ueber Llama-3.1 und Qwen-3 Modellfamilien hinweg, mit durchschnittlich 11% absoluter Verbesserung.
Methodik
MARCH besteht aus drei spezialisierten Agenten, die alle aus einem einzigen Basismodell abgeleitet werden:
Der Solver generiert Antworten basierend auf Anfrage und abgerufenen Dokumenten. Der Proposer zerlegt diese Antworten in atomare, verifizierbare Frage-Antwort-Paare, mit besonderem Fokus auf numerische Behauptungen. Der Checker beantwortet diese Fragen ausschliesslich anhand der Originaldokumente -- ohne Zugang zur Solver-Antwort. Diese Informationsbarriere ist der Kern des Ansatzes.
Das Training erfolgt ueber Proximal Policy Optimization (PPO) mit gemeinsamer Gradientenberechnung ueber Solver- und Checker-Trajektorien. Die Belohnungsfunktion ist eine Zero-Tolerance Reward (ZTR): Nur wenn jede einzelne extrahierte Behauptung durch den Checker unabhaengig bestaetigt wird, gibt es eine Belohnung von 0; andernfalls -1. Dieses Alles-oder-Nichts-Prinzip verhindert, dass das Modell auf partielle Korrektheit optimiert.
Die Trainingsdaten sind bewusst verrauscht: BioASQ fuer STEM-Domaenen, 2WikiMultiHopQA und MuSiQue fuer allgemeine Themen, mit 24-88% irrelevanten Dokumenten im Retrieval-Kontext -- realistisch fuer Produktionsumgebungen.
Relevanz fuer die Praxis
Drei Aspekte machen MARCH fuer den praktischen Einsatz besonders interessant. Erstens ist der Ansatz modellgroessen-effizient: Ein 8B-Modell mit MARCH uebertrifft deutlich groessere Modelle ohne dieses Framework, was den Einsatz in ressourcenbeschraenkten Umgebungen ermoeglicht. Zweitens ist MARCH orthogonal zu anderen Methoden -- es laesst sich mit Chain-of-Thought-Prompting und Few-Shot-Learning kombinieren, ohne Konflikte. Drittens benoetigt das Training keine zusaetzlichen manuellen Annotationen oder externen Faktencheck-Tools.
Fuer Teams, die RAG-Systeme in Produktion betreiben, zeigt MARCH einen konkreten Weg: Die architektonische Trennung zwischen Generierung und Verifikation ist das wirksamste Mittel gegen Bestaetigungsfehler. Selbst ohne das vollstaendige Training-Framework ist die Grundidee -- den Verifizierer von der zu pruefenden Antwort zu isolieren -- in bestehende Pipelines uebertragbar.