微软决策模型实测：概率输出如何革新AIOps根因定位

当决策模型不再"说话"：概率输出为运维降本增效

在AIOps（智能运维）领域，日志异常检测与微服务根因定位一直是两大核心难题。传统方案要么依赖人工经验设定规则，要么使用大语言模型（LLM）生成分析报告。微软推出的Decision-1模型提供了一个全新思路：它不生成任何自然语言，只输出概率数值——是/否判断输出 noul，多选判断输出 choice，有序评分输出 score。每次调用仅消耗约1个输出token。

这种"沉默"的设计恰好契合运维场景：工程师不需要模型解释"为什么"，只需要一个快速、精准的概率信号来辅助决策。开发者Pedro Sakuma在GitHub上开源了完整的复现项目，用两个公开AIOps数据集对Decision-1、gpt-4.1-nano、推理模型以及非LLM基线进行了系统对比。

Decision-1在根因分析与HDFS异常检测上的结果

HDFS日志异常检测：从49%到86%的优化之路

数据集的真实面貌

实验使用Loghub HDFS_v1数据集，按数据块（block）分组日志序列。每个数据块应有完整生命周期：NameNode分配块、三个DataNode（副本因子为3）接收并确认、PacketResponder终止、最终注册到NameNode。

关键发现来自对300个数据块的校准集分析：38个正常块包含异常关键词（如"got exception while serving"），14个异常块反而没有错误日志。异常的真实信号是生命周期完整性——预期步骤是否重复三次、缺失了哪些环节。简单规则"出现任何异常事件"在测试集上仅达71%。

副本因子（Replication Factor） 是分布式存储系统（如HDFS）中一个数据块被复制存储的份数。HDFS默认副本因子为3，意味着每个数据块会被写入三个不同的DataNode节点。这一机制保证在单个节点故障时数据仍然可用。副本因子直接决定了数据块生命周期中应该出现多少次"分配""写入""确认""终止"等事件——当副本因子为3时，这些步骤理应重复三次。因此，任何环节次数不足或缺失，都可能意味着数据块写入异常。理解副本因子是解读本文后面"生命周期完整性"判断逻辑的前提，也是将日志文本转化为结构化校验规则的关键领域知识。

第一次尝试的失败

最初的prompt很直觉：状态是事件模板加计数，问题为"这个块是否异常？"。Decision-1得分49%（AUC 0.68），甚至不如71%的规则基线。保存的输出揭示了问题：概率与事件数量相关性0.43，与标签相关性仅0.14。短块（≤10事件，全为异常）平均异常概率0.45，而15-20事件的正常块却得到0.66——模型对词法线索和日志体量过度反应，并把"缺失事件"误判为健康。

AUC（Area Under the ROC Curve，ROC曲线下面积） 是衡量二分类模型排序能力的常用指标，取值在0.5到1之间。0.5代表模型判断与随机猜测无异，1.0代表完美区分。AUC不依赖具体阈值，因此适合评估模型输出的概率信号质量，而准确率则受阈值选择影响较大。本文中Decision-1原始得分49%（AUC 0.68）意味着在准确率上甚至不如规则基线，但0.68的AUC说明其概率排序仍略优于随机——问题主要出在默认阈值0.5不合适，以及输入特征的构造方式误导了模型。这也解释了后文为何强调"必须校准阈值"。

结构化提问的突破

两个关键调整彻底改变结果：状态层面，从HDFS领域知识计算 lifecycle_summary（预期副本数、分配次数、写入启动/完成数、确认终止数、注册数、缺失步骤、错误事件数）；问题层面，从"是否异常"改为"生命周期是否完整"。

在1200个测试块上的最终结果：Decision-1校准后准确率86%（阈值0.15），gpt-4.1-nano为79%，gpt-6.1-sol（仅100样本）为66%。Decision-1的AUC达0.964。

训练分类器仍是首选

当有标注数据和稳定schema时，逻辑回归以50个标注块达95.1%，8000块达99.7%。零样本场景才是决策模型的优势区间——无需训练、schema频繁变化时仍有86%可用性。

零样本（Zero-shot）场景 指模型在没有针对目标任务进行任何微调或提供标注示例的情况下直接执行推理。与之对应的是少样本（few-shot，提供少量示例）和微调（fine-tuning，用标注数据更新参数）。零样本决策模型的优势在于：无需收集标注数据、无需训练流程、可在schema频繁变动时快速上线。本文中，当有50到8000个标注块时，逻辑回归在稳定schema下达到95%甚至99%以上的准确率，远超零样本LLM的86%；但当标注稀缺或字段结构经常变化时，Decision-1等零样本方案成为唯一可行选择。这一权衡关系是选择技术路线的核心依据。

微服务根因定位：94%准确率的实战验证

任务设计与状态构建

RCAEval RE2-OB数据集在11个微服务的Online Boutique上注入5种服务的6类故障，共90个案例。模型接收的状态经过脚本压缩：故障前后各12分钟的指标变化（CPU、内存、套接字、磁盘、延迟、错误率）、trace跨度时间变化、日志量变化，均只保留变化最大的前若干项。

服务级定位表现出色

Decision-1在90个案例中正确识别根因服务85次（94%），超过"最大指标偏移"规则基线（82%，McNemar p=0.013）。在规则与模型分歧的17个案例中，14个是Decision-1正确——规则往往被下游症状误导（9次误选frontend），尤其在丢包和延迟故障中。

模型也犯了可预见的错误：3次将邮件延迟故障的调用方checkout误判为根因，2次在丢包场景中被下游服务误导。

McNemar检验 是一种针对配对二分类数据的统计检验方法，用于判断两个分类器在同一组样本上的错误模式是否存在显著差异。它关注的是两个模型预测不一致的样本：其中一方正确、另一方错误的案例数量。本文中规则基线与Decision-1在17个案例上产生分歧，其中14个由Decision-1正确，McNemar检验给出 p=0.013，意味着这种差异在统计上显著（通常p<0.05视为显著），即Decision-1的优势不太可能仅由随机波动造成。引入该检验可以避免仅凭准确率数字的微小差距就得出过度结论。

故障类型识别仍是短板

故障类型识别仅51%准确率。CPU和延迟故障特征明显（各15次中正确13次），但丢包故障0次正确，套接字耗尽仅2次正确。状态中没有任何字段直接描述"丢包"或"套接字耗尽"，所有模型（包括gpt-6.1-sol的54%）在此均表现不佳。

实践建议：用Decision-1来排序排查方向（11个服务缩小到1个，耗时240ms），而非直接命名故障类型。

成本与延迟对比

模型	平均延迟	1380次调用成本
Decision-1	240ms	约$0.015
gpt-4.1-nano	728ms	约$0.05-0.07
gpt-6.1-sol	2052ms	约$0.56

Decision-1在同等调用量下比推理模型便宜约两个数量级。

实践要点

状态工程胜于模型选择：让模型接收已计算好的生命周期摘要和指标变化量，而非原始计数
问结构性问题："生命周期是否完整"优于"是否异常"
必须校准阈值：0.5是糟糕的默认值，需在留出集上优化
有标签时训练分类器：小模型在稳定schema上全面超越LLM
决策模型不做解释：重大决策保留人工审核环节

完整代码和复现步骤见GitHub项目 pedrosakuma/decision-1-aiops。