企业落地AI:大模型、传统模型,还是两者结合?

企业准备引入 AI 时，需要回应的需求往往很具体：客服希望少花时间查资料，业务部门希望预测更准，管理者则要考虑投入是否值得。大模型让不少工作有了新的做法，但这些需求未必适合用同一种技术解决。已有系统要不要换，也需要拿实际效果来比较。

以售后服务为例，客户说“机器刚到就有异响，能不能直接换一台”，看起来只是一个问题，处理起来却要查订单、了解故障、核对保修条款，最后才能决定是否换货。能把回复写得清楚，只完成了其中一部分工作。对于企业来说，更值得关心的是：从收到请求到办完这件事，究竟能少花多少时间，少出多少差错？

把这件事拆开，几种技术的用处就容易理解了。大模型可以帮助理解客户的表述、整理资料和拟写回复；判断设备异常，可能还要分析传感器数据或图像；保修期限由订单日期和规则计算；创建换货单则要核查权限。一个项目里，完全可以让不同的方法分别承担合适的工作。

大模型带来的收益已经有实证研究，但结果也说明，使用它的人和任务同样重要。《经济学季刊》2025 年发表的一项研究，观察了 5,172 名客服人员使用生成式 AI 辅助工具的情况，平均每小时解决的问题数增加了 15%。收益主要集中在经验较少、技能较弱的人员；最熟练的员工收益较小，部分质量指标还有下降。这是单家企业的研究，员工生产率的提高也没有被直接等同于利润增加。

研究来源：Brynjolfsson、Li、Raymond，《Generative AI at Work》，《经济学季刊》，2025 年正式发表版。

因此，企业既有理由尝试大模型，也需要认真比较其他办法。对某类工作有效，不代表适合所有工作；一套方案能否长期使用，还要把数据准备、人工复核和运行费用一起考虑进去。

几种技术，各自擅长什么

预测一个商品下周能卖多少，与回答客户为什么不能退货，对系统的要求很不一样。前者需要从历史数据中寻找规律，后者需要读懂客户的问题，再对照有效的业务规则。企业选择技术时，可以从这些具体差别入手。

如果企业已经有交易、客户、设备或经营数据，希望预测一个数值，或者识别某一类情况，经典机器学习通常值得先试。逻辑回归、决策树、梯度提升树都属于这一类。它们围绕明确的目标学习，比如预测需求、找出值得复查的交易，或判断哪些客户更可能流失。

图片里的缺陷、振动信号里的异常，则可以考虑任务专用深度学习。模型围绕图像、语音、时序、推荐等任务训练或调整，把能力集中在特定工作上。这里的“专用”指它要解决什么问题，模型未必很小，也不一定要从零训练；在预训练模型的基础上做迁移学习，同样是常用办法。

面对客户描述、长篇文档和多样的提问，大语言模型，也就是 LLM，提供了另一种做法。它借助预训练获得的语言与知识能力，再通过提示词、检索资料、调用工具或微调，适应企业的任务。多模态模型还可以接收图像等输入。许多过去难以逐条写成规则的语言工作，由此可以较快做出原型，交给使用者试用。

这些名称之间有交叉：LLM 在技术上也属于深度学习。把它单独拿出来比较，是因为企业采用通用 LLM，与围绕特定任务训练、调整模型，在数据准备、开发方式和运行成本上有不同的取舍。实际项目可以组合使用，没必要只选一类。

候选方案也应随研究进展更新。2022 年一项覆盖 45 个数据集的基准研究发现，树模型在其考察的典型中等规模表格任务上仍有优势。2025 年的 TabPFN 研究则表明，经过预训练的表格基础模型，在论文设定的小中型数据范围内也能取得很强的表现。两项研究对应不同的模型和条件，不能据此认定树模型永远领先，也不能推断通用聊天模型已经擅长所有表格预测。

