💬 NLP

LakeQA: An Exploratory QA Benchmark over a Million-Scale Data Lake

Das Papier stellt LakeQA vor, einen umfassenden Benchmark, der auf 9,5 TB heterogener Daten basiert und große Sprachmodelle dazu herausfordert, eine suchzentrierte Beantwortung von Fragen durch die Kombination von Dokumentenabruf mit komplexer Multi-Hop-Argumentation durchzuführen, was selbst bei Spitzenmodellen signifikante Leistungsunterschiede offenbart.

Ursprüngliche Autoren: Haonan Wang, Jiaxiang Liu, Yurong Liu, Austin Senna Wijaya, Tianle Zhou, Eden Wu, Yijia Chen, Wanting You, Reya Vir, Daniela Pinto, Grace Fan, Yusen Zhang, Juliana Freire, Eugene Wu

Veröffentlicht 2026-06-10

📖 5 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Haonan Wang, Jiaxiang Liu, Yurong Liu, Austin Senna Wijaya, Tianle Zhou, Eden Wu, Yijia Chen, Wanting You, Reya Vir, Daniela Pinto, Grace Fan, Yusen Zhang, Juliana Freire, Eugene Wu

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie sind ein Detektiv, der versucht, einen sehr spezifischen Fall zu lösen. In den meisten Detektivgeschichten (oder Standard-KI-Tests) reicht der Autor Ihnen einen Stapel Akten und sagt: „Die Antwort steht auf diesen drei Seiten.“ Ihre Aufgabe ist es lediglich, diese zu lesen und den Hinweis zu finden.

LAKEQA ist eine andere Art von Test. Hier gibt der Autor Ihnen eine Frage, aber keine Akten. Stattdessen werden Sie in ein riesiges, chaotisches Lagerhaus von der Größe einer Kleinstadt geworfen, das mit 40 Millionen verschiedenen Dokumenten gefüllt ist. Einige sind ordentlich organisierte Tabellenkalkulationen, andere sind unordentliche PDFs, alte Textdateien oder Regierungsberichte.

Ihre Aufgabe ist es, die Antwort zu finden, indem Sie durch dieses Lagerhaus suchen und die Fäden über viele verschiedene Dokumente hinweg verknüpfen.

Hier ist eine Aufschlüsselung dessen, worum es in dem Papier geht, unter Verwendung einfacher Analogien:

1. Das Problem: Die „Nadel im Heuhaufen“ ist eigentlich eine „Nadel in einem Berg aus Heuhaufen“

Aktuelle KI-Modelle (Large Language Models) sind großartig darin, ein Buch zu lesen und Fragen dazu zu beantworten. Aber in der realen Welt sind Daten nicht ordentlich verpackt. Sie sind über Millionen von Dateien in „Data Lakes“ verstreut.

Der alte Weg: Der KI wird ein spezifisches Buch gegeben und die Frage gestellt: „Welche Farbe hat das Auto?“ Die KI liest das Buch und antwortet.
Der LAKEQA-Weg: Der KI wird die Frage gestellt: „Finde die Grundschule in New York, die kleine Klassen und die wenigsten Gewalttatvorfälle zwischen 2008 und 2011 hatte.“
- Die KI weiß nicht, welche Datei die Schulnamen enthält.
- Die KI weiß nicht, welche Datei die Klassengrößen enthält.
- Die KI weiß nicht, welche Datei die Kriminalstatistiken enthält.
- Sie muss nach den richtigen Dateien suchen, diese herunterladen, sie lesen und dann die Informationen aus all diesen Dateien kombinieren, um das Rätsel zu lösen.

2. Der Benchmark: Eine „Multi-Hop“-Schatzsuche

Das Papier stellt LAKEQA vor, einen neuen Test, der darauf ausgelegt ist zu prüfen, wie gut eine KI bei dieser speziellen Art von Detektivarbeit ist.

Stellen Sie sich eine Aufgabe in LAKEQA wie eine Schatzsuche mit 8 Hinweisen vor:

Hinweis 1: Sie müssen ein Viertel finden. (Sie suchen in Wikipedia).
Hinweis 2: Dieses Viertel liegt neben einem anderen Viertel. (Sie suchen in einer Datenbank für Karten).
Hinweis 3: Sie müssen Schulen in beiden Vierteln finden. (Sie suchen in einer Regierungsliste).
Hinweis 4: Sie müssen diese Schulen nach der Klassengröße filtern. (Sie öffnen eine Tabellenkalkulation).
Hinweis 5: Sie müssen die Kriminalstatistik für die verbleibenden Schulen prüfen. (Sie öffnen einen anderen Bericht).
...und so weiter.

