Agentic DAG-Orchestrated Planner Framework for Multi-Modal, Multi-Hop Question Answering in Hybrid Data Lakes

Das Paper stellt A.DOT vor, einen agenticen, DAG-basierten Planungsrahmen für die mehrstufige, multimodale Beantwortung von Fragen in hybriden Datenseen, der durch die Zerlegung von Anfragen in parallele Teilabfragen, schema-bewusstes Reasoning und explizite Nachverfolgbarkeit die Genauigkeit und Vollständigkeit im Vergleich zu bestehenden RAG-Systemen signifikant verbessert.

Das Wesentliche

Stellen Sie sich vor, Sie arbeiten in einem riesigen, chaotischen Archiv, das aus zwei völlig unterschiedlichen Welten besteht:

1. Die Welt der Tabellen: Hier liegen ordentliche Excel-Listen mit Zahlen, Namen und Daten (z. B. "Rechnung Nr. 123, Betrag: 500 €, Kunde aus Texas").
2. Die Welt der Dokumente: Hier liegen stapelweise unordentliche Akten, Verträge und E-Mails in Textform (z. B. "Die Zahlungsbedingungen für Texas-Kunden sind: 30 Tage").

Wenn Sie als Chef jetzt fragen: "Wie viel Geld haben wir durchschnittlich von Kunden aus Texas bekommen und unter welchen Bedingungen zahlen sie?", dann ist das für einen normalen Computer wie ein Albtraum. Er muss erst die Tabelle durchsuchen, dann die Texte lesen, die Informationen verknüpfen und eine Antwort formulieren.

Bisherige Systeme (wie einfache Suchmaschinen oder KI-Chatbots) machen das oft so: Sie werfen die Frage blindlings in beide Welten, holen alles heraus, was irgendwie passt, und versuchen dann, den Haufen an Informationen zu einem Satz zu verarbeiten. Das ist ineffizient, langsam und oft ungenau.

A.DOT ist wie ein genialer Chef-Orchestrator, der genau weiß, wie man diese Aufgabe löst. Hier ist die Erklärung, wie er funktioniert, mit ein paar einfachen Analogien:

1. Der Bauplan (DAG-Orchestrierung)

Stellen Sie sich vor, Sie wollen ein komplexes Haus bauen. Ein gewöhnlicher Bauarbeiter würde einfach loslegen und hoffen, dass es passt. A.DOT hingegen ist ein Architekt, der zuerst einen perfekten Bauplan (einen sogenannten "DAG" oder gerichteten azyklischen Graphen) zeichnet.

• Was bedeutet das? Der Architekt zerlegt Ihre Frage in kleine, handhabbare Schritte:
  • Schritt 1: Suche in der Tabelle nach "Texas".
  • Schritt 2: Berechne den Durchschnitt der Beträge.
  • Schritt 3: Nimm die IDs aus Schritt 1 und 2 und suche in den Textdokumenten nach den "Zahlungsbedingungen".
• Der Clou: Schritte, die nichts miteinander zu tun haben, können parallel erledigt werden (wie zwei Handwerker, die gleichzeitig arbeiten). Das spart enorm viel Zeit.

2. Der Qualitätskontrolleur (Validator & DataOps)

Bevor der Bau beginnt, schaut sich der Architekt den Plan genau an.

• Strukturelle Prüfung: "Haben wir die richtigen Werkzeuge? Gibt es die Spalte 'Texas' wirklich?"
• Semantische Prüfung: "Macht die Frage überhaupt Sinn?"

Wenn etwas schiefgeht (z. B. der Plan ist falsch), springt nicht einfach ein neuer Architekt ein, der alles neu erfindet. Stattdessen gibt es ein Spezial-Team (DataOps), das wie ein Schadenverhütungsteam arbeitet:

• Der Diagnostiker: Findet heraus, warum es nicht klappt.
• Der Reparateur: Macht kleine, schnelle Korrekturen am Plan, ohne alles neu zu bauen.
• Der Neuplaner: Wenn es wirklich schlimm ist, wird der Plan komplett neu gezeichnet.

Das verhindert, dass das System in einer Endlosschleife hängen bleibt oder falsche Antworten liefert.

3. Der effiziente Kurier (Variable Binding)

Frühere Systeme schickten oft den ganzen Stapel Akten von Schritt 1 zu Schritt 2, auch wenn nur eine einzige Zeile gebraucht wurde. Das ist wie ein Paketbote, der einen ganzen Container mit Möbeln bringt, nur um ein einziges Sesselbein zu liefern.

A.DOT ist schlauer: Es schickt nur das Notwendige weiter. Wenn Schritt 1 die "Rechnungs-ID" gefunden hat, schickt A.DOT nur diese ID an Schritt 2, nicht den ganzen Text der Rechnung. Das macht das System extrem schnell und verhindert, dass sensible Daten unnötig herumgereicht werden (Datenschutz!).

