检索噪声怎么降到 0能用规则解决的，别交给概率

这是「RAG 知识库 · 建库与运维」系列的第二讲。上一讲讲分段模式决定「一段装多少」，这一讲讲库里文档一多之后的另一个问题：检索串味。

场景：给一家网络设备厂商做问答，五百多篇文档横跨三个产品线，还有 verified 与 draft 两种状态、1.0 到 2.0 两个版本。这是典型的大杂库——同一个主题在不同产品线的文档里反复出现。

四个问题：跨产品线串扰（问 S6850 的 STP 配置，召回 S12500 的相似章节）、草稿混入正式答案、旧版本误答、以及为了规避串扰而拆库带来的隐性成本。根子在于向量检索是概率匹配——它比的是「语义像不像」，不知道这段属于哪个产品线、是哪个版本、是草稿还是正式版。

元数据闸门：给知识库定义字段结构、入库打标，检索时先按条件筛出文档子集，再在子集里做向量检索。顺序很重要——先过滤、后向量。收益是确定性子集、平台原生、顺带替代多库架构；还有一层容易忽略的价值：召回段落带着元数据回来，答得不对时你能对账，而不是只有一段文本可猜。

Schema 设计三问：这个字段会被用来过滤吗（不会的别建）／过滤一次能排除多少噪声（文档类型、产品线、版本、可信度这类高价值字段）／枚举值稳定吗（「S6850」和多一个空格的「S6850 」是两条枚举，条件会悄悄失效）。

两个数字：同一查询「STP 环路如何避免」，不过滤时 8 段结果里 6 段是无关产品线（75% 噪声）；加一个 product_line 条件后噪声归零，且 top_k 不缩水（在过滤后的子集里重新取满）。另一个是 0 段不报错：version 是数字字段，过滤值传字符串 "2" 会静默返回 0 段，没有任何报错——这种失败只能靠断言抓。

金句：能用规则解决的事，不要交给概率——闸门的价值不在于更聪明，而在于它不猜。

完整文字版见下方文章。