retrieval-augmented-gen llm vector-database python rag agents

PageIndex: Vektorloses, auf Logik basierendes RAG mit Baumindex

PageIndex ersetzt die Vektordatenbank durch einen von einem LLM gesteuerten Baumindex. Wie dieses auf Logik beruhende RAG-Verfahren funktioniert – mit Python-Code, einer MCP-Verbindung sowie Vergleichszahlen.

Verlag: REACTAPP.TOPAuf dieser Website hinzugefügt 28. Okt. 202614 Min. Lesezeit3118 Wörter

Quellen: PageIndex: The RAG Framework That Threw Out Vector Databases and Still Hit 98.7% Accuracy

Stellen Sie sich ein RAG-Framework vor, das Vektordatenbanken völlig weglässt und anschließend ein Benchmark-Ergebnis präsentiert, dem kein system basierend auf Embeddings nahekommt. Das ist PageIndex, ein Open-Source-Projekt von VectifyAI. Auf FinanceBench, dem Standard-Benchmark für die Fragebeantwortung anhand finanzieller Dokumente, erreichen herkömmliche RAG-Systeme basierend auf Vektoren Werte von etwa 30 bis 50 Prozent. PageIndex weist hingegen 98,7 Prozent auf. Dazu kam es nicht durch ein besseres Embedding-Modell, sondern durch das Weglassen von Embeddings.

Dieses Ergebnis verdient eine genaue Betrachtung, denn die Fragebeantwortung anhand von SEC-Unterlagen gehört zu den schwierigsten Suchaufgaben in der praktischen KI. Sie erfordert mehrstufiges Denken, Sprünge zwischen Abschnitten sowie genaue Zahlen. Das beste System, das bisher verfügbar ist, verwendet weder Vektoren noch Chunking noch Vektordatenbanken.

Hier erfahren Sie, was PageIndex leistet, wie es aufgebaut ist, wie der funktionierende Python-Code aussieht, wo es hervorragt und wo nicht.

Die Wand, auf die lange Dokumente prallen

Jeder, der RAG für Inhalte entwickelt hat, die länger sind als ein Blogbeitrag, kennt dieses Problem. Ein Benutzer fragt ein auf einem 200-seitigen Jahresbericht basierendes System, wie sich die Gesamteinnahmen im Haushaltsjahr 2024 im Vergleich zu 2023 verhalten. Der Standardablauf sieht wie folgt aus:

Das Dokument in Blöcke fester Größe aufteilen, in der Regel 300 bis 500 Token.
Jeden Block mit einem Modell wie text-embedding-3-large verarbeiten.
Die Vektoren in Pinecone, Weaviate, Milvus, Chroma, pgvector oder ähnlichen Systemen speichern.
Zur Abfragezeit die Frage verarbeiten und die k-k nächsten Vektoren anhand der Kosinusähnlichkeit abrufen.
Diese Blöcke an das LLM weiterleiten, um die Antwort zu erstellen.

Für kurze, unstrukturierte Inhalte wie Blogbeiträge, Supportanfragen und Produktdokumente funktioniert das hervorragend. Ein 10-K-Bericht bricht die Struktur jedoch auf vorhersehbare Weise auf.

Die Abfrage sieht nicht wie die Antwort aus. Bei der Vektorabfrage wird angenommen, dass der Text, der der Abfrage am ähnlichsten ist, am relevantesten ist. Doch eine Abfrage drückt eine Absicht aus, nicht den Inhalt. Eine Frage zu Umsatztrends zeigt nicht die Zeile in Tabelle 47 an, sondern jeden Absatz, der über Umsätze berichtet.

Ein Begriff, sechzig Stellen. In einem langen Jahresbericht kommt „Betriebsgewinn“ in verschiedenen Kontexten Dutzende Male vor. Die Ähnlichkeitsberechnung stuft sie mehr oder weniger gleich ein, sodass der Abschnitt, der die Frage tatsächlich beantwortet, möglicherweise nie zu den drei besten gehört.

