PageIndex：无向量推理驱动 RAG 革命，AI 检索如何告别向量嵌入依赖

背景：从「模糊匹配」到「精准导航」—— RAG 检索范式的根本困境

自 2023 年 RAG（Retrieval-Augmented Generation，检索增强生成）成为大模型应用的主流范式以来，整个行业投入了海量资源去优化它。向量数据库供应商融资不断，Embedding 模型迭代迅速，分块策略的论文层出不穷。然而，一个根本性的问题始终没有被正面回答——

我们是否真的需要用「语义相似度」来检索知识？

回顾一下传统 RAG 的核心流程：

用户提问 → 查询文本向量化 → 在向量数据库中 Top-K 检索 → 拼接上下文 → LLM 生成

这个流程看起来自然，但它建立在一个并不稳固的假设上：语义相似度能够代表答案相关性。然而现实中，这个假设经常失效。

当用户问"2023 年 Q3 净利润是多少"，传统 RAG 可能返回语义上与"利润""Q3""2023"相似的所有文本块——有时是收入增长描述，有时是成本分析，有时是税率讨论。每一个都沾边，但拼不出用户真正想要的数字。Embedding 做的本质上是"模糊照片匹配"，而不是"目录导航"。

这就是向量 RAG 的根本局限：它用几何距离模拟语义关联，用概率相似度替代精确推理。当文档结构清晰、问题明确时，这种"猜测式"检索尚可接受；但当文档复杂度提升、问题粒度变细时，它的精度瓶颈就暴露无遗。

2026 年，一个全新的 RAG 流派正在颠覆这一切——无向量推理驱动检索（Vectorless Reasoning-Driven Retrieval）。其中的代表性框架 PageIndex，彻底抛弃了 Embedding、向量数据库和相似度计算，让 LLM 像人类专家一样：先读目录，再定位章节，最后精读答案。

这一范式转变，不只是工程上的优化，而是对 RAG 底层逻辑的重构。本文将深入拆解 PageIndex 的架构设计、核心算法原理、实战代码，以及它与向量 RAG 的全面对比。

一、传统 RAG 到底做错了什么：切块陷阱与向量地狱

在深入理解 PageIndex 之前，我们先系统性地拆解传统向量 RAG 的四大根本缺陷。这不是为了否定向量 RAG 的价值，而是要搞清楚：在什么条件下，向量 RAG 是最优解，在什么条件下，它反而成了瓶颈。

1.1 固定切块策略的语义破坏

传统 RAG 的第一步，是将文档切分成固定大小的文本块（Chunk）。这个动作看似简单，实际上是整个系统精度上限的决定性因素之一。

常见的切块策略包括：

# 策略一：固定大小切块（Fixed-Size Chunking）
def fixed_chunk(text, chunk_size=500, overlap=50):
    chunks = []
    for i in range(0, len(text), chunk_size - overlap):
        chunks.append(text[i:i + chunk_size])
    return chunks

# 策略二：递归字符分割（Recursive Character Splitting）
def recursive_chunk(text, delimiters=['\n\n', '\n', '. ']):
    # 按优先级递减的分割符递归切分，保留语义单元
    pass

# 策略三：语义感知分割（Semantic-Aware Splitting）
def semantic_chunk(text):
    # 按句子边界 + 段落结构切分，尽量保持语义完整性
    pass

无论哪种策略，固定切块都面临一个不可能三角：块太大 → 上下文窗口浪费 + 噪声引入；块太小 → 上下文断裂 + 关系丢失。

以一份 50 页的财务报告为例：

├── 第1章 执行摘要 (页1-5)         ← 块A
├── 第2章 财务状况 (页6-20)        ← 块B
│   ├── 2.1 资产负债表 (页6-10)   ← 块B1
│   ├── 2.2 利润表 (页11-15)      ← 块B2
│   └── 2.3 现金流量表 (页16-20)  ← 块B3
└── 第3章 风险分析 (页21-50)       ← 块C

如果按 500 字符固定切块，"2.2 利润表"的内容可能和"2.1 资产负债表"混在同一个块里，导致语义混淆。而用户问"本季度净利润"时，系统可能返回的是资产负债表相关的块——因为它们的向量在语义空间中足够接近。

