Law的数字世界

核心能力一览#

它最适合的场景，是专业、结构清晰、又长又复杂的文档：

• 上市公司财报、招股书、年报
• 法律合同、判决书、合规手册
• 技术规范、API 文档、白皮书
• 学术论文、研究报告

如果你是律师、金融分析师、做合规的、做尽调的、做政策研究的——这个工具的设计就是冲着你来的。

一张图看懂：两种 RAG 的工作流对比#

上面是切片喂向量库的老路，下面是 PageIndex 的”建索引树 → LLM 推理 → 精准翻页”新路。两条流水线一对比，差别就清楚了：

传统向量 RAG 流水线

1
PDF → 文本抽取 → 分块（512-1024 tokens）
2
     → 向量模型编码 → 存入向量数据库 → 余弦相似度搜索
3
     → 取 Top-K 块 → 喂给 LLM → 生成答案

PageIndex RAG 流水线

1
PDF → 生成树状索引（LLM 构建分层目录）
2
     → 用户提问 → LLM 在树结构上做推理
3
     → 定位相关节点 → 抓取精确页内容
4
     → 喂给 LLM → 生成答案（带页码引用）

关键差别：传统 RAG 在”文本相似度”上做检索，PageIndex 在”文档结构”上做推理。前者是”找长得像的段落”，后者是”想想答案应该在哪一章”。

PageIndex 的工作原理（再细一层）#

整个流程拆开看就两步：

第一步：构建文档树索引（只做一次）

读取 PDF → 由 LLM 识别章节层级 → 输出一棵 JSON 树。每个节点带：

• title：章节标题（如「第三节 管理层讨论与分析」）
• node_id：节点唯一 ID（如 0010）
• start_index / end_index：起止页码
• summary：LLM 生成的章节摘要
• nodes：子节点链接
• text：章节原文（按需返回）

文档保留了天然的层级结构，没有任何关系被切断——交叉引用、上下文、章节归属全在。

第二步：LLM 推理导航（每次查询）

问题来了之后，LLM 只看标题 + 摘要（不读全文），输出推理过程和需要检索的节点 ID。例如问完美世界年报”2025 年研发投入是多少？占营收的比例是多少？”：

1
推理过程：
2
问题询问研发投入金额与占比。节点 0012 标题为
3
"2025年度财务状况与经营成果分析"，财务明细一般在这一节披露，
4
是最相关的位置。节点 0005「第二节 公司简介和主要财务指标」
5
可能有高层汇总，但通常只给关键指标，不含研发占比拆解。
6
因此主要检索节点 0012，必要时辅以节点 0005。
7

8
检索节点：0012  页码：22  标题：2025年度财务状况与经营成果分析

然后只把这个节点的完整原文塞给 LLM，生成最终答案。

从问题到答案，全程只调 2 次 LLM：一次导航推理，一次答案生成。没有余弦相似度，没有向量数据库，整个推理链可读、可验证——答案错了，你一眼就能看出是”选错了章节”还是”章节对但生成出了问题”。

四种主流 RAG 横评#

光看表格还是抽象，我给你翻译一下：

• 传统向量 RAG：图书馆里随机翻 5 张书页给你看
• PageIndex：先看目录，再翻到第 3 章第 2 节给你看
• GraphRAG：把整个图书馆的知识画成关系网，问什么先去查网
• LightRAG：GraphRAG 的轻量版，省点钱

怎么选？#

TIP

决策树（按你的实际场景选）

• 你只是想问几篇财报 / 长合同 / 大手册的问题 → 无脑选 PageIndex
• 你有几千上万份文档要做企业知识库 → 传统向量 RAG + 精排
• 你要做跨文档的全局综述、关系挖掘 → GraphRAG
• 你要又便宜又快、还能多跳推理 → LightRAG
• 你又懒又有钱 → 直接调 PageIndex 云端 API，省去自己运维

必须泼一盆冷水#

WARNING

