> ## Content Index
> Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# PageIndex：基于推理的RAG
- URL: https://www.hubwiz.com/blog/pageindex-reasoning-based-rag/
- Published: 2026-03-12T13:02:42.000Z
- Updated: 2026-03-12T13:02:42.000Z
- Description: PageIndex用两个步骤取代了整个分块-嵌入-搜索流程：从文档构建层次树，然后让LLM对该树进行推理以找到答案。
- Author: admin
- Tags: LIBRARY, PAGEINDEX, RAG, #Import 2026-10-14 14:41

标准的RAG流程会对文档进行分块、嵌入，然后按相似度进行搜索。但是相似度不等于相关性，对于密集的专业文档而言，这种差距正是准确度消亡的地方。

默认的RAG技术栈在两年里几乎没有变化。获取文档，将其分块，对每个块进行嵌入，存储向量，在查询时检索最相似的前k个结果。这对于博客文章和FAQ页面来说效果足够好了，但对于企业中最重要的文档——200页的SEC申报文件、监管提交材料、技术手册和法律合同——它却会彻底失效。

下面是标准流程在实际应用中的样子——以及它恰好在哪里崩溃：

```python
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.vectorstores import Chroma
from langchain_openai import OpenAIEmbeddings

# 第一步：对文档进行分块
splitter = RecursiveCharacterTextSplitter(chunk_size=512, chunk_overlap=50)
chunks = splitter.split_documents(documents)
# 第二步：嵌入并存储
vectorstore = Chroma.from_documents(chunks, OpenAIEmbeddings())
# 第三步：按相似度检索
results = vectorstore.similarity_search("递延资产的总价值是多少？", k=5)

```

这会检索出五个其嵌入向量与查询最接近的块。但"最接近"并不等于"正确"。问题询问的是一个总价值。最相似的块可能描述的是递延资产如何*增加*——语义上接近，但事实错误。实际的总价值在附录G中，第77页引用了"参见附录G获取详细统计表"这个短语。没有嵌入模型能够将这个交叉引用与查询连接起来，因为这种连接需要推理，而不是相似度。

一位阅读10-K文件的分析师不会去寻找与其问题看起来最相似的段落。他们会浏览目录，推理哪个章节可能包含答案，翻到该章节，阅读内容，并遵循交叉引用。PageIndex完全复制了这个过程。

## 1、PageIndex的实际作用

