I wrote about graph-based retrieval as the frontier past plain RAG a couple weeks back, then covered Graphify as a concrete code-focused example of exactly that shift. PageIndex, trending again this week under GitHub’s Trendshift ranking, is the same underlying idea pointed at a different target: not code, but long, structured documents — legal filings, financial reports, technical manuals.
The core mechanism inverts the usual RAG pipeline entirely. Standard RAG chunks a document into fixed-size pieces, embeds each chunk into a vector, and retrieves by measuring similarity between your question’s embedding and the stored chunks — the approach I laid out in detail separately. PageIndex skips embedding and chunking altogether. It sends the document to an LLM and asks it to generate a hierarchical tree structure — effectively an intelligent, machine-generated table of contents — then, at query time, has the model reason over that tree, navigating down through sections the way a person would flip to the right chapter rather than scanning every page. The project’s own framing draws the comparison directly to AlphaGo: reasoning-based tree search, not similarity math.
Where this actually beats vector search, concretely rather than just architecturally: cross-reference following. A document that says “see Appendix A” is something PageIndex can act on directly — it identifies the Appendix A node in its tree and retrieves it. A vector-based system has no real concept of a document-level cross-reference at all; two chunks referring to each other structurally can sit far apart in embedding space with nothing connecting them. For financial and legal documents specifically, where an answer routinely depends on following an explicit reference between sections, that’s a genuine capability gap rather than a marginal accuracy difference — reflected in the project’s reported results on FinanceBench, where it outperforms standard vector RAG specifically on deep, structure-dependent analysis of a single document.
The honest limit, stated plainly by the people who built it: PageIndex works best on documents with real, explicit hierarchical structure. A messy, unstructured document — one without meaningful section boundaries, headers, or organization to build a tree from in the first place — doesn’t give the reasoning step much to navigate, and the approach’s advantage over plain vector search narrows accordingly. This isn’t a general replacement for embeddings everywhere; it’s a better fit specifically where the source material already has real structure a human reader would use to navigate it.
Where this connects directly to Graphify, beyond both being “reasoning over structure instead of similarity search”: Graphify builds its graph from a codebase’s actual AST — deterministic, because code has an unambiguous, machine-parseable grammar to extract structure from. PageIndex builds its tree from a document using an LLM’s judgment about what the structure probably is, because prose doesn’t have anything as rigid as a syntax tree to parse directly. That’s a meaningful difference in what each tool can actually guarantee: Graphify’s EXTRACTED edges are verifiably true because they’re read straight from the grammar; PageIndex’s tree is itself already an LLM’s interpretation, one layer removed from ground truth before any retrieval even happens. Both are legitimate, useful approaches — they’re just applied to domains with genuinely different amounts of real, extractable structure already sitting in the source material.
The practical takeaway: if you’re building retrieval over structured, hierarchical documents rather than a loose knowledge base of disconnected facts, and specifically need answers that depend on following explicit cross-references or understanding where something sits in a document’s actual organization, PageIndex is worth trying before defaulting to another vector database — it’s solving a problem vector similarity was never actually built to handle.
