PageIndex

VectifyAIMIT活跃维护

面向 RAG 的文档索引方案,不依赖向量数据库,用推理方式定位和检索文档内容,适合构建 Agent 式检索流程。

📑 PageIndex: Document Index for Vectorless, Reasoning-based RAG

v0.5.3发布于 2026-11-05 18:16 UTC40,324star +163 / 7 天3,471fork同步于 2026-11-10 05:19 UTC

怎么上手

由 README 提炼,执行前请确认
pip install -U pageindex
硬件要求按 README 说明

README 未说明显存或 GPU 要求,本地模式主要依赖所配置的 LLM API(如 OpenAI),也可通过 Claude Code 订阅调用 Claude 模型

下载:源码 zip·GitHub Releases(安装包)本站不镜像安装包

项目说明

由 README 自动翻译提炼

用树形索引加 LLM 推理替代向量检索的 RAG 引擎,专治长文档问答

面向 RAG 的文档索引方案,不依赖向量数据库,用推理方式定位和检索文档内容,适合构建 Agent 式检索流程。

核心能力

  • 为每篇文档生成层级树索引,不做切块也不建向量库
  • 检索时由 LLM 在树上有推理地逐层定位相关章节
  • 检索结果可追溯到具体页码,过程可解释
  • 索引模型只需基础模型,聊天模型决定检索质量
  • 支持本地与云端两种模式,云端额外提供 OCR 与图像理解

容易踩的坑

需要自备 OPENAI_API_KEY 等模型 API key,否则无法建索引和问答;本地模式只适合文本型 PDF,扫描件和图片多的文档要用云端模式;用 Claude 订阅需额外安装 pip install -U "pageindex[claude]" 并把模型名加 claude-code/ 前缀

内容由模型根据 README 生成,可能不完整或不准确,以官方文档为准。看原文 README

最近发版