Chunking verfälscht Tabellen. Ein Tabellenkopf landet im Chunk 14 und die gewünschte Zeile im Chunk 15. Keiner von beiden ergibt für sich genommen Sinn. Überlappende Fenster, semantisches Chunking sowie tabellenbewusste Parser helfen zwar, lösen aber das zugrunde liegende Problem nicht.

Kein Gedächtnis über verschiedene Anfragen hinweg. Wenn die vorherige Nachricht nach Vermögenswerten fragte und die nächste „Was ist mit Verbindlichkeiten?“ fragt, betrachtet das Retrieval-System dies als eine völlig neue Anfrage. Es gibt keine Anhaltspunkte dafür, dass der Benutzer vermutlich auf denselben Abschnitt derselben Berichterstattung anspielt.

Querverweise bleiben verborgen. Angenommen, Seite 12 verweist die Leser auf Anhang G, der sich auf Seite 87 befindet. Der Text des Anhangs weist keine semantische Überschneidung mit der ursprünglichen Frage auf, weshalb das Vector RAG-System den Verweis niemals verfolgen wird. Das Einfügen von Querverweismetadaten in die Datenblöcke ist eine Workaround-Lösung, ist jedoch anfällig und nicht skalierbar.

Das sind keine seltenen Randfälle – sie resultieren aus der Architektur selbst. Wie Mingtian Zhang, Mitbegründer von VectifyAI, in der Projektankündigung sagte, benötigt das Retrieval eigentlich Relevanz, und Relevanz erfordert Schlussfolgerungsvermögen.

Was PageIndex ist

PageIndex ist ein vektorloses, auf Logik basierendes RAG-Framework, das im September 2025 von VectifyAI veröffentlicht wurde und von Zhang sowie Yu Tang entwickelt wurde. Es ist unter der MIT-Lizenz verfügbar, und der Repository wuchs schnell – Ende März 2026 hatte es bereits 23.000 „Stars“ sowie fast 2.000 „Forks“ erreicht.

Die zentrale Idee stammt von AlphaGo. Anstatt einen Raum gründlich zu durchscannen, wobei die Vektorähnlichkeit jeden Abschnitt vergleicht, wird hier eine gelernte Strategie eingesetzt, um intelligent voranzukommen. PageIndex wendet dieses Prinzip auf Dokumente an und weist drei bemerkenswerte Eigenschaften auf:

Keine Vektordatenbank. Die Dokumentstruktur sowie das logische Denken von Large Language Models ersetzen die Ähnlichkeitssuche – es gibt daher weder Pinecone noch Chroma noch Embeddings.
Kein Chunking. Dokumente bleiben als natürliche Abschnitte, Kapitel, Absätze und Tabellen organisiert, anstatt in willkürlichen 500-Token-Fenstern.
Navigation im menschlichen Stil. Es verhält sich wie eine Person, die manuell in einem Dokument sucht: Man schaut sich den Inhaltstext an, findet den Abschnitt, der wahrscheinlich die Antwort enthält, und liest ihn.

Die Methode besteht aus zwei Schritten.

Schritt 1: ein hierarchischer Baumindex

Durch die Einpflege eines Dokuments entstehen keine Embeddings. PageIndex analysiert die Struktur des Dokuments und erzeugt einen hierarchischen Baum – im Grunde einen für LLMs geeigneten Inhaltstext. Jeder Knoten enthält einen Titel, eine kurze Zusammenfassung des Abschnitts, einen Seitenbereich sowie Kindknoten für Unterkapitel, die so tief verschachtelt werden können, wie es nötig ist.

Ein 50-seitiges SEC-Dokument kann einen Baum mit 30 bis 50 Knoten ergeben, der als ein einziges JSON-Objekt gespeichert wird. Nichts befindet sich in einer Vektordatenbank – es handelt sich ausschließlich um JSON. Das gesamte Objekt passt in ein einziges Kontextfenster eines LLMs, und man kann jeden Knoten öffnen und lesen. Ein Knoten sieht so aus:

{
  "node_id": "0006",
  "title": "Financial Stability",
  "start_index": 21,
  "end_index": 22,
  "summary": "Covers the Federal Reserve's financial stability oversight...",
  "sub_nodes": [
    {
      "node_id": "0007",
      "title": "Monitoring Financial Vulnerabilities",
      "start_index": 22,
      "end_index": 28,
      "summary": "Describes the Fed's vulnerability monitoring framework..."
    },
    {
      "node_id": "0008",
      "title": "Domestic and International Cooperation",
      "start_index": 28,
      "end_index": 31,
      "summary": "Federal Reserve collaboration with international bodies..."
    }
  ]
}

Jeder node_id verweist auf den Rohinhalt jener Abschnitt: Texte, Tabellen und Bilder. Das LLM kann den Inhalt jedes Nodes anfordern, wenn es ihn benötigt.

Der architektonische Clou liegt darin, wo dieser Index gespeichert ist. Eine Vektordatenbank führt einen separaten, statischen Index der Embeddings außerhalb des Modells. Hier befindet sich der JSON- Baum innerhalb des aktiven Kontexts des LLM während der Inferenz. VectifyAI bezeichnet dies als In-Context-Index – das Modell fragt ihn nicht nur ab, sondern arbeitet auch in Echtzeit mit ihm.

Schritt 2: durch Schlussfolgerungen gesteuerte Baumsuche

Wenn eine Frage eintrifft, gibt PageIndex dem LLM den Baum – ausschließlich mit Titeln und Zusammenfassungen, ohne Rohtext – und fragt im Grunde, wo man anhand dieser Struktur und dieser Frage suchen soll. Das Modell liest die Knotentitel und Zusammenfassungen, beurteilt, welche Abschnitte wahrscheinlich die Antwort enthalten, und gibt eine Liste der Knoten IDs zurück. Das System lädt anschließend den tatsächlichen Inhalt dieser Knoten herunter.

Die Informationsabrufung erfolgt in einem Zyklus:

Scannen Sie den Inhaltstext, um die Gliederung zu verstehen und mögliche Abschnitte zu identifizieren.
Wählen Sie einen Abschnitt, der am ehesten das Gewünschte enthält.
Lesen Sie ihn und holen Sie den Rohtext aus diesem Knoten ab.
Prüfen Sie, ob das ausreicht. Falls ja, schreiben Sie die Antwort. Falls nein, kehren Sie zum ersten Schritt zurück und versuchen Sie es mit einem anderen Abschnitt.

Das ist ein anderes Paradigma als die Vektorsuche. Eine Vektordatenbank berechnet die Kosinusähnlichkeit für jeden Datenblock parallel – was schnell, aber oberflächlich ist. PageIndex hingegen lässt das LLM darüber nachdenken, wo sich die Antwort wahrscheinlich befindet. Dabei kann das Modell Querverweise verfolgen, erkennen, dass eine Frage zu Appendix-Daten zum entsprechenden Appendix-Node gehört, und feststellen, dass eine mehrteilige Frage Inhalte aus zwei Abschnitten benötigt. Jeder Schritt hinterlässt außerdem einen Nachvollziehungsverlauf, sodass man sehen kann, welche Knoten besucht wurden und warum. Die Informationsabrufung ist somit nicht mehr eine Black Box.

Das Beispiel Appendix G

Eine auf der MCP-Integration von VectifyAI basierende Demo zeigt, warum das wichtig ist. Jemand fragt nach der Gesamtsumme der aufgeschobenen Vermögenswerte in einem Jahresbericht der Federal Reserve. Der Hauptteil auf den Seiten 75 bis 82 behandelt die Veränderung der aufgeschobenen Vermögenswerte, gibt aber nie die Gesamtsumme an. Auf Seite 77 steht jedoch ein Satz, der besagt, dass Tabelle 5.3 Einnahmen, Ausgaben und Verteilungen zusammenfasst und dass Anhang G detailliertere Informationen liefert.