这是一个结构清晰、答案确定的问题，却被向量检索的不精确性搞成了"大海捞针"。

1.2 Embedding 模型的精度天花板

Embedding 模型（BERT、Sentence-BERT、E5 等）将文本映射到高维向量空间，通过余弦相似度或点积来衡量文本间的语义距离。问题是，这个映射过程天然存在信息损失：

1. 语义压缩失真：一段包含精确数字、日期、代码的文本被压缩成几百维向量后，精确信息几乎完全丢失。用户问"2023 年 Q3 净利润同比增长率"，Embedding 只能记住"2023""Q3""净利润""增长"这几个语义标签，具体的数字百分比完全无法保留。

2. 领域适配问题：通用 Embedding 模型在金融、法律、医疗等专业领域的精度显著下降。金融文档中的"EBITDA""递延所得税资产"，与通用语料中的词义完全不同，但 Embedding 模型往往无法区分。

3. 多语言与符号的语义鸿沟：数学公式、化学结构式、代码片段的语义很难被自然语言 Embedding 准确捕获。Embedding 模型对"LaTeX 公式"的理解，远不如对"文字描述公式"的理解。

1.3 向量数据库的运维成本

引入向量数据库（Pinecone、Milvus、Chroma、Weaviate 等）意味着额外的运维复杂度：

• 容量规划：向量数据库需要预分配存储空间，高密度向量（如 1536 维 OpenAI text-embedding-3-small）的存储成本是普通文本的数十倍。
• 索引维护：新增文档需要重新索引，生产环境中要做到实时更新的同时保证检索性能，是一件工程上极富挑战的事情。
• 精确检索 vs 近似检索的矛盾：向量数据库通常使用 HNSW、IVF 等近似最近邻（ANN）算法，在召回率（Recall）和吞吐量之间做权衡。这意味着即使理论上语义相关的内容存在，也有可能被漏掉。

1.4 端到端精度难以保障

传统 RAG 系统有太多"黑盒"环节，每个环节都有精度损失：

文档 → [切块] → [Embedding] → [向量检索] → [上下文拼接] → [LLM生成]
           ↓           ↓            ↓             ↓
         语义断裂    向量失真    近似漏检      上下文污染

当用户问一个需要综合多个章节才能回答的问题时，传统 RAG 的链路式误差累积会导致最终答案偏离正确方向，甚至产生幻觉。

二、PageIndex 的核心思想：让 LLM 像图书管理员一样翻书

2.1 一句话理解 PageIndex

PageIndex 是一个无向量（Vectorless）的 RAG 框架。它抛弃了 Embedding 和向量数据库，转而让 LLM 通过文档的树形层级结构进行推理式检索——就像人类专家读书，先看目录，再定位章节，最后精读答案。

这个设计理念来源于一个朴素的观察：人类阅读长文档时，从不使用"语义相似度"。

当你拿到一本《深入理解计算机系统》时，你会：

1. 看目录，了解书的整体结构（Chapter 1 → 系统概述, Chapter 2 → 程序结构...）
2. 根据问题定位章节：问"函数调用栈帧结构"→ 定位到 Chapter 3
3. 翻到对应章节，快速浏览小节标题，找到精确段落

你不会把书的每一页都扫描成一张"模糊照片"，然后用"语义相似度"去找答案。这种方法对人类来说是低效的——对 LLM 来说，同样低效。

2.2 生活化类比：三种场景下的检索对比

场景一：餐厅点菜

结果：传统 RAG 可能返回"酸汤肥牛"（酸味相似）、"水煮鱼"（鱼相似）——都不对。PageIndex 直接命中。

场景二：图书馆查资料

用户问题："美联储 2023 年的通胀监控策略"

结果：传统 RAG 给的是"正确答案的碎片"，PageIndex 给的是"正确答案本身"。

场景三：查快递物流

2.3 PageIndex 的核心工作流

文档上传
    ↓
┌─────────────────────────────┐
│  Step 1: 构建树形索引（生成"智能目录"）  │
│  LLM 分析文档层级结构，生成 JSON 树   │
│  节点 = 章节标题 + 页码范围 + 摘要   │
└─────────────────────────────┘
    ↓
┌─────────────────────────────┐
│  Step 2: 推理检索（ReRank + Tree Walk）  │
│  LLM 根据用户问题推理定位到树中分支   │
│  结合页面范围信息精准提取答案块       │
└─────────────────────────────┘
    ↓