5 个版本v0.5.3
  1. v0.5.3PageIndex 0.5.3 — Lower Cost, Higher Accuracy than Vector RAG最新正式版2026-11-05 · 2026-11-05 18:16 UTC
    • Cheaper than vector RAG: for both index and query.
    • Faster: trees are created from layout stats.
    • Unified SDK: vectorless RAG. Local or cloud, for index and chat.
    • Runs on your Claude subscription.

    Index, to chat, to agent integration, one client. Local mode needs no server, no vector DB, no PageIndex API key.

    client = PageIndexClient()
    client.submit_document("report.pdf")
    client.chat("What does the report conclude?")
    

    Highlights

    • Flash engine: the local default (mode="standard" keeps the classic LLM pipeline). Embedded bookmarks are consumed when trustworthy, and tree optimization is on by default — optimize="merge" for the deterministic LLM-free pass, "full" (default) adds LLM expand, which runs a wave of nodes concurrently instead of one round-trip at a time.
    • One complete surface, local and cloud: PageIndexLocalClient(storage_path=...) is the same client as cloud — submit, tree, page content, chat, and agent tools all present in both modes, so code moves between them unchanged.
    • Cloud documents, your own model: api_key decides where your documents live; a configured chat model decides who answers — and the two combine. PageIndexClient(api_key="pi-...", chat_model="openai/gpt-5.2") runs the same in-process document-QA engine over the live cloud tool set. Page content flows through your process to your provider on your credentials; doc_id targets at the prompt level; enable_citations stays with the managed chat.
    • Agent integration: the cloud MCP tool contract, in-process — client.agent_tools() (plain functions), as_openai_tools(), as_anthropic_tools(), as_claude_mcp(), plus one-call openai_agent_config() / anthropic_runner_config() / claude_agent_config() bundles and agent_instructions() for the system prompt. Cloud clients get the live server tool set over the MCP bridge (read-only endpoint by default); local clients get the in-process subset with the same schemas and envelopes — agent prompts port unchanged.
    • Chat surfaces: chat() — question in, answer out, on any backend; chat(stream=True) shows the run as it happens, thinking and tool calls woven into the text, or as typed events via .events; chat(protocol="responses" | "messages") drives the OpenAI Responses or Anthropic Messages API natively with that protocol's own shapes, and chat_completions() keeps the OpenAI-compatible envelope — all with doc_id targeting, streaming, honest usage accounting, and prompt-cache continuity across turns. Transcripts append verbatim: a protocol lane's output goes back into the next request unchanged.
    • Model & connection knobs: index_model / chat_model, index_backend / chat_backend (and per-call backend) passed verbatim to each lane — LiteLLM-routed providers, keyless OpenAI-compatible servers, Azure/Bedrock/Vertex included.
    • index= / chat= slots: the grouped spelling of the flat arguments — a string shorthand or a mapping (index={"model": ..., "storage_path": ...}, chat={"model": ..., "backend": ...}). "cloud" / "local" name a side, an optional mode= cross-checks it, and PageIndexLocalClient / PageIndexCloudClient take the same slots. PageIndexCloudClient() reads PAGEINDEX_API_KEY; a bare PageIndexClient() stays local no matter what the environment holds.
    • Typed config shapes: IndexConfig / CloudIndexConfig / LocalIndexConfig / ChatConfig, with py.typed shipped so your type checker sees them.
    • Nothing fails quietly: unknown keys, mixed sides, empty values and mode/content conflicts refuse at construction with the legal vocabulary in the message; dead credentials or a missing model fail the indexing run instead of storing a document with blank summaries; every cloud error carries its HTTP status.
    • Dependencies: Python >= 3.10; openai-agents in the base install (the chat engine); [anthropic] and [claude] extras for those SDKs. Pillow >= 9.0 is n
  2. v0.5.2PageIndex 0.5.2 — Lower Cost, Higher Accuracy than Vector RAG2026-11-04 · 2026-11-04 11:07 UTC
    查看更新说明
    • Cheaper than vector RAG: for both index and query.
    • Faster: trees are created from layout stats.
    • Unified SDK: vectorless RAG. Local or cloud, for index and chat.
    • Runs on your Claude subscription.

    Index, to chat, to agent integration, one client. Local mode needs no server, no vector DB, no PageIndex API key.

    client = PageIndexClient()
    client.submit_document("report.pdf")
    client.chat("What does the report conclude?")
    

    Highlights

    • Flash engine: the local default (mode="standard" keeps the classic LLM pipeline). Embedded bookmarks are consumed when trustworthy, and tree optimization is on by default — optimize="merge" for the deterministic LLM-free pass, "full" (default) adds LLM expand, which runs a wave of nodes concurrently instead of one round-trip at a time.
    • One complete surface, local and cloud: PageIndexLocalClient(storage_path=...) is the same client as cloud — submit, tree, page content, chat, and agent tools all present in both modes, so code moves between them unchanged.
    • Cloud documents, your own model: api_key decides where your documents live; a configured chat model decides who answers — and the two combine. PageIndexClient(api_key="pi-...", chat_model="openai/gpt-5.2") runs the same in-process document-QA engine over the live cloud tool set. Page content flows through your process to your provider on your credentials; doc_id targets at the prompt level; enable_citations stays with the managed chat.
    • Agent integration: the cloud MCP tool contract, in-process — client.agent_tools() (plain functions), as_openai_tools(), as_anthropic_tools(), as_claude_mcp(), plus one-call openai_agent_config() / anthropic_runner_config() / claude_agent_config() bundles and agent_instructions() for the system prompt. Cloud clients get the live server tool set over the MCP bridge (read-only endpoint by default); local clients get the in-process subset with the same schemas and envelopes — agent prompts port unchanged.
    • Chat surfaces: chat() — question in, answer out, on any backend; chat(stream=True) shows the run as it happens, thinking and tool calls woven into the text, or as typed events via .events; chat(protocol="responses" | "messages") drives the OpenAI Responses or Anthropic Messages API natively with that protocol's own shapes, and chat_completions() keeps the OpenAI-compatible envelope — all with doc_id targeting, streaming, honest usage accounting, and prompt-cache continuity across turns. Transcripts append verbatim: a protocol lane's output goes back into the next request unchanged.
    • Model & connection knobs: index_model / chat_model, index_backend / chat_backend (and per-call backend) passed verbatim to each lane — LiteLLM-routed providers, keyless OpenAI-compatible servers, Azure/Bedrock/Vertex included.
    • index= / chat= slots: the grouped spelling of the flat arguments — a string shorthand or a mapping (index={"model": ..., "storage_path": ...}, chat={"model": ..., "backend": ...}). "cloud" / "local" name a side, an optional mode= cross-checks it, and PageIndexLocalClient / PageIndexCloudClient take the same slots. PageIndexCloudClient() reads PAGEINDEX_API_KEY; a bare PageIndexClient() stays local no matter what the environment holds.
    • Typed config shapes: IndexConfig / CloudIndexConfig / LocalIndexConfig / ChatConfig, with py.typed shipped so your type checker sees them.
    • Nothing fails quietly: unknown keys, mixed sides, empty values and mode/content conflicts refuse at construction with the legal vocabulary in the message; dead credentials or a missing model fail the indexing run instead of storing a document with blank summaries; every cloud error carries its HTTP status.
    • Dependencies: Python >= 3.10; openai-agents in the base install (the chat engine); [anthropic] and [claude] extras for those SDKs. Pillow >= 9.0 is n
  3. v0.5.1PageIndex 0.5.1 — Lower Cost, Higher Accuracy than Vector RAG2026-11-03 · 2026-11-03 04:58 UTC
    查看更新说明
    • Cheaper than vector RAG: for both index and query.
    • Faster: trees are created from layout stats.
    • Unified SDK: vectorless RAG. Local or cloud, for index and chat.
    • Runs on your Claude subscription.

    Index, to chat, to agent integration, one client. Local mode needs no server, no vector DB, no PageIndex API key.

    client = PageIndexClient()
    client.submit_document("report.pdf")
    client.chat("What does the report conclude?")
    

    Highlights

    • Flash engine: the local default (mode="standard" keeps the classic LLM pipeline). Embedded bookmarks are consumed when trustworthy, and tree optimization is on by default — optimize="merge" for the deterministic LLM-free pass, "full" (default) adds LLM expand, which runs a wave of nodes concurrently instead of one round-trip at a time.
    • One complete surface, local and cloud: PageIndexLocalClient(storage_path=...) is the same client as cloud — submit, tree, page content, chat, and agent tools all present in both modes, so code moves between them unchanged.
    • Cloud documents, your own model: api_key decides where your documents live; a configured chat model decides who answers — and the two combine. PageIndexClient(api_key="pi-...", chat_model="openai/gpt-5.2") runs the same in-process document-QA engine over the live cloud tool set. Page content flows through your process to your provider on your credentials; doc_id targets at the prompt level; enable_citations stays with the managed chat.
    • Agent integration: the cloud MCP tool contract, in-process — client.agent_tools() (plain functions), as_openai_tools(), as_anthropic_tools(), as_claude_mcp(), plus one-call openai_agent_config() / anthropic_runner_config() / claude_agent_config() bundles and agent_instructions() for the system prompt. Cloud clients get the live server tool set over the MCP bridge (read-only endpoint by default); local clients get the in-process subset with the same schemas and envelopes — agent prompts port unchanged.
    • Chat surfaces: chat() — question in, answer out, on any backend; chat(stream=True) shows the run as it happens, thinking and tool calls woven into the text, or as typed events via .events; chat(protocol="responses" | "messages") drives the OpenAI Responses or Anthropic Messages API natively with that protocol's own shapes, and chat_completions() keeps the OpenAI-compatible envelope — all with doc_id targeting, streaming, honest usage accounting, and prompt-cache continuity across turns. Transcripts append verbatim: a protocol lane's output goes back into the next request unchanged.
    • Model & connection knobs: index_model / chat_model, index_backend / chat_backend (and per-call backend) passed verbatim to each lane — LiteLLM-routed providers, keyless OpenAI-compatible servers, Azure/Bedrock/Vertex included.
    • index= / chat= slots: the grouped spelling of the flat arguments — a string shorthand or a mapping (index={"model": ..., "storage_path": ...}, chat={"model": ..., "backend": ...}). "cloud" / "local" name a side, an optional mode= cross-checks it, and PageIndexLocalClient / PageIndexCloudClient take the same slots. PageIndexCloudClient() reads PAGEINDEX_API_KEY; a bare PageIndexClient() stays local no matter what the environment holds.
    • Typed config shapes: IndexConfig / CloudIndexConfig / LocalIndexConfig / ChatConfig, with py.typed shipped so your type checker sees them.
    • Nothing fails quietly: unknown keys, mixed sides, empty values and mode/content conflicts refuse at construction with the legal vocabulary in the message; dead credentials or a missing model fail the indexing run instead of storing a document with blank summaries; every cloud error carries its HTTP status.
    • Dependencies: Python >= 3.10; openai-agents in the base install (the chat engine); [anthropic] and [claude] extras for those SDKs. Pillow >= 9.0 is n
  4. v0.5.0PageIndex 0.5.0 — Lower Cost, Higher Accuracy than Vector RAG2026-10-29 · 2026-10-29 22:53 UTC
    查看更新说明
    • Cheaper than vector RAG: for both index and query.
    • Faster: trees are created from layout stats.
    • Unified SDK: vectorless RAG. Local or cloud, for index and chat.
    • Runs on your Claude subscription.

    Index, to chat, to agent integration, one client. Local mode needs no server, no vector DB, no PageIndex API key.

    client = PageIndexClient()
    client.submit_document("report.pdf")
    client.chat("What does the report conclude?")
    

    Highlights

    • Flash engine: the local default (mode="standard" keeps the classic LLM pipeline). Embedded bookmarks are consumed when trustworthy, and tree optimization is on by default — optimize="merge" for the deterministic LLM-free pass, "full" (default) adds LLM expand, which runs a wave of nodes concurrently instead of one round-trip at a time.
    • One complete surface, local and cloud: PageIndexLocalClient(storage_path=...) is the same client as cloud — submit, tree, page content, chat, and agent tools all present in both modes, so code moves between them unchanged.
    • Cloud documents, your own model: api_key decides where your documents live; a configured chat model decides who answers — and the two combine. PageIndexClient(api_key="pi-...", chat_model="openai/gpt-5.2") runs the same in-process document-QA engine over the live cloud tool set. Page content flows through your process to your provider on your credentials; doc_id targets at the prompt level; enable_citations stays with the managed chat.
    • Agent integration: the cloud MCP tool contract, in-process — client.agent_tools() (plain functions), as_openai_tools(), as_anthropic_tools(), as_claude_mcp(), plus one-call openai_agent_config() / anthropic_runner_config() / claude_agent_config() bundles and agent_instructions() for the system prompt. Cloud clients get the live server tool set over the MCP bridge (read-only endpoint by default); local clients get the in-process subset with the same schemas and envelopes — agent prompts port unchanged.
    • Chat surfaces: chat() — question in, answer out, on any backend; chat(stream=True) shows the run as it happens, thinking and tool calls woven into the text, or as typed events via .events; chat(protocol="responses" | "messages") drives the OpenAI Responses or Anthropic Messages API natively with that protocol's own shapes, and chat_completions() keeps the OpenAI-compatible envelope — all with doc_id targeting, streaming, honest usage accounting, and prompt-cache continuity across turns. Transcripts append verbatim: a protocol lane's output goes back into the next request unchanged.
    • Model & connection knobs: index_model / chat_model, index_backend / chat_backend (and per-call backend) passed verbatim to each lane — LiteLLM-routed providers, keyless OpenAI-compatible servers, Azure/Bedrock/Vertex included.
    • index= / chat= slots: the grouped spelling of the flat arguments — a string shorthand or a mapping (index={"model": ..., "storage_path": ...}, chat={"model": ..., "backend": ...}). "cloud" / "local" name a side, an optional mode= cross-checks it, and PageIndexLocalClient / PageIndexCloudClient take the same slots. PageIndexCloudClient() reads PAGEINDEX_API_KEY; a bare PageIndexClient() stays local no matter what the environment holds.
    • Typed config shapes: IndexConfig / CloudIndexConfig / LocalIndexConfig / ChatConfig, with py.typed shipped so your type checker sees them.
    • Nothing fails quietly: unknown keys, mixed sides, empty values and mode/content conflicts refuse at construction with the legal vocabulary in the message; dead credentials or a missing model fail the indexing run instead of storing a document with blank summaries; every cloud error carries its HTTP status.
    • Dependencies: Python >= 3.10; openai-agents in the base install (the chat engine); [anthropic] and [claude] extras for those SDKs. Pillow >= 9.0 is n
  5. v0.4.7PageIndex 0.4.7 — Better retrieval than Vector RAG, at lower cost2026-10-24 · 2026-10-24 11:12 UTC
    查看更新说明
    • Cheaper than vector RAG: for both index and query.
    • Faster: trees are created from layout stats.
    • Unified SDK: vectorless RAG. Local or cloud, for index and chat.
    • Runs on your Claude subscription.

    Index, to chat, to agent integration, one client. Local mode needs no server, no vector DB, no PageIndex API key.

    client = PageIndexClient()
    client.submit_document("report.pdf")
    client.chat("What does the report conclude?")
    

    Highlights

    • Flash engine: the local default (mode="standard" keeps the classic LLM pipeline). Embedded bookmarks are consumed when trustworthy, and tree optimization is on by default — optimize="merge" for the deterministic LLM-free pass, "full" (default) adds LLM expand, which runs a wave of nodes concurrently instead of one round-trip at a time.
    • One complete surface, local and cloud: PageIndexLocalClient(storage_path=...) is the same client as cloud — submit, tree, page content, chat, and agent tools all present in both modes, so code moves between them unchanged.
    • Cloud documents, your own model: api_key decides where your documents live; a configured chat model decides who answers — and the two combine. PageIndexClient(api_key="pi-...", chat_model="openai/gpt-5.2") runs the same in-process document-QA engine over the live cloud tool set. Page content flows through your process to your provider on your credentials; doc_id targets at the prompt level; enable_citations stays with the managed chat.
    • Agent integration: the cloud MCP tool contract, in-process — client.agent_tools() (plain functions), as_openai_tools(), as_anthropic_tools(), as_claude_mcp(), plus one-call openai_agent_config() / anthropic_runner_config() / claude_agent_config() bundles and agent_instructions() for the system prompt. Cloud clients get the live server tool set over the MCP bridge (read-only endpoint by default); local clients get the in-process subset with the same schemas and envelopes — agent prompts port unchanged.
    • Chat surfaces: chat() — question in, answer out, on any backend; chat(stream=True) shows the run as it happens, thinking and tool calls woven into the text, or as typed events via .events; chat(protocol="responses" | "messages") drives the OpenAI Responses or Anthropic Messages API natively with that protocol's own shapes, and chat_completions() keeps the OpenAI-compatible envelope — all with doc_id targeting, streaming, honest usage accounting, and prompt-cache continuity across turns. Transcripts append verbatim: a protocol lane's output goes back into the next request unchanged.
    • Model & connection knobs: index_model / chat_model, index_backend / chat_backend (and per-call backend) passed verbatim to each lane — LiteLLM-routed providers, keyless OpenAI-compatible servers, Azure/Bedrock/Vertex included.
    • index= / chat= slots: the grouped spelling of the flat arguments — a string shorthand or a mapping (index={"model": ..., "storage_path": ...}, chat={"model": ..., "backend": ...}). "cloud" / "local" name a side, an optional mode= cross-checks it, and PageIndexLocalClient / PageIndexCloudClient take the same slots. PageIndexCloudClient() reads PAGEINDEX_API_KEY; a bare PageIndexClient() stays local no matter what the environment holds.
    • Typed config shapes: IndexConfig / CloudIndexConfig / LocalIndexConfig / ChatConfig, with py.typed shipped so your type checker sees them.
    • Nothing fails quietly: unknown keys, mixed sides, empty values and mode/content conflicts refuse at construction with the legal vocabulary in the message; dead credentials or a missing model fail the indexing run instead of storing a document with blank summaries; every cloud error carries its HTTP status.
    • Dependencies: Python >= 3.10; openai-agents in the base install (the chat engine); [anthropic] and [claude] extras for those SDKs. Pillow >= 9.0 is n

