何时不该用LLM？工程决策五道闸门框架

“这个需求能不能用大模型做？”——这几乎成了每个技术团队立项时的条件反射。但一个更该先问的问题是：这个需求真的需要大模型吗？

并非所有软件问题都需要LLM。如果一个任务能用确定性规则、SQL查询、标准API、搜索算法或传统机器学习可靠解决，那么引入LLM只会增加成本、延迟、安全暴露面和维护复杂度，却换不来更好的结果。

这份来自工程实践的分析框架给出了一条核心判断线：当系统需要精确计算、可预测输出、严格执行保证、极低延迟，或者无法容忍未经核验的结果时，就不该用LLM。

先定义问题，再选技术

最常见的架构错误，是先选技术再定义任务。以发票处理为例，它其实包含文档抽取、字段校验、税额计算、采购单匹配、差异检测和审批等多个环节——这些环节并不需要同一种技术。

文档抽取在版式高度多变时，可能适合OCR、文档AI或LLM；税额计算应当使用确定性业务逻辑；采购单匹配可以用查询和预定义规则；异常差异则可能需要统计异常检测或人工复核。

所以第一个问题应该是：这个任务需要语言理解或生成，还是只需要执行已知的业务逻辑？ 如果答案是后者，就从常规软件开始。

七种不该使用LLM的场景

输出必须数学精确

财务对账、税额计算、库存余额、合同定价，都应依赖经过验证的算法和合适的数值表示。LLM可以解释请求，但计算应保持确定性。原文给出的例子里，折扣计算用 Decimal 处理浮点问题，并对价格和折扣率做边界校验——这类逻辑交给模型生成是不必要的风险。正确做法是使用校验过的业务逻辑、十进制运算和专用计算库。

IEEE 754 与十进制运算：绝大多数编程语言默认的浮点数（float/double）遵循 IEEE 754 标准，采用二进制表示，因此像 0.1、0.2 这样的十进制小数无法被精确存储，累加或乘除后会产生微小误差。金融和库存场景中，这类误差经过大量交易累积后会造成对账不平。解决方案是使用十进制浮点（如 Python 的 decimal.Decimal、Java 的 BigDecimal、数据库的 NUMERIC/DECIMAL 类型），它们以定点方式保存十进制数，能按预期舍入规则精确运算，代价是性能低于二进制浮点。若交给 LLM 生成算式或结果，模型无法保证逐位正确，也无法保证每次都执行同一条运算路径。

边界校验（boundary validation）：指在计算前后对输入和输出的取值范围、类型、精度做显式检查，例如价格不能为负、折扣率必须落在 0 到 1 之间、总额不超过上限。它是把“模型可能胡编”转化为“系统一定拒绝”的关键手段，让错误在进入账务前就被拦截，而不是靠事后人工发现。

确定性计算与可复现性：财务审计要求同一输入在任何时间、任何环境都得到同一输出，并留下可追溯的计算依据。确定性代码天然满足这一要求，而 LLM 采样具有随机性，即使温度设为 0，也可能因版本、后端或并行策略变化而输出不同结果，难以作为审计凭证。

流程有明确定义的规则

一个有明确时效、排除类别和审批阈值的退款政策，更适合用规则引擎或常规应用逻辑表达。原文的简化示例中，超过30天或不符合资格直接拒绝，金额超500转人工审核，其余通过——注意原文明确提醒这不是完整退款政策，生产系统还需要身份认证、交易校验、欺诈控制和审计记录。

延迟要求极其严格

LLM推理会引入网络、输入处理、生成和工具调用的多重延迟。工业控制回路、底层网络包处理、高频交易、安全关键设备控制等场景，更适合优化算法、嵌入式逻辑或经过时序验证的专用低延迟模型。

答案已存在于结构化数据中

如果收入数字已经在权威数据库里，直接查库，而不是让模型“生成”这个结果。原文的示例SQL按已支付发票统计某月收入——同时提醒该查询假设“收入”等同于已支付发票金额，财务报告可能采用不同口径。LLM可以把用户问题翻译成受约束的查询，但授权和聚合应始终由应用层控制。

敏感数据无法满足处理架构要求

如果实现方案无法满足数据处理、留存、访问控制和部署要求，就不要引入LLM。私有部署和受治理的托管服务可以支持敏感负载，但必须能证明控制措施有效。OWASP将提示注入和敏感信息泄露列为LLM应用的重要风险。

