1.2 应用场景与传统模型对比

1.2 应用场景与传统模型对比

本节摘要：大模型的应用已覆盖生成、理解、对话、代码、多模态与智能体六大类场景，但它不是传统机器学习的全面替代者。本节用一张多维对比矩阵讲清两类模型的边界，并给出工程选型的决策框架——核心结论是：专精稳定用传统模型，多样泛化用大模型，真实系统大多是两者的混合。

阅读目标

阅读完本节，你应当能够：

1. 按生成 / 理解 / 对话 / 代码 / 多模态 / 智能体归类大模型的主要应用
2. 说出大模型相对传统机器学习模型在七个维度上的差异
3. 用决策框架判断一个具体任务该用哪类方案
4. 设计一个典型的"大模型 + 传统模型"混合架构

先看应用全景

大模型的通用性让它能覆盖大量场景。按任务性质可以归成六类：

• 文本生成与改写：营销文案、文章润色、邮件起草、报告初稿。特点是容错率高、人工终审，是最先大规模落地的方向。
• 理解与分析：摘要、分类、情感分析、信息抽取、文档比对。这类任务传统 NLP 也能做，大模型的优势是免标注、换任务不用重训。
• 对话与问答：客服、虚拟助手、知识问答。配合检索增强生成（RAG）把模型接到企业知识库上，是当前企业落地最多的形态——模型负责语言理解与组织，检索负责提供事实依据，缓解幻觉。
• 翻译：多语言互译，低资源语言对的效果提升尤其明显。
• 代码：代码生成、补全、解释、单测编写、缺陷定位。开发者工具是目前商业化最成功的方向之一。
• 多模态与智能体（Agent）：图像理解、视觉问答、图文生成；再往上是让模型做规划、调用工具、自动执行多步任务的智能体，被视为下一个应用浪潮。

两类模型放在一起看

大模型与传统机器学习模型的差异，值得逐维度过一遍。下面这张对比矩阵把七个关键维度并排展开：

大模型与传统机器学习模型对比矩阵

矩阵之外再补三点矩阵装不下的观察：

第一，推理成本随规模线性甚至超线性增长。 传统逻辑回归的推理近乎免费，而千亿模型处理一个请求要动用几十 GB 显存的矩阵运算。第 7 章整章都在讲怎么把这块成本压下来，但压完仍然比小模型贵几个量级。高并发场景（搜索引擎排序、推荐召回）每秒几万次调用，这个价差直接决定架构。

第二，不确定的输出会改变测试范式。 传统模型的输出是确定函数，可以做回归测试；大模型带采样随机性，同一个提示两次回答可能不同，质量评估只能统计化（跑几百条样本算通过率），这会把质量保障成本从研发期推到运营期。

第三，能力的边界是模糊且移动的。 今天大模型做不好的精确数值计算、严格格式输出，可能下个版本就好了。选型结论需要定期复核，别把一次评估当成永久结论。

工程上怎么选

把上面的对比收敛成一个决策框架，按顺序问四个问题：

1. 任务是否要求精确与确定？ 风控评分、库存预测、工业质检、强格式输出——要求硬精度和可复现的，优先传统模型或规则系统。
2. 输入是否以自然语言为主、且表达多变？ 用户自由输入的客服提问、评论观点、文档内容——传统模型在这类输入上做预处理非常痛苦，大模型天然适配。
3. 任务是单一稳定还是多样易变？ 单一稳定且已验证的任务，专用模型更便宜；需求频繁变化、长尾任务多的场景，大模型的免重训优势会吃掉推理溢价。
4. 调用频次与延迟预算是多少？ 每秒数万次、毫秒级响应的链路上不适合放大模型；异步生成、人机交互场景则毫无压力。

典型的混合架构长这样：用户自然语言先由大模型做理解与意图识别，抽出的结构化字段交给传统模型做精确打分或检索排序，最后大模型把结果组织成自然语言回复。大模型守"语言接口"两端，传统模型守"精确计算"中间——各干各擅长的事。

⚠️ 常见误区：以为大模型在所有任务上都碾压传统模型。事实上在专精、需要精确数值或强稳定性的任务上，专用小模型常常更准、更便宜、更好审计。为一个二分类任务上大模型，属于用火箭发动机驱动自行车。

动手算一笔账

选型最终落在成本上，值得动手估一次。假设客服意图识别任务，日请求 100 万次：

• 方案 A（微调小模型）：标注 2 万条数据一次性成本约数万元；推理用 CPU 或单卡，单次成本约 0.0001 元量级，日均推理成本百元级。换任务需重新标注训练。
• 方案 B（大模型 API）：免标注，提示词维护；按每次请求 1000 token、单价按主流 API 中位数估，日均推理成本数千元。换任务改提示词即可。
• 交叉点：任务量大且稳定时 A 全生命周期成本更低；任务多变、需要长尾泛化时 B 的总拥有成本反而低。

