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

这种模式是在生成答案之前，通过快速路径对用户的问题进行分类：这是在询问事件、政策、价格、状态、人物职衔、软件 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）也是同样的道理，只不过是在一个迭代速度快三倍的技术栈中重演。模型的训练数据截止于某个日期。你的产品与该日期的关系是一个经过设计的表面——无论是有意设计还是无心之过，它终究是一种设计。选择第一种方案的团队交付的是经得起考验的助手。而选择第二种方案的团队，则会在第一个用户询问有关“上季度才更新的答案”的问题时，才发现自己交付了什么——而模型因为无从得知最新情况，依然会给出答案。