page_index

This vectorless, vision RAG notebook passes PDF page images directly to Vision Language Models without OCR or embeddings. This eliminates the text extraction pipeline entirely, no layout detection, no character recognition, no vector search — only visual reasoning over document images, retrieved through reasoning-based hierarchical tree search.

This challenges a foundational assumption in document AI: that text must first be extracted before it can be understood. Traditional RAG pipelines depend on OCR for text recognition, chunk the extracted text, embed those chunks into vectors, and retrieve by similarity.

Each transformation step introduces error: tables fragment, spatial relationships dissolve, annotations separate from their anchors. Vectorless Vision RAG collapses this multi-stage process into just two steps: reasoning-based page retrieval, then visual interpretation. The VLM sees the document as it was meant to be read — a complete visual artifact with intact structure, typography, and spatial semantics.

The implication isn't that OCR or embeddings are obsolete, it's that preprocessing pipelines should justify their complexity cost. When the final model itself can consume the original representation, intermediate transformations become architectural overhead, rather than enabling infrastructure, a relic of a text-first paradigm in a world moving toward reasoning-native, vectorless document understanding.

In modern document question answering (QA) systems, OCR serves an important role by converting PDF pages into text that can be processed by Large Language Models (LLMs). The resulting text can provide contextual input that enables LLMs to perform question answering over document content.

Traditional OCR systems typically use a two-stage process that first detects the layout of a PDF — dividing it into text, tables, and images — and then recognizes and converts these elements into plain text. With the rise of vision-language models (VLMs) (such as Qwen-VL and GPT-4.1), new end-to-end OCR models like DeepSeek-OCR have emerged. These models jointly understand visual and textual information, enabling direct interpretation of PDFs without an explicit layout detection step.

However, this paradigm shift raises an important question:

> If a VLM can already process both the document images and the query to produce an answer directly, do we still need the intermediate OCR step?

We build a practical vectorless, vision-based question-answering implementation for long documents, without relying on OCR. Specifically, we adopt a vectlorless, reasoning-based retrieval layer and the multimodal GPT-4.1 as the VLM for visual reasoning and answer generation.

In modern document question answering (QA) systems, OCR serves an important role by converting PDF pages into text that can be processed by Large Language Models (LLMs). The resulting text can provide contextual input that enables LLMs to perform question answering over document content.

Traditional OCR systems typically use a two-stage process that first detects the layout of a PDF — dividing it into text, tables, and images — and then recognizes and converts these elements into plain text. With the rise of vision-language models (VLMs) (such as Qwen-VL and GPT-4.1), new end-to-end OCR models like DeepSeek-OCR have emerged. These models jointly understand visual and textual information, enabling direct interpretation of PDFs without an explicit layout detection step.

However, this paradigm shift raises an important question:

> If a VLM can already process both the document images and the query to produce an answer directly, do we still need the intermediate OCR step?

We build a practical vision-based question-answering implementation for long documents, without relying on OCR. Specifically, we adopt a vectlorless, reasoning-based retrieval layer and the multimodal GPT-4.1 as the VLM for visual reasoning and answer generation.

Large language models (LLMs) have revolutionized natural language processing (NLP), particularly through Retrieval-Augmented Generation (RAG), which enhances LLM capabilities by integrating external knowledge. However, traditional RAG systems face critical limitations, including disrupted contextual integrity due to text chunking, and over-reliance on semantic similarity for retrieval. To address these issues, we propose CausalRAG, a novel framework that incorporates causal graphs into the retrieval process. By constructing and tracing causal relationships, CausalRAG preserves contextual continuity and improves retrieval precision, leading to more accurate and interpretable responses. We evaluate CausalRAG against regular RAG and graph-based RAG approaches, demonstrating its superiority across several metrics. Our findings suggest that grounding retrieval in causal reasoning provides a promising approach to knowledge-intensive tasks.

The word index originally came from how humans retrieve information: book indexes and tables of contents that guide us to the right place.

Computers later borrowed the term for data structures such as B-trees, hash tables, and more recently, vector indexes. They're highly efficient for machines, but also abstract and unnatural: not something a human, or an LLM, can directly use as a reasoning aid. This creates a gap between how indexes work for computers and how they should work for models that reason like humans.

PageIndex is a new step that looks back to move forward. It revives the original, human-oriented idea of an index and adapts it for LLMs. Now the index itself (PageIndex) lives inside the LLM's context window: the model sees a hierarchical table-of-contents tree and reasons its way down to the right span, much like a person would retrieve information using a book's index.

PageIndex MCP shows how this works in practice: it runs as a MCP server, exposing a document's structure directly to LLMs. This means platforms like Claude, Cursor, or any MCP-enabled agent can navigate the index themselves and reason their way through documents, not with vectors or chunking, but in a human-like, reasoning-based way.

Lol you mean vector db is more like hash_map. map is more tree based

I have page index in my book :)

I guess the major foucs in certain uses cases is not speed but accuracy and retrieval quality.

curious about the other attempt you see

LOL ctrl-f feels like bm25 vector search

In specific domains, accuracy matters more than than speed. Document structure and reasoning bring better retrieval than semantic search which retrieves "similar" but not "relevant" results.

you can use document search straedgies (like SQL metadata search, semantic search etc, doc descrption search by LLM) to narrow down the doc candidates first.

github repo: github.com/VectifyAI/PageIndex