Jev 最不适合干的活，可能就是告警研判

原创

messfree
messfree

MessFreeSecurity

2026年9月21日 21:43
北京

在小说阅读器读本章

去阅读

在公众号小说中沉浸阅读

先说结论：Jev 是个好东西，但如果你负责的是告警研判（Alert Triage），我劝你先把那只伸向采购按钮的手收回来。

不是因为 Jev 不准，而是因为告警研判这个东西，从问题结构上就和 Jev 的能力边界正好拧着。

先复习一下：Jev 到底强在哪

Jev 的核心动作只有一个：给几个候选打分，选一个。

\"这个工单是账单问题还是技术问题？\"\"这 37 个链接哪个是招聘入口？\"\"Agent 刚才这一步做对了吗？\"——候选集是给定的，语义判断是模糊的，但选择空间是封闭的。

它快（毫秒级）、便宜（不用动大模型）、任务还能临时定义。在 Browser Use 里判断\"点哪个\"，在 Third Hand 里判断\"下一步选哪个\"，一天几十万次的小判断，省下来的时间和钱是真实的。

这个模式成立有一个隐含前提，大多数人没注意：

候选集是别人替它准备好的。

Jev 从来不需要回答\"有哪些可能\"，它只需要回答\"哪个最像\"。前者是生成问题，后者是选择问题。Jev 只做后者。

记住这个前提，我们来看告警研判。

告警研判的第一个反直觉：它根本不是选择题

很多人想象中的告警研判是这样的：

告警进来 → 判断是\"严重 / 一般 / 忽略\" → 完事

如果真是这样，那确实是个三分类的选择题，Jev 闭着眼都能做。

但真实世界的告警研判长这样：

凌晨三点，数据库 CPU 打满。你要回答的不是\"这是几级告警\"，而是——为什么。

为什么？可能是慢查询、可能是索引失效、可能是上游流量突增、可能是主从切换后的连锁反应、可能是隔壁团队昨天上线的批处理任务、可能是一年里只会出现一次的定时任务撞车了……

注意这里的区别：

Browser Use 的候选集是页面上的 37 个链接，环境直接给你； 告警研判的候选集是所有可能的故障原因，没人给你，你得自己想。

研判的本质不是\"从已知选项里选\"，而是\"把未知原因变成已知选项\"。这一步——生成假设、拉取证据、验证排除——才是研判里最贵的部分，而它恰好是生成式问题，恰好是 Jev 不做的事。

Jev 能干的，只是最后那一步\"这个假设像不像\"。可那一步在整个研判链路里，时间上占比可能不到 5%。

用一个只加速最后 5% 的模型，去解决一个瓶颈在前 95% 的问题，这个账算不过来。

第二个反直觉：告警研判的成本结构，和 Jev 正好相反

Jev 类模型的所有卖点，都建立在一个假设上：单次判断错了，代价很小。

路由错了工单？重来。选错了链接？回退。Agent Judge 判错了？下一轮再判。这类场景容错率高，错了不明显、不致命、可恢复。

告警研判的账本完全是另一个记法：

1. 基础比率极端失衡。 一个中大型系统，99% 以上的告警是噪音。这意味着一个\"准确率 90%\"的模型，在这个基础比率下会产出海量误报——原来看那 1% 真告警的人，现在要看混进来的假告警，噪音不但没减少，可能反而变多了。还记得那篇文章里那个反例吗？13.7ms，QPS 58，百题准确率 50%。快是真的快，错也是真的错。

2. 漏报的代价是事故，误报的代价是信任。 把一条真告警判成\"忽略\"，凌晨三点没人知道，天亮就是 P0 事故。更糟的是\"狼来了\"效应：只要小模型错杀过一次真告警，团队就会回到全量人工看告警的老路——这是告警系统建设中最经典的死循环，也是为什么那么多智能告警项目死在了试点阶段。

3. \"选得可靠难很多\"，这句话在告警场景是致命的。 原文里其实已经点出了 Jev 的软肋：模型说自己有 90% 把握时，这个 90% 能不能信？在客服路由场景，置信度不准顶多影响排序。在告警场景，置信度就是分级依据——\"有 90% 把握可以忽略\"和\"实际 60% 可以忽略\"，中间隔着的可能是一次故障复盘会。

