本文为工程实践复盘，客户信息已脱敏；所述数据均为示意值，不对应任何具体合同或审计数字。

一、项目背景

我们给一家区域零售集团做企业知识库问答，初版把商品手册、售后政策、内部制度一股脑切片入库，跑通后大家都觉得挺好。直到有一次，一位顾客问起两周前刚调整的"七天无理由退货"细则，机器人引的还是旧版条款，门店照着旧版执行，引发了一桩客诉，还被拍了照发到社交平台。我们这才意识到：一个建好就静止的知识库，比没有知识库更危险——它会"自信地答错"，而且错得很具体、很有说服力。政策、价格、库存这些要素天天在变，而 RAG 检索到的还是入库那一刻的快照。更隐蔽的是，旧版切片还在向量库里，检索时偶尔会和新版一起被召回，模型自己分不清哪个新，就挑了旧的讲。于是我们决定把知识库从"一次性灌入"改造成"可持续更新、可标注时效、可追溯版本"的活系统，让过期信息在检索阶段就被挡住。

二、落地场景

我们搭了一条增量接入流水线：监听源系统（政策文档、价盘表、FAQ）的变更事件，只在文档级内容哈希变化时触发重切片，避免整库重建。每个切片除了向量，还携带"生效日期"和"失效日期"两个时效标签，以及来源文档版本号。检索阶段，网关与检索层协同对过期或临近失效的切片做降权或召回拦截；答案侧强制引用带版本号的出处，让用户知道"这是哪一版政策、何时生效"。当新版本与旧版本冲突时，系统默认保留最新版、把旧版打上墓碑标记归档，而不是两版并存让模型"自由发挥"。运营人员可以在管理台看到"时效待核"清单，逐步把存量文档的生效日期补全，让整库从"部分可信"走向"全程可信"。

三、关键技术挑战与解决思路

第一个难点是增量接入与去重。整库重切代价太高、还会引入抖动，我们用文档级内容哈希做差异检测，仅对变更文档重切片，对变更切片只重新生成向量、并与既有向量做去重合并，控制写入压力。第二个难点是时效标记与过期召回。并非所有知识都有显式失效日期，我们对"强时效类"（价格、活动、政策）强制带失效日期，对"弱时效类"（品牌介绍、操作规范）用来源系统的更新时间戳作为新鲜度信号，检索时按新鲜度排序并降权陈旧切片。第三个难点是冲突仲裁。当同一知识点出现两个版本，我们不在检索阶段同时召回，而是以最新版本为准、旧版本加墓碑，必要时把冲突抛给人工审核，避免模型自己"二选一"选错。第四个难点是存量回填：历史文档没有生效日期，我们按首次入库时间近似填充，并打"时效待核"标记，由运营逐步校正，绝不让假新鲜混进生产。

案例片段（已脱敏）：增量重切片的差异判定片段：python doc_hash = sha256(new_content) if doc_hash == store.get(last_hash):    return "skip"                       # 未变更，跳过 chunks = rechunk(new_content) for c in chunks:    upsert_vector(c, effective_date, version) store.set(last_hash, doc_hash)

四、效果数据

以脱敏示意口径看：改造后，知识库的平均更新时延（从源系统变更到可被正确检索）由原来的"需人工全量重建、以天计"缩短到约 15 分钟。过期信息的检索召回率（用户本应看到新政策却取到旧切片的比例）由约 9% 降至约 0.8%。带版本出处引用的回答占比从约 40% 提升到约 95%，因"答旧知"导致的客诉类工单下降约 71%。存量文档的"时效待核"标记在约三周内被运营校正完毕，时效字段完整率从 0 提升到约 92%。知识库整体问答准确率（按周抽检）提升约 8 个百分点。所有数值均为示意值，不对具体合同负责。

五、可复用经验总结

知识库一定要"可更新"，静止的库是负债不是资产；更新机制要按文档级差异触发，别动不动整库重建，既浪费算力又引入抖动。时效标记要先于检索——在切片阶段就打上生效/失效日期，检索时才有依据做召回拦截，而不是等答错了再下架。版本与溯源不可省，答案必须带出处版本号，冲突时以最新版为准并归档旧版，两版并存只会制造幻觉。存量文档的时效字段允许先近似后校正，但一定要打"待核"标记，否则假新鲜比真陈旧更隐蔽，因为它看起来"有出处"。

在落地过程中我们逐步把“时效”从技术指标变成组织动作：每个业务域指定一名文档责任人，对所属知识的生效与失效日期负责，治理看板每周自动拉出“临期清单”推给责任人确认，避免新鲜度只靠系统信号、没人兜底。我们还把“过期知识致错事件数”列为知识库的北极星指标之一，和准确率并列考核，倒逼各团队把更新当成例行而不是救火。实践下来，最难的不是技术而是习惯——当责任人看到自己域的陈旧片段被抽检抓出，更新主动性明显提升。另一个收获是：时效治理让 RAG 的检索质量有了“时间维”的护栏，原本答非所问里相当比例其实是答了旧知，这部分在时效拦截后显著下降。我们后来把这套机制固化成上线前必过的检查项：任何新知识入库都必须带时效标签，缺失则不允许进入生产检索，从入口堵住假新鲜。另外，我们把“元数据完整率”写进数据域的月度考核，和责任人的绩效弱挂钩，确保治理不是一阵风，而是持续运转的日常。

案例片段（已脱敏）：时效召回拦截配置片段：yaml retrieval:  freshness:    strong_ttl: [price, campaign, policy]   # 强时效类强制失效日期    weak_ttl_signal: source_updated_at        # 弱时效类用更新时间戳  expired_action: recall_and_block            # 过期切片直接召回拦截  citation: { require_version: true }          # 答案强制带版本出处