PageIndex 的几个坑，先看清楚再上车

1. 扩展性差：单文档无敌，几百上千文档时树构建慢、查询贵。别拿它替代企业级向量库。
2. 成本结构不同：向量 RAG 一旦建好索引，边际查询成本趋近于零；PageIndex 每次查询都要调 LLM 做推理导航，成本随查询量线性增长。日均万次查询的场景，这笔账要好好算。
3. 依赖文档结构：标题层级混乱、纯扫描件 OCR 不准的 PDF，效果会打折扣；无章节的纯文本会降级为按固定页数均匀切割，优势消失。
4. 中文用户特别注意：开源版的搜索算法用的是简单字符串匹配，对中文直接失效。中文场景建议走云端 API，而非自托管开源版。
5. 不适合实时高并发：实测 23 页文档单次查询延迟 3-10 秒，比向量 RAG 慢两到三个数量级，做实时搜索框就别想了。
6. 重建成本高：文档一更新，整棵树可能要重新构建。

一句话总结：长、结构清晰、对准确性要求高的少量文档，PageIndex 是神器；其他场景请慎重。

工具组合说明#

PageIndex 有三种用法，按你的技术水平选：

最推荐的起点：先用方法一验证效果，有感觉再上方法二、方法三。

方法一：零代码网页版(最适合小白)#

完全不想写代码？官方提供了一个网页聊天界面：chat.pageindex.ai/chat

用法极简：

1. 打开 pageindex.ai 注册账号（Google 账号一键登录）
2. 进入 Chat 界面，点左下角 + Add documents 上传你的 PDF
3. 等待建树（进度条转完）
4. 直接在对话框里提问

左侧有 Documents（文档库）、Library、Chats（历史对话）三个入口，管理多份文档很清晰。

我把完美世界 2025 年报丢进去，问”2025 年营收和净利润是多少？同比变化如何？“——它先后展开了 Get document structure（读目录）和 Get page content（抓页面）两个推理步骤，然后给出带页码引用的精确答案：

注意看每个数字后面的小角标——那是”溯源页码”，点开就能跳到原 PDF 的对应章节。这就是 PageIndex 区别于传统向量 RAG 的关键体验。

TIP

网页版适合快速验证：先把你最想测的那份财报或合同丢进去，再问几个问题，确认效果好再考虑接 API 或自托管。

方法二：Python SDK（30 秒装好，5 分钟出结果）#

适合想写代码、把 PageIndex 集成到自己工作流的人。

安装 PageIndex SDK#

这条路 30 秒就能搞定：

1
pip install -U pageindex

截至 2026 年 3 月，最新版本是 0.2.6。

去 pageindex.ai 注册账号，拿一个 API Key（新用户有免费额度可以白嫖）。在 Dashboard 的 API Keys 页面，点 + Create your first key，起个名字（比如 test_key）就行：

WARNING

API Key 只显示一次——创建完立刻复制保存到密码管理器或 .env 文件里，关掉对话框就再也看不到了。丢了只能重新生成。

我实战跑通的脚本 quickstart.py（拿一份完美世界 2025 年年度报告约 200 页 PDF 实测）：

1
from pageindex import PageIndexClient
2
import time
3
import json
4

5
API_KEY = "你的API_KEY"
6
PDF_PATH = "./完美世界：2025年年度报告.pdf"
7

8
pi_client = PageIndexClient(api_key=API_KEY)
9

10
# 1. 提交文档（首次提交，构建文档树）
11
result = pi_client.submit_document(PDF_PATH)
12
doc_id = result["doc_id"]
13
print(f"文档已提交，doc_id: {doc_id}")
14

15
# 2. 轮询，等树构建完成
16
while True:
17
    info = pi_client.get_document(doc_id)
18
    if info.get("status") == "completed":
19
        break
20
    print(f"当前状态: {info.get('status')}，等待中...")
21
    time.sleep(5)
22

