企业官网建设流程全解析

按理说现在聊 AI 应用架构，绕不开 LLM，但真要上手搭过生产级系统的朋友应该都有同感：LLM 不是万能的，更不是免费的。我见过太多团队，一开始图省事，把所有逻辑判断都往大模型里塞，结果模型响应慢、成本飙升、输出还不稳定，最后又灰溜溜地往回拆。这篇文章想聊的就是这个：到底什么负载适合直接调 LLM，什么负载应该换专用决策模型来扛。我会结合自己实际做过的项目，把判断标准、场景拆解和混搭落地的思路完整讲一遍，适合正在做 AI 应用工程化、或者准备把 LLM 能力接入现有系统的开发者参考。

1. 先搞明白：LLM 到底擅长什么、不擅长什么

1.1 LLM 的真实能力边界

先说个最容易被忽略的事实：LLM 的本质是一个"基于海量文本训练出来的概率分布模拟器"，它在做的是"根据上下文预测下一个最合适的 Token"，而不是在做"严格的逻辑推理"。这意味着三件事。

第一，对于开放语义类任务——比如意图识别、情感分析、内容摘要、开放域问答、文本改写——LLM 堪称顶配。这些任务没有标准答案，衡量标准是"通不通顺、合不合语境"，这恰好是概率模型的强项。

第二，对于封闭决策类任务——比如"这个用户的请求该走哪个服务""这笔订单该不该自动退款""这个日志属于哪一类异常"——LLM 能做，但属于"高射炮打蚊子"。它的能力远超需求，但伴随的高成本、高延迟和不稳定性完全没必要。

第三，LLM 有一个天然缺陷叫"不可复现性"。同一个 Prompt，温度设成 0，同一批请求，跑十次可能有八次结果一致，但总有两次会给出诡异的输出。这在决策链路里是致命的——业务方不会接受"今天判定通过、明天判定拒绝"的系统。

我个人习惯把 LLM 比作一个"超级博学的顾问"：你问他"这段用户反馈在表达什么情绪"，他能给你讲得头头是道；但你让他"严格按照规则列表逐一核对每个字段然后给出布尔结论"，他反而容易在细节上翻车。而专用决策模型就像一个"训练有素的质检员"——他只干一件事，但干得又快又准。

1.2 三个被高估的通用性陷阱

我在多个项目里总结出，盲目把负载丢给 LLM 通常会踩三个坑，这三个坑几乎是必然发生的。

第一个坑是成本失控。LLM 按 Token 计费，一次调用哪怕只是判断一个布尔值，也要把整个上下文重新计算一遍。假设一个系统每天有 100 万次决策请求，每次请求消耗大约 1000 Token（包含系统 Prompt、用户输入、工具定义），按市面上主流模型的定价算，一天的成本至少够买一台配置不错的 GPU 服务器。更麻烦的是，这个成本是线性增长的，业务涨一倍，费用就翻一倍，根本没有规模效应。而专用决策模型跑在自己的推理服务上，边际成本趋近于零。

第二个坑是延迟不可控。LLM 的响应时间通常在几百毫秒到几秒之间，遇到高峰期还会排队。但很多决策场景是有超时预算的——比如网关层面的负载调度，超过 100 毫秒就可能导致上游客户端超时重试，重试又带来更大的压力，形成恶性循环。我在一个网关项目里实测过，纯规则判断的耗时在 1 毫秒到 5 毫秒之间，而同样一个判断交给 LLM，P99 延迟直接到了 2.8 秒，这个差距在线上是不可接受的。

第三个坑是行为不可预期。LLM 是一个概率模型，即使你精心设计了 Prompt 和 Few-shot 示例，它依然可能在边界情况下输出意料之外的内容。举个真实的例子：我们曾经让 LLM 做日志分类，区分"系统异常"和"业务正常"两类。大部分情况都正确，但有一类日志——比如"connection reset by peer"——LLM 会时而归类为异常（因为看到 connection、reset 这些词），时而归类为正常（因为预训练数据里这种日志太常见了）。而我们的告警系统只认规则分类结果，这种抖动直接导致了误报率上升。后来我把这个分类任务换成了基于关键特征匹配的专用模型，准确率从 94% 直接拉到 99.6% 不说，关键是行为完全稳定。

2. 哪些负载该换专用决策模型：三个判断标准

2.1 标准一：决策空间是否可枚举

这是我的第一判断准则：如果一个问题所有可能的输出结果能提前列完，那就不该用 LLM，至少不该直接用 LLM。

举个例子，"判断一个请求应该路由到 A 服务还是 B 服务"，输出空间就是两个值。再比如"这个文本属于哪一类违规内容"，如果已经预先定义了 20 个类别，输出空间就是 20 个值。这种任务的核心难点不是"理解"，而是"精确匹配"，而精确匹配恰恰是传统分类模型、规则引擎、甚至简单的哈希映射最擅长的事情。

