维普论文
208.52M · 2026-02-17
文档输入 --> 文本切块(Chunking) --> 向量嵌入(Embedding) --> 存入向量数据库
|
用户提问 --> 问题向量化 --> 向量相似度检索(Top-K) --> 拼接上下文 --> LLM 生成回答
传统 RAG 系统的关键环节包括：
| 环节 | 说明 | 典型工具 |
|---|---|---|
| 文本切块 | 将文档按固定大小（如 512 tokens）切分为 chunks | LangChain、LlamaIndex |
| 向量嵌入 | 将每个 chunk 转化为高维向量表示 | OpenAI Embedding、BGE、Jina |
| 向量存储 | 将向量写入专用向量数据库 | Pinecone、Milvus、Weaviate、Chroma |
| 语义检索 | 基于余弦相似度检索最相关的 Top-K chunks | FAISS、HNSW 索引 |
| 上下文拼接 | 将检索到的 chunks 拼接为 LLM 的上下文 | Prompt 模板 |
固定大小的切块策略无法感知文档的自然结构，经常在段落中间、甚至句子中间断开，导致：
原始文档:
第三章 财务分析
3.1 营收概览
公司2024年Q3营收为52.3亿元，同比增长15.2%。
其中，核心业务贡献了38.7亿元（占比74%），
详细拆分见表3-2。
[表3-2: 业务线营收拆分]
...
切块后:
Chunk 1: "...公司2024年Q3营收为52.3亿元，同比增长15.2%。其中，核心业务贡献了38.7亿"
Chunk 2: "元（占比74%），详细拆分见表3-2。[表3-2: 业务线营收拆分]..."
--> 数字被截断，表格引用与表格内容分离
向量检索本质上是计算语义空间中的距离，但语义相似并不等于业务相关：
部署传统 RAG 需要维护一套独立的向量数据库基础设施：
| 成本项 | 说明 |
|---|---|
| 存储成本 | 向量索引占用大量内存和磁盘空间 |
| 计算成本 | 嵌入生成需要 GPU 资源，每次文档更新需重新嵌入 |
| 运维成本 | 向量数据库的集群管理、备份、扩缩容 |
| 调优成本 | chunk_size、overlap、嵌入模型选择等参数需要大量实验 |
| 一致性成本 | 文档更新后，向量索引的增量同步和一致性维护 |
复杂文档（如财报、法律合同、技术手册）中大量存在内部交叉引用：
向量检索是一个「黑箱」过程：
PageIndex 由 Vectify AI 开发，其核心理念是：
PageIndex 工作流程
文档输入 --> 结构解析 --> 构建层级文档树(Document Tree)
|
[根节点: 文档标题与摘要]
/ |
[章节1摘要] [章节2摘要] [章节3摘要]
/ | /
[3.1摘要] [3.2摘要] ... [小节摘要] [小节摘要]
| | | |
[页面内容] [页面内容] [页面内容] [页面内容]
用户提问 --> LLM 推理 --> 从根节点开始逐层决策 --> 定位到最相关的叶节点 --> 提取精确内容
PageIndex 将文档转化为一棵语义层级树，而非向量集合：
| 特性 | 说明 |
|---|---|
| 自然结构保留 | 章节、小节、段落的层级关系完整保留 |
| 节点摘要 | 每个节点包含对应内容的 LLM 生成摘要 |
| 页面对齐 | 叶节点与原文页面精确对应，支持页码引用 |
| 动态深度 | 树的深度根据文档实际结构自适应调整 |
检索过程不再是向量距离计算，而是一个多步推理过程：
用户提问: "公司2024年Q3的研发费用率是多少？"
推理步骤:
Step 1: [根节点] 阅读文档整体摘要，判断这是一份季度财报
Step 2: [章节级] 在"经营分析"、"财务报表"、"管理层讨论"中选择 --> "财务报表"
Step 3: [小节级] 在"利润表"、"资产负债表"、"现金流量表"中选择 --> "利润表"
Step 4: [页面级] 定位到利润表中包含"研发费用"行项的具体页面
Step 5: [提取] 提取研发费用金额和营收金额，计算费用率
检索路径: 根 --> 财务报表 --> 利润表 --> 第47页
每次检索都生成完整的推理链路，包含：
| 对比维度 | 传统向量 RAG | PageIndex |
|---|---|---|
| 索引方式 | 向量嵌入 + 向量数据库 | 层级文档树 |
| 文档处理 | 固定大小切块 | 按自然结构组织 |
| 检索机制 | 余弦相似度 Top-K | LLM 推理树搜索 |
| 检索依据 | 语义距离（数学计算） | 逻辑推理（类人决策） |
| 上下文保留 | 局部（单个 chunk 内） | 全局（沿树路径保留层级上下文） |
| 可解释性 | 低（向量距离难以解释） | 高（每步推理路径透明） |
| 跨引用支持 | 不支持 | 支持沿树结构追踪引用 |
| 对比维度 | 传统向量 RAG | PageIndex |
|---|---|---|
| 依赖组件 | 嵌入模型 + 向量数据库 + 应用层 | LLM + 文档解析器 |
| 基础设施 | 需要部署和维护向量数据库集群 | 无需额外数据库 |
| 参数调优 | chunk_size、overlap、top_k、嵌入模型 | 树结构生成策略 |
| 文档更新 | 需要重新嵌入并更新向量索引 | 重新生成文档树 |
| 部署复杂度 | 高（多组件协调） | 低（单一流程） |
| 成本结构 | 存储 + 计算（嵌入 + 检索） | 计算（LLM 推理调用） |
以 FinanceBench 金融文档分析基准测试为例：
| 系统 | 准确率 | 说明 |
|---|---|---|
| PageIndex (Mafin 2.5) | 98.7% | 基于推理的文档树检索 |
| GPT-4o（直接回答） | ~60-70% | 无 RAG 增强 |
| 传统向量 RAG + GPT-4o | ~75-85% | 标准向量检索流程 |
问题本质：传统 RAG 的切块策略是一个「有损压缩」过程，不可避免地破坏文档的完整性。
PageIndex 方案：保留文档自然结构，按章节/小节/页面组织信息，每个节点都包含完整的上下文。
传统 RAG: 文档 --> [chunk1] [chunk2] [chunk3] ... [chunkN] (信息碎片化)
PageIndex: 文档 --> 树状结构(章节 > 小节 > 页面) (结构完整保留)
问题本质：向量检索衡量的是语义空间中的距离，而非业务逻辑上的相关性。
PageIndex 方案：LLM 在推理过程中理解问题的真实意图，通过逻辑判断而非数学距离来定位信息。
例如，面对问题「2024年Q3净利率」：
问题本质：在合规要求严格的行业（金融、法律、医疗），不可解释的检索结果不可接受。
PageIndex 方案：每次检索生成完整的推理路径，标注来源页码和章节编号，支持人工审核和验证。
检索报告:
问题: "合同中关于知识产权归属的约定是怎样的？"
推理路径: 合同全文 --> 第五章 知识产权 --> 5.2 权利归属 --> 第23-24页
来源引用: "第5.2条 权利归属：甲方在合同期间完成的所有..."
置信度: 高（精确匹配到专属条款）
问题本质：向量数据库是一个独立的技术栈，增加了架构复杂度和运维负担。
PageIndex 方案：
| 传统 RAG 技术栈 | PageIndex 技术栈 |
|---|---|
| 应用服务 | 应用服务 |
| 嵌入模型服务 | -- |
| 向量数据库(Pinecone/Milvus) | -- |
| 文档解析器 | 文档解析器 |
| LLM 服务 | LLM 服务 |
| 共 5 个组件 | 共 3 个组件 |
问题本质：复杂文档中的交叉引用是理解文档的关键，但切块后引用关系完全丢失。
PageIndex 方案：树状结构天然支持引用追踪。当 LLM 在某个节点遇到「详见第 X 章」时，可以沿树结构导航到目标节点继续阅读。
| 场景 | 原因 |
|---|---|
| 金融报告分析 | 文档结构严谨，需要精确数值提取和多步推理 |
| 法律合同审查 | 存在大量交叉引用，需要逐条追溯 |
| 技术手册查阅 | 多层级目录结构，需要按章节定位 |
| 学术论文分析 | 段落引用关系复杂，需要上下文完整性 |
| 监管合规审查 | 对可解释性和可追溯性有严格要求 |
| 局限 | 说明 |
|---|---|
| 大规模多文档检索 | 树搜索适合单文档深度分析，跨数万篇文档检索时，向量检索的效率优势明显 |
| 非结构化文档 | 对于缺乏清晰结构的文档（如聊天记录、碎片笔记），树构建效果受限 |
| LLM 调用成本 | 每次检索需要多步 LLM 推理调用，token 消耗高于单次向量检索 |
| 实时性要求 | 多步推理的延迟高于向量检索的毫秒级响应 |
| 文档质量依赖 | 树结构的质量取决于原始文档的结构清晰度 |
选择 PageIndex 的场景:
- 单文档或少量文档深度分析
- 对准确率和可解释性要求极高（如金融、法律）
- 文档结构清晰且层级分明
- 需要跨引用追踪能力
- 希望简化基础设施栈
选择传统向量 RAG 的场景:
- 大规模知识库检索（数万至数百万文档）
- 需要毫秒级响应延迟
- 文档类型多样且结构不统一
- 需要跨文档语义关联
- 成本敏感（LLM 推理费用较高）
PageIndex 代表了 RAG 技术演进的一个重要方向，其核心贡献在于：
传统向量 RAG 和 PageIndex 并非简单的替代关系，而是在不同场景下各有优势。对于需要高精度、可解释、深度文档分析的专业场景，PageIndex 提供了一种更优雅的解决方案；对于大规模、低延迟、跨文档语义搜索的场景，传统向量 RAG 仍然是更实际的选择。
两种方案的融合（如用向量检索做粗筛，用 PageIndex 做精读）也是值得探索的方向，可以兼顾效率和精确度。
