先聊一个我最近常被问到的场景社区小店的老板想做个“智能助手”让我帮忙优化提示词结果他每次问“今天店里还剩多少豆子、要不要补货”这类问题大模型都能煞有介事地回一大段可细看数字全是编的。这其实是很多团队绕不过去的坎——LLM 看起来啥都能回答但一旦涉及需要精确计算、严格规则、高速响应的决策它就原形毕露了。这篇文章咱们就掰开揉碎聊清楚LLM 到底适合扛什么负载什么场景必须换专用决策模型以及从 LLM 迁移到专用模型时架构、评估、踩坑该怎么做。内容是我在实际项目里反复折腾过的经验尽量讲得直白省得你在生产环境里走弯路。1. LLM 做决策看着能行其实每一行都在花钱1.1 三种最常见的“LLM 决策”实现方式代价都不小很多人第一反应是“让大模型直接给结论”最常见就这几种玩法第一种是Few-shot Prompt把几个历史决策案例塞进上下文让模型照着给新决策。看似省事但每个 token 都是成本上下文越长延迟和费用越是线性往上飙。你塞进去 5 个案例一次调用花掉的 Token 可能比正常对话多出几十倍。第二种是Chain-of-Thought让模型“先分析、再下结论”。这确实能提升一点复杂问题的正确率但 Token 消耗直接翻倍甚至翻三倍而且模型输出结果是流式的你没法预估一次调用到底吐多少字。对在线接口来说这个时间波动很要命。第三种是Function Calling/Tool Use让 LLM 先判断“该调哪个工具”再把工具返回的结果揉进回答。这种方式最接近工程落地但本质上你还是把“决策”这个责任外包给了一个概率模型——它决定调哪个工具本身就是一次可能出错的决定。如果这一步错了后面全错你还得多加一层校验逻辑。1.2 算一笔账一万次请求的成本能差出多少咱们算笔具体的账。假设每天有一万个决策请求每次请求给 LLM 的上下文大约 2000 token输出 300 token。按比较常见的 API 价格粗算单次调用成本大约在 0.01 到 0.03 元之间一天就是 100 到 300 元一个月下来 3000 到 9000 元。这还只是纯接口费用。如果你做的是在线实时决策还得考虑延迟——单次 LLM 调用普遍要 1 到 3 秒稍微复杂点加上工具调用可能到 5 秒以上。很多业务根本等不了这个时间。换成专用决策模型呢一个 LightGBM 或者逻辑回归单次预测在毫秒级成本接近于零而且延迟几乎恒定。1.3 LLM 的真正强项恰恰不是“拍板”说了这么多不是要全盘否定 LLM。它对意图理解、开放域对话、内容生成、信息抽取这类任务确实有不可替代的优势。但“决策”这件事要求的是可复现、可解释、可审计、低成本、低延迟——这五个词几乎每一个都踩在 LLM 的短板上。经验之谈如果一个负载的核心矛盾是“算得准”、“回得快”、“成本稳”那它大概率不该交给 LLM 拍板。LLM 适合做“理解”这层不适合做“决定”这层。2. 什么负载该换专用决策模型先看这四条硬指标别一上来就聊模型选型先把“要不要换”这个问题想清楚。我总结了四条判断标准你拿业务场景一条条对基本不会跑偏。2.1 延迟敏感型50 毫秒和 2 秒之间隔着一道天花板在线交易的反欺诈、广告的实时竞价RTB、风控的实时拦截这类场景对延迟的要求不是“别太慢”而是“必须快”。广告竞价有的要求 50 到 100 毫秒内返回决策LLM 一次调用就以秒计还没算网络抖动和排队。直接判死刑。反欺诈也是一样。用户点一下支付你让风控等三秒再决定拦不拦用户体验直接崩掉而且这三秒里可能已经发生盗刷。这类场景的决策模型老老实实上规则引擎加梯度提升树特征算好之后就是一组 if-else 加一次模型打分毫秒级出结果。2.2 成本敏感型量大、毛利薄每一个 token 都在吃利润库存补货、物流调度、会员营销触达、内容推荐排序……这些场景的特点是请求量巨大单次决策能带来的利润却很薄。拿优惠券发放举例一次券包推荐决策的边际收益可能只有几毛钱如果每次都用 LLM 生成个性化推荐语光接口费就把利润吃光了。更别说日志分类、工单自动打标这种每天几十万、上百万次调用的场景用 LLM 简直是往水里扔钱。2.3 确定性要求型链路错一步后面全是事故生产排程、设备参数调优、财务对账、库存上下限控制这些场景要的不是“合理的建议”而是“满足约束条件的最优解”。LLM 的问题在于它给出的答案经常“听起来很对”但数字是幻觉出来的。库存计算差一个单位在制造业可能就是一次停产事故。这种场景必须使用确定性算法——线性规划、约束求解、动态规划或者直接上规则。结果可复现、可回溯错在哪一步证据链清清楚楚。2.4 安全合规型不可解释的决策等于没有决策金融信贷审批、医疗辅助诊断、法律文书审查这类行业对决策有硬性的合规要求你凭什么拒绝这个客户这个判断依据什么规则、什么特征、什么阈值LLM 给不出可审计的解释哪怕你强制它输出推理过程那也是模型编出来的不是真实的决策依据。轻则被监管挑战重则吃诉讼。四条标准总结成一张自查表拿去对判断维度适合专用决策模型可以继续用 LLM响应要求毫秒级恒定低延迟秒级无硬性时限单次成本预算接近零与请求量无关按 token 计费可接受输出确定性同输入同输出可复现允许语义多变解释性要求必须提供决策证据链只需参考性建议调用量级十万级/日以上几百到几千级错误容忍误判有真金白银损失有兜底审核机制3. 换什么专用决策模型不是只有“深度学习”一条路很多人一听“专用决策模型”下意识觉得要上多复杂的深度网络。真不是。所谓专用是指在特定约束下做得又快又稳的任何模型。3.1 五个常用选项选型先看数据量第一类是梯度提升树家族XGBoost、LightGBM、CatBoost 这哥仨。结构化表格数据的霸主特征工程做得好小数据量也能打训练快推理更快。我大部分决策类项目首选就是它。第二类是逻辑回归/线性模型。基线模型之王适合特征稀疏、需要强解释性的场景。金融风控里很多评分卡就是逻辑回归每个特征的权重就是明明白白的系数监管来了直接摆桌上。第三类是强化学习。注意这只适合“决策序列”类问题比如推荐流排序、游戏 AI、机器人路径规划。单次决策用它属于杀鸡用牛刀而且训练成本高、调参地狱团队没有专门的 RL 经验慎入。第四类是运筹优化。线性规划、整数规划、约束规划。排产、物流路径、资源分配这类带硬约束的决策用优化求解器比任何机器学习模型都靠谱。不是所有决策都需要“学”很多是“算”。第五类是检索式决策/kNN。当你有大量历史优质决策案例新请求来了直接找最相似的历史案例套用当时的决策。这招在客服应答、工单处理建议上特别好用配上一个 Embedding 模型做相似度检索既能保留个性化又不需要每次重新生成。3.2 案例库存补货从 LLM 换到 LightGBM 运筹约束我帮一个零售客户做过一次迁移。原来他们的补货建议是运营人员手动做后来试过让 LLM 根据销售数据“写建议”结果每次给的数量都是拍脑袋没一次对得上动态安全库存。迁移方案分两层LightGBM 负责预测未来 7 天的销量输出一个预测值和置信区间运筹优化模块负责根据预测值、当前库存、在途库存、最小起订量、供应商交期求解出“最优订货量”和“建议订货日期”。整个链路每天凌晨跑一次批处理决策时间从秒级降到毫秒级补货准确率提升后库存周转天数降了约 8%。3.3 案例客服路由从 LLM 意图识别换到 Embedding 轻量分类器还有个典型的场景是客服工单分流。最开始我们尝试用 LLM 判断用户意图再路由到对应部门效果好但成本扛不住高峰期同一秒进来几百个工单全走 LLM 接口直接排队。后来改为两步走先用一个 Embedding 模型把用户问题向量化再用一个轻量的分类器比如逻辑回归或浅层 MLP做意图分类。Embedding 这一步虽然也跟“大模型”沾边但它属于特征提取不是决策主体。决策主体换成了毫秒级、几乎零成本的小分类器准确率反而更稳定因为分类器只接受固定维度的向量输入不会像 LLM 那样被长文本带偏。3.4 案例内容审核初筛用规则 GBDTLLM 只做辅助内容审核是个特殊场景——直接上 LLM 判断“这个文本有没有违规”成本高而且尺度飘忽。更稳妥的做法是第一层规则引擎拦截明显违规词敏感词、广告链接、手机号第二层 GBDT 模型对文本特征、用户历史行为特征打分区分“确定合规”、“可疑”、“确定违规”只有落到“可疑”这一档的样本才升级给 LLM 做语义层面的深度审核或者直接转人工。这样做的好处是90% 的流量在最便宜的两层就解决掉了LLM 只处理少部分疑难样本成本可控而且每一层都有审计日志出了纠纷能回溯。4. 混合架构落地路由、灰度、监控一步都不能省4.1 第一步给系统装一个“路由闸门”最现实的方案不是“全换”或“全不换”而是做成一个混合架构。前面用一个路由模块判断当前请求该走哪条链路规则引擎、专用模型、还是 LLM。路由判断本身不用复杂模型几条策略加一组阈值就能完成。伪代码大概是这个意思def route(request): # 1. 耗时敏感型请求直接走专用模型 if request.latency_sla_ms 100: return rule_engine # 2. 规则明确先试规则 if rule_engine.can_handle(request): return rule_engine # 3. 高风险/高价值需要语义理解的走 LLM if request.risk_level 0.8 or request.need_semantic: return llm # 4. 默认走专用模型 return gbdt_model路由层要单独监控因为路由错了后面全部白费。我会把路由的 decision 也写进日志跟最终结果一起复盘。4.2 第二步评估别只盯准确率要算“决策损失”换模型的评估口径不能只有 accuracy。决策类任务要重点看“误判代价”也就是错了这一单到底损失多少钱。比如信贷场景把坏人放过去是坏账损失把好人拦下来是收入损失两笔账差别很大。所以评估标准要设置成总决策损失 误放损失 误杀损失 人工复审成本这比准确率有用得多。在正式上生产之前务必跑一段“影子模式”也就是让新模型和旧逻辑并行跑新模型的决策只记录、不生效。攒够至少一两周的样本把新模型和旧逻辑的决策放在同一份数据上对比看差异率有多少再决定要不要放量。4.3 第三步灰度放量的节奏灰度不是三分钟就能完成的。建议按 1% → 10% → 50% → 100% 四步走每一步观察至少一个完整业务周期。如果发现错误率或者人工复审率升高马上回滚路由配置不用重新发布代码只要把流量切回旧链路就行。灰度期间的监控指标至少要覆盖这五组监控维度关键指标告警阈值参考决策质量误判率、人工复审率复审率超过旧链路 2 倍即告警延迟P50 / P99 响应时间P99 超 200ms 持续 10 分钟告警成本单次请求成本、日均总成本预算超支 120% 告警稳定性接口错误率、超时率错误率超 1% 触发熔断业务指标转化率、拒付率、库存周转偏离历史均值 2 个标准差4.4 换完之后的成本长什么样一个量化对比再回到前面那个一万次请求的例子上。原来每天一万个决策请求全走 LLM一天成本按 150 元算。换成分层架构后规则引擎拦截掉 60%零成本剩余 4000 个请求走 GBDT按一台普通 CPU 服务器跑均摊成本几乎可以忽略只有最难的 5%500 个请求走 LLM每天成本约 7.5 元。一个月下来成本从约 4500 元降到约 300 元以内延迟还从秒级变成了毫秒级。这还没算节省下来的时间以及因为决策更准而减少的业务损失。5. 踩过的坑逐个给你列出来5.1 坑一小样本硬上深度模型不如先跑基线有人一看“上模型”就直接搬来一个 Transformer 或者深度网络结果训练集只有几千条样本模型过拟合得一塌糊涂线上表现比简单规则还差。我的建议是先跑一个带特征工程的 LightGBM 或者 XGBoost配上合理的交叉验证把基线成绩打出来。如果基线已经能解决业务问题了就别往复杂里折腾。在决策模型里“贵”不等于“好”稳定才最重要。5.2 坑二评估只盯“准确率”漏了“误判代价”准确率是个会骗人的指标。欺诈场景里如果欺诈率本来就只有 1%你模型全判“正常”准确率也有 99%但业务已经亏到姥姥家了。一定要从业务损失出发定义评估指标。把混淆矩阵拆开看每一类错误对应的真实代价是多少加权之后才是模型真正的好坏。5.3 坑三把 LLM 的“偶尔正确”当成能力这是最隐蔽的坑。LLM 在决策任务上偶尔会给出惊艳的回答于是团队就有了一种错觉这模型真聪明有些决策比我拍脑袋强多了。但生产系统要的不是“偶尔惊艳”而是“稳定不崩”。我在项目里见过太多次这样的场景模型在 10 次决策里对了 9 次团队很开心直到那错误的 1 次出现在核心客户身上把前面省下的成本全赔回去还倒贴。LLM 的强项是“生成”决策系统要的是“一致性”。这俩就不是一回事。5.4 坑四路由阈值拍脑袋定上线后被极端情况打穿路由层的阈值看似简单实际上最容易出问题。比如你设“风险分数大于 0.8 走 LLM 深度分析”结果某天因为外部原因风险分数整体飙升大量请求涌进 LLM 链路成本和延迟瞬间爆掉。方案是给每条链路都加独立的“容量上限保护”到了上限就自动走降级路径比如直接走规则引擎宁可决策粗糙一点也不能让系统挂掉。5.5 坑五换模型的同时忘了建特征平台很多团队犯的错误是拍板换模型之后发现拿不到像样的特征数据。决策模型 90% 的工作量其实是特征工程——清洗、聚合、时效性管理。没有好的特征平台再牛的模型也是白搭。建议先把特征计算和存储做成独立服务在线离线统一口径决策模型才能稳定迭代。6. 我的最终判断别把 LLM 当“万能决策机”它是“语义接口”如果你问我大模型在决策系统里到底该站在哪个位置我的答案是它应该是“接口”不是“大脑”。大脑是规则引擎、优化求解器、梯度提升树它们稳定、可控、可解释出了问题能定位能修复。而 LLM 最适合做的是最前面那层——“这个人到底想要什么”也就是把模糊的、开放的、多义的输入转成结构化的、机器能处理的任务描述然后把决策权交还给专用模型。我在实际项目里的习惯是接到一个决策需求先问五个问题——这个决策允许延迟多久单次决策能接受多少成本错了的代价是什么需要给监管或客户解释吗请求量每天有多少五个问题问完该走哪条路基本就清楚了。多数情况下答案都不是“直接调 LLM”或“上一个 DNN”而是一套分层的组合方案。最后分享一个小技巧不管用的是什么模型决策结果一定保留原始特征快照和模型版本号。线上出了问题直接把当时的输入特征调出来重算一遍十分钟内就能定位是数据问题、模型问题还是规则问题。这套习惯救过我很多次比任何复杂的监控面板都管用。