Wenn die KI bei Hinweis 2 stecken bleibt, kann sie Hinweis 8 niemals lösen. Das Papier nennt dies „Multi-hop reasoning“ (Multi-Hop-Schlussfolgerung). Die KI muss einen Schritt machen, eine neue Information finden und diese nutzen, um zu entscheiden, wo sie als Nächstes suchen muss.

3. Die Skalierung: Eine „Bibliothek von Babel“

Das Papier hat diesen Test mit einer massiven Datensammlung erstellt:

9,5 Terabyte an Daten (stellen Sie sich eine Bibliothek mit Millionen von Büchern vor).
40 Millionen Dokumente (eine Mischung aus strukturierten Daten wie Excel-Tabellen und unstrukturierten Daten wie Textartikeln).
Quellen: Wikipedia (für allgemeines Wissen) und Data.gov (für reale, unordentliche Regierungsdaten).

Dies ist wichtig, weil frühere Tests nur kleine, saubere Textsammlungen verwendeten. LAKEQA zwingt die KI, mit der „Unordnung“ der realen Welt umzugehen.

4. Die Ergebnisse: Die KI verirrt sich

Die Forscher haben sieben der klügsten verfügbaren KI-Modelle (einschließlich GPT-5.2 und Claude) bei dieser Herausforderung getestet.

Die Punktzahl: Die beste KI beantwortete nur etwa 18 % bis 33 % der Fragen korrekt.
Das Hauptversagen: Die KI scheiterte nicht daran, dass sie nicht lesen oder schlussfolgern konnte. Sie scheiterte daran, dass sie die richtigen Dateien nicht finden konnte.
- Analogie: Stellen Sie sich einen brillanten Detektiv vor, der jeden Verbrechen lösen kann, aber in einem riesigen Lagerhaus mit verbundenen Augen steht. Er kann die Beweise nicht finden, weil er nicht weiß, in welches Regal er schauen muss.
Das „Long Chain“-Problem: Mit zunehmender Anzahl der Schritte (Hops) sank die Leistung der KI drastisch. Je mehr Schritte sie machen musste, desto wahrscheinlicher war es, dass sie sich verirrte oder einen vorherigen Hinweis vergaß.

5. Das Fazenzit: Die Suche ist der Flaschenhals

Das Papier kommt zu dem Schluss, dass KI zwar immer besser im „Denken“ (Reasoning) wird, aber immer noch schrecklich im „Suchen“ (Searching und Entdecken) in riesigen, unorganisierten Data Lakes ist.

Aktuelle KI: „Ich kann ein Buch perfekt lesen, aber wenn man das Buch in einem Haufen von 40 Millionen anderen Büchern versteckt, kann ich es nicht finden.“
Das Ziel: Wir brauchen KI-Agenten, die nicht nur kluge Leser sind, sondern auch erfahrene Entdecker, die in der Lage sind, durch riesige, unordentliche Datenspeicher zu navigieren, um die spezifischen Beweise zu finden, die sie zur Lösung eines Problems benötigen.

Zusammenfassend lässt sich sagen: LAKEQA ist ein Stresstest, der zeigt, dass heutige KI immer noch sehr schlecht darin ist, Nadeln in massiven, unordentlichen Heuhaufen zu finden, selbst wenn sie die Intelligenz besitzt, die Nadel zu verstehen, sobald sie sie gefunden hat.

Technisches Resümee: LAKEQA – Ein explorativer QA-Benchmark über einen Data Lake im Millionen-Maßstab

Problemdefinition

Jüngste Large Language Models (LLMs) haben signifikante Fortschritte beim lese-basierten Question Answering (QA) gemacht, bei dem Evidenz entweder explizit bereitgestellt oder trivial aus engen, kuratierten Korpora abrufbar ist. Reale Szenarien beinhalten jedoch oft Exploratives Question Answering (EQA) über heterogene Data Lakes. In diesen Umgebungen wird die Evidenz nicht vorab bereitgestellt; stattdessen ist sie über massive Sammlungen strukturierter (z. B. CSV, JSON) und unstrukturierter (z. B. PDF, HTML) Dokumente verstreut. Das Lösen solcher Probleme erfordert Agenten, die iterativ nach relevanten Dateien suchen, intermediäre Entitäten entdecken und über mehrere abhängige Schritte hinweg schlussfolgern müssen, bevor sie eine endgültige Antwort formulieren.