Vector RAG steckt hier fest. Anhang G ist eine Tabellensammlung von Zahlen, die keinerlei semantische Ähnlichkeit mit einer Frage zu aufgeschobenen Vermögenswerten aufweist, weshalb die Datenbank ihn ignoriert. PageIndex verhält sich anders. Der LLM liest den Baum, geht zur Finanzabteilung, findet die Verweisung auf Anhang G, folgt ihr durch den Baum, holt die richtige Tabelle ab und gibt die genaue Zahl zurück, wobei der Nachvollziehungsverlauf jeden Schritt zeigt.

Python, von Anfang bis Ende

Der untenstehende Code ist aus dem offiziellen PageIndex-Kochbuch übernommen, wobei Kommentare den Ablauf veranschaulichen. Beginnen Sie mit der Installation:

pip install pageindex openai

Importe:

import os
import json
import asyncio
from pageindex import PageIndexClient
from openai import AsyncOpenAI

Dann die Anmeldeinformationen und Clients. Ein API-Schlüssel stammt vom PageIndex-Dashboard:

# Grab an API key from https://dash.pageindex.ai/api-keys
PAGEINDEX_API_KEY = os.environ["PAGEINDEX_API_KEY"]
OPENAI_API_KEY = os.environ["OPENAI_API_KEY"]pi_client = PageIndexClient(api_key=PAGEINDEX_API_KEY)
openai_client = AsyncOpenAI(api_key=OPENAI_API_KEY)

Baue den Baum

Füge die Hilfsprogramme hinzu:

import pageindex.utils as utils

Laden Sie ein PDF hoch und lassen Sie PageIndex den Baum erstellen. Das Indizieren dauert etwas, daher prüft das Skript kontinuierlich, bis es fertig ist, und gibt das Ergebnis aus:

# Upload a PDF; PageIndex handles the tree generation
doc = pi_client.upload("annual_report_2024.pdf")
doc_id = doc["doc_id"]# Tree generation takes a bit, so we poll
while not pi_client.is_retrieval_ready(doc_id):
    print("Still indexing...")
    import time; time.sleep(5)# Grab the tree and take a look
tree = pi_client.get_tree(doc_id, node_summary=True)["result"]
print("Document Tree:")
utils.print_tree(tree)

Der Ausdruck zeigt jeden Abschnitt, jede Unterabschnitt und jeden Seitenbereich an, wodurch sofort klar wird, ob der Baum die Gestaltung korrekt erfasst hat.

Lassen Sie den LLM den Baum durchsuchen

Das ist der zentrale Schritt. Die Funktion erhält den Baum sowie eine Abfrage:

async def find_relevant_nodes(tree: dict, query: str) -> list:
    """LLM reasons over tree structure to identify relevant nodes."""

Im Inneren wird der Rohtext entfernt, um Tokens zu sparen, da das Modell nur Titel und Zusammenfassungen benötigt. Die Anweisung stellt das Modell als Experten für Dokumentensuche dar, weist es an, Kreuzverweise zu befolgen, und bittet um JSON mit seiner Begründung sowie einer Liste der Node-IDs:

    # Strip raw text to save tokens; the LLM only needs titles and summaries
    tree_without_text = utils.remove_fields(
        tree.copy(), fields=["text"]
    )    search_prompt = f"""
    You are a document retrieval expert. Given a question and
    a hierarchical tree structure of a document, identify all
    nodes likely to contain the answer.    Each node has a node_id, title, and summary.
    Follow cross-references if a section mentions another.    Question: {query}    Document tree structure:
    {json.dumps(tree_without_text, indent=2)}    Reply in this JSON format only:
    {{
        "thinking": "<reasoning about which nodes are relevant>",
        "node_list": ["node_id_1", "node_id_2"]
    }}
    """    response = await openai_client.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": search_prompt}],
        temperature=0,
        response_format={"type": "json_object"},
    )    result = json.loads(response.choices[0].message.content)
    print(f"LLM reasoning: {result['thinking']}")
    return result["node_list"]

