K8.2 知识库会变：更新、失效与重建
一张没兑现的支票
整个中篇反复用同一个论据说明 RAG 为什么赢过微调：
改知识库比重训一次模型快几个数量级，改完立刻生效。
K0.1 用它说明为什么模型「记不住最新的事」，K7.3 用它说明为什么长上下文替代不了 RAG，上篇 5.9 也用它把「补事实」这类需求整个推给了 RAG。
这句话是对的。但它一直没说清楚：「改」到底是怎么改的，以及要付多少钱。
这一节把这张支票兑现——顺便告诉你，其中有一种「改」贵得会影响你的技术选型。
六种改法，代价差四五个数量级
请按顺序做四个实验：
实验 ①：从最便宜的开始。 库拖到「20 万块」（约一万份文档，一个中型企业库），点「新增一份文档」。要重嵌 20 块、费用四舍五入是 0 元、耗时不到一秒。这就是那句「改完立刻生效」的底气所在。
实验 ②：注意「改一句话」的陷阱。 点「改一份文档里的一句话」——要重嵌的还是 20 块，也就是整份文档，不是被改的那一块。为什么？回想 K2 的切块：块的边界是按字数/语义顺着文档切下来的。你在中间删了一句话，后面所有块的边界整体位移了。只更新「看起来被改到」的那一块，会留下一批错位的旧块。
实验 ③：找出那个几乎免费的。 点「改权限标签 / 元数据」——要重嵌 0 块。这条最容易被误判：很多人以为改了标签就得重建索引。不用，向量本身没变，改的只是挂在它旁边的字段。K8.1 那套权限过滤能实时生效，靠的正是这一点。
实验 ④：现在看那个贵的。 点「换嵌入模型」，然后把库规模从 20 万一路拖到 1000 万块。费用从 40 元涨到 2000 元，耗时从 7 分钟涨到 5.6 小时——而且这是全库 100% 重建，没有任何折中余地。
为什么换嵌入 模型没有折中
实验 ④ 那个「100%」值得单独解释，因为它是这一节最重要的一条工程约束。
一个非常自然的想法是：新文档用新模型嵌，老文档留着旧向量，慢慢过渡。
这行不通，而且不是「效果差一点」，是根本不能用。
回到 K1.1 的基本设定：语义检索靠的是「意思相近的文本，向量坐标也相近」。但这个坐标系是每个模型自己定的——同一句话，A 模型把它放在某个位置，B 模型放在完全不同的位置。两套坐标系之间没有任何对应关系。
所以混用的后果是：你拿新模型编码的查询向量，去和一半新、一半旧的库比距离。和旧向量算出来的那些距离是纯噪声——不是「不太准」，是完全没有意义。检索结果会变成新旧混杂的随机排序。
一句话记住：向量库里的向量必须全部来自同一个嵌入模型。 这是硬约束。
由此得到一条选型建议，我认为是中篇最实用的一条：
选嵌入模型要比选对话模型更谨慎。 对话模型可以随时换——换个 API 地址就行，历史数据不受影响。嵌入模型一旦上线就产生了迁移成本，而且库越大越难换。
全库重建怎么做到不停服
真要全库重建的时候，标准做法是双写切换（也叫蓝绿索引）：
- 新建一份索引，用新模型在后台慢慢灌——这期间线上流量完全走旧索引，用户无感；
- 灌完之后，拿 K6 的评测集在新索引上跑一遍，确认它确实不比旧的差（换个「更先进」的模型在你的具体语料上变差，是真实会发生的事）；
- 一次性切流量过去；
- 旧索引留几天再删，以便随时回滚。
代价是这段时间要同时养两份索引，存储和成本翻倍。但对比「停服几小时」，这笔钱几乎总是值得付。
最便宜的那个，最容易出事
回到实验里的「删除一份文档」——它要重嵌 0 块，一分钱不花。但它是这六种里最容易出事故的。
原因是 K3.2 混合检索留下的伏笔：如果你上了混合检索，你有两套索引——向量索引和倒排索引。删除必须在两边都执行。
漏删一边的后果是：一份你以为「已经删掉」的文档，还能被检索出来。放在这些场景里想一下——离职员工的资料、法务要求撤回的文件、用户行使删除权的个人信息。这不是效果问题，是合规事故。
而且它极难自 查：向量检索测不出来（那边删干净了），只有恰好用关键词命中时才会暴露。
这一节兑现了那张支票，但要把附加条款也读完。
一、「立刻」取决于你的同步链路。 文档在源系统（网盘、Confluence、数据库）改了，到它在 RAG 里生效，中间隔着一条你自己搭的同步管道。如果这条管道是「每晚跑一次批处理」，那「立刻」实际是「最长 24 小时」。真要做到分钟级，需要源系统能推变更事件（webhook / CDC），这是一整块工程量，不是配置项。
二、旧答案会被缓存住。 如果你为了省钱做了问答缓存（同一个问题直接返回上次的答案），文档更新后缓存里那个旧答案还在。缓存要能按「涉及哪些文档」失效，而这要求你记录每个缓存条目引用了哪些块——很多实现没做，于是「改完立刻生效」在有缓存的路径上直接失效。
三、评测基线也会失效。 改了切块策略之后，块 id 全变了。你在 K6 精心标注的「这个问题的正确块是 #1234」全部对不上——评测集要跟着重建。所以切块策略最好在上评测集之前定下来，之后再改就是双倍工作量。
四、和微调比，RAG 赢的是「改的成本」，不是「零成 本」。 前面那句「快几个数量级」在增量更新上完全成立（几秒 vs 几小时），但换嵌入模型这一档已经进入「小时级 + 要排期 + 要回滚方案」的工程行动了。诚实的说法是：RAG 让日常更新变得几乎免费，但它自己的基础设施变更仍然是有分量的工程。
- 六种变更的代价极不对称：增删改单份文档几乎免费，换嵌入模型/改切块策略要全库重建，中型库上差四五个数量级。
- 改一句话要重嵌整份文档——切块边界会整体位移，只更新「被改的那一块」会留下错位的旧块。
- 改权限标签/元数据不用重嵌（向量没变），这是 K8.1 权限能实时生效的基础。
- 向量库里的向量必须全部来自同一个嵌入模型，新旧混用算出来的距离是纯噪声。推论：选嵌入模型要比选对话模型更谨慎，库越大越难换。
- 全库重建用双写切换（新索引后台灌 → 评测确认 → 切流量 → 旧索引留几天回滚），代价是短期存储翻倍，换来用户无感 。
- 删除最便宜但最容易出事：向量索引和倒排索引必须同时删干净，漏一边就是「已删内容仍可被检索」的合规事故。
延伸阅读
- K2.1 为什么要切块——「改一句话要重嵌整份文档」的原因（边界位移）就在这里。
- K3.2 混合检索——「两套索引都要同步」的由来。
- 下一节 K8.3 文档也会攻击你：知识库不只会过期，它还可能被人下毒。