索引新鲜度（Index Freshness）说的是：检索索引里的内容和真实数据源"对得上"的程度；增量重建（Incremental Rebuild）是维持这份新鲜度的做法——只更新变了的那一小块，而不是把整个知识库推倒重来。
从一个图书馆的比方说起
RAG（Retrieval-Augmented Generation，AI 词典：检索增强生成">检索增强生成）的知识库，本质上是一个图书馆加上它的卡片目录。文档进来后要先切块（chunking），转成向量（embedding）写进向量库（vector store），有的系统还会顺手建一份关键词索引（比如 BM25），方便精确匹配工单号、产品型号这类词。
全量重建，就是把整馆书的卡片全部重抄一遍。明明只新上了三本书，你却抄了一百万张卡——时间和钱都花在没变的部分上。增量重建则是：新书上架只抄新卡，书下架就把旧卡抽走。听起来简单，难的是"哪些变了"你得知道。
判断变化，通常靠内容哈希、修改时间、版本号，或者上游数据库的变更捕获（CDC）和消息通知。找到变化的文档后，只对它重新切块、重新向量化，替换库里对应的旧记录。
最容易翻车的细节是：删除必须传播到块一级。一份文档被删了，它的十几个向量块也得一起删，否则检索还会命中"幽灵块"，模型据此回答，你会得到一段引用着已废止文件、语气还特别笃定的答案。权限变更同理——文件还在，但某些人已经无权看了，索引里的副本得跟着改。
另一个要点：换了向量化模型，通常就得全量重建。不同模型产出的向量不在同一个语义空间里，混着用等于拿两种语言互相检索。具体怎么兼容，各家向量库不同，以官方文档为准。
和相邻概念的区别
| 维度 | 全量重建 | 增量重建 |
|---|---|---|
| 计算成本 | 高，全部内容重算 | 低，只算变化部分 |
| 生效速度 | 小时到天级 | 分钟级 |
| 实现复杂度 | 低 | 高，要处理变更捕获与删除传播 |
| 主要风险 | 贵、窗口期长 | 残留过期块、状态不一致 |
| 典型场景 | 换模型、改切块策略 | 日常内容更新 |
也要和"缓存"分开：缓存优化的是同一个问题被反复问，索引新鲜度解决的是数据本身变了。
对从业者的实际意义
先问一句：这份数据多久变一次，变了之后多久必须能被检索到？答案是"一个季度"和"五分钟"，对应的架构完全不同。周更的 FAQ，每周重建一次就够；工单、价格、库存这类，得上事件驱动的增量更新。
对普通职场人来说，新鲜度事故很好识别：AI 助手还在引用上个月已经作废的报销标准。遇到"AI 说的和现行规定不一致"，第一反应不该是模型在胡说，而该问一句——索引最后一次更新是什么时候。