A question asks why a company increased its inventory impairment allowance. Vector retrieval returns ten passages containing "inventory" and "impairment": an accounting policy, a risk disclosure, historical figures, and several definitions. Every passage is semantically similar. None explains the change.
This is not necessarily a topK problem. Similarity search is good at finding text that resembles the query. Professional document analysis needs evidence that supports an answer, often across definitions, exceptions, and distant sections.
PageIndex targets that gap. The interesting idea is not the label "vectorless." It is the decision to replace one nearest-neighbor lookup with a staged search through document structure.
First build a map that an agent can read
PageIndex converts a PDF or Markdown document into a hierarchy. Nodes contain titles, page or index ranges, summaries, identifiers, and children. The result resembles a table of contents, but it is designed for model-guided retrieval.
At query time, an agent can judge which top-level branches are relevant, descend into selected children, and finally inspect source pages or sections.
textdocument -> semantic tree question -> reason over tree -> candidate sections -> source evidence
This differs from the familiar pipeline of fixed-size chunks, embeddings, and vector topK. Structure narrows the search space before the model reads detailed evidence.
What "no chunking" actually means
The project presents itself as "No Vector DB, No Chunking." The second claim is best read as "no independent fixed-length retrieval chunks."
The system still needs node boundaries, page ranges, and candidate sections. Without them, it could not locate evidence. The difference is that boundaries follow the document's natural organization instead of turning every 500 tokens into an isolated unit.
PageIndex does not eliminate segmentation. It promotes segmentation from a mechanical preprocessing step to a document-modeling problem. That distinction matters more than the slogan.
Where the approach has an advantage
Tree retrieval is most plausible when three conditions hold.
First, the material has a stable hierarchy. Financial reports, regulations, manuals, textbooks, and technical specifications already encode useful priors in their sections.
Second, the question requires contextual judgment. "When does this policy apply?" may require a definition, a scope section, and an exception. Sentence-level similarity does not guarantee complete evidence.
Third, the answer must be traceable. A tree keeps titles and page ranges close to the retrieval path, making it easier to show where evidence came from.
The case is weaker for short FAQs, loosely connected messages, or collections of independent facts. High-throughput, low-latency systems may also reject the cost of repeated model decisions.
Index quality becomes the ceiling
A tree is a map. If headings, tables, footnotes, or page boundaries are reconstructed incorrectly, the retrieval agent can reason carefully and still enter the wrong branch.
A production evaluation should inspect:
- heading hierarchy and section boundaries;
- preservation of tables and cross-page paragraphs;
- summaries that retain exceptions and qualifiers;
- stable node IDs and citations after document updates.
The project README also distinguishes the open-source package from its cloud pipeline. Self-hosted PageIndex uses standard PDF parsing, while the hosted service offers enhanced OCR and tree construction for complex documents. A polished cloud demo should not be treated as evidence for the open-source parser.
Treat the benchmark as a lead, not a verdict
The PageIndex team reports 98.7% accuracy on FinanceBench. The number is worth investigating, but it is reported through project-maintained results and should not be mistaken for an independent reproduction.
On a real corpus, split evaluation into stages:
- Did the correct evidence enter the candidate nodes?
- Do cited pages match the source?
- Do multi-hop questions include every required section?
- What are the model-call count, token cost, and tail latency?
- How many failures come from indexing, retrieval, or final generation?
A single answer-accuracy score hides where the system fails. Stage-level measurements reveal whether the map was wrong, the path was wrong, or the answer ignored correct evidence.
Vector retrieval can still be part of the system
At corpus scale, finding candidate documents before reasoning over sections is often more practical than asking one agent to navigate millions of files.
textmetadata / vector search -> candidate documents PageIndex tree search -> candidate sections generation + validation -> answer with page references
Vector search can provide cheap coarse recall, while tree search performs the expensive structural pass. Whether both layers are justified depends on corpus size, query complexity, and latency constraints, not ideology.
My view
PageIndex matters because it reminds RAG teams that a long document is not an unordered bag of chunks. Headings, pages, citations, and section relationships are retrieval signals.
For questions requiring cross-section reasoning and traceable evidence, giving the model a map before asking it to read is a credible approach. The tradeoff is that risk moves from embedding recall into tree construction and agent decisions. That deserves evaluation, not mythology.