很多人接到需求时会被问一句「这个用大模型做好不好」，但脑子里只有「大模型 = ChatGPT」这一个印象，说不清它跟以前的机器学习方案差在哪。这篇不讨论谁更强，而是从数据准备、通用性、出错方式、算力账四个角度把两条路线摆开，再给你一份对照表和小规模试跑步骤，用在选型会上讲明白为什么你这个场景适合哪条路。
很多人接到需求时会被问一句「这个用大模型做好不好」，但脑子里只有「大模型 = 聊天框」这一个印象，说不清它跟以前的机器学习方案差在哪。这篇不讨论谁更强，而是把两条路线在做事方式、数据依赖、出错方式和算力账上摆开对比，再给你一份能自己动手验证的判断清单，用在选型会上讲明白为什么你这个场景适合哪条路。
先明确一点：两条路不是新旧替代关系，线上不少系统是「大模型负责理解和生成、传统模型负责打分和排序」的组合。所以下面每一节都尽量给判断标准和排查动作，而不是空讲概念。拿不准的时候，最省事的办法是各花一周做同一个子任务，用同一批样例比正确率、成本和交付时间，数字到站内相关页面核对当时的行情。
先把「传统 AI」这词说清楚，不然对比全是空的
「传统 AI」这个说法很宽，落到工程上一般指为单一任务专门训练的判别式模型：分类、回归、目标检测、推荐打分，输入输出字段固定。大模型走的是另一条路子，先用海量文本做通用预训练，再靠提示词或少量示例适配任务，一次训练能接多种活。判断你手上这个需求属于哪一类，先看两样东西：有没有已经标好、格式统一的样本，以及输出字段是不是固定。
- 判别式模型
- 只回答「属于哪一类」或「分值多少」，输出空间在训练时就定死了
- 生成式大模型
- 输出是开放文本或结构化内容，靠提示词约束格式，能力边界更宽但更不可控
- 混合架构
- 大模型抽信息、传统模型做决策，是很多线上系统的实际形态
- 手上有几千条以上、标注规范的样本，且输出字段固定 → 先考虑传统路线
- 任务描述能写成 20 条「输入 → 期望输出」样例 → 可以先试大模型做原型
- 两者都满足 → 优先看延迟和成本要求，再决定主链路交给谁
- 完全没数据也没样例 → 先把任务写成样例集，这一步谁做都得走
数据门槛的差别：一个要标注，一个要会描述
传统 AI 的起点是数据集：要人工打标、要正负样本相对均衡，标一批只够跑个基线，量不够效果就上不来，而且标注口径一变就要重标。大模型的起点是任务描述：先写清楚输入是什么、期望输出长什么样，用几十条样例做提示词或做小规模微调就能看到效果，迭代速度通常快不少。但这条路也有明确的适用边界。
什么情况下不适用大模型：如果任务本质是数值预测或强规则判定，比如额度评估、风控打分、库存补货量预测，一个特征清晰的模型往往比大模型更稳也更好解释。反过来，任务涉及语义理解、多轮改写、非结构化文本抽取，传统模型光是整理特征就够喝一壶。判断动作很具体：把想做的事写成 20 条「输入 → 期望输出」的样例，能顺手写出来就先试大模型，写不出来先回去整理数据。
| 对比维度 | 传统 AI 路线 | 大模型路线 |
|---|---|---|
| 起步条件 | 已有标注数据集 | 一份任务描述加少量样例 |
| 主要成本 | 标注与特征工程 | 推理调用量、上下文长度、是否自托管 |
| 迭代方式 | 重新标数据、重训模型 | 改提示词、换样例、必要时再微调 |
| 典型强项 | 数值预测、排序打分、强规则判定 | 语义理解、内容生成、非结构化信息抽取 |
| 出错形态 | 概率型误判，可用阈值控制 | 看起来对的错误，需要格式校验和人工抽样 |
出错方式不一样，验收方式就得跟着变
传统 AI 的错误通常是概率型误判，可以用准确率、召回率一套指标卡阈值，指标稳定就敢上线。大模型的错误形态完全不同：编造事实、跑偏格式、忽略约束、同一个问题两次答案不一致。所以大模型项目的验收重点不能只盯一个分数，而是抽样人工看、格式校验和兜底规则这三件事一起上。什么情况下先别用：业务对错误零容忍，又没有人工复核环节，关键链路先别交给大模型。
- 固定一份回归样例集把上线前跑过的问题和期望输出存成文件，覆盖正常、边界和刁钻三类，别只存顺手的例子
- 改一处就跑一遍换模型、改提示词、调温度参数之后都重跑回归集，对照差异再决定要不要保留这次改动
- 加格式校验和兜底要求输出结构化内容时，先做字段和取值校验，不通过就走人工队列或规则兜底，而不是直接返回给用户
- 记录失败样本把每次跑偏的案例归到同一份清单里，积累到一定量再判断是提示词问题还是任务本身不适合
这套流程的价值在于把「感觉效果好」变成「可复现的对比」。如果你带的团队之前只做过传统模型，最容易漏掉的是失败样本的记录习惯，而这恰恰是大模型项目里最值钱的资产。
算力和落地的账怎么算：别只比单价
传统 AI 的成本大头在标注和特征工程，模型训练往往是一次性投入；大模型的成本大头在推理调用量、上下文长度，以及要不要自己托管。按调用量走还是自己部署，取决于你的日均请求量、数据能不能出内网、延迟要求这三件事。具体单价和托管行情波动快，到站内价格追踪页面核对当时的数字，别拿几个月前的截图做决策。
- 先量延迟基线：用站内测速工具跑一遍你最关心的场景，拿自己环境下的真实数字，比看第三方榜单靠谱
- 估调用量：把日均请求数乘以平均输入输出长度，再留出重试和调试的余量
- 判断数据边界：数据不能出内网就走自托管或私有部署路线，能出内网再考虑按调用量付费
- 算迁移成本：从传统方案切过来，重做的大头往往是质检和兜底流程，不是模型本身
- 留退路：关键链路上准备一个降级方案，避免单点依赖导致整体不可用
一张对照表，帮你把选型会上的话说明白
把前面的判断收拢成一句话：有大量标注数据、输出格式固定、还要求结果可解释，传统路线更省事；任务多样、需求还在变、输出是自然语言或结构灵活，先用大模型做原型，再决定要不要沉淀成专有模型。同一个产品里两条路完全可以并存，上游用大模型做抽取和改写，下游用轻量模型做打分和过滤，这在工程上很常见。
| 你的场景特征 | 建议先走哪条路 | 下一步动作 |
|---|---|---|
| 有标注数据、输出字段固定 | 传统 AI | 先跑基线模型，确定指标阈值 |
| 需求频繁变、输出是自然语言 | 大模型 | 写 20 条样例做提示词原型 |
| 既要理解文本又要打分排序 | 两者组合 | 大模型抽字段，小模型做决策 |
| 对错误零容忍又无人工复核 | 暂不交给大模型 | 先补人工或规则兜底环节 |
还是拿不准，就做小规模试跑：同一个子任务，两条路各花一周，用同一批样例比正确率、成本和交付时间。这种对比的结论通常比任何评测榜单都更有说服力，因为它用的是你自己的数据和最在意的指标。
下一步想让选型会有据可依，可以先去站内看各家模型的当前价格与能力对比，再用测速工具量一遍自己环境下的延迟，两个数字摆在一起，为什么选哪条路基本就清楚了→常见问题
只做分类任务，还有必要上大模型吗？
通常没必要先上。分类任务如果标签体系稳定、训练样本够，传统模型成本更低也更好解释。只有标签经常变、类别说不清、或者样本很少时，才值得先用大模型跑一遍做基线，再考虑是否把它蒸馏成小模型。具体用什么模型到站内模型库对照当时的清单。
大模型是不是不需要准备数据了？
不是不需要，是换了形式。传统路线要标注样本，大模型路线要样例、规则和回归集。你仍然得准备一批带期望输出的测试样例，否则没法判断换模型之后是变好还是变差。数据准备的门槛降低了，但「能验收」这件事没有省掉。
两条路线能混在同一个系统里吗？
很常见。上游用大模型做理解、抽取和改写，把结果转成结构化字段；下游交给传统模型做打分、排序或规则判定。这样做的好处是关键决策点仍然可解释、可回退。前提是接口字段定义清楚，并且给大模型的输出加格式校验，失败就走兜底逻辑。
