[KongchangAI]
· 1 min read· 996 words

PageIndex: A New Reasoning-Based RAG Approach Without Vectors

PageIndex: A New Reasoning-Based RAG Approach Without Vectors

PageIndex replaces vector indexes with hierarchical document trees, letting LLMs navigate long documents like a human reader.

PageIndex is an open-source RAG framework from VectifyAI built around a "vectorless, reasoning-based" philosophy, offering an alternative to traditional vector RAG for long-document scenarios. It constructs a hierarchical table-of-contents tree for each document and has the model reason its way to the relevant section at query time, rather than relying on embedding similarity. This makes retrieval paths transparent and traceable, and keeps retrieved content contextually complete — ideal for structured documents like technical manuals, legal contracts, and financial reports. The trade-off is higher token usage and latency per query. The authors emphasize the two paradigms are complementary, not competing. The project has earned ~39K GitHub stars, reflecting strong community interest in RAG architecture innovation.

What Is PageIndex

In an era where Retrieval-Augmented Generation (RAG) has gone mainstream, vector databases have become almost a default requirement. But PageIndex, an open-source project from VectifyAI, takes a different path — proposing a "Vectorless," reasoning-based RAG architecture. The project has already accumulated 38,731 stars and 3,356 forks on GitHub, with 2,860 new stars added in a single week, and its momentum keeps growing.

PageIndex project homepage

PageIndex's core concept is building a Document Index for documents, enabling large language models to locate relevant content through a hierarchical table of contents — much like a person flipping through a book — rather than relying on vector similarity search. This approach is especially meaningful for long-document Q&A, professional reference retrieval, and similar use cases.

Why Go "Vectorless"?

The typical traditional RAG pipeline works like this: split documents into chunks, convert each chunk into a vector using an embedding model, store them in a vector database, then retrieve the closest chunks via vector similarity at query time. This approach is mature and efficient, but it comes with several long-standing pain points.

First, there's the semantic chunking problem. Mechanically splitting text at fixed lengths often cuts logical units in half, leaving retrieved chunks without sufficient context. Second, similarity doesn't equal relevance — vector retrieval surfaces content that "looks like" the query, not necessarily what's actually needed, especially for questions that require cross-section reasoning. Third, vector databases introduce their own engineering complexity and storage costs.

PageIndex tries to sidestep these issues in a way that more closely mirrors how humans read — no aggressive chunking, no vector indexing, just letting the model navigate through a structured document outline using reasoning.

It's worth noting that traditional RAG chunking strategies carry a heavy parameter-tuning burden. Common approaches include fixed character-count splits, sentence-level splits, paragraph-level splits, and the increasingly popular semantic chunking — which uses embedding models to detect semantic discontinuities between adjacent sentences. While smarter than fixed-length splitting, semantic chunking still can't guarantee logical coherence across paragraphs. Embedding models themselves introduce additional dependencies: different models produce significantly different vector quality on the same corpus, and the embedding space doesn't fully align with a downstream LLM's semantic space — leading to retrieval noise where "vector distance is small but semantic match is poor." These issues are especially pronounced in multi-hop reasoning scenarios, where a question's answer requires synthesizing information from multiple parts of a document, and a single-pass vector retrieval is almost guaranteed to miss critical pieces.

How Reasoning-Based Retrieval Works

PageIndex's approach can be understood as follows: first, generate a hierarchical tree structure for a document — similar to a book's table of contents — where each node corresponds to a chapter, section, or page. When a user asks a question, the model doesn't go digging through a vector store for fragments. Instead, like someone consulting a reference book, it first checks the table of contents to determine which chapter likely contains the answer, then drills down layer by layer to locate the specific content.

PageIndex structure diagram

The biggest advantage of this reasoning-based retrieval is interpretability and contextual completeness. The model's retrieval path is explicit and traceable — why it chose a particular section is a result of reasoning over the document's structure, not a black-box vector distance calculation. For long-document scenarios in finance, law, academia, and other fields that demand high accuracy and auditability, this transparent retrieval logic is especially valuable.

Additionally, because the document's original hierarchical structure is preserved, retrieved content naturally carries its full context — avoiding the "isolated fragment" problem that plagues traditional chunking.

This retrieval paradigm has conceptual similarities to "Tree of Thoughts" and agent-style navigation. As the model traverses the document tree, it performs a form of hierarchical reasoning at each node: deciding "which subtree is more likely to contain the target information" — similar to binary search tree path selection, except the decision criterion is natural language semantics rather than numerical comparison. This requires the underlying LLM to have strong instruction-following and contextual understanding capabilities, meaning PageIndex's real-world performance is tightly coupled to the capability of the model being used. The expansion of context windows has also been a key enabler of this approach — when a model can process an entire chapter or even a full document in one pass, the "navigate to node, then read carefully" pattern has clear advantages over repeated vector retrieval.

Use Cases and Trade-offs

PageIndex isn't trying to replace vector-based RAG entirely — it offers an alternative path optimized for specific scenarios. It works best with well-structured long documents such as technical manuals, financial reports, research papers, and legal contracts — documents that already have good section organization and naturally lend themselves to building a document tree.

That said, the trade-offs are real. Constructing and maintaining the document tree, plus invoking a large model for reasoning-based navigation on every query, means higher token consumption and latency compared to a simple vector lookup. For high-volume short texts, FAQs, and other fragmented, unstructured corpora, traditional vector retrieval remains more cost-effective.

In other words, vectorized and vectorless approaches aren't opposites — they're complementary. Developers should choose the right approach based on document characteristics, accuracy requirements, and cost constraints, and may even benefit from using both within the same system.

Project Value and Community Traction

As a Python project, PageIndex racing to nearly 40,000 stars in a short period reflects the developer community's strong appetite for RAG architecture innovation. As LLM reasoning capabilities and context windows continue to improve, reasoning-based retrieval — "let the model read and find it itself" — is becoming increasingly viable, and PageIndex has landed squarely on that trend.

For teams building enterprise knowledge bases or document Q&A systems, PageIndex at least offers a new option worth evaluating — especially when you've noticed traditional RAG repeatedly falling short on long documents and cross-section reasoning tasks. It may be time to try a retrieval paradigm that more closely mirrors how humans actually read.

#PageIndex#vectorless RAG#reasoning-based retrieval#RAG architecture#document index#long document QA#LLM retrieval#no vector database
Share:

Related articles