公开幻觉应对指南：当你的 AI 在公众场合说出蠢话时该怎么办

你会通过一张截图发现它。

客户会把它发出来，记者会引用它，或者团队里的某个人会在晚上 11 点在 Slack 上给你发个链接。你的 AI 系统言之凿凿地给出了错误的答案 —— 错到滑稽，或者错到可能伤及他人 —— 而且现在已经公开了。

大多数工程团队花费数月时间强化他们的 AI 流水线以防这一时刻的到来，却发现他们从未计划过一旦这一时刻到来该怎么办。他们知道如何迭代评估（evals）和调整提示词（prompts）。他们不知道该由谁来发布回复推文，该回复应该说些什么，或者如何区分是一次性的倒霉样本，还是已经在生产环境中运行了数周的潜在故障模式。

这就是针对那一刻的应对指南。

无人预先划定的界限

当幻觉公开化时，需要同时解决两个并行的问题：技术上发生了什么，以及你在公开场合对此说些什么。这两者不是同一项工作，混淆它们是大多数团队跌倒的地方。

沟通问题本质上是信任问题。用户和媒体想知道你是否知情、是否在意，以及是否会再次发生。他们不想听技术复盘 —— 至少现在不想。他们首先想要的是承认。在发布任何公开声明之前，花费第一个小时诊断根本原因是一个常见的错误；利益相关者会用他们自己的解读来填补这段沉默。

工程问题是一个诊断问题。这只是随机采样带来的偶然现象，还是你的系统在这一类查询中已经胡编乱造数月了？答案决定了后续的一切 —— 是简单的提示词修复就足够，还是你面临的是一个重新训练周期。在诊断之前就急于修复是另一个常见错误；团队发布的补丁只解决了特定公开故障的症状，而没有触及潜在的模式。

大多数团队犯的错误是将整个问题分配给一个人或一个团队。正确的结构是两条在定义好的检查点同步的并行轨道：

• 轨道 1（沟通）：发布临时声明，处理媒体和用户咨询，保持公开的沟通节奏。
• 轨道 2（工程）：复现故障，归类其根本原因，界定其影响范围。

两条轨道立即启动。它们共享一个状态频道。谁也不等谁。

故障分级：在动任何代码之前先对故障进行分类

在编写修复方案之前，你需要了解这是哪种故障。工程分类至关重要，因为补救路径很快就会分道扬镳。

一次性采样噪声：多次运行相同的提示词。如果错误输出只是偶尔出现，且语义熵（semantic entropy）很高（不同运行之间的响应差异巨大），那么你面对的是采样随机性。模型处于其分布中偶尔产生此类输出的部分。这是最不令人担忧的一类，但也最容易被误分类 —— 一个有 5% 概率出现此输出的提示词可能自上线以来就一直在运行。

系统性提示词问题：运行原始提示词的变体。如果错误输出在特定的表述或主题类别中可靠地复现，但在其他情况下不复现，那么故障出在提示词设计上 —— 缺失约束、上下文窗口未明确说明，或者系统提示词无意中诱导了故障。这是早期生产系统中最常见的根本原因。

训练数据污染：如果幻觉在同一领域的多个不同提示词中出现 —— 特别是如果模型对特定领域的特定事实类别言之凿凿地出错 —— 你处理的可能是训练阶段的问题。模型习得了一个错误的信念。提示词工程无法修复这个问题；检索增强（RAG）或微调才是解决之道。

RAG 检索故障：如果你的系统使用检索增强生成（RAG），而模型生成了一个听起来很合理但没有任何检索文档支持的答案，那么故障出在检索层。模型的生成质量没问题；它是在错误的 grounding 上下文中工作，或者在应该有上下文时却完全没有。

语义熵是最快的第一轮诊断工具。在 temperature > 0 的情况下运行标记的查询 20 次。如果响应高度聚合，则很可能是系统性问题（根本原因 2–4）。如果它们很分散，则很可能是采样噪声（根本原因 1）。无论哪种方式，你都还没有得到全貌。

第二步是日志溯源。在你能有把握地确定根本原因之前，你需要原始事件的推理日志：包括系统提示词在内的完整提示词、如果涉及 RAG 的检索上下文、确切的补全结果，以及理想情况下的 token 级 logprobs（对数概率）。如果你的观测栈在推理时没有捕获这些，分级诊断将会变慢且缺乏说服力。这值得在你的事后复盘中记录下来：事后重建事件的能力取决于你在此之前部署了什么样的监控。

公开场合该说什么（以及不该说什么）

预声明（holding statement）是你的公关流程中需要发布的第一项内容，理想情况下应在确认事件后的 60–90 分钟内发布。它的作用非常有限：承认你已经知晓了该输出结果，传达你对此高度重视，并承诺会有后续跟进。

它绝对不该做的事：

• 承诺具体的工程修复。你还不知道根本原因。承诺一个你无法交付的修复会加剧损害。
• 声称它“不会再次发生”。它可能会。在这里，认知谦逊（epistemic humility）并非软弱——过度自信后再次发生故障才是。
• 轻视输出结果。即使你觉得这个故障无害或有趣，经历它的用户可能并不这么认为。
• 深入探讨技术细节。技术解释属于事后复盘（postmortem），而不属于预声明。

