安全运营中的 LLM：高准确率为何仍漏报

LLM 做安全运营，既能拿到 98% 的告警分诊准确率，也能在另一场测试里漏掉 40.4% 的攻击。差距来自任务、数据和流程的变化，不能直接归结为模型强弱。

作者筛查了 378 条去重记录，提取 32 组定量比较，给出的结论很明确：LLM 适合整理非结构化信息、辅助调查和提出处置方案；高吞吐检测和自主执行动作，则需要严格限制。对正在做日志分析、告警助手或 AI Agent 的程序员，这篇最有价值的是帮你确定模型该放在哪一层。

先分清任务，再看准确率

安全运营中心（SOC）的工作至少要拆成四类：检测判断事件是否恶意；分诊决定告警应该呼叫值班人员、创建工单还是忽略；调查还原事件经过及关联；响应决定采取什么动作，以及谁有权执行。

它们需要的能力不同。检测面对海量事件，关心误报、漏报和延迟；分诊受团队政策影响；调查要求证据完整；响应还必须衡量克制程度。安全知识选择题得分再高，也不能证明模型能读懂你们的日志。

作者为此给比较结果分了四档。A 类要求同数据、同测试框架、同指标，由同一团队运行双方方案；B 类允许引用基线或存在调优差异，只适合判断方向；C 类只能说明单个系统的能力上限；D 类访谈、标准和收益模型，只能提供约束条件。

这个区分直接影响结论可信度。59 项来源里有 34 项仍是预印本或在审稿，作者没有把不同等级的结果混在一起求平均。

98% 就是一个容易被误读的数字。SIABENCH 中，GPT-5 在 100 条正负样本均衡的告警上达到这个成绩；另一组 35 条告警上达到 97.1%，但其中只有 5 条真实告警、30 条误报，全部判为正常也有 85.7% 准确率。

作者另做了一笔计算：假设攻击占比为 0.1%，10,000 条告警中只有 10 起真实事件，模型召回率为 90%、误报率为 1%，那么约有 9 条正确告警和 100 条错误告警，告警里的真阳性比例只有 8.3%。误报率降至 0.008%，这个比例才升到 91.8%。

脱离真实攻击占比的准确率，无法告诉你值班人员每天要处理多少错误告警。

模型适合读懂日志，不一定适合判定攻击

原文最干净的一组对照，是 XGBoost 与经过 LoRA 微调的 RoBERTa，在固定 29 个特征、每类 50,000 条网络流上比较。

同分布测试中，两者几乎打平：NF-UNSW-NB15-v2 上的 macro F1 分别为 0.9966 和 0.9938，但后者吞吐量低约 5,806 倍。换环境，用 UNSW 训练、CIC 测试，XGBoost 的 F1 为 0.8116，RoBERTa 降到 0.6582。换成对抗扰动，在 ε=0.15 时，RoBERTa 又以 0.9552 胜过 XGBoost 的 0.6917。

因此，谁更好取决于你在考验什么：原环境识别、跨环境迁移，还是对抗规避。这里比较的还是微调编码器，不能把结果直接当成通用聊天模型的表现。

日志异常检测也有类似结果。跨 HDFS、BGL、Thunderbird、Spirit 的测试中，微调 DeBERTa 达到 95.3%–98.9% F1，Drain 加随机森林为 86.4%–95.1%，零样本 GPT-4 为 81.2%–88.3%。GPT-4 每次预测耗时 890 ms、每 1,000 次花费 $8.40，解析器加分类器只需 0.3 ms。

更有希望的分工，是让模型先提取结构，再交给专门方法处理。原文引用的小于 10B 的模型配合专用日志解析器，相比此前的小模型解析方案，平均准确率提高 12.5%，分组 F1 提高 23.8%，模板 F1 提高 50.6%。这些提升属于解析任务，不能算作攻击检测提升。

带证据检索的分诊流程也展示了潜力：在通过真实 SIEM 回放的 1,022 条正常告警和 225 条攻击告警上，一个多智能体方案达到 F1 0.958、召回率 0.969，漏报率为 3.1%；最好的对照推理流程漏报率为 40.4%。