23
# 3. 保存目录树到本地，方便后面查看
24
tree = pi_client.get_tree(doc_id)["result"]
25
with open("tree.txt", "w", encoding="utf-8") as f:
26
    f.write(json.dumps(tree, ensure_ascii=False, indent=2))
27
print("目录树已写入 tree.txt")
28

29
# 4. 针对财报的典型问题（异步查询：submit_query + get_retrieval）
30
questions = [
31
    "2025年公司的营收和净利润是多少？同比变化如何？",
32
    "公司2025年研发投入是多少？占营收的比例是多少？",
33
    "公司的主要业务板块有哪些？各板块2025年表现如何？",
34
    "经营性现金流和净利润的差异原因是什么？",
35
]
36

37
results = []
38
for i, q in enumerate(questions, 1):
39
    print(f"提交问题 {i}/{len(questions)}：{q}")
40
    resp = pi_client.submit_query(doc_id=doc_id, query=q)
41
    retrieval_id = resp["retrieval_id"]
42
    while True:
43
        r = pi_client.get_retrieval(retrieval_id)
44
        if r.get("status") == "completed":
45
            results.append({"question": q, "answer": r.get("result", r)})
46
            break
47
        time.sleep(3)
48

49
# 5. 写入 Markdown 结果文件
50
with open("results.md", "w", encoding="utf-8") as f:
51
    f.write("# 财报检索结果\n\n")
52
    for i, r in enumerate(results, 1):
53
        f.write(f"## 问题 {i}\n\n**{r['question']}**\n\n{r['answer']}\n\n---\n\n")
54

55
print("全部完成，结果已写入 results.md")

WARNING

官方文档里的 retrieve() 已经废弃——我第一次照着官方 README 的 pi_client.retrieve(...) 写，返回里直接给了一行 deprecation 警告：Retrieval endpoints are deprecated. Use the chat-completion API。 现在的正确姿势是异步两步走：先 submit_query() 拿 retrieval_id，再轮询 get_retrieval() 拿结果。上面的脚本就是踩坑后改对的版本。

跑起来：

1
python quickstart.py

第一次跑会比较慢——200 页的财报，构建树大概 3-8 分钟。但树只建一次，后续所有查询都复用这棵树。下次跑可以把 doc_id 写死、跳过 submit_document 那步，直接发问。

底层到底怎么工作的？

整个流程每次查询只调 2 次 LLM：第一次”导航推理”（让模型看着目录想”答案在哪一节”，只读标题+摘要，不读全文），第二次”答案生成”（把选中节点的完整原文送进去）。

没有余弦相似度，没有向量数据库，整个推理链可读、可验证——答案错了，你一眼就能看出是”选错了章节”还是”章节对但生成出了问题”。

PageIndex 生成的目录树长什么样#

光看代码抽象，看看真的目录树。下面是 PageIndex 给这份 200 页财报生成的 tree.txt 节选——这就是它喂给 LLM 做”导航推理”的东西：

1
[
2
  {
3
    "title": "第二节 公司简介和主要财务指标",
4
    "node_id": "0005",
5
    "page_index": 6,
6
    "nodes": [...]
7
  },
8
  {
9
    "title": "第三节 管理层讨论与分析",
10
    "node_id": "0006",
11
    "page_index": 10,
12
    "nodes": [
13
      { "title": "一、报告期内公司从事的主要业务", "node_id": "0007", "page_index": 10 },
14
      { "title": "二、报告期内公司所处行业情况", "node_id": "0008", "page_index": 10 },
15
      { "title": "2025年度经营业绩与核心业务发展分析", "node_id": "0010", "page_index": 14 },
16
      { "title": "业务经营概况与财务业绩分析", "node_id": "0011", "page_index": 18 },
17
      { "title": "2025年度财务状况与经营成果分析", "node_id": "0012", "page_index": 22 }
18
    ]
19
  }
20
]

