RAG am Limit: Warum Pageindex zeigt, wo klassische Vektorsuche scheitert

Was diese Woche passiert ist

Golem hat am 12. Mai einen ausführlichen Ratgeber zu Pageindex veröffentlicht – einem Ansatz für strukturiertes Dokumentenverständnis, der bewusst nicht auf klassische Vektorsuche setzt. Stattdessen erschließen Agenten die Dokumente, ähnlich wie ein Mensch ein Inhaltsverzeichnis nutzt: erst grob navigieren, dann gezielt in den relevanten Abschnitt eintauchen.

Der Hintergrund: Retrieval-Augmented Generation (RAG) ist seit zwei Jahren der Standard-Baustein für „KI auf eigenen Dokumenten”. Dokumente werden in kleine Chunks zerschnitten, in Vektoren umgewandelt, in einer Vektordatenbank abgelegt. Bei einer Frage holt das System die ähnlichsten Chunks und übergibt sie dem LLM. Funktioniert in Demos hervorragend. In der Praxis – und das ist der Punkt, an dem der Golem-Artikel ansetzt – häufig nicht.

Pageindex dreht die Logik um. Statt blind nach semantischer Ähnlichkeit zu suchen, baut das System eine baumartige Struktur des Dokuments auf. Der Agent entscheidet dann pro Frage, in welchen Ast er navigiert. Das klingt nach mehr Overhead, liefert laut Pageindex aber bei strukturierten Dokumenten wie Verträgen, technischen Handbüchern oder Geschäftsberichten deutlich bessere Treffer.

Warum das jetzt für KMU zählt

Ich sehe in der Beratungspraxis dasselbe Muster immer wieder: Ein Unternehmen startet ein RAG-Projekt, weil „die KI soll unsere Dokumente kennen”. Nach drei Monaten und 15.000 bis 40.000 Euro Investment kommt die Ernüchterung. Das System findet bei einfachen Fragen die richtige Antwort. Sobald die Frage aber Kontext über mehrere Abschnitte hinweg braucht, halluziniert es oder zitiert die falsche Klausel.

Die typischen Schwachstellen klassischer RAG-Setups:

• Chunking zerreißt Zusammenhänge. Eine Vertragsklausel verweist auf eine Definition zwei Seiten vorher. Der Chunk mit der Klausel kennt die Definition nicht.
• Vektorsuche findet semantisch Ähnliches, nicht logisch Richtiges. Bei der Frage „Welche Kündigungsfrist gilt für Vertrag XY?” liefert sie gerne die Kündigungsklausel aus dem Mustervertrag, nicht aus dem konkreten.
• Strukturinformation geht verloren. Ob ein Absatz in „Ausnahmen” oder „Hauptregeln” steht, ist für die Bedeutung entscheidend – Embeddings sehen das nicht.
• Tabellen und Listen werden zerstückelt. Eine Preistabelle, in zehn Chunks zerlegt, ist hinterher keine Preistabelle mehr.

Für KMU mit überschaubaren Dokumentenmengen – sagen wir, ein paar hundert bis wenige tausend Dokumente – sind agentenbasierte Ansätze wie Pageindex aus meiner Sicht oft die bessere Wahl. Der Grund ist pragmatisch: Sie brauchen keine Vektordatenbank, keine Embedding-Pipeline, kein Re-Ranking-Modell. Sie brauchen einen guten Index, eine sinnvolle Strukturierung und ein LLM, das durch das Dokument navigieren kann.

Der Trade-off ist real: Agentenbasierte Suche braucht mehr LLM-Calls pro Anfrage, ist also teurer und langsamer als ein Vektor-Lookup. Bei 50 Anfragen pro Tag in einer KMU-Wissensbasis spielt das keine Rolle. Bei 50.000 Anfragen pro Tag in einem Kundenportal schon.

Mein Rat: Drei Schritte für KMU mit RAG-Projekt

1. Ehrliche Bestandsaufnahme, falls Sie bereits ein RAG-System haben.

Nehmen Sie 50 echte Nutzerfragen aus dem letzten Monat. Lassen Sie zwei Personen aus dem Fachbereich – nicht aus IT – die Antworten bewerten: korrekt, teilweise korrekt, falsch, halluziniert. Wenn die Quote „korrekt” unter 70 Prozent liegt, ist das System nicht produktiv einsetzbar, egal was das Dashboard sagt. Häufiges Muster: Geschäftsführung glaubt, das System funktioniere, weil die IT zufrieden ist. Die Fachabteilung umgeht es längst.

2. Bevor Sie das Modell tauschen, prüfen Sie die Dokumentenstruktur.

Der häufigste Fehler in KMU-RAG-Projekten ist nicht das falsche LLM. Es ist Müll-Input. PDFs, die aus gescannten Faxen entstanden sind. Word-Dokumente mit zwölf Versionen im selben Ordner. Excel-Sheets, in denen die Überschrift in Zeile 7 steht. Bevor Sie über Pageindex, Vektor-Alternativen oder Modellwechsel nachdenken: Räumen Sie auf. Strukturierte, sauber benannte, mit Metadaten versehene Dokumente lösen mehr Probleme als jeder Architekturwechsel.

3. Bei Neuprojekten: klein anfangen, Architektur offen halten.

Ich rate KMU aktuell dazu, RAG-Projekte nicht mit einer fertigen Vektordatenbank-Lösung zu starten, sondern mit einem konkreten Use Case und maximal 100 Dokumenten. Bauen Sie zwei Prototypen parallel: einen klassischen RAG-Ansatz und einen agentenbasierten wie Pageindex oder eine eigene Tree-Search-Implementierung. Vergleichen Sie an denselben 30 Testfragen. Der Aufwand für diesen Doppelbau liegt bei 5.000 bis 8.000 Euro – und erspart Ihnen mit hoher Wahrscheinlichkeit ein gescheitertes 30.000-Euro-Projekt.

Wichtig: Pageindex ist nicht die einzige Antwort. GraphRAG von Microsoft, hybride Ansätze mit Knowledge Graphs, agentische Retrieval-Frameworks wie LlamaIndex Workflows – der Markt bewegt sich gerade weg vom Dogma „Vektorsuche löst alles”. Wer 2024 oder Anfang 2025 ein RAG-System gebaut hat, sollte 2026 ernsthaft prüfen, ob die Architektur noch passt.

Was ich nicht empfehle

Den Sprung „weg von RAG, hin zu Long-Context-LLMs”. Ja, GPT-5.5 und Gemini verarbeiten heute mehrere Millionen Tokens. Nein, das ersetzt keine Dokumentensuche bei mehreren hundert Dokumenten. Die Kosten pro Anfrage explodieren, die Antwortqualität bei sehr langem Kontext ist nachweislich schlechter als bei gezieltem Retrieval, und die Latenz wird für Anwender unzumutbar. Long-Context ist ein Werkzeug für einzelne große Dokumente, kein Architekturmuster für Wissensbasen.

Fazit

Der Pageindex-Artikel ist kein Hype-Stück, sondern ein nüchterner Hinweis darauf, dass die RAG-Architektur, die wir seit 2023 gebaut haben, nicht für alle Anwendungsfälle taugt. Für KMU heißt das: Wenn Ihr RAG-Projekt frustriert, liegt es selten am LLM. Es liegt am Ansatz – und der ist überprüfbar. Wer jetzt einen Schritt zurücktritt und die Architektur hinterfragt, spart sich in den nächsten zwölf Monaten viel Geld und Frust.