最近看了不少团队把 LLM 当成万能药什么负载都往上塞人机交互也让它做内部状态判断也让它做连个加减乘除的决策都要走一次大模型。我理解这种冲动毕竟一个接口能处理自然语言、能泛化、能“看起来聪明”谁不想省事。但做系统不是写 Demo很多决策负载放进 LLM 里短期看得见效果长期全是坑。这篇就把我自己的选型思路和踩过的坑整理一下聊聊哪些负载真的该换专用决策模型以及怎么搭一个“快慢分离”的混合决策架构。先说结论LLM 的优势在语义理解、开放域泛化和生成式交互而决策系统的核心诉求往往是确定性、低延迟、可解释、可控成本。这两者天然有冲突。把冲突的负载硬塞给 LLM等于让一个擅长开脑洞的创意总监去当流水线质检员不是不能干但成本高、稳定性差、出了问题还说不清。真正靠谱的做法是先做负载分类再决定每类负载走哪条路径。1. 别让 LLM 扛下所有先看三类“伪需求”我先说三个我在实际项目里反复见到的场景。这三类负载乍一看都能用 LLM 解决但仔细拆解之后你会发现它们更像是“伪需求”——真正的解法在 LLM 之外。1.1 高频短延迟决策Token 生成再快也追不上查表第一类是高频短延迟决策。典型例子是智能客服里的“下一步动作选择”和电商系统的“实时推荐排序”。我一个做客服系统的朋友曾经把所有对话分支都用 LLM 判断用户说“我要退款”LLM 判断出意图后再让 LLM 决定“该调用退款接口还是转人工”。每次决策多花 1.5 到 3 秒高峰期并发一上来token 费用像水龙头一样哗哗流。更麻烦的是LLM 对同一个输入的回答会有抖动——今天返回“调用退款接口”明天可能返回“建议转人工”因为模型有采样温度、上下文微小变化都会影响输出。这种不确定性对一个生产级客服系统是不可接受的。这类负载真正的解法是查表和规则意图识别用 LLM 做一次粗分类然后“下一步动作”直接查一个状态机映射表。状态机清晰、可测试、毫秒级返回成本几乎为零。LLM 只需要在状态机无法覆盖的开放域对话里补位。1.2 强一致与低容忍错误概率生成是双刃剑第二类是强一致、低错误容忍的决策。比如金融领域的审批决策、风控规则判断、权限校验。这些场景通常有明确的合规要求每个决策都要能追溯为什么拒绝、依据哪条规则、阈值是多少。LLM 是一个概率模型它的输出本质上是“最像正确答案的文本”不是“经过严格推理得到的结果”。你问它“这笔交易是否异常”它能给你一段看起来合理的分析但这段分析无法保证每次都对同一个输入给出同一个结论更无法保证它引用的规则真实存在。我见过一个团队把风控预警的判断交给 LLM结果有一次模型因为上下文里偶然出现的一个词把正常交易判成了高风险后续的审计流程完全无法解释模型的决策依据。最后他们花了两周时间把所有规则重新改成硬编码阈值判断LLM 只做规则之外的辅助分析。这个项目我印象非常深它让我意识到一个原则凡是决策结果需要审计、需要稳定复现的场景默认不要用 LLM。1.3 数值优化与规划求解大模型不擅长精确计算第三类是数值优化与规划求解。比如仓库的订单分配、运输路径规划、排产调度。这些问题的本质是在约束条件下求最优解适合用运筹优化算法、动态规划、图搜索来解。LLM 的数学能力虽然一直在提升但它在本质上仍然是“下一个 token 预测”做不了精确到小数点后几位的数值优化更无法保证输出是全局最优解。举个例子一个物流项目里团队想用 LLM 直接生成“最优配送路线”结果模型给出的路线从直觉上看没问题但计算后比普通贪心算法还多了 8% 的里程。问题不是模型不聪明而是它没有真正在做搜索与验证只是在“模仿”一个最优解的样子。这类负载正确的做法是把它抽象成数学模型用成熟的求解器OR-Tools、Gurobi 等或者启发式算法去解LLM 最多做“自然语言描述到结构化约束”的转换不做最终的方案生成。2. 为什么 LLM 在决策负载上“物理上”不合适前面说的三类伪需求背后其实有三个结构性原因。这些原因不是调参能解决的而是模型架构和工作方式决定的。2.1 概率采样和确定性要求的根本冲突LLM 的推理过程是概率采样给定输入 token 序列模型计算下一个 token 的概率分布然后按一定策略采样。温度大于 0 的时候同样的输入可能得到不同的输出就算设成 0在浮点计算、批处理等因素影响下输出也可能有细微抖动。而决策系统的第一性原理是确定性相同的输入必须产生相同的输出这样系统才能测试、才能审计、才能预期。这个冲突在“规则可穷举”的场景里最明显。如果某个决策可以用 10 条规则覆盖全部情况规则引擎的执行结果是可证明的而 LLM 的结果只是一个“大概率相同”的猜测。把确定性需求交给概率模型本质上就是让系统的正确性建立在概率上这在实际工程里非常危险。我自己的经验是如果一个决策的判断逻辑能写成分支条件if-else、决策表、状态机那就不要用 LLM。LLM 的泛化能力在开放域是优势但在封闭域里反而是负担——它会把一些本不该有的“灵活性”带进来。2.2 成本曲线线性调用和边际成本的现实账再说成本。很多人在方案设计阶段只看单次调用的价格觉得“一次几分钱不贵”。但一旦流量上来这个账就不是这么算了。假设你的系统每天处理 100 万次决策每次决策调用一次 LLM平均输入输出 1500 token按市场价大致估算单次成本 0.002 到 0.005 元一天就是 2000 到 5000 元一个月 6 万到 15 万元。这还只是模型调用费没算网关、重试、错误处理、日志存储的成本。而用规则引擎或者查表100 万次决策的成本几乎可以忽略——就是一次内存查询或一次函数调用。更关键的是延迟成本。规则引擎的决策通常在微秒到毫秒级别LLM 的首 token 延迟至少几百毫秒完整生成可能要几秒。在用户可感知的交互链路里这多出来的几秒会直接转化为流失率。有些团队为了压延迟用更小的模型、做量化、搞缓存折腾一圈最后还是不如直接用专用决策模型来得干脆。2.3 可解释性与审计决策系统的隐形刚需第三点是可解释性。很多决策场景——尤其是涉及钱、权限、合规的场景——要求每个决策都能被审查为什么是这个结果依据了什么条件。规则引擎天然满足这个需求因为它的每条规则、每个条件都可以被记录和重现。LLM 则像一个黑盒你只能看到输入和输出中间过程无法精确还原。即使你用 Chain-of-Thought 让它“逐步思考”那也只是模型生成的文字不是它真实的推理过程。我在实际项目里还发现一个更微妙的问题LLM 的“解释”往往是事后合理化。你问它为什么做这个决策它会生成一段听起来很合理的分析但这段分析和它实际做出决策的计算过程未必一致。如果审计人员拿这段解释当依据可能被误导。所以在需要严格审计的场景里不要依赖 LLM 的可解释性宁愿让规则引擎来兜底。3. 那什么负载才真正值得上 LLM说了这么多 LLM 不能干的不代表我反对用 LLM。恰恰相反LLM 在决策链路里有很多不可替代的位置。关键在于你要认清它适合什么然后把它放在合适的位置上。3.1 开放域语义理解与意图解析LLM 最擅长的是开放域语义理解。传统规则引擎解决不了的问题比如用户说“我上次买的那个黑色的东西能退吗”这句话里没有明确的商品 ID也没有明确的订单编号规则引擎只能靠关键词硬匹配效果很差。LLM 可以结合上下文理解“黑色的东西”指的是“黑色款蓝牙耳机”并且判断用户的意图是“退货咨询”。这个能力是规则引擎无法替代的。这类负载适合 LLM是因为它的本质是“把非结构化输入映射到结构化意图”而 LLM 恰好是文本到语义的最佳映射器。在实际项目中我通常把 LLM 放在入口做意图分类和实体抽取输出结构化的 JSON然后让下游状态机决定具体执行逻辑。这样 LLM 负责“理解”规则引擎负责“决策”各司其职。3.2 规则无法穷举的长尾场景还有一些场景规则的组合空间太大无法穷举。比如个性化推荐里的“内容偏好理解”你没法写几千条规则覆盖每个用户的兴趣组合再比如“质检工单分类”工单的写法千奇百怪规则模板很难覆盖所有表达方式。这类场景适合用 LLM 做初筛和聚类再结合人工审核。LLM 在这里的价值是“覆盖面”和“泛化能力”。它不需要精确只需要把大多数情况打对标签把长尾情况兜住。但注意LLM 的输出在这里通常是“候选集”而不是“最终决策”最终决策还是要由确定性逻辑或人工把关。我管这个叫“LLM 做草稿规则做终审”。4. 负载分类与选型判断框架有了上面的分析我在实际项目里会用一个简单的框架来给负载分类然后决定每个负载走哪条路径。这里分享一个最简版本。4.1 一张表看清四类负载负载类型典型场景决策特征推荐方案LLM 的角色规则判定型权限校验、风控阈值、流程分支规则可穷举、需确定性规则引擎 / 决策表不参与或仅做前置语义解析数值优化型路径规划、排产、资源分配约束最优解、需精确计算运筹优化 / 启发式算法将自然语言转为约束条件状态决策型客服对话状态转移、任务流程管理状态有限、转移明确状态机 / 工作流引擎意图解析、槽位填充开放理解型情感分析、文本分类、相似匹配语义开放、无标准答案LLM / Embedding 模型主力角色这张表的逻辑不是按“业务领域”分的而是按“决策特征”分的。你面对任何一个负载先问自己三个问题规则能穷举吗结果需要确定性吗计算精确度要求高吗如果三个问题的答案里有至少一个“是”那就要慎重考虑上 LLM。4.2 选型判断的五个筛子我把判断过程进一步细化成五个筛子每个负载过一遍这五个筛子基本就能确定该不该上 LLM。第一筛延迟要求。如果端到端延迟要求小于 500 毫秒LLM 很吃力直接走专用模型。第二筛成本敏感度。如果单次决策成本预算是几厘钱LLM 大概率超预算。第三筛确定性要求。如果相同输入必须产生相同输出LLM 不合适。第四筛可解释性要求。如果决策需要审计追溯LLM 不合适。第五筛规则可穷举性。如果规则能覆盖 95% 以上场景先用规则引擎。这五个筛子不用按顺序过但有一个是“一票否决”的确定性要求。只要这个负载明确要求确定性输出那就别考虑 LLM 了直接换专用决策模型。我在前面提到的风控场景就是典型哪怕其他条件都合适确定性这一关过不了一切免谈。5. 实操构建“快慢分离”的混合决策架构理论讲完了说点实操。我在实际项目里搭过一套“快慢分离”的混合决策架构基本思路是把 LLM 放在慢路径把规则引擎放在快路径用一个路由器Router在两者之间做分流。这里分享一个最小可用的实现思路。5.1 一个最小可用的 Router 示例Router 的核心职责是判断当前请求走哪条路径。最简单的实现就是一组优先级规则先判断是否能被规则引擎覆盖如果能就直接走规则如果不能再上 LLM。# router.py import json class DecisionRouter: def __init__(self, rule_engine, llm_handler, coverage_checker): self.rule_engine rule_engine # 专用决策模型规则引擎 self.llm_handler llm_handler # LLM 处理器 self.coverage_checker coverage_checker # 规则覆盖检查器 def decide(self, context): # 第一步快速路径——规则引擎能覆盖就直接决策 if self.coverage_checker.is_covered(context): result self.rule_engine.execute(context) return { path: rule, result: result, confidence: 1.0, latency_ms: result.latency_ms } # 第二步慢路径——规则覆盖不了才走 LLM llm_result self.llm_handler.process(context) # 第三步LLM 结果经过校验器不合法就降级到默认策略 if llm_result.is_valid: return { path: llm, result: llm_result.payload, confidence: llm_result.confidence, latency_ms: llm_result.latency_ms } else: fallback self.rule_engine.fallback(context) return { path: fallback, result: fallback, confidence: 0.5, latency_ms: fallback.latency_ms }这个 Router 里有几个细节值得注意。第一coverage_checker是关键。它负责判断当前输入是否在规则引擎的覆盖范围内。最简单的实现是维护一张规则条件表逐条比对输入是否符合任一规则的条件。更聪明一点的做法是先用 LLM 做意图提取然后拿提取出的结构化参数去匹配规则表——这样规则引擎覆盖的其实是“意图参数”的组合比直接匹配原始文本可靠得多。第二llm_result.is_valid这个校验步骤不能省。LLM 的输出是自由的你必须用 JSON Schema 或者类型检查器强制约束它的输出格式并且校验关键字段是否合法。比如它输出了一个不存在的商品 ID那这个结果就要被丢弃。我在一个真实项目里用这个架构处理客服工单的分类与路由。工单进入后先做规则匹配大约 72% 的工单能命中预定义规则直接进对应的处理队列平均耗时 80 毫秒剩下 28% 的复杂工单走 LLM 分类平均耗时 2.8 秒但准确率能达到 91%。用这套方案整体成本和延迟比“全部走 LLM”降低了差不多一个数量级。5.2 降级链与容错策略有 Router 还不够你要设计好降级链。降级链的基本思路是LLM 挂了或者超时系统不能跟着挂要有一条退路。我常用的降级链是LLM → 简化版小模型 → 规则引擎 → 默认策略。每一级都比上一级更快、更便宜但能力也逐步降低。实际操作中我在 LLM 调用外面加了一层超时控制一般设 3 到 5 秒。一旦超时立即中断请求降级到规则引擎。同时LLM 的调用要做熔断——连续失败超过阈值就暂时关闭 LLM 通道避免雪崩。另外还有一个容易忽略的点降级要带标记。所有走了降级路径的请求都要在日志里打上degradedtrue的标记方便后续排查和统计降级率。如果发现降级率长期偏高说明你的规则引擎覆盖范围不够该扩充规则了而不是苛责 LLM 不稳定。6. 踩坑实录与排查技巧最后分享几个我在实际项目中踩过的坑每个都是真金白银换来的教训。6.1 抖动最容易被忽略的“隐性故障”我第一次把 LLM 放进生产决策链路时最大的教训是“抖动”。模型在线测试时准确率 93%上线后用户反馈“时好时坏”。一开始我以为是网络问题查了半天才发现是模型本身的输出抖动——同一句话有时候理解对了有时候突然理解偏了。后来我专门做了个实验拿 1000 条固定测试集重复调用模型 20 次统计输出一致性。结果让我很惊讶在温度设为 0.3 的情况下有 6% 的样本在不同调用之间给出了不同的决策结果。这个比例在测试集“一次通过”时根本看不出来但在生产环境里会被无限放大。解决办法有几个一是把温度调到 0最大化确定性二是对关键输出做校验不合法就重试三是在 Router 层面做多模型投票。我自己最常用的是“温度 0 输出校验 一次重试”的组合能把抖动影响降到最低。但记住这些都只是缓解不是根治。如果业务场景完全不能容忍抖动就该直接换专用决策模型。6.2 规则与 LLM 结果冲突时怎么办混合架构里最头疼的问题就是规则引擎说“走 A 分支”LLM 说“应该走 B 分支”听谁的我的原则是默认听规则的除非规则明确标记为“需要 LLM 辅助”。为什么因为规则引擎是确定性系统它的错误是可复现、可修正的LLM 的错误是概率性的你可能无法复现它错在哪。系统设计要让确定性部分成为控制面Control Plane让概率性部分成为增强面Augmentation Plane。听起来有点绕我举个例子。权限校验场景里规则引擎判断“用户 A 无权访问资源 B”此时 LLM 跳出来说“根据对话上下文用户 A 是管理员代理应该放行”。这个冲突怎么处理我的做法是规则引擎的结果作为主导LLM 的输出只能生成一条“例外申请”记录提交给人工审批而不是直接绕过规则。这样既利用了 LLM 的开放域理解能力又守住了系统的确定性底线。6.3 做一张“决策策略速查表”放在团队文档里最后送大家一个实用工具把前面讲到的选型逻辑浓缩成一张速查表放在团队的项目文档里。每次评审方案时先过一遍这张表能省下很多争论。场景问题推荐方案规则能写清楚、条件有限规则引擎 / 决策表状态转移明确、流程固定状态机 / 工作流引擎需要精确计算最优解运筹优化 / 求解器语义理解、意图解析、长尾分类LLM高频调用、成本敏感规则引擎 缓存结果需要审计、必须可解释规则引擎 审计日志低频复杂判断、无明确规则LLM 人工复核我在实际评审里用这张表过滤掉了至少一半“硬上 LLM”的方案。不是 LLM 不好而是它不该被用在不该用的地方。决定系统质量的说到底还是架构设计者对负载本质的理解而不是模型本身有多强。架构设计的核心是让每个组件做它最擅长的事。LLM 是理解与生成的好手规则引擎是确定性与可解释性的守护者两者不该对立而是该分工。我在多个项目里反复验证了这个思路先分类、再分流、最后兜底系统既有了 LLM 的语义能力又保住了决策链路的可靠底牌。下次再有人问“这个负载能不能用 LLM”你先别急着回答把负载放进问题清单里过一遍答案自然就出来了。 
长河君 · 2026/10/8 20:35:21 · 阅读 1.2k 别让LLM扛下所有决策：混合架构实现快慢分离
最近看了不少团队把 LLM 当成万能药什么负载都往上塞人机交互也让它做内部状态判断也让它做连个加减乘除的决策都要走一次大模型。我理解这种冲动毕竟一个接口能处理自然语言、能泛化、能“看起来聪明”谁不想省事。但做系统不是写 Demo很多决策负载放进 LLM 里短期看得见效果长期全是坑。这篇就把我自己的选型思路和踩过的坑整理一下聊聊哪些负载真的该换专用决策模型以及怎么搭一个“快慢分离”的混合决策架构。先说结论LLM 的优势在语义理解、开放域泛化和生成式交互而决策系统的核心诉求往往是确定性、低延迟、可解释、可控成本。这两者天然有冲突。把冲突的负载硬塞给 LLM等于让一个擅长开脑洞的创意总监去当流水线质检员不是不能干但成本高、稳定性差、出了问题还说不清。真正靠谱的做法是先做负载分类再决定每类负载走哪条路径。1. 别让 LLM 扛下所有先看三类“伪需求”我先说三个我在实际项目里反复见到的场景。这三类负载乍一看都能用 LLM 解决但仔细拆解之后你会发现它们更像是“伪需求”——真正的解法在 LLM 之外。1.1 高频短延迟决策Token 生成再快也追不上查表第一类是高频短延迟决策。典型例子是智能客服里的“下一步动作选择”和电商系统的“实时推荐排序”。我一个做客服系统的朋友曾经把所有对话分支都用 LLM 判断用户说“我要退款”LLM 判断出意图后再让 LLM 决定“该调用退款接口还是转人工”。每次决策多花 1.5 到 3 秒高峰期并发一上来token 费用像水龙头一样哗哗流。更麻烦的是LLM 对同一个输入的回答会有抖动——今天返回“调用退款接口”明天可能返回“建议转人工”因为模型有采样温度、上下文微小变化都会影响输出。这种不确定性对一个生产级客服系统是不可接受的。这类负载真正的解法是查表和规则意图识别用 LLM 做一次粗分类然后“下一步动作”直接查一个状态机映射表。状态机清晰、可测试、毫秒级返回成本几乎为零。LLM 只需要在状态机无法覆盖的开放域对话里补位。1.2 强一致与低容忍错误概率生成是双刃剑第二类是强一致、低错误容忍的决策。比如金融领域的审批决策、风控规则判断、权限校验。这些场景通常有明确的合规要求每个决策都要能追溯为什么拒绝、依据哪条规则、阈值是多少。LLM 是一个概率模型它的输出本质上是“最像正确答案的文本”不是“经过严格推理得到的结果”。你问它“这笔交易是否异常”它能给你一段看起来合理的分析但这段分析无法保证每次都对同一个输入给出同一个结论更无法保证它引用的规则真实存在。我见过一个团队把风控预警的判断交给 LLM结果有一次模型因为上下文里偶然出现的一个词把正常交易判成了高风险后续的审计流程完全无法解释模型的决策依据。最后他们花了两周时间把所有规则重新改成硬编码阈值判断LLM 只做规则之外的辅助分析。这个项目我印象非常深它让我意识到一个原则凡是决策结果需要审计、需要稳定复现的场景默认不要用 LLM。1.3 数值优化与规划求解大模型不擅长精确计算第三类是数值优化与规划求解。比如仓库的订单分配、运输路径规划、排产调度。这些问题的本质是在约束条件下求最优解适合用运筹优化算法、动态规划、图搜索来解。LLM 的数学能力虽然一直在提升但它在本质上仍然是“下一个 token 预测”做不了精确到小数点后几位的数值优化更无法保证输出是全局最优解。举个例子一个物流项目里团队想用 LLM 直接生成“最优配送路线”结果模型给出的路线从直觉上看没问题但计算后比普通贪心算法还多了 8% 的里程。问题不是模型不聪明而是它没有真正在做搜索与验证只是在“模仿”一个最优解的样子。这类负载正确的做法是把它抽象成数学模型用成熟的求解器OR-Tools、Gurobi 等或者启发式算法去解LLM 最多做“自然语言描述到结构化约束”的转换不做最终的方案生成。2. 为什么 LLM 在决策负载上“物理上”不合适前面说的三类伪需求背后其实有三个结构性原因。这些原因不是调参能解决的而是模型架构和工作方式决定的。2.1 概率采样和确定性要求的根本冲突LLM 的推理过程是概率采样给定输入 token 序列模型计算下一个 token 的概率分布然后按一定策略采样。温度大于 0 的时候同样的输入可能得到不同的输出就算设成 0在浮点计算、批处理等因素影响下输出也可能有细微抖动。而决策系统的第一性原理是确定性相同的输入必须产生相同的输出这样系统才能测试、才能审计、才能预期。这个冲突在“规则可穷举”的场景里最明显。如果某个决策可以用 10 条规则覆盖全部情况规则引擎的执行结果是可证明的而 LLM 的结果只是一个“大概率相同”的猜测。把确定性需求交给概率模型本质上就是让系统的正确性建立在概率上这在实际工程里非常危险。我自己的经验是如果一个决策的判断逻辑能写成分支条件if-else、决策表、状态机那就不要用 LLM。LLM 的泛化能力在开放域是优势但在封闭域里反而是负担——它会把一些本不该有的“灵活性”带进来。2.2 成本曲线线性调用和边际成本的现实账再说成本。很多人在方案设计阶段只看单次调用的价格觉得“一次几分钱不贵”。但一旦流量上来这个账就不是这么算了。假设你的系统每天处理 100 万次决策每次决策调用一次 LLM平均输入输出 1500 token按市场价大致估算单次成本 0.002 到 0.005 元一天就是 2000 到 5000 元一个月 6 万到 15 万元。这还只是模型调用费没算网关、重试、错误处理、日志存储的成本。而用规则引擎或者查表100 万次决策的成本几乎可以忽略——就是一次内存查询或一次函数调用。更关键的是延迟成本。规则引擎的决策通常在微秒到毫秒级别LLM 的首 token 延迟至少几百毫秒完整生成可能要几秒。在用户可感知的交互链路里这多出来的几秒会直接转化为流失率。有些团队为了压延迟用更小的模型、做量化、搞缓存折腾一圈最后还是不如直接用专用决策模型来得干脆。2.3 可解释性与审计决策系统的隐形刚需第三点是可解释性。很多决策场景——尤其是涉及钱、权限、合规的场景——要求每个决策都能被审查为什么是这个结果依据了什么条件。规则引擎天然满足这个需求因为它的每条规则、每个条件都可以被记录和重现。LLM 则像一个黑盒你只能看到输入和输出中间过程无法精确还原。即使你用 Chain-of-Thought 让它“逐步思考”那也只是模型生成的文字不是它真实的推理过程。我在实际项目里还发现一个更微妙的问题LLM 的“解释”往往是事后合理化。你问它为什么做这个决策它会生成一段听起来很合理的分析但这段分析和它实际做出决策的计算过程未必一致。如果审计人员拿这段解释当依据可能被误导。所以在需要严格审计的场景里不要依赖 LLM 的可解释性宁愿让规则引擎来兜底。3. 那什么负载才真正值得上 LLM说了这么多 LLM 不能干的不代表我反对用 LLM。恰恰相反LLM 在决策链路里有很多不可替代的位置。关键在于你要认清它适合什么然后把它放在合适的位置上。3.1 开放域语义理解与意图解析LLM 最擅长的是开放域语义理解。传统规则引擎解决不了的问题比如用户说“我上次买的那个黑色的东西能退吗”这句话里没有明确的商品 ID也没有明确的订单编号规则引擎只能靠关键词硬匹配效果很差。LLM 可以结合上下文理解“黑色的东西”指的是“黑色款蓝牙耳机”并且判断用户的意图是“退货咨询”。这个能力是规则引擎无法替代的。这类负载适合 LLM是因为它的本质是“把非结构化输入映射到结构化意图”而 LLM 恰好是文本到语义的最佳映射器。在实际项目中我通常把 LLM 放在入口做意图分类和实体抽取输出结构化的 JSON然后让下游状态机决定具体执行逻辑。这样 LLM 负责“理解”规则引擎负责“决策”各司其职。3.2 规则无法穷举的长尾场景还有一些场景规则的组合空间太大无法穷举。比如个性化推荐里的“内容偏好理解”你没法写几千条规则覆盖每个用户的兴趣组合再比如“质检工单分类”工单的写法千奇百怪规则模板很难覆盖所有表达方式。这类场景适合用 LLM 做初筛和聚类再结合人工审核。LLM 在这里的价值是“覆盖面”和“泛化能力”。它不需要精确只需要把大多数情况打对标签把长尾情况兜住。但注意LLM 的输出在这里通常是“候选集”而不是“最终决策”最终决策还是要由确定性逻辑或人工把关。我管这个叫“LLM 做草稿规则做终审”。4. 负载分类与选型判断框架有了上面的分析我在实际项目里会用一个简单的框架来给负载分类然后决定每个负载走哪条路径。这里分享一个最简版本。4.1 一张表看清四类负载负载类型典型场景决策特征推荐方案LLM 的角色规则判定型权限校验、风控阈值、流程分支规则可穷举、需确定性规则引擎 / 决策表不参与或仅做前置语义解析数值优化型路径规划、排产、资源分配约束最优解、需精确计算运筹优化 / 启发式算法将自然语言转为约束条件状态决策型客服对话状态转移、任务流程管理状态有限、转移明确状态机 / 工作流引擎意图解析、槽位填充开放理解型情感分析、文本分类、相似匹配语义开放、无标准答案LLM / Embedding 模型主力角色这张表的逻辑不是按“业务领域”分的而是按“决策特征”分的。你面对任何一个负载先问自己三个问题规则能穷举吗结果需要确定性吗计算精确度要求高吗如果三个问题的答案里有至少一个“是”那就要慎重考虑上 LLM。4.2 选型判断的五个筛子我把判断过程进一步细化成五个筛子每个负载过一遍这五个筛子基本就能确定该不该上 LLM。第一筛延迟要求。如果端到端延迟要求小于 500 毫秒LLM 很吃力直接走专用模型。第二筛成本敏感度。如果单次决策成本预算是几厘钱LLM 大概率超预算。第三筛确定性要求。如果相同输入必须产生相同输出LLM 不合适。第四筛可解释性要求。如果决策需要审计追溯LLM 不合适。第五筛规则可穷举性。如果规则能覆盖 95% 以上场景先用规则引擎。这五个筛子不用按顺序过但有一个是“一票否决”的确定性要求。只要这个负载明确要求确定性输出那就别考虑 LLM 了直接换专用决策模型。我在前面提到的风控场景就是典型哪怕其他条件都合适确定性这一关过不了一切免谈。5. 实操构建“快慢分离”的混合决策架构理论讲完了说点实操。我在实际项目里搭过一套“快慢分离”的混合决策架构基本思路是把 LLM 放在慢路径把规则引擎放在快路径用一个路由器Router在两者之间做分流。这里分享一个最小可用的实现思路。5.1 一个最小可用的 Router 示例Router 的核心职责是判断当前请求走哪条路径。最简单的实现就是一组优先级规则先判断是否能被规则引擎覆盖如果能就直接走规则如果不能再上 LLM。# router.py import json class DecisionRouter: def __init__(self, rule_engine, llm_handler, coverage_checker): self.rule_engine rule_engine # 专用决策模型规则引擎 self.llm_handler llm_handler # LLM 处理器 self.coverage_checker coverage_checker # 规则覆盖检查器 def decide(self, context): # 第一步快速路径——规则引擎能覆盖就直接决策 if self.coverage_checker.is_covered(context): result self.rule_engine.execute(context) return { path: rule, result: result, confidence: 1.0, latency_ms: result.latency_ms } # 第二步慢路径——规则覆盖不了才走 LLM llm_result self.llm_handler.process(context) # 第三步LLM 结果经过校验器不合法就降级到默认策略 if llm_result.is_valid: return { path: llm, result: llm_result.payload, confidence: llm_result.confidence, latency_ms: llm_result.latency_ms } else: fallback self.rule_engine.fallback(context) return { path: fallback, result: fallback, confidence: 0.5, latency_ms: fallback.latency_ms }这个 Router 里有几个细节值得注意。第一coverage_checker是关键。它负责判断当前输入是否在规则引擎的覆盖范围内。最简单的实现是维护一张规则条件表逐条比对输入是否符合任一规则的条件。更聪明一点的做法是先用 LLM 做意图提取然后拿提取出的结构化参数去匹配规则表——这样规则引擎覆盖的其实是“意图参数”的组合比直接匹配原始文本可靠得多。第二llm_result.is_valid这个校验步骤不能省。LLM 的输出是自由的你必须用 JSON Schema 或者类型检查器强制约束它的输出格式并且校验关键字段是否合法。比如它输出了一个不存在的商品 ID那这个结果就要被丢弃。我在一个真实项目里用这个架构处理客服工单的分类与路由。工单进入后先做规则匹配大约 72% 的工单能命中预定义规则直接进对应的处理队列平均耗时 80 毫秒剩下 28% 的复杂工单走 LLM 分类平均耗时 2.8 秒但准确率能达到 91%。用这套方案整体成本和延迟比“全部走 LLM”降低了差不多一个数量级。5.2 降级链与容错策略有 Router 还不够你要设计好降级链。降级链的基本思路是LLM 挂了或者超时系统不能跟着挂要有一条退路。我常用的降级链是LLM → 简化版小模型 → 规则引擎 → 默认策略。每一级都比上一级更快、更便宜但能力也逐步降低。实际操作中我在 LLM 调用外面加了一层超时控制一般设 3 到 5 秒。一旦超时立即中断请求降级到规则引擎。同时LLM 的调用要做熔断——连续失败超过阈值就暂时关闭 LLM 通道避免雪崩。另外还有一个容易忽略的点降级要带标记。所有走了降级路径的请求都要在日志里打上degradedtrue的标记方便后续排查和统计降级率。如果发现降级率长期偏高说明你的规则引擎覆盖范围不够该扩充规则了而不是苛责 LLM 不稳定。6. 踩坑实录与排查技巧最后分享几个我在实际项目中踩过的坑每个都是真金白银换来的教训。6.1 抖动最容易被忽略的“隐性故障”我第一次把 LLM 放进生产决策链路时最大的教训是“抖动”。模型在线测试时准确率 93%上线后用户反馈“时好时坏”。一开始我以为是网络问题查了半天才发现是模型本身的输出抖动——同一句话有时候理解对了有时候突然理解偏了。后来我专门做了个实验拿 1000 条固定测试集重复调用模型 20 次统计输出一致性。结果让我很惊讶在温度设为 0.3 的情况下有 6% 的样本在不同调用之间给出了不同的决策结果。这个比例在测试集“一次通过”时根本看不出来但在生产环境里会被无限放大。解决办法有几个一是把温度调到 0最大化确定性二是对关键输出做校验不合法就重试三是在 Router 层面做多模型投票。我自己最常用的是“温度 0 输出校验 一次重试”的组合能把抖动影响降到最低。但记住这些都只是缓解不是根治。如果业务场景完全不能容忍抖动就该直接换专用决策模型。6.2 规则与 LLM 结果冲突时怎么办混合架构里最头疼的问题就是规则引擎说“走 A 分支”LLM 说“应该走 B 分支”听谁的我的原则是默认听规则的除非规则明确标记为“需要 LLM 辅助”。为什么因为规则引擎是确定性系统它的错误是可复现、可修正的LLM 的错误是概率性的你可能无法复现它错在哪。系统设计要让确定性部分成为控制面Control Plane让概率性部分成为增强面Augmentation Plane。听起来有点绕我举个例子。权限校验场景里规则引擎判断“用户 A 无权访问资源 B”此时 LLM 跳出来说“根据对话上下文用户 A 是管理员代理应该放行”。这个冲突怎么处理我的做法是规则引擎的结果作为主导LLM 的输出只能生成一条“例外申请”记录提交给人工审批而不是直接绕过规则。这样既利用了 LLM 的开放域理解能力又守住了系统的确定性底线。6.3 做一张“决策策略速查表”放在团队文档里最后送大家一个实用工具把前面讲到的选型逻辑浓缩成一张速查表放在团队的项目文档里。每次评审方案时先过一遍这张表能省下很多争论。场景问题推荐方案规则能写清楚、条件有限规则引擎 / 决策表状态转移明确、流程固定状态机 / 工作流引擎需要精确计算最优解运筹优化 / 求解器语义理解、意图解析、长尾分类LLM高频调用、成本敏感规则引擎 缓存结果需要审计、必须可解释规则引擎 审计日志低频复杂判断、无明确规则LLM 人工复核我在实际评审里用这张表过滤掉了至少一半“硬上 LLM”的方案。不是 LLM 不好而是它不该被用在不该用的地方。决定系统质量的说到底还是架构设计者对负载本质的理解而不是模型本身有多强。架构设计的核心是让每个组件做它最擅长的事。LLM 是理解与生成的好手规则引擎是确定性与可解释性的守护者两者不该对立而是该分工。我在多个项目里反复验证了这个思路先分类、再分流、最后兜底系统既有了 LLM 的语义能力又保住了决策链路的可靠底牌。下次再有人问“这个负载能不能用 LLM”你先别急着回答把负载放进问题清单里过一遍答案自然就出来了。