反过来，如果一个任务输出空间是开放的、不可穷举的——比如"生成一段促销文案""把这段自然语言翻译成 SQL"——那才是 LLM 的主场。因为这种任务没有固定答案，你无法用手写规则覆盖所有情况，必须借助模型的泛化能力。

我把这个标准总结为一句话："如果你能在需求文档里列出所有可能的输出类型，你就应该考虑用专用决策模型。"这个原则帮我挡掉了至少一半不必要的 LLM 调用。

2.2 标准二：确定性是否是硬性要求

有些场景允许"大多数情况下正确"，但有些场景要求"必须每次正确"。

典型如权限判定、合规校验、支付风控。这类场景一旦判定错误，后果不是"用户觉得体验不好"，而是资损、合规事故甚至法律风险。你不可能跟审计解释"大模型今天心情不好，把一个越权请求放过去了"。这类负载对确定性有极高要求，必须换专用决策模型——通常是一套基于明确规则和特征矩阵的判定系统。

判断方法很简单：你问自己一个问题，"这个决策如果出错了，最坏后果是什么？"如果答案是"产生资损""导致安全问题""违反合规要求"，那对不起，LLM 直接出局。就算你要用 LLM，也只能把它放在辅助位——比如生成建议和理由描述——而最终的决策权必须由确定性系统掌握。

另一个值得注意的维度是"结果需要留痕和审计"。专用决策模型的判定逻辑是透明的、可解释的、可回溯的——"因为字段 A 为空且金额超过阈值，所以拒绝"。而 LLM 给出的判定是黑盒，你可能很难复现"为什么模型这次给了我 Yes"。在监管严格的数据场景中，这个差异可能直接决定项目能不能过审。

2.3 标准三：失败模式是否可容忍

第三个标准很务实：LLM 是会出错的，你要看这个错误的代价是什么。

先说可容忍的场景。比如一个"智能客服总结对话内容"的功能，偶尔总结偏了，用户自己重看一遍记录就完了，最多影响一点体验，不伤筋动骨。这种负载没必要换专用模型，因为 LLM 的高质量输出值得这个容错成本。

再说不可容忍的场景。还是拿负载均衡器举例。一个网关系统每天处理几十亿次转发，如果让 LLM 来决定每个请求路由到哪个后端，一旦它"灵光一现"把请求路由到了一个不合适的实例，影响的是整条链路的稳定性，且故障面不可控。这种场景下，LLM 的不可预期误差就是不可接受的，必须换专用决策模型来扛。

还有一个容易被忽视的维度：依赖可用性。LLM 服务通常是外部依赖，它的可用性、配额、限流都不受你控制。如果整个系统的关键决策链路强依赖一个外部的、不受控的服务，那么无论它输出质量多高，架构上都是脆弱的。专用决策模型部署在你的可控环境内，可用性你可以自己保证，这才是关键路径该有的姿态。

3. 典型场景拆解：从真实负载类型说起

3.1 负载类型一：规则路由与策略分发

最典型的"不该直接调 LLM"的负载就是路由和分发。

我做过一个实际的网关项目，流量入口统一由网关接管，根据请求特征——比如 URL、Header、用户等级、设备类型——将请求分发到不同的后端服务。最初方案确实考虑过用 LLM，想的是"让模型理解请求语义后再做智能路由"，结果评估完直接放弃了。

原因很简单：这个场景看似需要智能，其实只需要"按规则匹配"。用户等级是枚举值，URL 的前缀是有限集合，这些信息完全可以通过一张路由表 + 几个前缀匹配规则就能完成，耗时在微秒级，且行为完全确定。

而 LLM 在这个场景下不仅帮不上忙，还会带来一个致命问题：它不保证同一个请求每次得到相同路由结果。一个路由表，不要求聪明，要求的是"永远一致"。如果同一用户在重复请求时被路由到不同后端，轻则造成会话状态不一致，重则导致事务中断。

所以我后来定的规则是：凡是"根据已知属性做确定映射"的负载，一律走规则引擎或专用路由模型。LLM 只参与那些真正无法用规则描述的开放性任务。

3.2 负载类型二：权限判定与合规校验

权限判定的特点是：类目固定、判定条件明确、错误代价高。

举例来说，"这个用户是否有权限查看这份文档"，其实就是一个布尔决策：有权限 / 没权限。判定依据是用户角色、文档密级和组织架构关系，这些信息都是结构化数据，整个判断过程完全可以用策略表 + 规则矩阵完成。如果你把这个问题抛给 LLM，它可能会结合"语义理解"给出一个模棱两可的结论——"根据上下文，我认为该用户有权限"——但在审计时，你需要的是确定的规则推导链。

