当你的 AI 功能过时：生产环境中的知识切断与时间溯源

你的 AI 功能在第三季度上线了。评估结果看起来不错。用户很满意。六个月后，满意度评分下降了 18 分，但你的仪表盘依然显示 99.9% 的可用性和低于 200 毫秒的延迟。没有任何地方看起来坏了。从传统意义上讲，也没有任何地方真的坏了。模型在响应，基础设施很健康。只是这个功能在悄无声息地出错。

这就是生产环境 AI 系统中“时间衰减”（temporal decay）的样子。它不会通过报错来提醒你。它以模型所知与现实世界现状之间的差距形式不断累积——等到你的支持队列反映出这一点时，损害已经持续数月之久。

知识截止并非单一的时间点

“知识截止”（knowledge cutoff）这个词暗示了一个清晰的界限：模型知道日期 X 之前的一切，而对之后的事情一无所知。现实情况则更加复杂，也更加危险。

训练语料库是异质的。一个模型的有效知识边界取决于你询问的是哪个子领域。对主要前沿模型的研究发现，即使在同一个模型内部，不同子资源（sub-resource）的有效截止日期也有显著差异。一个标榜知识截止到 2024 年 12 月的模型，在通用新闻方面可能确实能达到 2024 年，但在你特定的监管领域，有效截止日期可能仅为 2022 年，因为该领域的内容在训练数据中代表性不足。

这意味着你在营销文案中看到的截止日期，并非你的功能实际在使用的截止日期。寻找真实边界的方法是经验主义的：构建一套与特定日期挂钩的已知答案的小型探测问题集，在部署时运行，并测量准确率下降的位置。供应商不会告诉你这些，但你的用户最终会告诉你。

除了初始的截止日期，还有一个更缓慢的次生问题：时间对齐（temporal grounding）。对多代大语言模型（LLM）的研究发现，与绝对日期查询相比，日期相对查询（date-relative queries）的准确率下降了 23–35%。当用户询问“HIPAA 合规性最近有什么变化？”时，模型必须推理出什么算作“最近”，将其锚定在它对当前日期的理解上，并据此检索信息。这三个步骤都是潜在的失败点。模型会系统性地错估相对时间参考，因为它们对“现在”的训练信号是被冻结的。

为什么这会悄无声息地失败

传统监控对时间衰减是盲目的，因为它测量的是系统行为，而非回答质量。你的 APM 仪表盘关注的是错误率、延迟百分位数和 Token 吞吐量。当你的模型对截止日期三个月后发生的调价给出陈旧回答时，这些指标都不会发生波动。

生产事故的失败模式是一致的：系统显示 99% 的可用性，同时提供错误的信息，唯一的信号是用户信任的逐渐瓦解。一家家电制造商的 AI 客服机器人（运行在不了解更新后的维修流程的模型上）将多套指令集组合成了语无伦次的指导。系统在每个可观察的指标上都显得很健康，但用户就是无法按照维修步骤操作。

这正是时间衰减比大多数生产故障更危险的地方：它是一个语义问题，而非运维问题。你现有的告警基础设施是围绕运维异常构建的。

有三类问题在没有新鲜度处理的情况下，不应直接路由给原生 LLM：

• 政策与合规性问题：税法、监管要求、许可条款——这些都有明确的日期，且实质内容变动频繁。
• 现状问题：市场价格、产品可用性、公司信息、人事变动。
• 相对时间问题：没有明确日期锚点的“最近”、“当前”、“最新”、“新”。

如果你的功能预期用途包含其中任何一类，你就面临时间对齐风险。

检测由截止日期引起的故障

检测需要你在现有的运维指标之外增加质量评估。以下三种方法在不同的成本点上都行之有效。

探测查询 (Probe queries)。创建一小组具有可验证答案的日期锚定问题：即在模型截止日期之后发生的变化。将这些作为“金丝雀”（canary）与常规流量并行运行，并跟踪准确率随时间的变化。随着世界与截止日期的偏离越来越远，金丝雀的准确率应呈预测模式下降。剧烈下降可能预示着特定领域的时效性已实质性恶化。

时间异常检测。在你的应用程序中增加监测，以检测用户查询何时包含时间性词汇（如“当前”、“最近”、“截至今天”），并标记这些请求进行质量抽样。询问时间相对问题的用户是受截止日期失效影响风险最高的人群。对一定比例的此类请求进行人工或自动化审核，并跟踪正确回答与陈旧回答随时间变化的比例。

检索管道中的新鲜度评分。如果你正在使用 RAG，你的检索层应在相关性分数之外输出新鲜度元数据。对于询问“当前最佳实践”的查询，8 个月前更新的文档与询问基础概念的查询相比，应具有不同的权重。在检索时进行陈旧度评分（计算更新后的天数除以该文档类型可接受的更新频率），为你提供了一个具体的告警指标。当检索到的文档平均陈旧度超过阈值时，就是一个值得叫醒相关人员处理的信号。

LLMLagBench 的研究方法为生产抽样提供了一个系统的补充：通过从新闻档案中构建密集的时间探测集，你可以精确识别模型性能发生拐点的位置——不仅是官方的截止日期，还有每个领域实际的有效边界。

RAG 无法自动解决这个问题

团队通常将 RAG 视为显而易见的解决方案：如果模型的知识是静态的，就增加检索功能，使其能够访问新鲜信息。这种直觉是正确的，但 RAG 引入了其特有的时间性故障模式，而大多数实现都忽略了这一点。

