LLM不是万能决策器：何时换用专用决策模型？

最近在帮一个团队做智能客服系统的改造，赶上了他们的一次“模型选型复盘会”。会上最扎心的一个问题来自业务负责人：上个月我们给工单的自动分派和优先级判断全部接了LLM，结果账单涨了三倍，分派准确率却下降了两个点，回调日志里还存了一大堆“模型拒绝回答”的记录。

这个问题太典型了。现在很多团队已经把LLM当成了所有问题的万能答案，什么决策都往上挂：库存补货让LLM给建议，汇率风险让LLM评估，甚至风控策略都让LLM来出。不是说大模型不行，而是它根本不该出现在这类负载里。我自己在几个项目里陆续把一批决策负载从LLM换成了专用决策模型，成本和效果都肉眼可见地变好了。这篇就说说我的判断标准和更换思路，至少能帮你少走几个月的弯路。

1. LLM不是万能遥控器：先看它凭什么“会”决策

1.1 LLM真正的强项在哪

先说清楚，LLM确实可以做决策，但这个“决策”和工程意义上说的决策不是一回事。LLM在做的是“基于概率的文本生成”——你给它一段上下文，它预测最像样的下一段输出是什么。决定它输出话语的不是一个明确的优化目标，而是一个巨大的词序列概率分布。

这带来一个特点：LLM特别擅长处理“语义上有歧义、目标上模糊、答案没有唯一标准”的任务。比如帮业务部门起草一个活动方案、把一长段客服对话浓缩成工单摘要、用自然语言回答“供应商延迟了，我们的货物安排该怎么调整”这种开放性问题。这类任务的正解本身就不是唯一的，评判标准是“看起来合不合理”，不是“数学上是否最优”。

所以做智能客服的意图识别开场白、生成答复草稿、做知识库问答，LLM是合适的。因为交互对象是人类，输出的合理度由人来感知，语义连贯性比什么都要紧。它能做的决策其实是“怎么说话、怎么组织内容”的决策。

1.2 LLM决策的隐性成本三座大山

问题出在把LLM用于它并不擅长的结构性决策时，三个成本会一起爆掉。

第一座大山是推理时延。一次LLM调用在大部分托管服务上都要1到3秒，复杂一点的CoT（思维链）提示词能拖到5秒以上。放到高频决策链路里，比如电商的实时推荐、路由器的拥塞控制、工厂里的毫秒级安全联锁，这个时延直接就是不可用的。就算不要求毫秒级，一次用户请求背后如果依赖三次LLM串行决策，用户体验也会被拖成一坨。

第二座大山是费用。按Token计费这件事在生成大量文本时尤其烧钱。决策任务往往只想要一个结论，但LLM必须先“写”一大段思考过程。团队里常见的情况是，一个月调用了几十万次LLM做同一类判断，结果逻辑上只是几行if-else的事，成本却高到财务来问话。

第三座大山是置信度漂移。LLM没有置信度的概念。它不是像决策树那样基于统计概率给出带有置信区间的结果，而是对每一个输入都给出一个看似笃定的答案。同一个问题换个措辞，它能给出相反的判断。这在线上风控、库存补货这类场景里是致命的——用户不会知道模型今天心情好不好，但月底的损失会知道。更麻烦的是，LLM的“幻觉”问题在决策链路上会被当成有效输入继续往下传，错误的代价会一直累积。

所以我的基本判断是：凡是要“反复、高频、同一标准、可验证”地做决定，先不要碰LLM。做生成、做理解、做开放问答，才是它的主场。把这两个边界划清楚，很多选型问题其实已经解决了一半。

2. 五张“换人”信号表：什么样的负载该用专用决策模型

在实际项目里，我不会一上来就劝人换模型，而是先看负载是否亮起下面的信号灯。任何一个亮了，我都建议认真研究专用决策模型的替换方案。

2.1 信号一：决策标准是否长期稳定

如果一个负载的决策逻辑在几个月内基本不变，比如判断“订单金额大于5000且客户信用等级在B以上就走人工审核”，那这段逻辑的稳定性极高。LLM的优势在于吸收变化和不确定性，但代价是“同一规则它今天和明天执行得不一样”。专用模型或者干脆是规则引擎，最核心的价值就是确定性——相同的输入永远给出相同的输出。

这种负载用LLM是纯赔本买卖。维护时你要一遍遍调提示词才能让输出稳定，而提示词本身就是一种没有版本化管理、难以做单元测试的东西。把稳定规则从提示词里剥出来，用确定的代码或统计模型去承载，是性价比最高的一步。

