RAG 知识新鲜度 SLO：不要只监控索引成功率

很多团队会监控“昨天的索引任务是否成功”，但用户真正关心的是“新政策发布后多久能被正确回答”。这两个指标不同：任务成功可能处理的是旧队列，源系统的 webhook 可能漏了，解析器也可能把新内容识别为空。知识新鲜度需要独立的 SLO 和证据链。

定义新鲜度的起点和终点

起点是源系统中内容真正可见的更新时间，不是爬虫发现时间。终点是新的、经过权限过滤的 chunk 可以被生产检索召回的时间。两者之差就是索引延迟。对于某些内容，还要加上答案刷新时间：如果缓存答案仍引用旧版本，索引更新并不等于用户已经得到新结论。

按内容风险设置不同目标。产品公告或普通帮助文档可以在数小时内更新；安全通告、价格、合规规则和故障 Runbook 可能要求分钟级。不要用一条全局 SLA 把所有来源平均掉，高风险文档被延迟时应自动提升优先级和告警级别。

能接 webhook 的源系统优先使用版本事件，并保留定期扫描作为漏事件兜底。没有事件能力的来源可以使用内容 hash、ETag、更新时间和 sitemap 差异检测，但要记录检测时间与源更新时间的差距。对于大量文档，先比较元数据再抓正文，避免每天全量解析造成不必要的成本。

同一文档短时间多次更新时，队列应合并到最新版本，而不是按顺序处理每一个中间版本。否则系统可能花大量时间索引已经过期的内容，并在最后才到达用户真正需要的新版本。版本比较和幂等写入是新鲜度系统的基础。

当检索到的证据超过允许新鲜度，系统可以标记答案可能过期、触发后台刷新、要求用户确认来源时间，或在高风险场景直接拒绝给出结论。不要让模型用旧资料回答“当前价格”“最新政策”这类问题，却不显示来源时间。

页面和 API 返回中包含来源更新时间、索引时间和版本信息。用户能看到答案基于何时的资料，支持团队也能快速判断问题是索引延迟、缓存延迟还是源系统没有更新。透明时间信息比“知识库已同步”这种笼统提示更可信。

定期按来源、内容类型和风险等级统计新鲜度 P50/P95、漏事件、解析失败、删除延迟和被用户标记为过期的答案。对超过 SLO 的来源做根因分析：是 webhook 不可靠、队列容量不足、解析器变慢，还是权限审核阻塞。每个问题都应有负责人和复测日期。

新鲜度 SLO 的价值在于把“知识库应该及时”变成可测的运营承诺。只有团队能看见从源文档变化到用户答案之间的全链路时间，RAG 才不会在内容规模增长后悄悄变成过期信息的放大器。

当高风险来源超过新鲜度 SLO，先停止把旧资料作为确定事实输出，再检查源事件、队列、解析和索引写入四个阶段。若无法在目标时间内恢复，可以临时将该来源标为“更新中”，引导用户查看官方页面或人工渠道。透明地承认资料尚未同步，比继续输出过期答案风险更小。

事后把延迟样本加入演练。模拟 webhook 漏发、队列堆积、解析失败和缓存未失效，验证告警是否真的能在用户受影响前触发。新鲜度不是一条仪表盘曲线，而是一套在异常情况下仍能保护用户的操作能力。

为每个来源指定内容 owner 和应急联系人。索引团队可以修队列和解析器，但只有来源 owner 能确认新政策是否已正式生效、旧版本是否必须立即下线。将责任写入来源配置和运行手册，才能让新鲜度告警在真实事故中得到及时处理，而不是停留在技术团队的待办列表。

在月度复盘中公布超过目标的来源和改进计划，让新鲜度从后台指标变成内容运营与产品团队共同负责的承诺。

对长期无法满足目标的来源设置替代策略：降低其在回答中的确定性、只展示原始链接、限制高风险问题使用，或暂时从检索集合移除。新鲜度 SLO 不应迫使系统假装资料可靠，而应帮助团队在资料不可靠时做出更安全的产品行为。

这些策略应定期复审并在来源恢复后解除。

恢复前通过抽样检索和人工复核确认新版本已经覆盖关键问题，再重新提升其回答权重。