问 125，别答出 65关键不在过滤，在值从哪来

这是「RAG 知识库 · 建库与运维」系列的第三讲。上一讲讲元数据过滤这道闸门的用法（Schema 设计三问、噪声 75% 降到 0）；这一讲讲它的能力边界。

开场那个要求：库里有 S12500 和 S6850 两款设备的操作手册，客户要求「问 125 的问题不能答出 65 的内容」——两款型号端口号与配置命令不同，答错型号客户照着配，设备起不来。

自动过滤实测废了：平台有个「元数据自动过滤」开关，让大模型读问题现场生成过滤条件。3 次查询 0 次全对——1 次只生效一半、2 次退化成根本没过；问「S12500 的 STP 配置」本该生成「型号=S12500、只查配置类」，结果一个都没生成，别的型号配置段与故障处理段全混进候选。成本上：3 次调用烧掉 6629 个 token，单次延迟从 7.5 秒拉到 26.9 秒。

机制四条：检索前先在文档层筛一次（只留命中文档编号）；向量检索只在筛出的分段里做（筛出去的物理上不在候选池）；没有文档命中就返回空结果，不会偷偷放宽条件；停用、归档文档永远进不了候选池。

两个结论：它是认标签不认人的闸门——筛的是「文档标了什么」，不是「用户问的是什么」（用户问题只有 automatic 模式才会被读）；它只管放行不纠错——条件是错的也照样执行，显式返回空结果。准确画像：文档级、认标签、确定性执行的闸门，没有理解能力，也不该有。

金句：型号能不能隔离，取决于型号这个值从哪来，不取决于过滤本身。过滤是执行器（执行器没问题）；失败根因是把「提取」这件需要设计的事，外包给了一次不可控的模型调用。可靠值源三路：入口固化 / 用户选择 / 应用层提取（抽不到就说不抽到，不猜）——共同点是值从可控的地方拿到，拿没拿到是确定的。

可照做的四步：建库打标（通用内容单独标「通用」，并做「带条件 vs 不带条件」自检）→ 型号当会话状态（确认一次全程生效）→ 检索节点手动模式，条件「型号 in (会话变量, 通用)」——通用值必须并进去，这是最容易漏的一环 → 验收跑四组用例。

客户三连问：① 没带型号——多数情况型号就在你手里（会话状态），真没带则「内容通用直接答、内容不同才反问」；② 上下文也判断不出——先查后判，把判断从检索前置关卡挪到结果出现歧义之后（需要区分型号的内容必然带型号词，内容自己会暴露）；③ 用户也不知道型号——按风险分级：低风险双列对号入座，高风险拒绝并引导看设备铭牌。

收口：能做的——按静态属性切池（版本状态、文档类型写死，与用户问什么无关所以可靠）；不能做的三条——不替你理解问题、不替文档打标、不解决「问题缺信息」。

完整文字版见下方文章。