提示注入（Prompt Injection）：OWASP 在 LLM 应用十大风险中将其列为首位。它指攻击者把恶意指令藏在用户输入、外部文档、网页或工具返回内容中，诱导模型忽略原有系统提示、泄露机密或执行越权操作。与 SQL 注入不同，提示注入没有简单的转义方案，因为自然语言指令和数据的边界本身是模糊的。防御依赖多层控制：输入过滤、指令与数据分离、最小权限工具调用、输出校验与人工复核。

敏感信息泄露（Sensitive Information Disclosure）：模型可能在回答中无意复述训练数据、系统提示、其他用户会话或工具返回的隐私字段。风险不仅来自模型本身，还来自日志、缓存、向量数据库和第三方托管服务。所谓“处理架构要求”通常包括数据驻留地区、是否用于再训练、留存期限、访问审计、加密与租户隔离。若这些要求无法被证明满足，就不应让模型接触该数据。

私有部署与受治理托管：私有部署指模型权重和数据都留在企业可控环境内；受治理托管则是在第三方云上通过合同与技术控制约束数据用途。两者都必须配合访问控制、密钥管理、网络隔离和监控，才能在合规评审中通过，单靠“不对外公开”的承诺并不足够。

专用模型更高效

欺诈检测、需求预测、缺陷分类、异常检测、预测性维护，用统计方法或任务专用机器学习往往更合适。LLM可以解释结果，但不必生成底层预测。关键是在代表性数据上做对比。

无法评估模型是否正确

没有代表性测试用例、没有定义不可接受的结果、没有评估或复核机制，就不该批准自主生产使用。在形成可度量的验收标准之前，受控原型或人工复核流程更可取。

三种技术路线的选择对照

原文给出一张需求—方案对照表，核心逻辑清晰：精确算术用确定性代码，业务规则执行用规则引擎，结构化数据检索用SQL或API，关键词精确匹配用搜索引擎，需求预测用统计或ML模型；而灵活文档摘要、语义文档发现、自然语言界面则适合LLM，高风险自动化操作必须配合确定性控制和人工监督。

这些是起点，不是普适规则。原文强调要针对自己的验收标准做基准测试。

算清楚LLM的真实成本

总拥有成本 = 开发 + 基础设施 + 推理 + 评估 + 监控 + 维护 + 异常处理。

原文给了一个假设性的百万级月请求量对比（明确标注为示意，非厂商价格或公开基准）：确定性服务单次成本0.001美元、成功率99.9%，每成功任务约0.001美元；LLM服务单次0.02美元、成功率97%，每成功任务约0.0206美元。

两者可能解决的是不同问题，确定性服务未必能处理语言密集型任务。要比较的是部署时间、每完成任务的成本、失败率、复核需求、维护、监控和安全开销。

五道闸门决策框架

这是全文最有操作性的部分，原文称其为“提出的工程方法，而非外部验证的标准”：

闸门1：是否真的需要语言智能？ 如果任务不需要灵活的语言解释或生成，从确定性软件开始。

闸门2：更简单的方案能否满足要求？ 对规则、搜索、API或专用ML做基准测试——不要把LLM只和“什么都不做”比较。

闸门3：系统能否容忍概率性行为？ 定义错误、不完整或不一致结果如何被检测和处理。

闸门4：LLM是否满足运行约束？ 在真实负载下测试延迟、吞吐、成本、可用性、隐私和安全。

闸门5：额外能力是否值得额外复杂度？ 只有当收益实质性且风险可控时，才批准LLM。

决策流的走向是：需要语言智能吗→不需要就用确定性软件；需要→对比更简单的替代方案；替代方案达标→优先用替代方案；否则→测试错误遏制、运行约束和可度量的增量价值，再批准受控的LLM实现。

闸门设计的逻辑：这五道闸门是从“是否必要”到“是否值得”的逐层过滤，而非并列清单。闸门 1 和 2 属于需求与替代方案层面，回答“有没有更简单、更可靠的路”；闸门 3 和 4 属于系统能力层面，回答“概率性行为与运行约束是否可接受”；闸门 5 属于经济与治理层面，回答“多出来的复杂度是否换来了实质增量收益”。前一道不通过，后面的讨论就失去意义，因此评审应按顺序推进，避免团队一上来就争论模型选型。