用户点评

登录用户的真实使用记录,可按版本和硬件筛选
共 0 条

    还没有人点评。第一个说出真实体验的人最有价值。

    README 原文

    未翻译

    PageIndex: Vectorless, Reasoning-based RAG

    • [Oct '26] 🔥 Page Search API: find the pages that answer each question in about a second, and send your LLM only those. Cut 97% token cost on document question answering; more accurate and faster than vector search (benchmark).
    • [Aug '26] PageIndex SDK: local and cloud modes — one client to index, retrieve, and chat on your machine (with your own LLM API key) or on PageIndex Cloud.
    • [Aug '26] ⚡ PageIndex Flash: fast tree index generation for text-based PDFs, now the default indexing method in PageIndex SDK local mode.
    • Scale PageIndex to Millions of Documents: PageIndex File System is a file-level tree indexing layer that lets PageIndex reason over an entire corpus, not just a single document.
    • PageIndex App: a human-like document analysis agent for long professional documents.

    What is PageIndex?

    Are you frustrated with vector database retrieval accuracy for long and complex documents? Vector-based RAG retrieves by semantic similarity. But similarity ≠ relevance — what retrieval actually needs is relevance, and relevance requires reasoning. On professional documents that demand contextual understanding, domain expertise, and multi-step reasoning, similarity search misses what is relevant but not similar, and returns what is similar but not relevant.

    Inspired by AlphaGo, PageIndex replaces the vector index with a hierarchical tree index and lets an LLM reason its way through it, the way a human expert turns to and reads the right section of a long report. Retrieval happens in two steps:

    1. Index: generate a tree-structure index for each document
    2. Retrieve: agentically search that tree with LLM reasoning

    TL;DR

    Compare with Vector RAG

    Vector RAGPageIndex
    Indexvector indextree index
    Retrievalsemantic similarity searchLLM reasoning over the tree
    Resultopaque, “vibe retrieval”traceable to explicit references
    Contextquery embedding onlyfull context: conversation history, domain knowledge, etc.

    It is ideal for financial reports, legal documents, regulatory filings, technical manuals, medical literature, academic textbooks, and any other long, complex professional document.

    Quickstart

    pip install -U pageindex
    
    import os
    from pageindex import PageIndexClient
    
    os.environ["OPENAI_API_KEY"] = "your-openai-key"
    
    client = PageIndexClient(
        index="gpt-6-luna",                 # model to build the tree index
        chat="gpt-6-sol",                   # model to search the tree
    )
    doc_id = client.submit_document("report.pdf")["doc_id"]
    
    answer = client.chat("What was the 2023 operating margin?", doc_id=doc_id)
    print(answer)
    

    Model Recommendations

    • index=: a basic model is sufficient. The tree structure itself is extracted from the document layout without an LLM; the index model only summarizes and refines it, which a basic model does well.
    • chat=: use the best model you can afford. The chat model searches the tree to retrieve information. See Query cost and accuracy.

    Have a Claude subscription? PageIndex can use your subscription to call Claude models through Claude Code: usage is covered by your plan, no API key needed. Install with pip install -U "pageindex[claude]", then prefix model names with claude-code/, e.g., index="claude-code/haiku", chat="claude-code/opus" (see example).

    Use PageIndex through the SDK client →

    Configure other models, streaming, multi-document search, citations, and more.

    Integrate PageIndex with your own agent →

    Drop PageIndex tools into the OpenAI Agents SDK, the Claude Agent SDK, or any other framework.

    Benchmarks

    Local indexing cost and time

    Building a tree locally runs about $0.001 per page with gpt-5.6-luna as the index model, so a 1,000-page textbook costs a little over a dollar and a few minutes, once, and every later question reuses it. PageIndex is designed not to rely heavily on the model used at index time, so in our experiments a basic model does not hurt quality.

    Indexing time also scales predictably with document length. In the same local setup, the benchmark documents (9 to 1,098 pages) finished in roughly 13 seconds to 4.5 minutes.

    Query cost and accuracy

    PageIndex Financial QA Benchmark compares the accuracy and query cost of 34 configurations of 19 LLMs answering 100 questions over 40 Form 10-K filings from 8 companies, with PageIndex doing the retrieval. Cost is measured per 100-question run and excludes one-time indexing.

    Full results, data, and reproduction instructions are in the benchmark repo.

    Cost per query vs. native PDF input

    The alternative to retrieval is handing the model the whole PDF on every question. That cost grows with the document; PageIndex's does not, because it reads only the nodes its reasoning reaches. On documents where both routes return the same answer, native PDF input costs 2.1× more at 52 pages and 16.6× more at 420 (gpt-5.6-sol, prompt caching excluded) — and at 805 pages the document no longer fits in the context window at all.

    Leading accuracy on FinanceBench

    PageIndex reached a state-of-the-art 98.7% accuracy on FinanceBench (financial document QA benchmark), vastly outperforming vector-based RAG.

    Explore the full FinanceBench evaluation results and the blog post.

    PageIndex Cloud

    The open-source version is ideal for text-heavy PDFs and local workflows. With PageIndex Cloud, document indexing and storage run in the cloud: PageIndex handles parsing, OCR, image understanding, tree-index construction, and managed storage for you. The chat and retrieval layer remains compatible with your model, so you can search the cloud-hosted index using the model provider your application already uses.

    Moving indexing and storage from Local to Cloud only requires a PageIndex API key:

    import os
    from pageindex import PageIndexClient
    
    os.environ["PAGEINDEX_API_KEY"] = "your-pageindex-key"
    os.environ["OPENAI_API_KEY"] = "your-openai-key"
    
    client = PageIndexClient(
        index="cloud",                       # build and store the index in PageIndex Cloud
        chat="gpt-6-sol",                    # use your preferred compatible model for chat
    )
    doc_id = client.submit_document("report.pdf", wait=True)["doc_id"]
    print(client.chat("What was the 2023 operating margin?", doc_id=doc_id))
    
    LocalCloud
    HandlesText-based PDFsText-based, scanned, and image-rich documents
    IndexingOn your machineManaged by PageIndex
    StorageLocal directoryCloud storage
    CitationsPage-levelBlock-level
    OCR & image understanding—✓
    Metadata—✓
    Folders—✓
    MCP server—✓

    More About PageIndex Cloud

    Ready to Try It?

    For dedicated deployment (VPC or on-premises), contact us or book a demo.


    ⭐ Support Us

    Leave us a star 🌟 if you like our project. Thank you!

    Please cite this work as:

    Mingtian Zhang, Yu Tang and PageIndex Team,
    "PageIndex: Next-Generation Vectorless, Reasoning-based RAG",
    PageIndex Blog, Sep 2025.
    
    @article{zhang2025pageindex,
      author = {Mingtian Zhang and Yu Tang and PageIndex Team},
      title = {PageIndex: Next-Generation Vectorless, Reasoning-based RAG},
      journal = {PageIndex Blog},
      year = {2025},
      month = {September},
      note = {https://pageindex.ai/blog/pageindex-intro},
    }
    

    © 2026 PageIndex AI