4. Die Gedächtnisstütze (Caching)

Wenn Sie A.DOT fragen: "Wie viel Geld haben Texas-Kunden gezahlt?" und eine Minute später: "Was ist die Summe der Zahlungen aus Texas?", erkennt das System sofort: "Hey, das ist im Grunde die gleiche Frage!"

Es nutzt ein Gedächtnis, um den alten Bauplan wiederzuverwenden, statt alles neu zu planen. Das ist wie ein erfahrener Koch, der für das gleiche Gericht nicht jedes Mal das Rezept neu schreibt, sondern einfach auf den alten Plan zurückgreift.

Warum ist das so wichtig? (Die Ergebnisse)

Das Papier zeigt, dass A.DOT im Vergleich zu anderen Systemen (wie dem bekannten "ReAct" oder einfachen Suchmaschinen) deutlich bessere Antworten liefert.

• Es ist genauer (14,8 % besser).
• Es vergisst weniger Details (10,7 % vollständiger).

Und das Beste: A.DOT hinterlässt eine Spur (Lineage). Sie können genau nachvollziehen, woher jede Information kam. Wenn die Antwort lautet "30 Tage Zahlungsziel", können Sie sehen: "Ah, das steht in Dokument X, Zeile 5, basierend auf Tabelle Y." Das schafft Vertrauen, besonders in Unternehmen, wo man wissen muss, ob eine Antwort auf Fakten oder nur auf Halluzinationen basiert.

Zusammenfassung

A.DOT ist wie ein super-organisierter Chef, der:

1. Einen perfekten Plan für komplexe Fragen macht.
2. Die Arbeit parallel aufteilt, damit es schnell geht.
3. Nur das Nötigste hin- und herschickt.
4. Fehler sofort erkennt und repariert.
5. Alles dokumentiert, damit man der Antwort vertrauen kann.

Es verwandelt das Chaos aus Tabellen und Texten in eine klare, verlässliche Antwort – genau das, was moderne Unternehmen brauchen, um aus ihren Daten echte Erkenntnisse zu gewinnen.

Technische Zusammenfassung

1. Problemstellung

Unternehmen nutzen zunehmend hybride Data Lakes, die strukturierte Daten (z. B. relationale Tabellen, SQL) und unstrukturierte Daten (z. B. Dokumente, Verträge, Vektorspeicher) kombinieren. Bestehende Lösungen für natürliche Sprachabfragen (NLQ) in diesen Umgebungen, wie z. B. RAG-Systeme (Retrieval-Augmented Generation), leiden unter mehreren gravierenden Mängeln:

• Ineffizienz und „Brute-Force"-Retrieval: Sie fragen oft alle Datenquellen unabhängig und unselektiv ab, was zu hohem Rechenaufwand und unnötigem Datenzugriff führt.
• Fehlende Multi-Hop-Logik: Komplexe Fragen erfordern oft mehrere Schritte (Hops), bei denen zwischen strukturierten und unstrukturierten Quellen hin- und hergesprungen werden muss (z. B. zuerst IDs aus einer Tabelle extrahieren, dann Details aus zugehörigen Dokumenten suchen). Bestehende Systeme können diese Abhängigkeiten oft nicht explizit planen.
• Halluzinationen und Datenlecks: Durch das Fehlen einer präzisen Planung neigen Modelle dazu, falsche SQL-Abfragen zu generieren oder mehr Daten zu extrahieren als nötig, was Sicherheitsrisiken birgt.
• Mangelnde Nachvollziehbarkeit: Es fehlt oft an expliziten Beweispfaden (Evidence Trails) und Datenherkunftsnachweisen (Lineage), was in Unternehmensumgebungen für Compliance und Vertrauen kritisch ist.

2. Methodik: Der A.DOT-Planner

Die Autoren stellen A.DOT (Agentic DAG-Orchestrated Transformer Planner) vor, ein Framework, das NL-Abfragen in ausführbare gerichtete azyklische Graphen (DAGs) übersetzt.

Architektur und Komponenten:

• Plan-Generator: Ein LLM (LLaMA-3 70B) zerlegt die Benutzeranfrage in einem einzigen Durchlauf in einen DAG. Jeder Knoten repräsentiert eine atomare Sub-Abfrage, die entweder eine SQL-Datenbank (strukturiert) oder einen Vektorspeicher (unstrukturiert) anspricht. Kanten definieren Abhängigkeiten und Datenflüsse.
• Plan-Validator: Bevor die Ausführung beginnt, wird der DAG sowohl strukturell (Schema-Konformität, keine Zyklen, korrekte Variablen) als auch semantisch (Erhaltung der Intentions, Typen der Join-Schlüssel) validiert.
• DataOps-System: Ein mehrstufiges Agentensystem für Diagnose und Remediation. Es besteht aus:
  • Diagnoser: Identifiziert Fehlerursachen (z. B. falsches Tool, fehlende Filter).
  • Recommender: Schlägt Recovery-Maßnahmen vor.
  • Fixer: Wendet lokale Korrekturen an, ohne die DAG-Struktur zu ändern.
  • Replanner: Generiert bei tiefgreifenden Fehlern einen neuen Plan.
