知识截止期是 UX 界面，而非脚注

模型有知识截止日期。用户不知道它是什么。产品在几乎所有情况下都不会告诉用户。当用户问了一个正确答案在三个月前已经改变的问题时，助手会给出一个言之凿凿的错误答案——这并非因为模型失效了，而是因为产品从未提供一种方式来标记这种信息鸿沟。你与用户之间的信任契约是隐性的、不对称的，并且每当世界发生变化而你的 UX 假装没有变化时，这种契约就会被悄然打破。

主流模式是将截止日期视为一个注脚：一段埋藏在帮助中心里的披露文本、一个无人阅读的 /about 页面，或者在第一周就被关闭的一次性工具提示。这种定位是一个 bug。知识截止日期不像“上下文长度”那样是模型的一个属性。它是一个 UX 界面——经过工程化、设计和演进——将其视为次要因素，会导致交付的产品在用户无法审计的语调下，围绕自身的无知进行编造。

这篇文章探讨的就是这个界面：为什么显而易见的定位会失败、答案的实际来源是什么，以及在下一次训练数据刷新再次改变标准之前，一支严肃的团队必须建立的设计原则。

“截止日期”是戴着同一个名字面具的三种不同鸿沟

团队交付错误 UX 的第一个原因是，“知识截止日期”被用来指代三种除了名称外毫无共同点的陈旧性差距。

• 训练截止日期 (Training cutoff)。发布的日期——例如 GPT-5.2 和 Claude 4.6 Opus 的“2025 年 8 月”，Gemini 3 的“2025 年 1 月”——在这之后，参数权重不再更新。这是你的帮助中心注脚所引用的日期。它也是整个技术栈中在操作层面最没用的数字。
• 每个主题的有效截止日期 (Effective cutoff per topic)。最近的研究追踪了每个维基百科条目、每个编程语言版本、每个新闻领域的有效截止日期，并发现它通常比报告的日期早几个月或几年。预训练中使用的 CommonCrawl 转储在时间上是不匹配的：2019–2023 年 RedPajama 转储中超过 80% 的类维基百科文档早于 2023 年，尽管转储本身是最近的。模型只有在那些近期内容真正按比例进入训练组合的主题上才“了解 2025 年 8 月”。对于长尾主题，有效截止日期可能比报告的早一年——而且模型无法告诉你针对面前的问题，具体是哪种情况。
• 索引截止日期 (Index cutoff)。检索系统有它自己的时钟。如果你的摄取任务在每天午夜运行，那么下午 2 点的文档更新的滞后时间长达 22 小时。如果每周运行一次，则长达 168 小时。如果是年度营销内容刷新，那么你运行的是一个过时一年的系统，却在演示文稿中称之为“实时 RAG”。

这三种差距是叠加的。一个询问“当前的退款政策是什么”的用户，得到的答案是由参数化知识（其有效截止日期取决于退款政策在预训练中出现的频率）、检索到的切片（其新鲜度取决于上次摄取任务运行的时间）以及模型对两者的推理组合而成的——而 UI 将所有这些呈现为一个答案，使用相同的字体、颜色和相同的置信度水平。

第一个值得做的设计决策是停止在你的规范文档中将“知识截止日期”作为一个单一概念。每一层都需要自己的名称、自己的负责人以及在产品中自己的展示界面。

来源有三类，而 UI 将其混为一谈

在新鲜度差距之下是更深层次的混淆：LLM 回复中的每个主张都来自三种来源之一，而 UX 几乎总是以相同的方式呈现它们。

• 检索 (Retrieved)。一段文字从你的索引语料库中提取出来，并与用户的问题一起展示给模型。其来源是具体的：文档 id、最后更新日期、段落范围。这是你可以引用的部分。
• 参数化 (Parametric)。该主张来自模型的权重——在预训练或微调期间记忆的事实。没有可以引用的文档。其“新鲜度”是该主题有效截止日期的函数，而模型本身并不知晓这一点。
• 推断 (Inferred)。模型结合了检索到的片段和参数化先验知识，产生了一个两者都不存在的主张。有时这是正确的综合，有时则是披着引用外衣的幻觉。UI 对它的展示与前两者相同。

