去年我参与一个风控项目评审业务方提了一个很典型的问题现在大模型都能写代码、读财报、做客服了为什么我们还要保留那套逻辑回归和XGBoost这个问题不是个例。几乎每一个尝试把大模型放进生产系统的团队都会在某个阶段遇到同一种焦虑是不是可以彻底抛弃经典机器学习把所有任务都扔给大模型。我的判断恰恰相反——大模型不会取代经典机器学习真正成熟的做法是让大模型去喂养经典机器学习。这里说的“喂养”不是比喻而是几种非常具体的工作流大模型提供特征、标注、路由和解释经典模型负责稳定、低成本、可解释的预测。两者不是竞争对手而是生产线上的不同工位。1. 这场争论到底在争什么1.1 一个常见的误判有了大模型还需要训练模型吗很多团队产生“大模型可以替代一切”的念头是从一次演示开始的。你拿一段客服工单让大模型判断优先级它给出了正确答案你再拿一段用户评论让它做情感分类它也分对了。于是结论很自然既然提示词就能解决问题为什么还要准备特征、训练模型、做评估这个误判的根源是把“能处理一个样本”和“能稳定处理一类任务”混为一谈。大模型在单个样本上的表现往往是被低估的但在生产环境中的表现往往是被高估的。原因在于生产环境有频率、延迟、成本、可复现性、治理约束而演示环境没有。我曾经见过一个团队用大模型做工单分类线下抽了 50 条数据评测准确率很高。等上线后发现业务方把分类体系从 12 类扩到 40 类提示词越来越长不同写法的大模型输出格式偶尔不一致下游系统解析 JSON 报错率飙升。最后他们还是把分类器换回了经典模型只保留大模型做摘要和解释。这不是说大模型分类不行而是说当一个任务需要持续、高频、稳定地输出结果时经典机器学习仍然有不可替代的位置。问题的关键不是“能不能”而是“该不该”。1.2 生成式任务和预测式任务不是同一个问题大模型最擅长的是开放生成任务摘要、翻译、改写、回答开放式问题。这类任务的共同点是答案不唯一评价标准是“像不像人写的”“有没有信息量”“是否符合事实”。经典机器学习最擅长的是有界预测任务判断一封邮件是否垃圾、一个用户是否会流失、一笔交易是否异常、一条工单属于哪个类别。这类任务的共同点是输出空间有限评价标准是准确率、召回率、精确率、AUC 这类可量化指标。业务系统里大量决策环节其实是预测任务。就算你用大模型生成了一段客户回复文案你仍然需要判断这段文案要不要发、什么时候发、发给谁这种判断可能就是一个分类或排序问题。你可以用提示词让大模型做预测但代价是把一个无界模型塞进一个有界任务里输出不稳定、成本更高、效果难溯源。所以真正重要的不是模型形态而是任务约束。模型的表达能力越强不等于越适合每一项工作。2. 为什么大模型不能直接替代经典机器学习2.1 成本、延迟、稳定性三类硬约束先看一张对比表这张表决定了大部分架构选型对比维度大模型经典机器学习推理速度通常数百毫秒到数秒通常亚毫秒到几毫秒单位成本按 token 计费高频场景成本高批量推理成本低可预测确定性同输入可能不同输出依赖采样参数固定权重下输入输出完全一致可解释性能生成解释文本但属于事后叙述可提供特征重要性、SHAP、单调性约束长尾理解强能处理开放词汇和新表达弱需要特征设计覆盖上下文利用强能感知上下文和隐含语义弱通常只接受固定特征向量工程化复杂度需要提示词、输出解析、守卫、反馈成熟模型注册、回滚、监控都有现成方案为什么成本是硬约束因为预测任务往往发生在“每个请求都要判断一次”的场景里。比如每次点击、每笔订单、每张工单、每条日志。如果一个系统每天有上亿次请求每次请求都调用大模型做一次分类成本会迅速变成一个不可忽视的负担。而同样的任务交给一个训练好的梯度提升树可能只需要几毫秒 CPU 时间。为什么确定性是硬约束因为下游系统需要根据输出来执行动作。你今天判断一个工单是“高优先级”明天同样内容变成“中优先级”业务方就会混乱。经典模型的输出是确定的除非你重新训练或调整阈值大模型则不同即使 temperature 设为 0不同版本、不同并发条件下仍可能出现波动。2.2 可解释性与治理要求在金融、医疗、政务这些领域模型预测结果往往要被人审查。审查者会问为什么这个用户是高风险为什么这笔交易被拦截经典模型可以给出答案因为收入字段低、历史逾期次数多、最近操作频次异常。这些理由对应到具体特征上是可追溯的。大模型也能给出“解释”比如“该用户收入较低且近期操作频繁因此判定为高风险”。但这是一种事后生成的叙述它不一定忠实于实际决策机制。模型内部并不是真的按照这个逻辑算的只是生成了一段看起来合理的解释。在一些强监管场景里这种解释不能被当成合规依据。如果从治理角度看经典机器学习可以做到标准化训练集有版本、权重有记录、特征有定义、输出有日志。大模型则需要额外管理提示词版本、输出格式、拒绝策略、幻觉兜底。不是说做不到而是复杂度明显更高。一个本来可以用统一特征表解决的问题引入大模型之后整个团队都要维护一套新的工具链。2.3 不是能力问题是工作流匹配问题我见过很多团队在讨论“要不要换成大模型”时实际问的不是模型能力而是工作流匹配。因为一个成熟的机器学习系统周围已经围绕了很多基础设施特征平台、训练调度、模型注册、在线推理、监控告警。这些设施都是围绕“输入特征 - 输出预测”这个接口设计的。如果要把全部预测任务换成大模型意味着把原来整齐的接口改成“输入文本 - 等待推理 - 解析文本输出”。上下游系统要改监控指标要改失败重试要改权限审计也要改。这不是模型问题而是系统重构问题。正确的思路不是从“哪个模型更强”出发而是从“工作流里哪一层需要语言智能哪一层需要稳定计算”出发。语言智能交给大模型稳定计算交给经典模型这是混合架构能够成立的底层逻辑。3. 大模型如何“喂养”经典机器学习四种典型工作流3.1 用大模型生成语义特征最常见的喂养方式是把大模型或专门的向量化模型当成特征提取器。一段文本输入进去输出一个固定维度的向量这个向量代表了文本的语义。然后把向量拼接到原来的结构化特征上一起送到经典模型里训练。比如客服工单场景原来的特征可能是客户等级、产品类型、历史工单数。现在你多了工单描述文本传统做法是 TF-IDF 或者手工提取关键词。但 TF-IDF 只看词频忽略语义。“无法登录”和“登录失败了”在 TF-IDF 里是两个完全不同的向量在语义向量里却非常接近。这时候经典模型的价值依然存在它负责把语义向量和结构化特征组合到一起学习它们之间的交互关系。梯度提升树可以直接接收这些拼接后的特征训练完成后仍然能给出特征重要性帮助团队理解哪些信息影响了判断。需要注意的是语义向量不是免费的。维度通常很高如果训练数据量不大可能会导致过拟合。一个稳妥的做法是先做 PCA 降维再和原有特征拼接用验证集判断要不要保留这一路特征。3.2 用大模型生成标注和数据标注成本是很多团队上不了监督学习的原因。大模型可以在这里扮演“弱标注器”的角色把文本丢给大模型让它输出分类结果和置信度然后人工抽样审核。具体流程可以这样设计先取 50 条样本让大模型按预设格式输出标签。人工抽查其中 20 条计算与大模型结果的一致性。如果一致性达到预期再扩大到几百条同时保留人工复核的兜底。把所有大模型标注、人工复核结果统一入库作为训练集。这个过程本质上是用大模型降低标注成本但最终的预测模型仍然是经典机器学习。优势在于经典模型对标注噪声更可控你可以通过置信度过滤、人工复核来清洗标签。如果你直接用大模型做在线预测反而很难做这种离线清洗。大模型还能用来做数据增强尤其是少数类样本。某个异常类别只有 30 条数据可以让大模型基于已有样本改写生成更多相似但不重复的文本。但要注意生成数据不等于真实数据它可能放大了模型偏见也可能引入虚假特征。原则上只能作为补充不能替代真实样本。3.3 用大模型做路由和意图识别混合架构里常见的一种结构是“前门路由”用户输入先进大模型由它判断意图或类别然后把请求分发给不同的经典模型。举个例子一个智能客服系统需要处理退款、物流、账号、产品咨询四类问题。你可以训练四个专项分类器每个模型在对应领域里又快又准。问题在于怎么判断当前问题属于哪一类。如果类别固定且数量少可以用一个小的经典分类器做路由但如果用户表达方式每天都在变经典分类器可能不够用。这时候大模型作为路由器的优势就体现出来了它能理解用户五花八门的表达稳定地输出结构化的意图标签然后把请求交给专项模型。这样你不需要用一个大模型处理所有业务细节只需要让它做“指路”这件事。真正解决业务问题的还是那些专项模型。3.4 用大模型做预测后的解释与行动建议第四种工作流反过来了经典模型先出预测结果大模型负责把结果翻译成人话并给出下一步动作。假设一个风险评分模型输出 0.87 分这个分数本身业务方看不懂。你可以把分数、关键特征、客户摘要一起传给大模型让它生成一段业务人员能理解的风险说明和处置建议。这样预测核心是稳定、可控、可审计的而语言表达部分则由大模型负责。这个模式对很多系统非常实用。因为经典模型的输出是结构化数据大模型的输出是自然语言两者天然互补。你既保留了预测的可解释性又获得了交互的自然性。很多人一上来就让大模型直接生成“结论”结果结论不稳定改成“经典模型打分 大模型解释”之后稳定性问题立刻缓解。四种工作流可以总结成一张表工作流大模型角色经典模型角色典型场景语义特征特征提取器预测核心文本分类、风险评分自动标注弱标注器目标模型标签稀疏的训练集意图路由调度器专项预测器智能客服、多任务分发结果解释解释器决策核心风险评估、工单处置4. 一个实战示例从大模型到经典分类器的混合管道4.1 场景设定与数据说明我们用一个虚拟的客服工单场景来说明完整流程。目标是根据工单文本和客户信息预测工单优先级高、中、低。表格里已经有客户等级、历史工单数、产品类型这几个字段新增的文本字段是客户描述。传统方案是只使用结构化字段训练梯度提升树效果一般因为大量判断信息藏在文本里。更传统的文本方案是 TF-IDF 加梯度提升能利用文本但理解不了语义。混合方案是用大模型生成文本向量拼接结构化特征再训练梯度提升树。先准备数据。假设你已经从业务库里导出了一张表字段包括customer_level: 客户等级字符串需要编码ticket_count: 历史工单数数值product_type: 产品类型需要编码description: 客户描述文本priority: 高/中/低人工标注标签4.2 用大模型生成特征这里给出一个伪代码结构实际实现时你只需要替换成自己的模型服务和向量化接口import pandas as pd from sklearn.preprocessing import StandardScaler, LabelEncoder from sklearn.decomposition import PCA df pd.read_csv(tickets.csv) df df.dropna(subset[description]) # 1. 文本向量化假设 get_embedding 会调用本地或远程的向量化服务 # 返回一个固定维度的 list比如 1024 维 embedding_dim 1024 embedding_cols [femb_{i} for i in range(embedding_dim)] df[embedding_cols] df[description].apply( lambda x: get_embedding(x) ).apply(pd.Series) # 2. 如果训练数据量不大先降维到 64 维避免高维稀疏带来过拟合 pca PCA(n_components64) X_embed_pca pca.fit_transform(df[embedding_cols]) # 3. 编码结构化特征 df[customer_level] LabelEncoder().fit_transform(df[customer_level]) df[product_type] LabelEncoder().fit_transform(df[product_type]) X_num df[[customer_level, ticket_count, product_type]].values X_num StandardScaler().fit_transform(X_num) # 4. 拼接特征 import numpy as np X np.hstack([X_num, X_embed_pca]) y df[priority].values这个代码只负责把特征准备好。实际工程里你可能不会把所有 embedding 直接塞进 DataFrame而是用特征存储服务统一管理。但这套思路是通用的。4.3 训练基线模型与混合模型接下来要同时做几个基线不能只训练混合方案否则你没法证明大模型特征真的有效。建议至少对比三组只用结构化特征。TF-IDF 文本特征 结构化特征。大模型向量特征 结构化特征。训练代码大致如下from sklearn.ensemble import GradientBoostingClassifier from sklearn.metrics import classification_report, roc_auc_score def train_and_eval(X_train, X_test, y_train, y_test): clf GradientBoostingClassifier( n_estimators200, max_depth4, learning_rate0.1, subsample0.9 ) clf.fit(X_train, y_train) y_pred clf.predict(X_test) print(classification_report(y_test, y_pred)) return clf评估指标建议记录在统一模板里方案精确率召回率F1P95 延迟训练时间是否保留仅结构化特征待测待测待测待测待测看基线TF-IDF 结构化待测待测待测待测待测对比大模型向量 结构化待测待测待测待测待测重点考察不要直接看整体准确率要看少数类。在工单优先级里“高优先级”往往是最少数但最重要的类别要单独看它的精确率和召回率。如果混合方案只是整体提升、但少数类掉点需要继续调阈值或者做采样。4.4 上线时的验证清单训练完成不是结束上线前要检查几件事向量服务是否稳定。向量化服务可能有超时、限流、维度变化。建议在调用层做缓存同一段文本不要重复向量化。特征顺序是否一致。训练时拼接顺序是结构化特征 降维向量线上也必须一样否则模型预测结果完全错乱。截断策略是否一致。训练时文本如何截断线上也要保持一致。如果训练时取前 2000 字符线上却传了 5000 字符向量分布会漂移。阈值是否需要单独设置。经典模型输出概率后高低优先级往往需要分别设定阈值而不是默认 0.5。注意不要一上来就把大模型特征直接加入线上全量流量。先灰度一批观察特征分布和预测稳定性确认没有异常再逐步放量。4.5 混合管线的排查链路如果混合模型上线后出了异常按下面的顺序排查不要一开始就怀疑模型效果先看现象是预测不准、接口超时、还是输出格式错误现象不同排查方向完全不同。再看输入文本字段是否完整有没有乱码、缺列、重复数据编码是否统一。再看大模型环节向量服务是否正常返回维度是否和训练一致有没有失败重试失败后是否用了默认向量。再看拼接特征结构化特征有没有做同样的编码和标准化顺序对不对PCA 降维使用的是不是同一套参数。再看经典模型输入特征数量是否正确阈值是否被意外修改模型版本有没有被回滚。最后看业务口径优先级标签的定义是否变化了训练集和线上分布是否已经漂移。这个顺序的核心逻辑是先排除链路故障再检查特征问题最后才怀疑模型本身。很多团队一遇到问题就重新训练模型结果发现是某个字段在线上没有被正确填充。5. 什么样的团队该走混合路线什么样的不该5.1 适合混合路线的三种特征不是所有团队都应该做大模型加经典模型的混合架构。从工程经验看适合的团队通常具备以下特征。第一种已经有结构化数据现在新增了文本类信息。如果业务库里已经有大量数值字段同时需要新增文本理解能力混合架构几乎是必然选择。你不会想放弃已经积累多年的结构化特征体系也没必要让大模型把所有结构化判断都重新学一遍。第二种预测任务高频、对成本敏感。单次大模型推理成本虽然下降很快但高频场景依然不适合全部依赖大模型。混合架构可以只在文本理解这个环节引入大模型最终打分交给低成本的经典模型。第三种需要可解释性和审计能力。银行、保险、医疗、政务等场景里模型决策需要被解释和审查。经典模型作为决策核心大模型作为辅助解释既能满足审计要求又能改善用户体验。5.2 不适合混合路线的情况如果任务本身是纯文本生成比如写摘要、翻译、写营销文案那直接使用大模型就好没必要在外面套一个经典模型。经典模型在这里没有太多可贡献的。如果团队连基础的评估集都没有也没有日志和监控那这时候上混合架构会把问题放大。因为你同时引入了大模型和经典模型两条链路出问题时很难判断是哪一段造成的。先建好数据基础再谈架构升级。如果文本量极少规则就能覆盖那就用规则。不要因为大模型热门就强行引入。技术选型的第一原则永远是匹配问题复杂度。5.3 一个可复用的判断框架我把自己的选型过程总结成一个“四层判断法”每次接到新需求都按这个顺序过一遍判断层要回答的问题指向第一层任务性质输出是开放文本还是有界标签/分数开放文本 - 大模型有界预测 - 经典模型第二层频率与延迟单次调用延迟能否承受几百毫秒不能承受 - 经典模型为主能承受 - 可考虑大模型参与第三层解释要求结果是否需要特征级解释需要 - 经典模型做核心不需要 - 可放宽第四层数据形态纯文本/表格/混合混合 - 大模型做特征、路由、解释经典模型做预测这个框架不是铁律但它能帮你在讨论中快速收敛。大多数业务场景走完四层之后指向的都是混合架构只是混合的方式不同。6. 长期视角大模型和经典机器学习会走向哪里6.1 生产系统的重心正在从“模型选择”转向“系统设计”现在关于大模型生产化的讨论越来越多里面反复强调的一个观点是真正难的不是选哪个模型而是如何把多个组件编排成一个稳定、可观测、可回滚的系统。缓存、重试、路由、评估、守卫、日志、监控这些能力的重要性不亚于模型本身。这个趋势带出一个结果大模型正在变成系统里的一个语言层而经典机器学习变成计算层。用户面对的是一个自然语言界面但在界面背后可能是多个经典模型在承担高频、低延迟、可审计的判断。大模型负责理解用户意图生成中间结果再把任务分发给合适的计算模块。这本质上是一种复合系统。将来判断一个系统是否“大模型化”不再看它是否调用了大模型而是看它是否以大模型为入口然后协调多种计算资源完成复杂任务。6.2 经典机器学习会退到更底层但不会消失有人会觉得这个判断太保守。但从工程演进的历史看技术栈的底层组件通常不会消失只会下沉和标准化。数据库没有因为大数据框架的出现而消失规则引擎没有因为机器学习出现而消失经典机器学习也不会因为大模型出现而消失。它会变成一种更底层的计算单元被封装在更大的系统里。很多外部表现为“大模型应用”的系统内部可能包括检索排序、风险控制、用户分群、内容推荐这些经典模型模块。这些模块单独拿出来看和十年前没什么本质区别差别在于它们现在被一个大模型壳子协调起来了。所以对于工程师来说经典机器学习的基本功不会贬值。特征理解、过拟合判断、评估设计、异常分析、模型治理这些能力在任何时代都有价值。大模型只是新增了一种工具而不是覆盖了所有工具。6.3 给个人的学习建议如果你现在刚开始学习或者正处在转型期不要只盯着大模型提示词技巧。给你一条更可靠的学习路线第一把经典机器学习的基础打牢。理解什么是过拟合什么是偏差方差权衡怎么设计验证集怎么读混淆矩阵。这些会决定你能不能真正判断一个模型好还是不好。第二学会把大模型当成一个能力组件而不是一个答案机器。练习用大模型做结构化输出做文本向量做弱标注做摘要和解释。真正值钱的是你设计接口的能力而不是背提示词模板。第三找一个混合数据场景完整做一遍。找一份带文本字段和数值字段的公开数据集分别训练经典模型、纯大模型方案、混合方案记录三组效果。这个过程会让你对“模型选型”有真实的体感而不是停留在概念争论上。回到开头那个评审会。我给业务方的回答是我们不是在大模型和经典机器学习之间做选择而是在为语言能力和计算能力划边界。大模型擅长理解和表达经典模型擅长稳定和可解释。当你能把两者接起来而不是试图用其中一个打晕另一个这个系统才真正具备了进入生产环境的资格。技术路线总会变但这个分工原则短期内不会变。