RAG的另一种思路，基于文档树结构的推理型检索

在过去两年中，RAG已经成为几乎所有AI应用的标配。无论是智能客服、企业知识库、财务分析还是法律文件问答，它们都遵循相同的逻辑流程：文档分割、向量化、向量相似度匹配、大模型生成答案。然而，这套看似简单有效的方案存在一个根本性的问题：相似性不等于相关性。

例如，当你提问"该公司2023年经营活动现金流的同比变化将是多少？"时，传统RAG可能会找到大量包含"现金流"的段落，但却遗漏了关键上下文：是经营活动还是投资活动？是2023年还是2022年？结果是：高相似度，但低相关性。

一种常见的做法是使用混合检索策略，即除了上述的向量检索外，还使用全文检索来补充。这样，在召回的文档集中，除了语义上的相似外，还包含了在原始问题中出现过的关键词，从而弥补单一检索的不足。

不过，今天我想介绍的是另一种方案PageIndex，它基于文档的层级结构进行推理搜索，而不是简单的向量相似度匹配，因此不需要额外的向量数据库和向量模型。因为这种方式更加符合人类的阅读习惯，即先看目录，定位章节，然后通过子标题逐步深入，在某些场景上能够更准确地召回相关内容。

PageIndex与传统向量RAG的对比

维度	传统向量RAG	PageIndex
检索方式	基于向量相似度搜索	基于文档树结构进行推理搜索
数据库要求	需要向量数据库	无需向量数据库，使用轻量JSON结构
分块处理	需要人工分割，破坏上下文	保留自然章节结构
检索透明度	黑盒搜索，仅返回相似度分数	完全透明，返回推理过程和完整搜索路径
上下文保留	受限于固定分块大小	保留完整的文档层级关系
专业文档表现	在金融、法律等复杂领域准确度受限	针对财务报告、法律文件等超长、复杂的专业文档进行优化

PageIndex的优势

1. 无需向量数据库：树结构以轻量级JSON格式存储，避免了向量数据库的复杂性和成本。这对于本地部署和处理机密文档特别有优势。

2. 无需人工分割：保留文档的自然结构（章节、小节等），避免了分块过程中的上下文丧失。

3. 基于推理的查找：PageIndex模拟人类专家阅读文档的方式，即先看目录，定位章节，然后通过子标题逐步深入。这种层级化的搜寻方式使AI能够真正理解文档逻辑。

4. 清晰可见的检索过程：返回完整的搜索路径和推理过程，而不是简单的相似度分数。每个检索结果都带有精确的页码和位置信息。

5. 专业文档优化：特别针对财务报告、法律文件、技术手册等超长、复杂的专业文档进行优化。

使用方法

环境要求与安装

PageIndex提供了多种使用方式，满足不同场景的需求。

1. 使用官方Python SDK

首先安装PageIndex Python包：

pip install pageindex

访问 *dash.pageindex.ai/api-keys*，获... key，然后在Python中初始化客户端：

# 创建客户端实例
from pageindex import PageIndexClient
pi_client = PageIndexClient(api_key="YOUR_API_KEY")

# 提交文档并获取文档ID
result = pi_client.submit_document("YOUR_PDF_PATH")
doc_id = result["doc_id"]

# 获取文档树结构
tree_result = pi_client.get_tree(doc_id)

2. 本地部署使用

如果你想在本地运行PageIndex，可以使用开源仓库：

# 克隆仓库
git clone https://github.com/VectifyAI/PageIndex.git
cd PageIndex

# 安装依赖
pip install --upgrade -r requirements.txt

# 设置OpenAI API密钥
# 创建 .env 文件
echo "CHATGPT_API_KEY=your_openai_key_here" > .env

# 处理PDF文件
python3 run_pageindex.py --pdf_path /path/to/your/document.pdf

除了pdf_path外，其他可选参数包括：

可选参数说明：

• --model: 使用的OpenAI模型（默认：gpt-4o-2024-11-20）
• --toc-check-pages: 检查目录的页数（默认：20）
• --max-pages-per-node: 每个节点最多页数（默认：10）
• --max-tokens-per-node: 每个节点最多token数（默认：20000）
• --if-add-node-id: 是否添加节点ID（默认：yes）
• --if-add-node-summary: 是否添加节点摘要（默认：yes）
• --if-add-doc-description: 是否添加文档描述（默认：yes）

执行该脚本后，会生成一个JSON文件，该文档树包含该文件的节点和摘要等信息。

3. MCP集成

PageIndex提供了MCP支持，可以直接集成到Claude、Cursor等应用：

3.1 远程MCP服务器

在你的MCP配置中添加：

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

3.2 本地MCP服务器

需要Node.js ≥18.0.0

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

核心特性

1. 推理型树结构索引生成

PageIndex的第一步是将长文档转换成层级化的树结构，类似于书籍的目录，但针对LLM进行了优化。这个过程有两个关键步骤：

（1）智能目录检测与文档解析

系统首先检查文档的前N页（默认20页）来识别现有的目录结构。如果文档有明确的目录，PageIndex会利用这个信息作为树的骨架。对于没有目录的文档，系统使用LLM来理解文档的逻辑结构。

（2）递归树节点生成

基于识别到的结构，PageIndex递归地为每个章节、小节创建树节点。每个节点包含：

