Azure Anomaly Detector参数交互逻辑及示例咨询

单参数明确定义 #

三个参数的生效优先级从高到低为Period > MaxAnomalyRatio > Sensitivity，各自作用如下：

• Period：整数类型，取值为0或正整数，用于告诉模型时序数据的固定波动周期。比如按小时采集、每24小时重复一轮波动的业务指标，周期就是24；按天采集、每7天重复一周波动的指标，周期就是7。传0时模型会自动用算法推算周期，但如果时序里有节假日、大促这类特殊波动点，自动推算很容易出错，手动传已知的准确周期能直接拉低一半以上的误报率。注意手动传周期时，输入的时序长度至少要覆盖4个完整周期，否则模型拟合精度会明显下降。
• MaxAnomalyRatio：浮点类型，取值范围0~0.49（不包含0），是检测结果里异常点占总时序点数量的硬上限。不管其他参数怎么设，最终返回的异常点占比绝对不会超过你设的这个值，本质是防误报的保险丝——比如业务做活动整体流量涨了30%，你总不希望所有时间点都被标记成异常触发告警风暴吧，这个参数就是用来卡这个上限的，默认值0.1代表最多10%的点会被判定为异常。
• Sensitivity：整数类型，取值范围0~100，是异常判定的软阈值。数值越小，判定标准越严格，只有偏离正常波动区间幅度极大的点才会被标记为异常；数值越大，判定越宽松，小幅偏离的点也会被识别。默认值95是比较宽松的水平，做生产告警一般不需要设这么高。

参数交互逻辑与实际示例 #

三个参数不是独立生效的，判定流程是固定的三步：

1. 先用你传入的Period（或者自动推算的周期）拟合正常时序的波动边界
2. 按照Sensitivity对应的阈值，计算每个时间点的异常得分，把所有超过阈值的点按异常程度从高到低排序
3. 按照MaxAnomalyRatio设定的最大异常点数量做截断，排在截断线后面的点哪怕过了灵敏度阈值，也不会被标记为异常

举个实际的监控场景例子：你用C#对接API检测服务错误率指标，时序是按小时采集的30天数据，共720个点，已知日周期固定为24，其中有一个小时错误率比正常水平高18%，模型计算这个点的异常得分刚好对应Sensitivity=80的阈值线：

• 组合1：Period=0、Sensitivity=80、MaxAnomalyRatio=0.1
  第一步自动推算周期时，如果刚好赶上大促数据干扰，模型把周期误判成168（周度周期），拟合出来的正常波动区间会变宽，这个18%偏离的点的异常得分会降到对应Sensitivity=70的水平，最终不会被标记为异常。
• 组合2：Period=24、Sensitivity=80、MaxAnomalyRatio=0.01
  第一步用正确的24小时周期拟合，这个点的异常得分确实过了Sensitivity=80的软阈值，但0.01的比例意味着720个点最多只能标记7个异常，如果前面已经有7个偏离幅度更高（比如错误率涨了50%以上）的点，这个18%偏离的点会被硬截断，不会出现在异常结果里。
• 组合3：Period=24、Sensitivity=60、MaxAnomalyRatio=0.2
  虽然MaxAnomalyRatio允许最多20%的点被标记为异常，但Sensitivity=60是非常严格的阈值，大概需要偏离正常水平40%以上才会触发，这个18%偏离的点根本过不了软阈值，哪怕异常名额充足也不会被标记。

C#生产对接的调参顺序 #

不要三个参数一起瞎调，按固定顺序来效率最高：

1. 先定Period：业务上有明确已知周期就直接传，不要用0自动推算，这一步做完基本能解决大部分误报问题。
2. 再定MaxAnomalyRatio：告警场景建议设在0.05~0.1之间，不要超过0.2，避免告警风暴；也不要低于0.01，否则真实异常可能被截断漏报。
3. 最后调Sensitivity：前两个参数固定后，从70开始每次加5，用历史上已经确认过的真实异常点做回测，调到真实异常都能被识别、同时误报量在运维能接受的水平就可以停了。

内容的提问来源于stack exchange，提问作者DMC