For a large collection of structured reports with reliable headings, page numbers, and tables, when would you choose vectorless retrieval such as PageIndex over embeddings, and what failure modes would you expect from each approach?
Choose PageIndex-style retrieval when document hierarchy, page locations, and table boundaries are trustworthy and questions depend on sections, time periods, or auditable citations. Use embeddings when the corpus is less structured or queries rely on paraphrase; in production, a hybrid often wins because each fails differently.
How to think about it
For a large archive of well-formed reports, I would choose PageIndex-style vectorless retrieval when the question can be answered by navigating the report hierarchy and must cite the right page or table. I would choose embeddings when the corpus is messy or the query depends on paraphrase across sections; in a serious system, I would usually combine them rather than treat them as rival religions.
Why the document structure changes the answer
An embedding is a numerical representation of text. An embedding-based retriever splits documents into chunks, converts each chunk into a vector, and returns the chunks whose vectors are closest to the query vector. “Closest” means semantically similar, not necessarily correct for the requested entity, date, table row, or page.
That distinction matters in reports.
A report is not merely a bag of paragraphs. It has a hierarchy:
- a document belongs to an organization and reporting period;
- a chapter contains sections;
- a section contains prose and tables;
- a table has a title, units, column headings, row labels, footnotes, and a page location.
PageIndex is a vectorless, reasoning-based approach that represents that hierarchy as a tree. A node might say “Capital adequacy,” contain its page range, and have child nodes for “Common equity tier 1 ratio” and “Risk-weighted assets.” Retrieval then navigates from the document or collection root into the relevant branches before reading the selected pages.
The important signal is topology: where information lives and what it belongs to. It is not distance in an embedding space.
That is valuable because table meaning is relational. The number 12.4 is useless without knowing whether it means percent, millions of dollars, a current-period value, or a prior-period value. A chunker may separate the number from its heading or footnote. A structure-aware index has a better chance of keeping those pieces together and pointing the model to the original page.
Vectorless does not mean “no model” or “no indexing.” Building and navigating the tree may require language-model calls. It means the system is not relying on vector similarity as its primary route to evidence.
A concrete scenario
Imagine an archive containing 10,000 quarterly bank reports, each 70 pages long: 700,000 pages in total. Every report uses stable headings such as “Capital Adequacy,” “Liquidity Risk,” and “Credit Exposure.” The reports also contain consistently formatted tables.
A user asks:
What was Bank North’s common equity tier 1 ratio in March 2025, and where is it reported?
A structure-aware system can use metadata to select Bank North and the March 2025 report, navigate to “Capital Adequacy,” then inspect the relevant table. Suppose the table is printed on page 42 but appears as PDF page 47 because the file has five pages of front matter. A good index preserves both identifiers. The answer can cite the table and explain the numbering difference.
An embedding retriever might also succeed. If the relevant chunk contains “common equity tier 1 ratio” and “March 2025,” it has a straightforward target. But it may instead return the executive summary, a prior-quarter discussion, or a similar table from another bank. The words are semantically close. The evidence is still wrong.
The advantage becomes clearer with a question such as:
Compare the liquidity coverage ratio disclosures in the risk section for Bank North’s March and June 2025 reports.
The report hierarchy gives the system a natural route: two known documents, one known section, then the corresponding pages and tables. Embeddings can retrieve the right passages, but they have to infer the bank, dates, section identity, and comparison set from a flat collection of chunks.
That is the case for PageIndex: when the document’s structure is reliable and structure itself answers part of the retrieval problem.
Expected failure modes
Neither approach is magic. They fail for different reasons.
| Approach | What commonly goes wrong | First symptom |
|---|---|---|
| Embeddings | The retriever finds semantically similar text from the wrong year, entity, or version | Citations cluster around a general summary or the wrong reporting period |
| Embeddings | Chunking splits a table from its title, units, headers, or footnotes | The answer gives a plausible number with the wrong unit or row |
| Embeddings | Repeated boilerplate dominates the nearest-neighbor results | Several top results say nearly the same generic thing |
| PageIndex | Heading detection or PDF parsing builds the wrong tree | The system says no relevant section exists, although the phrase is visibly in the report |
| PageIndex | The language model chooses the wrong branch during navigation | It cites a nearby section with a convincing but irrelevant explanation |
| PageIndex | Page labels are confused with PDF offsets, or scanned pages are misread | The cited page is off by one or contains the wrong table |
| PageIndex | Tree navigation requires several model calls | Latency and cost rise, especially for broad cross-document questions |
Embedding retrieval is particularly vulnerable to entity and time mistakes. “Revenue increased” appears in thousands of reports. Without strong metadata filters, the retriever can return a highly similar sentence from 2024 when the user asked about 2025. Adding metadata filters and reranking helps, but those are engineering fixes, not properties embeddings provide automatically.
Embeddings also have a numeric weakness. Language-model embeddings are good at semantic similarity, but exact identifiers, small decimal differences, and table coordinates are not semantic concepts in the ordinary sense. A query for “3.75 percent in Q2” may retrieve text about “3.8 percent in Q1” because the surrounding language is nearly identical.
PageIndex has its own sharp edges. It depends on the source structure being correctly extracted. A scanned PDF may need optical character recognition, or OCR, which can turn 8.6% into 86% or mistake a multi-column heading for body text. A stable visual layout does not guarantee a stable machine-readable tree.
It also depends on navigation decisions. If the user asks an ambiguous question such as “What did the company report about exposure?”, several branches may be reasonable: credit exposure, geographic exposure, or market exposure. The tree makes those branches visible, but it does not eliminate ambiguity. The system still needs clarification, broader search, or a fallback retriever.
Finally, a tree can locate a table without correctly interpreting it. Extracting a value, matching it to the right row, applying a footnote, and calculating a year-over-year change are separate tasks. Retrieval supplies evidence. It does not turn a language model into an accounting system.
The senior answer: use the structure, but keep a fallback
I would not make this a pure PageIndex-versus-embeddings decision.
For this archive, I would make the report tree the primary route. I would store document metadata such as organization, reporting period, document type, printed page, PDF page, section title, table title, and source hash. I would preserve table regions rather than flattening every page into ordinary prose.
Then I would add fallback paths:
- Use exact or lexical search for unusual identifiers, numbers, and named entities.
- Use embeddings for unstructured appendices, narrative language, and questions that cross section boundaries.
- Use a reranker or a language model to compare candidates.
- Answer only from retrieved evidence, with page and table citations.
- Validate extracted numbers against the source table before performing arithmetic.
The textbook answer is that structure-aware retrieval wins on structured documents. The more precise answer is that it wins when the structure is both reliable and relevant to the question. If the reports have consistent headings but users ask broad questions such as “How are companies responding to supply-chain pressure?”, embeddings may still be better because the relevant language can appear under many unrelated headings.
The trade-off is also operational. A PageIndex-style tree may deliver better provenance and fewer context fragments, but constructing and navigating it can require more model work. Embeddings usually offer mature, fast approximate search over large collections, especially when the index is already built. If the product needs sub-second autocomplete over millions of short records, a tree-navigation system may be the wrong tool.
What they’ll ask next
“Would you ever use embeddings here?”
Yes. I would use them as a fallback or a second retrieval channel. They are useful for paraphrases, inconsistent headings, appendices, and questions that do not map neatly to the report taxonomy. I would merge their candidates with structure-based candidates and then rerank.
“How would you evaluate the choice?”
Build a representative test set containing exact table lookups, wrong-period traps, cross-report comparisons, ambiguous section names, and scanned documents. Measure whether the correct evidence was retrieved, whether citations point to the right page and table, whether the numeric answer is correct, and the latency and cost per query. Answer quality alone can hide a citation failure.
“Can PageIndex solve table questions?”
It can improve table retrieval by preserving the table’s place in the document and its surrounding context. It does not guarantee correct cell extraction or arithmetic. I would use a table-aware parser and deterministic validation for important numbers.
One line to say in the room
“I’d prefer PageIndex when the report hierarchy and page-level provenance are trustworthy, use embeddings for semantic escape hatches, and expect PageIndex to fail on bad structure while embeddings fail on similarity without enough identity, time, and table context.”