研究来源：Grinsztajn 等，树模型与深度学习的表格数据对比研究，NeurIPS，2022；Hollmann 等，TabPFN 表格基础模型研究，《自然》，2025。

时序领域也有 Chronos-2 这样的专用基础模型，用预训练能力处理预测任务。它与让聊天助手读一串数字、猜下季度销量，在任务设计上有明显区别。视觉、表格和时序基础模型，都可以按实际需求纳入比较。

资料来源：Amazon Science，《Introducing Chronos-2: From univariate to universal forecasting》，2025 年 10 月 20 日。

图 1｜LLM 属于深度学习。企业可以按任务比较几条应用路线，也可以在同一项目中组合使用。

放到日常工作中，差别才会显现

数据需要准备到什么程度

做经典监督学习，通常需要历史样本和可靠的标签。标签就是样本对应的结果，例如某个客户后来是否流失。如果今天把流失定义为“三十天未购买”，明天又改成“合同到期未续约”，数据再多，模型也可能学错目标。任务专用深度学习还可能需要标注缺陷、覆盖不同工况，或专门安排数据采集；迁移学习、自监督学习和异常检测则能减少部分标注工作。

LLM 的起步方式更灵活。不少语言任务给出少量示例，就能先试起来。但企业的产品规则、合同口径和最新政策，仍然需要有人整理和维护。文档权限、版本管理、验收样本也不能省。少量样本足以帮助探索一种做法，却未必足以证明它适合日常使用。

这会影响项目的投入顺序。传统模型可能在开始训练前就要花较多时间整理数据；LLM 原型可以更早出现，但随着试用深入，团队仍要补齐资料和评估依据。预算只算到演示完成，很容易漏掉后续工作。

业务变了，模型能否跟着变

任务稳定、输出明确时，专用模型可以围绕一个目标反复优化。响应时间、单位时间能处理的任务数、判断阈值和资源占用，也更便于针对这项工作细调。相应的代价是，业务一变，原有的数据特征、标签和训练方法可能都要调整；面对没有见过的输入，效果也可能明显下降。

LLM 对语言变化的适应性更强。客户换一种说法，或者需要从多份文档里整理信息，模型仍有可能理解意思并给出说明。这适合需求和表达还在变化的工作。可如果任务只是把大量工单分到固定的几个类别，通用能力带来的收益，就要与额外的运行费用和结果波动一起比较。

所以，处理文本也可以先试专用方法。垃圾信息分类、工单分流，既可以测试把文本转成向量后配合轻量分类器，也可以测试专用语言模型和 LLM。表格任务则可能用到 LLM 的辅助：先把不规范的文字描述整理成字段，再交给预测模型。选择要看每一步的实际贡献。

怎样判断结果是否可靠

不同模型都有可能出错。传统模型会误判，也可能因为新数据与训练时不同而失效；LLM 还可能写出看似合理、实际没有依据的内容。NIST 的生成式 AI 风险框架将这类虚构内容列为需要管理的风险。

资料来源：美国国家标准与技术研究院（NIST），《生成式人工智能风险管理框架配套文件》，NIST AI 600-1，2024。

让答案按表格或 JSON 等规定格式输出，能方便系统读取，却不能保证其中的内容正确。检索增强生成，也就是 RAG，可以让回答参考外部资料，但还要检查找到的是不是有效条款、有没有用对适用条件。附上一条链接，也不代表那份资料真的支持回答中的结论。

研究来源：Lewis 等，《Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks》，NeurIPS，2020。

解释结果时也有类似的问题。逻辑回归的系数较容易检查，复杂树模型和神经网络通常需要额外分析；即便知道某个因素对预测影响较大，也不能据此认定它是原因。LLM 写出的推理说明，同样未必忠实反映了内部判断过程。解释可以帮助复查，结论本身仍要验证。