Aktuelle Benchmarks versäumen es, diese Komplexität gleichzeitig zu erfassen. Bestehende Datensätze besitzen entweder eine hohe Suchintensität (große Dokumentensammlungen), aber eine geringe Reasoning-Tiefe (wenige Hops), oder eine hohe Reasoning-Tiefe, operieren jedoch über kleine, kuratierte Suchräume. Es mangelt an einem umfassenden Benchmark, der sowohl hohe Suchintensität (Scannen von Millionen Dokumenten) als auch hohe Reasoning-Intensität (langfristige, Multi-Hop-Argumentation mit impliziten Zwischenschritten) fordert.

Methodik

1. Benchmark-Konstruktion (LAKEQA)

Die Autoren führen LAKEQA ein, einen Benchmark, der darauf ausgelegt ist, EQA-Fähigkeiten über einen massiven, heterogenen Data Lake zu evaluieren.

Skalierung des Data Lake: Der Benchmark basiert auf einer Sammlung von etwa 9,5 TB Daten, bestehend aus rund 40 Millionen einzigartigen Dokumenten.
Quellen: Die Daten werden aus zwei komplementären Open-Data-Quellen aggregiert:
- Wikipedia: Parsed aus dem neuesten englischen Dump, um als kanonischer Textkorpus zu dienen.
- Data.gov: Geerntet aus dem Harvard LIL data.gov Archiv, welches diverse, schwach standardisierte öffentliche Regierungsartefakte (strukturierte Tabellen, Metadaten, Berichte) bereitstellt.
Aufgabendesign: Jede Aufgabe ist eine komplexe natürliche Sprachfrage, die einen Agenten dazu zwingt:
1. Relevante Dokumente aus der 40M-Sammlung zu identifizieren.
2. Unterstützende Fakten zu extrahieren.
3. Reasoning-Schritte zu verketten, bei denen das Ergebnis eines Schritts als Eingangsbedingung für den nächsten dient.
Annotationsprozess: Aufgaben werden über einen Human-in-the-Loop-Prozess unter Beteiligung von Experten auf PhD-Niveau und fortgeschrittenen Studenten erstellt. Der Prozess umfasst:
- Subfragen-Konstruktion: Annotatoren leiten Fakten aus Dokumenten ab und formulieren Sub-Fragen, wobei sie diese so verketten, dass $Answer_i$ eine Voraussetzung für $Question_{i+1}$ ist.
- Fragen-Umschreibung: Die Kette wird in eine einzige, natürlich klingende Frage umgeschrieben, die Dokumenten-Identifikatoren verbirgt, um eine triviale Entdeckung zu verhindern.
- Qualitätskontrolle: Jede Aufgabe durchläuft eine mehrstufige Überprüfung durch unabhängige Annotatoren, um die logische Validität, Natürlichkeit und die Eindeutigkeit der finalen Antwort durch die Evidenz sicherzustellen.

2. Experimentelles Setup

Evaluierte Modelle: Sieben Frontier-LLMs wurden getestet, darunter proprietäre Modelle (OpenAI GPT-5.2, GPT-5-mini, Anthropic Claude Haiku/Sonnet/Opus 4.5) und Open-Source-Modelle (DeepSeek-R1, Llama-3.3-70B).
Agenten-Umgebung: Die Modelle wurden mit einer Tool-Suite ausgestattet, die realistische Datenanalyse-Workflows imitiert, einschließlich:
- search(query): Keyword- und semantische Suche über den Data Lake.
- list_files, download, inspect: Dateiverwaltung und Vorschau.
- execute_code: Python-Ausführung für lokale Datenanalysen (Filtern, Aggregation).
Baselines: RAG-Baselines wurden unter Verwendung von BM25 und Hybrid-Suche (BM25 + Vektor) über Stichproben-Teilmengen des Data Lakes (10k–50k Dokumente) getestet.
Metriken: Die Leistung wurde mittels Exact Match (EM) für die End-to-End-Genauigkeit sowie Precision, Recall und F1 auf Dokumentenebene für die Effektivität der Suche gemessen.

Kernergebnisse

1. Performance-Gap

Selbst mit Zugriff auf Such- und Inspektions-Tools haben State-of-the-Art LLMs erhebliche Schwierigkeiten mit LAKEQA:

