知识更新:别让它自信地回答"上个版本的规定"

四种更新场景,四种处理

最凶险的是"修改":如果你只是把新版本加进去,旧块还在——检索时两个版本都可能进 top-k,模型看到矛盾信息,要么随机挑一个,要么把两个数字都说出来。用户看到"59 元(或 79 元)"会当场失去信任。

一套够用的更新机制

① 给每个块打上溯源信息

chunk = {
    "id": "policy_delivery#p2",     # 稳定 ID(文档 + 段落)
    "doc_id": "policy_delivery",    # 所属文档
    "content_hash": "a1b2c3…",      # 内容哈希,用来判断"变没变"
    "version": "v3.2",
    "updated_at": "2026-08-04",
    "text": "...",
}

② 增量更新:按文档为单位"先删后加"

def upsert_doc(doc_id, new_text):
    new_chunks = split(new_text)
    old = index.get_by_doc(doc_id)
    if hash_all(new_chunks) == hash_all(old):
        return "未变,跳过"          # 省掉重复嵌入的钱
    index.delete_by_doc(doc_id)      # ← 关键:先删干净
    index.add(embed(new_chunks))
    return f"更新 {len(new_chunks)} 块"

内容哈希的作用:定时任务全量扫一遍文档时,没变的直接跳过,不用重复付嵌入费用。文档多了之后这能省很多。

③ 更新完必须重跑评测

这是最容易被跳过、后果最严重的一步。文档一改,你之前的评测集可能有一半答案就过时了。所以:

• 评测集也要版本化(标注"依据 v3.2 的规定");
• 政策类改动后,先更新评测集的标准答案,再跑分;
• 分数明显掉了 → 大概率是新旧块混在库里,或切分对新文档不适用。

上线后的三个运维习惯

1. 给答案带上"依据版本/日期":回答末尾加一句"依据《配送规则 v3.2》(2026-08 更新)"。用户能一眼看出信息新旧,你也能在投诉时快速定位;
2. 定时全量校验:每周跑一次"文档哈希 vs 索引哈希"的比对,发现漂移就重建——别指望每次改文档的人都记得通知你的系统;
3. 重建索引要能灰度:大规模重建(比如换嵌入模型)时,新旧索引并存、灰度切流量,跑评测确认不掉分再全切(AP7 讲灰度)。

🔧 动手做:模拟一次政策变更(12 分钟)

1. 拿你 ap4.2 的知识库,改掉一个关键数字(比如免运门槛 59 → 79),但不更新索引。
2. 跑一遍评测集——系统还在用旧答案吗?它有没有一丝犹豫?(不会有,这就是问题所在。)
3. 实现 upsert_doc(先删后加 + 内容哈希跳过),重新索引,再跑一遍。
4. 制造"只加不删"的事故:把新版块加进去但不删旧块,跑评测——观察模型面对矛盾信息时怎么表现(可能给出两个数字,或随机挑一个)。
5. 给回答加上"依据版本/日期"的尾注,看看体验差别。

✅ 做到这里你应该有:一个带溯源信息的索引结构 + 一个增量更新函数 + 一次"只加不删"的事故体验。

为什么:🎉 AP4 完结。ap4.1 那个"编造 5/8"的基线,现在被你用切分 → 检索 → 评测 → 重排 → 引用 → 更新六道工序治住了。

但请记住这一节的位置:前五节决定你的 RAG 上线时有多好,这一节决定它三个月后还剩多少。见过太多 RAG 项目在上线时惊艳、半年后沦为"过期信息生成器"——差别就在有没有这套更新机制。

我的知识库:【文档类型和数量】,更新频率【多久一次、谁来改】,存储【文件/数据库/云文档】。请帮我设计更新机制:1) 块的溯源字段设计;2) 增量更新流程(先删后加、哈希跳过);3) 怎么发现「文档改了但没同步」;4) 更新后评测集怎么跟着更新;5) 大规模重建索引的灰度方案。