一项 2025 年关于引用和 LLM 信任的研究发现，当回复包含引用时，用户的信任度会显著提高——即使这些引用是随机的。只有当参与者真正点击进入并核查时，信任度才会下降。合理的解释是：大多数用户不会核查，引用的视觉存在正在承担引用本身并未真正赢得的工作。如果你的 UI 不分青红皂白地引用所有内容——包括由貌似相关的 URL 包装的参数化和推断主张——你就是为答案中最不值得信任的部分构建了一个信任放大器。

修复方法是结构性的，而非风格上的。渲染输出中的每个主张在被 UI 看到之前，都需要被标记其来源类别：检索到的需带有真实的来源和真实的时间戳，参数化的需带有诚实的“来自训练数据，上次刷新于 [报告的截止日期]”标签，推断出的需带有明确的“综合”标注。模型是循环中唯一在生成时知道哪个是哪个的组件。事后通过将字符串与检索到的片段进行反向匹配来恢复这些信息，仅在模型逐字复制的情况下有效，而这种情况本就不需要帮助。

“世界是否依旧”预检

某些意图具有模型可以察觉的时效性，而一个廉价的预检关口（pre-flight gate）能在充满自信的错误答案交付之前，拦截其中令人惊讶的高比例。

这种模式是在生成答案之前，通过快速路径对用户的问题进行分类：这是在询问事件、政策、价格、状态、人物职衔、软件 API 还是市场状况？如果是，则执行单次 Grounding 检查——一次检索过程、一个工具调用或一个具备时效意识的系统提示词——然后才综合得出答案。如果没有任何新鲜来源可以支撑该主张，模型会被指示在答案中披露其知识截止日期，而不是将其掩盖。

预检的经济账非常关键。针对小模型的一次简短分类调用可能会增加约 80–150ms 的延迟，且单次请求成本微乎其微。相比之下，如果对一个已弃用的 API、过期的价格或一位在 9 个月前就离职的员工给出一个充满自信的错误回答，其代价是一个支持工单、流失风险，或者在受监管领域引发合规审查。当具有时效性的意图比例低于 1% 时，这种做法就能收回成本；而在客户支持工作负载中，这一比例通常接近 30%。

这个关口不是一个笼统的“对于任何时效性查询，一律拒绝回答”的规则。那是开发者们惨痛教训换来的失败模式：训练为过度倾向于拒绝回答的模型，在面对长尾问题时会变得毫无用处，而这些问题的参数化回答其实就足够了。OpenAI 自身关于模型幻觉原因的分析指出，标准的基于准确性的评估套件会惩罚谦逊并奖励自信的猜测——因此，根据这些评估训练出的模型具有强烈的“瞎编”倾向。预检关口正是产品团队基于每个意图覆盖这种倾向的地方，同时将误拒预算作为一级指标进行追踪。

时效性标注作为设计的视觉界面

如果出处（provenance）要变得可视化，那么视觉语言必须发挥实际作用。那些在用户实际使用中存续下来的模式往往具有几个共同属性。

• 行内显示，而非脚注。 段落末尾的时间戳几乎等同于不存在。在主张本身旁边放置一个小的“截至（as of）”徽章，点击或悬停可展开查看来源，这更容易被阅读，因为它打断了你注视该主张时的视觉路径。
• 三种状态，而非两种。 “已引用”对比“未引用”的粒度太粗。“已检索（上次更新于 X 天前）”、“来自训练数据（上次刷新于 Y 个月前）”以及“无 Grounding 的模型推理”是用户可以据此采取行动的三种可区分状态。前两者是你可以核实的主张；后者则是你应该视为假设的主张。
• 相对于问题的时效性，而非索引时效性。 如果文档早于你所询问的政策变更，那么“2 天前更新”虽然精确但毫无用处。最终落地的标注应该是“更新于 [问题隐含参考的事件] 之前 / 之后”——这要求系统从查询中提取时间锚点，而不仅仅是从文档中提取一个时效数字。
• 非对称语言应对非对称自信度。 关于信任校准的研究发现，第一人称的委婉语（如“我不确定，但是……”）能显著提高用户判断的准确性，因为它们引导用户进行核实。产品经理追求“愉悦感”而剥离委婉语的本能，实际上优化了错误的指标。一个错误率为 5% 的自信助手，其导致的用户结果比一个错误率为 5% 但带有委婉语的助手更差，因为用户是根据语气而非潜在的错误率来校准自己的预期。

