PageIndex：用页面级结构化索引破解RAG向量检索召回不完整难题

1. 从“向量检索”到“结构化导航”PageIndex 要解决的核心痛点如果你最近半年在折腾 RAG 应用大概率会有一种疲惫感向量数据库换了一茬又一茬Embedding 模型从 bge 换到 m3e 再换到各种榜单新秀切块大小从 512 调到 256 再调到 128召回率还是卡在某个尴尬的数字上。用户问一个需要跨三段文档才能回答的问题检索出来的永远是语义最相似但信息最残缺的那一段。这不是你的调参姿势不对而是纯向量检索这套范式本身存在结构性缺陷。PageIndex 这个标题从字面拆开就是“Page”加“Index”直译是“页面索引”。但结合 RAG、LLM、SDK、向量数据库这组关键词来看它显然不是指数据库里那种 B 树索引而是指向一种面向文档页面的结构化索引机制。我个人的理解是它试图在传统“切块-向量化-相似度召回”这条流水线之外补上一层“页面级导航”的能力让 LLM 在检索时不只是拿到一堆语义相近的碎片而是能像人翻书一样先定位到相关页面再在页面内部做精细阅读。为什么这件事重要因为 RAG 的瓶颈从来不在“找相似”而在“找完整”。向量检索的本质是语义近邻搜索它擅长回答“哪段文字和问题最像”但它不擅长回答“回答这个问题需要哪几段文字组合起来”。一个典型的翻车场景是用户问“这个项目的部署流程分几步”向量检索可能只召回“第三步配置环境变量”这一段因为它的语义和“部署流程”最接近但第一步和第二步被漏掉了。LLM 拿到残缺上下文要么胡编要么说“根据提供的信息无法回答”。PageIndex 要做的就是给文档建立一层页面级的结构索引让检索过程从“扁平相似度匹配”升级为“先导航后精读”。这有点像你在图书馆找书向量检索是直接冲到书架前凭直觉抽一本最像的而 PageIndex 是先查目录卡确定这本书在哪个区、哪一排、哪一层然后再去精确取书。两者的效率和信息完整度完全不在一个量级。注意PageIndex 目前并不是一个已经标准化的通用协议不同团队对它的实现方式差异很大。有的把它做成文档预处理阶段的页面摘要索引有的把它做成检索时的两阶段路由层。本文讨论的是它作为一种设计思路的通用价值以及在实际 RAG 项目中怎么落地。适合读这篇内容的人正在做 RAG 应用但召回质量卡脖子的工程师、需要给 LLM 接私有知识库的产品团队、以及想理解“为什么向量数据库不是万能药”的技术决策者。下面我会从原理、实现、踩坑、调优四个层面把 PageIndex 这套思路拆开讲透。2. PageIndex 的底层逻辑为什么“先定位页面再精读”比“直接向量召回”更靠谱2.1 向量检索的“语义漂移”问题到底出在哪要理解 PageIndex 的价值得先承认向量检索的一个根本局限Embedding 是对文本语义的压缩而压缩必然有损。一段 500 字的文档切块经过 Embedding 模型编码后变成一个 768 维或 1024 维的向量这个向量保留了“这段话大概在讲什么”但丢掉了“这段话在文档中的位置”“它和前后段的关系”“它属于哪个章节”这些结构信息。当用户 query 进来同样被编码成向量然后在向量空间里找最近邻。问题在于query 的语义重心和文档块的语义重心往往不在同一个维度上。比如 query 是“PageIndex 怎么处理跨页表格”它的语义重心在“跨页表格处理”而文档中真正包含答案的块可能标题是“表格解析模块”内容里讲的是“对于跨页表格采用合并单元格策略”这个块的语义重心在“表格解析”。两者向量距离不算近但信息是匹配的。这就是所谓的语义漂移检索系统找的是“语义最像的”而不是“信息最全的”。PageIndex 的思路是在向量检索之前加一层“页面级粗筛”用页面标题、页面摘要、页面关键词这些结构化信号先圈定一个候选页面集合再在这个集合内部做精细检索。粗筛阶段不依赖稠密向量而是依赖页面级的稀疏特征比如 BM25、关键词命中、标题匹配。这样做的代价是召回范围可能变大但换来的是信息完整度的提升。2.2 页面索引的三种常见构建方式在实际项目中PageIndex 的构建方式我见过三种主流做法各有适用场景。第一种是标题层级索引。把文档按 H1/H2/H3 标题拆成树形结构每个节点对应一个页面或一个章节节点上挂载该章节的摘要和关键词。检索时先匹配标题树定位到最相关的章节再在该章节内部做向量检索。这种方式适合结构清晰的文档比如技术手册、产品文档、学术论文。缺点是如果文档本身没有规范标题树就建不起来。第二种是滑动窗口页面摘要。不依赖标题而是把文档按固定页数比如每 3 页切成一个逻辑页面对每个逻辑页面生成一段摘要摘要和页面内容一起存入索引。检索时先用 query 匹配摘要命中后再进入页面内部检索。这种方式对无结构文档友好但摘要生成需要额外调用 LLM成本和延迟都会上升。第三种是混合索引也是我个人最推荐的。它结合了前两种先用标题树做一级导航标题缺失的地方用滑动窗口补位每个页面节点同时存储摘要、关键词和原始文本块。检索时走“标题匹配 → 摘要匹配 → 块级向量检索”三级漏斗。这种方式的鲁棒性最好但实现复杂度也最高。索引方式适用文档类型构建成本检索延迟召回完整度标题层级索引结构规范文档低低中滑动窗口摘要无结构长文本高需 LLM中中高混合索引通用中高中高2.3 PageIndex 和传统向量数据库的关系不是替代是补位这里要澄清一个常见误解PageIndex 不是要干掉向量数据库。向量数据库在块级精细检索上依然是最高效的工具PageIndex 是在它前面加了一层路由层。你可以把整个检索链路想象成快递分拣PageIndex 是“按城市分拣”向量数据库是“按街道分拣”。没有城市分拣直接按街道分拣遇到同名街道就会分错有了城市分拣街道分拣的准确率会大幅提升。在实际架构里PageIndex 通常以两种形态存在。一种是离线预处理形态在文档入库阶段先跑一遍页面索引构建把页面摘要、标题树、关键词这些元数据存到关系型数据库或搜索引擎里向量数据库只存块级向量。检索时先查元数据库拿到候选页面 ID 列表再用这些 ID 去向量数据库里做过滤检索。另一种是在线路由形态不预先建索引而是在 query 进来时先用一个轻量 LLM 或规则引擎判断 query 可能涉及哪些页面再动态路由。前者适合文档更新频率低的场景后者适合文档频繁变动的场景。提示如果你的文档量在 1000 页以下其实可以跳过 PageIndex直接用向量检索加 rerank 也能凑合。PageIndex 的收益在文档量上万页、且文档结构复杂时才会明显体现。不要为了架构而架构。3. 动手实现一个最小可用的 PageIndex 层3.1 环境准备与依赖选型先说一下我的技术选型思路。做 PageIndex 层核心需要三样东西文档解析器、摘要生成器、索引存储。文档解析我用unstructured或者pymupdf前者对多格式支持好后者对 PDF 的表格和版面还原更准。摘要生成用本地 LLM 就行ollama跑一个 7B 或 8B 的模型足够没必要上 GPT-4因为页面摘要不需要太高的推理能力只需要把页面内容压缩成两三句话。索引存储我习惯用SQLite加FAISS的组合SQLite 存页面元数据FAISS 存块级向量轻量且不依赖外部服务。pip install pymupdf unstructured ollama faiss-cpu sqlite3如果你用的是langchain4j那套 Java 生态思路是一样的只是把 Python 库换成对应的 Java SDK。langchain4j的Easy RAG模块其实已经内置了简单的文档路由但它的路由粒度是文档级不是页面级所以还是需要自己补一层。3.2 页面切分与摘要生成的具体步骤第一步是页面切分。我的做法是先用pymupdf把 PDF 按物理页拆开然后对每一页做一次“逻辑页面合并”如果连续两页的标题相同就合并成一个逻辑页面如果某页没有标题就往前找最近的标题作为它的归属。这样得到的逻辑页面既保留了物理页的边界又不会把同一个章节切得太碎。import fitz def split_by_logical_page(pdf_path): doc fitz.open(pdf_path) logical_pages [] current_title None current_content [] for page_num, page in enumerate(doc): text page.get_text() # 简单启发式取第一行作为标题候选 first_line text.strip().split(\n)[0] if text.strip() else if first_line and len(first_line) 50: if current_title and current_content: logical_pages.append({ title: current_title, content: \n.join(current_content), start_page: page_num - len(current_content) }) current_title first_line current_content [text] else: current_content.append(text) if current_title and current_content: logical_pages.append({ title: current_title, content: \n.join(current_content), start_page: page_num - len(current_content) 1 }) return logical_pages第二步是摘要生成。对每个逻辑页面调本地 LLM 生成一段 100 字以内的摘要同时抽取 5 到 8 个关键词。摘要的 prompt 我一般这样写“用一句话概括以下内容的核心主题再用一句话说明它解决了什么问题。不要超过 80 字。”关键词抽取用简单的 TF-IDF 加规则过滤就行没必要上 LLM因为关键词只需要覆盖页面主要实体不需要语义理解。import ollama def generate_summary(page_content): prompt f用一句话概括以下内容的核心主题再用一句话说明它解决了什么问题。不要超过80字。 内容 {page_content[:2000]} 摘要 response ollama.chat(modelqwen2.5:7b, messages[ {role: user, content: prompt} ]) return response[message][content]第三步是索引存储。建两张表pages表存页面 ID、标题、摘要、关键词、起始页chunks表存块 ID、页面 ID、块文本、块向量。检索时先查pages表做粗筛拿到候选页面 ID 后再用WHERE page_id IN (...)去chunks表做向量检索。3.3 检索链路的两阶段路由实现检索阶段是整个 PageIndex 的核心。我的实现分两步页面粗筛和块级精排。页面粗筛用 BM25 加标题匹配的混合打分。BM25 负责关键词层面的召回标题匹配负责结构层面的召回。具体做法是把 query 分词后对每个页面的标题和关键词做 BM25 打分同时计算 query 和页面标题的编辑距离相似度两个分数加权求和取 Top 5 页面作为候选。from rank_bm25 import BM25Okapi import jieba def coarse_retrieve(query, pages, top_k5): corpus [p[title] .join(p[keywords]) for p in pages] tokenized_corpus [list(jieba.cut(doc)) for doc in corpus] bm25 BM25Okapi(tokenized_corpus) tokenized_query list(jieba.cut(query)) scores bm25.get_scores(tokenized_query) # 标题相似度加权 for i, page in enumerate(pages): title_sim compute_edit_similarity(query, page[title]) scores[i] scores[i] * 0.7 title_sim * 0.3 top_indices sorted(range(len(scores)), keylambda i: scores[i], reverseTrue)[:top_k] return [pages[i] for i in top_indices]块级精排就是在候选页面内部做向量检索。把候选页面的所有块向量拿出来和 query 向量算余弦相似度取 Top 3 到 Top 5 块作为最终上下文。这里有个细节如果候选页面数量少于 3 个我会把粗筛的 top_k 调大或者直接退化成全量向量检索避免因为粗筛太激进导致漏召回。注意粗筛的 top_k 不要设太小。我一开始设成 3结果发现有些问题的答案分散在 4 个页面里粗筛只召回 3 个页面就漏了。后来改成 5 到 8 之间召回完整度明显提升延迟只增加了不到 200 毫秒。4. 实测中踩过的坑与排查链路4.1 页面摘要质量不稳定导致的“导航失灵”第一个坑是摘要生成的质量问题。我用 7B 模型生成摘要时发现有些页面的摘要写得非常泛比如“本章介绍了系统的相关内容”这种摘要对粗筛毫无帮助因为 query 匹配不到任何有效信息。排查下来发现原因是 prompt 里没有给模型足够的约束模型倾向于生成“安全但无用”的概括。修复方案是在 prompt 里加两个约束一是要求摘要必须包含页面中出现的具体实体名称二是要求摘要必须包含一个动词短语说明该页面的功能。改完 prompt 后摘要质量明显提升粗筛命中率从 62% 涨到 81%。这个数字是我在 200 条测试 query 上跑出来的虽然样本不大但趋势很明显。4.2 标题树断裂时的降级策略第二个坑是标题树断裂。有些 PDF 的标题格式不统一有的用加粗有的用字号有的干脆没有标题。我的切分逻辑依赖“第一行短文本作为标题”遇到没有标题的页面就会把整页内容归到上一个标题下导致逻辑页面过大摘要失去区分度。排查这个问题的过程比较曲折。我一开始以为是摘要模型的问题换了更大的模型效果没变。后来把逻辑页面的内容打印出来看才发现是切分逻辑把三个章节合并成了一个页面。修复方案是加一个降级策略如果连续 5 页都没有检测到新标题就强制按物理页切分并对每个物理页单独生成摘要。这样虽然会增加索引数量但保证了每个页面节点的区分度。4.3 粗筛与精排的分数尺度不一致第三个坑比较隐蔽。粗筛用的是 BM25 分数精排用的是余弦相似度两个分数的尺度完全不一样。我一开始直接把两个分数相加做最终排序结果发现 BM25 分数普遍在 10 到 30 之间余弦相似度在 0.6 到 0.9 之间相加之后 BM25 完全主导了排序精排形同虚设。修复方案是做分数归一化。对粗筛分数做 min-max 归一化对精排分数也做 min-max 归一化然后按 0.4 和 0.6 的权重加权。这个权重是我试出来的粗筛权重低一些因为粗筛只是路由精排才是决定最终上下文质量的关键。如果你用的是 rerank 模型那精排分数本身就已经是归一化的相关性分数可以直接用。问题现象根因修复方案效果摘要泛化无信息prompt 约束不足强制包含实体和动词短语粗筛命中率 62%→81%逻辑页面过大标题检测失败连续 5 页无标题则按物理页切分页面区分度提升排序被粗筛主导分数尺度不一致min-max 归一化后加权精排生效5. PageIndex 的调优经验与边界条件5.1 什么场景下 PageIndex 收益最大根据我的实测PageIndex 在三种场景下收益最明显。第一种是长文档问答文档超过 50 页问题需要跨章节信息组合。第二种是结构化文档检索比如技术手册、法律合同、医疗指南这些文档本身有清晰的章节结构PageIndex 能充分利用。第三种是多文档知识库文档之间主题相近但内容互补PageIndex 能先按文档路由再按页面路由避免跨文档的语义混淆。反过来如果你的文档都是短文本比如每条记录只有几百字那 PageIndex 的收益就很有限因为页面级路由的粒度太粗直接向量检索就够了。另外如果 query 都是简单的实体查询比如“XX 的客服电话是多少”那向量检索加关键词过滤就能解决不需要上 PageIndex。5.2 页面粒度的选择粗一点还是细一点页面粒度是 PageIndex 调优的核心参数。粒度太粗一个页面包含太多主题摘要失去区分度粒度太细页面数量爆炸粗筛的候选集变大延迟上升。我的经验值是每个逻辑页面控制在 500 到 1500 字之间。低于 500 字页面信息量不足摘要写不出东西高于 1500 字页面内部主题太杂摘要只能泛泛而谈。这个范围不是拍脑袋定的。我做过一组对比实验把同一份 300 页的技术文档分别按 300 字、800 字、1500 字、3000 字切分然后跑 100 条测试 query看最终答案的完整度。800 字和 1500 字的表现最好300 字因为页面太碎导致粗筛召回不稳定3000 字因为页面太大导致摘要区分度下降。当然这个数字和文档类型有关技术文档偏紧凑法律文档可能要到 2000 字才合适。5.3 和 rerank 模型的配合方式PageIndex 和 rerank 不是互斥的而是互补的。我的推荐链路是PageIndex 粗筛 → 块级向量检索 → rerank 精排。粗筛负责把候选范围从全量文档缩小到 5 到 8 个页面向量检索负责在每个页面内部召回 10 到 20 个块rerank 负责从这些块里挑出最相关的 3 到 5 个。这样 rerank 的输入量可控延迟不会爆炸同时召回质量有保障。如果你没有 rerank 模型也可以用 LLM 做一次“上下文压缩”把候选块喂给 LLM让它挑出真正相关的部分。但这种方式延迟高适合离线场景或者对延迟不敏感的应用。提示PageIndex 的粗筛阶段不要用 LLM 做路由除非你的文档量很小。LLM 路由的延迟在秒级而 BM25 加标题匹配的延迟在毫秒级。粗筛阶段追求的是高召回不是高精度用轻量方法就够了。6. 从 PageIndex 延伸出去RAG 检索范式的下一步PageIndex 本质上是在解决 RAG 的一个根本矛盾检索的粒度是固定的但问题的信息需求是动态的。向量检索把文档切成固定大小的块但有些问题只需要一个块就能回答有些问题需要跨五个块。PageIndex 通过页面级路由让检索粒度变得更有弹性但它依然没有完全解决“动态粒度”的问题。我最近在关注的一个方向是查询驱动的动态切块不预先切块而是在 query 进来时根据 query 的语义结构动态决定切块边界。比如 query 问的是“对比 A 和 B 两个方案的优缺点”系统就动态切出 A 方案所在段落和 B 方案所在段落而不是按固定窗口切。这个方向目前还在实验阶段但思路很有意思它把切块从预处理阶段挪到了检索阶段对系统的实时计算能力要求更高。另一个方向是多模态 PageIndex。现在的 PageIndex 主要处理文本页面但很多文档包含表格、图表、流程图。这些非文本内容在向量检索里往往被忽略但它们承载的信息密度很高。我试过用 OCR 加表格解析把图表转成文本再索引效果一般因为图表的结构信息在转文本时丢失了。未来如果有多模态 Embedding 模型能直接编码图表结构PageIndex 的覆盖面会大很多。回到当下如果你正在做 RAG 项目我的建议是先把基础向量检索跑通再考虑加 PageIndex。不要一上来就上复杂架构因为很多问题其实用 rerank 加查询改写就能解决。PageIndex 是当你的文档量上万页、结构复杂、召回质量卡在瓶颈时才值得投入的优化手段。它不是一个银弹而是一把在特定场景下很好用的手术刀。我在实际项目里落地 PageIndex 时最大的体会是页面摘要的质量决定了整个系统的上限。摘要写得好粗筛准后面精排就轻松摘要写得烂粗筛漏后面怎么调都救不回来。所以如果你决定上 PageIndex先把摘要生成的 prompt 调到位用几十条真实 query 做验证确认粗筛命中率稳定在 80% 以上再往下做。这个前置工作看起来不起眼但它决定了你后面是事半功倍还是事倍功半。