客服路由错一次，用户多等十分钟。告警研判错一次，是事故，或者是一次复盘。

错误代价不对称的场景，不适合用\"快但没那么可靠\"的组件卡在关键路径上。这是分布式系统设计的老原则，放到 AI 分层里同样成立。

第三个反直觉：告警研判的敌人是漂移，而 Jev 的舒适区是稳定

原文里有个细节很有意思：传统自动化的问题是\"今天入口叫 Careers，明天叫 Jobs\"。Jev 的解法是语义判断，不用改规则。

但告警世界的漂移比这凶残得多：

• 架构一升级，告警的含义就变了：同一个\"连接数偏高\"，在老架构下是常规波动，在新架构下可能是泄漏前兆；
• 业务一做大，长尾就出现了：判断规则覆盖的永远是头部 80%，剩下 20% 恰恰是最容易出事故的那部分；
• 故障模式是对抗性的：你今天学会的模式，明天系统就以你没见过的方式挂掉——这是和垃圾邮件识别、风控对抗同构的问题，而这类问题十年的历史告诉我们：小模型打不过持续演化的分布。

原文说 Jev\"任务可以临时定义\"，这是优点。但告警研判要的不是\"能定义新任务\"，而是已有判断在新环境里还成立。前者是灵活性，后者是稳健性。Jev 给你前者，你要的是后者。

还有一层没几个人愿意说的：用小模型做研判，失败是静默的。

大模型判错了，你能看它的推理过程，知道它错在哪。小模型给一个分数、一个标签，错了你都不知道它为什么错。告警研判是强审计场景——每一次\"为什么没有升级\"都需要一个能写进复盘报告的答案。一个打分接口给不了你这个答案。

那 Jev 在告警领域就一点用没有吗？

有，但位置很刁钻。说三个我认为成立的用法：

1. 判\"像不像已知噪音\"，而不是判\"是不是故障\"。 把问题倒过来设计：不要让 Jev 判断告警的严重级别（开放生成、高代价），而是让它判断\"这条告警和过去 30 天被确认过的 200 条噪音模式，像不像其中某一条\"（封闭候选集、错了顶多多看一眼）。这是 Jev 的主场。但说实话——这事儿规则引擎和传统分类模型干了十年，Jev 的增量是\"不用写规则\"，不是\"能力上的质变\"。

2. 做离线裁判，别做在线闸门。 让 Jev 离线评估研判 Agent 的历史决策（\"这个 Agent 当时判对了吗\"），跑批量回放、评估新 prompt 的效果。错了重新跑一遍就行，零风险。原文里 LangChain 的 Agent Judge 用法，搬到告警领域，离线比在线合适得多。

3. 卡在\"人类要不要被叫醒\"这一层的外围，且永远配一条逃生通道。 Jev 说\"低置信\"的，直接转人工或大模型——只让它做分流，不做终审。并且必须有监控：Jev 的分流比例漂移、噪音漏出率上升，自动降级回全量模式。

你会发现这三个用法的共同点：Jev 永远不在关键路径上，永远不承担最终责任。

而很多人想象的用法——\"上了 Jev，告警自动研判，值班同学可以睡了\"——恰恰是唯一会出事故的那种。

最后说点可能得罪人的

Jev 火了之后，我看到一批\"接入告警平台\"的方案演示。演示都很漂亮：一条告警进来，8 毫秒，判级完成。

但演示里没告诉你的是：那条告警进来之前，有人花了几个月把告警清洗、收敛、关联、降噪做完了。等一条告警干净到\"Jev 能一眼判级\"的程度，它其实已经不需要研判了。

告警研判真正的难题，从来不在那最后一毫秒的选择里，而在：

• 把散落在八个系统里的证据拉到一起；
• 在没人告诉你候选集的情况下想出第四种可能；
• 为每一次判断准备一个经得起复盘的解释；
• 在 99% 的噪音里，不放过那 1%。

这些都是\"慢功夫\"。慢功夫没有被解决，前面加一个 8 毫秒的模型，就像给一个还不会走路的孩子买跑鞋。