invalid s1. 无向量RAG：重新定义文档检索的新范式
在传统RAG系统中，我们经常遇到一个令人沮丧的场景：当你向AI询问一份200页合同中的具体条款时，系统可能会返回一个看似相关但实际上错误的答案。这种情况并非模型本身的问题，而是传统检索方法的根本缺陷——它假设"看起来相似的文本就是相关文本"，这种假设在处理结构化文档时往往会失效。
1.1 传统RAG的局限性解析
传统RAG系统通常采用两阶段流程：
- 索引阶段：将文档分割成300-500词的文本块，通过嵌入模型转换为向量表示，存储在向量数据库中
- 查询阶段：将问题同样转换为向量，通过相似度搜索找到最接近的文本块，最后交给LLM生成答案
这种方法在处理非结构化知识库时表现尚可，但在面对法律合同、财务报告等结构化文档时，存在三个致命缺陷：
语义相似≠内容相关：向量搜索优化的只是文本相似性，而非答案的正确性。当询问"什么推动了Q3收入增长"时，系统会返回所有提到"收入"的段落，而非真正解释增长原因的段落。
分块破坏文档结构：将文档机械分割会切断原本的逻辑关联。定义在一个块中，而依赖关系和上下文在另一个块中，导致模型只能基于不完整的上下文进行猜测。
缺乏可解释性：传统方法只返回相似度分数，无法解释为什么选择某个文本块。在专业领域，这种"黑箱"特性使得错误难以被发现和纠正。
1.2 无向量RAG的核心思想
无向量RAG采用完全不同的方法，其核心思想是：让LLM像人类专家一样推理文档结构，而非依赖向量相似度。这种方法消除了对嵌入模型和向量数据库的依赖，转而构建文档的层次化表示，让模型能够智能地导航到最可能包含答案的部分。
关键创新点包括：
- 文档树：将文档转换为带有标题、页码范围和LLM生成摘要的层次化JSON结构
- 推理式检索：LLM通过分析文档树的结构和节点摘要，决定需要检索哪些部分
- 完全可追溯：系统会记录检索决策的完整推理过程，每个答案都能追溯到具体的文档部分
这种方法特别适合财务报告、法律合同、技术手册等具有清晰结构的文档类型，在这些场景下，它能提供比传统RAG更准确、更可靠的检索结果。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. PageIndex实现详解
PageIndex是一个实现无向量RAG的开源库，它通过两个核心组件解决了结构化文档检索的问题：树生成和树搜索。
2.1 文档树生成技术
PageIndex的树生成过程将原始PDF转换为富含语义信息的层次结构。每个树节点包含以下关键信息：
json复制{
"title": "Financial Stability",
"node_id": "0006",
"start_index": 21,
"end_index": 22,
"summary": "The Federal Reserve monitors financial vulnerabilities...",
"nodes": [
{
"title": "Monitoring Financial Vulnerabilities",
"node_id": "0007",
"start_index": 22,
"end_index": 28,
"summary": "The Federal Reserve's monitoring approach includes..."
}
]
}
树生成的关键技术细节：
- 结构分析：解析PDF中的标题层级和页面布局，识别文档的天然组织结构
- 内容摘要：使用LLM为每个章节生成精准摘要，保留核心语义信息
- 关系保持：维护章节间的父子关系，确保文档的逻辑完整性不被破坏
提示：在实际应用中，建议对生成的文档树进行人工校验，特别是对关键章节的摘要准确性进行检查，这可以显著提高后续检索的准确率。
2.2 基于推理的树搜索机制
当用户提出问题时，PageIndex执行以下步骤：
- 问题分析：LLM首先理解问题的实质信息需求
- 树导航：LLM遍历文档树的标题和摘要（不查看完整文本），识别潜在相关节点
- 决策生成：输出包含两部分内容：
thinking：逐步推理过程，解释为什么选择特定节点node_list：最终确定的节点ID列表
示例搜索过程：
python复制search_prompt = f"""
You are given a question and