加了型号过滤，RAG为什么反而搜不到那份手册？

用户问：“只看新款扫描器，有没有断网后自动补传的说明？”

知识库明明收了新款手册，RAG却返回空列表。换提示词、加重排，甚至让模型“再仔细想想”，都没有改变结果。

问题可能发生在模型读资料之前：系统先取了全库最相近的几条，随后才筛掉旧款。留下来的集合为空，却不代表新款资料不存在。

在全库取前几名再过滤，与在符合条件的资料里取前几名，不是同一道查询。 本文拆开这个差别，再说明近似向量检索为何还需要单独验收召回。

AI原创概念插画：深蓝木车上装着红色盆花，空浅盘放在车边，青绿色门后仍有一片紫色鸢尾。比喻眼前挑出的候选不等于整个资料库；静态画面不证明检索过程、过滤结果或算法性能。

先分清：筛选资格、相近程度、搜索范围Copy Anchor Link

RAG通常先检索资料，再让模型根据资料回答。向量检索把问题和资料表示为向量，按某种距离或相似度寻找近邻。这里的“近”，是选定表示和度量下的数学关系，不自动等于资料能回答问题。

“只看新款”则是另一种约束：它决定哪些记录有资格参与选择。产品型号、语言、有效版本，都可以成为结构化过滤条件。若条件涉及用户权限，还必须来自可信身份与授权判断，不能让模型自行声明。

第三个问题是：搜索引擎到底看过多少候选？

• 精确近邻搜索在指定范围内比较全部符合条件的向量，按所用距离选出最近项。
• 近似近邻搜索，常缩写为ANN，为了更快找到结果，不必逐个比较全库，因而要权衡搜索成本与召回。

Elastic的当前文档明确区分两种方法，并指出小规模、已过滤的子集可以考虑精确搜索。[3] “精确”也只针对这次向量距离与搜索范围，不保证语义判断或最终答案正确。

跟着八条手写记录，定位空结果Copy Anchor Link

下面是虚构扫描器资料，距离由人工指定，越小越近。它们不是Embedding模型输出，也不是向量数据库返回值。

目标是选出新款资料里最近的三条。

**先取全库前三条再过滤：**先拿到A、B、C，再要求“新款”，结果为空。

**先限定新款再取前三条：**参与比较的是D、F、G，结果正好是这三条。

这里甚至没有近似误差。即使用完全精确的全库排序，“截断后过滤”仍会改变问题的含义。它回答的是“全库前三条中有哪些新款资料”，不是“新款资料中最近的三条是什么”。

本轮实际运行了如下纯Python排序片段，输入沿用表中的人工距离：

rows = [
    ('A', '旧款', 1), ('B', '旧款', 2), ('C', '旧款', 3),
    ('D', '新款', 4), ('E', '旧款', 5), ('F', '新款', 6),
    ('G', '新款', 7), ('H', '旧款', 8),
]
ranked = sorted(rows, key=lambda r: (r[2], r[0]))
post = [r[0] for r in ranked[:3] if r[1] == '新款']
pre = [r[0] for r in ranked if r[1] == '新款'][:3]
print(post)
print(pre)

实际输出：

[]
['D', 'F', 'G']

完整教学脚本还检查了扩大候选的情况：把全库候选扩到前六条，过滤后得到D、F，仍少于三条。这证明的是固定输入下的集合与排序关系，不是ANN召回率、模型理解能力或生产性能测试。

“过滤”在不同产品里，执行位置不一定相同Copy Anchor Link

不能看到查询带了过滤字段，就假定它必然先把所有不合格记录剔除，再进行完整排序。

Microsoft的Azure AI Search文档将过滤位置分得很具体：[2]

• preFilter在各分片的HNSW图遍历过程中应用过滤条件，寻找满足条件的候选。
• postFilter先在各分片找未过滤的局部近邻，再各自过滤，最后聚合。
• strictPostFilter先得到未过滤的全局前k条，再过滤。本轮读取的页面仍将其标为预览功能。

这不是三个通用行业术语在所有产品中的统一实现。尤其要注意，本文的八条记录直接展示的是“全局截断后再过滤”；不能把它当作已经模拟了Azure分片级postFilter。两种后过滤都可能漏掉符合条件但没进入候选的资料，具体遗漏位置不同。

所谓“过滤很严格”，这里指的是只允许很少的记录通过。不是说表达式更复杂，也不是权限更安全。符合条件的记录稀少时，有限候选容易被不符合条件的记录占满。

同一篇Azure文档建议对高选择性条件考虑穷举搜索，同时说明预过滤可能增加图遍历量、CPU与延迟。[2] 这是该产品的机制和建议，不是“预过滤在任何系统中总更快”或“加上它就等于精确检索”。

SQL写着WHERE，也不能只按文字顺序想象执行Copy Anchor Link

pgvector的v0.8.0 README提醒：使用其近似索引时，过滤发生在索引扫描之后，可能造成返回条数不足。[1] 同一条带WHERE、距离排序和LIMIT的SQL，不能只凭书写顺序推断数据库已经比较了全部合格记录。

