企业官网建设流程全解析

很多人把大模型当成一把万能扳手，不管什么螺丝都想去拧一下。遇到用户请求，先甩给 LLM；内容打标，LLM；关键词提取，LLM；甚至连简单的条件判断都要套一层提示词。结果呢？推理成本翻了几倍，响应时间飙到一秒以上，线上时不时还冒出几个诡异的幻觉输出，吓得运营同学半夜打电话。

我做了几年的 AI 应用落地，踩过不少这样的坑。后来把一部分负载从大模型上挪走，换成了专用决策模型，成本和稳定性立刻就好了很多。

这个标题看起来像一句吐槽，其实背后是一个很严肃的架构问题：什么样的负载适合 LLM，什么样的负载根本不需要上大模型，甚至上了大模型反而更糟。

这篇文章就聊聊我自己的判断标准、分类方法，以及一些实际项目中总结出来的替换经验。希望能帮你在做技术选型的时候少走点弯路。

1. 先把负载分清楚：不是所有决策都叫决策

我们通常说的“负载”，在 LLM 应用里其实可以拆成三类：内容理解类、决策控制类、生成创作类。这三类对模型的依赖程度、容错要求、成本敏感度完全不一样，混在一起谈“该不该用 LLM”就是耍流氓。

1.1 生成创作类：LLM 的主场，别折腾

生成类任务，比如文案润色、代码注释生成、邮件起草、故事创作，这类任务的核心诉求是“开放”、“多样”、“没标准答案”。你用规则模型或传统分类模型去做，出来的东西生硬到没法看。

这类负载没有争议，交给 LLM 是最优解。唯一要注意的是别用太大的模型做太轻的活，比如写个商品简介非得上 1750 亿参数的旗舰模型，那是烧钱玩。一个 7B 或 13B 的模型微调一下，效果和后端大模型差距没那么大。

1.2 内容理解类：看情况，能降级就降级

内容理解包括情感分析、意图分类、信息抽取、文本打标、摘要生成。这类任务有个特点：答案空间是有限的。用户问“天气怎么样”，意图就是“查天气”，不会跑出一个“第六维空间天气指数报告”；用户提交一条“退款”工单，意图就是“退款”，不会变成“向宇宙发射退款信号”。

答案空间有限，就意味着可以用更轻量的模型去拟合。传统做法是 BERT 系列做微调，效果稳定、推理延迟低、单次调用成本可以忽略不计。

但稍微复杂的理解任务，比如“这段话里包含几个隐含意图”、“这个用户吐槽背后真实情绪是什么”，传统小模型的表现就吃力了。这时候 LLM 才有优势。

1.3 决策控制类：最容易“用力过猛”的环节

决策控制类负载，指的是系统根据输入数据做出一个动作选择，比如：路由分发、权限校验、流量调度、参数自适应、状态机流转。

这类负载的输入是明确的，输出是确定的，往往只有几个离散选项。最典型的例子就是智能客服系统的“会话流转”：用户说了一句“我要投诉”，系统要决定下一步是进入投诉流程，还是先安抚情绪，还是转人工。

这个决定，老实讲，用一个文本分类模型就够了，甚至可以写死规则。但很多团队非得上 LLM，理由五花八门：字面匹配太死板、用户表达太灵活、想让系统显得“聪明”。

结果是：每次会话流转都要等一次大模型推理，用户那边转圈圈，系统这边烧算力。

1.4 我的负载分类速查表

你在做负载评估的时候，先对号入座。明白自己手里的活属于哪一类，再考虑要不要用 LLM。

2. 判断标准：三个问题决定要不要把负载迁走

我判断一个负载到底该不该继续挂在 LLM 上，不会看什么高深理论，就问自己三个问题。这套方法用了几年，基本没有翻车。

2.1 标准一：这个决策的“错”是不是不可承受

LLM 输出的最大问题不是笨，而是不稳定。同一句话，温度设 0 都可能在两个答案之间跳。如果这个负载的错误会直接导致资损、违规、伤用户，那就不适合纯 LLM 做最终决策。

