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