2.2 信号二：决策是否具备硬约束

现实中有一大类决策是带约束条件的：比如生产排产不能让两台机器同时处理同一个工单，配送路径要在规定时间窗内到达且不超过车辆载重，广告投放预算不能超支。这类问题是典型的“约束满足问题”和“组合优化问题”，经典算法如分支定界、线性规划、约束规划可以保证在给定条件下找到最优解，或者至少在可行解中挑选最好的。

LLM面对约束时表现非常糟糕。它不是不会算，而是它没有“可行解”的概念，会一本正经地给出违反约束的结论。你很难通过提示词让模型无论多复杂都严格守住约束。换个角度，给LLM一个包含上万个变量和上百条约束的排产问题，它连近似解都给不出稳定的。而这类问题正是OR-Tools这类求解器的老本行。出现硬约束，基本就是和LLM说再见的时候。

2.3 信号三：对时延和吞吐是否有明确要求

我做过一个供应链需求预测的接口，业务方要求99分位响应时间不超过150毫秒，而且需要在每秒几百个请求的峰值下保持稳定。一开始的方案是先尝试用LLM读历史数据并给出预测，但实测下来明显撑不住；后来换成梯度提升树模型，训练好之后每次预测就是一次数组运算，P99时延只有8毫秒，吞吐量上升了两个数量级，GPU不再被占满，晚上也不用提心吊胆地看账单。

需要理解的是，LLM的推理过程无法离线“预制”。它每次都要重新跑一遍网络前向计算。而专用决策模型——无论是线性回归、决策树还是一个简单的查表——在部署后的推理路径都非常短，很多甚至可以做到零依赖单机运行。当负载对时延和并发有明确指标时，专用模型天然就是对的选项。

2.4 信号四：是否要求决策过程可解释、可审计

金融风控、医疗辅助决策、司法辅助建议这类领域，对决策逻辑的可解释性要求几乎是法律级别的。为什么这笔交易被拒？为什么这个患者被分到高危组？业务方必须能给出明确、可核验的理由。LLM给出的答案在今天依然是个概率黑盒，虽然有人在做可解释性研究，但远远达不到生产审计的要求。

反观逻辑回归、决策树、规则引擎，每个特征对输出的贡献方向和大小都是可以计算和展示的。甚至某些线性模型可以直接用一个公式来表达全部决策逻辑。只要把这类负载挪到专用模型上，合规方来检查的时候，摆出一份特征贡献表就够了。这不是LLM能承诺的东西。

2.5 信号五：预测目标是否可以被量化评估

最后一个信号最容易被忽略：你的负载有没有明确的评估指标？比如库存补货，评估指标就是缺货率和库存周转率；点击率预估，评估指标是AUC或LogLoss；推荐排序，评估指标是NDCG。只要目标能被量化，就一定存在一个可以针对这个指标反复优化的专用模型。

LLM的问题在于它很难被针对某个指标“调优”。同一组测试集上，你今天跑一遍、明天跑一遍，结果就有波动。开发专用模型时可以反复跑离线评估，迭代特征和超参数，直到指标不再变化。每次改动都能量化看到涨跌。这种闭环优化能力，是LLM目前给不了的。

3. 判定方法论：用“决策四问”快速对负载分诊

3.1 四问分诊：结构、频率、成本、失败代价

我不太建议拿着大而全的框架去套所有负载，项目里时间永远不够。所以我把判断逻辑浓缩成四个问题，每次评审会就靠它拍板。

第一问：这个决策的输入输出是否是结构化数据？输入是数字、类别、布尔值，输出是一个确定性的标签或数值，这样的决策天然应该是程序化处理的。第二问：一个决策在业务生命周期里会发生多少次？如果是几十万次，必须用极低边际成本的方式去做。第三问：一个错误决策的直接代价是什么？是浪费一点算力，还是会造成库存积压、资金损失？第四问：业务方需要的是一个“答案”，还是一段“解释和讨论”？如果是前者，给准确答案就行；如果是后者，才需要LLM的生成能力。

这四个问题问完，方向就基本确定了。我一般会画一张表把所有负载列出来，逐条打分。如果“结构化程度高、发生频次高、失败代价大、只需答案”，这个负载毫无疑问要上专用决策模型，没有任何含糊空间。

3.2 分诊后的分流矩阵