评估 8 种 LLM 摘要不确定性表达惯例的视觉研究发现，最有效的惯例并不是最美观的，而是那些与用户即将做出的决策一一对应的惯例。一个显示“73% 自信度”的仪表盘只是装饰；而一个标注“此主张来自训练数据，可能已过时——请在你的 CRM 中核实”的标签则是一条指令。

保持界面诚实的评估规范

时效性 UX 不是一次性的交付。它是一个需要维护的特性，如果没有评估规范（eval discipline），它会像任何其他未维护的界面一样退化。

有效的评估包含三个组成部分，而大多数团队最多只具备其中之一。

• 固定的截止日期后意图集。 一组精心挑选的问题，其正确答案取决于模型知识截止日期之后发生变化的事实。正确的行为是显式披露（“我不知道——原因是……”），而不是给出充满自信的错误答案。这是发现参数化越权的评估方法。每当模型升级时，请重新基准化。
• 动态语料库检索评估。 一组问题的正确答案取决于最近更新的文档，评分标准是检索到的片段时效性是否与答案所声称的一致。这能捕捉到索引已过时、但模型仍根据预训练先验知识编造了一个自信时间戳的情况。它还能捕捉到反向情况：检索到的片段是新鲜的，但模型更倾向于陈旧的参数化回答，因为“检索抗性（retrieval-resistance）”本身也是一种已知的模型行为。
• 标注界面的校准评估。 抽样真实的生产环境追踪数据，为每个呈现的主张标注其真实出处，并根据事实真值（ground truth）为 UI 的标注评分。该指标是每个主张类别的标注准确率，并作为 SLO 进行追踪。当该指标出现偏差时，意味着界面在撒谎——通常是因为提示词的更改模糊了模型对检索输出与参数化输出的内部区分，而由于时效性 UI 看起来没变，所以没人察觉。

组织级的失败模式是显而易见的：提示词团队调优愉悦感，评估团队调优诚实度，获胜条件取决于薪水最高的人最后看了哪个指标，而界面则随着那周风向的变动而交付。解决方案是将校准评估提升到与延迟或错误率同等的地位——在任何提示词更改交付之前，该数值必须保持在范围内，并由专人负责。

知识截止日期是一项功能，只要你善用它

大多数 LLM 产品无意中传达出的信息是：“模型是全知全能的，请相信答案。”这是错误的，用户终究会发现这一点，而这种发现是一条单行道——一旦用户发现在他们可以验证的事实上，助手表现出“自信地胡说八道”，他们就会无限期地对那些无法验证的事实的信任度打折扣。修复这种信任崩塌比预防它要困难得多。

刻意传达的信息——“这是我检索到的内容，这是我记住的内容，这是我的推论，以及我的记忆截止日期”——在 Demo 中听起来可能没那么令人惊艳。但这也是一年后严谨用户依然会信任的唯一信息。构建展示这些信息的界面的成本是实实在在的：来源分类法、预检门控、标注语言、校准评估，以及当产品团队要求去掉这些限定性表述时据理力争的决心。而不构建它的代价则是信任的缓慢流失，没有任何仪表盘能追踪到这种变化，直到它最终体现在流失用户群中——这些人的退出访谈里都会充斥着类似“它听起来是对的，但事实并非如此”的抱怨。

在 2010 年代发布过 API 的工程师都明白，“端点行为”（endpoint behavior）并非仅仅是响应体所呈现的内容，而是你在版本迭代、弃用和边缘情况中维护的契约。“知识截止日期”（Knowledge cutoff）也是同样的道理，只不过是在一个迭代速度快三倍的技术栈中重演。模型的训练数据截止于某个日期。你的产品与该日期的关系是一个经过设计的表面——无论是有意设计还是无心之过，它终究是一种设计。选择第一种方案的团队交付的是经得起考验的助手。而选择第二种方案的团队，则会在第一个用户询问有关“上季度才更新的答案”的问题时，才发现自己交付了什么——而模型因为无从得知最新情况，依然会给出答案。