返回精确上下文 → LLM 生成

这个流程中，没有任何 Embedding 计算，没有任何向量数据库查询。完全基于文档的原生结构信息和 LLM 的推理能力。

三、架构深度解析：从索引构建到推理检索的全链路拆解

3.1 树形索引的构建逻辑

PageIndex 的第一步，是将原始文档转换为树形索引结构（JSON Tree）。这个过程由 LLM 自动完成，无需人工定义 schema。

构建输入：

• 原始文档（PDF、Markdown、HTML、Word 等）
• 可选：文档的目录信息（如果原始文档包含 TOC）

构建输出：

{
  "root": {
    "title": "2024年Q3财务报告",
    "page_range": "1-50",
    "children": [
      {
        "title": "1. 执行摘要",
        "page_range": "1-5",
        "children": []
      },
      {
        "title": "2. 财务状况",
        "page_range": "6-20",
        "children": [
          {
            "title": "2.1 资产负债表",
            "page_range": "6-10",
            "children": []
          },
          {
            "title": "2.2 利润表",
            "page_range": "11-15",
            "children": [
              {
                "title": "2.2.1 营业收入",
                "page_range": "11-12",
                "children": []
              },
              {
                "title": "2.2.2 净利润",
                "page_range": "13-14",
                "children": []
              }
            ]
          }
        ]
      }
    ]
  }
}

LLM 驱动构建的实现代码：

import json
from typing import List, Dict, Any

class DocumentTreeBuilder:
    """
    使用 LLM 自动分析文档结构，构建树形索引
    核心思想：让 LLM 读取文档后，像人类一样总结出章节目录结构
    """

    SYSTEM_PROMPT = """你是一个专业的文档结构分析专家。请分析输入文档的层级结构，
    生成一个树形 JSON 索引。每个节点包含：
    - title: 章节标题
    - page_range: 页码范围（如 "1-5"）
    - children: 子章节列表
    - summary: 章节内容摘要（用于推理检索）
    
    注意：
    1. 只提取文档的实际层级结构，不要虚构内容
    2. 页码范围要精确
    3. 每个叶节点至少包含 2-3 句内容摘要
    4. JSON 必须严格合法，不需要 markdown 包裹"""

    def __init__(self, llm_client):
        self.llm = llm_client

    def build_index(self, document_content: str, file_type: str = "pdf") -> Dict[str, Any]:
        """
        构建文档树形索引

        Args:
            document_content: 文档的纯文本内容
            file_type: 文档类型（pdf/markdown/html）

        Returns:
            树形索引 JSON 对象
        """
        user_prompt = f"请分析以下{file_type}文档的结构，生成树形索引：\n\n{document_content[:8000]}"

        response = self.llm.chat(
            system=self.SYSTEM_PROMPT,
            user=user_prompt,
            response_format="json_object"
        )

        return json.loads(response.content)

    def build_index_from_pdf(self, pdf_path: str) -> Dict[str, Any]:
        """
        从 PDF 文件构建索引
        需要先用 PyMuPDF 或 pdfplumber 提取文本
        """
        import fitz  # PyMuPDF

        doc = fitz.open(pdf_path)
        full_text = ""

        for page_num, page in enumerate(doc, start=1):
            text = page.get_text()
            full_text += f"\n--- 第 {page_num} 页 ---\n{text}"

        return self.build_index(full_text, file_type="pdf")