为了避免主观判断，我用一个简单的二维坐标来归类：横轴是输入输出结构化程度，纵轴是决策交互复杂性。落在右下角（结构化、复杂交互）的任务，比如多轮谈判策略生成，可以先用LLM做整体框架再人工校验；落在左上角（非结构化、简单决策）的，用LLM做分类带一点生成能力也尚可；落在左下角（结构化、简单决策）的任务，什么模型都不用，直接规则；而真正要重点替换的是右下角往中间靠的“结构化、但决策本身有复杂约束或优化需求”的任务。

这一块我用一个表格总结经验：

这张表不是学术标准，是我从几个实际项目里总结出来的经验谱系，大概率能覆盖大部分常见负载。

3.3 量化收益预估：换之前先算账

决定要不要换，最后还得算一笔账。我会在迁移前用一周的线上流量做统计：这一周LLM决策的总调用次数、总Token费用、平均时延、错误率（通过人工抽检得到）。然后用专用模型做同一批历史数据的离线回放，测出预期的时延和准确率，再乘以同样的调用量，得到替换后的预估费用。

我之前一个工单分类负载，一周LLM调用是38万次，费用折合人民币约2100元，P95时延2.8秒，人工抽检准确率92%。换成BERT分类模型后，一周推理成本基本就是一台普通GPU服务器费用的很小一部分，P95时延降到200毫秒，准确率经过几轮调优到了96%。这一组数字拿出来，业务方不用再听你讲任何大道理，直接用计算结果就同意迁移了。

成本账一定要算，因为很多团队卡在“模型崇拜”上，总觉得LLM才是先进方案。拿出一组真金白银的数字，比说服力强一百倍。

4. 从调LLM到换模型：落地迁移的七个工程动作

4.1 第一步：建立负载清单和分诊记录

开始动手前，把目前线上所有调用LLM的决策点列出来。不要只列接口名，要具体到每个决策点的输入、输出、调用频次、上游和下游模块。这一步看起来很基础，但很多团队连自己的LLM调用点都没梳理全，散落在各个服务的代码里。

这一步的产出是一张负载登记表。这张表的价值会贯穿整个迁移过程，后面每次灰度验证和性能对比都要依赖它。我在每个项目里都会保证这张表的字段足够完整，包括：业务部门、负责人、决策类型、稳定规则占比、平均输入token数、平均输出token数、日调用量、单次时延、错误处理逻辑。

4.2 第二步：双跑与影子模式

不要直接切换。稳妥的做法是让新旧方案并行跑，新方案只记录结果，不真正影响业务。这叫影子模式。

实现方式很简单：在原有的LLM决策调用之上加一层路由，流量还是照常走LLM，但同时把同样的输入发给专用决策模型。两个结果都记录下来，业务方看到的还是LLM的输出。这一步只为了做对比评估：统计专用模型与LLM在相同输入下的结果差异、执行时延、资源开销。我当时跑了整整两周影子模式，收集了足够多的样本之后，才根据对比结果进入真正的灰度切换。

4.3 第三步：灰度切流量

影子模式证明专用模型的效果达标后，不要一次性切100%，按5%、20%、50%、100%的节奏切。每切一档，要看三天指标：决策准确度（通过抽检和下游反馈反推）、时延、上下游系统报错、用户投诉量。

这里有一个经验：灰度切换的观察期不能只看主指标，要把“下游改动量”也当作信号。如果切到某种流量比例后，下游的处理逻辑频繁出现不符合预期的分支，那说明专用模型的某些输出模式与原先LLM不同，需要先修下游兼容逻辑再继续切。

4.4 第四步：建立回归基线

这一步是我特别想强调的。专用决策模型上线后，要把历史数据和决策结果整理成一个离线回归集，每次改动模型或规则都要用这个集合跑一遍回归。没有回归基线的模型迭代，就像在雷区散步，你不知道哪一步会炸。

实操中，我一般会用过去三个月的真实请求做分层抽样，组成一个包含边界情况的测试集。测试集不要太大，几千条足够了，但必须覆盖各种极端输入。比如工单分类就要覆盖“信息为空”“全是噪音字符”“长度超过上限”这些情况。把这些情况固化成测试用例后，每次模型改动都要过一遍完整回归，允许有预期的指标变动，但必须解释清楚变动原因。这个习惯救过我很多次，有一次新版本模型在所有正常样本上都表现更好，但在边界样本上直接漏了一个关键分类，最后是靠回归基线拦下来的。

4.5 第五步：监控指标不能只看准确率