模型给出的分数也要经过检验。分类器输出 0.9，不意味着相应样本就一定有九成正确；让分数与实际正确率相符，是概率校准要解决的问题。LLM 自称“有九成把握”，更不能直接成为允许办理业务的依据。企业应在独立样本上检查分数、正确率和拒绝处理之间的关系，再决定分数达到多少才能采用结果。

研究来源：Guo 等，《On Calibration of Modern Neural Networks》，ICML，2017。该研究讨论神经网络概率校准，不是对当前 LLM 自报置信度的测试。

开发和长期运行，各要花多少钱

调用 LLM 接口，往往能缩短语言类原型的开发时间。日常使用时，费用却与多项因素有关：一次要检索多少资料、送入多长的上下文、调用几次工具、失败后是否重试，以及还需要多少人工复核。用户等待检索和业务接口的时间，也要算进响应时间，不能只看模型多快开始输出。

专用模型可能在前期投入更多数据准备、训练和集成工作。等任务固定、调用量足够大，较低的单次运行成本才有机会摊薄这些投入。究竟多大的业务量值得调整方案，要根据硬件利用率、模型大小、任务难度和服务要求测算，很难套用一个统一数字。

把模型放在哪里运行，也要另算一笔账。私有部署可能符合企业的数据和环境要求，但需要承担闲置算力、容量预留、升级、监控和人员费用。使用外部接口，则要核查数据使用约定、可用性、版本变化，以及将来更换服务的成本。选哪种模型、怎样部署，需要分别作判断，再看它们能否配合。

图 2｜图中列出的是选择候选方案时的参考倾向。实际比较仍要使用同一批业务样本和同一套验收要求。

从业务目标到上线决定

比较方案时，可以先把不能接受的情况列清楚，排除不合适的做法，再看余下方案的效果和成本。这套流程是本文的实践建议。它保留每一项判断的依据，避免一个看似漂亮的总分掩盖了关键问题。

把期望改成可以验收的目标

“提升客服智能化水平”很难用来验收。一份更有用的任务说明，应写清处理哪些工单、结果给谁使用、允许自动完成到哪一步，以及怎样才算办好一单。业务负责人确定期望的结果，技术负责人说明实现条件，双方共同确认验收口径。

比较的起点是当前流程，包括每单耗时、首次解决率、返工率、人工复查量和成本。节省处理时间当然有价值，但还要看这段时间去了哪里。如果人员总成本没有变化、业务量也没有增长，短期收益可能体现为更充裕的服务能力或员工时间，不能直接算成节省了同额现金。

有些要求必须先满足

数据只能留在指定环境，系统响应必须跟上生产节拍，金额不能算错，某类操作只能由授权人员批准。这些要求应事先写清，并安排相应的测试，不能等其他指标都做出来以后再补。

方案达不到要求，就要改变部署方式、减少自动处理的范围，或者暂缓上线。后果严重的错误，也不能因为预计发生得少，就被平均收益抵消。需要人工复核的环节，还得确认复核者能看到依据、有时间检查，并且有办法拦住错误操作。

看清数据里有什么，又缺什么

如果目标是预测数值或类别，要看结果标签是否可靠、历史数据能否代表今后的业务。如果目标是回答问题，要看事实能否追溯、资料是否及时更新。无论哪类任务，都应检查重要人群、产品和工况是否在样本中得到覆盖。

标签尤其值得追问。过去被人工拒绝的申请，未必都是真的高风险；推荐系统只从有过曝光的商品获得反馈，也会影响它学到的规律。LLM 可以帮助自动标注，但需要抽样复核，不能把模型自己的判断反复当成正确答案。

数据之外，有些问题还要由业务部门先解决。政策互相矛盾，就要确定采用哪个口径；缺少合法可用的数据，就要先补齐数据条件。否则，模型输出的结果仍会带着这些未解决的问题。

给简单方案一个公平的比较机会

明确的计算可以写程序，固定条件可以用规则，找原文可以先试搜索。排产和库存分配还可能需要约束优化：预测需求，与决定如何分配资源，是不同工作。Google 的机器学习工程指南也建议，在需要时先用简单规则建立产品和度量，再引入更复杂的方法。