这笔账里还没算 A 方案的数据漂移维护成本与 B 方案的输出校验成本——两者都真实存在，都要进总账。

一条真实的演进路径

抽象的选型框架配上一个典型的演进故事更好理解。一个电商团队的几年路径，几乎是行业缩影：

起步阶段，他们用规则加传统模型做客服路由——关键词匹配加意图分类器，准确率稳定在八成多，但用户换种问法就失效，维护关键词库成了无底洞。第二阶段，接入大模型接口做意图识别与兜底回复，规则库退居幕后处理高频确定性问题——这就是第一个混合架构：大模型处理长尾表达，小模型处理高频精确。第三阶段，把商品知识与售后政策接进检索增强管线，回复从"话术"升级为"有出处的答案"；同时用微调过的小模型替换通用接口处理高峰流量，成本降了一个量级。

这个路径里值得提炼的规律有三条：先混合再深入，第一次接入不要追求替代，追求共存；知识靠外挂不靠参数，检索增强先于微调；成本优化发生在验证成功之后，先用最贵但最简单的方式跑通，再逐步下沉到便宜的组件。反过来走的团队——第一天就想私有化部署加微调——大多死在了验证业务价值之前。

给技术决策者的三个提醒

第一，把大模型项目当产品项目而非算法项目立项。决定成败的变量排序大致是：场景选择、数据与流程、评估体系、模型与提示词。预算也应按这个顺序分配，而多数新手团队把它完全倒过来，把八成精力花在最末位的模型选型上。

第二，为不可预期性设计。模型输出会漂移、接口会改版、价格会调整、新模型会突然改变最优解。架构上留出模型可替换的抽象层（第 7.3 节的兼容格式就是为这准备的），评测上保持对变化的敏感（第 8 章），这两个慢变量决定你能否以快应变。

第三，用可度量的成功标准立项。"提升客服效率"是愿望，"首次解决率从六成五提到七成五，单次服务成本不超过人工的三分之一"才是标准。没有数字的项目无法判断该扩张还是该止损——这条管理纪律与大模型无关，却决定大模型项目的生死。

常见追问：怎么向管理层解释"不要全上大模型"？

给一个经过验证的沟通框架：先展示成本账（每次调用的单价乘预估调用量，对比现有方案的总拥有成本），再展示风险账（输出不确定性带来的校验人力、幻觉在业务中的代价），最后给出混合方案（大模型处理长尾、现有系统保住主干）的渐进路线。沟通的关键是承认大模型的价值（不要显得守旧），同时把决策拉回数字层面——一旦讨论回到"具体哪个任务、多大调用量、多少预算"，情绪化的"全面升级"主张自然站不住。

再追问：混合架构的边界怎么划？

混合系统最大的工程难题是"路由"——哪类请求给大模型、哪类给规则与传统模型。实践中用三层递进：先按业务显式规则分（涉及支付的必走规则、闲聊走大模型，这两端最清晰）；再按置信度分（传统模型输出的置信度低于阈值时升级给大模型复核）；最后按历史效果分（统计各类请求在两条通道的实际表现，定期调整路由）。三层叠加后，多数请求走便宜通道、少数走昂贵通道，成本与质量的平衡点由数据持续校准。

最后一问：传统模型会被彻底取代吗？

十年内看不到。专精任务上小模型的成本优势是数量级的（第 7 章的成本账），可解释与可审计的属性更是某些行业的准入门槛。更可能的长期格局是"大模型做接口与人机交互，专用模型做规模化的判断与计算"，就像电力系统里既有高压输电也有终端变电——层级化共存，而不是单一替代。把"取代叙事"换成"分工叙事"，你对技术演化的预判会准确得多。

本节要点回顾

• 应用六类：生成、理解、对话问答、翻译与代码、多模态、智能体；RAG 是企业落地最多的形态。
• 对比七维：任务范围、数据需求、训练成本、推理成本、可解释性、稳定性、长尾泛化——大模型赢在通用与泛化，输在贵、慢、黑盒、不确定。
• 选型四问：精度确定性、输入形态、任务稳定性、频次延迟。
• 真实系统多为混合架构：大模型管语言接口，传统模型管精确计算。
• 结论要定期复核：大模型的能力边界在持续移动。

第 1 章的认知地图画完了。第 2 章往下挖地基：线性代数、概率与神经网络这些被本章反复借用的词，终于要给出严格定义。