Vektorloses RAG: Wie PageIndex Dokumente ohne Embeddings liest
Vectorloses RAG mit PageIndex: Warum die in Blöcken durchgeführte Vektorsuche im Kontext langer Berichte versagt und wie ein auf Schlussfolgerungen basierender Baumindex die Antwort findet – mit Code.
Quellen: I Deleted My Vector Database and My RAG System Got Better
Fragen Sie jemanden, was in Kapitel 7 passiert ist – er wird das ganze Buch nicht noch einmal lesen. Er wird den Inhaltstext öffnen, direkt zu Kapitel 7 springen und nur diesen Teil lesen. Das ist schnell und genau.
Die meisten KI-basierten Dokumentensuchsysteme funktionieren ganz anders. Sie teilen den Text in willkürliche Abschnitte auf, wandeln jeden Abschnitt in Zahlen um und vergleichen die Frage mit den Zahlen, die am nächsten liegen. Manchmal ist das in Ordnung. Manchmal erstreckt sich die Antwort über die Grenze eines Abschnitts, ohne dass das System sie wahrnimmt. Ein neuerer Ansatz namens vectorless RAG verzichtet auf dieses Zahlenverfahren und lässt das Modell die Struktur eines Dokuments genauso lesen wie ein Mensch. Berichten zufolge erreichte er bei einem schwierigen Finanztest 98,7 %, während herkömmliche Verfahren kaum 50 % schafften. Was folgt, erklärt dieses Ergebnis Schritt für Schritt aus den Grundlagen.
Was RAG leistet
RAG steht für retrieval-augmented generation. In der Praxis bedeutet das, einem Modell Zugang zu Ihren eigenen Dokumenten zu geben, sodass seine Antworten aus Ihren Daten stammen und nicht nur aus der Trainingsdatenbasis.
Das ist wichtig, weil Modelle wie GPT oder Claude eine Wissensgrenze haben. Sie haben niemals die internen Berichte, rechtlichen Verträge oder medizinischen Unterlagen einer bestimmten Organisation gesehen. RAG schließt diese Lücke, indem es relevante Abschnitte abruft und sie dem Modell unmittelbar vor der Antwort zur Verfügung stellt. Die Versprechen sind einfach: Man stellt eine Frage und erhält eine Antwort, die auf den eigenen Materialien beruht. In der Realität wird es jedoch komplizierter.
Die brute-force-Methode
Der offensichtlichste Ansatz besteht darin, das gesamte Dokument zusammen mit der Frage in den Prompt einzufügen und das Modell damit arbeiten zu lassen. Keine Datenbanken, keine komplizierten Mechanismen.
from openai import OpenAI
import PyPDF2
client = OpenAI(api_key="your-api-key")
# Extract all text from a PDF
def extract_pdf_text(pdf_path):
reader = PyPDF2.PdfReader(pdf_path)
full_text = ""
for page in reader.pages:
full_text += page.extract_text() + "\n"
return full_text
document_text = extract_pdf_text("annual_report.pdf")
user_question = "What was the total revenue in 2024?"
response = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "Answer based on the provided document."},
{"role": "user", "content": f"Document:\n{document_text}\n\nQuestion: {user_question}"}
]
)
print(response.choices[0].message.content)
Das ist in Ordnung für ein fünfseitiges PDF. Ein 200-seitiger Jahresbericht stößt jedoch schnell an Grenzen.
- Begrenzungen des Kontexts. Modelle können nur eine begrenzte Menge an Text auf einmal verarbeiten, und ein 200-seitiges Dokument kann bis zu 300.000 Token umfassen – mehr als selbst die größten Modelle bewältigen können.
- Qualitätsverlust. Selbst wenn alles hineinpasst, werden die Antworten vage. Wenn ein Modell dazu aufgefordert wird, eine Nadel in einem ganzen Heuhaufen zu finden, verliert es den Fokus.
- Kosten. Anbieter berechnen nach Token, sodass das Versenden von 300.000 Token pro Frage – selbst wenn diese mit nur einer Seite beantwortet wird – schnell teuer wird.
RAG wurde genau, um diese Grenzen zu umgehen, entwickelt.
Wie vector RAG funktioniert
Die Idee ist einfach. Das Dokument wird einmal verarbeitet, intelligente Repräsentationen davon in einer Datenbank gespeichert, und bei der Beantwortung einer Frage werden nur die relevanten Teile abgerufen. Der Prozess umfasst fünf Schritte:
- Chunking. Der Dokument wird in kleinere Teile aufgeteilt, beispielsweise alle 500 Wörter oder jeweils ein Absatz.
- Embedding. Ein spezialisiertes Modell wandelt jeden Chunk in eine Liste von Zahlen, einen Vektor, um, der seine Bedeutung erfassen soll. Ähnliche Ideen erhalten ähnliche Zahlenwerte.
- Speicherung. Die Vektoren werden in eine dafür konzipierte Datenbank wie ChromaDB, Pinecone oder Weaviate eingefügt. Milvus, Qdrant sowie die PGVector-Erweiterung für PostgreSQL sind weitere gängige Optionen.
- Suche. Auch die Frage wird eingebettet, und die Datenbank gibt die Chunks zurück, deren Vektoren am nächsten liegen. Das ist eine Ähnlichkeitssuche.
- Generierung. Die abgerufenen Chunks sowie die Frage werden gemeinsam an das Modell übergeben, sodass es mit einem fokussierten Kontext arbeiten kann.
Eine vollständige funktionsfähige Version unter Verwendung von ChromaDB und OpenAI sieht wie folgt aus:
from openai import OpenAI
import chromadb
import PyPDF2
client = OpenAI(api_key="your-api-key")
# Step 1: Extract and chunk the document
def extract_and_chunk(pdf_path, chunk_size=500):
reader = PyPDF2.PdfReader(pdf_path)
full_text = ""
for page in reader.pages:
full_text += page.extract_text() + "\n"
words = full_text.split()
chunks = []
for i in range(0, len(words), chunk_size):
chunk = " ".join(words[i:i + chunk_size])
chunks.append(chunk)
return chunks
chunks = extract_and_chunk("annual_report.pdf")
# Step 2 and 3: Embed and store in ChromaDB
chroma_client = chromadb.Client()
collection = chroma_client.create_collection("my_documents")
collection.add(
documents=chunks,
ids=[f"chunk_{i}" for i in range(len(chunks))]
)
# Step 4: Search for relevant chunks
user_question = "What was the total revenue in 2024?"
results = collection.query(
query_texts=[user_question],
n_results=5
)
relevant_chunks = "\n\n".join(results["documents"][0])
# Step 5: Generate answer with focused context
response = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "Answer based only on the provided context."},
{"role": "user", "content": f"Context:\n{relevant_chunks}\n\nQuestion: {user_question}"}
]
)
print(response.choices[0].message.content)
Die meisten Unternehmen nutzen heutzutage etwas Ähnliches. Es kommt gut mit einfachen Fragen zu unkomplizierten Dokumenten zurecht, stößt aber auf Grenzen, sobald die Dokumente komplizierter werden.
Drei Gründe für das Versagen
Teile, die eine Idee halbieren
Stellen Sie sich einen Berichtsabsatz vor, in dem steht, dass der Betriebsgewinn im dritten Quartal 4,2 Milliarden Dollar betrug, was einem Anstieg von 12 Prozent im Vergleich zum Vorjahr entspricht – hauptsächlich wegen Cloud-Diensten, die 2,8 Milliarden Dollar an wiederkehrenden Einnahmen einbrachten (Details in Anhang C). Wenn ein 500-Wörter-Abschnitt zufällig mitten in diesem Satz endet, behält ein Teil die Zahl, verliert aber die Erklärung, während der nächste Teil die Erklärung behält, aber die Zahl verliert. Keiner der Teile gibt die vollständige Geschichte wieder.
Das Versagen lässt sich leicht nachstellen:
paragraph = """The company's Q3 operating income was $4.2 billion,
representing a 12% increase over the prior year period. This growth
was primarily driven by the expansion of cloud services, which
contributed $2.8 billion in recurring revenue as detailed in the
segment breakdown in Appendix C."""
# Simulating a chunk boundary at word 20
words = paragraph.split()
chunk_1 = " ".join(words[:20])
chunk_2 = " ".join(words[20:])
print("Chunk 1:", chunk_1)
print("---")
print("Chunk 2:", chunk_2)
Fragen Sie nach dem Grund für den Anstieg des Betriebsgewinns im Q3 – die Suche könnte entweder den Abschnitt zu Cloud-Diensten ohne Zahlen liefern oder den Abschnitt mit den Zahlen ohne Erklärung. In jedem Fall ist die Antwort unvollständig.
Die Aufteilung in Absätze löst das Problem nicht. Einige Absätze bestehen aus zwei Sätzen, andere füllen eine halbe Seite, und drei aufeinanderfolgende Absätze können nur zusammen einen zusammenhängenden Bericht liefern.
Referenzen, die zu nichts führen
Verträge und Finanzdokumente verweisen auf Angaben wie „Abschnitt 4.2.1 regelt dies“ oder „Detaillierte Tabellen finden Sie im Anhang G“. Eine Frage zu einem Punkt auf Seite 12, der auf Daten auf Seite 87 verweist, landet wahrscheinlich auf Seite 12, weil die Schlüsselwörter übereinstimmen – doch die Vektorsuche verfolgt den Verweis nicht zu Seite 87, wo sich die Zahlen befinden.
Eine schnelle Simulation zeigt das Problem:
# Simulating a cross-reference failure
documents = {
"page_12": "The company's debt-to-equity ratio improved significantly in 2024. For a full breakdown of long-term obligations, see Appendix G on page 87.",
"page_45": "Marketing expenses increased by 15% due to new campaigns.",
"page_87": "Appendix G: Long-term debt stands at $12.4B. Senior notes: $8.1B. Credit facility: $4.3B. Maturity schedule: 2026-2034."
}
# Vector RAG would likely return page_12 for a debt question
# but miss page_87 where the actual numbers live
# because "debt-to-equity ratio" is more similar to the query
# than "Senior notes" and "Credit facility"
Das ist in Verträgen, regulatorischen Unterlagen und wissenschaftlichen Arbeiten üblich. Die Antwort befindet sich oft gleichzeitig an zwei Orten, und ein System, das diese nicht miteinander verbinden kann, liefert stets unvollständige Ergebnisse.
Nicht übereinstimmendes Vokabular
Die Vektorähnlichkeit hängt stark davon ab, ob die Formulierungen des Benutzers denen des Dokuments ähneln. Wenn in einem Bericht von „non-GAAP-adjustiertem EBITDA“ die Rede ist und der Benutzer nach angepassten Erträgen fragt, könnten die Vektoren nicht gut genug übereinstimmen, um den richtigen Textabschnitt zu liefern. Die Menschen kennen nicht immer die genaue Terminologie eines Dokuments – und sollten das auch nicht müssen.
In technischen Bereichen wird die Situation noch schlimmer. Ein Arzt, der nach Behandlungsprotokollen für Herzinfarkte sucht, könnte Abschnitte übersehen, die als „Managementwege bei Myokardinfarkt“ bezeichnet sind. Die Bedeutung ist identisch, doch die Vektoren können so weit auseinanderliegen, dass die richtigen Abschnitte nie angezeigt werden.
Das sind keine seltenen Randfälle. In langen, strukturierten Dokumenten in der Praxis treten sie regelmäßig auf.
Der vectorlose RAG
Im September 2025 veröffentlichte ein Team bei VectifyAI ein Framework namens PageIndex, das einen anderen Ansatz verfolgt. Es teilt die Dokumente nicht in Abschnitte auf und vergleicht keine Nummern. Stattdessen erstellt es eine strukturierte Karte des Dokuments, damit ein KI-Modell sich darin zurechtfinden kann.
Die Inspiration stammt davon, wie Experten tatsächlich arbeiten. Wenn einem Analysten ein 200-seitiger Bericht übergeben wird und jemand nur eine Zahl benötigt, liest er nicht jede Seite. Stattdessen schaut er in den Inhalt, wählt den Abschnitt, der am ehesten die Antwort enthält, und liest diesen genau durch. Wenn dort steht „siehe Anhang G“, schaut er zum Anhang G.
PageIndex sorgt dafür, dass ein Modell auf dieselbe Weise handelt. Die entscheidende Erkenntnis ist, dass der am meisten ähnliche Text nicht immer der relevanteste ist. Eine Vektordatenbank gibt alles zurück, was der Frage am ähnlichsten erscheint, doch die Antwort befindet sich manchmal in einem Abschnitt, der überhaupt nicht danach aussieht. Was benötigt wird, ist ein logisches Denken darüber, wo die Antwort sein sollte – nicht nur Mustererkennung.
Das System arbeitet in zwei Schritten.
Schritt eins: ein Baumindex
Anstelle von Teilung in Blöcke und Einbettung wird das Dokument an ein logisches Modell übergeben, das es als Baum darstellt. Stellen Sie sich einen klugen Praktikanten vor, der den gesamten Bericht liest und einen mehrstufigen Inhaltstext erstellt, bei dem jeder Eintrag einen Titel, eine kurze Zusammenfassung, einen Seitenbereich sowie Links zu seinen Unter-Einträgen enthält. Ein Finanzbericht könnte so aussehen:
Root: Annual Report 2024
|-- Executive Summary (pages 1-3)
| Summary: "Overview of company performance, key metrics..."
|-- Financial Statements (pages 15-45)
| |-- Income Statement (pages 15-20)
| |-- Balance Sheet (pages 21-30)
| +-- Cash Flow Statement (pages 31-45)
|-- Risk Factors (pages 46-60)
+-- Appendices (pages 80-120)
|-- Appendix A: Segment Data (pages 80-95)
+-- Appendix G: Detailed Tables (pages 96-120)
Keine Vektoren und keine Embeddings – nur eine logische Struktur, die der Organisation des Dokuments entspricht. Das Modell nutzt sein logisches Denken, um natürliche Grenzen wie Kapitelabschnitte, Themensprünge und neue Abschnitte zu erkennen, anstatt an einer festgelegten Wortanzahl zu schneiden.
Schritt zwei: suchbasiertes logisches Denken
Zur Abfragezeit wird dem Modell nur der Baum angezeigt, niemals das gesamte Dokument. Es durchsucht die Überschriften und Zusammenfassungen, setzt sein eigenes Fachwissen ein und wählt die Knoten aus, die am ehesten die Antwort enthalten könnten.
Betrachten wir eine Frage zur jährlichen Veränderung des Betriebsgewinns. Die Logik des Modells verläuft ungefähr wie folgt: Gewinnmargen sind eine finanzielle Kennzahl, daher ist die Gewinn- und Verlustrechnung relevant, doch für einen jährlichen Vergleich könnten auch frühere Zahlen benötigt werden, möglicherweise im Anhang. Es gibt die Node-IDs beider Abschnitte an, das System lädt nur den ursprünglichen Text für diese beiden Abschnitte herunter, und die endgültige Antwort wird aus diesem eng begrenzten Kontext erstellt.
Eine funktionierende Demonstration des Konzepts erfordert nichts weiter als einfache OpenAI-Aufrufe:
import json
from openai import OpenAI
import PyPDF2
client = OpenAI(api_key="your-api-key")
# Extract text page by page
def extract_pages(pdf_path):
reader = PyPDF2.PdfReader(pdf_path)
pages = {}
for i, page in enumerate(reader.pages):
pages[i + 1] = page.extract_text()
return pages
pages = extract_pages("annual_report.pdf")
all_text = "\n".join([f"--- Page {k} ---\n{v}" for k, v in pages.items()])
# Step 1: Build the tree index using AI reasoning
tree_prompt = f"""You are a document analyst. Read this document and create
a hierarchical table of contents as a JSON tree. Each node should have:
- "title": section name
- "summary": 2-3 sentence description of what this section covers
- "pages": [start_page, end_page]
- "children": array of child nodes (or empty array)
Document:
{all_text[:80000]}
Return ONLY valid JSON. No other text."""
tree_response = client.chat.completions.create(
model="gpt-4.1",
messages=[{"role": "user", "content": tree_prompt}],
response_format={"type": "json_object"}
)
document_tree = json.loads(tree_response.choices[0].message.content)
print("Document tree built successfully!")
print(json.dumps(document_tree, indent=2)[:500])
# Step 2: Reasoning-based search over the tree
user_question = "What was the year-over-year change in operating margin?"
search_prompt = f"""You are a retrieval expert. Given a user question and
a document's table of contents tree, identify which sections are most
likely to contain the answer.
Think step by step:
1. What kind of information does the question ask for?
2. Which sections would a human expert check first?
3. Are there sections that might cross-reference each other?
Document tree:
{json.dumps(document_tree, indent=2)}
Question: {user_question}
Return JSON with:
- "reasoning": your step-by-step thought process
- "relevant_pages": list of page numbers to retrieve"""
search_response = client.chat.completions.create(
model="gpt-4.1",
messages=[{"role": "user", "content": search_prompt}],
response_format={"type": "json_object"}
)
search_result = json.loads(search_response.choices[0].message.content)
print("Reasoning:", search_result["reasoning"])
# Step 3: Fetch only relevant pages and generate answer
relevant_text = ""
for page_num in search_result["relevant_pages"]:
if page_num in pages:
relevant_text += f"\n--- Page {page_num} ---\n{pages[page_num]}"
answer_response = client.chat.completions.create(
model="gpt-4.1",
messages=[
{"role": "system", "content": "Answer precisely based on the document context provided."},
{"role": "user", "content": f"Context:{relevant_text}\n\nQuestion: {user_question}"}
]
)
print("\nAnswer:", answer_response.choices[0].message.content)
Der ganze Trick lässt sich also in einem Satz zusammenfassen: Vermeiden Sie den Vektorlagern, vermeiden Sie Embeddings, vermeiden Sie die Anpassung der Chunk-Größe und lassen Sie das Modell den Überblick studieren, entscheiden, wo die Antwort stehen sollte, und nur diese Abschnitte abrufen.
Verwendung des PageIndex-Frameworks
Die selbstgemachte Version eignet sich gut zum Lernen. Für echte Projekte übernimmt PageIndex die schwierigen Aufgaben: Es erzeugt optimierte Bäume, unterstützt fortgeschrittene Suchstrategien und ist als Cloud-Dienst oder als selbst gehostete Option verfügbar. Die grundlegende Verwendung sieht so aus:
from pageindex import PageIndexClient
import time
# Initialize the client
pi_client = PageIndexClient(api_key="your-pageindex-api-key")
# Upload and process your document
result = pi_client.submit_document("./annual_report.pdf")
doc_id = result["doc_id"]
# Wait for processing to complete
while True:
status = pi_client.get_document(doc_id)["status"]
if status == "completed":
print("Document processed!")
break
time.sleep(5)
# Inspect the generated tree structure
tree_result = pi_client.get_tree(doc_id)
if tree_result.get("status") == "completed":
tree = tree_result["result"]
for node in tree:
print(f"[{node['node_id']}] {node['title']} - Page {node['page_index']}")
# Ask questions using the Chat API
response = pi_client.chat_completions(
messages=[{"role": "user", "content": "What was total revenue in FY2024 vs FY2023?"}],
doc_id=doc_id
)
print(response["choices"][0]["message"]["content"])
Der erzeugte Baum hat folgende Form:
{
"title": "Financial Stability",
"node_id": "0006",
"page_index": 21,
"text": "The Federal Reserve maintains financial stability...",
"nodes": [
{
"title": "Monitoring Financial Vulnerabilities",
"node_id": "0007",
"page_index": 22,
"text": "The Federal Reserve's monitoring focuses on..."
},
{
"title": "Domestic and International Cooperation",
"node_id": "0008",
"page_index": 28,
"text": "In 2023, the Federal Reserve collaborated..."
}
]
}
Jeder Knoten verfügt über eine eindeutige ID, die auf das ursprüngliche Dokument verweist, einen Titel, den eigentlichen Text sowie Kindknoten für Unterkapitel. Das Modell durchläuft den Baum, indem es Zusammenfassungen liest und entscheidet, welche Äste weiter geöffnet werden sollen.
Mehrere Dokumente können in einer Abfrage miteinander verglichen werden:
response = pi_client.chat_completions(
messages=[{"role": "user", "content": "Compare the results across these two reports."}],
doc_id=["pi-abc123def456", "pi-abc123ghi789"]
)
Entwickler, die Agenten mit LangChain, CrewAI oder dem OpenAI Agents SDK erstellen, können PageIndex über das Model Context Protocol (MCP) anschließen. Dadurch kann ein Agent es als Suchwerkzeug ohne speziellen Integrationsscode aufrufen.
Der Benchmark hinter der Behauptung
FinanceBench ist der Benchmark, der die Aufmerksamkeit auf vectorloses RAG gelenkt hat. Seine Fragen stammen aus echten SEC-Unterlagen (10-K- und 10-Q-Berichten) und erfordern präzise Antworten: Zahlen aus Tabellen, mehrstufige Berechnungen sowie Querverweise zwischen verschiedenen Abschnitten. Es handelt sich dabei keineswegs um ein Spielzeug.
Herkömmliche vectorbasierte RAG-Lösungen erzielen auf diesem Benchmark Werte von etwa 30 % bis 50 %. PageIndex, angetrieben von seinem Mafin 2.5-Reasoning-Engine, erreichte 98,7 % – das ist eine völlig andere Liga und kein geringer Vorteil. Drei Gründe werden immer wieder genannt:
- Verfolgung von Querverweisen. Wenn in einer Dokumentation „siehe Anhang G“ steht, navigiert das Reasoning-Modell durch den Baum zu Anhang G und holt die entsprechenden Daten ab. Ein Vektorlager hat keine Ahnung, dass es dem Pointer folgen sollte.
- Erhaltung der Struktur. Eine Finanztabelle enthält Überschriften, verschachtelte Überschriften, Fußnoten sowie Verlinkungen zwischen Zellen. Baumstrukturen halten diese Elemente innerhalb klarer Grenzen zusammen, während eine feste Blockgröße sie voneinander trennt.
- Mehrschrittiges Reasoning. Um die jährliche Veränderung des Betriebsgewinns zu ermitteln, sind Zahlen aus zwei Abschnitten sowie eine Berechnung erforderlich. Das Reasoning-Modell erkennt, dass beides benötigt wird, und holt es gemeinsam ab, während eine Ähnlichkeitssuche vermutlich nur den dem Frageformulierung am nächsten liegenden Block auswählen würde.
Eine ehrliche Einschränkung: Stand Anfang 2026 hatte das PageIndex-Team noch keine detaillierten Angaben zu Geschwindigkeit oder Durchsatz veröffentlicht. Jede Abfrage erfordert mehrere aufeinanderfolgende Modellaufrufe für die Durchsuchung und das Schlussfolgern, wodurch sie pro Abfrage langsamer und teurer ist als eine einfache Vektorabfrage. Für Anwendungen mit hohem Volumen und niedriger Latenzzeit ist dieses Kompromissmodell möglicherweise nicht geeignet.
Wahl zwischen den beiden
Vectorless RAG ist kein universeller Ersatz für Vektordatenbanken. Es handelt sich um ein spezialisiertes Werkzeug.
Vector RAG eignet sich, wenn die Antworten innerhalb einer Sekunde bereitstehen müssen, wenn das Korpus aus vielen kurzen Dokumenten besteht, wie beispielsweise einer FAQ-Datenbank oder einer Sammlung von Artikeln, wenn die Kosten pro Abfrage wichtiger sind als die perfekte Genauigkeit, oder wenn ein Consumer-Chatbot mit ausreichend guten Antworten auskommt.
Vectorloses RAG eignet sich für lange, strukturierte professionelle Dokumente: Jahresberichte, Verträge, regulatorische Unterlagen und technische Handbücher. Es ist auch geeignet für Fälle, in denen Genauigkeit an erster Stelle steht, bei denen Abfragen cross-referenziert werden müssen oder bei denen ein klarer Audit-Trail zeigen sollte, woher jeder Teil einer Antwort stammt.
Für die Produktion lohnt es sich, ein Hybridmodell in Betracht zu ziehen. Leichte Metadaten oder Schlüsselwortfilter können eingrenzen, welche Dokumente relevant sind, und anschließend findet ein baumbasierter Reasoning-Prozess die genauen Abschnitte darin. Dadurch entsteht bei der ersten Abfrage die Geschwindigkeit einer herkömmlichen Suche und bei der zweiten Abfrage die Genauigkeit des Reasonings.
Der Kostenausgleich ist real. Reasoning-Modelle sind pro Aufruf teurer als Embedding-Modelle, und das Durchlaufen von Bäumen bedeutet mehrere sequenzielle Aufrufe sowie höhere Latenzzeiten. Geschwindigkeit und Preis werden gegen Genauigkeit und Erklärbarkeit eingetauscht. In regulierten Bereichen wie Finanzen, Recht und Gesundheitswesen, wo falsche Antworten Konsequenzen haben, lohnt sich dieser Tausch in der Regel.
Wohin es geht
Der Wandel von einer auf Ähnlichkeit basierenden zu einer auf Reasoning basierenden Suchmethode ist noch jung, doch die Richtung ist klar. PageIndex unterstützt bereits eine auf Bildern basierende Variante, die direkt mit PDF-Seitenbildern arbeitet, ohne Textextraktion oder OCR. Die Seitenbilder werden eingegeben, und das Modell handelt auf der Grundlage dessen, was es sieht. Das hilft bei komplexen Layouts, gescannten Seiten und eingebetteten Diagrammen, mit denen Textextraktion nur schlecht umgehen kann.
Auch an der Entwicklung von agiler Informationsabrufung wird gearbeitet. Anstelle eines einzigen Durchlaufs untersucht das Modell weiterhin den Inhalt: Es folgt Referenzen, vergleicht Abschnitte, stellt sich selbst Nachfragen und verfeinert seine Antwort über mehrere Überlegungsrunden hinweg – das ist der Unterschied zwischen dem Überfliegen eines Dokuments und seinem gründlichen Studium.
Jeder, der experimentieren möchte, kann das Open-Source-Repositorium PageIndex auf GitHub nutzen, das ausführbare Jupyter-Notebooks für sowohl die Standard- als auch die auf KI-basierter Vision basierenden Verarbeitungsschritte bietet. Das Projekt erreichte nach seinem Start im September 2025 20.000 Sterne, und seine Discord-Community ist aktiv.
Vektordatenbanken werden weiterhin bestehen und bewältigen viele Arbeitslasten hervorragend. Dennoch nehmen die Anwendungen zu, die eine detaillierte Auswertung langer, komplexer Dokumente erfordern, und die Methode, den Text in fest definierte Abschnitte aufzuteilen in der Hoffnung, dass eine Ähnlichkeitssuche den richtigen Abschnitt findet, wird zunehmend unzureichend. Verträge, Unterlagen und technische Spezifikationen sind genau die Dokumente, die ein Unternehmen am meisten schätzt, und dort bringt eine auf Logik basierende Suche den größten Nutzen.
Die sinnvolle Art, dies zu beurteilen, besteht darin, die selbst erstellte Version an einem bereits gut verstandenen Dokument auszuprobieren und anschließend PageIndex am selben Dokument zu testen, um zu sehen, wie gut der Baum die durch das Chunking zerstörte Struktur bewahrt. Das beste Suchsystem ist nicht das mit der ausgefeiltesten Technologie – es ist das, das die richtige Antwort findet.
Ein Weg, es auszuprobieren
- Vector RAG – geeignet für Grundlagen: Installieren Sie
chromadbundopenai, führen Sie das ChromaDB-Beispiel mit einem kurzen Dokument aus, versuchen Sie es anschließend mit einem längeren Dokument und beobachten Sie, ab wann die Antworten unzuverlässig werden. - DIY-Vectorlos – geeignet zum Verständnis des Konzepts: Führen Sie das einfache OpenAI-Beispiel mit Baumlogik auf demselben Dokument aus und vergleichen Sie die Antworten mit der Vektorversion.
- Produktionsreife Vectorlos-Lösung: Holen Sie sich eine kostenlose PageIndex-API-Schlüssel von der Dokumentationsseite, installieren Sie das
pageindex-Python-Paket und folgen Sie dem SDK-Beispiel. Laden Sie ein echtes Dokument hoch und stellen Sie Fragen, deren Antworten bereits bekannt sind – das ist der schnellste Weg, um die Eignung zu prüfen.
Sämtliche Beispiele verwenden Python 3.10 oder neuer zusammen mit dem OpenAI SDK, ChromaDB und PyPDF2, die über pip install openai chromadb PyPDF2 pageindex installiert werden. Ein OpenAI-API-Schlüssel ist erforderlich, außerdem ein PageIndex-Schlüssel für die PageIndex-Beispiele.
Verwandte Artikel
- Semantische Suche in PostgreSQL mit pgvector und Node.js – kein LLM erforderlich — Erstellen Sie eine bedeutungsbasierte Suche innerhalb von PostgreSQL mithilfe von pgvector, MiniLM-Embeddings und Node.js: Tokens, Blöcke, Vektoren, ein IVFFlat-Index, Abstandsberechnungen sowie Methoden zum Auslesen der Scores.
- Agenten-Memoriesnaps, Fähigkeiten, Verfall und branchenspezifische Speicherung — Vier Erweiterungen für eine eingebettete Vektor-Datenbank-Speicherschicht für Programmier-Agenten: portable Snaps mit Zusammenführung, Aktivierung von Fähigkeiten, Verfall mit Konfliktprüfungen sowie memorielle Strukturen, die auf bestimmten Branchen beschränkt sind.