资料来源：Martin Zinkevich，《Rules of Machine Learning》，Google for Developers 工程指南。

预测和识别项目，至少应拿一个合适的经典或专用模型作比较。语言项目，则可以从搜索、模板、专用语言模型和 LLM 中，选择可行的方案测试。若主要问题是缺少知识，就先补充来源和检索；若需要稳定的格式或行为，再考虑微调。经常变化的企业事实，仍适合放在可更新、可核查的资料系统里。

混合方案也在比较范围内。不过，每加一个环节，都要说清它改善了什么，同时计入接口故障、错误传递和维护工作。如果简单做法已经达标，再增加一个模型就需要有足够的理由。

在相同条件下，看看谁能把工作做好

用于调试的样本，要与验收样本分开。来自同一客户、设备、文档或订单的高度相似记录，应按业务关系分组，避免一部分用于调试，另一部分又进入验收。预测任务按时间划分训练和验收区间，再沿时间滚动回测；每个时点的训练、调参和输入，都只能使用当时已经获得的信息。

这意味着未来才发生的退款、维修结果或销量，都不能提前出现在数据里。验收还要保留少见但重要的情况，例如过期政策、缺失字段、模糊图片、冷门产品和无法回答的问题。LLM 任务可以对部分样本重复运行，观察同一输入是否产生明显不同的结果；接入文档和工具后，还要测试恶意指令、越权请求及外部接口故障。

评价标准跟着业务走。预测除了误差，还要看缺货和积压的影响；分类要看误报、漏报，以及在现有人力下能查出多少问题；问答要检查关键事实、引用是否支持答案，以及何时应该拒答。自动化流程则要追查业务系统最终生成了什么记录，不能仅凭回复通顺就判定成功。

结果报告应同时列出合格率、自动处理覆盖率、转人工比例和总工时。难题全部转给人，自动回答的正确率可能很好看，却未必省下多少工作。样本不足时，也要说明结果有多大不确定性；一批样本中没有出现错误，不能证明日后不会出错。

质量过关后，再核算成本

满足质量和必要条件的方案，才值得继续比较经济性。月度成本可以分为两部分：固定部分包括开发与数据投入的摊销、基础设施和维护；随业务量变化的部分包括推理、检索、工具调用、复核与返工。

总成本除以按同一标准完成的合格任务数，就是每项合格任务的成本。未完成和转人工的任务，也应在报告中交代。返工之后仍可能留下的错误损失，能估计的另行列出，同时避免把同一次错误的返工费用重复记账。不可接受的风险，即使发生概率低，仍然要按前面约定的要求处理。

比较到这一步，应当能作出一个具体决定：采用规则、专用模型、LLM 或混合方案，或者继续试点、暂缓。将适用范围、负责人、验收记录和回退方式一起留下，今后任务、数据或模型版本变了，才知道需要重新检查什么。

图 3｜先检查必要条件，再比较效果与成本。采用规则、保留人工或暂缓上线，也可以是评估后的合理选择。

把复核和返工也算进成本

假设两套工单处理方案面对同样的业务，每月完成 10 万单，最终质量也相同。人工成本按每分钟 1 元计，复核与返工是不同工作，不重复记账。用这组假设，可以看看调用费用之外的支出怎样改变选择。以下金额均为演示数字，不是厂商报价或项目实测。

方案 A 主要调用 LLM：固定成本每月 2 万元，每单技术运行费用 0.10 元；20% 的工单需复核，每单两分钟；另有 2% 需返工，每单五分钟。月度成本为 2 万＋1 万＋4 万＋1 万，共 8 万元，每单 0.80 元。

方案 B 采用专用模型与 LLM 分工：固定成本每月 4 万元，每单技术运行费用 0.03 元；8% 的工单需复核，每单两分钟；另有 1% 需返工，每单五分钟。月度成本为 4 万＋0.3 万＋1.6 万＋0.5 万，共 6.4 万元，每单 0.64 元。