与“先定义问题再选技术”的衔接：闸门 1 对应文章开头的核心判断——任务需要语言理解还是只需执行已知逻辑。把闸门 1 做成硬性前置条件，可以防止“条件反射式用大模型”把架构评审带偏。

为什么强调可度量的增量价值：闸门 5 要求收益实质性且风险可控，是因为 LLM 引入的失败模式（幻觉、不确定重试、输出格式漂移）无法完全消除，只能用评估、监控和人工兜底来遏制。若这些成本高于确定性方案的处理成本，即便模型体验更好，也不构成批准理由。原文明确说明该框架是提出的工程方法，而非行业标准，团队应结合自身验收标准调整闸门顺序和阈值。

客户支持工单路由的三种架构

一个SaaS平台需要路由重复扣费、修改账户邮箱、API报错等请求。原文对比了三种架构：

方案A：基于规则的路由。 通过关键词匹配把工单分到账单、账户、技术或人工复核。透明可测，但客户措辞出人意料或描述多个问题时覆盖有限。

方案B：基于LLM的路由。 能理解多样表达，但增加推理成本、模型评估、输出校验和额外失败模式。

方案C：混合路由。 明确请求走规则，常见变体走轻量分类器，歧义语言用LLM，低置信度或高影响案例转人工。路由策略仍由应用控制。

比较的指标包括分类精确率和召回率、误路由率、人工复核率、P95延迟、每张正确路由工单的成本和维护投入。混合系统只有在带来可度量收益时才更优。

把LLM放在边界，而不是所有地方

核心架构原则是：把语言解释与权威业务执行分开。 LLM可以把意图翻译成结构化请求；确定性服务负责校验schema、执行权限、应用业务规则、执行关键操作。

原文的流程链一目了然：用户请求→LLM解释意图→结构化请求→schema校验→授权+业务规则→确定性API执行→已验证结果→用户响应。

结构化输出可以约束响应格式，但语法正确不代表解释正确或执行已授权。这对于连接企业系统的AI Agent尤其重要。

结构化输出（Structured Output）：通过 JSON Schema、函数调用或语法约束，要求模型按固定字段返回结果，便于程序解析。但语法正确只说明格式合格，不代表语义正确——模型可能填错字段、给出不存在的枚举值或编造参数。因此必须在应用侧重新校验类型、范围、必填项与业务规则，并把不通过的结果退回重试或转人工。

职责分离原则：把 LLM 定位为“意图翻译器”，而不是“执行器”。用户请求先由 LLM 转成结构化请求（如 {action: "refund", orderId: "...", amount: 120}），随后由确定性服务完成 schema 校验、身份认证、权限判断、业务规则应用和事务执行。这样即使模型被诱导产生越权意图，也会在授权层被拦截。

为什么对 AI Agent 尤其重要：Agent 往往能调用工具、写入数据库或触发外部 API，其动作空间远大于纯文本对话。若把授权和业务规则也交给模型判断，一次提示注入就可能变成真实资金损失或数据泄露。因此 Agent 的工具应遵循最小权限原则，关键操作需二次确认或人工审批，并保留完整的调用审计链。

验证与幂等：确定性服务在执行前应校验请求是否合法、是否重复提交，并返回可核验的结果。LLM 不参与判定“是否已授权”“是否已扣款”，只负责把自然语言意图转成可被程序检查的结构化请求，这是全文架构原则的落点。

审批LLM前该问的十个问题

问题定义：什么需要LLM，考虑过哪些替代方案？基线：最强的非LLM方案表现如何？质量：用什么数据集和指标评估正确性？可靠性：模型失败或输出无效时怎么办？安全：模型能否访问或变更超出用户授权范围的东西？性能：负载下的P50、P95、P99延迟是多少？经济性：每个成功业务任务的成本是多少？归属：谁维护提示词、数据集、配置和监控？变更管理：模型和数据更新的重测机制是什么？退出策略：能否在不重构应用的前提下替换模型？

架构评审的一条实用规则

原文结尾给出一句可以直接搬进评审会的话：如果去掉LLM不会实质性降低系统满足需求的能力，那它大概率不该出现在关键路径上。

LLM不是不能用于业务逻辑，而是它更适合解释请求；权威规则、计算、权限和事务一般应保持确定性。追求的目标始终是：构建能可靠交付业务成果的最简系统。