举一个真实案例：我们曾经做过一个电商平台的售后审核模块，用户的退款申请要先判断“是否符合退款条件”。这个判断涉及订单状态、商品类型、售后时效等多个条件。

最开始直接用 LLM 判断，结果连续出现两个问题。第一，同样的申请内容换个表达方式，LLM 给出相反的结论。第二，模型偶尔会“脑补”出订单里不存在的规则。

后来把审核逻辑抽出来，写成了规则引擎加决策树，把文本理解部分保留给 LLM，比如“识别用户申请中提到的关键信息”，但最终放不放过，完全由规则决策。

这个改动的结果很直接：审核准确率从 94% 提到 99.7%，线上再也没出现过规则误判导致资损的客诉。

2.2 标准二：延迟和成本是不是已经顶不住了

很多人忽略了，LLM 的推理延迟不是恒定不变的，输入长度一变，延迟就跟着变。当你的系统达到一定并发后，P99 延迟会非常难看。

我们有一套内部指标：如果单次决策的端到端延迟超过 800ms，或者日均推理成本占整体云资源成本的 15% 以上，就停下来说清楚这个负载到底解决了什么问题。

有一次我们排查性能瓶颈，发现一个首页的信息流推荐模块，里面有个标签判定环节，竟然动态调用了 LLM 接口，单次判定 1.2 秒。这个环节根本不需要理解语义，就是基于用户行为数据算标签优先级。我们后来换成了 LR 排序模型，单次判定降到 3ms，成本几乎降到零。

那天我盯着监控面板想了很久：如果这个负载早一点做成本评估，能省下大半年优化资源的时间。

2.3 标准三：有没有更稳定的“封闭式替代方案”

LLM 本质上是一个开放域模型，它能回答任何问题，但这也意味着它在封闭域任务上不够可靠。

与其让一个“通才”去答只能选 A/B/C/D 的题，不如让一个“偏才”专注做这道题。

你在评估负载时，先试着把它拆成两个部分：理解部分和决策部分。理解部分保留 LLM，比如解析用户的模糊表达、抽取实体；决策部分换成代码逻辑、规则引擎、检索匹配或小模型分类。

举一个落地案例：知识库问答里有个“问题分发器”模块，用户提问后，系统要决定把问题分给“售前”“售后”“投诉”还是“技术”哪个队列。

这个分发动作的准确率直接决定后链路质量，而且输出类别是固定的四种。

还用 LLM 做分发？完全没必要。

我们用一个轻量级的文本多分类模型，输入是问题文本，输出是四个类别的概率分布，模型文件只有几十 MB，CPU 上都能跑，单次推理 1ms 级别。

这个模型上线后，分发准确率从 LLM 时代的 86% 提升到 93%。原因是它只见过这四个类别的训练样本，不会像 LLM 一样去“自由发挥”。

2.4 小结：把负载拆开看，别一把梭

这三个问题合在一起，就是一套很实用的量化评估框架：

• 错误代价 > 收益：果断迁走
• 延迟/成本超阈值：果断迁走
• 有封闭式替代方案：果断迁走

三个问题都没有命中，说明这个负载确实需要 LLM 的开放理解能力，那就留着，但也要做好兜底设计。

3. 什么负载该换专用决策模型：实操案例拆解

下面几个场景都是我在真实项目里处理过的。选它们是因为覆盖面比较广，你可以直接借鉴思路。

3.1 案例一：智能客服的会话状态机

智能客服肯定是 LLM 的重度用户。但别被骗了，整个客服链路里，真正需要 LLM 的只有对话生成和复杂语义理解，其余全是决策负载。

我们做会话流转时，最初设计是：用户每发一句话，大模型先理解，再决定“接下来走哪个意图分支”。

结果上线后有两个问题。第一，每轮对话都要等大模型推理，用户体验在高峰期明显变卡。第二，状态流转偶尔会乱跳，明明用户说“我要退货”，模型抽风跳到“我要投诉”分支。

后来我们加了一个轻量级的调度层：

• 第一层：关键词命中 + 规则引擎，快速判断用户的显性意图（“退货”“投诉”“人工客服”）
• 第二层：BERT 分类模型，处理模糊表达（“这东西不好使” -> 疑似故障反馈）
• 第三层：LLM 兜底，前面两层都没把握时，才调用大模型做深度理解