一个适用于大多数事故类型的预声明模板：

我们已经注意到今天在社交平台上分享的 [产品/功能名称] 产生的非预期输出。我们对此高度重视。我们的团队正在调查发生的原因，并将在 [具体时间] 前分享更全面的更新。如果你受到影响，请联系 [联系方式]。

三个要素使其生效：它足够具体以建立公信力（你点名了产品），它不对根本原因进行猜测，并且它承诺了时间表。承诺时间表很重要——如果没有它，声明读起来就像是在推卸责任。

后续沟通应在工程团队找到根本原因后进行。这才是提供技术解释的时机。要具体：“由于我们的系统提示词（system prompt）没有考虑到 X 导致了这种情况”比“这是一个罕见的边缘案例”更好。含糊其辞的解释看起来像是在掩饰。

不同受众需要不同的版本。内部团队需要完整的技术复盘。客户支持需要一个简短、通俗易懂的版本。公开声明应介于两者之间——对发生的事情保持诚实，同时不需要读者理解 Transformer 架构。

事故后评估：防止同样的截图出现第二次

公开幻觉事件最持久的产物不是你发布的修复，而是你添加到回归测试套件（regression suite）中的评估案例，它让该失效模式无法在未被检测的情况下再次进入生产环境。

每一次生产环境的故障都应转化为至少一个评估案例：原始查询（或一组语义等价的查询）、预期输出，以及一个能够区分可接受响应与失效模式的评分器（grader）。评分器可以是一个简单的关键词检查、一个正则表达式、一个带有评分标准的第二个 LLM 裁判，或者人工标注——其形式并不如它在 CI 中运行这一事实重要。

引用准确性值得拥有独立于通用事实准确性的跟踪。团队经常在引用幻觉依然存在的情况下提高了整体事实准确性指标——模型产生了看起来合理但没有任何检索文档支持的断言。这些问题很难通过聚合指标捕捉，但很容易通过有针对性的引用可靠性检查（citation-grounding checks）捕捉。

对于 RAG 系统，上述失效分类意味着不同的评估系列：

• 检索质量评估：系统是否在应该检索到相关文档时检索到了？当文档不存在时，它是否能识别？
• 可靠性评估（Grounding evals）：生成的响应是否保持在检索内容的范围内？
• 分布外评估（Out-of-distribution evals）：当用户提问的内容超出了检索语料库的范围时，系统会产生什么？

事故发生后也是审计你的 AI 开发时间中有多少百分比投入到了评估基础设施的好时机。生产级 AI 系统的基准是大约 30–40% 的工程精力投入在测试和验证上。大多数在这一阈值之下运作的团队都是在透支时间。

最后：在发布任何修复之前，针对该事故的查询运行你的回归测试套件。这确保了修复确实解决了失效模式，而不仅仅是被抓住的那个特定表述。针对特定表面形式进行提示词补丁（Prompt-patching）而保留底层模式是一个常见的陷阱——你通过了已知故障的评估，信心满满地发布，然后在三周后遇到了同一个故障的另一种表述。

在需要之前建立应对指南（Playbook）

能够妥善处理公开幻觉事件的团队都有一个共同特征：他们在事件发生前就排练过。这不需要正式的桌面演练（尽管它们很有帮助）。它需要提前决定：

• 谁发布预声明，谁在发布前进行审核？
• 谁负责工程问题的分级处理（engineering triage）？如果两小时内根本原因不明确，升级路径是什么？
• 重建事故需要什么样的日志和可观测性？是否已经就位？
• 后续沟通的 SLA 是什么？

公关与工程的界限是其中最难提前划定的部分，因为它看起来像是一个软性问题。其实不然。当截图开始疯传的那一刻，这两个职能部门都在时间压力下运作，而权责不明意味着两个团队都会等待对方先行动。在事故发生前，请在两个团队都阅读过的文档中以书面形式定义它。

好消息是 AI 系统进步神速。顶尖前沿模型（frontier models）的幻觉率已从四年前的 20% 左右下降到如今表现最好系统的 1% 以下。工程下限正在提高。但生产系统不仅仅是前沿模型——它们是模型加提示词加检索加应用逻辑，而失效模式会在每一层叠加。0.7% 的模型幻觉率加上 5% 的检索失败率，再加上一个会放大自信生成的提示词，会给你一个比任何单一组件都更容易失败的系统。

应对指南不会让幻觉消失。它确保当一个幻觉被公开时，你的响应更迅速、更有公信力，并且相比于仅仅解释当前的幻觉，它更有可能防止下一个幻觉的发生。

---

截图总会出现。唯一的问题是你的团队是否做了那些乏味的准备工作来妥善处理它——日志记录、评估基础设施、公关分工、演练。这些投资不会出现在演示（demo）中。它们会出现在某人发布截图后的那三十分钟里。