Inhalt abrufen und beantworten

Die nächste Funktion sammelt den Rohtext für die ausgewählten Knoten:

def collect_node_content(tree: dict, node_ids: list) -> str:
    """Pull raw text from the nodes the LLM selected."""
    all_nodes = utils.flatten_tree(tree)
    context_parts = []

Dann erstellt der Schleifenkörper den Kontext, wobei jeder Abschnitt mit einem Titel und einem Seitenbereich versehen wird, und der gesamte Ablauf umfasst außerdem das Auswählen von Knoten, das Herunterladen von Inhalten, die Erstellung einer Antwort mit Quellenangaben sowie die Rückgabe der Antwort zusammen mit den verwendeten Knoten.

    for node in all_nodes:
        if node["node_id"] in node_ids:
            title = node.get("title", "Untitled")
            pages = f"pages {node.get('start_index', '?')}-{node.get('end_index', '?')}"
            text = node.get("text", "")
            context_parts.append(
                f"[{title} | {pages}]\n{text}"
            )
    return "\n\n---\n\n".join(context_parts)
async def answer_query(tree: dict, query: str) -> dict:
    """Full vectorless RAG pipeline: tree search + answer generation."""    # Step 1: LLM picks the nodes
    node_ids = await find_relevant_nodes(tree, query)    # Step 2: Fetch content from those nodes
    context = collect_node_content(tree, node_ids)    # Step 3: Generate answer with citations
    answer_prompt = f"""
    Answer the question using only the provided context.
    Cite specific pages and sections in your answer.    Context:
    {context}    Question: {query}
    """    response = await openai_client.chat.completions.create(
        model="gpt-4.1",
        messages=[{"role": "user", "content": answer_prompt}],
        temperature=0,
    )    return {
        "answer": response.choices[0].message.content,
        "retrieved_nodes": node_ids,
        "context_length": len(context),
    }
# Run it
query = "What was the total value of deferred assets in 2023?"
result = asyncio.run(answer_query(tree, query))
print(result["answer"])
print(f"Nodes used: {result['retrieved_nodes']}")

Anschluss an MCP

Für Claude, Cursor oder jeden MCP-kompatiblen Agenten verbindet PageIndex sich direkt über einen gehosteten Server:

{
  "mcpServers": {
    "pageindex": {
      "type": "http",
      "url": "https://api.pageindex.ai/mcp",
      "headers": {
        "Authorization": "Bearer your_api_key"
      }
    }
  }
}

Es existiert außerdem ein lokaler MCP-Server zum Hochladen von Dateien von der Festplatte, und er erfordert Node.js 18 oder neuer:

{
  "mcpServers": {
    "pageindex": {
      "command": "npx",
      "args": ["-y", "@pageindex/mcp"]
    }
  }
}

Die Zahlen im Kontext

Die Hauptzahl stammt von FinanceBench, das auf tatsächlichen SEC-Unterlagen wie 10-Ks, 10-Qs und 8-Ks zurückgreift und nur exakte Antworten zulässt. Mafin 2.5, VectifyAI’s Finanzanalyse-Tool, das auf PageIndex basiert, wurde anhand des vollständigen Datensatzes getestet. Berichtete Genauigkeit:

System	Genauigkeit	Benchmark-Coverage
Mafin 2.5 (PageIndex)	98,7%	100%
Traditionelles Vektor-RAG	etwa 50%	variiert
GPT-4o ohne RAG	etwa 31%	100%
Perplexity	etwa 45%	variiert

Ein Unterschied von rund 49 Prozentpunkten gegenüber herkömmlichem Vektor-RAG ist keine geringe Verbesserung – es handelt sich dabei um eine völlig andere Kategorie von Ergebnissen. Drei Faktoren tauchen immer wieder auf:

Verfolgung von Querverweisen. In-Dokument-Verweise wie „siehe Anhang G“ werden über den Baum navigiert. Eine Ähnlichkeitssuche kennt sie nicht.
Erhalt der Struktur. Tabellen haben Überschriften, Fußnoten und Zellbeziehungen. PageIndex bewahrt diese als Baumknoten, während das Aufteilen in Blöcke sie zerstört.
Mehrschrittiges Denken. Eine Frage, die FY2023 mit FY2024 vergleicht und in verschiedenen Teilen der Dokumentation vorkommt, wird durch den iterativen Loop natürlich bearbeitet.

Wo es nachlässt

PageIndex ist für seinen Nischenbereich beeindruckend, ersetzt aber nicht überall Vektor-RAG.

Es ist langsamer. Jeder Abruf beinhaltet mehrere Aufrufe von LLMs: Lesen des Index, Überlegen zu Knoten, Abrufen des Inhalts, Überprüfen der Ausreichendheit, möglicherweise Wiederholung des Vorgangs. Vector RAG antwortet in Millisekunden, PageIndex in Sekunden. Der Mitbegründer hat festgestellt, dass da der Abruf während der Generierung inline stattfindet, die Zeit bis zum ersten Token mit einer normalen LLM-Aufruf vergleichbar sein kann, die Gesamtlatenz jedoch weiterhin höher ist.
Es kostet mehr. Mehrere Inferenzaufrufe pro Abfrage im Vergleich zu einem einzigen Embedding-Aufruf. Bei hohem Volumen werden die Kosten unangemessen hoch.
Es ist für Tiefe, nicht für Breite konzipiert. Es zeichnet sich durch tiefgehende Extraktion aus einem langen Dokument aus. Das Durchsuchen von 10.000 kurzen Dokumenten gleichzeitig ist der Bereich, in dem Vektordatenbanken ihre Berechtigung haben – für jedes Dokument einen Baum aufzubauen und darüber zu reasoningen ist nicht praktikabel.

Die Struktur ist wichtig. Eine ordentlich formatierte SEC-Datei ergibt einen hervorragenden Strukturbaum. Eine schlecht formatierte Scan-Datei ohne logische Abschnitte führt zu einem minderwertigen Inhaltstabelle, wodurch alles danach beeinträchtigt wird. Für solche Fälle gibt es einen bildbasierten Modus, doch strukturierte Dokumente bleiben weiterhin die beste Wahl.

Auch das Schlussfolgern von LLMs ist unvollkommen. Vector RAG funktioniert nicht richtig, weil Embeddings die Bedeutung nur annähernd wiedergeben. PageIndex funktioniert fehlerhaft, wenn das Schlussfolgern nur ungenau ist: Das Modell kann zum falschen Abschnitt wechseln, eine Zusammenfassung falsch interpretieren oder einen relevanten Unterpunkt überspringen. Diese Fehler sind leichter interpretierbar und vermutlich einfacher zu beheben, treten aber dennoch auf.

Ein einziger Benchmark. FinanceBench misst die Qualität der Prüfung gut strukturierter SEC-Unterlagen. Ergebnisse für unübersichtliche, mehrdomänige, mehrdeutige Abfragen bei sehr unterschiedlichen Dokumenttypen wurden nicht in demselben Maße unabhängig überprüft. Der Wert von 98,7 Prozent ist real, doch es ist wichtig zu wissen, was damit gemessen wird.

Wann es verwenden

Wählen Sie PageIndex, wenn:

die Dokumente lang, strukturiert und professionell sind: Jahresberichte, Verträge, regulatorische Unterlagen, technische Handbücher
Genauigkeit wichtiger ist als Geschwindigkeit – beispielsweise, wenn eine falsche Antwort Geld kostet oder Compliance-Risiken verursacht
die Abfragen mehrstufiges Denken oder den Wechsel zwischen Abschnitten erfordern
Ihnen Audit-Spuren benötigt werden, da jede Antwort mit einer Nachvollziehbarkeit und Referenzen zu Knotenpunkten geliefert wird, was in regulierten Branchen geschätzt wird

