1. 契机——AI 写下了”639″，而实际数量是 0 #

不久前，我们的本地 LLM 在自动生成的监控报告中写下了”639 次认证失败”。当我们实际核查日志时，该时间窗口内的认证失败次数却是0。LLM 只是凭空生成了一个看起来合理的数字（我们在《本地 LLM 捏造监控报告数值事件及其对策》一文中记录了这一插曲）。

这并非 LLM 的缺陷，而是它的本性。LLM 擅长生成”在上下文中看起来合理的文本”，但它没有内置任何机制来保证”数字在事实上是准确的”。它常常能写出正确的数字，但那并非因为正确性得到了保证——只是碰巧对了而已。

在 AI Ops 中，这一点不容忽视。一份无法信任的监控报告形同虚设，甚至更加危险。如果有人相信”639 次认证失败”并据此采取行动，就会把时间花在一个根本不存在的问题上。反之，真正的异常则可能被掩盖。

因此，我们构建了一套不会盲目信任 LLM 所写数字的机制——幻觉审计。本文介绍其实现背后的思路。

2. 原理——事实不是由 LLM 制造的，而是由日志制造的 #

审计的出发点，是角色分离。

监控报告中出现的”事实”——数字、计数、IP 地址、时间戳——并非来自 LLM 的文本生成，而是来自对真实设备日志的确定性查询。LLM 的角色仅限于将已确认的事实措辞为人类易于阅读的文本。

• 事实（数字、对象、时间戳） → 由针对日志的查询得出（事实依据）
• 叙述（摘要、说明、行文） → 由 LLM 生成

仅这一层分离，就大大减少了捏造的空间。让 LLM”阅读日志并计数”很容易导致数错（即捏造）；但如果先聚合出计数结果，把已确认的数值交给它，再让它”用这些数字来说明情况”，数字就不会再变动了。

3. 通过”审计”捕捉仍然可能残留的捏造 #

即使角色已经分离，LLM 在撰写时仍可能悄悄夹带未被提供的数字，或搞错对象。因此，我们设置了一个审计步骤：在输出生成之后，再次将 LLM 生成的报告与源日志进行交叉核对。

大致流程如下。

1. Aggregate logs to build the "confirmed facts"       <- ground truth
2. Hand the confirmed values to the LLM to generate the report text
3. Extract the quantitative claims from the generated report
   (e.g., "N authentication failures on host A")
4. Cross-check each claim against the source logs (the confirmed facts in step 1)
5. If an unsupported or contradictory claim is found,
   replace it with the confirmed value, or regenerate the report
6. Record every detected mismatch (when, where, what was fabricated)

这里有两个关键点。

交叉核对是确定性的。我们不会让另一个 LLM 来做匹配。用一个自身也可能产生幻觉的东西去审计幻觉，是没有意义的。交叉核对是针对一个不可动摇的事实——源日志——所做的机械式检查。

验证的单位是"声明"。与其事后从自由文本中提取数字，不如让 LLM 从一开始就以易于验证的结构（"对象 / 指标 / 数值"三元组）输出，这样匹配就会稳健得多。我们关注的不是行文的形式，而是每一条声明是否有事实依据支撑。

匹配示例（数值仅用于说明）：

[AUDIT] report_id=████
  claim: host=A  metric=auth_fail  value=639
  truth: host=A  metric=auth_fail  value=0
  => MISMATCH  (replace with confirmed value / regenerate)

  claim: host=B  metric=port_scan  value=47
  truth: host=B  metric=port_scan  value=47
  => OK

4. 这并非是要"让 LLM 变得更聪明" #

这是设计理念上的关键所在。幻觉审计并不是试图让 LLM 变得更聪明或更准确的方案。在不改变"LLM 会犯错"这一前提的情况下，它让输出变得可信，靠的正是结构本身。

即使 LLM 写错了数字，它也会在审计中与事实依据进行交叉核对，因此最终报告中的数字是有保证的。我们把信心托付的对象，不是 LLM 的聪明程度，而是验证机制本身。

5. 设计上的取舍（坦率地说） #

这并非万能药。

1. 成本会增加。聚合、生成、审计这几道工序会增加处理步骤。尽管如此，我们认为在生产环境的监控报告中，"可信"这一价值值得付出这样的成本。
2. 它所能捕捉的，是"事实与数量"层面的捏造。诸如"认证失败次数"这类可验证的声明可以被交叉核对，但像"这一趋势看起来很危险"这样的主观叙述，其有效性很难通过机械方式验证。正因如此，我们才将 LLM 的角色限定于摘要与格式化，并将其设计为不做判断。
3. 它假定事实依据本身是正确的。审计建立在"源日志即为事实"这一前提之上。日志采集本身的准确性，以及设备层面判定的准确性，正是其基础（采集与自动判定机制在其他文章中另有介绍）。

6. 与 BASTION 根本理念相同的原则 #

这种"不信任 LLM 所写数字"的立场，与 BASTION 整体的设计理念是一脉相承的。

真正驱动系统行动的决策——对攻击 IP 的最终判定、执行防火墙阻断——并非由 LLM 做出，而是基于真实设备日志的确定性判定（多层关联攻击活动检测机制）。LLM 擅长的是自然语言的摘要与格式化，而非生产环境中的决策——这条界线，正是我们在《设计越精美，越要用真实数据去怀疑》一文中所描述的验证纪律

幻觉审计将同样的原则应用到了报告层。无论是 LLM，还是（可能已被攻陷的）Agent，对我们而言都是需要"不信任、且加以验证"的对象。

7. 总结 #

我们将 AI 委托处理的范围越广，"如何验证 AI 的输出"就越决定着产品的可信度。

• 事实（数字）不是由 LLM 制造的，而是取自日志
• LLM 所写的声明，会在输出后与事实依据进行交叉核对
• 交叉核对是确定性的。切勿用幻觉去审计幻觉
• LLM 的角色被限定于摘要与格式化，它不做判断

不要囫囵吞下 LLM 所写的数字。这并不起眼，但它是在生产环境中放心运行 AI Ops 的基础。