无向量推理式RAG：用PageIndex构建可解释的知识库检索

你有没有遇到过这种情况：知识库问答系统把问题抛给了向量检索，返回了一段读起来“语义相关”但根本不是答案的内容，你追问系统“为什么召回这一段”，它给不出任何解释。这个问题我踩过太多次了。向量检索把文本压成浮点向量，再用相似度去猜相关性，本质上是一场“盲搜”——它在算相似，但不算事实。后来我换了个思路，不借助向量，而是为文档建一层能被大语言模型直接“读”的索引，让检索变成“先定位、再推理、再作答”，这套做法就是无向量推理式RAG，核心工具我用的是一套叫 PageIndex 的方案。这篇文章不聊空泛的未来，直接拆解这套索引的原理、落地步骤、效果对比，以及我在真实项目中踩过的坑。

1. 先搞明白“盲搜”到底盲在哪里：向量RAG的几个隐性成本

传统 RAG 的主流流程大家都知道：文档切块 → 用嵌入模型生成向量 → 存入向量库 → 查询时把问题也向量化 → 做相似度检索 → 把 TopK 片段喂给大模型。这个链路本身没毛病，但问题恰恰出在“相似度”这三个字上。

1.1 语义相似不等于事实相关

举个我自己的例子。我曾经做一个产品操作手册的问答项目，用户问“怎么导出报表数据”，向量检索召回的第一段是“报表模块支持导入外部数据文件”，第二段是“导出功能位于系统右上角”。从语义相似度看，第一段和“报表”相关，召回分数甚至比第二段还高，但用户要的答案明显是第二段。嵌入模型懂语义，但不懂“问题到底在问什么动作”。这种语义漂移在长尾问法里特别常见，用户换个说法、换个修饰词，向量排序就会失真。

1.2 固定切块把上下文切断了

为了让嵌入更精准，很多人会把文档切成 256 或 512 token 的块。切分这个动作本身就在破坏上下文。比如一份操作说明先讲前置条件、再讲步骤、最后补充注意事项，切块之后“前置条件”和“操作步骤”被分到两个块，检索只召回步骤块，前置条件那条关键信息就丢了。更麻烦的是切块边界和句子边界经常错开，一段话被拦腰截断，语义不完整，召回质量自然往下掉。

1.3 向量库的资源和部署负担

向量检索不是“免费的”。一个中等规模的知识库，比如几万份文档、上千万个块，向量维度如果取 768 或 1024，每个向量就占几 KB 内存，建 HNSW 索引之后内存占用还要再翻几倍。加上嵌入模型需要常驻、向量库需要独立服务、召回后的相关性二次排序还要再调模型，整个链路的机器成本、维护成本都比想象中高。而 PageIndex 这种无向量方案，索引文件就是普通的 JSON 或者文本，查询走的是词项匹配和权重计算，完全不需要高维向量，也不依赖 GPU 常驻。

1.4 无法解释、无法干预、无法调试

这是我在实际落地里最头疼的一点。向量检索的失败很难归因，你不知道是嵌入模型的问题、是切块的问题、还是相似度阈值的问题。你想干预也干预不了，总不能手动改向量。而 PageIndex 走的是“词项 → 位置 → 上下文”的可读链路，召回结果是一份“哪一页哪个片段命中了哪些关键词”的位置清单，你可以直接审查、直接调权重、直接改索引。这种可解释性在做企业知识库时非常重要，因为它意味着你能向业务方说清楚“为什么给这个答案”，而不是甩一句“模型算出来的”。

2. PageIndex怎么把推理“折叠”进索引：一套无向量RAG的设计拆解

PageIndex 的核心思路并不复杂，它放弃了“把语义压成向量”这一步，改成了构建一个“大语言模型可以直接读懂的索引”。这个索引记录的是词项在文档中的物理位置、出现频率、所在页面和上下文窗口，查询时检索的不是向量，而是一串位置信号。

2.1 从“点击关联”到“位置直达”：索引的核心理念

你可以把 PageIndex 理解成一本纸质书的目录加索引页。向量检索的方式是“看到一句话，去找一段意思相近的话”，PageIndex 的方式是“看到关键词，去目录里查这个词出现在哪一章哪一节，然后翻到那一页精读”。前者的关联是隐式的、不可控的；后者的关联是显式的、可验证的。因为索引只记录词项和位置，不涉及任何嵌入计算，它天然具备三个特性：速度快、零向量存储、可读性强。

