RAG & RetrievalSep 6, 20264 min read

PageIndex for RAG: Document-Tree Retrieval Overview

PageIndex: Compare tree retrieval with local and cloud capability boundaries. Assess document structure before applying a reported RAG accuracy score.

Docs analysis

Who this is for: Developers evaluating PageIndex.

The answer in 3 lines

  • Compare tree-based retrieval with local and cloud capability boundaries.
  • Assess document structure before applying a reported RAG accuracy score.
  • Evidence: linked documentation; no independent test results are claimed.

Evidence: Analysis of the linked documentation and source-reported behavior; examples and decision tables are explanatory, not executed tests.

AI-assisted documentation analysis · 3 source links

Based on linked documentation and web research. Source-reported benchmarks are attributed to their publishers; this report does not establish independent testing. How reports are produced.

PageIndex replaces a vector index with a document tree and uses an LLM to navigate that tree. The README describes indexing natural document sections and retrieving through reasoning. This is worth examining for long, structured documents where locating the relevant section and following context matter; it is not enough evidence to declare one retrieval method best for every corpus.

PageIndex: the documented flow

Loading diagram…

Conceptual map of the documented components, not a measured deployment or proof of failure recovery.

The retrieval unit changes from chunks to sections

The documented process builds a tree index and searches it with a model. The project's explanation highlights contextual queries and references within documents as motivations for this design.

The practical difference is what the retriever can use to decide where to look. A document's structure can make its sections and relationships useful navigation signals. That advantage depends on the material being indexed and the questions being asked. A collection of short, unrelated records presents a different problem from a long report with appendices and internal references.

The project's comparison with vector retrieval should also be read as its design argument, not a proof that all vector-based systems ignore conversation history or cannot preserve provenance. Those broader properties depend on the surrounding retrieval system.

Indexing and answering have different model requirements

The README distinguishes the model used for index summarization and refinement from the model used to search the tree and answer questions. It recommends a basic model for indexing and a stronger model for chat. Source

This suggests separating one-time preparation from repeated query work in a cost model. Reusing an index amortizes preparation, but query cost still depends on the retrieval path and model. “No vector database” describes one removed component; it does not imply no indexing, storage, or model-call cost.

Local and cloud are different capability sets

The README presents local mode for text-heavy PDFs and cloud mode with managed indexing, OCR, image understanding, and storage. Its comparison table distinguishes page-level local citations from line-level cloud citations, and lists additional cloud capabilities for larger collections. Source

That difference matters before adoption. A scanned document collection is not the same input as a text-based PDF corpus. Nor does running local storage with your own model key establish that a remote model provider receives no data. Follow the configured processing path rather than inferring privacy from the word “local.”

Keep benchmark claims attached to their task

The project reports 98.7% accuracy on FinanceBench and separately describes a local-mode benchmark of 62 lookup questions across 34 PDFs. It also reports indexing and query-cost measurements for particular models and document sizes. Source

These are different evaluations. A financial question-answering result should not be presented as the expected accuracy of every local SDK deployment. A lookup benchmark with answers in running text also does not establish performance on every chart, scan, or multi-document reasoning task.

One reviewed third-party guide says there are no published latency or throughput benchmarks, while the reviewed README includes indexing-time and query-cost results. The useful reconciliation is narrower: some reported measurements now exist, but they still do not provide a universal end-to-end latency or throughput guarantee.

Choose by document shape and operating needs

PageIndex is most interesting when document structure provides information that a retrieval workflow can exploit. Before choosing it, distinguish text PDFs from scans, one document from a corpus, preparation cost from query cost, and reported benchmark tasks from the application's questions. That produces a more defensible decision than choosing from the headline accuracy alone.

Compare retrieval routes on the questions your PDFs imply

Suppose a corpus contains annual reports with footnotes and scanned appendices. A good comparison asks where the answer lives and whether the retrieval route preserves the evidence needed to interpret it. The documented tree index and local/cloud capability distinction make document shape central to the choice. Retrieval and mode differences

Question categoryEvidence to retainFailure to distinguish
A value explained by a nearby footnoteSelected section, answer and citationFinding a value without its qualification
A reference to another sectionNavigation path and final supporting passageStopping at the reference rather than its target
Content available only as a scanAvailable extracted content and processing modeInput extraction failure mistaken for bad retrieval

Run the same question set through the candidate and the existing retrieval route. Track preparation cost separately from query work, and check citations against the underlying documents. Evaluate whether the chosen local or cloud mode supports the actual inputs before interpreting an answer-quality score.

This procedure can reveal where tree navigation helps and where extraction or model selection remains the bottleneck. It does not reproduce FinanceBench or establish that reasoning-based retrieval always outperforms vector retrieval. The final adoption decision should include both useful answers and the cost of producing them.

Evidence and scope

Primary repository documentation was refreshed on 14 October 2026. The worked scenario is a planning exercise derived from documented behavior, not a product test. Reported measurements remain attributed to their source and workload.

Keep exploring

Practical guide: Why RAG Gives Wrong Answers With Relevant Documents →

Retrieval & memory: questions, tradeoffs, and guides →

Browse all reports · Suggest a correction