文档一变，答案就旧了过期比没有更危险

这是「RAG 知识库 · 建库与运维」系列的第四讲（系列收尾）。前三讲把库建好——分段模式定结构、元数据过滤降噪声、能力边界划清值源；这一讲回答最后一个问题：它能活多久。

开场那个追问：你今天答对的这条内容，三个月后还对吗？手册 v2 发布那天起，v1 的内容就过期了，但问答系统不知道，它还在答旧版——而且答得头头是道：结论清晰、依据齐全、每条都指向手册某一章。唯一的问题是那是旧版口径，按旧参数配置设备起不来。它答错的方式很「权威」，非行家一眼看不出。

金句：知识库会过期，而「过期」比「没有」更危险——没有知识库时，人知道自己不知道，会去翻最新手册；知识库答了旧版，人以为问题解决了，错的答案被当成对的执行了。所以文档更新不是上线后的边角维护，而是问答系统能否长期可信的核心命题。

四件事一条链：粒度（建库时定结构）→ 版本（更新时处理旧文档）→ 守门员（更新后必过两道验证）→ 责任（谁长期跑这套流程）。

第一件·粒度：知识库里的「段」不是独立管理单位，平台是文档级管理，没有分段级接口。入库时以什么颗粒度上传，更新时就得以什么颗粒度替换；重传不是打补丁——整篇按规则重新分段，只改一行相邻边界也可能跟着变。经验一条：把容易变的东西单独装（判断依据是「可能独立变更的内容单元」，不是章节序号）——几百页手册按章拆、参数表 FAQ 独立成文。就像不是把整栋楼浇成一体，而是把承重结构和水电管线分开，管线要换只动管线。

第二件·三步定位：哪份变了（看源文件不看库，库内分段只是快照）→ 库里的谁（靠建库时登记的对照清单：源文件名/库文档编号/入库时间/文件指纹，没有它几十上百篇只能靠猜）→ 怎么换（删旧传新等索引，然后必须验证）。

第三件·旧版本三种去处：替换删除 / 停用归档（不参与检索但保留）/ 版本并存——并存不是乱存，是靠元数据标明「现行/历史」，在检索节点的过滤条件里限定「状态=现行」，从检索这步就把历史版本拦掉，不靠模型判断（模型判断会漂，过滤规则不会）。额外收益是溯源：答案带版本号出来（「依据《配置指导》v2.3 第 4 章」），客户能对得上手上那本手册，答错也能追到是哪一版依据。

第四件·守门员：每次更新都是质量事件，会把检索带偏且很隐蔽（分段风格不一致互相干扰／删了旧文档但向量索引可能有残留／新文档覆盖旧主题后命中位置悄悄换了）。两道检查：固定问题集回归（建库时留代表性测试问题并注明期望命中段落，更新前记基线、更新后对比；问题集要随业务增补并重新标定基线）+ 旧版残留检查（拿旧版特有表述去问，专防「删了还在」）。高频错误：只测「新内容答得出」，不测「旧内容是不是真不出来了」。

第五件·谁维护：平台给的是「零件」（上传删除、分段索引、检索过滤、命中测试），而源文件变更检测、对照清单维护、回归问题集沉淀、更新流程约定这四样平台都没有——闭环得有人搭、有人跑。软件装上就能用，知识库装上只是开始，它需要被持续喂养。三种形态：客户自管（要有「实际专人」，不是顺便管一下）/ 交付方维护服务（主动拉取变更优于被动等通知）/ 纯交付不维护（风险自担）。

系列收束：第一讲定结构（一段装多少）、第二讲解决噪声（取哪些段）、第三讲划边界（值从哪来）、第四讲回答它能活多久；前三讲是把它建好，这一讲是让它一直好。收在：文档一更新，答案就得跟着对——问答系统的价值上限，是知识常新的能力。

完整文字版见下方文章。