每个节点带 title（章节标题）+ node_id（节点唯一 ID）+ page_index（起始页码）+ text（章节原文）。LLM 看到这棵树，就像你看一本书的目录——“问的是研发投入，那应该看节点 0012「2025年度财务状况与经营成果分析」“。

方法三：开源自托管（完全本地化）#

如果你想完全本地化、不依赖云服务，把 GitHub 项目拉下来自己跑：

1
git clone https://github.com/VectifyAI/PageIndex.git
2
cd PageIndex
3
pip install -r requirements.txt

设置你的 OpenAI API Key（PageIndex 自托管模式默认用 GPT-4o 来做树构建和检索推理）：

1
$env:OPENAI_API_KEY="sk-xxxxx"

然后跑 cookbook 里的示例脚本：

1
python run_pageindex.py --pdf_path ./your-doc.pdf

WARNING

自托管模式的 token 消耗肉眼可见。100 页的 PDF 构建一次树，保守估计要消耗 10-30 万 token。GPT-4o 跑下来大约 $1-3。先用便宜的 gpt-4o-mini 试效果，确认没问题再上 gpt-4o。

中文用户额外注意：开源版自带搜索是简单字符串匹配，对中文直接失效。中文场景强烈建议走方法一或方法二。

进阶玩法：接到 Claude Desktop / Cursor（MCP 模式）#

如果你已经在用 Claude 桌面端或者 Cursor，可以装 PageIndex 的 MCP 服务，让 AI 编辑器直接调它，不用写代码。

打开 Claude Desktop 的配置文件（Windows 路径）：

1
%APPDATA%\Claude\claude_desktop_config.json

加入这一段：

1
{
2
  "mcpServers": {
3
    "pageindex": {
4
      "command": "npx",
5
      "args": ["-y", "@vectifyai/pageindex-mcp"],
6
      "env": {
7
        "PAGEINDEX_API_KEY": "你的API_KEY"
8
      }
9
    }
10
  }
11
}

保存后完全退出再打开 Claude Desktop（关掉系统托盘的图标，不是简单关窗口）。再问 Claude：“帮我分析这份 PDF……”，它就会自动调 PageIndex 来翻文档了。

Cursor 用同样的 JSON 格式，路径在设置 → MCP Servers 里。

效果评测：完美世界财报实测结果#

200 页的财报，4 个典型问题，PageIndex 都答出来了，每个数字都能溯源到具体节点和页码。挑两个最能看出差距的说：

问题：2025 年研发投入是多少？占营收的比例？

PageIndex 定位到节点 0012「2025年度财务状况与经营成果分析」，输出：

• 研发投入：17.82 亿元（同比 -20.00%），占营收 26.75%
• 资本化 1.57 亿（资本化率 8.81%），费用化 16.25 亿

注意：报表上”研发费用”16.25 亿（费用化部分）和”研发投入”17.82 亿（含资本化）是两个数。传统 RAG 经常混着抓，PageIndex 看目录就知道哪个数在哪节，没有混淆。

问题：经营性现金流和净利润为什么差这么多？

这题最考验”推理导航”——答案散落在现金流量表附注、利润表、权益变动表三处。PageIndex 定位到 0012、0059、0043 三个节点，精准抓出”现金流量表补充资料”那张关键表：净利润 6.92 亿 → 加回减值/折旧 ≈ 5.5 亿、加回经营性应收存货变动 6.8 亿、减经营性应付 9.25 亿 → 经营活动现金流 10.93 亿（同比 +89.57%）。

一击命中的关键

传统向量 RAG 大概率会抓回一堆”现金流”和”净利润”的零散段落，但答不出”为什么差异”——差异藏在「现金流量表补充资料」这张表里。PageIndex 看目录就知道去哪查，一击命中。

速度与成本（实测）：建树 3-8 分钟（一次性），单次查询 5-15 秒，云服务 ¥0.3-1.5/次。比向量 RAG 慢一个数量级，但对”要精确、要溯源”的财报、合同、合规场景，这延迟可以接受。