检索的"新鲜度"是持续问题
文档在更新、产品在改版、政策在变。检索系统如果只在"建库时"读一遍 ✗，
就会逐渐给出过期答案 ✗，而且很难被发现 ✗（用户只看到"答案不对"，看不到"资料是去年的" ✔）。
新鲜度治理有两件事：增量更新与过期标注 ✔。
一、增量索引（不要每次全量重建）
- 按变更源驱动：文档更新 → 只重跑受影响文档的解析/切分/嵌入 ✔；
- 保留文档版本：每次变更生成新版本，索引里记录
doc_version✔； - 删除要同步：文档下线必须从索引移除 ✔（否则会检索到已删除内容 ✗）；
- 全量重建定期做（例如每月 ✔）用于纠正长期漂移 ✔。
全量重建要能并行灰度（新索引与旧索引并存，切流后再删旧索引 ✔），否则重建窗口就是事故窗口 ✗。
二、过期标注（比"删除"更实用）
很多内容不是"错"，而是"旧" ✔。做法：
- 索引里带发布时间与有效期（若有 ✔）；
- 检索结果按时间排序或加权（见排序那篇 ✔）；
- 回答里标注时间 ✔： "该说法来自 2024-03 的文档" ✔；
- 超期内容降权但不删除 ✔（历史信息仍可能有用 ✔）。
关键是让用户看到时间 ✔ —— 而不是让系统"假装资料是新的" ✗。
三、该观测的三个指标
- 索引滞后时间（文档更新到可检索的延迟 ✔）—— 这是最实用的新鲜度指标 ✔；
- 过期命中率（检索命中超过 N 天的片段占比 ✔）；
- 删除残留（抽查已下线文档是否还能被检索到，应为 0 ✔）。
四、两个常见坑
- 只更新正文不更新元数据 ✗ → 排序与筛选用的时间字段仍是旧的 ✔；
- 重建索引时忘了清缓存 ✗ → 用户仍拿到旧答案 ✔（缓存键要含索引版本 ✔，见缓存与可复现那两篇 ✔）。
五、落地顺序
- 先给索引加
doc_version与published_at✔； - 做按变更的增量更新（先做"新增/更新"，删除随后 ✔）；
- 回答里加时间标注 ✔；
- 加索引滞后时间指标与删除残留的定期抽查 ✔。
一条判据
随机抽 10 条回答，能否说出每条依据的资料时间 ✔？
说不出，就说明"时间"还没有进入检索与展示链路 ✗。