合规校验同样如此。比如内容审核场景中的"是否包含违禁词""是否命中黑名单"，这些都属于"封闭集的分类问题"。用专用决策模型——比如基于敏感词库 + 规则模板 + 兜底评分模型——可以做到毫秒级响应和 100% 可解释。LLM 在这类任务中可以做一个很有价值的补充角色：对"疑似违规但规则无法判定"的长尾内容做语义级判定，但必须作为第二道闸，而非唯一闸门。

我在实践中通常采用"规则优先 + LLM 兜底"的三级架构：第一级走敏感词命中，第二级走分类模型判断，第三级才调用 LLM 处理前两层无法确定的疑难内容。这样既保留了 LLM 的语义理解能力，又把确定性决策牢牢握在专用模型手里。

3.3 负载类型三：数据清洗与格式标准化

这类负载比较有意思——它既涉及规则，又涉及语义，所以很容易让人误判为"必须上 LLM"。

先从规则侧看：将时间字符串统一成固定格式、把电话号码脱敏、将金额字段规范为小数——这些都是纯规则操作，用正则 + 格式化函数就能搞定，执行速度微秒级。你完全不需要让 LLM 理解"2024年3月5日"是什么意思再输出"2024-03-05"，正则映射一秒跑几万条。

但确实有一类清洗任务需要语义理解：比如从一段非结构化的地址文本中提取省市区、从一段聊天记录中识别用户意图。这些任务因为输入形态不确定，规则覆盖不全，才需要用 LLM 来做语义抽取。

所以我对数据清洗类负载的拆分方法是：先跑规则清洗，把能结构化的部分全部结构化；剩下无法用规则处理的高歧义文本，才作为"漏网之鱼"送进 LLM。最后再加一层基于规则的结果校验，确保模型输出符合格式要求——如果格式不合法，直接丢弃并走兜底逻辑。

这样一条链路走下来，LLM 的调用量通常只占原始负载的 5% 到 10%，成本降了一个量级，清洗质量反而更稳定。

3.4 负载类型四：异常检测与容错控制

关于"LLM 智能体自主容错控制"，热搜词里反复出现，这确实是一个 AI 工程化里非常吸引人的方向——让 LLM 当"智能运维大脑"，自主发现问题、定位原因、执行修复。听起来很酷，但落地时一定要拆开看。

我见过一些团队尝试让 LLM 直接接管故障处置链路：检测到服务异常，LLM 自动分析日志、生成修复命令并执行。这个方案在演示环境里很惊艳，但在生产环境里我是不敢直接用的。原因很简单，故障处置是"高风险确定性场景"——你需要的不是"大概知道哪出了问题、大致修改一下配置"，而是"精确定位根因、按照预案逐步执行、每一步都确认影响范围"。

更合理的做法是"感知层用专用模型、决策层用 LLM、执行层用脚本"的混合架构。具体来说：第一步，用基于规则的监控和异常检测模型（比如时序异常检测、阈值告警）兜住所有确定性信号，一旦触发告警，立即进入预案流程；第二步，把告警信息、上下文日志、拓扑关系整理成 Prompt，调用 LLM 生成一份"根因假设分析报告"；第三步，报告中的建议只作为参考，真正执行变更必须经过审批链路和预检脚本。

这个架构下，LLM 从"决策者"降级为"分析顾问"，反而是它最适合的角色。系统既拥有了语义分析能力，又没有把关键控制权交给一个不可控的模型。

4. 混搭架构怎么落地：一套可复用的参考方案

4.1 先统一接入层，把"决策"和"执行"分离开

这是我多次踩坑后总结出来最重要的一条架构原则：无论你用什么模型做决策，都要把"决策逻辑"和"业务执行"彻底解耦。

你的系统里不应该出现"调用 LLM 然后直接改数据库"这种代码。正确的做法是：决策环节独立成一个决策层，这个层只负责输出"结果对象"——包含判定结果、置信度、依据、决策模型标识符——业务层再根据结果对象执行后续动作。

这样做的好处有三个。第一，你可以在决策层随时切换模型，今天是 LLM，明天换成规则模型或分类模型，业务层完全无感。第二，你可以对每一次决策做日志和审计——"这条请求由规则引擎判定为拒绝，理由是命中风控策略 #12"，而不是"这条请求由 LLM 判定为拒绝，理由无法解释"。第三，你可以针对不同负载配置不同的决策链路——A 类请求走规则，B 类请求走分类模型，C 类请求才走 LLM——灵活度大幅提升。

实现上也并不复杂，本质上就是一个"决策网关"：接收请求上下文，根据预设的分流策略，决定将请求路由到规则引擎、分类模型还是 LLM，最后统一返回决策结果对象。

