Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: PageIndex – Vectorless RAG

github.com

Post reply on HN
Print view View original

1–10 of 147 posts

Show HN: PageIndex – Vectorless RAG

#1

Post by page_index »

Not all improvements come from adding complexity — sometimes it's about removing it.

PageIndex takes a different approach to RAG. Instead of relying on vector databases or artificial chunking, it builds a hierarchical tree structure from documents and uses reasoning-based tree search to locate the most relevant sections. This mirrors how humans approach reading: navigating through sections and context rather than matching embeddings.

As a result, the retrieval feels transparent, structured, and explainable. It moves RAG away from approximate "semantic vibes" and toward explicit reasoning about where information lives. That clarity can help teams trust outputs and debug workflows more effectively.

The broader implication is that retrieval doesn't need to scale endlessly in vectors to be powerful. By leaning on document structure and reasoning, it reminds us that efficiency and human-like logic can be just as transformative as raw horsepower.

Show HN: PageIndex – Vectorless RAG
github.com

Re: Show HN: PageIndex – Vectorless RAG

#4

Post by mosselman »

So if I understand this correctly it goes over every possible document with an LLM each time someone performs a search?

I might have misunderstood of course.

If so, then the use cases for this would be fairly limited since you'd have to deal with lots of latency and costs. In some cases (legal documents, medical records, etc) it might be worth it though.

An interesting alternative I've been meaning to try out is inverting this flow. Instead of using an LLM at time of searching to find relevant pieces to the query, you flip it around: at time of ingesting you let an LLM note all of the possible questions that you can answer with a given text and store those in an index. You could them use some traditional full-text search or other algorithms (BM25?) to search for relevant documents and pieces of text. You could even go for a hybrid approach with vectors on top or next to this. Maybe vectors first and then more ranking with something more traditional.

What appeals to me with that setup is low latency and good debug-ability of the results.

But as I said, maybe I've misunderstood the linked approach.

Re: Show HN: PageIndex – Vectorless RAG

#6

Post by brap »

Very cool. These days I’m building RAG over a large website, and when I look at the results being fed into the LLM, most of them are so silly it’s surprising the LLM even manages to extract something meaningful. Always makes me wonder if it’s just using prior knowledge even though it’s instructed not to do so (which is hacky).

I like your approach because it seems like a very natural search process, like a human would navigate a website to find information. I imagine the tradeoff is performance of both indexing and search, but for some use cases (like mine) it’s a good sacrifice to make.

I wonder if it’s useful to merge to two approaches. Like you could vectorize the nodes in the tree to give you a heuristic that guides the search. Could be useful in cases where information is hidden deep in a subtree, in a way that the document’s structure doesn’t give it away.

Re: Show HN: PageIndex – Vectorless RAG

#7

Post by neya »

This is good for applications where a background queue based RAG is acceptable. You upload a file, set the expectation to the user that you're processing it and needs more time for a few hours and then after X hours you deliver them. Great for manuals, documentation and larger content.

But for on-demand, near instant RAG (like say in a chat application), this won't work. Speed vs accuracy vs cost. Cost will be a really big one.

Re: Show HN: PageIndex – Vectorless RAG

#10

Post by kruxigt »

neya wrote: post #7

This is good for applications where a background queue based RAG is acceptable. You upload a file, set the expectation to the user that you're processing it and needs more time for a few hours and then after X hours you deliver them. Great for manuals, documentation and larger content. But for on-demand, near instant RAG (like say in a chat application), this won't work. Speed vs accuracy vs cost. Cost will be a real…

[dead]
Post reply on HN