# 简化使用示例
def demo_tree_builder():
    # 模拟一个简单文档的树形索引构建
    sample_doc = """
    ## 第1章 公司概况
    本章介绍公司的基本信息，包括成立时间、业务范围等。

    ### 1.1 公司历史
    公司成立于2010年，专注于金融科技领域。

    ### 1.2 业务范围
    公司主要提供支付结算、风险管理等金融科技服务。

    ## 第2章 财务数据
    本章详细披露公司的财务状况。

    ### 2.1 收入情况
    2024年Q3实现营业收入15.6亿元，同比增长23%。

    ### 2.2 利润情况
    2024年Q3净利润为3.2亿元，净利率为20.5%。
    """

    tree = {
        "root": {
            "title": "公司季度报告",
            "page_range": "1-20",
            "summary": "某公司2024年Q3季度报告，包含公司概况和财务数据",
            "children": [
                {
                    "title": "1. 公司概况",
                    "page_range": "1-10",
                    "summary": "介绍公司历史和业务范围",
                    "children": [
                        {
                            "title": "1.1 公司历史",
                            "page_range": "1-5",
                            "summary": "公司成立于2010年，专注金融科技"
                        },
                        {
                            "title": "1.2 业务范围",
                            "page_range": "6-10",
                            "summary": "支付结算、风险管理等金融科技服务"
                        }
                    ]
                },
                {
                    "title": "2. 财务数据",
                    "page_range": "11-20",
                    "summary": "2024年Q3财务状况详细披露",
                    "children": [
                        {
                            "title": "2.1 收入情况",
                            "page_range": "11-15",
                            "summary": "营业收入15.6亿元，同比增长23%"
                        },
                        {
                            "title": "2.2 利润情况",
                            "page_range": "16-20",
                            "summary": "净利润3.2亿元，净利率20.5%"
                        }
                    ]
                }
            ]
        }
    }

    print("树形索引构建完成:")
    print(json.dumps(tree, ensure_ascii=False, indent=2))
    return tree

3.2 推理检索引擎：两步定位法

PageIndex 的检索分为两个精确的步骤，区别于向量 RAG 的"一锅炖"：

Step 1：LLM 推理定位（Reasoning-Based Navigation）

class PageIndexRetriever:
    """
    PageIndex 推理检索器
    核心：让 LLM 推理出用户问题应该定位到树形索引的哪个分支
    """

    NAVIGATION_PROMPT = """你是一个专业的图书管理员。用户提供一个问题，你需要根据文档的树形索引，
    推理出这个问题最可能属于哪个章节分支。

    索引结构：
    {tree_json}

    用户问题：{user_question}

    请按以下 JSON 格式回答（只需返回 JSON，不要其他内容）：
    {{
        "reasoning": "你的推理过程：为什么这个问题应该去这个分支？",
        "target_path": ["根节点标题", "子节点1", "子节点2", ...],
        "page_range": "预计的页码范围",
        "confidence": 0.0-1.0  # 你对这个判断的置信度
    }}
    """

    def __init__(self, tree_index: Dict, llm_client):
        self.tree = tree_index
        self.llm = llm_client

    def retrieve(self, question: str) -> Dict:
        """
        根据问题推理定位到树中节点

        Args:
            question: 用户问题

        Returns:
            定位结果：目标节点路径、页码范围、推理依据
        """
        tree_json = json.dumps(self.tree, ensure_ascii=False)

        response = self.llm.chat(
            system="你是一个精确的信息定位专家。",
            user=self.NAVIGATION_PROMPT.format(
                tree_json=tree_json,
                user_question=question
            ),
            response_format="json_object"
        )

        result = json.loads(response.content)

        # 精确定位：结合页码范围提取原文
        target_node = self._walk_tree(self.tree, result["target_path"])

        return {
            "target_node": target_node,
            "page_range": result["page_range"],
            "reasoning": result["reasoning"],
            "confidence": result["confidence"]
        }

    def _walk_tree(self, node: Dict, path: List[str]) -> Dict:
        """根据路径在树中精确定位节点"""
        if not path:
            return node

        current = path[0]
        for child in node.get("children", []):
            if child["title"] == current:
                return self._walk_tree(child, path[1:])

        return node  # fallback: 返回当前节点

Step 2：精确提取答案块（Precision Extraction）

    def extract_answer(self, question: str, node: Dict, full_document: str) -> str:
        """
        在定位到的节点范围内，精确提取答案

        这个步骤让 LLM 在确定的页码范围内做精准提取，
        而不是在整个文档中"猜测"最相关的内容
        """
        extraction_prompt = f"""文档树结构显示，用户的问题「{question}」最可能位于：
        章节：{node.get('title', 'N/A')}
        摘要：{node.get('summary', 'N/A')}
        页码范围：{node.get('page_range', 'N/A')}

        请在以下完整文档中，找到该章节的完整内容（注意页码范围）：
        ==========
        {full_document}
        ==========

        返回的内容必须：
        1. 严格在该章节的页码范围内
        2. 包含所有相关的具体数据、日期、数字
        3. 保持原文的完整性，不要摘要或改写
        """

        answer = self.llm.chat(
            system="你是一个精确的信息提取专家，只提取原始内容，不添加任何解释。",
            user=extraction_prompt
        )

        return answer.content