这个三层设计上线后，90% 以上的用户请求在前两层就完成路由，只有不到 10% 的对话会触达 LLM。整体成本下降了 70%，决策延迟从秒级降到百毫秒级。

这里面最核心的思考是：不要用一个昂贵的通才去做一个便宜的专才就能干的事。

3.2 案例二：内容审核中的风险分级

内容审核大家都很熟了。合规场景下第一原则永远是确定性优先，因为审核结果要可回溯、可解释、可追责。

我们用 LLM 做过一段时间的辅助审核，模型可以给出“疑似违规”的判定，但问题有两个：

• 模型判定的依据不稳定，同一个内容微调一下措辞，边界就飘了
• 一旦审核结果有争议，无法向质控团队解释“模型为什么这么判”

后来我们把审核链路改成分级策略：

• 一级：规则库 + 敏感词库 直接命中，秒杀
• 二级：文本分类模型（针对文本类别），判断是否为高风险类型
• 三级：LLM 辅助理解，输出风险点说明，供人工复核参考

这个方案下 LLM 反而成了辅助工具，而不是决策主体。人工审核员在看 LLM 的输出时，会参考模型给的理由，但最终裁定权在规则引擎和审核人员手里。

这个设计让审核结果可以追溯、可以解释、可以复现，完全符合合规审查要求。

3.3 案例三：日志异常分类与工单自动路由

运维侧也有大量决策负载。最早我们有套工单系统，用户上报问题后，工单要先分类，再分配给对应运维组。

一开始用 LLM 分类，准确率还行，但因为是自建 IDC，GPU 资源非常紧张。一个工单分类就要占用宝贵的推理资源，其他核心业务在排队，运维团队怨声载道。

我们去分析了一批工单文本后发现，用户的表达虽然长尾，但主体部分还是高度重复的（“数据库连接失败”“接口超时”“磁盘告警”“页面打不开”）。

于是做了两件事：

1. 用离线任务定期跑向量化 + 聚类，把常见工单类型沉淀成模板
2. 在线实时分类改用 fastText 模型，词向量加 n-gram 特征，轻量高效

现在工单系统上线后，90% 的工单分类走 fastText，5% 走模板匹配，只有 5% 真正无法归类的长尾工单才送到 LLM。

这个案例里，我特别想强调一个概念：负载是可以分流的，不用全体走一条路。你的系统完全可以让 90% 的负载走轻量链路，5% 走中等链路，剩下 5% 才走重量级链路。流量的价值不一样，花在它们身上的成本自然也不一样。

3.4 案例四：推荐系统中的偏好排序

最后聊一个容易忽略的：推荐系统里的打分和排序。

很多团队在试验“用 LLM 做个性化推荐”，让模型根据用户历史行为生成推荐理由和排序。我知道这看起来很酷，但落地之后成本高到你怀疑人生。

推荐场景的典型特征是：请求量大、实时性要求高、候选集大。用 LLM 对每个候选商品打分，那延迟和成本是灾难级的。

合理的方式是混合架构：

• 召回阶段：用向量检索或协同过滤，把用户可能感兴趣的几十个候选拉出来
• 排序阶段：用 GBDT、LR 或者深度排序模型，对候选打分排序
• 解释阶段：让 LLM 生成推荐理由，作为前端展示

这才是各就各位。你也不用担心 LLM 在这里丢了工作，它负责的是用户看得见的文案，而不是后端冷冰冰的决策数字。

4. 负载调度与流量治理：别让 LLM 堵住系统主干道

把负载挪出 LLM 之后，还有一个经常被忽视的问题：就算你已经决定了哪些负载走 LLM、哪些走专用决策模型，你还需要一套“负载调度器”来管理流量。

这个调度器做的事情类似传统架构里的负载均衡器，但优先级更高——它决定了每个请求应该路由到哪条处理链路。

4.1 负载调度器：L4 还是 L7，都得能控流

我们当时的系统在接入 LLM 之后，访问流量暴增，最初的网关在并发一高就报错。后来在网关层加了一个负载调度器，专门负责流量接入和分发策略。

