PageIndex — vectorless, reasoning-based retrieval

VectifyAI's document-retrieval engine, and the reason openkb can compile documents longer than a context window. MIT, Python, 35,435★ as of 2026-08-31 (repository created 2025-04-01) — an order of magnitude more attention than openkb itself, which is the newer, smaller sibling built on top of it.

Page scoped to what openkb's README and the PageIndex README state. No independent evaluation ingested; the accuracy number below is the maker's own. Corrected 2026-09-14: an independent run exists — Kirk Ryan (kirkryan.co.uk, 2026-03-04) ran PageIndex with Qwen3-32B via Ollama against vector providers on his own 16-query set: PageIndex averaged 575,288 ms (~9.6 min) per query, and 9 of 16 queries timed out at ten minutes, against 42–48 ms for the hosted vector providers and ~18 s for local Ollama embeddings. Indexing a 15 KB article took 459 s because the tree build makes many LLM calls. His reading is a precision–recall trade: PageIndex returns nothing rather than something irrelevant. It does not test the maker's FinanceBench accuracy figure, which stays the maker's own.

The claim: similarity is not relevance

The framing is a direct attack on the embedding assumption underneath retrieval-augmented-generation: "Vector-based RAG retrieves by semantic similarity. But similarity ≠ relevance — what retrieval actually needs is relevance, and relevance requires reasoning." On long professional documents, the README argues, similarity search "misses what is relevant but not similar, and returns what is similar but not relevant."

The replacement, explicitly modelled on AlphaGo's search: drop the vector index, build a hierarchical tree index of the document, and let an LLM reason its way down it — the way a person opens a long report at the right section. Two steps: generate a tree-structure index per document, then agentically search that tree.

The tree structure is now extracted heuristically from the document's own layout, not built by an LLM (the "PageIndex Flash" update, Aug 2026); the LLM only summarizes and refines it. The expensive model goes on the search side, not the indexing side.

Not a sixth gap — a different primitive

retrieval-augmented-generation here carries a five-gap account of what the mainstream design misses — no-accumulation (llm-wiki), exact-token (BM25, hybrid-retrieval-rag), factual-connection (knowledge-graph, gbrain), temporal-validity (temporal-knowledge-graph), and whole-corpus sensemaking (graphrag). Every one of those keeps the vector index and adds something beside it. PageIndex is the first entry in the thread that removes it, on a complaint upstream of all five: document structure is destroyed at chunk time. Its answer is not a better similarity function or a richer edge type but the deletion of the embedding step — retrieval as navigation rather than as nearest-neighbour lookup.

That places it beside, not inside, long-context-vs-chunking, which asks how to segment text before embedding it. PageIndex's answer to that question is: don't. It is the strongest form of the argument, and the one with the most to lose — reasoning over a tree costs an LLM call per hop where a vector lookup costs a matrix multiply, and the README's own model advice ("use the best model you can afford" for search) concedes the retrieval step is now the expensive one.

The number, and what it is worth

98.7% accuracy on FinanceBench, against ~50% for vector-based RAG, per the maker's own evaluation repository (VectifyAI/Mafin2.5-FinanceBench) and blog. Tier T3 for this claim: the vendor ran its own system against a benchmark it chose, and reported the comparison. The evaluation code is public, which is more than most of the corpus offers, but nobody independent has run it. FinanceBench is a real third-party benchmark (arXiv 2311.11944), so the task is not invented — the grading of it is.

Read against gbrain's "+31.4 points P@5 from the graph" and hybrid-retrieval-rag's Perplexity/Glean validation, this is a third self-reported retrieval win on a third axis, and the corpus still has no source that benchmarks these alternatives against each other. That remains an open question, not a settled ranking.

Commercial shape

Local and open-source by default; a paid PageIndex Cloud tier (PAGEINDEX_API_KEY) adds OCR for scanned PDFs, faster structure generation, and scale. There is also a hosted chat product, an MCP server, and a "PageIndex File System" that extends tree indexing from one document to a whole corpus — the same move openkb's roadmap makes at the wiki layer. openkb is Apache-2.0 and free; the long-document path inside it runs on the open-source PageIndex, with the cloud tier as an upsell.

Related

openkb · vectifyai · retrieval-augmented-generation · hybrid-retrieval-rag · long-context-vs-chunking · knowledge-graph · gbrain · llm-wiki · model-context-protocol