3.3 推理检索 vs 向量检索：本质差异

四、实战：PageIndex 检索系统完整实现

4.1 项目结构

pageindex-rag/
├── pageindex/
│   ├── __init__.py
│   ├── tree_builder.py      # 树形索引构建器
│   ├── retriever.py         # 推理检索引擎
│   ├── extractor.py          # 答案精确提取器
│   ├── document_parser.py    # 文档解析（PDF/MD/HTML）
│   └── config.py             # 配置管理
├── tests/
│   └── test_retriever.py
├── examples/
│   └── financial_report_demo.py
└── requirements.txt

4.2 核心检索循环完整实现

#!/usr/bin/env python3
"""
PageIndex RAG 完整检索演示
功能：上传文档 → 构建树形索引 → 推理检索 → 精确提取答案
"""

import json
from dataclasses import dataclass
from typing import List, Optional
from tree_builder import DocumentTreeBuilder
from retriever import PageIndexRetriever
from extractor import AnswerExtractor


@dataclass
class RetrievalResult:
    """检索结果"""
    question: str
    target_node_title: str
    target_path: List[str]
    page_range: str
    reasoning: str
    extracted_context: str
    confidence: float

    def __str__(self):
        return f"""
=== PageIndex 检索结果 ===

问题：{self.question}

目标章节：{' → '.join(self.target_path)}
页码范围：{self.page_range}
置信度：{self.confidence:.1%}

推理过程：
{self.reasoning}

提取的上下文：
{self.extracted_context}
"""


class PageIndexRAG:
    """
    PageIndex 完整 RAG 系统
    支持文档上传、树形索引构建、推理检索、答案生成
    """

    def __init__(self, llm_provider: str = "openai", model: str = "gpt-4o"):
        self.llm_provider = llm_provider
        self.model = model
        self.tree_builder = DocumentTreeBuilder(llm_client=self._get_llm_client())
        self.index: Optional[dict] = None
        self.document_content: Optional[str] = None
        self.retriever: Optional[PageIndexRetriever] = None

    def _get_llm_client(self):
        """获取 LLM 客户端（示例：OpenAI）"""
        from openai import OpenAI
        return OpenAI()

    def ingest_document(self, file_path: str) -> dict:
        """
        文档摄入：解析文档并构建树形索引

        Args:
            file_path: 文档路径（支持 PDF/MD/HTML）

        Returns:
            构建完成的树形索引
        """
        # 1. 解析文档
        if file_path.endswith('.pdf'):
            self.document_content = self._parse_pdf(file_path)
        elif file_path.endswith('.md'):
            with open(file_path) as f:
                self.document_content = f.read()
        else:
            raise ValueError(f"Unsupported file type: {file_path}")

        # 2. 构建树形索引
        self.index = self.tree_builder.build_index(
            self.document_content,
            file_type=file_path.split('.')[-1]
        )

        # 3. 初始化检索器
        self.retriever = PageIndexRetriever(
            tree_index=self.index,
            llm_client=self._get_llm_client()
        )

        print(f"✅ 文档摄入完成")
        print(f"   索引节点数：{self._count_nodes(self.index)}")
        print(f"   文档长度：{len(self.document_content)} 字符")

        return self.index

    def _parse_pdf(self, pdf_path: str) -> str:
        """解析 PDF 为纯文本"""
        import fitz
        doc = fitz.open(pdf_path)
        text = ""
        for page_num, page in enumerate(doc, start=1):
            text += f"\n--- Page {page_num} ---\n{page.get_text()}"
        return text

    def _count_nodes(self, tree: dict) -> int:
        """统计树形索引节点数"""
        count = 1
        for child in tree.get("children", []):
            count += self._count_nodes(child)
        return count

    def query(self, question: str, extract_full_context: bool = True) -> RetrievalResult:
        """
        查询：推理检索 + 精确提取

        Args:
            question: 用户问题
            extract_full_context: 是否提取完整上下文

        Returns:
            检索结果对象
        """
        if not self.retriever:
            raise RuntimeError("请先调用 ingest_document() 摄入文档")

        # Step 1: LLM 推理定位
        retrieval = self.retriever.retrieve(question)

        # Step 2: 精确提取答案
        if extract_full_context:
            target_node = retrieval["target_node"]
            extractor = AnswerExtractor(llm_client=self._get_llm_client())
            extracted_context = extractor.extract(
                question=question,
                target_node=target_node,
                full_document=self.document_content
            )
        else:
            extracted_context = target_node.get("summary", "")

        return RetrievalResult(
            question=question,
            target_node_title=retrieval["target_node"].get("title", ""),
            target_path=retrieval.get("target_path", []),
            page_range=retrieval["page_range"],
            reasoning=retrieval["reasoning"],
            extracted_context=extracted_context,
            confidence=retrieval["confidence"]
        )

    def save_index(self, output_path: str):
        """保存树形索引到文件"""
        with open(output_path, 'w', encoding='utf-8') as f:
            json.dump(self.index, f, ensure_ascii=False, indent=2)
        print(f"✅ 索引已保存到：{output_path}")

    def load_index(self, index_path: str, document_content: str):
        """从文件加载树形索引"""
        with open(index_path, encoding='utf-8') as f:
            self.index = json.load(f)
        self.document_content = document_content
        self.retriever = PageIndexRetriever(
            tree_index=self.index,
            llm_client=self._get_llm_client()
        )
        print(f"✅ 索引已加载，共 {self._count_nodes(self.index)} 个节点")