调度器的核心职责有三个：

• 识别负载类型：通过 header、路径、参数模式，识别当前请求属于“生成类”“分类类”“决策类”哪一种
• 分流到对应处理单元：分类类负载直接走到规则引擎或小模型服务，生成类负载才走到 LLM 网关
• 动态降级：当 LLM 服务出现超时或不可用时，默认把高风险决策流量切到规则链路

这套设计让我想到传统架构里的防洪峰策略。以前做高并发系统，我们会在 Nginx 层做限流、熔断、降级。现在做 AI 系统，同样需要这套思路，只是调度的维度从“哪个服务”变成了“哪类智能负载”。

4.2 屏蔽高负载 JavaScript：给前端减负

可能你会问，“屏蔽高负载 JavaScript”和文章主题有什么关系？

我遇到过不止一次：前端页面里嵌入了一段直接调用 LLM 接口的 JavaScript，用户在浏览器里每点一次按钮，就触发一次大模型请求，结果页面卡成幻灯片。

这不是算法问题，是前端资源消耗问题。高负载的 JS 脚本在浏览器解码、执行时，会占满主线程，导致页面失去响应。就算后端性能再好，前端阻塞一样能把体验毁掉。

我的建议是：前端代码里禁止直接发起 LLM 调用。所有对模型的请求，统一走后端 BFF 层，由后端完成负载识别、调度策略、鉴权、缓存等逻辑。前端只负责展示结果。

这样做的几点好处很明显：

• 请求地址统一收敛，便于鉴权和限流
• LLM 的密钥、提示词模板不会暴露在浏览器侧
• 后端可以做结果缓存，同一类问题短时间内重复请求时可以直接命中缓存，减少 LLM 调用

4.3 动态降级的正确姿势：先降级，再熔断，最后拒绝

负载调度器里最考验功力的是降级策略。

系统在高峰期打满时，如果你不加控制，LLM 服务的接受能力会直线下降，大量请求排队、超时、报错，最终拖垮整个应用。

我们的策略是三层递减：

1. 先降级：把非核心的 LLM 决策负载切到规则引擎或小模型链路，虽然效果可能打点折扣，但至少服务可用
2. 再熔断：当 LLM 服务错误率达到阈值，直接熔断调用，不再往 LLM 网关发送新请求
3. 最后拒绝：如果小模型链路的容量也到了瓶颈，才允许调度器返回友好提示或排队请求

这个顺序很重要。降级一定是最先做的，因为它的损失最小、恢复最快。熔断是有损的，会直接放弃当前请求。拒绝是最不得已的选项，只在系统濒临崩溃时才会触发。

我用这个策略扛住过一次流量高峰，那次活动流量是平时的 8 倍，LLM 集群提前打满，但因为有了降级链路，用户端的整体体验没有崩盘，页面依然能给出基本回复，只是少了一些生成类的内容。

5. 从 LLM 到专用决策模型：迁移路径图

前面聊了不少思路，这一章给一份可以直接落地的迁移路径。这套路径我们在多个项目中验证过，照着走基本不会出大问题。

5.1 迁移的五步路径图

第一步：盘点存量负载

把所有调用 LLM 的接口全部列出来，建立一个清单。字段包括：接口名称、调用场景、单次输入 token 均值、单次输出 token 均值、端到端延迟、日均调用量、单次调用成本、错误率。

没有这份清单，后面所有优化都是空谈。

第二步：按“三问”做完筛选

对照第二节的三个问题，给每个负载打标：

这一步完成后，你基本能看到一个清晰的分布：真正需要 LLM 的负载往往不到三分之一。

第三步：定义替代模型的输入输出

迁移前先明确边界：新模型的输入是什么、输出是什么、准确率目标是多少。

比如工单分类：输入是工单标题 + 描述文本，输出是十个工单类别。那么你需要准备一万条左右的历史工单数据，做标注和切分。

第四步：小流量验证

新模型部署后先在灰度环境跑起来，把它的预测结果和 LLM 的预测结果做对比。这里要注意一个细节：不能只看准确率，还要看“人看起来合不合理”。