准确率只是一个面。迁移后的监控体系至少要覆盖四个维度：调用侧（时延、错误率、超时率）、决策侧（结果分布、置信度、与旧方案的差异度）、成本侧（单次决策费用、日均费用）、业务侧（下游反馈指标、人工介入率、最终业务结果）。

我在监控里特别关注的是“决策结果分布漂移”。例如，补货模型给出的补货量建议，过去LLM经常给出的数值区间比较宽，换成专用模型后数值区间变得集中，这种分布的改变往往意味着业务方需要适配新的决策习惯，若不提前打招呼，上线头一周业务人员会有不小的困惑。

4.6 第六步：预留快速回退机制

换模型再顺利，也要在代码里提前埋好回退开关。最直接的办法是用配置中心做开关，一旦新方案出现问题，可以立即把流量全部切回LLM或其他旧方案，整个过程不需要发版、不需要重启。

我的习惯是回退机制永远放在上线清单的第一优先级。不是不相信新方案，而是生产环境里发生什么都可能，停电、上游数据源变更、特征缺失，都可能让专用模型表现异常。有回退兜底，团队心里不慌，试错的胆子也更大。

4.7 第七步：沉淀调优机制

很多团队把模型一上线就当成结束，这是大忌。专用决策模型的价值需要通过持续迭代释放。上线后要驱动一个简单的飞轮：每天记录预测结果与实际结果的差异，每周生成差异分析，每月基于差异调整特征和阈值。

以库存补货为例，专用的统计模型上线后，它预测的补货量会与实际销量产生差异，这个差异就是调优信号。如果发现某个品类长期被低估，说明该类目的特征没有充分表达，这时候解决的是特征工程问题，而不是反复调整提示词的问题。这种“看数据、改特征、验证指标”的闭环，是整个专用决策模式的核心。

5. 三个真实案例复盘：从翻车到换方案

5.1 案例一：库存补货从LLM到时序预测模型

这个案例来自一个做日化品电商的朋友团队。他们最早的库存补货决策直接让LLM读取过去三个月的销量数据，然后输出一个补货建议。表面上看很合理，直到遇到一个典型的翻车场景：某款洗衣液因为一次促销活动销量暴涨，LLM读到的数据里包含了促销期的异常值，给出的下一期补货建议直接翻了四倍，导致仓库积压。团队再去看提示词，发现压根没有让模型识别促销因子，也没有异常值处理逻辑。

替换方案是用一个带节假日和促销事件特征的时序预测模型，例如Prophet或者LightGBM加时间特征。模型可以显式引入“是否有促销”这个变量，还能在特征工程里对促销期销量做衰减加权，避免历史峰值污染常规预测。换完后补货准确率提升明显，更重要的是，每个预测都有特征贡献度可以回溯，业务侧可以清楚地知道“这个补货量是受上周促销影响的”。这类负载换完以后，后续再也没有出过离谱的积压。

5.2 案例二：工单分派从LLM到分层分类器

这是我开头提到的那个智能客服团队的工单分派负载。原方案是让LLM阅读工单内容，判断业务类型、紧急程度和负责团队，一条龙完成。做到后面发现三个问题：偶发的分类漂移让同类型工单被分到不同团队，原因不可解释；高并发时LLM的时延拖慢了整体工单流转；费用随着工单量增长降不下来。

我们重构的做法是把它拆成两层：第一层用传统文本分类模型（轻量级BERT或FastText）做业务类型初判；第二层用规则引擎根据用户等级、合同类型、历史响应SLA（服务水平协议）来定优先级和分派团队。只有机器分派置信度低于阈值时，才让LLM介入做人工辅助判断。这样90%的工单走快速通道，剩下10%的疑难工单才用LLM，成本降下来，分派稳定性和可解释性双双提升。这个案例最能说明“混合路由”的思路，不是二选一，而是让合适的引擎处理合适的负载。

5.3 案例三：故障根因定位从LLM到因果图与规则推理

还有一个算比较硬的案例。在某内部运维平台上，原来的告警根因分析让LLM读日志然后猜测故障源。结果在真实故障时，LLM给出的根因判断时对时错，关键原因是它无法把不同告警之间的时序和拓扑关系做逻辑推理。它看到服务A报错、服务B也报错，就猜测是服务B的锅，完全没有意识到服务B是服务A的下游，真正的问题出在服务A的数据库连接池耗尽。