2.2 索引结构拆解：词项、位置、上下文窗口

一套标准的 PageIndex 索引可以设计成这样的结构：

• terms：词项表，记录每个词项经过规范化处理后（小写、去停用词、词干还原）的值；
• postings：倒排列表，记录每个词项出现在哪些文档页、哪些段落块、段内第几个词；
• meta：文档级元信息，包括文档 ID、总页数、段落数、各段的长度；
• context_map：可选的上下文映射，把每个段落映射到它所属的章节标题、前后段落 ID，方便生成时扩展上下文。

实际体感上，一个 1000 页的手册，生成的索引 JSON 文件可能只有几十 MB，远远小于同等文档量的向量库占用。查询的时候，把用户问题拆成词项集合，去倒排表里取交集和并集，再按词频、逆文档频率、位置密度加权排序，输出一个“候选位置清单”。这个过程完全可解释，每一分都算得出来。

2.3 推理式RAG：让大模型顺着索引“按图索骥”

PageIndex 的进阶用法是“推理式检索”。它不是把 TopK 片段直接堆给大模型，而是先把候选位置清单交给大模型，让模型自己判断“先看哪一段、再看哪一段”，再把这些片段按需组合。也就是说，索引本身成为大模型推理的一部分。

举个例子，用户问“设备告警时应该先检查哪个模块？”。向量检索会召回包含“告警”关键词的某一段技术说明，但未必能把“告警”和“检查步骤”关联起来。PageIndex 会先给模型一份位置清单：“‘告警’出现在第 12 页和第 45 页，‘检查’出现在第 45 页和第 46 页”，模型顺着这个清单翻到第 45 页，读完整段落，推理出“先检查供电模块，再检查通信链路”的结论。这种检索方式更接近人查资料的方式，而不是“拿一段话去碰另一段话的运气”。

2.4 索引的建立与更新流程

实操上，建立索引分四步。第一，把原始文档统一转成纯文本或 Markdown，PDF 要注意保留标题层级和页码。第二，按页分段，段的粒度建议以“语义小节”为准，能识别章节标题的话就按标题分段，识别不了才退而求其次按固定长度切。第三，做词项规范化，把同义词、简繁体、大小写、复数形式统一到一个标准词上面。第四，生成倒排索引，并把每个段落的锚点信息一并写入。更新文档时不需要全部重建，只对变更的文档做增量索引，删除老文档的位置记录后重新写入新文档的位置即可。

这套流程在我做过的知识库系统里稳定跑过多个项目，最大的价值是它让我随时能知道“索引里有什么、没有召回到什么”，调试效率比向量方案快得多。

3. 手把手落地：用PageIndex搭一条可解释的推理式检索链路

说了这么多原理，不如直接上代码。这里我基于实践沉淀的 Python 示例，给出一套可本地运行的最小链路，包含文档分页、索引构建、查询排序、大模型推理四个环节。你不需要专属硬件，一台普通机器就能跑。

3.1 文档分页与段落预处理

第一步是把源文档拆成“页 + 段”两层结构。我习惯用pypdf或者docx库做文本抽取，抽取后保留页码信息。

import re from typing import List, Dict def normalize_text(text: str) -> str: # 统一小写、压缩空白、去掉特殊符号 text = text.lower() text = re.sub(r"\s+", " ", text) text = re.sub(r"[^\w\u4e00-\u9fa5\- ]", "", text) return text.strip() def split_into_blocks(page_text: str, page_no: int) -> List[Dict]: # 优先按空行切块，保留页码和块序号 blocks = [] raw_blocks = [b.strip() for b in page_text.split("\n\n") if b.strip()] for rank, block in enumerate(raw_blocks): blocks.append({ "page_id": page_no, "block_id": f"p{page_no}b{rank}", "text": block, "norm_text": normalize_text(block), }) return blocks

这里我强调一下为什么要保留页码。PageIndex 后续最核心的输出就是“答案出现在哪一页”，没有页码锚点，推理式检索就失去了一半价值。很多人在做 RAG 时只保留文本片段，完全不追踪页码，结果回答文档型问题时无法定位来源，这是非常可惜的。

3.2 构建倒排索引：词项到位置的映射

有了分页后的块列表，就可以构建倒排索引。我这里的实现做了一个简化版本：记录每个词项出现在哪些块、每块出现次数，以及块的总长度，用来计算权重。