[PageIndex](http://github.com/VectifyAI/PageIndex?ref=hubwiz.com) 用两个步骤取代了整个分块-嵌入-搜索流程：从文档构建层次树，然后让LLM对该树进行推理以找到答案。

**第一步：树构建。** PageIndex解析PDF并生成JSON树——一个机器可读的目录，包含摘要、页码范围和嵌套的子章节。下面是美联储年度报告输出结果的样子：

```json
{
  "node_id": "0006",
  "title": "Financial Stability",
  "start_index": 21,
  "end_index": 22,
  "summary": "The Federal Reserve's role in maintaining financial stability...",
  "sub_nodes": [
    {
      "node_id": "0007",
      "title": "Monitoring Financial Vulnerabilities",
      "start_index": 22,
      "end_index": 28,
      "summary": "The Federal Reserve's monitoring framework..."
    },
    {
      "node_id": "0008",
      "title": "Domestic and International Cooperation",
      "start_index": 28,
      "end_index": 31,
      "summary": "In 2023, the Federal Reserve collaborated..."
    }
  ]
}

```

每个`node_id`直接映射到原始内容——来自对应页面的文本、图像或表格。这棵树保留了文档的自然层次结构，而不是将其切割成512个token的片段。没有嵌入，没有向量数据库——索引纯粹是位于LLM上下文窗口内的JSON。PageIndex团队称之为"上下文内索引"，因为模型可以在推理过程中直接引用、导航并对其进行推理。

**第二步：智能体检索。** 当用户提出问题时，LLM读取树并遵循一个迭代循环：**1.** 识别可能包含答案的章节 **2.** 检索最有希望的章节的原始内容 **3.** 提取相关信息，以及 **4.** 要么回答问题，要么返回到树并尝试另一个章节。

## 2、入门指南：自托管

在本地运行PageIndex的最快方式。这会使用开源仓库从任何PDF生成树结构。

```bash
# 克隆并安装
git clone https://github.com/VectifyAI/PageIndex.git
cd PageIndex
pip3 install --upgrade -r requirements.txt

# 设置你的OpenAI API密钥
echo "CHATGPT_API_KEY=your_openai_key_here" > .env
# 从任何PDF生成树
python3 run_pageindex.py --pdf_path /path/to/annual-report.pdf

```

默认模型是`gpt-4o-2024-11-20`。你可以使用可选参数自定义行为：

```css
python3 run_pageindex.py \\
  --pdf_path /path/to/document.pdf \\
  --model gpt-4o-2024-11-20 \\
  --toc-check-pages 20 \\
  --max-pages-per-node 10 \\
  --max-tokens-per-node 20000 \\
  --if-add-node-id yes \\
  --if-add-node-summary yes \\
  --if-add-doc-description yes

```

PageIndex也直接支持markdown输入——如果你已经转换了PDF或者想要索引结构化文档，这很有用：

```css
python3 run_pageindex.py --md_path /path/to/document.md

```

关于markdown路径的一点说明：它使用`#`标题级别来确定节点层次（`##` \= 级别2，`###` \= 级别3）。如果你的markdown是从PDF或HTML机器转换的，标题通常不可靠。对于这些情况，PageIndex团队建议先使用他们的OCR工具生成保留结构的markdown，然后在该输出上运行树生成器。

自托管路径为你提供了对树构建的完全控制。输出是一个JSON文件，你可以检查、修改并在任何下游管道中使用。

📎 *开源仓库：* [*github.com/VectifyAI/PageIndex*](https://github.com/VectifyAI/PageIndex?ref=hubwiz.com)

## 3、入门指南：Python SDK（云端API）

用于生产工作负载——通过PageIndex API提交文档、生成树并运行基于推理的问答。

```typescript
pip install -U pageindex
from pageindex import PageIndexClient

# 初始化（在dash.pageindex.ai获取你的API密钥）
pi_client = PageIndexClient(api_key="YOUR_API_KEY")
# 提交文档进行处理
result = pi_client.submit_document("./2023-annual-report.pdf")
doc_id = result["doc_id"]
# 检查处理状态
status = pi_client.get_document(doc_id)["status"]
if status == "completed":
    print("Document processed - tree is ready")

```

文档处理完成后，你可以直接检索树结构：

```bash
# 获取生成的树
tree = pi_client.get_tree(doc_id)["result"]
print(json.dumps(tree, indent=2))  # 检查层次结构

```

或者跳过树，直接进入问答——Chat API在后台运行完整的智能体检索循环：

```bash
# 与单个文档对话
response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "What is the total value of deferred assets?"}],
    doc_id="pi-abc123def456"
)
print(response["choices"][0]["message"]["content"])

# 跨多个文档对话
response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "Compare revenue recognition policies across these filings"}],
    doc_id=["pi-abc123def456", "pi-abc123ghi789"]
)
print(response["choices"][0]["message"]["content"])

```

多文档对话对于财务分析特别强大——比较年度申报、跨公司交叉引用披露，或识别期间内会计政策的变化。

📎 *SDK文档：docs.pageindex.ai/quickstart · 开发者面板：dash.pageindex.ai*

## 4、入门指南：MCP集成

PageIndex提供了一个MCP服务器，将其基于推理的检索暴露给任何MCP兼容的客户端——Claude Desktop、Cursor或任何智能体框架。这让你可以直接从现有工具与长PDF对话，而不会触及上下文长度限制。

对于Claude Desktop，最简单的路径是一键扩展——从发布页面（[pageindex-mcp](http://github.com/VectifyAI/pageindex-mcp/releases?ref=hubwiz.com)）下载`.mcpb`文件并双击安装。OAuth会自动处理。

对于其他MCP客户端，在你的配置中添加：

```json
{
  "mcpServers": {
    "pageindex": {
      "command": "npx",
      "args": ["-y", "pageindex-mcp"]
    }
  }
}

```

这会运行一个支持完整PDF上传的本地MCP服务器。如果你更喜欢无本地设置的直接连接：

```json
{
  "mcpServers": {
    "pageindex": {
      "type": "http",
      "url": "https://chat.pageindex.ai/mcp"
    }
  }
}

```

本地服务器自动处理文件上传和身份验证。直接HTTP连接仅支持通过URL的PDF（不支持本地文件上传）。两个选项都为你的智能体提供相同的基于推理的检索——LLM导航文档的树结构，而不是依赖于向量相似度。

📎 *MCP服务器仓库：github.com/VectifyAI/pageindex-mcp（84颗星，MIT许可证）· 设置指南：pageindex.ai/mcp*

## 5、为什么向量搜索在专业文档上失效

问题不在于糟糕的嵌入模型或错误的块大小。这是分块-嵌入-搜索架构本身固有的五个结构性限制。

**查询-知识空间不匹配：** 问题"公司的债务趋势是什么？"表达的是意图，而不是内容。答案位于一个题为"长期义务和信贷便利"的章节中，这与查询几乎没有表面层面的语言共同点。

> 嵌入模型无法弥合这个差距，因为连接需要领域推理，而不是余弦相似度。

**相似度不是相关性：** 在领域特定的文档中，许多段落共享几乎相同的语义，但在相关性方面存在关键差异。一份10-K文件可能包含几十段关于收入确认的段落，但只有一段回答了关于"2023财年政策变化"的问题。

> 嵌入模型对它们的排名几乎相同。

**硬分块破坏上下文：** 将文档分割成512个token的块会切断句子、表格和逻辑章节。跨越两个块的表格会变成两个无意义的片段。

> 引用脚注的段落会在脚注位于不同块时失去该引用。

**没有对话记忆：** 每个向量查询都是独立的。如果用户在上轮询问了"财务资产"，现在询问"那负债呢？"，检索器无法知道它应该查看同一份报告的同一章节。

**交叉引用消失：** 当文档说"表5.3总结了收入和支出；参见附录G获取详细统计表"时，向量检索器没有机制可以遵循该引用。答案在附录G中，但那里没有任何内容在语义上与原始问题相似。

> **在PageIndex团队自己的测试中，这个确切的场景发生了：** 一个关于递延资产总值的查询命中了一个仅报告*增加*的章节（第75-82页）。第77页引用附录G以获取总数。基于推理的检索器遵循了这个提示。向量检索器以高置信度返回了错误的章节。

## 6、PageIndex与RAPTOR的区别

RAPTOR（递归抽象处理以进行树组织检索，斯坦福，ICLR 2024）也构建树——但这两个系统的工作方式有根本区别。

RAPTOR从传统分块开始，对块进行嵌入，使用高斯混合模型按语义相似度对它们进行聚类，总结每个聚类，并递归地重复该过程以自底向上构建树。在检索时，它仍然在树的所有层级上使用向量相似度搜索。RAPTOR改进了被索引的内容，但检索仍然基于嵌入：

```makefile
# RAPTOR：树改进了索引，但检索仍然基于向量
from raptor import RetrievalAugmentation

RA = RetrievalAugmentation()
RA.add_documents(document_text)
# 检索仍在底层使用嵌入
answer = RA.answer_question("What are the company's debt trends?")

```

PageIndex完全跳过分块和嵌入。它解析文档的固有结构以构建树，并且在检索时LLM通过推理导航树——在任何阶段都没有向量搜索：

```makefile
# PageIndex：没有嵌入，没有向量数据库——LLM对树进行推理
from pageindex import PageIndexClient

pi_client = PageIndexClient(api_key="YOUR_API_KEY")
result = pi_client.submit_document("./10-K-filing.pdf")
# 检索基于推理：LLM导航树结构
response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "What are the company's debt trends?"}],
    doc_id=result["doc_id"]
)

```

实际区别：RAPTOR仍然需要向量数据库和嵌入模型。PageIndex只需要一个LLM和文档。RAPTOR查找相似的节点；PageIndex根据它在查找的内容决定接下来访问哪个节点。

📎 *RAPTOR：arxiv.org/abs/2401.18059（Sarthi等人，斯坦福，ICLR 2024）*

## 7、更广泛的趋势：通过推理进行检索

PageIndex是远离基于嵌入检索这一更广泛转变的一部分。

Chroma的"上下文腐烂"研究（2025年7月）测试了18个最先进的LLM——包括GPT-4.1、Claude 4、Gemini 2.5和Qwen3——并发现随着输入长度增加，模型性能显著下降，即使是在简单任务上。这一发现强化了一个观点："将所有内容倾倒到一个长上下文窗口中"并不是良好检索的可靠替代方案，而进入上下文的*内容*比能容纳*多少*更重要。

Claude Code团队从另一个方向得出了类似的结论。Claude Code的创建者Boris Cherny在2025年5月的Latent Space播客采访中说，早期版本使用了带有本地向量数据库的RAG，但他们转向了智能体搜索——让模型使用grep和文件读取等工具进行探索——因为它超越了所有其他方法。原因不仅仅在于准确性：简单性、没有陈旧性、没有外部索引的安全风险，以及没有同步漂移的可靠性问题。

> **PageIndex将相同的原理应用于文档：** 不是预先计算外部相似度索引，而是让模型自己的推理来处理检索。

树结构给了LLM可以推理*的对象*——文档的结构化映射，使导航变得高效，而无需嵌入。

## 8、权衡

基于推理的检索不是免费的，而公平的评估需要点名其成本。

**Token消耗：** 树构建需要多次LLM调用来解析、总结和结构化文档。智能体检索每次查询需要多个推理步骤——读取树、选择节点、提取内容、可能迭代。

> 向量搜索通过单次嵌入调用在毫秒级返回结果。PageIndex用延迟和成本换取准确性。

**规模：** PageIndex对于单个文档或小集合效果极佳——这正是财务分析、法律审查或监管合规的场景。

> **对于搜索数千个文档，向量数据库仍有明显优势：** 它们可以在亚秒级时间内搜索包含数百万个文档的语料库，这是顺序LLM推理无法比拟的。

**LLM依赖：** 检索质量完全取决于底层模型的推理能力。较弱的模型在导航树时会对要访问哪些章节做出更糟糕的决策。

> 这与向量搜索是一种根本不同的失败模式，在向量搜索中，检索质量取决于嵌入质量。

**树构建成本：** 构建树是每个文档的一次性成本，但比嵌入更昂贵。对于频繁变更的语料库，重建成本很重要。

> **诚实的框架：** 向量RAG是一种快速、廉价的近似方法，对于简单文档效果足够好。PageIndex是一种较慢、更昂贵、更准确的方法，适用于"足够好"不够用的文档。这两种方法也可以互补——向量搜索将大型语料库缩小到相关文档，然后PageIndex对那些特定文档进行推理以获得精确答案。

## 9、从哪里开始

选择一份重要的文档。一份10-K申报文件、一份监管提交材料、一份100页的技术手册——某个你的当前RAG管道给出不准确答案的文档。

**如果你想要完全控制，** 克隆开源仓库，生成树，并检查JSON输出。在将其插入任何管道之前，先理解层次结构。

**如果你想要快速结果，** `pip install pageindex`，通过SDK提交文档，并使用Chat API。智能体检索循环在服务器端运行——你无需自行构建基础设施即可获得基于推理的答案。

**如果你想要与现有工具集成，** 将MCP服务器添加到Claude Desktop或Cursor。上传一个超出上下文限制的PDF，并询问一个需要交叉引用章节的问题。在那里你会看到差异。

标准RAG管道并没有消亡。但对于最重要的文档——那些带有表格、附录、交叉引用和监管精度要求的文档——"直接分块和嵌入"的时代正在让位于某种更准确的东西。LLM可以像人类专家那样阅读文档，而事实证明这比任何嵌入模型所能逼近的都要好。

---

原文链接: [Stop Chunking, Start Reasoning: How PageIndex Replaces Vector Search with LLM-Driven Retrieval](https://medium.com/@pankaj%5Fpandey/stop-chunking-start-reasoning-how-pageindex-replaces-vector-search-with-llm-driven-retrieval-a1d4d3fc30d2?ref=hubwiz.com)

汇智网翻译整理，转载请标明出处