Vector RAG vs Vectorless(Page Index) RAG

Why Vector RAG Is Not the Whole Story

Vector RAG splits documents into fixed-size chunks, generates an embedding vector per chunk, stores those vectors in a vector database, and at query time embeds the query and retrieves the K nearest vectors. The LLM answers from whatever chunks came back. The document’s structure — its sections, its argument flow, its hierarchy — is lost the moment chunking begins.

PageIndex takes a different position. Instead of flattening a document into a sequence of chunks, it builds a hierarchical tree index that preserves the document’s structure. Instead of retrieving by vector similarity, it lets an LLM agent navigate that structure the way a human reader would — scanning the table of contents, identifying relevant sections, and reading exactly the pages that matter.

2. A Comparison ( Page Index vs Vector RAG):

How PageIndex JSON Tree Actually Looks Like

{
  "doc_id": "it-support-rules-v1",
  "doc_name": "IT_Support_Ticketing_Rules.pdf",
  "page_count": 12,
  "nodes": [
    {
      "node_id": "0001",
      "title": "Purpose",
      "page_index": 1,
      "text": "Defines the rules, criteria, and workflows for classifying IT support tickets by severity level and routing them to the appropriate team.",
      "nodes": []
    }
  ]
}

Notice what is in the text field of each node. It is not a page reference. It is not a heading. It is a summary of the actual content — specific enough for an agent/LLM to get the context. This is the critical insight: the tree itself carries sufficient information for reasoning on a well-structured document. g

Example:

Below is an example of a ticket system where raised tickets need to classify

Title: Production PostgreSQL database completely unreachable
Description: All users getting 500 errors. Started 10 minutes ago.
Affected users: all users
Environment: Production
Impact: No one can log in. Revenue impacted.

Vector RAG

Vector RAG retriever returns the K=5 nearest chunks. What comes back depends entirely on how the document was chunked. There is no structure awareness. The retriever does not know that “Keyword Triggers” and “Severity Assignment Rules” are sibling sections under “Ticket Assignment Rules.” It knows only cosine distance.

# Vector RAG — what the agent sees
retrieved_chunks = [
    "NET handles wifi, vpn, network, internet connectivity...",   # wrong chunk
    "DBA handles database downtime, connection failures...",      # right team
    "SEV-2: core feature broken for 30%+ users...",              # wrong severity
    "Application errors, 500 errors, API failures...",           # wrong team
    "Escalation: SEV-2 unresolved after 8hrs escalates..."       # irrelevant
]
# Agent has to reason across mismatched, partially relevant chunks
# No guarantee SEV-1 criteria and DBA assignment appear together

PageIndex — Passing the JSON Tree

With PageIndex, the agent receives the complete JSON tree in its prompt. No vector search. No graph traversal. The agent reads the tree the way a senior engineer reads a document — skims the structure, identifies the relevant nodes from their summaries, and reads only the pages that matter. Below is a tree structure snippet.

Node 1 text: "SEV-1: full system outage affecting all users,
                  production database down..."
  → "all users", "Production", "database completely unreachable"
  → matches SEV-1 criteria exactly → severity: SEV-1

Node 2 text: "SEV-1: Response SLA 15 minutes, Resolution SLA 4 hours"
  → SLA confirmed from tree
Result: { "team_code": "DBA", "severity": "SEV-1", ... }

Where PageIndex Fits in the Retrieval Landscape

Vector RAG is the right default for document search at scale where structure is heterogeneous, data is fully private, and retrieval needs to work across thousands of documents simultaneously. It is the architecture behind most production RAG systems today, and for good reason — it is proven, fast, and operationally straightforward.

PageIndex is the right choice when documents are structured, when the hierarchy carries meaning, and when you want an agent to reason over a document the way a domain expert would — by reading the structure first, then fetching exactly what the question requires.

The question is not which approach is best in the abstract. It is which approach fits the structure of your documents, the nature of your queries, and the constraints of your production environment.

Closing Thoughts

Each retrieval architecture answers a different question when the agent queries the knowledge base. Vector RAG asks: what text is semantically similar to this query? PageIndex asks: what part of this document’s structure is relevant to this query?

References:

• PageIndex Documentation: https://docs.pageindex.ai
• Previous article: The Validated RAG Ingestion Pipeline — https://medium.com/@karnawat.saurabh/the-validated-rag-ingestion-pipeline-589a383c294b