按这些假设，A 的成本可以写成“2 万元＋0.60 元×单量”，B 是“4 万元＋0.24 元×单量”。两者约在每月 5.56 万单时持平。如果业务只有 1 万单，A 的成本是 2.6 万元，B 是 4.24 万元，前期投入较少的方案反而更便宜。

复核比例变了，结论也可能改变。假如 B 的复核率从 8% 升到 16%，处理 10 万单的月度成本就会升至 8 万元，与 A 持平。业务量增加带来的优势，需要建立在相应的质量和复核要求上；多出来的人工工作，可能抵消节省的运行费用。

企业自己的测算还要计入可能遗漏的集成费用、超时处理、容量预留和可估计的错误损失。把关键假设调高或调低，看看哪项变化会让结论反转，比只算一个平均值更有用。这个例子预设最终质量相同，才可以直接比较成本；质量不同，就要回到前面的验收要求重新判断。

图 4｜全部数字为演示假设。固定成本已按月计入；技术运行费用包含模型与配套调用，复核、返工分别核算。

换一个场景，选择也会变化

企业知识问答：资料能否支持答案

员工面对分散的政策、产品说明和操作手册，有时只想找到原文，有时则需要综合几份资料，判断具体该怎么办。后一类需求适合测试检索与 LLM 的组合：模型理解问题、整理证据和组织回答，文档系统管理权限、有效版本和原文位置。

这也解释了为什么普通搜索仍值得比较。如果员工只需要找到一份文件，生成一段回答未必更方便。需要综合条款时，再检查答案是否漏掉适用条件，引用能否支持结论，以及找不到依据时是否停止回答。

文档质量差、版本冲突多、权限不清，就先把资料整理好。问题高度固定时，持续维护的问答条目也可能够用。验收应看员工完成任务一共用了多久，单看答案长短或对话轮数，很难说明是否改善了工作。

需求预测与风险识别：结果要对应实际决定

零售商预测下一周各商品的需求，可以比较季节性基线、梯度提升树和专用时序模型，数据条件合适时再加入时序基础模型。预测时已经知道的促销计划可以使用，未来实际销量不可以。结果还要按品类、门店和促销期拆开看，否则平均误差下降，可能掩盖重点商品缺货增加的问题。

风险识别也要考虑后续怎样处理。如果一天只能安排人工复查一百笔交易，就应比较这一百笔里能发现多少真实问题，以及还会漏掉多少问题、误伤多少正常业务。正常样本占比很高时，总体准确率容易显得漂亮，单看这一项不够。

如果关键信息藏在投诉、维修记录或不规范的文字说明里，可以让 LLM 提取有原文依据的字段，再交给预测模型。提取环节带来的额外错误若超过收益，就应取消这一做法。还要分清预测与干预：模型发现了相关性，不等于某项运营措施就一定能改善结果，措施本身仍需要验证。

工业视觉质检：先看缺陷能否拍清楚

工位和零件固定、缺陷定义清楚时，可以从成像条件与专用视觉模型开始。光照、镜头、分辨率和取样方式，决定图像中是否有足够的信息。裂纹如果只留下模糊的几个像素，换更强的语言模型也无法凭空获得可靠依据。

缺陷标签少，也不代表没有可尝试的办法。MVTec AD 的经典设定是训练集提供正常图像，测试集同时包含正常和异常图像。但公开数据集上的表现，只能帮助了解方法，不能直接当成某条产线的误检、漏检水平。

资料来源：MVTec AD 数据集官方说明及原始论文，Bergmann 等，CVPR，2019。

验收要覆盖不同批次、设备和光照条件，检查重点缺陷漏检率、误剔除率，以及整套系统的处理时间。多模态 LLM 可以用于测试异常说明、维修知识辅助，或更开放场景中的理解任务；若要让它承担核心判定，也必须在产线条件下证明能力。