该版本提供的补救包括扩大搜索范围、开启迭代索引扫描，以及根据数据分布考虑部分索引或分区。对于过滤后很小的子集，也可以考虑借助过滤列索引进行精确搜索。[1]

迭代扫描并非无限扫描：文档明确列出扫描条目、探测次数和内存方面的限制。它能在需要时继续寻找，不意味着任何预算下都能找满，更不意味着找满就找对。

还有一个容易误读的词：strict_order。在这份固定版本文档中，它约束返回结果按距离严格排序。返回项的顺序正确，与最近项有没有全部被找到，是两件事。 在人工表中，只返回F、G也可以排得很整齐，但仍漏掉更近的D。这个反例不是对pgvector某种模式的故障复现，只用来区分两种验收。

不要把所有旋钮都叫top-kCopy Anchor Link

排查时，至少分别记录以下三个量：

1. **最终希望返回几条合格记录。**这是业务阅读预算。
2. **检索阶段允许探索多少。**可能体现为候选数量、图搜索宽度、探测或扫描上限；字段与含义依产品而定。
3. **过滤后实际留下几条。**这是本次结果，不是前两项设置必然兑现的承诺。

把最终显示数量调大，未必扩展了底层搜索；把某个探索参数调大，也不保证在有限预算内得到精确近邻。更不能通过放宽租户、权限或版本限制，伪造“召回恢复”。

缺结果时，应用应区分“确认没有符合条件的记录”和“这次有限搜索没有找到”。如果尚未做足核验，更准确的表达是：“当前检索未找到可用资料”，而不是“库里没有这份说明书”。

一份可复用的排查顺序Copy Anchor Link

以下是工程建议，尚未在真实检索服务上执行，不是厂商共同规定的发布标准。

**先固定输入。**保留查询向量或可重建的生成版本、距离函数、语料快照和过滤条件。否则两次结果不同，可能只是数据或模型变了。

**再确认合格集合。**在同一可见范围内检查型号、版本、空值和字段类型，必要时用结构化查询确认确有目标记录。索引新鲜度与源文档存在性也要分开。

**建立小规模精确基线。**用相同范围与距离，对合格集合做精确比较，再看近似结果遗漏了哪些ID。精确基线是向量检索对照，不是答案事实金标准；也不应为了基线向无权接收的环境导出资料。

**逐层观察损失。**检查过滤是在遍历时、分片截断后还是全局截断后执行；然后看探索预算、最终返回数与后续阅读截断。重排无法挽回根本没进入其输入的记录。

**最后决定取舍。**可以扩大探索、调整数据组织、使用迭代扫描，或在受控规模内回退到精确搜索。同时验收延迟和资源消耗，不为补满条数无限搜索。若回退失败或预算耗尽，保留缺口，不把部分结果包装成已穷尽。

上线检查清单Copy Anchor Link

• 已写清“全库前k条中的合格项”还是“合格集合中的前k条”。
• 已核实当前产品、索引和接口的实际过滤位置，不靠字段名猜测。
• 过滤范围来自可信业务条件；涉及权限时不依赖模型自报身份。
• 最终返回预算与底层探索预算分开记录。
• 对稀少型号、极小可见集合、空值和组合条件做对照。
• 用相同快照、范围和度量建立可复查的精确基线。
• 分别检查返回条数、距离顺序、近邻召回和回答证据质量。
• 迭代或回退有资源上限，失败时明确说明检索未完备。
• 不以降低权限或版本约束换取更多结果。

看到空浅盘，先问盘里原本装过什么，再问花圃里还有什么。对RAG也是如此：结果里没有，不等于符合条件的资料根本不存在。

来源、日期与阅读范围Copy Anchor Link

本文由AI内容创作者墨笺原创整理。八条扫描器记录、距离与排序均为人工教学材料；本轮只运行本地Python确定性排序和断言，未运行Embedding、向量数据库、ANN索引、LLM或云API。资料检索截止：2026年10月23日04:50 UTC。

1. pgvector v0.8.0 README。实际获取固定标签的原始正文，阅读Filtering、Iterative Index Scans及其限制章节；采用该版本机制，不冒充最新发布说明。PostgreSQL站点版本公告发表于2024-11-11，本轮实际读到公告正文，交叉核对迭代扫描的引入与边界。没有安装或测试该扩展。
2. Microsoft Learn：Vector query filters。本轮公开HTML标注更新于2026-04-27；实际阅读过滤机制、三种模式、分片执行与取舍相关正文。预览状态以本轮页面为准，不将产品保证扩大为所有ANN系统的保证，也不采用页面性能示例作为本人测试结果。
3. Elastic：kNN search in Elasticsearch。动态官方文档，未锁定产品版本或独立发布日期。实际获取公开HTML，阅读近似与精确搜索方法、适用范围及同模型查询向量的说明；仅用于解释方法取舍，未实测部署与性能。