# ==================== 使用示例 ====================

def demo_financial_report():
    """
    演示：财务报告问答系统
    场景：用户上传一份季度财务报告，通过 PageIndex 进行精准问答
    """

    # 模拟财务报告内容
    financial_report = """
    ====== 2024年Q3财务报告 ======

    --- Page 1 ---
    2024年第三季度财务报告

    --- Page 2 ---
    第1章 执行摘要
    本季度公司实现营业收入15.6亿元，同比增长23%；净利润3.2亿元，同比增长18%；
    净利率为20.5%，较去年同期提升1.2个百分点。

    --- Page 3 ---
    第2章 详细财务数据

    --- Page 4 ---
    2.1 收入分析
    2024年Q3营收构成：
    - 主营业务收入：13.2亿元（占比84.6%）
    - 其他业务收入：2.4亿元（占比15.4%）
    同比来看，主营业务收入增长25%，其他业务收入增长12%。

    --- Page 5 ---
    2.2 成本分析
    营业成本为9.8亿元，毛利率为37.2%。
    主要成本构成：
    - 原材料成本：5.6亿元
    - 人工成本：2.8亿元
    - 制造费用：1.4亿元

    --- Page 6 ---
    2.3 利润表
    营业收入：15.6亿元
    营业成本：9.8亿元
    毛利润：5.8亿元
    毛利率：37.2%
    营业费用：1.8亿元
    管理费用：0.6亿元
    净利润：3.2亿元
    净利率：20.5%

    --- Page 7 ---
    第3章 风险分析
    本季度主要风险因素包括：
    1. 原材料价格波动风险
    2. 市场需求变化风险
    3. 汇率波动风险
    """

    # 初始化系统
    rag = PageIndexRAG(llm_provider="openai", model="gpt-4o")

    # 构建树形索引
    tree = rag.tree_builder.build_index(financial_report, "text")
    rag.index = tree
    rag.document_content = financial_report
    rag.retriever = PageIndexRetriever(tree_index=tree, llm_client=rag._get_llm_client())

    # 问答演示
    questions = [
        "本季度净利润是多少？",
        "毛利率和净利率分别是多少？",
        "主营业务收入同比增长了多少？",
    ]

    for q in questions:
        result = rag.query(q)
        print(result)


# ==================== MCP 协议集成 ====================

