Lately I keep seeing this everywhere:
“RAG is dead”
“Vector search is outdated”
“Reasoning-based retrieval is the future”
And suddenly… everyone is talking like vector search is useless.
I’m not against the hype. These things happen.
But honestly, this whole idea didn’t just click for me immediately.
Because for me, this problem was already in my head for a long time.
Not because of hype.
Just because of my use case.
What I Was Actually Trying to Figure Out
I read a lot of long tech blogs and architecture posts.
After reading, I always have questions like:
- “why did they do this?”
- “what’s the tradeoff here?”
- “what happens if we change this design?”
So I wanted a system where I can:
- paste a document
- ask questions
- actually get useful answers
At some point I started thinking:
should I just stick with vector RAG?
or should I try something like PageIndex / reasoning-based retrieval?
or even something like Agent-style flow later?
That curiosity is what pushed me to build this.
Not the “RAG is dead” trend.
So I Built a Simple Comparison
Nothing fancy.
Just a small app where:
- same document
- same question
- same model
- only retrieval changes
Pipeline 1 — Vector RAG
- split document
- embed
- store in ChromaDB
- retrieve top-k
- answer
This is what most of us are already doing.
Pipeline 2 — PageIndex
- build a tree structure from the document
- let the model navigate it
- pick relevant sections
- answer from that
This felt very different.
Not “searching”.
More like… “reading with guidance”.
What I Noticed
The difference is actually deeper than I expected.
Vector RAG:
find similar chunks
PageIndex:
figure out where the answer should be, then go there
That “where” part is interesting.
One Example
I tested with a Netflix architecture article.
Question:
Why did they use live origin instead of only CDN?
Vector RAG
- faster (~7s)
- decent answer
- but retrieval had some noise
PageIndex
- slower (~11s)
- answer felt more precise
- citations were cleaner
My Honest Take
Vector RAG is not dead.
But…
Blind chunking + embedding + top-k is not enough anymore (at least for some cases).
Where I See the Difference
Vector RAG works well when:
- you have multiple documents
- you want speed
- you just need “good enough” answers
PageIndex works well when:
- single long document
- structured content
- you want cleaner reasoning
What I’m Actually Thinking Now
I don’t think this is:
“one replaces the other”
Feels more like:
both solve different parts of the problem
What I’m more interested in now is:
- can I combine them?
- use vector search to find documents
- then use something like PageIndex inside that?
That feels more practical.
Why I’m Exploring This
For my use case, I’m also thinking about:
- can I plug this into an agent flow later?
- how does retrieval affect agent decisions?
- does better retrieval reduce hallucination in multi-step tasks?
That’s where this is going for me.
Final Thought
Honestly, I didn’t build this to prove anything.
Just to understand.
And one thing became clear very fast:
hype says “X is dead”
reality says “it depends”
If you’re building something similar, I’d really suggest:
Don’t pick a side early.
Test both.
You’ll understand the difference immediately.
Top comments (0)