AI助手不带条件能找到一份产品资料，限定市场或版本后却回答“没有相关内容”。这时继续补写提示词，未必能解决问题。资料可能没有丢，变化的是检索要搜索哪一批候选，以及系统怎样在这批候选里寻找相似内容。

AWS在9月30日介绍S3 Vectors的元数据预筛选：ENHANCED模式先确定满足元数据条件的向量，再只在其中做相似检索。官方对CLASSIC的描述则是向量搜索与筛选配合进行、逐个验证候选，不能把它简单说成“固定取前几条，然后统一过滤”。两种模式的区别需要按实际机制理解。

先问符合条件的资料到底有哪些

产品知识库里的市场、版本或文档状态，通常来自企业自己写入的元数据。筛选表达式看上去正确，并不代表资料上的值也一致。新版本资料仍挂着旧标签、缺字段，或者约定的状态名称前后不同，都可能把应当命中的资料排除。

排查时可以先挑一份已知适用的文件，核对它是否真的进入索引、元数据实际是什么，再检查请求使用的条件。若文件根本不满足当前条件，相似度再高也不该被返回。把筛选删掉后“终于有答案”，只证明更大的范围里有相似内容，不能证明原来的约束可以删除。

接着才是索引模式。AWS说明，已有索引会保持CLASSIC，直到被更新；9月30日之前创建的桶，也不会仅因后来新建索引就自动采用新的默认模式。不能看到一条功能公告，就假定现有产品库已经切换了行为。需要读取实际配置，而不是凭创建时间的模糊记忆判断。

更多结果，可能正好是错的结果

对于售前产品回答，一份旧规格或不适用市场的说明书，可能比暂时不回答更容易引起误解。检索质量不只看返回多少条，还要看这些条目有没有满足问题里的条件。为让结果变多而放宽市场、版本或文档状态，可能让答案变得流畅，却失去原本的适用范围。

可以准备一组很小但明确的对照：一份确定在范围内的资料，以及一份文字相近但不在范围内的资料。检查前者能否被找到、后者是否仍被排除。若只测“有没有返回结果”，就看不出新设置是否靠混入不适用内容改善了表面表现。

这和更换嵌入模型时核对旧索引不是同一项检查。模型与向量配置决定相似性比较的基础；元数据条件决定哪些资料有资格参与比较。两个环节都可能使答案缺失，但处理办法不同，不应一遇到漏答就同时换模型、重建库和改提示词。

元数据筛选也不能单独证明访问权限已经正确。租户或市场字段可以参与检索约束，谁有权发起什么查询仍需由应用自己的授权规则决定。这次机制变化不构成放宽文档访问的理由。

对已经维护产品知识库的中国外贸团队，先把一次漏答还原为具体查询、条件和候选资料，再决定是否调整索引模式。若问题出在字段值或版本标注，纠正那条数据，通常比让模型反复猜“应该去哪找”更切中原因。

参考来源