Researchers built a new RAG approach that: - does not need a vector DB. - does not embed data. - involves no chunking. - performs no similarity search. And it hit 98.7% accuracy on a financial benchmark (SOTA). Here's the core problem with RAG that this new approach solves:... Traditional RAG chunks documents, embeds them into vectors, and retrieves based on semantic similarity. But similarity ≠ relevance. When you ask "What were the debt trends in 2023?", a vector search returns chunks that look similar. But the actual answer might be buried in some Appendix, referenced on some page, in a section that shares zero semantic overlap with your query. Traditional RAG would likely never find it. PageIndex (open-source) solves this. Instead of chunking and embedding, PageIndex builds a hierarchical tree structure from your documents, like an intelligent table of contents. Then it uses reasoning to traverse that tree. For instance, the model doesn't ask: "What text looks similar to this query?" Instead, it asks: "Based on this document's structure, where would a human expert look for this answer?" That's a fundamentally different approach with: - No arbitrary chunking that breaks context. - No vector DB infrastructure to maintain. - Traceable retrieval to see exactly why it chose a specific section. - The ability to see in-document references ("see Table 5.3") the way a human would. But here's the deeper issue that it solves. Vector search treats every query as independent. But documents have structure and logic, like sections that reference other sections and context that builds across pages. PageIndex respects that structure instead of flattening it into embeddings. Do note that this approach may not make sense in every use case since traditional vector search is still fast, simple, and works well for many applications. But for professional documents that require domain expertise and multi-step reasoning, this tree-based, reasoning-first approach shines. For instance, PageIndex achieved 98.7% accuracy on FinanceBench, significantly outperforming traditional vector-based RAG systems on complex financial document analysis. Everything is fully open-source, so you can see the full implementation in GitHub and try it yourself. I have shared the GitHub repo in the replies!show more

GitHub repo: (don't forget to star it ⭐ )

If you found it insightful, reshare it with your network. Find me → @_avichawla Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.

this is the pattern i keep seeing with ai: "here's the complex infrastructure you need" (6 months later) "actually, you don't need any of that" the tools are simplifying faster than people can implement the old approaches. sometimes the best move is waiting.

The problem here remains extracting / encoding the structure of the document. Does this help with that at all? Being able to search isn’t useful if you can’t reliably transform lots of documents into this searchable data structure.

there are chunks.

When you have millions or billions nodes and subnodes in PageIndex’s json data format, how does it find the most relevant one? Reading all the json with an LLM?

@grok how does this compare to RLM (

There are some limitations though! PageIndex incurs higher latency and LLM costs due to per-query reasoning, making it less ideal for real-time or massive datasets. Traditional RAG remains preferable for broad, flat corpora like FAQs or web pages.

I... understand the impulse behind this, and certainly a non-vectored file store is a sensible tool to have but... Friend, this is the work of folks who couldn't handle RAG and so had to build the kiddie pool version. It's the only way they could keep pretending to be lifeguards. This is the sort of tool built by coders who dump 200 page ledgers and tech docs into a rag and expect the model to just know it all. Folks who think RAGs are for "golden truths" and oracles. They are people simple don't understand WHAT RAG _IS_. It's a strategic backup context tank. It's prompting on demand. It's giving your model a subconscious. This is like watching people say "Flying planes is hard. We can just build a 600 story building any time we want to get to that spot in the sky."

"similarity != relevance" is marketing bullshit. Modern RAG moved past naive top_k years ago... reranking, hybrid search, query decomposition, HyDE) framing vector RAG as "vibe retrieval" is a strawman from 2022-23))) and bench is a cherry picked... right?) of course it is try this on messy real world PDFs with inconsistent formatting and scanned pages or just.... typical enterprise documentation)) and yea... how many tokens get burned with just 100 users?)

But if you have to look in a DB of tens of thousands of documents, this approach will not scale

This is indeed a really interesting approach. Let me dig more into this. Thanks for sharing.

Why don’t you just brood knowledge graphs? And lean into meta data. I solved this long time ago with literally seemingly perfect results

I call it BS. They are still using an LLm to generate the summary field of a chunk. That in itself is like a vector

Looks very cool. Here is my version of the approach . You can install it with a skill `npx skills add --skill rusty-page-indexer`. Made it work with folders and as cli, both local and remote LLM that support OpenAI

We got them beat - 100%

@grok fact check and why this sounds like too good to be true?

PageIndex doesn’t replace vector RAG - it replaces flat retrieval for deeply structured documents where relevance is defined by document logic, not semantic proximity.

If this holds up, it’s a big ops win: no embeddings, no chunking, no vector DB means less plumbing and fewer silent failure modes. RAG in prod usually dies on retrieval drift and context pollution, not the model. Curious to read the core idea.

This is the real fix for RAG. Structure beats similarity when the docs actually matter.

I like the idea of this but it can’t scale

Thanks for the shoutout! PageIndex is a vectorless, reasoning-based RAG engine that mirrors how humans read — delivering traceable, explainable retrieval without vector DBs or chunking.

Creating documents like structured knowledge just makes sense.

PageIndex is clever,reasoning over structure beats blind similarity every time for dense docs like financials. No chunking or vector DB is the real win: preserves context, traceable paths, fewer hallucinations. 98.7% on FinanceBench is impressive, but production speed and cost at scale will decide if it replaces vector RAG broadly.

That's serious stuff! So annoying to chunk doc in pieces in a weirdo database only a computer can understand. Kudos to them

@grok what are retrieval costs on this compared to RAG say for a law firm that has 100,000+ documents

So this is basically GraphRAG?

Hmm, good embedding models should help you find, semantically related vectors, not necessarily similar in the way you describe it.

Treating documents as structured systems instead of flat text feels like the obvious next step. Relevance usually lives in hierarchy, not similarity.

Cc @AgnoAgi

This PageIndex approach is a clever rethink of RAG

Ok when you have a small bunch of documents, you can build a Notebook LM like, but when you have a million documents database I'm not sure it will work.

@pelaseyed

Interesting!

@grok first matters

This is really cool, can’t wait to try on some tricky data set