向量索引会衰减。 当你在索引时对文档进行嵌入（embedding）时，这些嵌入反映的是该时间点的文档内容。如果政策文档更新了，旧的嵌入仍留在索引中，检索到的将是过时的内容。如果没有显式的索引维护，你的 RAG 系统积累“时间债务”的速度，正等同于源语料库的变化速度。

过时问题之所以严重，是因为它是隐形的。检索成功了 —— 你得到了文档，评分看起来很正常 —— 但返回的文档可能是 14 个月前最后更新的，而它们描述的政策在此期间已经修订过两次了。

将向量索引视为动态基础设施而非一次性 ETL 任务需要：

• 计划性过时扫描。 每天（或者对于高波动领域更频繁地）根据适用于该文档类型的过时阈值扫描已索引的文档。法律文件可能有 30 天的阈值；定价数据可能需要每小时扫描。超过阈值的文档将被标记并从活动检索中移除，直到它们经过重新认证或更新。
• 变更数据捕获（CDC）集成。 如果你的真相源数据存储在数据库中，请将索引更新视为该数据库变更日志的下游。当源文档发生变化时重新生成嵌入，而不是按照可能错过突发变化的固定时间表进行。
• 增强层中的新鲜度元数据。 在根据检索到的片段构建提示词（prompt）时，将源时间戳与内容一并包含在内。“根据 2026 年 4 月更新的文档……”能为模型和用户提供单纯内容无法传递的信息年龄信号。

没人会问的发布设计问题

大多数时间性故障在发布前跳过的需求分析中是可预见的。六个月后，它们看起来就像是无声的回归。在发布前值得问的三个问题：

该功能的正确答案的时间跨度是多少？ 回答关于基础软件架构概念的功能可以容忍 2 年前的模型，且只需极少的新鲜度处理。但回答关于供应商定价、监管合规或市场状况的功能则不行。在决定架构之前，将你的功能查询类型映射到预期的信息半衰期。

你的提示词中“今天”在哪里？ 在系统提示词中显式注入当前日期是许多团队都会跳过的基础干预措施。如果没有它，模型就没有相对日期推理的锚点。研究表明，直接注入日期有助于处理显式调用当前日期的查询，但对于因果推理链条来说还不够 —— 一个被告知“今天是 2026 年 4 月”的模型可能仍会将其对“近期进展”的理解锚定在其训练数据期间。日期注入是入场券，而非完整的解决方案。

你将如何知道功能何时降级？ 在发布前而非发布后定义你的时间质量 SLO（服务水平目标）。选择一组与你关注的领域相关的金丝雀查询（canary queries），建立基准准确率，并设置告警阈值。如果你在发布时没有定义这些，那么你第一次知道功能降级的时候，就是用户不再信任该功能的时候。

截断感知的查询路由

对于服务于多种查询类型的系统，路由比统一的 RAG 增强更具针对性。决策逻辑比看起来要简单：

• 时间无关查询 —— “解释 CAP 定理”、“什么是 B 树索引” —— 可以安全地交给原生 LLM，无需新鲜度处理。这些答案不会改变。
• 慢变查询 —— “数据库模式设计的最佳实践” —— 受益于低频率索引刷新的可选 RAG。以月为单位的漂移很重要，但以周为单位的漂移通常不重要。
• 快变查询 —— “当前的 AWS S3 定价是多少”、“上季度 GDPR 执行情况有何变化” —— 需要高频率索引更新的 RAG，并且通常受益于显式的弃权逻辑：如果检索到的内容超过了新鲜度阈值，宁愿拒绝回答，也不要自信地回复过时数据。

这种路由的基础设施不需要很复杂。在进入的查询上使用一个轻量级的分类器，标记时间敏感度 —— 时间无关、慢变、快变 —— 并在生成前对检索结果进行过时检查，这对于大多数应用来说已经足够了。

大规模监控时间健康度

一旦你在 RAG 流水线中有了新鲜度检测手段，时间健康度就成了与延迟和错误率同等重要的一级指标。至少要跟踪以下指标：

• 检索时的平均文档年龄：实际用于响应的文档的平均新鲜度
• 过时违规率：返回文档超过其领域特定新鲜度阈值的检索百分比
• 金丝雀探测准确率：每周对照你的锚点查询集进行测量
• 时间敏感查询量：包含时间性语言的流量占比，作为风险暴露的领先指标

当任何领域的过时违规率超过阈值，或金丝雀探测准确率比发布基准下降超过 N 个点时，进行告警。这两个信号结合在一起，可以在用户报告之前捕获大多数由模型截断引起的问题模式。

底层思维模型

这种有益的转变在于将知识新鲜度视为基础设施，而非内容。你的向量索引需要一份操作手册（runbook）。你模型的有效知识截止时间（cutoff）需要进行经验衡量和逐领域的跟踪。你的监控系统在运行指标之外，还需要质量指标。

采用这种模型的 AI 功能开发团队往往能在金丝雀数据（canary data）中发现时序性失效。而不采用该模型的团队，则会在用户投诉中发现这些问题——而那时距离能够干净利落地修复问题的窗口期已经过去了六个月。

好消息是这些模式已经存在，并不算罕见，且大部分工作在于埋点检测（instrumentation）而非开创性的工程研发。坏消息是，当你第一天发布 RAG 系统时，这些都不会自动发生。你必须有意识地回头去补齐它们——这比在首次部署前就加入要困难得多。