几乎所有入门教程、主流开源框架的标准流程都是固定模板：文档切片分块→文本向量嵌入→用户问题向量化→全局计算余弦相似度→截取得分最高的Top-K片段送入大模型上下文。长久以来，我们默认这就是RAG检索的标准答案，甚至把"提升向量召回精度"当成优化检索环节的唯一方向。
但一套逆向的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 位置编码； 第三步：双表关联校验，锚定精准文本行、锁定对应章节上下文范围，完成检索。
全程不需要向量嵌入、不需要余弦相似度计算、不需要大模型打分。依靠文档结构化解析+显性筛选规则，就能拿到比Top-K向量召回更精准、层级更合理的检索结果。
结合上述对比，总结落地层面的核心思考： 我们过去一直在优化"怎么让相似度打分更准"，本质上是在给有缺陷的黑盒检索流程 打补丁。而这套筛选式检索思路，是从顶层重构RAG的检索逻辑：能靠结构化规则精准筛选的场景，坚决不用黑盒相似度搜索。
余弦相似度、Top-K召回从来不是RAG检索的本质，只是缺少结构化文档解析时的妥协方案。当我们把原始文档解析成带层级、带字段的结构化数据后，检索就回归了最简单的本质：条件筛选，多表关联。
这也是未来企业级RAG落地的核心趋势：减少黑盒模型打分，多做白盒结构化规则；告别盲目Top-K召回，优先精准条件筛选。