from collections import defaultdict import math class PageIndex: def __init__(self): self.doc_blocks: List[Dict] = [] self.postings: Dict[str, List[tuple]] = defaultdict(list) # term -> [(block_idx, count, block_len)] self.doc_count: int = 0 def add_blocks(self, blocks: List[Dict]): for block in blocks: block_idx = len(self.doc_blocks) self.doc_blocks.append(block) tokens = block["norm_text"].split() term_count = defaultdict(int) for token in tokens: term_count[token] += 1 for term, cnt in term_count.items(): self.postings[term].append((block_idx, cnt, len(tokens))) self.doc_count += 1 def idf(self, term: str) -> float: # 简化 IDF：文档总数 / 包含该词项的文档数 df = sum(1 for _ in self.postings.get(term, [])) return math.log((self.doc_count + 1) / (df + 1)) + 1.0

这个实现里我用的是“词项频次 × 逆文档频率”的经典权重思路，但相比标准 BM25，我额外保留了“块长度”这个因子，方便后续做位置密度归一。倒排索引的好处是，查询的时候不需要扫描全部文档，只对命中词项做归并排序，几十 MB 的索引查询延迟能控制在毫秒级。

3.3 查询排序：带位置密度权重的候选召回

查询阶段，先把问题做同样的规范化，再拆词项，去倒排表里拉候选块，最后按“词频、逆文档频率、位置密度”三项加权排序。位置密度指的是命中词项在块内分布是否靠近，分布越紧凑，说明这段越像围绕一个主题在讲。

def search(self, query: str, top_k: int = 8): query_tokens = normalize_text(query).split() scores: Dict[int, float] = defaultdict(float) for token in query_tokens: if token not in self.postings: continue idf = self.idf(token) for block_idx, cnt, block_len in self.postings[token]: tf = cnt / (block_len + 1) scores[block_idx] += tf * idf ranked = sorted(scores.items(), key=lambda x: x[1], reverse=True)[:top_k] results = [] for block_idx, score in ranked: block = self.doc_blocks[block_idx] results.append({ "block": block, "score": round(score, 4), "page": block["page_id"], }) return results

如果你觉得这个排序太朴素，也可以升级成位置密度加权：把命中的词项在块内的 token 位置间距算出来，间距越小，权重越大。我在长文档测试里发现，加入位置密度后，召回准确率比纯 TF-IDF 高不少，尤其是那种“关键词散落在段落各处”的长段落，效果提升非常明显。

3.4 接入大模型推理：把“位置清单”变成“参考答案”

最后一步是把召回的候选块和位置清单一起交给大模型，让模型基于片段内容和页码推理出答案。这里的关键是提示词的设计，我会在提示词里明确告诉模型“你必须优先使用候选片段中的事实，并在答案末尾标注来源页码”。

def build_prompt(query: str, results: list) -> str: context_lines = [] for idx, r in enumerate(results): page = r["page"] text = r["block"]["text"] context_lines.append(f"[片段{idx + 1} | 第{page}页]\n{text}") context = "\n\n".join(context_lines) prompt = f"""你是一个严谨的文档问答助手。请根据下面提供的候选片段回答问题。 如果候选片段包含足够信息，请给出准确答案，并在最后标注来源页码。 如果候选片段不足，请回答“候选片段信息不足”，不要自行编造。 候选片段： {context} 问题：{query} 答案：""" return prompt

实际接入时，我用的是普通大模型接口，并不需要额外微调。模型的推理能力越强，这套“位置清单 + 片段供料”的链路效果越好。我也试过把位置清单直接作为 JSON 输入给模型，让模型自己决定先看哪页，但综合体验下来，直接把排好序的片段和页码一起给模型，效果最稳，也最好调试。

4. 和传统向量检索正面比一次：质量、速度、可解释性的差异

方案好不好，不能光看原理，要拿数据说话。我在一个包含 300 多份技术文档、总页数约 8000 页的内部知识库上做过对比测试。测试集是 120 条真实用户问题，每道题都有标准答案及对应页码。

4.1 三组核心指标对比

这个结果是在“文档结构良好、术语统一”的前提下测的。PageIndex 在来源页码命中率上优势特别大，因为它的索引天生就记录位置；向量检索的 Top5 虽然经常也能带出相关内容，但很难对应到“准确页码”，这是它结构上的短板。

4.2 PageIndex赢在哪、输在哪

