What is vectorless retrieval (PageIndex), and when would you use it over a vector database?
Vectorless retrieval skips embeddings entirely: it organizes a document into a hierarchical tree (titles, summaries, page ranges) and the LLM reasons a path down it — root to chapter to section — then reads only the chosen section to answer. It is structure-aware and explainable, but it spends an LLM call at each hop, so it suits a small number of well-structured documents. A vector database is the opposite trade: one millisecond ANN lookup that scales to millions of chunks but is flat and blind to document structure. Use vectors for large, messy corpora and speed; use PageIndex for bounded structured docs where the answer is found by reasoning about where it lives; combine them by shortlisting with vectors then navigating within a document.
How to think about it
Vector RAG embeds every chunk and the query, then retrieves the top-k nearest by cosine similarity. Fast, scalable — but flat: it ignores where a passage sits in the document and can return plausible-but-wrong neighbours.
PageIndex (vectorless) builds a tree of the document — essentially its table of contents, with a summary and page range per node — and the LLM navigates it: at each level it reasons which branch is most relevant, descends, and finally reads just the chosen section.
| Vector search | PageIndex | |
|---|---|---|
| Index | embeddings + ANN | parsed document tree |
| Per-query cost | one ANN lookup (ms) | one LLM call per hop |
| Scales to | millions of chunks | bounded structured docs |
| Strength | speed, recall at scale | structure-aware, explainable |
When to use which: vectors for huge, messy corpora where speed and recall matter; PageIndex for a few well-structured documents (a contract, a 10-K) where the question needs reasoning about where the answer lives.