• Plan-Executor: Führt den DAG in topologischer Reihenfolge aus. Unabhängige Knoten werden parallel verarbeitet. Ein entscheidendes Merkmal ist das Variable-Binding: Es werden nur minimale, notwendige Daten (z. B. IDs) zwischen Knoten weitergegeben, um den Overhead zu minimieren und Speicherprobleme zu vermeiden.
• Plan-Caching: Ähnliche oder paraphrasierte Abfragen werden durch Template-Matching und semantische Suche erkannt, um bereits validierte DAG-Pläne wiederzuverwenden.

Besonderheiten:

• Paraphrase-aware Caching: Erkennt semantisch äquivalente Fragen und nutzt gespeicherte Pläne.
• Streaming & Partial Answers: Ergebnisse können sofort ausgegeben werden, sobald ein Knoten fertig ist (falls should expose answer=true), während der Rest des DAG weiterläuft.
• Daten-Lineage: Jeder Schritt protokolliert Eingaben, Ausgaben und die Herkunft der Daten, was eine vollständige Auditierbarkeit ermöglicht.

3. Schlüsselbeiträge

1. A.DOT-Framework: Ein agenter Ansatz, der DAG-basierte Planung mit struktureller und semantischer Validierung sowie einem dualen DataOps-System für Fehlerbehebung kombiniert.
2. Variable-Binding-Mechanismus: Selektive Weitergabe von Daten zwischen Sub-Abfragen über verschiedene Modalitäten hinweg, was die Skalierbarkeit erhöht und Datenlecks reduziert.
3. Parallele Ausführungsstrategie: Nutzt die Unabhängigkeit von DAG-Knoten, um die End-to-End-Latenz zu senken.
4. Plan-getriebene Ausführung: Ermöglicht durch detaillierte Protokollierung von Beweisen und Datenherkunft eine vollständige Verifizierbarkeit und Auditierbarkeit.
5. Empirische Validierung: Nachweisbare Verbesserungen gegenüber bestehenden State-of-the-Art-Methoden auf einem relevanten Benchmark.

4. Ergebnisse

Das Framework wurde auf dem HybridQA-Datensatz (3.466 Frage-Antwort-Paare) evaluiert, der Multi-Hop-Reasoning über Tabellen und Text erfordert. Als Baselines dienten Standard-RAG, ReAct und LLM-Compiler.

• Leistungsgewinn: A.DOT erreichte im Vergleich zum stärksten Baseline-Modell (Standard RAG) eine absolute Steigerung der Antwortkorrektheit um 14,8 % (von 56,2 % auf 71,0 %) und eine Steigerung der Vollständigkeit um 10,7 % (von 62,3 % auf 73,0 %).
• Vergleich mit Baselines:
  • ReAct: Scheiterte oft an der sequenziellen Ausführung und der Begrenzung auf 20 Schritte, was die Wiederherstellung bei Fehlern einschränkte.
  • LLM-Compiler: Zeigte Schwächen durch mangelnde Validierung und fehlende Robustheit bei Laufzeitfehlern.
  • Ablationsstudie: Zeigte, dass sowohl der Validator als auch das DataOps-System essenziell sind. Ohne DataOps fiel die Korrektheit drastisch auf 60,0 %, da Fehler nicht korrigiert werden konnten. Die Kombination beider Komponenten führte zu den besten Ergebnissen.

5. Bedeutung und Ausblick

Die Arbeit stellt einen bedeutenden Schritt von reinen Forschungsprototypen hin zu unternehmensreife Lösungen dar.

• Praktische Relevanz: Das System wird derzeit als zentrales Retrieval-Modul für IBM Watsonx.data Premium evaluiert. Dies unterstreicht die Eignung für reale, komplexe Unternehmensdatenlandschaften.
• Vertrauen und Compliance: Durch die expliziten Beweispfade und die Nachverfolgbarkeit der Datenherkunft adressiert A.DOT kritische Anforderungen an Sicherheit und Compliance in Unternehmen.
• Zukunftsperspektiven: Geplant ist die Erweiterung auf mehrstufige Konversationen (Multi-Turn) und die Integration weiterer Modalitäten wie Graphdatenbanken oder Bilddaten.

Zusammenfassend bietet A.DOT eine robuste, effiziente und nachvollziehbare Architektur, die die Lücke zwischen der Komplexität hybrider Datenquellen und den Anforderungen an präzise, vertrauenswürdige KI-Antworten schließt.