我们曾经某个分类模型准确率 95%，但运营反馈“它的分类逻辑太机械”，比如把“发货地是深圳”误判成“深圳发货”，在细分类上让人哭笑不得。后来我们在训练时加入了领域词表，这个问题才解决。

第五步：逐步切流量

灰度验证通过后，开始按 10%、30%、50%、100% 的节奏切流量。每一档都观察延迟、成本、错误率三个指标，确认没有劣化再继续。

整套迁移周期一般两到三周能完成，不复杂，但需要耐心。

5.2 迁移过程中最容易忽略的细节

细节一：专用决策模型也需要“提示词”吗？

专用决策模型不需要，但需要特征，这些特征的提取方式最好做成可配置的接口。比如分类模型的输入不只是原始问题文本，还会拼接一些用户画像特征（会员等级、历史行为偏好），这样模型能学到更多信息。

细节二：迁移后的监控指标别照抄 LLM

过去你监控 LLM，看的指标是 token 消耗、攻击检测率、幻觉率。现在迁移到专用决策模型，要换一套指标体系：推理延迟、QPS、内存占用、分类召回率、特征缺失率。指标定义同步更新，否则监控失控都不知道为什么控。

细节三：保留一个“逃生舱”

即使确定了可以迁移，也要在代码里保留一个开关：随时可以把流量切回 LLM。这不是不信任新模型，而是为了应急。

有一次我们迁移了客服路由模型，上线第三天发现新模型对特定方言识别的准确率远低于 LLM，造成了小范围用户投诉。我们靠着一个配置开关 10 分钟之内切回 LLM，然后再去补数据、重新训练，整个过程没有造成大的用户影响。

6. 评估体系：怎么量化专用决策模型的价值

没有评估体系，说“换了模型之后更好”就是拍脑袋。我建议从四个维度建一套行之有效的评估框架。

6.1 评估维度一：准确率，但要分业务口径

准确率不是单一数字。在一个决策链路里，要分头定义每条链路的准确率：

• 路由准确率：请求被分发到正确类别的比例
• 判定准确率：决策模型给出的结论和人工一致的比例
• 覆盖准确率：模型能覆盖的业务场景占全部业务场景的比例

比如客服路由模型，路由准确率目标设为 90%，判定准确率目标 85%。两个数字分开看，落地方案才会更有针对性。

6.2 评估维度二：成本，要算到“单次请求”而非“总花费”

很多人只盯着总账单，其实那是被平均了的大锅饭。真正要算清楚的是单次请求成本。

这些数字真实得吓人。单次看起来差距不大，乘以日调用百万次，一个月下来就是一笔不小的预算。

6.3 评估维度三：延迟，别只看平均，要看 P95/P99

LLM 推理的延迟分布往往比小模型宽，高并发时尤其明显。用 P95 和 P99 作为标准更能反映用户体验。

我们在迁移前的数据：LLM 工单分类 P99 是 3.2 秒，迁移后的小模型 P99 是 45ms。用户感知从“转圈圈好久”变成了“秒开”。

评判一个决策模型是否合格，我个人的建议是：P99 延迟不超过上游接口超时阈值的一半，这样就算模型出问题也不会大面积拖垮上游。

6.4 评估维度四：可解释性和稳定性

决策模型的另一个巨大优势是可以在决策后输出置信度和关键特征贡献。

比如客服路由模型输出了“投诉意图，置信度 0.92，特征贡献最大的是‘我要投诉’这个词”。

这样的输出可以直接展示给运营人员，他们能理解为什么路由发生了，也能够依据置信度阈值去调整人工介入策略。这部分价值很难量化，但对信任体系的建立非常重要。

7. 实测记录：一次完整的负载替换过程

这一节，我把一次完整的替换过程记录拎出来，方便你对照自己的项目。

背景：我们的工单系统每天约十万张工单，之前全部走 LLM 分类。单日成本约八百块钱，P99 延迟 2.8 秒。目标是降本增效，并缩短整体流程时长。

过程分四个阶段：

阶段一：数据准备（3天）

从历史工单中导出 30 万条已完结的工单，字段包含：标题、描述、标签、分类结果。清洗后按 8:1:1 切分成训练、验证、测试集。