客服与流程处理：让各个环节接得上

回到开头的换货请求。LLM 可以整理产品、症状和客户诉求，缺少订单号就补问；业务接口查询真实订单和库存；有数据和验收依据时，专用模型可以提供故障或风险判断；规则负责核对资格、期限和额度。

给客户的说明可以由 LLM 起草，金额计算和状态更新则交给业务系统。关键字段无法核实，就转人工处理。提交操作时还要检查权限和重复请求，避免一次重试生成两张换货单。出了问题，记录应能帮助查清用了哪条政策、哪项模型结果，以及是谁批准的。

图 5｜示意架构。专用模型有数据和验收依据时才接入；模型输出仍须经过业务系统的权限与执行校验。

这样的分工需要付出集成和维护成本。组件越多，等待时间和故障点也可能增加。如果查订单、套用少量规则就能处理大部分请求，用简单系统加必要的文本辅助即可。是否保留一个模型环节，应看它有没有改善从接单到办结的整项工作。

试点之后，怎样决定是否继续

一张简洁的决策表，可以把讨论留下来。试点开始前，写清任务范围、当前基线、不可接受的错误、数据来源、候选方案、验收方法、成本假设和负责人。质量、自动处理覆盖率要达到多少，峰值负载下允许等多久，人工能接管多少任务，也应提前约定，并注明验收样本量或观察期，以及批准人。

这样，试点结果出来以后，团队就有事先确认的标准可以对照，不必再从结果里挑选有利的指标。推进时可以先回放历史任务，排查明显错误，再让系统接收真实输入、暂不影响业务决定，也就是影子运行。达到约定标准后，再限定范围试用；没有达到，就继续验证或缩小范围。

评估收益时，能随机分组就采用同期对照；做不到时，尽量让参与比较的任务难度、人员经验和业务时段接近，并说明还存在哪些干扰。人工复核所花的时间、修改了什么、最后是否仍然出错，也要记录，定期抽样检查已通过的任务。点击了“确认”，并不等于这单一定正确，尤其是复核者只看到了答案、没有看到依据的时候。

试点结束前，日常维护的责任也要有人接下。业务负责人确定可接受的结果，数据负责人维护来源与口径，技术团队负责版本、部署、日志和回退，使用者记录失败样本。Google 的生产就绪评估研究也强调，生产系统需要的测试和监控，远不止离线模型效果。

研究来源：Breck 等，《The ML Test Score》，IEEE Big Data，2017。

持续观察的内容包括输入变化、质量抽检、人工接管、延迟和单位成本。如果真实结果要过一段时间才能知道，可以先看已有的运行信号，等结果到来再补做评估。传统模型要留意数据特征和标签的变化；LLM 系统还要维护提示词、知识库、检索配置及模型版本。每次升级，都应回放关键样本，检查有没有出现新的错误。

回退安排还要处理已经发生的业务后果。发现越权或重复建单时，可以暂停自动提交，把待处理工单转人工；技术团队恢复已验收版本，业务负责人核对并处理已经产生的错误记录。仅仅恢复模型版本，不会自动撤销错误订单。

如果任务逐渐稳定、业务量增加，人工修正也积累成了可靠样本，就可以测试更小的模型或蒸馏方案。仍要保留独立验收集，不能把模型生成的数据全部视为正确标签；调整后，也要重新计算整项工作的成本。需求还在频繁变化时，继续保留较灵活的方案也可能合适。

图 6｜本文建议。立项、试点验收和重大版本变更时都可填写，保留每次决定的依据与责任人。

最终留下的选型记录，应该让接手项目的人看得明白：这套方案适用于哪些业务，满足了什么要求，成本怎么算，哪些情况出现后需要重新评估。下一次业务或技术发生变化，就能从已有记录和新的失败样本继续判断，而不必重新争论哪一类模型更先进。