知识库更新，坑不在建索引，在切换的那几秒。这周素材里没有直接讲这个的——只有几篇讲 agent 面对检索证据和自身先验冲突时怎么反应，算擦边。所以这篇主要是工程判断。结论先放这：全量重建加双索引原子切换，对多数团队性价比最高；增量更新不是更高级，是更贵，只有重建窗口长到业务忍不了才值得上。
全量重建没错，错在假装没有窗口
全量重建的代码路径只有一条：拉数据、切分、embedding、写进新索引。没有状态机，没有「这条文档上次同步到哪个版本」的元数据表，出问题重跑就行。这种简单性是真值钱的。
问题是重建那段时间怎么办。我见过不少团队的做法是——不办。旧索引继续服务，建完了再整个覆盖过去。听起来没问题，实际上这段时间用户搜到的还是旧内容：新文档搜不到，删掉的文档还活着。如果业务能接受「最长滞后若干小时」，那这就够了，一行代码都不用改。难受的是这个滞后压不下去的时候。
双索引切换：把「重建」和「上线」拆开
做法很土。新索引写到另一个名字，建完跑一遍预置的验收查询，然后把读别名原子地指过去。回滚就是把别名指回来，秒级。Elasticsearch 用 alias，Qdrant 有 collection alias，Milvus 也有，pgvector 那边没现成的，就在应用层加一张路由表或者套一层 view。
真正容易踩的就三件事：
- 别名切换必须原子，别出现一半请求打新、一半打旧
- 旧索引别急着删，留到确认没问题再回收
- 验收查询提前写死在配置里，别上线当天临时拍脑袋
代价是双倍存储加重建期间的双份算力。存储这块现在基本可以忽略，真正花钱的是 embedding 重算。所以「双索引贵不贵」这个问题，答案取决于你的重算成本，不取决于你的磁盘。
双索引也不是万能的
超大库上，这招会失效。多大算大，我给不出数——取决于你的向量维度、分片数、重算用的机器。但判断方法很直接：看一次全量重建跑多久、峰值吃掉多少写入带宽。如果重建本身要跑十几小时、要占掉集群一半的 IO，那你在重建期间再加一份索引，线上查询会被拖垮。这时候双索引不是两倍成本，是两份互相干扰。
更常见的一种：重建时长随文档量线性涨，业务要求的滞后窗口不变。两条线迟早交叉。交叉那天，你就必须上增量了。
增量更新救不了换 embedding 模型
这是我觉得最容易被忽略的地方。很多人把增量更新当成终点，好像上了它以后就不用重建了。不是。
先说增量本身最难的也不是新增，是删除和修改——文档被删了要落 tombstone，位置漂移要能对上，一套状态机跑下来，维护成本比全量重建高一个量级。这还只是日常同步。
真正的问题是：增量更新解决「文档变了」，解决不了「模型变了」。换 embedding 模型，哪怕是同家族的下一版，新旧向量也不在一个空间里，不能混着检索。这时候唯一正确的做法还是全量重算，老老实实走双索引。而模型迭代这件事，按现在的节奏一年总会来一两次。所以增量省的是日常同步的钱，不是模型升级的钱。
ArXiv 这周有篇 Accurate but Not Humble，讲 LLM agent 在检索证据和自身先验冲突时，未必会改答案。搬到知识库场景就是另一层麻烦：索引换了，缓存没换、prompt 里的 few-shot 例子没换、上游 agent 的记忆没换，用户看到的还是旧答案。切换不只是切索引，缓存那层也得一起 invalidate。这块经常被漏。
阈值由业务定，不由技术定
「重建多久算长」这个问题，技术给不出答案。技术能给的是一条曲线：文档量涨上去之后，全量重建的 wall time 怎么变。这条曲线自己测，方法也简单——每次重建埋点，记开始时间、结束时间、文档数、索引体积，跑上半年就有数了。
拍板的是业务。搜索停 20 分钟行不行？结果滞后 4 小时行不行？电商可能 20 分钟都不行，内部 wiki 可能滞后一天也没人管。两个答案对应两套方案，没有通用的那条线。
这周 HN 上 Docker Agent、Talorys 这类自托管 agent 项目热度都不低，说明知识库这东西各家搭各家的，本来就不指望有个标准答案。
按我现在看，大部分团队不需要增量更新。先上双索引，把重建窗口和上线时刻解耦，省下的时间拿去优化重建速度——并行分片、只重算变化的分区、把 embedding 批大小调对，这些都比写一套增量同步状态机便宜。也许半年后回头看，这套说法会被真正的大库打脸。但大库是少数。