Bleiben Sie bei vector RAG, wenn:

bei hohem Anfragenvolumen sind antwortzeitnahe Ergebnisse innerhalb von Sekundenbruchteilen erforderlich
es werden große Mengen an kurzen Dokumenten durchsucht
die Dokumente sind unstrukturiert oder im Gesprächsstil verfasst
90 Prozent Genauigkeit reichen aus
die Kosten pro Anfrage stellen die Hauptbeschränkung dar

Eine hybride Lösung wurde vermutlich noch nicht ausreichend erforscht. Verwenden Sie die Vektorsuche, um herauszufinden, welches Dokument in einem großen Korpus relevant ist, und übergeben Sie es anschließend an PageIndex für eine detaillierte Auswertung.

Was gibt es seit dem Start Neues?

Seit September 2025 hat sich das Projekt rasant weiterentwickelt.

Agent-basiertes, vektorloses RAG. Die neueste Erweiterung integriert einen selbst gehosteten PageIndex in das OpenAI Agents SDK. Dem Agenten werden drei Tools (get_document(), get_document_structure() und get_page_content()) zur Verfügung gestellt, und er analysiert den Baum selbstständig, ruft die richtigen Tools auf und holt den Inhalt ab, ohne manuelle Auswahl von Knoten vorzunehmen. Dies ist das Vorbild für agentbasierte Arbeitsabläufe:

pip install openai-agents
python3 examples/agentic_vectorless_rag_demo.py

Bildbasiertes Modus ohne OCR. Ein auf Bildverarbeitung ausgelegter Prozessschritt überspringt nun das OCR. Die Seitenbilder gelangen direkt an ein Modell, das auf Bildern arbeitet, und der Baum wird aus dem erstellt, was dieses Modell auf der Seite erkennt. Für Finanzdokumente, bei denen die Anordnung eines Bilanzblatts genauso viel Bedeutung hat wie der Text, ist das von großer Bedeutung. Diagramme, Tabellen mit verschmolzenen Zellen und Fußnoten bleiben vollständig erhalten, da nichts zuerst in Text umgewandelt wird.

Ein TypeScript SDK, pageindex-js-sdk, wurde Anfang 2026 für Node.js-Integrationen und webbasierte Dokumentenwerkzeuge veröffentlicht. Eine ein-Klick-.mcpb-Desktop-Erweiterung installiert PageIndex in Claude Desktop, wobei die OAuth-Verwaltung automatisch abgewickelt wird. ChatIndex, ein separates Repository seit Januar 2026, wendet dieselbe Baumindexierungsidee auf lange Konversationshistorien an.

Der größere Wandel

PageIndex repräsentiert einen weiteren Schritt weg von der passiven Suche, bei der alles Ähnliche abgerufen wird, hin zu einer aktiven, proaktiven Suche, die überlegt, wo gesucht werden soll. Dies ist bereits in Programmierwerkzeugen zu erkennen. Claude Code und Cursor haben sich von der auf Vektoren basierenden RAG-Technologie für Code abgewandt und stattdessen die aktive Erkundung des Codebases bevorzugt; das Team hinter PageIndex erwartet, dass auch Dokumente diesem Ansatz folgen werden. Bei strukturierten Dokumenten erscheint diese Prognose plausibel.

Vektordatenbanken werden nicht verschwinden. Sie sind schnell, günstig und ausreichend gut für eine breite Palette von Anwendungen. Doch dort, wo Genauigkeit, Transparenz und ein tiefes Verständnis der Dokumente unverzichtbar sind – wie bei Finanzaudits, rechtlichen Ermittlungen, Krankenakten oder regulatorischen Anforderungen – ist eine auf Schlussfolgerungen beruhende Suche grundsätzlich besser geeignet.

Der Code sowie die Dokumente befinden sich unter https://github.com/VectifyAI/PageIndex, die Dokumentation unter https://docs.pageindex.ai/.