阶段二：基线建模（2天）

先用简单的 TF-IDF + Logistic Regression 建一版快速基线，准确率大约 78%。再换成 fastText（词向量 + n-gram），准确率提升到 85%。两个模型都在只有 CPU 的机器上运行，单次推理时间都在 1ms 左右。

阶段三：联调与灰度（4天）

在测试环境跑通模型服务，定义好了输入输出格式。灰度切换时，用 10% 的流量跑了一周，重点观察“新模型分类结果人工接受率”，新模型是 91%，旧 LLM 只有 86%。

阶段四：全量切流（1天）

切到 50% 观察一天，再切 100%。整个过程没有出现明显劣化，最终保留新模型作为主链路，LLM 降级为疑难工单的长尾分类兜底。

最终结果：

这个数据单我留了很久，每次团队说“新模型效果不如 LLM”的时候，我就把这份记录重新贴一遍。

8. 常见问题与排查技巧实录

8.1 问题一：替换后准确率反而下降了，怎么办

常见原因有三个：数据分布不一致、类别不平衡、特征工程做得不够。

排查顺序建议：

1. 先查特征是否有效覆盖业务边界情况（“退款”“退货”“换货”这类近义词是否都进入了训练样本）
2. 再查训练集和线上真实数据的分布差异，比如线上有很多方言表达，但你训练集里全是书面语
3. 最后看类别不平衡，比如“技术咨询”类别有 3 万条样本，“投诉”类别只有 800 条，模型天然倾向把样本分到多数类，此时要加类别权重或做采样

8.2 问题二：专用决策模型上线后，运维拒绝验收怎么办

这类情况往往不是模型差，而是运维团队对“黑盒模型”缺乏信任。应对方式不是解释，而是给信任：

• 增加“预测解释”功能：每次预测都输出置信度和特征贡献
• 增加“人工复核通道”：模型低置信度的样本自动送人工复核
• 建立对比报表：每周输出模型与人工判定的差异分析

运营团队看到这些数据之后，信任度提升很明显，哪怕模型偶尔判断失误，也不会被一票否决。

8.3 问题三：模型上线后出现了“长尾漂移”

业务场景是会变的。一个工单分类模型，年初分类准确率 95%，半年后可能降到 85%，因为用户的语言表达方式、业务上下文都产生了变化。

解决办法是定期做数据回流：

• 每月从线上抽取样本新增到训练集
• 每季度重新训练一次模型
• 半年做一次特征评估，看哪些特征权重变了，哪些特征已经失效

如果期间业务模式发生大调整（比如从售后客服升级成全渠道客服），那就需要重新进行数据生产，不能指望旧模型硬扛。

8.4 问题四：替换后测试时没问题，一上线就开始报错

我先确认一下“报错”是什么类型，再决定怎么处理：

• 如果是推理服务本身的性能问题（超时、OOM、内存泄露），这类问题会在压测阶段暴露，但如果压测没有按真实流量配比做，就容易漏
• 如果是预测结果不符合预期，多为输入数据格式和训练时不一致。常见的有：文本未清洗（HTML 标签没去掉）、编码不一致（UTF-8 和 GBK 混用）、字段缺失（训练时用了“标题 + 描述”，线上只传了标题）

我的建议是每次上线前做一次“线上数据回放”：用接线的真实日志去喂新模型，看结果是否符合预期。这一步成本很低，但能挡住大量低级错误。

9. 最后分享一个核心经验

做了这么多负载替换之后，我最大的体会是：不要先选模型，而是先选边界。

边界是什么？是你的业务对这个决策的容错度、可解释性、延迟成本要求。先把边界画清楚，再决定在边界里面用什么模型。LLM 不是唯一解，也不该成为默认解。

我在实际选址中会先想清楚这几个问题：

• 这个负载如果判断错了，造成什么后果？
• 用户能等待的最长时间是多少？
• 运营团队对这个决策的解释要求有多高？
• 我的 GPU 预算经得起多少比例的请求走大模型？

把这些想明白了，模型选型自然而然水落石出。有时候方案简单一点，系统反而能走得更远。