检索的「新鲜度」治理：增量索引与过期标注

只在一开始读一遍文档，检索会逐渐给过期答案。本文给出增量索引的四个要点、过期标注的四种做法、该观测的三个指标（索引滞后/过期命中/删除残留）、两个常见坑与落地顺序。

检索的"新鲜度"是持续问题

文档在更新、产品在改版、政策在变。检索系统如果只在"建库时"读一遍 ✗，

就会逐渐给出**过期答案** ✗，而且很难被发现 ✗（用户只看到"答案不对"，看不到"资料是去年的" ✔）。

新鲜度治理有两件事：**增量更新**与**过期标注** ✔。

**按变更源驱动**：文档更新 → 只重跑受影响文档的解析/切分/嵌入 ✔；

**保留文档版本**：每次变更生成新版本，索引里记录 `doc_version` ✔；

**删除要同步**：文档下线必须从索引移除 ✔（否则会检索到已删除内容 ✗）；

**全量重建定期做**（例如每月 ✔）用于纠正长期漂移 ✔。

全量重建要**能并行灰度**（新索引与旧索引并存，切流后再删旧索引 ✔），否则重建窗口就是事故窗口 ✗。

很多内容不是"错"，而是"旧" ✔。做法：

索引里带**发布时间**与**有效期**（若有 ✔）；

检索结果**按时间排序或加权**（见排序那篇 ✔）；

回答里**标注时间** ✔： "该说法来自 2024-03 的文档" ✔；

超期内容**降权但不删除** ✔（历史信息仍可能有用 ✔）。

**关键是让用户看到时间** ✔ —— 而不是让系统"假装资料是新的" ✗。

1. **索引滞后时间**（文档更新到可检索的延迟 ✔）—— 这是最实用的新鲜度指标 ✔；

2. **过期命中率**（检索命中超过 N 天的片段占比 ✔）；

3. **删除残留**（抽查已下线文档是否还能被检索到，应为 0 ✔）。

**只更新正文不更新元数据** ✗ → 排序与筛选用的时间字段仍是旧的 ✔；

**重建索引时忘了清缓存** ✗ → 用户仍拿到旧答案 ✔（缓存键要含索引版本 ✔，见缓存与可复现那两篇 ✔）。

1. 先给索引加 `doc_version` 与 `published_at` ✔；

2. 做按变更的增量更新（先做"新增/更新"，删除随后 ✔）；

3. 回答里加时间标注 ✔；

4. 加索引滞后时间指标与删除残留的定期抽查 ✔。

> 随机抽 10 条回答，能否说出每条依据的**资料时间** ✔？

> 说不出，就说明"时间"还没有进入检索与展示链路 ✗。