Geringe Genauigkeit: Das leistungsfähigste Modell, Claude-sonnet-4.5, erreichte lediglich 32,87 % Exact Match auf dem vollständigen Benchmark (LAKEQA-full). GPT-5.2 erzielte 18,37 %, und Open-Source-Modelle schnitten noch schlechter ab.
Cost-Accuracy-Trade-off: Während größere Modelle (z. B. Claude Opus) auf dem Mini-Set eine höhere Genauigkeit zeigten (45,93 %), verursachten sie signifikant höhere Kosten und Laufzeiten. Kleinere, günstigere Modelle scheiterten oft aufgrund ineffizienter Codegenerierung oder mangelhafter Argumentation.

2. Fehleranalyse

Die Trajektorien-Analyse ergab, dass der primäre Flaschenhals die Dokumenten-Entdeckung (Document Discovery) ist, nicht das Reasoning über gefundene Evidenz:

Suchfehler: Modelle scheiterten häufig daran, die benötigten "Gold"-Dokumente abzurufen, um die Frage zu beantworten. Der Recall auf dem abgerufenen Satz ( $D_{ret}$ ) war niedrig, was darauf hindeutet, dass Agenten nicht in der Lage waren, relevante Dateien aufzuspüren.
Explorationsfehler: Selbst wenn relevante Dokumente abgerufen wurden, versäumten es Agenten oft, diese zu inspizieren oder zu analysieren. Beispielsweise erreichte Claude-sonnet-4.5 auf LAKEQA-full einen Recall von 42,36 % auf abgerufenen Dokumenten, aber nur 13,04 % Recall auf akzessierten Dokumenten ( $D_{acc}$ ), was auf eine Diskrepanz zwischen Retrieval und effektiver Exploration hindeutet.
Fehlerakkumulation: Die Leistung sank drastisch mit zunehmender Anzahl der Reasoning-Hops. Aufgaben, die >18 Hops erforderten, zeigten einen massiven Abfall der Genauigkeit, was darauf hindeutet, dass langfristige Exploration die kumulativen Fehler aus imperfektem Retrieval und übersehenen Constraints verstärkt.

3. RAG-Baselines

Das Hinzufügen von Retrieval-Tools zu reduzierten Dokumenten-Teilmengen (10k–50k) verbesserte die Leistung leicht, löste das Problem jedoch nicht. Die Ergebnisse legen nahe, dass EQA keine Single-Shot-Retrieval-Aufgabe ist; Agenten müssen iterativ fehlende Informationen inferieren, neue Abfragen formulieren und entscheiden, wann die Evidenz ausreichend ist – eine Fähigkeit, die aktuellen RAG-Systemen fehlt.

Bedeutung und Ansprüche

Das Paper positioniert LAKEQA als realistisches Testfeld für die Entwicklung von LLM-Agenten, die in modernen Data-Lake-Umgebungen operieren können. Seine Bedeutung liegt in:

Überbrückung der Lücke: Es ist der erste Benchmark, der gleichzeitig Suchintensität (40M Dokumente) und Reasoning-Intensität (Multi-Hop-Ketten) skaliert und damit eine Limitation früherer Arbeiten wie OTT-QA (hohe Suche, geringes Reasoning) oder MuSique (hohes Reasoning, geringe Suche) adressiert.
Identifizierung von Flaschenhälsen: Die Experimente zeigen, dass aktuelle LLM-Agenten noch nicht in der Lage sind, eine effektive iterative Suche und Exploration durchzuführen. Der primäre Fehlermodus ist die Unfähigkeit, die korrekten Evidenzdokumente zu entdecken und zu öffnen, nicht die Unfähigkeit zu argumentieren, sobald die Evidenz gefunden wurde.
Relevanz für die reale Welt: Durch die Nutzung heterogener Regierungs- und Wikipedia-Daten spiegelt LAKEQA die unordentliche, unstrukturierte Realität realer Data Lakes wider und geht über kuratierte Korpora hinaus, um Agenten mit der Komplexität der Evidenzsuche "im Dunkeln" herauszufordern.

Die Autoren kommen zu dem Schluss, dass LLMs zwar in der Lese-Komprehension fortgeschritten sind, effektive Suche und Exploration jedoch die primären Flaschenhälse für die Lösung komplexer, Open-Domain-Fragen über groß angelegte Data Lakes bleiben.