class PageIndexMCPAdapter:
    """
    PageIndex MCP 协议适配器
    让 PageIndex 可以作为 MCP Server 被其他 AI Agent 调用
    """

    TOOL_DEFINITION = {
        "name": "pageindex_retrieve",
        "description": "使用 PageIndex 无向量推理检索从文档中精确提取答案",
        "input_schema": {
            "type": "object",
            "properties": {
                "question": {
                    "type": "string",
                    "description": "用户问题"
                },
                "document_id": {
                    "type": "string",
                    "description": "已摄入的文档 ID"
                }
            },
            "required": ["question", "document_id"]
        }
    }

    def __init__(self, rag_system: PageIndexRAG):
        self.rag = rag_system

    def handle_tool_call(self, tool_input: dict) -> dict:
        """
        处理 MCP 工具调用
        """
        question = tool_input["question"]
        document_id = tool_input["document_id"]

        result = self.rag.query(question)

        return {
            "content": [
                {
                    "type": "text",
                    "text": f"目标章节：{result.target_node_title}\n"
                            f"页码范围：{result.page_range}\n"
                            f"置信度：{result.confidence:.1%}\n\n"
                            f"提取内容：\n{result.extracted_context}"
                }
            ]
        }

4.3 与 LangChain/LlamaIndex 集成

from langchain_core.tools import tool
from pageindex_rag import PageIndexRAG

# 全局 RAG 实例
_pageindex_rag: PageIndexRAG = None

def init_pageindex():
    global _pageindex_rag
    _pageindex_rag = PageIndexRAG(llm_provider="openai")
    _pageindex_rag.ingest_document("./docs/annual_report_2024.pdf")

@tool
def pageindex_search(question: str) -> str:
    """
    在财务文档中精确检索答案。

    适用场景：
    - 查询具体的数字、日期、金额
    - 需要完整上下文而非碎片信息
    - 金融、法律、医疗等高精度文档检索

    不适用场景：
    - 开放式知识问答（用通用 RAG）
    - 跨文档综合分析（用 Agent 编排）
    """
    if not _pageindex_rag:
        return "请先初始化 PageIndex 系统"

    result = _pageindex_rag.query(question)
    return f"""
📑 检索结果

章节：{result.target_node_title}
页码：{result.page_range}
置信度：{result.confidence:.1%}

内容：
{result.extracted_context}
"""

五、性能对比：向量 RAG vs PageIndex 推理 RAG

5.1 金融文档基准测试

在金融文档（年报、研报、财务报表）上，对比两种 RAG 在精确数字查询任务上的表现：

结论：在需要精确数字、完整段落上下文的场景，PageIndex 的准确率远超向量 RAG，幻觉率降低 10 倍。代价是检索延迟略高——但对于知识库问答场景，200-500ms 的延迟完全可接受。

5.2 适用场景选型决策树

你的文档检索场景
    │
    ├── 是否需要精确数字/日期/代码/公式？
    │   ├── 是 → PageIndex ✅（精确提取，原文保留）
    │   └── 否 ↓
    │
    ├── 文档结构是否清晰（层级分明）？
    │   ├── 是 → PageIndex ✅（树形索引优势明显）
    │   └── 否（碎片化、混合文档）↓ 
    │
    ├── 是否跨多文档综合分析？
    │   ├── 是 → Agent 编排 + 向量 RAG（多跳能力）
    │   └── 否 → 向量 RAG（适合开放式语义匹配）
    │
    └── 部署运维复杂度要求？
        ├── 极简优先 → PageIndex ✅（零外部依赖）
        └── 向量基础设施完善 → 向量 RAG（已有 Pinecone/Milvus）

5.3 混合架构：PageIndex + 向量 RAG 双轨并行

在生产环境中，可以将两者结合：

class HybridRAG:
    """
    混合 RAG 架构：PageIndex + 向量 RAG 双轨并行
    根据问题类型自动选择最优检索路径
    """

    ROUTING_PROMPT = """分析用户问题，决定使用哪种检索策略：

    PageIndex 适用（精确、结构化文档）：
    - 需要具体数字、日期、金额
    - 文档结构清晰（章节目录）
    - 问题明确，不需要发散

    向量 RAG 适用（开放、语义匹配）：
    - 概念解释、定义查询
    - 跨主题综合分析
    - 文档结构不清晰

    用户问题：{question}

    返回格式：{{"strategy": "pageindex" | "vector" | "hybrid"}}
    """

    def __init__(self):
        self.pageindex = PageIndexRAG()
        self.vector_rag = VectorRAG()  # 传统向量 RAG

    def query(self, question: str) -> str:
        strategy = self._route(question)

        if strategy == "pageindex":
            return self.pageindex.query(question)
        elif strategy == "vector":
            return self.vector_rag.query(question)
        else:  # hybrid
            pi_result = self.pageindex.query(question)
            vec_result = self.vector_rag.query(question)
            return self._merge_results(pi_result, vec_result)

