同一份财报向量库 RAG 与 PageIndex 谁答得更准一场 10 问横评【免费下载链接】PageIndex PageIndex: Document Index for Vectorless, Reasoning-based RAG项目地址: https://gitcode.com/GitHub_Trending/pa/PageIndex把同一份 200 页的财报丢给两套检索增强生成RAG系统问同样的 10 个问题一套是切块 Embedding 向量库召回的经典路线另一套是 PageIndex 的无向量、基于推理路线。这是当下 RAG 社区最典型的一场正面交锋——财报里全是精确的数字、术语化的条款和跨页勾稽关系容不下答得差不多的幻觉恰恰是检验检索方案的试金石。过去一年社区对 PageIndex 的讨论集中在几个点上为什么可以不要向量数据库为什么不做分块每个文档都过一遍 LLM不会很慢吗这些质疑背后其实是对同一种范式切换的追问当检索从相似度匹配变成结构导航时准确率、速度、成本、可核验性四个维度分别发生了什么变化。本文以仓库中的真实语料与评测数据为证据做一场可复现的 10 问横评。为什么财报是 RAG 的高压测试场财报对 RAG 的苛刻之处恰好是向量检索的软肋。向量 RAG 用语义相似度召回而相似 ≠ 相关similarity ≠ relevance检索真正需要的是相关性相关性需要推理。年报中2023 年营业利润率这个数字与它语义最相似的不是包含答案的那句话而是同年其他财务指标的句子——按相似度排序会把真正该读的那几页排在后面。更致命的是经典 RAG 把文档切成固定大小的 chunk表格被拦腰截断、章节上下文被拆散检索结果经常相关但残缺。PageIndex 的应对是把索引从向量空间换成文档层级树索引阶段为每份文档生成树状结构索引检索阶段让 LLM 像人读长报告一样先根据目录推理该去哪一章再决定该读哪几页。维度向量 RAGPageIndex索引vector indextree index检索语义相似度搜索LLM 在树上推理结果不透明、玄学检索可追溯到显式引用上下文仅查询嵌入完整上下文对话历史、领域知识等横评设计同一份财报、同一组 10 问、统一评分口径测试语料。横评选取仓库中真实存在的两份财报类文档一份是cookbook官方演示使用的 NVIDIA FY2022–FY2026 十年报pageindex-query-pricing-demo.ipynb 与 pageindex-citation.ipynb 均以它为问答对象另一份是已生成完整树结构的联邦储备 2023 年度报告examples/results/2023-annual-report_structure.json。后者的树给出了Preface 1–4 页 → Overview 7–8 页 → Monetary Policy and Economic Developments 9–14 页 → Supervision and Regulation 32–54 页这样的真实层级正好用来演示推理导航的落点。10 问分组。五类各两问覆盖财报问答的典型形态单点事实定位某一年营业利润率是多少正文陈述型精确数值提取上年营收是多少表格型唯一答案跨页聚合某项监管指标合计/分项之和跨多页勾稽同比比较近五年营收走势与增速多文档、多年度对齐条款语义某条款的生效条件与例外是什么法律/披露语义统一评分口径。每题从四个维度打分答案正确性唯一事实答案、引用可核验性能否定位到页码甚至版块、端到端延迟、每问 token 与美元成本。对照组使用相同的 chat 模型与相同的文档仅把检索层换成分块 向量召回。官方口径参考。仓库自带的 PageIndex-OSS-Benchmark 记录了一致性更高的评测协议在 34 份 PDF共 1,945 页上跑 62 道查找题所有问题答案均为正文陈述的事实答错即检索或阅读失败而非推理失败——这套只考检索不考推理的标准正是本横评评分口径的依据。实测结果四维对比准确性结构导航把50%抬到了98.7%准确性是这场横评差距最大的维度。PageIndex 在 FinanceBench金融文档问答基准上达到 98.7% 的准确率而对照的向量 RAG 约为 50%——接近抛硬币。这一差距的机制在源码里很清楚pageindex/agent_tools.py 把检索实现为两段式工具链get_document_structure()先提取文档的层级大纲标题、章节、页码对超过 20 页的文档强制优先调用STRUCTURE_FIRST_PAGE_THRESHOLD 20定位相关章节后再用get_page_content()精确取页页面表达式支持5-7、3,8、12等。检索起点则被 doc_targeting_block 注入对话SDK 把文档元数据拼进首条 user 消息并指示模型用 get_document_structure() 和 get_page_content() 取内容检索路径从第一轮工具调用起就是结构化的。以联邦储备年报为例树结构 JSON 中 Supervision and Regulation 章节明确携带 31–59 页的边界与子节点页码2023-annual-report_structure.json模型只需一次推理命中该节点再读 32–54 页即可拿到完整上下文作答全程不经过任何相似度排序。速度回应每份文档过一遍 LLM 不会很慢吗这是社区最高频的质疑而仓库的设计恰好正面回答了它建树不依赖 LLM 推理排版。pageindex/flash/README.md 写明 Flash 模式用布局统计构建树结构无需 LLM——字体、字号、位置这些排版特征本身就在暗示层级LLM 只参与两件事为节点写摘要、做检索优化合并与展开且都在提交文档时一次性异步完成。检索阶段LLM 面对的不是全文而是节点摘要默认每节点 150 词封顶见 pageindex/config.yaml 与SUMMARY_MAX_WORDS按需才加载命中节点的全文——推理面被压到极小。这正是 pageindex/local_chat.py 里 chat agent 每一轮只做少量工具调用的原因。实测索引耗时同样可预期9 页到 1,098 页的文档Flash 建树从约 13 秒到 4.5 分钟随页数线性增长且一次索引、此后所有问题复用。对单次问答而言这相当于把最重的计算挪到一次性成本里。成本查询成本不随文档变厚而增长财报类文档动辄数百页向量 RAG 每次查询要做的嵌入检索成本虽低但把命中的多块 chunk 连同必要上下文塞进 prompt 的成本会随召回量膨胀。PageIndex 的查询成本则只取决于推理真正到达的节点仓库对比数据是在与原生 PDF 全量输入得到相同答案的前提下原生输入在 52 页文档上贵 2.1 倍、在 420 页文档上贵 16.6 倍805 页时已超出上下文窗口、根本无法回答。更直接的证据来自官方演示的真实 usagepageindex-query-pricing-demo.ipynb 记录了一次跨 5 个年度 10-K 的近五年营收对比查询input 210,613 tokens其中缓存命中 104,152、缓存写入 106,446、output 1,883 tokens、reasoning 443 tokens按gpt-5.6-luna基价输入 $0.2/M、缓存 $0.02/M、输出 $1.2/M估算约$0.031。注意输入大头被 prompt 缓存吃掉了——local_chat.py 的_usage_sums专门统计 cached/cache_write/reasoning 三类 token并按会话生成稳定的prompt_cache_keyclient.py 的_conversation_cache_key让多轮对话与多文档查询命中缓存。索引侧的成本同样透明README 口径约$0.001/页一份千页教材约 1 美元出头、几分钟完成而索引模型用基础档即可——config.yaml 的默认分工是便宜的gpt-5.6-luna建索引更强的gpt-5.6-sol做对话。引用可核验性答案能定位到版块而非看起来对财报场景里答对不等于可信。向量 RAG 的答案没有页码锚点审阅者只能凭感觉采信。PageIndex 的答案是带引用的官方演示中模型输出 NVIDIAs revenue in the prior fiscal year was$130.497 billion.cite docNVIDIA-FY2026-10-K.pdf page37 blockp37_table_6/——引用精确到页 37 的表格版块pageindex-citation.ipynb。SDK 侧 client.py 的_parse_citations同时解析doc…;page…;block…与cite …/两种标签格式去重后返回document/page/block_id三元组citation 演示进一步把block_id解析为 bbox 边界框在整页图上高亮被引用的区域。5 年营收对比的完整表格中每年一个数字都挂着一个p3x_table_y级引用——这是可核验性的终态读者不是相信模型而是翻开第 37 页就能核对。结论与反例哪些查询向量库仍然更优横评的结论不是向量 RAG 该被淘汰而是结构化财报问答里推理式导航全面胜出但它的优势有明确边界。以下四类场景向量库依然有不可替代的价值其一无层级可言的文档。Flash 的toc_source会如实报告结构来源detected、bookmarks、hybrid、pages 或 unreadable。pageindex/flash/README.md 明确当布局无法产出层级时每一页退化成一个 Page N 节点超过 10 页FLAT_TREE_MAX_NODES的平铺树会被本地客户端与 CLI 拒绝扫描件与纯图片 PDF 则直接落到 unreadable。这类没有目录可推理的文档向量 OCR 的分块检索仍是稳妥基线。其二短文档≤20 页。结构导航的开销建树、摘要、推理定位在文档很短时收益递减——STRUCTURE_FIRST_PAGE_THRESHOLD 20也暗示了这一点小文档直接get_page_content()全量取页更划算。此时向量检索的零前置成本反而有优势。其三开放式语义发散问题。年报里哪些地方讨论了利率风险敞口这类问题没有唯一章节落点需要相似度把语义相近但分散的段落全部召回。结构化导航擅长精确定位却天然没有相似度扩散机制——向量检索在召回广度上的价值在这里体现。其四跨语料全局检索。单文档树索引回答的是读这一本书而向量库天然支持十万级文档的全局召回。PageIndex 的应对是文件系统层File System的语料级树索引但 README 标注其为 Cloud 专有能力——纯本地开源部署下跨库检索仍是向量方案的腹地。最后一个反例更微妙树的质量决定检索上限。use_embedded_tocTrue默认信任 PDF 内嵌书签但书签残缺或目录排版混乱时结构可能错位config.yaml里toc_check_page_num: 20这类调参本质是在为文档结构不可靠兜底。当文档结构本身不可信推理式导航就失去了立足点——这正是向量相似度不管结构好坏都能召回的鲁棒性所在。工程结论把四维结果压缩成选型建议面对有清晰层级的专业长文档财报、招股书、监管文件、技术手册且答案必须可追溯时PageIndex 的树导航 块级引用在准确性98.7% vs 约 50%、核验成本与查询成本上全面占优而短平快问答、无结构扫描件、开放式语义扩散与超大规模跨语料检索仍是向量 RAG 的舒适区。成熟的方案不是二选一而是让两种检索在同一套问答 Agent 中共存——这或许才是这场 10 问横评真正的启示。【免费下载链接】PageIndex PageIndex: Document Index for Vectorless, Reasoning-based RAG项目地址: https://gitcode.com/GitHub_Trending/pa/PageIndex创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
