其实大部分对AI模型的误解，都来自对基础逻辑的不了解。这里先从运维的使用角度，把AI模型的概念理清楚。简单来说，AI模型是通过对大量历史数据做统计分析，提炼出数据背后的关联规律，再用这套规律对未知的新数据做判断、预测的计算逻辑。和传统的基于规则的判断方式比，AI模型能处理规则覆盖不到的复杂情况，不用人手动把所有可能的规则一条条写出来。但这不代表AI模型能脱离规则，脱离实际场景自己产生正确结果，很多人就是在这里踩了坑。
最早我接触到AI模型在运维的落地，就是故障预警场景。很多团队碰到周期性的偶发故障，人工很难总结出固定规则，就想到用AI模型找前兆。我前两年碰过一个案例，某业务团队花了两个多月，整理了过去两年的运行数据，训练出一个AI模型，测试的时候准确率超过92%，大家都觉得效果很好，结果上线跑了一个多月，一次真实的严重故障都没提前预警出来，反而每天都有十几条误报，最后不得不关掉了。
后来一起复盘找原因，问题出在训练数据的采样上。这个团队两年里只发生过7次严重的宕机故障，大部分时间都是正常运行，故障数据占总数据量还不到千分之一。训练AI模型的时候，为了提高整体准确率，AI模型只要默认判断"一切正常"，整体准确率就能超过99%，那点极少的故障前兆，早就被大量正常数据覆盖了，AI模型根本学不到对应的规律。测试的时候用的是平衡过的测试集，看不出问题，一到线上真实场景，就完全不对了。
从这个案例里能得到的经验是，用AI模型做预测类任务，首先要解决数据平衡的问题，不是总数据量越大效果越好，有代表性的样本才有用。如果故障样本太少，就得做过采样或者数据增强，不能直接把原始数据丢进去就训。另外，训练出来的AI模型，不能只看测试集的准确率，一定要在线上挂一段时间做影子测试，就是AI模型只跑不发告警，把结果偷偷记下来和实际发生的情况对比，算清楚真实的误报率漏报率，再调整阈值，没问题了再正式上线。很多人跳过影子测试这一步，急着上线，最后效果不好反而浪费时间。
第二个常见的场景是异常流量检测，用来提前发现过量爬虫、异常请求这类会占用资源的情况，避免影响正常用户访问。这个场景里AI模型比固定规则好用的地方在于，正常流量的模式本身会变，固定规则很难跟上变化，AI模型如果更新及时，能自适应小的调整。但我也见过不少团队踩了概念漂移的坑。
有个电商团队，大促之前训了AI模型做异常流量检测，大促期间效果很好，就没动过，结果过了三个月，做秋季大促的时候，AI模型把三分之一的正常活动流量都判定成异常，直接拦了，导致不少真实用户进不来，影响了正常业务。查下来的原因就是，原来AI模型学习的是平峰时期的流量特征，大促之后虽然没换模型，但用户的访问行为、流量的大小分布都和原来不一样了，原来学到的规律已经不适用了，也就是常说的概念漂移。
很多人对AI模型有个误会，觉得训练完就可以一劳永逸一直用，实际上在运维这种业务和数据都一直在变的场景里，AI模型的效果会随着时间慢慢下降。一般来说，用来做在线检测的AI模型，至少一到两个月就要重新训练一次，碰到业务做大规模推广、活动、架构调整这类变更之后，还要立刻更新AI模型，不能训完就不管。我见过最长的，有人用三年前训的AI模型还在线上跑，那效果可想而知，和瞎蒙没多大区别。
第三个我觉得是目前AI模型用得最稳妥的场景，就是日志分析和故障排查辅助。线上出故障的时候，特别是分布式架构，几十上百个服务出日志，工程师要从几G甚至几十G的日志里找错误，很费时间。用AI模型提前把和当前故障相关的日志分类、提取出来，能大大缩小排查范围。
这个场景好就好在，AI模型只是做辅助，不用它直接做决策，哪怕错个一次两次，也不会直接导致业务故障，工程师最后还是会自己判断，试错成本很低。我自己之前在排查多服务关联的故障时用过训练好的AI模型筛日志，原来要翻半小时才能找到错误点，现在几分钟就能定位到大概范围，确实能省不少时间。
但这里也有个容易忽略的点，就是AI模型对日志格式的统一性要求很高。很多团队的不同服务用不同的日志框架，有的输出json，有的输出纯文本，时间格式、字段名也不统一，直接把原始日志丢给AI模型，提取出来的特征误差很大，分类结果自然不准。所以在准备训练数据之前，一定要先做日志的归一化处理，统一格式、统一字段，把无用的噪声信息过滤掉，这个步骤花的时间不一定比训模型少，但对效果影响很大，不能省。
聊完几个具体场景，再说说很多团队都会问的问题，我们要不要上AI模型？其实不是所有团队都需要。我见过小团队，一共就五六台服务器，三个服务，每月最多一两次小故障，人工处理完全过来，非要花几个月搭环境、训AI模型，投入的成本比能省的还多，完全没必要。
一般来说，只有当你的服务规模到一定程度，每天的告警量、日志量已经大到人工处理不过来，需要第一层过滤辅助判断的时候，用AI模型才有实际的收益。另外，要明确AI模型的定位，它是辅助工具，不是替代人，大部分运维场景里，最终的决策还是要靠人，AI模型只是帮人节省找信息的时间，不要指望它能完全代替工程师处理故障。
还有一个常见的误区，就是选AI模型的时候，盲目追求大参数、大模型，觉得越大的AI模型效果越好。我前两年碰过一个团队，为了做异常检测，专门训了一个参数过亿的大AI模型，训练的时候用了三台高性能服务器训了半个月，最后出来的结果，比原来用的小模型准确率只高了0.6%，但推理的时候，每秒只能处理二十多条数据，资源占用是小模型的十二倍，线上跑起来，本身就占了一台机器的资源，完全得不偿失。
其实从实际落地的经验来看，大部分运维场景对准确率的要求，不是说要精确到小数点后几位，只要准确率过了90%，就能满足辅助的需求，剩下的提升带来的收益非常小，完全抵不上资源成本的增加。所以选AI模型的时候，先从小模型试起，能满足当前的需求，就不用换更大的模型，够用就行，这个原则能帮你省很多不必要的投入。
最后再讲一个部署时候的常见问题，很多团队训好AI模型，就直接往现有体系里一加，当成独立的告警源，结果原来的告警就已经很多了，又加上AI模型输出一堆新告警，工程师的告警箱更满了，本来想省时间，反而更忙了。
正确的做法其实是把AI模型的输出，作为附加信息挂在原有的告警或者日志上，不要单独发告警。比如原来的监控告警是"某实例CPU负载超过80%"，AI模型在这个告警后面加一个附加信息，"根据历史数据，该实例10分钟内负载升到100%的概率为78%"，工程师看到就能直接判断优先级，先处理概率高的，不用额外多出来一堆告警。这样既用到了AI模型的结果，也不会增加额外的负担，结合现有体系的体验会好很多。
还有可解释性的问题，也顺便提一句。对可靠性要求高的场景，尽量选可解释性强的AI模型，不要用完全黑盒的复杂模型。我之前帮人排查过一个问题，用黑盒AI模型做异常请求拦截，上线一周就出了十几次误拦，翻遍了模型结构也看不出来为什么AI模型会把这些正常请求判定成异常，整个团队查了三天，什么问题都没找出来，最后只能把这个AI模型换掉，换成一个可解释性强的树模型，才发现是新上线的一个接口响应长度，刚好和原来训练数据里异常请求的响应长度分布重合，AI模型学到了错误的关联，只要调整一下输入特征，去掉不重要的长度字段就好了。黑盒模型出了错，你根本不知道为什么错，是数据的问题还是特征的问题，很难调，只能重新训，时间成本很高。可解释性强的AI模型，出了错你能直接看到哪部分判断不对，针对性调数据调参数，效率高很多。
总的来说，AI模型现在在运维场景里已经有不少成熟的用法，能帮我们解决很多人工处理起来很麻烦的问题，但它也不是万能的，很多问题本质上还是数据和工程的问题，不是靠AI模型就能自动解决的。大部分踩坑的情况，都是对AI模型的期望太高，或者没有做好前置的工程准备，就急着上线。 以上内容仅作技术交流，具体实践还要结合实际环境来判断。