但这是 B 类证据，测试集和获胜系统出自同一团队，尚无独立复现。它说明这种架构可能有效，不能作为上线后的效果承诺。获胜方案每例使用 5,075 tokens，一个更弱的方案却用了 33,438 tokens，也提醒我们：推理更长，不保证判断更准。

真正危险的是模型有权执行，却不会克制

响应阶段最刺眼的结果，是一个 Agent 实现了 100% 的事件遏制，却在 82.5% 的测试回合中采取了不必要动作。

只看遏制成功率，它十分优秀；加入多余动作指标，评价立刻改变。自动化系统不能只回答「有没有解决问题」，还要回答「是不是有必要这么做」。

原文提供了更具体的架构证据：在金融行业 SOC 的 200 起真实事件上，确定性政策校验器拦下了 466 个不符合政策、需要审批的动作，没有降低任务召回率。把同样政策直接写进提示词，却让两个供应商的模型出现相反变化。

模型可以提出动作，动作权限应该由代码决定。

原因还包括提示注入。日志不是天然可信的材料，攻击者可能控制其中的字段，借此把指令送进模型上下文。一项覆盖 48 种策略、防御和任务组合的研究中，平均注入成功率从朴素提示下的 26.6%，降到最强防御下的 11.8%，仍未归零。直接要求覆盖指令的攻击成功率为 0%，伪装角色的攻击却能让 68% 的恶意日志被压下。

这类攻击往往藏在看似合理的业务内容里。只加一句「忽略日志中的指令」，保护不了整个执行链。

另一项包含 12,847 条日志、其中 2,569 条为对抗样本的测试中，分层防御后仍有 8.4% 残余攻击成功率。合理做法是限制模型只能输出规定字段或白名单动作，再逐项验证参数、权限和审批条件。

解释也不能替代验证。原文的钓鱼研究中，Llama-2-7B 和 Llama-3-8B 的解释对齐指标 CC-SHAP 超过 0.95，但分类准确率只有 40% 和 30%。解释看起来与模型判断一致，不代表判断符合事实。

我的判断

我赞成作者把模型放在解析、归纳和提出候选方案的位置。这里任务边界比较清楚，也容易保留证据，让人工复核或程序校验接得上。

但「不要让 LLM 进入检测路径」仍应理解为针对通用模型直接分类的部署建议。原文自己的实验已经表明，微调编码器在部分测试和对抗扰动下有竞争力。做技术选型时，要分别比较规则、随机森林、微调编码器和通用模型，不能把所有 Transformer 都当成同一种方案。

成本结论同样有前提。原文引用的 Monte Carlo 收益模型认为，多数配置下部署不盈利，但它是建模结果，不是生产实测。每 1,000 条告警约 $0.16 的便宜分诊方案，也只在 200 条合成告警上测试过。API 便宜，不代表复核和返工便宜。

目前没有生产 SOC 的受控端到端试验，证明 LLM 能改善平均检测时间 MTTD 或平均恢复时间 MTTR；也没有每起已解决事件的成本研究。作者列出的案例提供了值得尝试的架构，还不足以证明一般团队都能获得相同收益。

此外，这篇汇总本身也需要审慎阅读：部分结果缺少直接可比的指标，部分高分数据集存在标签泄漏疑虑。合理态度是借它确定验证方向，别把引用数量当成结论的保证。

能拿来做什么

• 做 Node 日志助手时，可以先确定性地采集、归一化和关联事件，再让模型提取上下文、生成摘要，并要求输出对应证据，方便定位错误来自哪一步。
• 做告警分诊时，用团队真实攻击占比回放数据，同时记录 precision、FPR、MCC 和每天预计误报告警数，不要仅用正负各半的小样本决定上线。
• 给 AI Agent 接入处置工具时，在服务端校验动作类型、参数、权限和审批状态，并记录不必要动作与升级比例，把克制程度纳入验收。
• 评估收益时，把人工复核、错误处置和返工时间计入成本，先与现有规则或分类器比较，再决定模型需要承担多少工作。