Skip to main content

Command Palette

Search for a command to run...

PageIndex: Vectorless Reasoning-Based RAG Framework

Not all improvements come from adding complexity -- sometimes it's about removing it. PageIndex takes a different approach to RAG. Instead of relying on vector databases or artificial chunking, it builds a hierarchical tree structure from documents and uses reasoning-based tree search to locate most relevant sections. This mirrors how humans approach reading: navigating through sections and context rather than matching embeddings. As a result, the retrieval feels transparent, structured, and explainable. It moves RAG away from approximate semantic vibes and towards explicit reasoning about where information lives.

Updated
4 min read
PageIndex: Vectorless Reasoning-Based RAG Framework

LLMs have become very powerful engines for document understanding and question answering. However, they are constrained by a fundamental architectural limit: context window which is the maximum number of tokens the model can process at once. This makes it challenging for LLMs to accurately interpret and reason over long, complex, domain-specific documents such as financial reports or legal filings.

To solve this, developers have heavily relied on Retrieval-Augmented Generation (RAG) powered by vector databases. But what if the very foundation of vector RAG is flawed for complex tasks ?
Enter PageIndex, a paradigm-shifting, "vectorless" and reasoning-based RAG framework. Instead of relying on mathematical embeddings, PageIndex organizes documents into a hierarchical tree and uses the LLM's own reasoning to navigate them -- just like a human expert would. Let us deep dive into how it works, why it matters, and how it's redifining document retrieval.


The Problem with Traditional Vector RAG

In traditional RAG, a document is chopped up into fixed-size "chunks" (e.g., 512 tokens), converted into mathematical vectors, and stored in a database. When you ask a question, the system looks for chunks that are semantically similar to your query.

While this works for simple lookups, it falls apart in complex, domain-specific scenarios (like legal or financial analysis). Here is why:

  1. Similarity ≠ Relevance: Vector databases assume that words with similar meanings contain the right answer. But if you ask for "inconsistencies across documents" or "direct quotes from John," vector search fails because these concepts do not map well to embeddings.

  2. Hard Chunking Destroys Context: Chopping a document into fixed blocks arbitrarily cuts through sentences and paragraphs, fragmenting the actual meaning of the text.

  3. Blind to Cross-References: If a document says "see Appendix G," a vector database will miss it because the text in Appendix G is not semantically similar to your original question.

  4. No Conversational Memory: Vector searches treat every query in isolation, making it incredibly hard to maintain multi-turn chat contexts (e.g., asking "What are the assets?" followed by "What about the liabilities?").


What is PageIndex ? The Core Concept

PageIndex takes a "subtraction" approach to innovation: it completely removes vector databases and chunking from the equation.

Instead of searching for semantic vibes, PageIndex relies on reasoning-based retrieval. In the preprocessing stage, it uses an LLM to read the document and generate a structured, JSON-based Table of Contents (ToC) tree.

This tree organizes the content into logical, natural sections—like chapters, subheadings, and pages—complete with node IDs, summaries, and metadata. This ToC is then fed directly into the LLM’s active context window, acting as an "in-context index".


How PageIndex Works: The Human-Like Loop

When you ask PageIndex a question, it doesn't just return a mathematical match. It dynamically "thinks" about where the answer might be, following a highly traceable, iterative loop:

  1. Read the ToC: The AI reviews the document's structure to understand the layout.

  2. Select a Section: It infers which section is most relevant (e.g., "The user asked about deferred assets, let me check the Financial Summary section" ).

  3. Extract Information: It pulls the raw data from that specific node.

  4. Evaluate Sufficiency: It asks itself: "Did I find the complete answer?" If the answer references "Table 5.3 in Appendix G," the AI loops back to the ToC, finds Appendix G, and reads it.

  5. Answer the Question: Once all context is gathered, it delivers a precise, fully-informed response.


Trade-Offs: Accuracy vs Speed

No system is perfect, and the developer community has rightly pointed out the trade-offs of vectorless retrieval.

  • The Pros: It is incredibly accurate. On the FinanceBench benchmark, PageIndex achieved a state-of-the-art 98.7% accuracy, significantly outperforming traditional vector systems. Furthermore, retrieval is completely transparent; the system leaves a trail of exactly which pages and sections it reasoned through.

  • The Cons: It is computationally heavier and slower. Having an LLM iteratively read summaries and traverse a tree costs more time and money per query than a simple mathematical vector comparison.

Ultimately, PageIndex is built for quality maximalists. If you are building a quick chat app over a product catalog, use a vector database. If you are building an AI analyst to parse 200-page earnings reports where a hallucination could cost millions, PageIndex is the superior choice.