---
title: 本地LLM捏造监控报告数值的事件及其对策
description: "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…"
url: "https://bestnetllc.co.jp/zh-hans/docs/%e6%9c%ac%e5%9c%b0llm%e6%8d%8f%e9%80%a0%e7%9b%91%e6%8e%a7%e6%8a%a5%e5%91%8a%e6%95%b0%e5%80%bc%e7%9a%84%e4%ba%8b%e4%bb%b6%e5%8f%8a%e5%85%b6%e5%af%b9%e7%ad%96/"
updated: "2026-06-08"
category: Tech Blog / AI安全运营
---

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

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件 | ![✅](https://s.w.org/images/core/emoji/17.0.2/svg/2705.svg) 通过（+2.5%） |
| 认证失败 | 639件 | 81件 | ![❌](https://s.w.org/images/core/emoji/17.0.2/svg/274c.svg) 捏造（-87%） |
| 账户锁定 | 669件 | 66件 | ![❌](https://s.w.org/images/core/emoji/17.0.2/svg/274c.svg) 捏造（-90%） |
| 认证错误 | 239件 | 102件 | ![❌](https://s.w.org/images/core/emoji/17.0.2/svg/274c.svg) 捏造（-57%） |
| 云应用全部项目 | 无数据 | 0件 | ![✅](https://s.w.org/images/core/emoji/17.0.2/svg/2705.svg) 通过 |

在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件） | ![❌](https://s.w.org/images/core/emoji/17.0.2/svg/274c.svg) 639件（捏造） | ![✅](https://s.w.org/images/core/emoji/17.0.2/svg/2705.svg) 0件（准确） |
| 账户锁定（输入：0件） | ![❌](https://s.w.org/images/core/emoji/17.0.2/svg/274c.svg) 669件（捏造） | ![✅](https://s.w.org/images/core/emoji/17.0.2/svg/2705.svg) 0件（准确） |
| 认证错误（输入：无） | ![❌](https://s.w.org/images/core/emoji/17.0.2/svg/274c.svg) 239件（捏造） | ![✅](https://s.w.org/images/core/emoji/17.0.2/svg/2705.svg) 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 服务页面](https://bestnetllc.co.jp/zh-hans/bastion-4/)
 [联系我们](https://bestnetllc.co.jp/zh-hans/contact-4/)