7. Juli 2026
RAG ohne Vektordatenbank? Der Vectorless-Hype im Faktencheck
98.7 Prozent statt 31: Eine spektakuläre Benchmark-Zahl befeuert die These, Vektordatenbanken seien obsolet. Wir haben die Primärquellen geprüft — was am Vectorless-RAG-Ansatz real ist, wo das Marketing beginnt und was Unternehmen tatsächlich daraus ableiten sollten.
Kaum eine Architektur-Frage erreicht uns in Beratungsgesprächen derzeit so häufig wie diese: Braucht unser RAG-System überhaupt noch eine Vektordatenbank? Auslöser ist eine Zahl, die seit Monaten durch Fachmedien und Tech-Newsletter zirkuliert: 98.7 Prozent Genauigkeit auf FinanceBench, einem Benchmark für Fragen an lange Finanzdokumente — gegenüber 31 Prozent für GPT-4o mit Suche. Erreicht haben soll das ein Ansatz, der ohne Vektordatenbank, ohne Embeddings und ohne Chunking auskommt. "Vectorless RAG" heisst das Schlagwort, PageIndex das Open-Source-Projekt dahinter. Wir haben die Primärquellen geprüft. Das Ergebnis vorweg: Die Technologie ist real und für einen bestimmten Dokumententyp tatsächlich interessant. Die spektakuläre Vergleichszahl ist Herstellermarketing mit eingestandener methodischer Schieflage. Und die wichtigste Lektion für Unternehmen liegt woanders, als die Schlagzeile suggeriert.
Was hinter dem Schlagwort steckt
PageIndex ist ein Open-Source-Projekt (MIT-Lizenz, über 33'000 GitHub-Stars) der Firma VectifyAI. Der Ansatz bricht mit der Standard-Pipeline von Retrieval-Augmented Generation: Statt ein Dokument in Chunks zu zerlegen, diese als Embeddings in eine Vektordatenbank zu schreiben und bei jeder Anfrage per Ähnlichkeitssuche abzurufen, baut PageIndex aus einem PDF einen hierarchischen Baum — im Kern ein maschinenlesbares Inhaltsverzeichnis mit Knotenbeschreibungen. Bei einer Anfrage navigiert ein Sprachmodell diesen Baum per Reasoning: Es liest die Beschreibungen, entscheidet, welcher Abschnitt relevant ist, und steigt so lange ab, bis die Fundstelle lokalisiert ist. Zurück kommen Seiten- und Abschnittsreferenzen statt anonymer Text-Schnipsel.
Das adressiert eine echte Schwäche klassischer RAG-Systeme, die wir aus eigenen Projekten gut kennen: Chunking mit fixer Länge zerreisst die Struktur langer Dokumente, und semantische Ähnlichkeit ist nicht dasselbe wie Relevanz. Gerade in Finanz-, Rechts- und Normtexten tauchen dieselben Begriffe in Dutzenden Abschnitten auf — welcher davon die Antwort trägt, entscheidet die Dokumentstruktur, nicht die Wortwahl. Dass ein Retrieval, das diese Struktur respektiert, auf langen Einzeldokumenten besser abschneidet als naives Chunking, ist plausibel und deckt sich mit unserer Projekterfahrung.
Die Zahlen im Faktencheck
Die 98.7 Prozent stammen nicht vom Open-Source-Tool.
Die Zahl gehört zu Mafin 2.5, dem kommerziellen Finanz-RAG-Produkt von VectifyAI, das auf PageIndex aufbaut. Wer das GitHub-Repository installiert, betreibt nicht das System, das den Benchmark angeführt hat — das Repository verweist für komplexe PDFs selbst auf den kostenpflichtigen Cloud-Service des Herstellers. Es handelt sich zudem um eine Selbstauskunft: kein Peer-Review, keine unabhängige Replikation.
Der Vergleichswert ist nicht im selben Setup entstanden.
VectifyAI räumt im eigenen Evaluations-Repository ein, dass die Vergleichszahlen für GPT-4o (31 Prozent) und Perplexity (45 Prozent) aus fremden Quellen übernommen wurden — und dass diese Systeme nur rund zwei Drittel des Benchmarks abdeckten. Ein Vergleich "auf denselben Dokumenten" ist das gerade nicht. Der wissenschaftlich belastbare Befund ist älter und unspektakulärer: Bereits das FinanceBench-Paper von Islam et al. (2023) zeigte, dass GPT-4-Turbo mit einem naiven, geteilten Vektor-Index nur 19 Prozent der Fragen korrekt beantwortet. Dass unoptimiertes Vektor-RAG an langen Geschäftsberichten scheitert, ist seit 2023 Konsens — keine Neuigkeit.
Der Durchbruch ist keiner.
Im selben Evaluations-Repository nennt VectifyAI die spezialisierten Konkurrenzprodukte Fintool (98 Prozent) und Quantly (94 Prozent, jeweils mit Abdeckungs-Vorbehalten). Spezialisierte Finanz-RAG-Systeme — teils mit Vektor-Komponenten — liegen also alle in derselben Region. Die Erzählung "Baum schlägt Vektor um Faktor drei" entsteht erst durch die Wahl der schwächsten verfügbaren Vergleichszahl.
Der Benchmark ist eine Nische.
FinanceBench prüft in der öffentlichen Fassung 150 Fragen an lange, aber jeweils bekannte Einzeldokumente — exakt das Terrain, für das eine Baum-Navigation gebaut ist. Über die Kernfrage der meisten Unternehmens-Anwendungen — die richtige Information in einem Korpus aus hunderten oder tausenden heterogenen Dokumenten zu finden — sagt der Benchmark nichts aus.
Kosten verschwinden nicht, sie verschieben sich
"Keine Vektordatenbank, keine Embeddings" klingt nach einem schlankeren Stack. Tatsächlich tauscht der Ansatz Infrastrukturkosten gegen Inferenzkosten. Der Baumaufbau kostet ungefähr einen LLM-Aufruf pro Knoten — ein technischer Deep-Dive rechnet für einen Report mit 131 Seiten rund 137 LLM-Aufrufe allein für die Indexierung vor. Jede Abfrage benötigt anschliessend mehrere sequenzielle LLM-Aufrufe statt eines einzigen Vektor-Lookups: höhere Latenz, höhere variable Kosten. Und der Ansatz skaliert schlecht über Dokumentgrenzen hinweg: Die Baum-Navigation funktioniert innerhalb eines strukturierten Dokuments; für die korpusweite Suche bleibt Vektor-Retrieval nach heutigem Stand robuster und günstiger. Wer wöchentlich hunderte Dokumente aktualisiert, baut mit einem LLM-indexierten Baum ein Kostenproblem, kein Architektur-Upgrade.
Der valide Kern
Trotz allem steckt im Hype ein Signal, das ernst zu nehmen ist: Strukturerhaltende Indexierung schlägt naives Chunking bei langen, hierarchisch gegliederten Einzeldokumenten — Geschäftsberichte, Verträge, Normen, technische Dokumentation. Deren Gliederung trägt Information; wer sie beim Indexieren wegwirft, bezahlt beim Abrufen. Dazu kommt ein zweites, oft unterschätztes Argument: Nachvollziehbarkeit. Ein Retrieval, das Seiten- und Abschnittsreferenzen liefert, ist in regulierten Umgebungen — Finanzindustrie, Legal, Compliance, Audit — ein handfester Vorteil, weil jede Antwort bis zur Fundstelle rückverfolgbar wird.
Die Konsequenz ist aber nicht "Vektordatenbank raus", sondern hybrid: Vektor- oder Hybrid-Suche findet die relevanten Dokumente im Korpus, strukturbewusste Navigation lokalisiert die Stelle innerhalb des Dokuments. Einen erheblichen Teil des beworbenen Vorteils erreicht man sogar ganz ohne Architekturwechsel — mit strukturbewusstem Chunking entlang der Dokumentgliederung, Abschnitts-Metadaten und Parent-Document-Retrieval im bestehenden Stack.
Fünf Empfehlungen für Unternehmen
1. Keine Architekturentscheide auf Basis viraler Benchmark-Zahlen.
Drei Prüffragen genügen meist: Wer hat gemessen — Hersteller oder unabhängige Dritte? Wurden alle Systeme im selben Setup evaluiert? Ist der Benchmark repräsentativ für den eigenen Anwendungsfall? Die 98.7-Prozent-Geschichte scheitert an allen dreien.
2. Ein eigenes Evaluations-Set aufbauen.
50 bis 150 "goldene" Frage-Antwort-Paare aus echten Nutzeranfragen, gegen die jede Pipeline-Änderung gemessen wird. Ohne eigene Evaluation ist jeder Stack-Wechsel Blindflug — mit ihr werden Hype-Zyklen zu beantwortbaren Fragen. Der Aufwand ist überschaubar, der Erkenntnisgewinn dauerhaft.
3. Zuerst das Chunking verbessern, dann über den Stack-Wechsel nachdenken.
Strukturbewusstes Chunking, Dokumenthierarchie in Metadaten und Parent-Document-Retrieval holen einen Grossteil des beworbenen Vorteils in den bestehenden Vektor-Stack — für einen Bruchteil der Migrationskosten.
4. Gesamtkosten rechnen, nicht Komponenten zählen.
"Vectorless" tauscht Datenbank- und Embedding-Kosten gegen LLM-Aufrufe bei der Indexierung und bei jeder einzelnen Abfrage. Bei hoher Abfrage-Frequenz oder häufigen Dokument-Updates kippt die Rechnung schnell zugunsten der Vektoren. Massgeblich sind Kosten pro Abfrage, Indexierungskosten und Update-Frequenz — über die erwartete Laufzeit gerechnet, nicht am Demo-Tag.
5. Nachvollziehbarkeit als Anforderung formulieren.
Der stärkste Punkt des Reasoning-Ansatzes ist nicht die Benchmark-Zahl, sondern die Rückverfolgbarkeit jeder Antwort bis zur Fundstelle. Wer in regulierten Märkten arbeitet, sollte diese Eigenschaft von jeder RAG-Architektur verlangen — sie ist auch mit Vektor-Retrieval erreichbar, wenn sie von Anfang an eingeplant wird.
Fazit
PageIndex ist ein ernstzunehmender Beitrag zur RAG-Werkzeugkiste — für lange, strukturierte Einzeldokumente eine echte Alternative zu naivem Chunking. Die virale Vergleichszahl ist dagegen ein Lehrstück in Benchmark-Marketing: Hersteller-Zahl eines kommerziellen Produkts, fremde Vergleichswerte, Nischen-Benchmark, daraus abgeleitet eine Industrie-These. Vektordatenbanken werden nicht abgelöst. Unternehmen, die jetzt hektisch ihren Vektor-Stack abschalten, lösen ein Problem, das sie nicht haben — Unternehmen, die daraus lernen, ihre Retrieval-Qualität systematisch selbst zu messen, gewinnen unabhängig davon, welche Architektur sich durchsetzt.
Wir betreiben mit RAG-Wissen und DocMind eigene RAG-Systeme in Produktion und begleiten Unternehmen von der Architektur-Entscheidung über den Aufbau eigener Evaluations-Sets bis zum lauffähigen System. Wer die eigene Retrieval-Architektur — oder eine verlockende Benchmark-Story — nüchtern prüfen lassen will: Ein Erstgespräch über digital-opua.ch/kontakt dauert dreissig Minuten und kostet nichts.