PageIndex: RAG Without Embeddings

Graph RAG went viral on LinkedIn last year, and for good reason: it solves a real problem.

The catch is that it's probably not the problem you have.

Graph RAG was built for finding patterns across many documents. Themes, entity webs, "what connects these 500 reports". It does that well. Diving deep into a single 200-page 10-K is a different job, which is what most teams actually need to do.

The tool for that is much quieter on LinkedIn.

PageIndex (VectifyAI, 26.7K stars on GitHub, MIT) is a vectorless retriever. No embeddings. No chunking. An LLM reads the document once and writes a hierarchical table of contents with a summary at each node. At query time, an agent navigates that tree like an analyst would: read the TOC, jump to a section, read the summary, decide if it's enough, descend if not.

I read the code. The agent has only three tools: fetch the structure without text (token-cheap), fetch a page range, fetch metadata. That's the entire retrieval surface. Every answer traces back to a node, so the path is fully auditable.

Reported result on FinanceBench (SEC 10-Ks, 10-Qs, 8-Ks): 98.7% accuracy on the full benchmark. The original FinanceBench paper (2023) puts vector RAG with GPT-4-Turbo at 19% with a shared store across filings, 50% with a per-filing store (narrower scope, closer to a single-doc setup). VectifyAI's own table adds ChatGPT 4o + Search at 31% and Perplexity at 45%, both on 66.7% coverage. Caveats: the 98.7% is self-reported, no independent reproduction yet, and the baselines mix vendor systems rather than a tuned vector RAG pipeline.

Honest limits. Past about 1000 documents, PageIndex falls back to FAISS, so it's vectorless within one doc, not at system scale. Each query takes 2 to 5 seconds and several LLM calls, with real cost per question.

How to choose, by question type:

Single-doc deep Q&A (one filing, one contract, one manual): tree wins. Structure preserves cross-references, audit trail is free, the accuracy gap on professional content is real.

Cross-doc themes (thousands of reports, entity webs): graph wins. Extraction and community summaries see what tree and vector can't.

Fuzzy lookup on flat content (snippets, FAQ, short docs): vector wins. Fast, cheap, good enough.

The deeper point: similarity is the wrong objective on professional documents. You don't want passages that look like the question, you want the one that answers it. That requires reasoning over structure, which cosine over chunks can't deliver.

Monday morning, open your last failed RAG query. Classify it on the three axes. If the question was single-doc deep and you defaulted to vector, you've been holding the wrong hammer.

What retriever is your stack actually using, and does it match the question?