实际上，在很长一段时间里，RAG的标准流程几乎被固化成了固定模板：先对文档进行切片处理，再生成向量嵌入，随后将用户问题也向量化，接着全局计算余弦相似度，最后截取Top-K片段投喂给大模型。无论是入门教程还是主流开源框架，几乎都沿用这一模式。我们也因此默认了检索就该如此，甚至把“提升向量召回精度”视为优化检索环节的唯一方向。

然而，一套逆向的RAG工程设计思路，直接颠覆了这一固有认知。完成文档解析之后，RAG的检索本质上并非相似度搜索，而是类SQL的结构化布尔筛选。这种落地方案的架构被称为Series RAG（序列分层RAG，这是一个原生学术定义的术语，并非随意杜撰），这也是它与传统朴素RAG之间最根本的分水岭。

先给出核心结论：传统RAG将检索定义为相似度匹配搜索；而更高效、可落地、可审计的工程级RAG，则将检索定义为多表关联的结构化筛选。

在这一新范式下，文档经过解析后会被沉淀为两张结构化数据表：line_df（全文细粒度文本行数据表）和toc_df（文档章节目录数据表）。整个检索流程不再进行全局向量相似度打分，而是针对这两张数据表执行类SQL的条件匹配。简单概括底层逻辑：用户提问具备明确的语义维度，解析后的文档具备结构化字段维度，检索的本质，就是问题维度与文档结构化维度之间的关联匹配（Join）。

很多人可能会疑惑：筛选和搜索听起来差别不大，何必刻意区分？其实两者完全不同。底层的运行机制、工程落地的缺陷、结果的可控性，差异巨大。而这正是传统RAG中幻觉、无效召回、结果不可复现等顽疾的根源所在。

我们不妨从底层逻辑出发，将这两个范式掰开揉碎进行对比：

传统RAG：相似度搜索（Search）

其核心是连续值打分排序。依靠余弦相似度、BM25等算法，对全局所有文档分块进行相似度的量化打分，然后按得分高低排序，强制截断，最终输出Top-K高得分片段。

这个流程天生带有两个硬伤。第一，它一定会返回结果。即使知识库中根本没有用户问题的答案，模型也会强行选出一批相似度最高的文本顶上去——这正是RAG知识幻觉的主要诱因。第二，结果完全不可审计、不可复现。向量排序依赖嵌入模型的隐特征维度，你根本无法直观判断到底是哪些语义特征决定了排序结果。过段时间更换模型或重复执行同一任务，排序结果很可能会飘移，没人能说清问题出在哪里。

新型工程RAG：布尔筛选（Filter）

其核心是离散布尔条件匹配。通过显性、可自定义的硬性条件来筛选数据，例如「文本行包含关键词」「章节目录标题匹配语义范围」等布尔判定规则。系统只会精准保留完全符合条件的数据行，没有匹配的内容则直接返回空结果。

这套方案完美解决了传统检索的致命短板。整个筛选逻辑由显性代码定义，全程透明、可核查、可永久复现。无论是半个月还是半年后，同样的筛选规则与知识库，必定输出完全一致的召回结果。对于企业级落地和合规审计场景而言，这一特性比微弱的召回精度提升重要得多。

用一个真实业务场景直观对比两种检索流程，差距会更清晰：

朴素传统RAG执行流程：

第一步：将用户问题做向量嵌入；第二步：遍历知识库中300多篇论文的文本分块，逐一计算余弦相似度得分；第三步：完全忽略文本的语义层级和章节逻辑，粗暴返回得分最高的5个分块。

整个过程依赖向量模型的黑盒判断，极易召回一些无关的高相似度片段。例如论文其他章节中提到的同类编码算法，上下文层级完全错乱，还容易混入噪声文本。

Series RAG（序列分层RAG）筛选式检索执行流程：

第一步：检索细粒度行数据表 line_df，用布尔筛选直接找出包含「位置编码」关键词的全部文本行，精准命中4条数据；第二步：检索目录数据表 toc_df，筛选章节标题包含「位置」语义的章节，锁定唯一目标章节：3.5 位置编码；第三步：进行双表关联校验，精准锚定这4条文本行，并锁定它们所属的章节上下文范围，完成检索。

全程不需要向量嵌入、不需要余弦相似度计算、不需要大模型打分。仅靠文档结构化解析加上显性筛选规则，拿到的检索结果比Top-K向量召回更精准、层级也更合理。

看完这一核心对比，落地层面的思考已然清晰：我们过去一直在琢磨“如何让相似度打分更准”，本质上是在给一个有缺陷的黑盒检索流程打补丁。而筛选式检索的思路，是从顶层重构了RAG的检索逻辑：能靠结构化规则精准筛选的场景，坚决不用黑盒的相似度搜索。

余弦相似度、Top-K召回，从来就不是RAG检索的本质。它们只是在缺少结构化文档解析时的妥协方案。当我们能将原始文档解析成带有层级和字段的结构化数据后，检索就回归到了最简单的本质：条件筛选，多表关联。

这，也是未来企业级RAG落地的核心趋势：减少黑盒模型打分，多做白盒结构化规则；告别盲目的Top-K召回，优先采用精准的条件筛选。