4.2 三种决策引擎的选型和适用边界

在混搭架构里，我通常把决策引擎分成三类，分别对应不同的负载类型。

第一类：基于规则的引擎。适合"条件明确、输出枚举、逻辑可穷举"的场景，比如路由分发、参数校验、状态机转换。实现方式可以是简单的 if-else 函数，也可以用规则引擎框架（比如 Drools 之类的商业或开源方案）管理成百上千条策略。规则的维护成本会随着复杂度上升，所以这类引擎适合规则数量可控、变更频率不高的场景。

第二类：专用决策模型。适合"特征明确但规则难以手工穷举"的场景，比如风险评分、异常检测、内容分类。这类模型通常是针对特定任务训练的小模型，参数量在几百万到几千万之间，单次推理耗时可压到 10 毫秒以内，且行为确定性高。相较于 LLM，它少的是"通用语义理解能力"，多的是"聚焦、稳定、可解释"。

第三类：LLM。只用于"语义理解、生成、开放问答"类场景。在决策链路里，它担任的是"辅助决策"或"兜底判断"的角色，必须在前后都加上确定性约束——前置校验限定它的输入范围，后置校验限定它的输出格式。

三类引擎的定位可以用一句话概括：规则引擎管"已知"，专用模型管"分类"，LLM 管"理解"。它们不是替代关系，是互补关系。

4.3 分流策略与降级链路设计

有了三种决策引擎，下一步就是设计分流策略——什么请求走什么引擎，这是整个架构的核心。

我常用的分流原则是"简单先行、由快到慢"：先把能通过规则判断的请求全部拦截下来，再让剩余请求进入分类模型，只有最复杂的一小撮请求才送到 LLM。这样做能确保 80% 以上的负载以最低成本最高速度完成决策，同时 LLM 的调用量被压缩到很小的一个比例。这也是我做负载调度器设计时反复强调的：调度器的首要目标不是"把每个请求都处理得最聪明"，而是"把每个请求分给最合适的处理器"。

降级链路同样重要。无论你把 LLM 放到哪个位置，都要假设它可能会失败——超时、限流、返回格式非法。所以每次调用 LLM 时都要带上"兜底策略"。我在实际项目中的兜底方案是：如果 LLM 调用失败，系统自动降级到分类模型或规则引擎的结果。即使降级后的结果没有 LLM 那么"聪明"，但至少能保证主流程不断。这个"降级必须优于报错"的原则，帮我避过好几次线上事故。

另外，所有决策结果都应该落到日志里，包含三个关键字段：决策引擎标识、输入摘要、输出结果。这不仅是审计需要，更是你做模型迭代时最宝贵的数据资产——你会发现，分析一段时间的日志之后，你能很清楚地看到"哪种负载在规则引擎里频繁出错，需要升级到分类模型"、"哪种负载在 LLM 里频繁超时，需要换更轻的模型"。

5. 常见问题与避坑实录

5.1 典型问题速查表

我把平时被问得最多、以及实际踩过的问题整理成了表格，给同样在做混搭架构的同行们一个参考。

5.2 一个值得反复强调的架构教训

最后分享一个我自己印象最深的项目教训。有一回，我们接手了一个客服工单自动分类系统，最初版本是"所有工单一律进 LLM 分类"。准确率确实高，但问题出现在两个维度：一是成本高到业务方直皱眉，二是高峰期常常因为 LLM 限流导致工单积压。

我们花了两个星期做了重构，核心就一件事：把"先判断走哪条链路"这一步前置。先用规则引擎处理带有关键词标签的工单（比如包含"退款""投诉""发票"等明确关键词的），这一步直接过滤掉了大约六成负载。剩余四成工单再进入一个轻量级文本分类模型做粗分。最后只有模型置信度低于阈值的工单，才交给 LLM 做精细化分类。

重构之后的效果是：LLM 调用量降到了原来的 15%，总链路平均处理时长从 3 秒降到 200 毫秒以内，成本直接省了八成以上，而分类准确率不仅没有下降，反而因为"规则兜住了确定性部分 + LLM 只处理真正难的样本"而略有上升。

这次经验让我形成一个很坚定的认知：好的 AI 应用架构，不是把所有聪明都堆在一个模型上，而是把不同负载放到最合适的位置上。LLM 是很强，但它应该是"最后一道闸"，而不是"唯一一扇门"。该扛负载的用专用决策模型去扛，该输出语义的才让 LLM 来发挥，这才是工程化最稳的做法。

如果你正在设计一个包含 LLM 的决策系统，建议你先画一张分流图：哪些请求走规则、哪些走模型、哪些走 LLM，每条链路的失败兜底是什么——把这几个问题想清楚了，系统的稳定性和成本基本就稳了一大半。