RAG 文档更新后仍返回旧答案：版本标记、过滤条件与回归验收

知识库刚更新完新版内容发布，RAG 问答却还在输出旧规则的答案，这类问题通常不是大模型“记混了内容”，而是旧的内容分片仍然留在了召回候选集合里。最稳妥的解决思路，是给每一份文档、每一个内容分片都写入可参与过滤的版本标记，正式提供服务时只开放单一有效版本，最后用固定的问题用例集完整校验召回结果和最终输出的回答。

先把“旧答案”拆成三个可观察状态

排查时先记录同一个问题的完整链路：查询文本、召回片段的 doc_id、version、status、相似度分数，以及模型最终引用的片段。只看最后一句回答，很容易把召回错误误判成模型推理错误。

举个常见场景，客服知识库把“退款到账时间”规则从 7 个工作日改成 3 个工作日之后，用户问起系统还是返回旧的7天答案，出现这个现象大概率归为三类原因：

• 召回阶段直接命中了旧版本的内容分片；
• 新版本文档还没完成向量化或者索引还没刷新生效；
• 召回结果已经拿到新分片，但上下文拼接逻辑还是把旧片段的优先级排得更高。

这三个状态的修复动作完全不同，所以第一步不是调大 top_k，而是把证据留在日志里。

分片元数据要能表达发布边界

一份完整文档拆成多个 chunk 之后，每个 chunk 都要同步写入同一套发布元数据。够用的最小字段结构参考如下：

{
  "doc_id": "refund-policy",
  "version": 12,
  "knowledge_space": "customer-service",
  "status": "published",
  "effective_from": "2026-08-25T00:00:00+08:00",
  "chunk_no": 3
}

version 负责区分内容，status 负责控制是否对外可见，knowledge_space 防止不同业务域串库。时间字段可以帮助审计，但不要拿它替代发布开关：时钟、时区和未来生效规则会让排查变复杂。

OpenAI 的向量库搜索接口会把文件属性过滤作为搜索参数的一部分，支持等于、不等于、范围和多条件组合筛选；市面上其他向量库也都有类似的 payload 或者 metadata filter 能力。核心点不在字段叫什么名字，而是这些过滤字段必须在发起检索之前就已经可以正常查询。

发布流程：先写入，再切换唯一有效版本

建议把全量发布拆成四个衔接的阶段。新版本先进入隔离状态，走完分片、向量化和索引可用性检查流程之后，再切换业务侧查询使用的全局版本号。

1. 写入候选版本：所有新分片使用 version=13,status=staging，不直接对线上问答开放。
2. 做检索抽样校验：用 10 到 20 个固定业务问题检查是否能正常召回版本 13 的内容，记录下空结果和相似度分值过低的异常情况。
3. 切换发布指针：把知识域的 active_version 从 12 改成 13，再让查询过滤 status=published 与该版本。
4. 留观测空间支持快速回滚：如果核心业务问题的答案出现不符合预期的偏差，直接切回旧版本号12即可，不用先急着删掉版本13的全量数据。

filter = {
  "and": [
    {"key": "knowledge_space", "type": "eq", "value": "customer-service"},
    {"key": "version", "type": "eq", "value": active_version},
    {"key": "status", "type": "eq", "value": "published"}
  ]
}

这里的 active_version 应来自配置或数据库中的单一发布记录，而不是由应用进程自己拼出来。多实例服务如果各自缓存版本号，切换后会出现一部分请求回答新规则、另一部分仍回答旧规则，日志里看起来像随机故障。

相似度不是版本正确性的替代品

旧内容片段和新内容片段往往措辞非常接近，甚至旧内容的向量相似度得分可能更高。先执行元数据过滤，再跑相似度排序，才能把“语义上足够相似”和“当前版本正式生效”两个校验逻辑分开。

如果使用向量库原生的过滤能力，过滤字段通常需要提前配置对应的索引。Qdrant 官方文档把 payload index 作为高效过滤的核心准备项；也就是说“字段已经成功写入”不等于“查询已经可以按这个字段高效过滤执行”，还要额外检查索引创建状态和字段类型是否符合要求。

用固定问题集验收一次更新是否真的生效

验收用例不用一开始就搭建复杂的自动化评测平台，先维护一份能稳定复现核心业务规则的问题集就够用：

• 新旧规则结论完全相反的问题，比如前面说的退款到账时间从7天改3天这类场景；
• 必须命中特定条款的问题，用来校验回答的引用来源是否正确；
• 知识库没有对应答案的问题，用来观测系统会不会编造不存在的内容；
• 不同同义表达的同类问题，用来确认版本过滤规则不会误伤正常召回。

每条用例至少保存四个结果字段：retrieved_versions、top_chunk_ids、citation_doc_ids 和 answer。发布门禁可以先用简单规则：

assert retrieved_versions == [active_version]
assert citation_doc_ids
assert answer_contains_expected_fact
assert no_forbidden_old_fact

这套流程不是用字符串匹配替代人工评审，而是先把最容易出现的版本串线问题拦截下来。对高风险的知识域场景，后续再补充人工抽样校验和拒答规则检查就好。

常见误区与回滚边界

最常见的误区就是上传新文档之后直接删掉旧版本的所有向量。这么做看起来清理得很干净，真要做回滚的时候连可用的旧数据都找不到，还可能因为删除任务和索引刷新进度不同步，造成短时间内检索结果为空的异常情况。保留所有历史版本数据，通过切换唯一有效版本指针的方式做发布，后续排查问题也更容易溯源复盘。

另一个误区是把缓存 TTL 当成版本一致性方案。缓存可以降低成本，但缓存键里至少应包含 knowledge_space 与 active_version；切换版本时主动失效，比等待几分钟自然过期更可控。

相关问题

只保存文档版本，不给 chunk 保存版本可以吗？

不建议这么做。检索返回的结果是分片粒度，过滤逻辑和引用溯源也都在分片层执行；只在文档层面记录版本号，很容易在分片拆分、重试任务或者增量更新的时候丢失版本发布的边界信息。

为什么新版本已经写入却搜不到？

先排查数据处理状态、索引刷新进度和过滤字段类型，再调整相似度阈值。新内容还没完成索引构建的时候，直接调高召回数量对解决问题没有任何帮助。

回滚时要不要重新生成旧向量？

如果旧版本向量还没被清理，优先切回旧版本指针恢复服务；只有旧数据已经损坏或者索引完全不可用的时候，才重新生成对应内容，并且把这次重建当成独立的变更走完整验收流程。

发布前速查

一套可以复用的排查顺序是：先确认新版本的分片和索引全部正常就绪，再确认查询过滤规则只允许命中当前生效版本，接着检查召回引用的分片全部来自同一个版本，最后用固定问题用例集验证新旧结论和拒答边界。只要其中任意一项校验没通过，就先把新版本停在候选状态，不要把“看起来答得出来”当成发布完成的标准。