500 行日志埋了 3 个故障，最阴的那个伪装成 WARN，AI 还是抓出来了

前阵子排障，我把两千多行日志丢给一个现成的「智能分析」工具，它给我标了三百多行"疑似异常"。我硬着头皮翻了半小时，翻出来的全是缓存未命中、慢查询、重试成功——没有一条是真故障。那一刻我挺怀疑的：这不叫降噪，这叫把噪音打包发回给我。后来我就想，如果是大模型来做这件事，会不会也一样被海量 WARN 淹死？

为了不靠感觉，我干脆自己造了个能复现的实验。

我写了段脚本，确定性地生成 500 行日志，时间跨度模拟系统一个小时的产出。其中 340 行 INFO、150 行 WARN、7 行 DEBUG，全是例行噪音——缓存未命中、慢查询两百多毫秒、重试成功、GC 暂停这类。然后我亲手埋了 3 个真故障：

• L110，一行 ERROR：连接池耗尽（active=20/20, idle=0），属于资源耗尽；
• L305，一行 ERROR：NullPointerException 打在 PayService.java:88，属于明确的代码异常；
• L470，一行 WARN：金额校验和对不上，order_id=88213 算出来是 199.00，实际应该是 199.50。

前两个是响当当的 ERROR，模型只要扫到就不会放过。我真正想为难它的是第三个：它伪装成和那 150 行一模一样的 WARN，混在里头，标签上看不出任何特殊。按我对"降噪"的理解，这种最容易被当成背景噪音一起淹掉。

我把这 500 行原样发给一个真实的大模型（走的是真 API，不是我替它编结果），提示词只要求一件事：忽略例行噪音，只挑出代表真实故障的行，并给行号。为了排除运气，我跑了三轮，每轮都是独立请求、不共享上下文。

结果跟我预想的不一样。三轮里，它都只标了 L110、L305、L470 这三行，一个不多、一个不少。我埋的三个故障，三轮全中，召回 3/3；而那 150 行 WARN 噪音，它一行都没误报，误杀数 0。

它给的理由也站得住，三轮表述略有不同但指向一致：L110 是连接池耗尽、资源耗尽类故障；L305 是空指针、明确代码异常；L470 是金额校验不一致、数据校验错误。

我得承认，我赛前赌它会至少漏掉 L470 那个。我的逻辑是：它长得太像噪音了，连我都得眯着眼在 WARN 堆里找。但模型不是靠"WARN 这个标签"来判定的，它是读了那行字——"checksum mismatch、computed 和 expected 对不上"——这句话的语义它就是认得出。我之前担心的"被噪音淹没"，前提是它像规则引擎一样只扫级别和关键词，而它实际做的是读意思。

不过这实验不能拿去吹过头，有几条我得说清楚。这 500 行是我造的，缺陷类型标准、上下文干净，真实的线上日志没这么"乖"——可能有几百行长得像故障但其实不是，也可能有故障藏在它压根没见过的业务约定里。我这次是 500 行一把喂进去，真要有几百万行，上下文窗口和成本就是另一回事了，到时候大概率得先做一轮粗筛再丢给模型，而不是全量直喂。模型没误报也不代表它永远不误报，三轮全绿更像是我这 3 个样本恰好都在它的舒适区。

所以我现在对"AI 做日志降噪"的态度是：把它当第一道语义粗筛挺香，它读得懂"金额对不上"这种藏在 WARN 里的真问题，不像关键词规则那样只会喊"有 WARN"。但真要上线接几百万行，我还不敢让它独占，至少得在它后面再挂一层我自己写的、针对这个业务的特征校验。

你平时排障，是真把日志丢给模型读过，还是也像我之前一样，觉得它无非是把噪音重新打包发回来？