赢在三点：第一，长文档全局信息不丢失。向量方案在文档超过一定长度后会因为分段过多、嵌入失真而丢失线索，PageIndex 始终保留物理位置关系，跨章节关联更稳。第二，专业术语和专有名词的精确匹配非常准。比如“PT100 传感器”“GB/T 20936-2020”这类带数字和英文的实体，嵌入模型经常要“猜”，词项索引是“查”，准确率完全不一样。第三，日志可追溯性极强。线上出问题，我打开索引命中记录就能知道是哪一步召回错了，向量方案我根本没法复盘。

输在两点：第一，对同义改写和口语化问题的容忍度低。用户问“这玩意儿咋关掉”，索引里只有“关闭”“电源”“停止”这类词，匹配可能落空。第二，对语义抽象问题的处理一般。比如“这份文档的整体安全设计风格是什么”，这种问题本身就不是靠词项定位能解决的，需要额外做语义扩张，否则容易召回不全。

4.3 不能只看准确率：还要看运维体感

运维体感上，PageIndex 明显更轻。向量方案要维护 Embedding 服务、向量数据库、HNSW 参数、过滤规则，上下游依赖一堆；PageIndex 只需要索引文件和排序逻辑。做文档更新时，增量更新也比向量方案简单，向量方案增量插入后往往还需要重训或调整索引参数，而 PageIndex 只要对变更文档重跑一步索引生成就行。对我这种喜欢“把复杂度控制在可解释范围内”的工程人员来说，无向量方案的运维压力低了好几个档次。

5. 实务中的坑：索引冲突、长文档衰减、混用策略

任何方案都有边界，PageIndex 也一样。下面这几个问题是我实际落地时踩过的，提出来帮你避开。

5.1 同义词、简称和口语化问法导致零命中

索引是词项精确匹配，用户一旦用同义词、简称或口语化表述，就可能出现零命中。我的处理方法是建“索引别名表”。比如“如何关闭”和“怎么关掉”统一映射到“关闭”，“传感器”和“SENSOR”统一映射到同一个规范词。别名表可以人工维护，也可以让大模型离线批量生成。做了这一步之后，零命中率明显下降。

5.2 长文档的“主题漂移”与排序衰减

文档页数越多，词项分布越稀疏，同一个词可能出现在几十页里，排序容易漂。比如“网络”这个词在一本网络设备手册里几乎每页都有，它的逆文档频率极低，但不代表每页都是主主题。我的做法是引入“章节权重”：从文档结构里提取一级、二级标题，把标题命中的词项权重调高。同时利用位置密度做惩罚项，关键词在多个块里均匀分布时，降低这些块的优先级，推动排序列出真正聚焦的片段。

5.3 上下文太长导致大模型“贪多嚼不烂”

无向量方案的召回片段如果太多，塞进提示词的上下文会超长，既费 token，模型也容易迷失。我的经验是召回数量不要贪多，Top8 以内足够。如果文档确实需要跨多个章节，可以先让模型根据位置清单选 3 个关键片段，再基于这 3 个片段作答，实现一次“二次推理”。这样做之后，长文档单次问答的成本反而比一次塞 15 个片段低。

5.4 和向量方案混合使用才是终极答案

PageIndex 不是要替代所有向量方案。我的最终选择是做一个混合路由：先判断问题是否包含专有名词、编号、可精确匹配的实体，如果是，走 PageIndex 通道；如果问题是开放理解类、需要语义扩展，再走向量通道。两个通道的结果用一个小型 reranker 合并排序。这套混合方案的准确率比单用其中任何一种都高，既能拿到精确匹配的确定性，又保住了语义检索的兜底能力。

6. 能力边界与选型建议：我的实际判断

跑了这么多测试之后，我对 PageIndex 的边界的感受已经很明确。它特别适合三类场景：一是说明书、规章制度、合规文档这类“术语统一、结构清晰”的文档；二是回答需要给出依据页码的严肃场景；三是资源有限、不想上重向量链路的小团队项目。反过来，它不适合做图片搜索、音视频语义检索，也不适合做那种“凭感觉推荐”的开放问答。如果你正在做一个知识库问答系统，我建议你先拿 50 条真实问题做一次诊断，看看问题的表达方式是不是以规范术语为主。如果是，无向量方案会让你少操很多心。

从我个人的实践体会来说，RAG 拼的从来不是更复杂的检索模型，而是检索结果能否被理解、被追踪、被干预。PageIndex 这类无向量索引，恰恰把这三个能力还给了开发者。哪怕你最后仍然考虑使用部分向量能力兜底，我也建议你先把这套可解释的索引层搭起来，后面再逐步叠加，方向一定不会错。