1.1 对比目标界定：任务类型、数据特征与业务约束
我做数据分析这些年，越来越觉得一个事儿：模型对比这件事，最怕的就是拿起来就比。你手里有逻辑回归、有XGBoost、有Transformer，一股脑儿丢进同一个数据集里跑一遍，谁的分数高谁就赢，这种做法看着利索，实际上不太靠谱。我踩过这个坑，早期做项目时，拿一个信贷违约预测的数据集，把当时能想到的模型全跑一遍，AUC最高的那个模型我兴冲冲拿去汇报，业务方一句“这模型为什么拒了这个客户”就把我问住了。那次之后我才明白，模型对比的第一步不是跑实验，是把对比的目标界定清楚。
任务类型决定了对比的起跑线。分类任务和回归任务看的东西不一样，异常检测和聚类看的又不一样。同样是分类，二分类和多分类的评价侧重点也有差别。我一般会先问自己几个问题：这个任务是要预测一个数值，还是要判断一个类别，还是要从数据里发现结构？任务类型不同，后面的指标选择、模型候选范围都会跟着变。这个界定如果含糊，后面所有的对比都是在沙上建塔。
数据特征这一块也得提前摸清楚。样本量多大，特征维度多高，是结构化表格还是文本图像，有没有严重的类别不平衡，缺失值比例怎么样。我做过一个设备故障预警的项目，正样本占比不到百分之一，这种数据你拿准确率去比模型，基本没有意义。数据特征会直接影响哪些模型适合上场，线性模型在小样本高维场景可能更稳，深度网络在数据量充足时才有发挥空间。
业务约束是最容易被技术出身的人忽略的一环。模型上线之后跑在什么环境里，推理延迟要求多少毫秒，能不能接受黑盒，有没有合规审计的要求。金融风控场景里，监管对可解释性的要求是硬性的，你模型效果再好，说不清楚决策逻辑就过不了关。制造业的边缘设备上，算力和内存都卡得死死的，一个大模型根本塞不进去。这些约束在对比开始之前就得摆到桌面上，它们不是事后补充说明，而是对比框架的一部分。
1.2 数据分析任务模型谱系：统计模型、传统机器学习、深度学习与预训练大模型
我习惯把数据分析的模型分成四大类来看，这个分法不一定严谨，但做对比的时候挺好用。第一类是统计模型，线性回归、逻辑回归、时间序列里的ARIMA、指数平滑这些。这类模型的历史很长，数学基础扎实，参数少，解释起来直接。我到现在做很多基线实验还是先用逻辑回归跑一遍，它的系数方向和显著性检验能给我不少关于数据的直觉。统计模型在样本量不大、需要强解释性的场景里依然很有生命力，不要觉得它老就轻视它。
第二类传统机器学习，决策树、随机森林、梯度提升树、SVM、KNN这些。这类模型在结构化数据上的表现相当能打，尤其是XGBoost、LightGBM这一支，我在表格数据任务里用它们的频率最高。它们的优势在于能自动捕捉特征之间的非线性关系和交互效应，对特征工程的要求比统计模型低一些，训练效率也不错。缺点是有时候调参空间大，容易过拟合，需要认真做验证。
第三类深度学习，全连接网络、CNN、RNN、LSTM、Transformer这些。深度模型在图像、语音、文本这些非结构化数据上是主力，在时序预测里也有不少应用。它的特点是表示学习能力强，能自动从原始数据里抽特征，但需要的数据量和算力都更大。我在实际项目里用深度模型会比较谨慎，先看数据量够不够，再看业务对推理成本敏不敏感。不是所有任务都值得上深度模型，这一点我吃过亏，也见过同行吃过亏。
第四类预训练大模型，这两年是绕不开的话题。BERT、GPT系列以及各种开源的基座模型，在文本理解、生成、多模态任务上展现了很强的通用能力。它们在数据分析里的用法主要有两种，一种是直接做零样本或少样本推理，另一种是微调之后嵌入到具体任务里。大模型的优势是泛化能力强、开发周期短，劣势是推理成本高、可解释性弱、对数据隐私有要求。我现在的做法是把大模型和传统模型放在同一个对比框架里看，而不是单独供起来。
这四类模型之间不是替代关系，是一个谱系。谱系的一端是强解释、低成本的统计模型，另一端是强能力、高成本的大模型，中间的传统机器学习和深度学习填满了大部分实际场景。我做模型对比时，通常会从这个谱系里挑三到五个有代表性的候选，覆盖不同复杂度层次，这样对比出来的结论才有参考价值。
1.3 对比维度设计：预测能力、可解释性、训练与推理成本、鲁棒性与可维护性
维度设计这件事，我觉得是模型对比里最能体现功力的地方。只看预测能力，对比就变成了刷榜。我一般会从四个维度来搭对比框架，这四个维度不是并列关系，具体项目里权重会差很多。
预测能力是大家最熟悉的维度，分类看准确率、精确率、召回率、F1、AUC，回归看MAE、RMSE、R²，聚类看轮廓系数这些。这个维度重要，但它只是起点。我在项目里会特别关注预测能力在验证集和测试集上的一致性，训练集上分数很高、测试集上掉一大截的模型，预测能力要打折看。
可解释性这个维度，技术团队常常嘴上重视、行动上轻视。我现在的做法是把它拆成两层来看。一层是模型本身的结构可解释性，线性模型的系数、决策树的规则路径、树集成模型的特征重要性，这些是模型自带的。另一层是事后解释，SHAP、LIME这些工具能给黑盒模型提供局部解释。两层结合起来看，才能对一个模型的可解释性做出比较完整的判断。在金融、医疗这些强监管场景里，可解释性的权重甚至可以放到和预测能力平级的位置。
训练与推理成本是落地时绕不开的。训练成本包括数据准备、算力消耗、调参时间，推理成本包括单次预测的延迟、批量处理的吞吐、部署所需的硬件。我做过一个实时风控的项目，模型推理必须在几十毫秒内完成，这种情况下一些复杂的集成模型和大模型就直接出局了。成本这个维度在实验室里容易被忽略，到了生产环境里往往是决定性的。
鲁棒性和可维护性是我这几年越来越看重的维度。鲁棒性是指模型面对数据分布漂移、噪声、异常值时的稳定性。可维护性是指模型上线之后，监控、更新、回滚这一整套流程好不好做。一个模型在测试集上表现很好，但数据分布一变就崩，或者每次更新都要推倒重来，这种模型在生产环境里是负担。我一般会看模型对特征扰动的敏感度，也会评估重训练的频率和成本。
这四个维度放在一起，就形成了一个立体的对比空间。不同项目里我会给不同维度分配权重，比如合规场景里可解释性权重高，实时场景里推理成本权重大，探索性分析里预测能力和可解释性并重。维度设计没有标准答案，关键是把权重分配的逻辑说清楚。
1.4 对比实验流程：数据划分、基线设置、交叉验证与结果复现
实验流程这块，我想说的是，严谨的流程设计比模型本身更能决定对比结论的可信度。我见过不少对比报告，结论下得很果断，但一看实验设计，数据划分有问题，基线设得不合理，结果也没法复现，这种报告的价值很有限。
数据划分是第一道关。时间序列数据不能随机划分，得按时间切，不然就是用未来信息预测过去，分数虚高。类别不平衡的数据要分层抽样，保证训练集和测试集的类别比例接近。我一般会留一个独立的测试集，在模型选择和调参阶段完全不碰它，最后只用它做一次最终评估。这个习惯听起来简单，坚持下来不容易，尤其是项目时间紧的时候，很容易忍不住拿测试集来调参。
基线设置是很多人忽略的一步。基线不一定是简单的模型，但一定要有明确的参照意义。我通常会用两类基线，一类是业务基线，比如现有规则引擎的效果或者人工判断的准确率，另一类是简单模型基线，比如逻辑回归或者多数类预测。有了基线，复杂模型的提升幅度才有意义。一个模型AUC做到0.85，听起来不错，但如果基线已经是0.83，那这个提升就得掂量掂量值不值。
交叉验证的选择要看数据特点。K折交叉验证在样本量适中、数据独立同分布的情况下很好用。时间序列要用时间序列交叉验证，保证每一折的训练数据都在验证数据之前。分组数据要用分组交叉验证，避免同一个实体同时出现在训练和验证里造成信息泄漏。我一般会同时看交叉验证的均值和方差，均值看整体水平，方差看稳定性。
结果复现是实验流程的底线。随机种子要固定，数据预处理步骤要写成可执行的脚本，模型超参数和训练环境要记录清楚。我自己有个习惯，每个对比实验都会写一个简短的实验日志，记下数据版本、模型配置、关键结果和异常观察。这个日志在项目复盘和交接时特别有用。对比结论能不能站得住，很大程度上取决于别人能不能按照你的流程跑出相近的结果。
2.1 分类与异常检测任务：准确率、精确率、召回率、F1、AUC与误报代价
我做分类任务的模型对比，第一步不是看指标，是先把混淆矩阵摊在桌面上。准确率这个指标太容易被误用了。我记得有一回帮一个团队看他们的反欺诈模型报告，准确率写着98.6%，乍一看挺唬人。再一问正样本占比，不到百分之二。这意味着什么？我把所有样本全判成负类，准确率也能到98%左右。这个指标在这个场景里基本失去了区分能力。所以我跟团队讲，拿到一个分类任务，先别急着看谁高谁低，看看数据长什么样，看看基线在哪。
精确率和召回率这一对，我觉得是分类对比里最需要业务方坐下来一起看的指标。精确率是你说“是”的时候有多少真是“是”，召回率是所有真正的“是”里你抓到了多少。这两个在大多数场景下是跷跷板关系，阈值一动，一个上去一个下来。我做信用评分的时候，业务部门关心的是坏客户能不能拦住，这时候召回率权重高。做营销响应预测的时候，投放成本高，精确率就得更看重。F1把这个权衡压成一个数，方便排序，但我不太建议只拿F1定胜负，因为它把精确率和召回率当同等重要，实际业务里很少这么理想。
AUC这个指标我用得多，它衡量的是模型把正负样本排序分开的能力，对阈值不敏感，适合做模型之间的横向比较。但AUC有个问题，它在类别极度不平衡的时候会给人过于乐观的感觉。我做过一个设备异常检测的项目，正负比大概是一比几百，AUC做到0.92，看着挺好，实际部署之后误报率高得运维人员受不了。原因就是AUC对大量负样本中的中间区域不敏感，那些误报恰好落在业务关注的区间里。
说到误报代价，这个事儿得单独拎出来讲。分类模型对比如果只比统计指标，不把误报和漏报的业务成本摆进去，对比结论很可能和实际价值南辕北辙。我现在的做法是算一个简单的代价矩阵，一个误报要花多少人工复核成本，一个漏报要承担多少风险损失，把这个加权进去之后再看模型排序。有时候A模型的F1低一点，但它的误报集中在低风险区间，人工处理成本低，反而更适合上线。这个算账过程不光技术团队要做，业务方也得参与进来，不然指标和体感永远对不上。
异常检测这块还有它的特殊性。异常检测任务里“异常”的定义本身就带模糊性，标注往往不完整，甚至有些异常类型训练时根本没出现过。这种场景下我只用AUC或者F1来对比模型是不够的，我会额外看模型在已知异常类型上的召回稳定性，以及它在未见类型数据上的评分分布变化。我用孤立森林、自编码器、One-Class SVM这些方法做过对比，结论是不同方法对不同形态的异常敏感度差别很大，单靠一个聚合指标排序，容易选出一个在某些异常类型上完全失灵的模型。
2.2 回归与时序预测任务：MAE、MSE、RMSE、R²、MAPE、SMAPE与残差诊断
回归任务的指标对比，我吃过只看RMSE的亏。RMSE对大误差惩罚重，这在很多场景里是合理的，比如库存预测里偶尔来个巨大的偏差会直接把成本拉爆。问题是RMSE对量纲敏感，你比较不同模型的时候，如果预测目标的单位不一样或者尺度差很多，光看绝对数值容易误判。MAE就好一些，它的解释更直接，平均每个预测偏了多少，业务方一听就懂。
R²这个指标我在做汇报的时候用得挺多，它表达的是模型解释了多少方差。它的问题是当预测目标和业务关心的方向不完全一致时，R²好看不代表业务价值高。我做销量预测的时候遇到过一次，一个模型的R²比另一个高出一截，但细看发现它在高销量区间的预测偏差很小，在低销量区间偏差很大。业务方最关心的恰恰是低销量商品的补货决策，因为高销量商品有安全库存兜底。这种结构性偏差，R²是看不出来的。
MAPE和SMAPE这两个指标我在时序预测任务里经常用，尤其是需要跟业务方对齐“平均偏了百分之几”这种讨论的时候。MAPE的计算直观，但它有个硬伤，实际值接近零的时候会爆炸。我做过一个日订单量预测，有些商品某些天就是零单，MAPE算出来直接飞上天。SMAPE在这方面好一些，分母用了绝对值和的一半，相对稳定。这两个指标我都会看，但一般不会拿它们单独做模型排序的主指标，更多是作为辅助视角。
残差诊断是我在回归对比里最看重的环节，比看聚合指标还上心。我会把每个候选模型的残差分布画出来，看它是不是围绕零对称，有没有明显的异方差，残差和预测值之间有没有残留的相关模式。有一回对比两个时序模型，指标上A模型略好，但残差图一看，A的残差在旺季月份系统性地偏负，说明它在这种高波动区间有系统偏差。B模型指标稍差，残差分布更均匀。我最后选了B，上线之后的表现验证了这个判断。残差诊断能帮我看到聚合指标掩盖住的结构性问题。
时序预测还要看预测步长和预测窗口的影响。单步预测和多步预测的模型表现排序可能完全不同。我做需求预测的时候，会按提前一周、提前一个月、提前一个季度分别评估模型。有些模型短期很强，越往后越拉胯。这种维度如果不拆开看，拿一个平均指标做对比，选出来的模型可能在业务真正需要的预测窗口上并不占优。
2.3 聚类与降维任务：轮廓系数、DBI、CH指数与业务可解释性
聚类任务的模型对比，说句实话，比监督学习要难办得多。没有标签，没有标准答案，指标算出来高低之分有了，但到底哪个聚类结果更有用，指标本身回答不了。我刚开始做客户分群的时候，拿着一堆轮廓系数和CH指数选了个分数最高的方案，拿去跟业务方过，对方看了半天说这分出来的群我们看不懂，也没法针对性地做运营。那次之后我调整了思路，内部指标只做初筛，最终选哪个方案得业务可解释性说了算。
轮廓系数衡量的是样本跟自己簇的紧密程度和跟最近邻簇的分离程度，取值在负一到一之间，越大越好。它直观好用，但在簇形状不规则或者密度不均匀的时候会偏低，这不一定说明聚类差。DBI是簇内散度和簇间距离的比值，越小越好，它假设簇是球形的，遇到长条形或者环形分布的数据会误判。CH指数用的是簇间方差和簇内方差的比值，计算快，但对簇的数量敏感，往往倾向于给出一个不是业务最优的簇数。
我现在的做法是这几个指标一起看，再加上对簇数量稳定性的观察。比如对同一份数据，分别聚成三到十簇，看每个指标随簇数的变化曲线，找拐点。更重要的是，我会把每个簇的中心或者代表性样本拿出来，让业务方看，问他们“这批人你觉得像不像一类”。如果业务方能说出这个群的特征画像，比如“这群是高频低客单、促销敏感型”，那这个聚类方案就有落地价值。如果业务方看了直摇头，指标再好看也要打问号。
降维任务的对比又是另一番光景。PCA、t-SNE、UMAP这些方法，我一般不看重构误差之类的纯数学指标来决定用哪个，更多是看降维后的可视化效果对于探索性分析有没有帮助，以及降维结果作为下游模型的输入时下游任务的表现。t-SNE在保留局部结构上很出色，适合做可视化展示，但它的全局结构保留得不好，而且每次跑结果会有差异。UMAP在这方面平衡一些，速度也快。PCA可解释性好，主成分能对应回原始特征，这在需要向业务解释的场景里是加分项。
有一个教训我想提一下。聚类和降维的评估里，稳定性是一个非常关键的维度，但容易被忽略。换个随机种子、或者对数据做轻微扰动，聚类结果就大变的方案，上线之后会非常难维护。我一般会对每个候选方案跑多次，看簇的划分一致性，用调整兰德指数或者类似的指标衡量稳定性。稳定性差的方案，哪怕轮廓系数高，我也不敢用。业务运营是要连续性的，今天分出来的群明天全变了，策略根本没法沉淀。
2.4 综合评测与统计检验：稳定性、显著性、泛化误差与多指标权衡
指标算完了，模型排了个序，这一步还不能直接下结论。我在对比报告里一定会加一块内容，就是这些排序到底靠不靠谱。具体来说，我会看几个东西。一个是重复实验下结果的波动，同样的数据划分，换几个随机种子，或者换几折交叉验证，看指标的均值和方差。有个模型平均分排第一，但方差特别大，换一次划分就掉到第三，这种“第一”的说服力是要打折扣的。
显著性问题我一般用配对检验来处理。比如两个模型在同一批测试样本上的预测结果，可以算它们的误差差异，做配对t检验或者Wilcoxon符号秩检验。我遇到过指标差距很小的情况，比如F1就差0.003，统计检验一做p值零点几，说明这个差距很可能是噪声。这种时候我会说两个模型在预测能力上难分伯仲，选型的决定因素要往成本或者可解释性那边找。不做这一步检验，很容易陷入过度解读微小差距的陷阱。
泛化误差的评估，我会特别留意训练集和验证集之间、验证集和测试集之间的指标落差。落差大意味着过拟合风险高。我对比模型的时候不光看测试集最终分数，还会看整个学习曲线的形态。有些模型在训练集上收敛得很快，验证集上也还行，但学习曲线很陡，说明它对数据量很敏感，样本稍微少一点或者分布一变就可能出问题。这种模型在生产环境里的稳健性要打个问号。
多指标权衡这一块，我不太喜欢用简单加权求和的方式硬凑一个综合分。指标之间的量纲和意义不一样，加权系数的选取主观性也大。我更倾向于用帕累托前沿的思路来看，把模型在几个关键指标上的表现画出来，找出那些不被其他模型全面压制的候选。最终选哪个，结合业务权重来定。比如有三个模型在帕累托前沿上，一个精度高成本高，一个精度中等成本低，一个精度略低成本也低，那就要看业务场景对精度和成本的边际敏感度。这个决策过程我会写成文字记录，把权衡逻辑交代清楚，而不是只给一个结论。
2.5 性能、成本与可解释性三维对比及可视化呈现
把性能、成本、可解释性放在一个框架里对比，说起来简单，做起来需要一些设计。我通常会在实验阶段就把这三类数据采集齐。性能好办，前面那些指标算出来就行。成本我拆成训练成本和推理成本，训练成本记录单次训练在什么硬件上跑了多久，推理成本记录单条预测延迟和批量吞吐。可解释性量化起来麻烦一些，我的办法是设几个维度打分，比如模型结构本身是否透明、有没有成熟的事后解释工具、解释结果的稳定性如何，每个维度一到五分，让团队里几个人分别打再取平均，虽然主观，但比不量化强。
可视化这块，我最常用的是雷达图和散点图的组合。雷达图适合看单个模型在多个维度上的均衡程度，一眼能看出短板在哪。散点图我一般画成性能对成本、或者性能对推理延迟的二维平面，每个点代表一个模型，点的大小或者颜色映射可解释性得分。这样一张图放出来，讨论的时候大家有共同的视觉锚点。我做汇报的时候发现，同样的结论用表格列出来大家容易走神，画成图之后业务方经常会指着某个点问“这个模型为什么成本这么高”，对话就自然展开了。
三维空间的呈现我试过用三维散点，效果一般，投影之后角度一变读起来就费劲。后来我改用分面或者二维加颜色映射的方式，信息密度够，也不至于让人看不懂。还有一个小经验，图上的标注要克制。我见过一些对比图，每个点旁边都堆满文字标签，密密麻麻，反而失去了可视化的意义。我一般只标注帕累托前沿上的模型和业务基线，其他的点让读者自己按需查看。
可视化是为决策服务的，不是为好看服务的。我每次做这类图都会先想清楚这次对比最想让读者看到什么。如果重点是推荐某个模型，我会把推荐理由通过图上的参考线和标注突出出来。如果重点是说明没有单一最优解，我会让多个模型在不同区域各有所长这个事实在图上自然呈现。图做完了，我一般会自己盯着看一分钟，问自己“如果我是业务方，我看完会做什么决定”，这个问题答不上来，图就得重做。
3.1 金融风控与信用评分：模型对比中的可解释性与合规要求
金融风控这块我做过的模型对比项目不算少，每次最让我头疼的不是技术指标怎么算，是解释怎么给。信用评分模型对比的时候，AUC高零点零几个点，业务方其实没那么在意。他们真正盯着问的是：这个模型为什么给这个人拒了？我印象特别深的一次，一个梯度 boosting 模型在测试集上的KS值和AUC都压过了逻辑回归一大截。我把对比报告递上去，风控负责人看完只说了一句，监管那边要是问起来，我拿什么跟人家讲。这句话把我拉回了现实。金融场景的模型选型，性能排名只是入场券，可解释性是硬门槛。
后来我的做法变了。不管对比结果里复杂模型领先多少，我始终坚持把逻辑回归或者广义线性模型作为基线摆在同一张表里。不是走个过场，是真的把它的系数、WOE编码的单调性、变量贡献方向都整理清楚。如果复杂模型最终要上，我会配套做SHAP值的稳定性分析，看同一个客户在不同样本扰动下解释结果会不会剧烈变化。有些模型虽然能给出特征重要性，但排序在相邻样本间跳来跳去，这种解释拿给合规部门看是要出事的。
信用评分还有一个特殊性，就是拒绝推断和样本偏差。我能拿到的违约标签只覆盖审批通过的客户，那些被拒掉的人表现怎么样，数据里根本看不到。做模型对比的时候如果不处理这个问题，离线指标再漂亮，上线后分布一漂移就露馅。我现在的习惯是对比实验里专门设计一个拒绝推断的修正版本，把加权后的指标和不修正的指标并列展示，让决策者看到两种口径下的排序差异。这个细节很多对比报告会漏掉，但在金融场景里它往往决定了模型能不能过内部审计。
合规要求的另一层含义是模型文档和可追溯性。每次模型换版本，对比了哪几个候选，各自在什么数据上训练的，超参数怎么定的，最终为什么选这个，这一整套东西我都要求团队留档。出过一件事，一个已经上线半年的评分卡被监管抽查，要求回溯当时的对比记录，结果发现实验脚本散在几个人的个人目录里，复现都复现不了。从那以后我规定所有对比实验必须走统一的实验管理平台，指标结果自动落库。这个流程上的投入，比多调几个模型参数值钱得多。
3.2 零售与营销分析：销量预测、客户分群与推荐场景的模型选择
零售场景的模型对比有个特别接地气的问题：你选的模型得跟供应链和运营的节奏对得上。我做销量预测的时候对比过统计模型、树模型和深度学习时序模型。纯看MAPE，深度学习模型在一些品类上确实占优。问题是它的训练和更新周期长，新品上架或者促销计划一变，重新训练要等很久。运营那边等不了。最终落地的方案是在大类目上用轻量梯度提升树做主力，几个波动规律特别稳定的长尾品类用季节性ARIMA兜底。这个组合不是指标最优的，但它更新快，运营团队自己就能触发重训。
客户分群这个事我在零售场景里踩过的坑更多。第二章讲过聚类指标好看不代表业务能用，零售这边还多一层约束：分群结果得能直接映射到触达动作上。我对比过K-means、层次聚类和基于高斯混合的分群方案。高斯混合在轮廓系数上表现不错，软分配的概率输出也挺优雅。真正的问题是运营要的是“这批人发什么券、什么时候发”，你给我一个概率分布矩阵，他们的CRM系统接不住。最后选的是K-means加业务规则后处理，簇中心能翻译成客单价、复购周期、品类偏好这几个维度上的区间描述，运营一看就懂怎么配活动。
推荐场景的模型对比逻辑又不一样。我一般把召回和排序分开对比。召回阶段对比协同过滤、双塔向量和基于规则的关联挖掘，看的核心指标是召回率和覆盖率。排序阶段对比逻辑回归、深度交叉网络和序列模型，重点看AUC和线上CTR的校准度。有一个体会挺深：离线AUC高不代表线上效果好，因为推荐系统的数据分布受自身推荐策略影响，存在反馈回路。我现在的对比实验会留一部分流量做随机探索，用这部分无偏数据来评估候选模型，不然对比结论会被历史策略带偏。
零售还有个绕不开的话题是冷启动。新品没有历史销量，新客户没有行为记录，模型对比的时候如果只在成熟样本上比，结论对冷启动场景没有参考价值。我会专门切出冷启动子集来做对比，看哪些模型在样本稀疏时还能站得住。经验上，融合了内容特征或者属性信息的模型在冷启动阶段明显更稳，纯行为序列模型这时候基本趴窝。这个维度的对比结果直接影响选型矩阵里“场景适配性”那一栏怎么填。
3.3 制造、医疗与运维：异常检测、故障诊断与风险预警中的对比策略
制造和运维场景的异常检测，我最大的感受是标注成本决定了对比策略。第二章提到过异常检测的评估难点，到了工业现场这个问题更突出。设备大部分时间正常运行，故障样本稀少，而且故障类型还会随设备老化不断变化。我做过一个旋转机械的故障预警项目，对比了孤立森林、单类SVM、自编码器重构误差和基于统计过程控制的残差监控。离线评估的时候用历史上已知的几次故障做测试集，自编码器召回最高。上线试运行三个月，误报把现场工程师折腾得够呛，最后他们直接把告警关了。
那次之后我调整了对比框架。工业异常检测的模型对比，我把误报率和平均无故障运行时间放在跟召回率同等重要的位置。具体做法是引入一个持续运行的影子模式，几个候选模型同时挂在数据流上跑，只记录不告警，运行一段时间后对比它们在实际工况下的告警频次和告警时段分布。这个方法慢，但能看到离线指标看不到的东西。比如有个模型在设备启停阶段疯狂误报，因为启停过程的信号形态跟故障有相似之处，离线测试集里这部分样本比例很低，指标上根本反映不出来。
医疗场景的对比策略更强调风险分层和临床可接受性。我参与过一个院内感染风险预警的模型对比，候选模型包括逻辑回归、随机森林和梯度提升。从AUC看梯度提升最好。临床科室反馈说，他们需要知道风险评分背后的主要驱动因素是什么，不然没法跟主治医生沟通干预措施。最后选的是逻辑回归加少量交互项，性能比最优模型低了两三个点，但每个风险因子都有明确的临床含义，护士站接受度很高。这个案例让我确认了一件事：在高风险决策场景里，模型对比的终点不是指标排行榜，是使用者的信任度。
运维场景的风险预警还有个特点是多指标联动。服务器或者网络设备的异常往往体现在CPU、内存、延迟、错误率等多个监控指标的组合模式上，单指标阈值告警误报多，多指标异常检测模型又容易把正常波动当成异常。我对比过基于马氏距离的多元统计方法、隔离森林和LSTM自编码器。马氏距离在指标相关性稳定的环境下表现很稳，解释性也好，能定位到是哪个指标偏离了正常联合分布。LSTM自编码器在捕捉时序模式变化上更强，但解释起来费劲。最终的落地方案是两层：马氏距离做第一道筛查，触发可疑窗口后再用LSTM重构误差做二次确认。两个模型各管一段，对比结论转化成了分层策略。
3.4 文本与多模态数据分析：大模型与传统模型的协同与边界
文本分析这块这两年变化太快了。我前几年做客服工单分类，对比的是TF-IDF加朴素贝叶斯、线性SVM和TextCNN。现在再立项，预训练大模型肯定要放进对比清单里。我的实际体会是，大模型在零样本和少样本场景下优势明显，尤其是工单内容涉及口语化描述或者新出现的问题类型时，传统模型需要重新标注大量数据才能跟上，大模型改改提示词就能应付个七七八八。但大模型不是万能钥匙。做高吞吐的实时分类，大模型的推理延迟和成本摆在那里，一天几十万条工单全走大模型，账单吃不消。
我现在的对比框架是把大模型和传统模型放在一条流水线的不同位置来评估。简单说，先看任务对语义理解的深度要求有多高。如果是关键词匹配就能解决大半的工单路由，轻量模型完全够用，大模型留给那些语义模糊、需要推理的复杂类别。我做过一个混合方案的对比，用小模型处理百分之七十的常规工单，剩下百分之三十不确定的交给大模型做精细判断。整体准确率比纯大模型方案低一个多点，成本降了六成多。这个性价比在业务侧是很能打的。
多模态数据分析的对比又是另一回事。我做过设备巡检的场景，输入是巡检照片加文字描述，任务是判断设备状态。对比方案包括图像分类模型单独跑、文本模型单独跑、以及图文融合模型。单模态模型各有盲区。图像模型对光照和拍摄角度敏感，文本模型对描述者的专业水平敏感。融合模型在联合表示上确实更好，但训练数据要求高，标注成本也上去了。实际落地的时候我们用了决策级融合，两个单模态模型各自输出置信度，再用规则做仲裁，效果比想象中好，维护起来也简单，哪个模态出问题单独修就行。
大模型和传统模型的边界，我觉得会随着任务和成本约束不断移动。做选型的时候我不会预设哪个一定更好，而是把几个关键约束列清楚：延迟要求、单次调用成本上限、数据隐私能不能出域、标注预算有多少、任务类型的变化频率。这几条一摆，很多选项会自动被排除掉。剩下能进对比实验的模型其实不多。这个先做约束筛选再做指标对比的顺序很重要，不然容易在技术上很兴奋，选了个业务上根本养不起的方案。
3.5 面向业务落地的模型选型矩阵、验证闭环与持续监控
选型矩阵这个东西我改过好几版。最早的版本就是一张表，横轴是模型，纵轴是指标，谁分高选谁。后来发现这样不行，业务约束根本没体现进去。现在我的矩阵分三层。第一层是门槛项，比如推理延迟不能超过多少毫秒、可解释性必须达到什么级别、数据合规能不能满足，不达标的直接出局，不进入打分环节。第二层是业务权重项，预测精度、稳定性、维护成本各占多少权重，这个权重由业务方和技术方一起定，定完签字。第三层是风险项，每个候选模型标注主要风险点，比如对数据漂移敏感、依赖的第三方服务有中断风险、冷启动表现差。三层过完，剩下的选项通常不多了。
验证闭环这块我吃过亏。有一次一个模型在离线对比里表现很好，上线之后前两周也正常，第三周开始指标往下掉。查原因发现上游数据源的某个字段口径悄悄变了，离线验证的时候用的还是旧口径的数据。这件事之后我在验证流程里加了两道关。一道是上线前的数据契约检查，把模型依赖的每个字段的分布、缺失率、取值范围都固化成检查项，跟历史基线比，偏离超过阈值就拦下来。另一道是灰度期间的在线评估，拿真实流量跑，跟当前线上模型做A/B对比，看核心业务指标有没有统计学上的显著差异。两道关都过了才放全量。
持续监控的指标体系我也调整过。早期只监控模型的预测分布和准确率，后来发现不够。现在分四块看。第一块是数据质量监控，输入特征的分布漂移、缺失率变化、异常值比例。第二块是模型表现监控，有标签的延迟反馈指标加上无标签的置信度分布变化。第三块是业务指标监控，模型直接影响的那个业务KPI，比如风控的通过率、推荐的点击率。第四块是系统健康度，推理延迟、吞吐、错误率。这四块里任何一块触发告警，都要走排查流程，不能只看模型指标。
最后说一个我越来越看重的东西：模型的退役机制。选型的时候大家想的是怎么把模型选上来，很少有人想它什么时候该下去。我现在的做法是在选型阶段就约定好退役触发条件，比如连续多少天核心指标低于基线、业务场景发生重大变化、维护成本超过阈值。触发之后走重新对比流程，而不是在原模型上修修补补。这个约定写在选型文档里，业务方和技术方都认。有了这个机制，模型对比就不是一次性的项目动作，变成了一个周期性的常规流程。团队对模型更替的心理负担也小了很多，反正到点就比，比完该换就换。
