Warum ein Graph zählen kann und ein Chatbot nicht

Fragen Sie einen Werksleiter, in welchen ausgelieferten Maschinen ein zurückgerufenes Teil steckt, klingt die Frage einfach. Technisch ist das gar keine Retrieval-Frage, sondern eine Mengenzugehörigkeits-Frage: Liefern Sie alles, was passt, und beweisen Sie, dass nichts fehlt. Vektorsuche wurde nie dafür gebaut, das zu beantworten, und zwei aktuelle Benchmarks messen inzwischen genau, wie deutlich sie dabei scheitert.

Eine Rangliste kennt kein „alle“

Ein Vektorindex liefert die Top-k-Textstellen, die einer Frage im Einbettungsraum am nächsten liegen, eine Liste fester Größe, per Konstruktion. Das ist das richtige Verhalten für „Finden Sie Dokumente wie dieses“. Es ist das falsche Verhalten für „Finden Sie jede Maschine, die Teil V-220 enthält“: Hat die wahre Antwortmenge 47 Mitglieder und k ist 10, weiß das System nicht, dass ihm 37 fehlen, und der Nutzer, der eine überzeugend klingende Antwort aus 10 Textstellen liest, weiß es auch nicht. Hoher Recall bei festem k ist noch keine Vollständigkeit und um Vollständigkeit geht es bei einer Zählfrage.

Die Literatur hat das bereits gemessen

Ein 2026er Benchmark, eigens dafür gebaut, AGGBench, formalisiert Aggregationsabfragen als „alle finden“, nicht „eines finden“ und berichtet für retrieval-basierte Ansätze Recall-Werte unter 0,05 bei genau dieser Aufgabe, sowohl Text-to-SQL als auch RAG scheitern an der Vollständigkeit, nicht knapp. Ein weiterer Benchmark, GlobalQA, isoliert Zählen und korpusweites Schlussfolgern gezielt und bewertet es direkt gegen eine graphstrukturierte Methode:

Keiner der beiden Werte ist in absoluten Zahlen hoch, das ist eine wirklich schwere Aufgabenklasse. Aber die Lücke ist mehr als vierfach, bei konstant gehaltenem Basismodell, gleichen Fragen und gleichem Korpus. Es ist dieselbe mechanische Grenze, mit der dieser Beitrag begann, nur gemessen. Selbst das GraphRAG-Papier (Edge et al., 2024) macht denselben Punkt aus der anderen Richtung: Es baute lokale/globale Suche eigens deshalb, weil „globale Fragen … von Natur aus eine abfragefokussierte Zusammenfassungsaufgabe sind, keine explizite Retrieval-Aufgabe“, für die flaches RAG nie gebaut wurde. Und die zugrunde liegende Schlussfolgerungslücke ist nicht neu: HotpotQA (Yang et al., 2018) zeigte bereits, dass Fragen, die mehrere verknüpfte Fakten brauchen, Ein-Schritt-Retrieval sprengen, acht Jahre bevor beide neueren Benchmarks bestätigten, dass das auch für Aggregation gilt.

Warum das kein Prompting-Problem ist

Der Reflex ist, das mit einem besseren Prompt zu lösen: „Listen Sie alle auf, seien Sie gründlich.“ Das erreicht nicht den eigentlichen Engpass. Das Modell sieht nur, was abgerufen wurde, bevor es zu generieren begann, also kann keine Anweisung im Prompt die 37 Maschinen zurückholen, die nie in den Kontext gelangten. Fragen Sie zweimal dieselbe Frage, kann sich die Rangfolge so verschieben, dass ein anderes Zehner-Set zurückkommt, das System ist also nicht nur unvollständig, es ist jedes Mal anders unvollständig. Das ist ein Problem der Retrieval-Schicht und es muss auf der Retrieval-Schicht gelöst werden.

Was ein Graph anders macht

Eine SPARQL-Abfrage über einen solchen Graphen ist keine gerankte Shortlist, sie ist eine Traversierung: Liefere jeden Knoten, der zu diesem Muster passt, egal wie viele es sind. Fragen Sie „welche Maschinen enthalten V-220“, ist die Antwort der Join aus Stücklisten-Graph und Lieferdaten, alle 47 Zeilen oder keine, mit einem Abfrageplan, den Sie prüfen können, falls die Zahl nicht plausibel wirkt. Nichts davon macht Vektorsuche überflüssig, „Fassen Sie die Rückrufmeldung zusammen“ ist weiterhin eine gute RAG-Frage. Aber „Listen Sie jede betroffene Maschine auf“ war nie ein Rankingproblem und keine noch so gute Retrieval-Feinabstimmung ändert, welche Art von Frage das ist.