• node_id: 唯一标识符（如"0006"）
• title: 节点标题
• page_index: 节点所在的页码
• text: 节点的文本内容
• summary: 节点的摘要（便于LLM快速理解）
• prefix_summary: 节点的前缀摘要（提供上下文）
• nodes: 子节点列表（递归结构）

生成的树结构示例：

{
  "title": "Financial Stability",
  "node_id": "0006",
  "page_index": 21,
  "text": "The Federal Reserve maintains financial stability through comprehensive monitoring and regulatory oversight...",
  "summary": "This section discusses the Federal Reserve's approach to maintaining financial stability.",
  "prefix_summary": "Overview of monetary policy framework",
  "nodes": [
    {
      "title": "Monitoring Financial Vulnerabilities",
      "node_id": "0007",
      "page_index": 22,
      "text": "The Federal Reserve's monitoring focuses on identifying emerging risks...",
      "summary": "Describes vulnerability monitoring strategies"
    },
    {
      "title": "Domestic and International Cooperation and Coordination",
      "node_id": "0008",
      "page_index": 28,
      "text": "In 2023, the Federal Reserve collaborated internationally...",
      "summary": "Details international coordination efforts"
    }
  ]
}

相比于简单的文本分割，树结构保留了文档的逻辑层级。这意味着LLM可以理解"第二级标题是从属于第一级标题"这样的关系，从而做出更准确的推理决策。

可以看出，文档的目录结构对索引的生成和检索都有重要影响，因此如果文档目录识别不准或者其他原因导致文档目录结构识别效果差的，都会造成后检索的质量问题。

2. 无向量的推理型树搜索

PageIndex的检索阶段使用LLM来导航树结构。基础的树搜索流程如下：

prompt = f"""
You are given a query and the tree structure of a document.
Each node contains a node id, node title, and a corresponding summary.
Your task is to find all nodes that are likely to contain the answer.

Query: {query}

Document tree structure:
{json.dumps(tree_structure, indent=2)}

Please reply in the following JSON format:
{{
  "thinking": "<Your reasoning about which nodes are relevant>",
  "node_list": ["node_id_1", "node_id_2", ...]
}}
"""

这个方法直接使用LLM推理来推理相关性 ，根据每一个节点的summary，从前面的索引树中提取所有相关节点，而不是数值相似度计算。

此外，与向量RAG不同，PageIndex的树搜索自动识别所有相关节点，无需手动调整Top-K参数，在一定程度上实现了精确和召回的trae-off。

3. 清晰可见的检索结果

PageIndex的检索API返回的结果包含完整的上下文信息：

{
  "title": "Monetary Policy and Economic Developments",
  "node_id": "0004",
  "nodes": [
    {
      "title": "March 2024 Summary",
      "node_id": "0005",
      "relevant_contents": [
        {
          "page_index": 10,
          "relevant_content": "The labor market has gained averaging 239,000 per month since June 2023..."
        }
      ]
    },
    {
      "title": "June 2023 Summary",
      "node_id": "0006",
      "relevant_contents": [
        {
          "page_index": 15,
          "relevant_content": "The labor market has remained very tight, with job gains averaging 314,000 per month during..."
        }
      ]
    }
  ]
}

关键特性：

• 完整搜索轨迹：返回从根节点到叶子节点的完整路径
• 精确页码引用：每条结果都带有确切的页码，便于验证
• 结构化输出格式：结构化输出，可直接喂入LLM生成答案
• 无需Top-K调优：树搜索自动识别所有相关节点

4. 灵活的专业知识集成

与向量RAG需要微调嵌入模型不同，PageIndex可以利用LLM的特性，通过简单修改Prompt来增强专业知识的处理：

prompt = f"""
You are given a question and a tree structure of a document.
Find all nodes likely to contain the answer.

Query: {query}

Document tree structure: {tree}

Expert Knowledge of relevant sections: {domain_expertise}

Expert hint example: If the query mentions EBITDA adjustments, 
prioritize Item 7 (MD&A) and footnotes in Item 8 (Financial Statements) 
in 10-K reports.

Reply in JSON format:
{{
  "thinking": "<Your reasoning>",
  "node_list": ["node_id1", ...]
}}
"""

这种方法使得为特定域定制PageIndex变得极其简单------只需在提示中添加领域知识即可。

总结

与传统RAG相比，PageIndex的结构更加轻量。它不依赖复杂的向量数据库，而是以树状结构将文档组织为可解析的JSON文件，大幅降低了部署难度和成本。同时，它保留了文档的自然上下文，避免了人工分块造成的语义破碎，使得信息在检索时更连贯、更准确。

PageIndex的核心优势在于推理型检索。通过让LLM沿树结构逐层推理，它能够找到真正相关的内容，而非仅仅语义相似的段落。每次检索的结果都附带完整的推理轨迹与页码引用，实现了过程的透明与可验证。

然而，这种方法也并非没有代价。PageIndex依赖LLM进行结构化提取与推理，意味着在处理大型文档时会消耗大量token，速度相对较慢 。此外，它目前更适合处理单一长文档，而非海量文档集合，难以完全替代向量RAG在大规模检索中的效率优势。

总的来说，PageIndex并不是向量RAG的替代品，而是可以作为一种补充手段。此外，也可以尝试用小模型来提取文档结构信息和摘要，而检索过程则还是使用更强的推理模型，这样在性能和效益上能达到平衡。