先聊一个我最近常被问到的场景：社区小店的老板想做个“智能助手”，让我帮忙优化提示词，结果他每次问“今天店里还剩多少豆子、要不要补货”这类问题，大模型都能煞有介事地回一大段，可细看数字全是编的。这其实是很多团队绕不过去的坎——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 给不出可审计的解释，哪怕你强制它输出推理过程，那也是模型编出来的，不是真实的决策依据。轻则被监管挑战，重则吃诉讼。

四条标准总结成一张自查表，拿去对：

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 案例：内容审核初筛用规则 + GBDT，LLM 只做辅助

内容审核是个特殊场景——直接上 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% 四步走，每一步观察至少一个完整业务周期。如果发现错误率或者人工复审率升高，马上回滚路由配置，不用重新发布代码，只要把流量切回旧链路就行。

灰度期间的监控指标，至少要覆盖这五组：

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”，而是一套分层的组合方案。

最后分享一个小技巧：不管用的是什么模型，决策结果一定保留原始特征快照和模型版本号。线上出了问题，直接把当时的输入特征调出来重算一遍，十分钟内就能定位是数据问题、模型问题还是规则问题。这套习惯救过我很多次，比任何复杂的监控面板都管用。