python异常检测

上周调一个日志分析脚本，异常数据里混进了一条来自测试环境的检测记录——某个字段的响应时间写成了 -1。整个统计图直接歪掉，异常均值被拉低，检测阈值报警全乱套。异常这就是检测异常检测要解决的事：不是所有数据都值得信任，有些点就是异常来捣乱的。

Python 做异常检测，检测路子其实挺野的异常。scikit-learn 里塞了一堆现成算法，检测IsolationForest 和 LocalOutlierFactor 是异常我用得最顺手的两个。前者适合高维数据，检测后者对局部密度变化敏感。异常但别指望它们能开箱即用——参数调不好，检测正常点也能给你标成异常。异常

拿 IsolationForest 举个例子。它的逻辑很聪明：随机切分数据，异常点因为“少而不同”，往往几步就被孤立出来。代码写起来也短：

from sklearn.ensemble import IsolationForest import numpy as np X = np.array([[1, 2], [2, 3], [3, 4], [100, 100], [1.5, 2.5]]) clf = IsolationForest(contamination=0.2, random_state=42) clf.fit(X) pred = clf.predict(X) # -1 是异常，1 是正常 

关键在 contamination 这个参数。它告诉模型“你认为数据里有多少比例是脏的”。设成 0.2 意味着每五个点里挑一个当异常。如果你根本不知道污染率——大多数真实场景都是这样——那就得靠可视化或者业务规则来兜底。我吃过亏：有次把 contamination 设成默认的 'auto'，结果在一份干净数据里硬找出了 10% 的“异常”，全是噪声。

另一种常见玩法是基于统计。比如计算 Z-score，超过 3 倍标准差的点就标记出来。简单粗暴，但对非正态分布的数据基本是灾难。我见过有人拿它处理用户点击流，点击量本来就不对称，Z-score 把一堆正常的高频用户全抓了。后来换成 IQR（四分位距）才消停：Q1 - 1.5*IQR 以下或 Q3 + 1.5*IQR 以上算异常。这个规则对偏态数据更稳，代码也就几行。

时间序列又是另一回事。像 statsmodels 里的 STL 分解，能把趋势、季节性和残差拆开，残差大的地方就是异常候选。但拆之前得确保周期设对——我试过把日周期数据按周周期拆，结果残差图跟心电图似的，全是假警报。后来用 pytorch 跑了个简单的 LSTM 自编码器，重构误差高的点才真正对应了服务器宕机事件。代价是训练慢，调参烦，没 GPU 的时候等得想砸键盘。

实际项目里，别只依赖一种方法。我现在的习惯是：先用简单统计快速筛一遍，把明显离谱的（比如负数、超量程）剔掉；再用 IsolationForest 或 LOF 做多变量检测；最后结合业务规则人工复核。有一次模型标了 200 个异常，人工一看，其中 180 个是促销活动带来的正常峰值——模型不懂业务，你得懂。

还有一个坑：数据预处理。缺失值填错了，异常检测直接跑偏。我见过用均值填充后，原本的异常点被“拉”回正常范围，模型完全失效。所以填充前先看看缺失模式，是随机缺失还是系统性缺失。有时候缺失本身就是异常信号——比如传感器该报数却没报。

工具选择上，PyOD 这个库值得一试。它把 30 多种异常检测算法打包成统一接口，切换模型就像换衣服。不过别贪多，选两三个适合数据形态的深入调参，比跑一遍所有算法然后挑个分数最高的靠谱。毕竟异常检测没有“标准答案”，只有“当前场景下够用的答案”。

最后说个观察：很多人把异常检测当成一次性任务。训练完模型，部署上线，就不管了。但数据分布会漂移，上个月正常的用户行为，这个月可能就成了异常。我现在的做法是每周重新拟合一次模型，同时监控预测异常率的波动。如果突然从 2% 跳到 15%，要么是业务变了，要么是数据管道坏了——两种情况都得查。