RAG 领域有个根深蒂固的假设：检索必须靠向量相似度匹配。

把文档切成块，算 embedding，塞进向量数据库，查询时算余弦相似度取 top-K——这套流程已经成了"标准答案"。但问题在于，语义相似不等于真正相关。 你问一个金融报告里的具体数字，向量检索可能把看起来"像"但完全不是同一张表的段落拽出来。

GitHub 上一个叫 PageIndex 的项目（29,300+ 星），直接挑战了这个假设：不用向量数据库，不做切块，靠 LLM 推理来检索。

本文提纲

1. 核心思路：像人一样读文档
2. 树索引：把目录变成 LLM 能理解的结构
3. 检索过程：Agent 自己决定看哪里
4. 效果：FinanceBench 98.7% 准确率
5. 三种部署方式
6. 适合什么场景？

核心思路：像人一样读文档

想象一个专家拿到一份 200 页的财报，要回答"公司 2025 年 Q3 的海外营收占比是多少"。

他不会把整份报告切成 500 个片段然后逐个看"像不像"这个问题。他会：

1. 翻目录 — 找到"财务数据"或"营收分析"章节
2. 精确定位 — 跳到对应页码
3. 读具体内容 — 提取数字
4. 判断充分性 — 信息不够就继续翻

PageIndex 就是把这个过程编码成 LLM Agent 的行为。核心区别：检索不是靠"什么看起来相似"，而是靠推理决定"下一步该看哪里"。

树索引：把目录变成 LLM 能理解的结构

PageIndex 把长文档转换成一个 JSON 格式的层级树状索引。长这样：

{
  "doc_name": "Annual Report 2025",
  "structure": [
    {
      "node_id": "0001",
      "title": "Financial Overview",
      "start_index": 15,
      "end_index": 28,
      "summary": "公司整体财务表现，包含营收、利润...",
      "nodes": [
        {
          "node_id": "0002",
          "title": "Revenue by Region",
          "start_index": 20,
          "end_index": 23,
          "summary": "按地区拆分的营收数据..."
        }
      ]
    }
  ]
}

每个节点包含标题、页码范围、摘要和递归的子节点。这个索引是一个 "in-context index"——直接驻留在 LLM 的推理上下文中，LLM 可以导航、引用和推理。

索引构建本身也靠 LLM：检测目录 → 提取结构 → 转换为 JSON → 页码定位 → 验证 → 生成摘要，每一步都是 LLM 调用。支持 PDF 和 Markdown 两种格式。

检索过程：Agent 自己决定看哪里

检索是 agentic 的。PageIndex 给 LLM Agent 暴露三个工具：

• get_document_structure() — 拿到树索引（不含正文，省 token）
• get_page_content(pages="20-23") — 读取指定页码的原始文本
• get_document() — 获取文档元数据

Agent 的检索流程：

1. 调用 get_document_structure() 拿到树索引
2. 看一遍结构，推理判断答案最可能在哪个章节
3. 调用 get_page_content(pages="X-Y") 读具体内容
4. 信息不够？继续推理，去其他章节找
5. 收集够了，生成答案——每个结论都带页码引用

全程可追溯、可解释。 你知道它读了哪些页、为什么读那些页、答案从哪来。传统 RAG 做不到这点——向量相似度是个黑盒，你很难解释"为什么返回了这 5 个 chunk"。

效果：FinanceBench 98.7% 准确率

官方在 FinanceBench（金融报告问答基准）上的对比：

30% 到 98.7%，这个差距不是调参能追回来的。根本原因是金融文档的检索难点：同一个文档里可能有 10 张表，向量检索分不清你要哪张，但 PageIndex 可以通过章节标题和页码精确定位。

而且，PageIndex 声称 没有 Time-to-First-Token 延迟——传统 RAG 需要等整个检索阶段完成才能开始生成，PageIndex 的检索和生成是交替进行的。

三种部署方式

自托管（开源，MIT 协议）：

from pageindex import PageIndexClient

client = PageIndexClient(workspace="./workspace")
doc_id = client.index("financial_report.pdf")
# Agent 通过 get_document_structure() + get_page_content() 自主检索

云服务（SaaS）：

from pageindex import PageIndexClient

pi_client = PageIndexClient(api_key="YOUR_API_KEY")
result = pi_client.submit_document("./report.pdf")
response = pi_client.chat_completions(
    messages=[{"role": "user", "content": "Q3 海外营收占比多少？"}],
    doc_id=result["doc_id"]
)

MCP 集成：兼容 Claude Agent SDK、OpenAI Agents SDK、LangChain、CrewAI、Google ADK 等主流框架。只要支持 MCP 协议，直接插上就能用。

云服务按 credit 计费（1 credit/页，索引一次性消耗），如果用 MCP + 自有 LLM，PageIndex 不收 credit 费。

适合什么场景？

PageIndex 不是来替代所有 RAG 的。它的优势在结构化长文档的精确问答：

• 金融 — 年报、SEC 文件、审计报告，数字必须精确到具体页码
• 法律 — 合同、判例法，条款引用必须可追溯
• 医疗 — 临床报告、药品说明书，信息不能有偏差
• 技术 — API 文档、产品手册，用户需要精确到某个章节的答案

如果是探索性搜索——"帮我找一些关于 X 的相关内容"——传统向量 RAG 反而更合适。

PageIndex 传递了一个重要信号：RAG 不等于向量检索。 检索的本质是信息定位，语义相似度只是其中一种策略，LLM 推理是另一种。在需要精确性的场景下，推理比相似度靠谱得多。

项目地址：https://github.com/VectifyAI/PageIndex

作者: itech001
来源: 公众号：AI人工智能时代
主页: https://www.theaiera.cn（每日分享最前沿的AI新闻和技术）

本文首发于 AI人工智能时代，转载请注明出处。