我们后面的做法是把告警数据送到一个基于拓扑关系的推理引擎里，维护一张服务依赖图，用规则和路径传播算法定位故障源头，然后在推理结果的基础上，再让LLM生成一段自然语言的故障解释报告。这样定位由专用推理引擎完成，可复现、可验证；LLM只负责把结论“翻译”成人话。这个改动之后，根因定位的准确率从62%提升到89%，而且每次结论都有推演路径可以复核。它说明：LLM可以作为“表达层”，但决策核心不能交给它。

6. 常见误区与排查建议

6.1 误区一：专用决策模型=“倒退”

我遇到过不少研发同学，觉得用规则和传统机器学习模型是技术上的倒退，没有LLM听起来高级。但工程不是求酷，是求稳和求值。逻辑回归、梯度提升模型、整数规划这些方法在工业界跑了十几年，稳定性早就被验证过了。它们不落后，只是没有出现在热搜上。

6.2 误区二：先让LLM跑起来再说，以后换

这个想法在项目快速启动时有一定道理，但代价很高。LLM一旦嵌入业务流程，后续换方案的阻力就会大幅增加，原因是业务方已经习惯了和它交互的方式，甚至围绕它的输出格式做了下游适配。替换时要连这些适配一起改，成本往往数倍于当初。正确的做法是启动时就做一次“决策负载分诊”，把该用专用模型的负载直接分出来，不给LLM留犯错的空间。

6.3 误区三：换模型只改代码，不改流程

把LLM换成专用模型，表面上是改代码和配置，实际上改的是业务侧的工作习惯。LLM输出的是自然语言段落，人可以一眼看出“它在说什么”；专用模型输出的是数字或标签，业务人员必须经过一定训练才能理解它的含义和边界。上线前要给业务侧做必要的培训，说明模型的判断依据和置信度含义，否则会出现“这个数字我不敢用”的阶段。

6.4 排查建议：如何判断切换后是否真的成功了

迁移是否成功，至少看三个信号。第一是成本信号，单次决策成本是否有量级下降；第二是质量信号，抽检准确率或人工介入率是否改善；第三是效率信号，P95时延和吞吐量是否达标。

但最容易被忽略的其实是“团队精力”这个信号。迁移完成后，模型维护工作是不是变得更简单了？问题是出现在特征工程和模型迭代上，还是仍然要花大量精力在“堵 prompt 漏洞”上？如果是后者，说明迁移不彻底。我个人的经验标准是：一个决策负载迁到专用模型后，日常维护工作量至少下降一半，才说明这次迁移是值得的。如果维护量没有下降，那只是换了个方式继续受罪。

另外我强烈的建议是：不要把所有的决策负载一次性迁移。稳扎稳打，一个月迁一个负载就很不错了。每次迁移都要把它当成一个小型项目来做，配置监控、写文档、做培训，全部走完流程，再启动下一个。我在实际项目里见过太多次因为“这次很简单”而跳过了监控配置，结果上线第二天出了问题才发现没有任何日志可以排查的窘境。

还有一个细节很多人没意识到：换了专用模型以后，上游的数据质量反而成了主要矛盾。LLM对输入数据的容错性相对较高，一些脏数据它会自动忽略或合理化；而专用模型对数据缺失和异常值特别敏感。所以迁移前一定要先把数据质量监控补上，对特征缺失率、取值范围、分布漂移做告警，否则模型上线后会让你在上游数据问题上忙得焦头烂额。

我踩过的一次印象很深的坑，是一次把“供应商交货评分”这个决策从LLM换成梯度提升模型，模型在测试集上表现得很好，但上线后前一周的评分分布明显异样。查了两天才发现，上游有个系统在两年前停止更新某个字段，而这个字段恰好在模型特征里权重很高。LLM时代根本没人注意这个字段是空的，因为它会“猜”一个合理的解释继续处理，而专用模型直接把这个缺失值当成一个真实的负向信号带入了计算。从那以后，我把“特征质量监控”列为了所有专用模型上线的前置条件。

目前我的团队内部已经形成了一条不成文的规定：任何新决策负载立项时，必须先在需求单里回答“它是生成型任务还是判定型任务”。判定型任务默认走专用决策模型，只有确实需要生成自然语言、或者需要开放式语义理解时，才允许评估LLM方案。这条规定落地之后，我们整体LLM成本下降了约七成，而业务指标并没有下滑，有些指标反而提升了。

所以如果你还在纠结某个负载是不是该继续用LLM，不妨直接从这几个角度去衡量：输出是结构化还是开放文本、决策是否符合硬约束、时延和成本是否受控、结果能不能被量化评估，以及团队是否有精力长期调prompt维护稳定性。把这几个问题想清楚，该换就换，不必手软。