Datadog 做了个专治告警的 AI 模型 Scout：效果追平顶级大模型，成本只要三分之一

凌晨三点，告警响了。值班工程师爬起来，先看监控面板，再翻日志，再猜是数据库连接池还是某个下游服务超时。这套动作里最耗时的部分不是修，而是找——找根因。Datadog 想用一个小模型把这半小时抢回来：它叫 Scout，跑在自家的 AI SRE 产品 Bits Investigation 里，专门干生产故障排查这一件事。

一分钟速览

• Scout 是 Datadog 自研的轻量级专用模型，用于生产告警的根因分析，目前处于封闭预览。
• 在自建 AlertEval 基准上，Scout medium 的效果接近 GPT-6.1 Sol high 与 Claude Opus 5.5 high，推理成本仅为其三分之一到八分之一。
• xhigh 档位效果对标 Claude Fable 5.1 xhigh，成本约为其四分之一。
• 模型基于 GLM-5.3 Flash 构建，用历史案例生成的模拟事件做训练。

为什么不用最强的大模型

答案只有两个字：成本。故障排查不是一次问答，而是一个多轮循环——Bits 先查一个指标，看结果，再决定下一步查什么，可能来回十几次。通用大模型当然能完成这类任务，但按 token 计费跑十几轮，单条告警的成本会高到无法接受。而生产环境的告警量是以万计的，Datadog 的设想是「每条告警都跑一遍」，让 Bits 在工程师还在穿鞋的时候就开始收集线索。

这就决定了模型选型的方向：不是追求最强，而是在够用的精度下把单次排查成本压到极致。专用小模型因此有了空间。

AlertEval 想看什么

Datadog 为此自建了 AlertEval 基准。数据集由真实告警、归档遥测数据和工程师撰写的故障说明组成，评判方式是用 LLM 当裁判，把 Scout 的报告与专家报告逐项比对：直接原因匹配、根本原因匹配得分，出现矛盾或缺乏证据支撑的推断扣分，最终折算成 0 到 100 分。

官方特意提醒，这个分数不等于成功解决故障的百分比——基准终究是基准，真实故障的长尾远超数据集覆盖。但作为横向对比的工具，它至少把「谁更会找根因」变成了可量化的东西。

成本账怎么算

按官方口径，Scout medium 的得分与 GPT-6.1 Sol high、Claude Opus 5.5 high 相近，而推理预估成本只有后者的三分之一到八分之一；xhigh 档位对标 Claude Fable 5.1 xhigh，成本约为其四分之一。Datadog 没有公布绝对定价，这些数字都是相对 Scout medium 单次排查成本而言。

这个区间其实很关键。三分之一意味着可以在告警全量上跑，八分之一意味着可以反复试错、多轮追问。AIOps 产品过去常常卡在「demo 很好看，账单很难看」，把单位成本压下来，才谈得上全天候值守。

专用模型会不会成为主流

Scout 基于 GLM-5.3 Flash 构建，用模拟事件训练，这个技术路线透露出一个趋势：企业不再执着于自研基座，而是拿开源或可授权的模型做领域微调，把预算花在数据与评测上。故障排查这类任务的好处是反馈明确——根因对不对，工程师一眼能看出来，数据闭环天然成立。

当然，封闭预览意味着它还没经过大规模真实环境的检验。误报的代价在 SRE 场景里很高：一条错误的根因推测，可能把工程师引向完全无关的方向，浪费的时间比没有 AI 更多。Scout 真正的考题不在 AlertEval 上，而在那些从未见过的、由三个服务同时抖动引发的复合故障里。