本地LLM捏造监控报告数值的事件及其对策

本地LLM捏造监控报告数值的事件及其对策

2 min read

2026.04 / Tech Blog / BASTION

本地LLM在监控报告中捏造数值,以及我们的应对方法 #

BASTION 的 AI 监控报告中写着”发生了639次认证失败”。而实际上是0次。这是一份关于我们如何应对本地LLM在安全监控中不可避免的幻觉问题——通过抽样核对与多层回退机制——的记录。

当AI说谎时 #

BASTION 每15分钟使用本地LLM分析基础设施日志,并向Slack发送报告。有一天,报告中写着这样的内容:

incoming-webhook 17:08

在Windows AD中,发生了大量认证失败和账户锁定,但由于Kerberos计算机账户和LDAP集成的原因,这属于正常现象。在VPN方面,OpenVPN发生了239次认证失败。

639次认证失败。239次VPN认证错误。仅看这些数字,你可能会判断为”异常”。

然而,当我们直接对实际日志进行统计后,发现认证失败仅有81次,VPN认证错误仅有102次。进一步调查后发现,我们传给LLM的输入数据中明确写着”认证失败:0次”和”VPN错误:无”。LLM竟将输入的”0″改写成了”639″。

抽样核对方法 #

为了验证报告中的数值是否正确,我们通过直接统计实际日志并与报告数值进行比对,实施了抽样核对。

Inspection procedure:
1. Extract numerical values in the report by item
2. Obtain actual measured values by directly grep/counting actual logs on the AI-SLOG server
3. Calculate the deviation rate between reported and measured values
4. Judgment: within ±10% is "pass," beyond that is "requires investigation"

对8个项目进行核对的结果:

项目 报告数值 实际数值 判定
FW拦截(特定IP) 477件 489件 ✅ 通过(+2.5%)
认证失败 639件 81件 ❌ 捏造(-87%)
账户锁定 669件 66件 ❌ 捏造(-90%)
认证错误 239件 102件 ❌ 捏造(-57%)
云应用全部项目 无数据 0件 ✅ 通过

在8个项目中,有4个检测到了幻觉(数值捏造)。

两个根本原因并存 #

为了厘清原因,我们检查了”传给LLM之前的输入数据”。

根本原因A:脚本传递了错误的数据。日志汇总脚本对部分设备传给LLM的数据并非”最近60分钟”,而是”全部时段的累计数据”。由于该脚本是通过统计文件的总行数进行计算的,因此长达数月的累计数据被当作”最近60分钟”传入了LLM。
根本原因B:LLM将”0件”改写成了”639件”。即使输入数据中明确写着”认证失败:0次”和”VPN错误:无”,LLM仍然生成了完全捏造的数字:639、669、239。即使将temperature设为0.2,也未能防止这一问题。

根本原因A是脚本的bug(可以确定性地修复)。根本原因B则是LLM本身的根本性局限。

对策:三层回退机制 #

我们没有采取”防止”LLM幻觉的思路,而是采取了”检测并替换”的方案。

第1层:确保输入数据的准确性 #

我们修复了脚本的bug,改为只将最近60分钟的数据传给LLM,而不是全部时段的累计数据。当输入正确时,LLM生成正确输出的概率也会提高。

第2层:通过提示词禁止数值捏造 #

我们在LLM的提示词中添加了以下规则:

【Absolute Rules for Numerical Values】
- Do not write any numerical values not present in the input data anywhere in the output
- Items marked as "0 cases" in the input must also be marked as 0 cases in the output
- Numerical values in the evidence section are permitted only as direct transcription from input data
- Speculation, completion, and approximation are prohibited

第3层:通过将输出数值与输入进行比对来检测差异 #

在LLM生成输出之后,我们实施了一个回退机制,将其与输入数据进行比对以检测矛盾之处。如果输入中标记为”0次”的项目在输出中显示为非零值,就会自动替换为安全文本。

Input: "authentication failures: 0 times"
LLM output: "639 authentication failures occurred"
  → Verification: Input is 0 times but output is 639 → Mismatch detected
  → Replacement: Automatically replaced with safe text

修正结果 #

实施三层回退机制后,我们在相同条件下再次进行了验证。

项目 修正前 修正后
认证失败(输入:0件) ❌ 639件(捏造) ✅ 0件(准确)
账户锁定(输入:0件) ❌ 669件(捏造) ✅ 0件(准确)
认证错误(输入:无) ❌ 239件(捏造) ✅ 0件(准确)
幻觉检测回退机制 仅能检测新造词和符号 也能检测数值捏造

LLM遵循了提示词规则,正确维持了零值,幻觉检测回退机制也未被触发。通过确保输入准确性(第1层)与强化提示词(第2层)的组合,问题在依赖第3层检测回退之前就已经解决。

幻觉无法被完全消除 #

虽然这一对策抑制了数值捏造,但使用140亿参数的本地模型是不可能完全防止幻觉的。关键不在于”信任LLM”,而在于通过设计来”约束LLM”。通过输入准确性保障→提示词约束→输出后验证这三层回退机制,可以防止LLM的误判在整个系统中蔓延。

定期抽样核对必不可少 #

此次幻觉正是通过抽样核对首次被发现的。LLM的输出在语法上是正确的,语境上也很自然——仅凭阅读是无法判断其为虚假信息的。将日志与报告进行比对的定期抽样核对纳入运维流程,对于AI监控系统的质量保证而言必不可少。

Agent工作流设计决定一切 #

在BASTION中,我们将LLM的作用限定为”日志模式分类判断”,而防火墙操作、数值统计、拦截执行则全部由shell脚本和Python处理。即使LLM捏造了数字,实际的拦截决策也是由脚本端的阈值决定的,因此业务影响仅限于通知文本不准确。如果我们让LLM直接编写防火墙规则,我们可能会因为虚构的攻击而拦截了真实的IP。

总结 #

在使用本地LLM进行安全监控时,LLM将输入的”0件”捏造为”639件”,出现了幻觉。根本原因是脚本bug(混入了全部时段的累计数据)与LLM数值捏造两者并存所致。

作为对策,我们实施了三层回退机制:输入数据准确性保障→通过提示词进行数值约束→输出后验证检测。修正后的再次验证确认,LLM准确地维持了零值,且未触发幻觉检测回退机制,验证了该对策的有效性。

AI监控并非万无一失。与其信任AI的输出,不如对其加以约束、验证并准备回退方案,这才是关键所在。这一设计理念正是在本地LLM环境下实现实用化安全监控的基石。

BASTION 在封闭网络中实现AI安全监控。

BASTION 服务页面
联系我们

Updated on 2026年6月9日

What are your feelings

  • Happy
  • 常规
  • Sad

©2020 BESTNET.LLC . All Rights Reserved.