RAG检索本质是筛选，别掉进余弦相似度陷阱

说起来，很长一段时间里，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召回，优先用精准的条件筛选。