做需求评审时，常有人一上来就说「用大模型做吧」，可你的数据只有几千行、要的是几毫秒响应、还得跑在客户机房里。这篇不比较名词定义，只给一套按数据量、交付周期和运维成本逐条打勾的判断顺序，让你在立项会上能说清为什么选简单方案，也写明哪些情况下这套判断不成立。
做需求评审时，最常听到的一句话就是「直接上大模型吧」。可真到了落地阶段，数据只有几千行、要求响应压到毫秒级、还得部署在客户内网机房的情况一点不少。这时候硬上深度学习，往往不是先进，是自己给自己挖坑。这篇不聊名词定义，只给一套能照着打勾的判断顺序，让你在立项会上把「为什么先用简单方案」讲明白。
先说明白：这里的「机器学习」指的是逻辑回归、树模型、梯度提升、简单聚类这类方法；「深度学习」指的是多层神经网络那一类。两者没有高下之分，只有合不合适。模型资料和各家能力对照，可以到 /models 看当时的清单，但选型这事得按你自己的数据、延迟、运维条件来定，不是按榜单来定。
先按这四件事排序，别先挑模型
很多人第一步就去比较哪个模型强，顺序反了。正确的顺序是先看任务类型，再看数据，再看交付约束，最后看可解释性。这四件事里任何一件卡住，后面的模型选型都是空谈。下面这张对照表可以直接搬到立项文档里用。
| 判断维度 | 偏向传统机器学习 | 偏向深度学习 |
|---|---|---|
| 输入形态 | 结构化表格、数值、类别特征 | 图像、语音、自由文本、多模态 |
| 数据规模与标注 | 样本少、标注贵、类别不均衡 | 数据量大、标注规范、可持续回流 |
| 交付约束 | 要求低延迟、离线、客户机房可跑 | 环境可控、算力可谈、能接受较重依赖 |
| 可解释性 | 需要特征权重、规则依据能讲清 | 允许黑盒，或只要求整体指标达标 |
- 任务类型：阈值判断、排序打分、表格预测这类，传统方法往往够用
- 数据规模：先算每类样本多少条，样本越薄，复杂模型越容易过拟合
- 交付约束：端到端延迟、离线能力、部署环境，先确认再讨论模型
- 可解释性：审批、风控、医疗建议这类场景，规则依据比零点几个点的提升更重要
数据和延迟这两关，基本决定答案
这两关过不了，模型再新也没用。数据这一关的核心不是「有没有数据」，而是「每一类有多少条、标注靠不靠谱、噪声大不大」。延迟这一关的核心不是单次前向多快，而是预处理加上推理再加上后处理，用户实际感受到的那个时间。
- 先跑一个基线用最简单的统计规则或线性模型跑一遍，记录效果和耗时。没有基线，后面所有「升级」都无从比较。
- 统计每类样本量把每个类别、每个关键特征的样本数列出来。哪一类少于几十条，就要先想清楚是补数据还是降复杂度。
- 算端到端延迟从请求进来到结果返回，把预处理、推理、后处理全加起来测。只测推理耗时会让自己误判。
- 确认部署环境边缘设备、浏览器端、老服务器分别能装什么、跑得动什么，先做一次实测，别等集成时才发现装不上。
常见的坑是拿一个漂亮的离线指标去汇报，忽略了线上推理的真实耗时和内存占用。判断标准很简单：如果基线方案在你的延迟预算内已经能达到业务门槛，那就没有必要上更复杂的结构。门槛定多少，建议在立项时和业务方一起写死，而不是上线后再吵。
算总账：训练、推理、运维各占多少
选型讨论里最容易漏掉的是运维。一次性训练投入看得见，长期维护和数据回流的人力往往看不见，但后者才是真正把人拖住的部分。把三笔账拆开列，决策会清楚很多。
- 训练投入
- 一次性成本，包括数据整理、标注、调参和验证所花的人力与算力
- 推理成本
- 每次调用要花多少资源，高频业务里这项会被放大很多倍
- 维护成本
- 定期重训、漂移监控、版本回滚、数据回流，这些才算工程成本
- 切换成本
- 从当前方案换成另一个方案要改多少接口、重训多少模型，越早写进评估越好
团队能力是硬约束。没人懂调参、分布式训练和显存管理时，选复杂模型等于把风险留到上线之后。判断标准不是「我们能不能学会」，而是「在交付周期内，出问题时有没有人能当场定位」。答不上来，就先选简单方案。
这几种情况，别硬省
反过来也要说清楚：不是所有场景都该省。硬省的结果可能是反复堆规则，最后维护成本比直接上复杂模型还高。下面这几类情况，简单方案通常很快就摸到天花板。
- 输入是非结构化且模式难手工描述：图像识别、语音转写、长文本理解，规则法很快到上限
- 数据量足够、标注规范、还有持续回流渠道，复杂模型才有持续吃到红利的前提
- 精度差一点会造成明显损失或安全问题的场景，优先保证效果而不是优先省事
- 需要对接现成生态，比如现成权重和成熟工具链时，自研简单方案反而更贵
注意边界：上面这些是「值得上复杂模型」的信号，不是「必须上」的结论。还要结合前面三节的延迟、成本和团队能力一起看。如果数据够但延迟预算极紧，或者团队没人能维护，可能仍然要选轻量方案，比如用现成服务替代自研。各家能力和可用性可以到 /rankings 和 /sites 核对当时的记录。
立项会用得上的勾选清单
把下面这张清单打印出来，立项会上逐项过一遍。每一项都要有明确结论和负责人，不能只写「待定」。凡是写「待定」的，默认按最保守的方案来排期。
| 检查项 | 要写出的结论 |
|---|---|
| 任务类型与输入形态 | 属于结构化还是非结构化，能不能手工写规则描述 |
| 样本量与标注成本 | 每类多少条、标注花多少人力、能不能持续补 |
| 基线方案 | 用什么方法做基线，效果和耗时的可复现数字是多少 |
| 延迟与部署环境 | 端到端预算多少，跑在什么设备上，有没有实测 |
| 可解释性要求 | 是否需要给出特征权重或规则依据，谁来审核 |
| 三笔成本与负责人 | 训练、推理、运维各谁负责，切换成本是否评估 |
关于成本和性能的具体数字，站内 /price-watch 和 /tools/speed-test 会有当时的记录，选型阶段直接引用页面上的实时数据，比拿旧截图讨论靠谱。判断标准始终是那一条：在当前约束下，哪个方案能让业务跑起来并且长期维护得住。
下一步带着这份清单去对一遍你手上的项目，再顺手查一下当时的模型资料和实测情况，能少走不少回头路。→常见问题
数据只有几千条，是不是就一定不能用深度学习？
不一定，但默认应该先跑传统方法当基线。样本少的时候，迁移学习、数据增强能救一部分场景，可代价是引入外部权重和更长的调试周期。判断标准不是「能不能」，而是这套方案在交付期内能不能稳定复现、上线后谁维护。数据规模的具体参考区间，可以到 /ai-dict/category/basics 把相关术语对照一遍再汇报。
业务方坚持要用最先进的模型，怎么说服？
别用「够不够先进」争，改用三个可量化的问题：现在能拿到的标注数据有多少、上线后允许多少延迟、出错时怎么解释和回滚。把基线方案的耗时与效果摆出来，再把复杂方案多花的训练与运维人力折成时间，让对方选。若对方仍坚持，先做小范围试点，把对比结果留档再推广。
模型上线后效果变差，是选型错了吗？
多数时候不是选型错，而是数据分布变了、上游口径改了或标注标准漂移。先做排查顺序：核对输入数据来源有没有变动、抽样比对近期样本与训练样本、检查特征是否缺失或被默认值填充。确认是漂移后再决定重训还是改方案。运维侧的成本和监控口径，可以到 /models/deploy 做一遍部署测算。