六、PageIndex 的局限性与适用边界

任何技术都有它的边界。PageIndex 也不例外。理性分析它的局限性，才能正确使用它。

6.1 不适合 PageIndex 的场景

1. 非结构化 / 碎片化文档
如果文档没有清晰的层级结构（如社交媒体评论、论坛帖子、混合内容网页），PageIndex 的"目录导航"优势就消失了。此时，向量 RAG 的语义匹配反而更灵活。

2. 开放式概念查询
用户问"介绍一下机器学习中的梯度下降"，这不需要精确数字，也没有明确的目标章节。向量 RAG 可以从多个角度返回相关概念；PageIndex 反而需要用户指定"哪本书的哪章"。

3. 超大规模文档库
当文档库达到百万级时，LLM 推理定位的计算成本会显著上升。PageIndex 的树形索引需要在内存中完整加载，横向扩展性不如向量数据库的分片方案。

4. 实时性要求极高的场景
PageIndex 的 LLM 推理延迟（200-500ms）比纯向量检索（50-100ms）高 3-5 倍。在毫秒级延迟要求的场景（如搜索补全），PageIndex 不适用。

6.2 PageIndex 的最佳实践

# 最佳实践一：选择结构清晰的文档优先使用
PREFERRED_DOC_TYPES = [
    "财务报告（年报/季报/招股书）",
    "法律合同与协议",
    "技术规格文档",
    "学术论文与研究报告",
    "政策文件与标准规范",
    "API 文档与开发手册",
]

# 最佳实践二：索引更新采用增量策略
def incremental_index_update(tree: dict, new_section: dict, parent_path: List[str]):
    """
    增量更新树形索引，避免全量重建
    只更新受影响的分支节点
    """
    pass

# 最佳实践三：多语言文档的索引构建
MULTILINGUAL_PROMPT = """分析以下多语言文档结构，
请同时考虑中英文标题和章节编号规律。
...
"""

七、总结与展望：从向量时代到推理时代

PageIndex 代表的"无向量推理检索"，给 RAG 领域带来了一次范式级的思考：

传统向量 RAG 的核心假设是：语义相似度能够代表答案相关性。 这个假设在很多场景下成立，但不是所有场景。

PageIndex 的核心假设是：文档结构信息和 LLM 推理能力，能够比语义相似度更精确地定位答案。 在结构化文档（财务报告、法律合同、技术文档）上，这个假设被验证了——准确率从 67% 提升到 97%，幻觉率从 23% 降到 2%。

这并不意味着向量 RAG 会消亡。在非结构化、碎片化、开放式文档检索场景，向量 RAG 仍然是最实用的方案。两者不是取代关系，而是互补关系。

2026 年的 RAG 生态正在走向分化：

• 精确检索场景（金融、法律、医疗、政府文档）→ PageIndex / Vectorless RAG
• 语义匹配场景（知识库问答、内容推荐、开放搜索）→ 向量 RAG
• 复杂推理场景（多跳分析、跨文档综合）→ Agent 编排 + 混合 RAG

从更宏观的视角看，PageIndex 反映了一个更大的趋势：随着 LLM 推理能力的持续提升，越来越多的"工程问题"正在变成"推理问题"。以前我们用精确算法（倒排索引、向量相似度）来解决信息检索；现在，我们开始让 LLM 自己推理"翻到哪一页"。

这个转变的意义远不止 RAG 本身。它预示着：在 LLM 推理能力足够强的情况下，很多基于"启发式规则"的信息系统，都可能迎来一次"推理化"重构。

这不是对传统方法的否定，而是让 AI 做它最擅长的事——推理，而不是猜测。

参考资源

• PageIndex 官方：https://vectify.ai/
• GitHub：搜索 pageindex 或 vectorless RAG
• 相关论文：Vectorless RAG, Reasoning-Based Document Retrieval
• 配套工具：PyMuPDF（PDF解析）、tree-sitter（代码结构解析）

本文首发于程序员茄子（chenxutan.com），如需转载，请联系作者。