企业官网建设流程全解析

最近一年，我越来越频繁地在各种代码评审和架构讨论里看到同一个问题：团队把什么都往大模型上堆。业务规则判断要问大模型，字符串格式化要问大模型，连一个简单的状态机流转都要套上“智能决策”的壳子去调一次LLM接口。结果呢？延迟上去了，账单上去了，线上还时不时飘几个诡异的超时告警。

所以我想认真聊一个话题：到底什么样的负载适合继续用LLM，什么样的负载应该换到专用决策模型上去。这里的“专用决策模型”，我指的是规则引擎、检索排序、传统机器学习模型（逻辑回归、GBDT这类）、有限状态机，甚至是经过剪枝的小型微调模型。它们不需要动辄几千亿参数，也不需要通用对话能力，但它们有确定性的输入输出、可预期的延迟和成本。

这篇文章不劝退LLM，也不是捧高传统模型。我只想把这几年在线上系统里摸爬滚打看到的真实负载情况摊开来讲清楚，给出一套可以拿去评审会上用的判断框架。如果你正在犹豫某个功能到底要不要接大模型，那这篇文章应该能帮你省下一笔不小的试错成本。

1. 为什么人人都想把负载塞给LLM：三个被低估的成本陷阱

先说一个我印象很深的评审场景。某个内部工单系统想把“工单优先级判断”交给大模型，理由是“人工写的规则太多，维护不过来”。听起来合理，但你真去算一笔账就会发现，这个需求里百分之八十的判断路径，其实用一张配置表加十几个条件分支就能覆盖。

这个现象不是个例。我观察下来，团队选择LLM作为默认方案，通常不是因为技术推演的结果，而是因为三个很隐蔽的心理惯性。

第一个惯性是“对话式交互的幻觉”。现在的开发框架、API文档、开源Demo，几乎全在演示“你问一句，它答一句”。这种交互模式太自然了，以至于我们在设计内部系统的时候，会不知不觉把所有的决策节点都改写成“输入一段文本，输出一个结论”的对话形式。但生产系统里的决策，大部分根本不是对话，而是确定性的规则映射。比如根据订单金额和用户等级计算折扣，根据设备指纹判断风险等级，这种任务天然是函数式的，强行包一层自然语言接口，纯粹是给自己找麻烦。

第二个惯性是“智能感的误判”。管理层和产品侧看到大模型能写诗、能翻译、能总结，就默认它处理任何“看起来需要理解力”的任务都比传统程序好。但实际上，LLM的强项是开放域理解与生成，而不是封闭域里的高频精确决策。你去问它“这个请求应该路由到A服务还是B服务”，它能给你一套漂亮的分析，可它并不知道A服务现在的CPU水位是多少，也不知道B服务的历史P99延迟曲线。这些信息在规则引擎和负载均衡器里是明明白白的数据，在大模型那里反而变成了“猜”。

第三个惯性最要命，叫做“复杂度转移幻觉”。很多人觉得，规则复杂到一定地步，维护成本就指数级上升，不如让大模型“自己学”。这话对一半。规则的维护成本上升确实存在，但把它全部丢给大模型，你只是把“维护逻辑”的复杂度，转移成了“验证输出质量”的复杂度。规则错了你改一行配置，大模型错了你要准备数据集、做评测、调提示词、处理回归。哪个成本高，真不好说。

这三个陷阱叠加在一起，就让很多系统在不知不觉间背上了一个根本不属于自己的负载。要判断一个负载该不该留在LLM这边，我们得先给负载本身画个像。

2. LLM负载的四种典型画像：从感知、翻译到决策的分类方法

我有个习惯，拿到一个待评估的需求，先不讨论技术方案，而是先给负载分个类。分完类，该用LLM的还是用LLM，该换专用决策模型的，理由会自己浮出来。

结合我看过的线上案例，LLM相关的负载大致能分成四种。

第一类是感知理解类。典型场景是意图识别、情感分析、实体抽取、文档信息提取。这类负载的共同特征是输入是非结构化的，输出是结构化的。比如用户发来一句“我想把订单取消掉，但是钱什么时候退？”，你需要从这句话里解析出intent=cancel_order和query=refund_time两个字段。这种任务传统NLP也能做，但LLM的确有巨大的优势——它能容忍表达上的千奇百怪，few-shot就能上手。这类负载，我强烈建议继续用LLM，因为它的核心价值就是那层语言理解能力，换规则去写穷举，写到你怀疑人生。

第二类是生成创作类。典型场景是文案生成、代码补全、摘要总结、翻译改写。这类负载的输入输出都是非结构化的，没有标准答案，质量靠人工主观评估。LLM是这类的绝对主力，没有什么可争的。唯一需要注意的是成本和质量之间的平衡，但那是用量策略问题，不是架构选型问题。

第三类是转换映射类。这种负载看起来很像第一类，输入一段文本，输出一个结构化字段，但本质上它做的是一一映射或者近似一一映射。典型场景是：把用户的自然语言地址解析成省市区编码，把设备型号描述映射到内部SKU编号，把客服话术分类到固定的工单类型。这类负载的分界线在于：输出的可能性空间是不是预先可知的。如果所有可能的输出你都能在开工之前列出来，那这就不是一个理解问题，而是一个检索加映射问题。你用LLM能做好，用分类模型加实体库也能做好，但后者的成本可能是前者的百分之一。很多系统里跑得最贵的那部分负载，恰恰是这一类。

第四类是决策规划类。典型场景是：给定当前状态，系统需要从若干动作里选一个执行，比如自动驾驶里的变道决策、交易系统里的风控放行、运维系统里的故障处置动作选择。这类负载对确定性和时延极度敏感。它可能需要感知能力来理解状态，感知部分可以交给LLM（比如读取告警文本、摘要日志），但最后的决策动作，我几乎不会直接让LLM拍板。因为LLM的推理过程不透明，输出不稳定，而且一次推理的延迟波动可能比专用决策模块高一个数量级。

把这四类负载按“输出是否开放”和“输入是否结构化”两个维度拉开看，你会发现一个很有意思的规律：LLM真正不可替代的区间，其实只在“输入非结构化且输出开放”这个象限里。感知理解类跨了半个象限，生成创作类整个都在里面。而转换映射类和决策规划类，输出端要么收敛、要么封闭，它们更适合落在专用决策模型那一侧。

3. 该换专用决策模型的红线场景：判别维度与自检清单

上一节的分类框架是感性的，到了评审会上你需要更硬的标准。我整理了一套判别维度，你可以拿它当尺子去量一个负载究竟该留在LLM还是迁出去。

输入输出结构是第一个维度。有一个非常朴素的测试方法：你在脑内模拟一下，如果把这个负载的输入换成一段JSON或者一组结构化字段，输出要求变成一个枚举值或者一个数值，你会不会觉得“少了点什么”？如果不会，那说明这个负载本来就不需要自然语言作为载体。我见过最极端的例子，有人把“判断字符串长度是否大于10”写成了prompt，让LLM回答true或false。这种负载换专用决策模型不是“该不该”的问题，而是“现在就该立刻换”的问题，因为规则引擎一行正则或者一个len()调用就解决了。

时延和吞吐的第二维度。你先给负载定两个数字：单次决策最长可接受的延迟，以及峰值每秒需要处理的请求量。然后拿LLM的实测数据去对。一般商用LLM接口的P95延迟在几百毫秒到数秒不等，还要考虑网络抖动和排队。如果你算出来峰值吞吐是每秒2000次，单次延迟预算在50毫秒以内，那这个负载和LLM的物理性能之间隔着一条鸿沟，你只能用缓存、批处理和蒸馏小模型这些技巧去“补”，而这些技巧本身就是把负载往专用决策模型方向推。

成本敏感度是第三个维度。这里我给一个我常用的估算公式：单次决策的隐性成本 = 模型调用费用 + 平均重试次数 × 单次费用 + 因为延迟导致的业务损失单价 × 平均额外等待时间。很多团队只看第一项，觉得还能接受。但你把重试率算进去，再把业务侧因为等结果而拉长的响应时间折算成转化率损失，很多负载立刻就不划算了。尤其那些量级在百万次每天的判断类负载，一个在专用决策模型上跑1毫秒的规则，换成LLM可能要花几十毫秒和真金白银，算完账没有人会犹豫。

错误代价是第四个维度，也是最容易被忽视的。你要问自己一个问题：这个负载如果答错了，后果是什么？如果答错之后会执行一个不可逆的动作（比如拒绝交易、下发指令、删除数据），或者会直接面向用户产生可见的错误，那这个负载就有一个正确性底线。LLM的输出天生带有概率性，同一个prompt跑十次可能有九次一样，但你的系统不能接受那一次不一样。这种情况你需要的是可解释、可回归、可单测的确定性逻辑，哪怕它“笨”一点，但它的错误是可预测的。专用决策模型在这方面有天然优势：规则写错了你能定位到具体分支，模型阈值调错了你能复现bad case，而LLM的错误往往是一团模糊的“语义偏差”。

我建议你把这四个维度做成一张自检清单，挂在需求评审的Wiki里。任何新的负载要接入LLM，先过一遍清单，凡是满足以下任意一条的，就该优先考虑专用决策模型：

• 输出的可能值集是预先可枚举的，且枚举规模不超过几千。
• 单次决策延迟预算小于100毫秒，或者峰值吞吐超过每秒100次。
• 单次调用成本乘以年调用量超过某个业务可承受的阈值（比如影响季度利润的1%）。
• 错误会触发不可逆动作，且系统无法接受1%以下的随机错误率。

这四条不是绝对真理，但用它们去筛，能帮你筛掉大部分“其实根本不需要大模型”的负载。

4. 从LLM到专用决策模型的切换路径：规则、检索、传统模型与小型模型

好，现在到了动手的部分。假设你认同某个负载应该换下来，那往哪儿换？我按侵入性从低到高，给你四条路径，你可以根据自己的数据积累情况和工程节奏选。

第一条路径：硬规则引擎。适用条件是你的输出空间小且业务逻辑相对稳定。最典型的例子就是工单路由。很多团队一开始用LLM做意图分类，输入一句用户反馈，输出“账单/技术/售后”的标签，效果还行，但量大了以后成本受不了。这种负载其实完全可以用关键词加规则表做：命中“退款”“扣款”“账单”归为账单类，命中“崩溃”“白屏”“报错”归为技术类，命中“退货”“换货”“物流”归为售后类。说实话，规则引擎一开始的准确率可能只有85%，比LLM的95%低，但它有两个优势：你会非常清楚那15%错在哪，而且你有办法一个分支一个分支地补。补到三个月后，规则引擎的准确率可以追平甚至超过LLM，而成本几乎可以忽略不计。

第二条路径：检索式决策。适用条件是输出空间大但可以被索引化。我给你举一个真实案例。某个电商团队原来用LLM做“商品类目预测”，用户输入一段商品描述，模型输出一个叶子类目。类目有几千个，规则根本覆盖不过来。后来他们怎么换的？他们把每个类目的名称、别名、典型属性词全部倒排进一个检索引擎，用户输入先做分词和向量召回，取Top 20候选类目，再用一个很小的分类模型（甚至可以只是LightGBM）在这20个候选项里做排序。整个链路的延迟不到20毫秒，准确率和原来持平，成本下降了差不多两个数量级。这就是典型的“LLM负责理解能力，专用模型负责决策能力”的分工——但在这个迁移里，LLM其实只参与了最初的候选挖掘，线上决策完全交给了检索和排序。

第三条路径：传统机器学习模型。适用条件是特征可以显式构造，且你有足够的历史标注数据。风控、推荐排序、定价这类负载是这里的常客。我认识一个做用户运营的团队，他们原来用一个LLM判断“这个用户会不会在七天内再次购买”，理由是“LLM能理解用户的所有行为轨迹”。但行为轨迹本质上是时序特征，你把最近七天的访问次数、加购数量、优惠券使用情况、历史转化率抽出来喂给梯度提升树，效果很可能会超过LLM。为什么？因为这类问题的决定因素本来就是几个核心特征，而不是语言表达里的微妙情绪。LLM在处理这类表格型特征时远不如专用模型擅长，它天生是为序列文本设计的，不是为特征交叉设计的。

第四条路径：小型微调模型。适用条件是语义理解确实需要，但线上性能预算不允许跑大模型。现在开源社区里有一批几亿参数的小模型，比如各种蒸馏过的Mini版本、量化到4bit的7B/3B模型，单机CPU甚至移动端都能跑。如果你的负载既有开放性（不好用规则穷举），又有高频低延迟要求，与其去调一个云端大模型，不如基于小模型做任务微调。我自己实践下来的经验是：分类任务的准确性，一个小模型在几百条标注数据上微调之后，往往能逼近甚至超过通用大模型zero-shot的水平。而且它部署在你自己的推理服务里，延迟稳定在20到50毫秒，没有网络抖动，没有按Token计费，出错还能自己盯日志。这条路径适合的是“看起来像感知理解类，但业务量撑不起外部接口调用”的负载。

切换的时候有一个关键动作我必须提醒你：别一次性下线LLM，要做影子模式。影子模式的意思是，新上线的专用决策模型和LLM并行跑一段时间，专用模型的输出先不进生产流程，只落日志。你拿它和LLM的输出做对比，把两边的分歧样本捞出来人工标注。跑一到两周，攒够几百个分歧样本，你就能精确算出专用模型的准确率、坏case长什么样，以及是否值得彻底切换。这个步骤很多人嫌麻烦跳过，结果上线之后发现模型在某个边缘case上犯了低级错误，然后灰溜溜地又把开关切回LLM。影子模式看着慢，其实才是最快的路径。

5. 混合架构的协同：LLM和专用决策模型如何分工不打架

把一部分负载换下去之后，你可能要面对一段“混合架构”的时期：系统里既有LLM驱动的高智能组件，也有规则和专用模型驱动的确定性组件。很多团队在这个阶段会出问题，症状通常是：看起来两边都工作了，但整体链路经常出一些莫名其妙的bug，两边互相甩锅。

我见过一个例子。某客服机器人，意图识别用的是LLM，意图确认以后的具体流程控制用的是规则引擎。问题是产品设计上允许LLM“发挥创造力”——它会自己发明一些规则引擎里根本没有的意图标签。规则引擎收到一个没见过的标签，就只能走兜底分支，用户于是得到一句“抱歉，我暂时无法处理”。到了复盘会上，LLM团队说“我识别得很准”，规则团队说“我逻辑没问题”，但用户就是不满意。问题出在哪？出在两边没有约定一个稳定的接口协议。

混合架构里，我给三个原则，执行好了就能让两边安安稳稳地协作。

第一个原则是LLM只输出结构化意图，不输出“建议动作”。什么意思？就是说，LLM的下游如果接着专用决策模块，它的输出必须被约束在一个预先定义好的schema里，比如{"intent": "cancel_order", "slots": {"order_id": "12345"}, "confidence": 0.92}。它不能自由发挥去输出“我认为应该先给用户退款”这种动作级建议。动作的选择是决策模块的事，LLM只负责把用户输入映射成事实性的结构化表示。这样做的好处是，决策模块永远面对的是有限的、可预处理的输入空间，而不是无边无际的自然语言。

第二个原则是确定性模块永远拥有最终裁决权。LLM输出的confidence再高，也只是“候选”。最终的放行、拒绝、路由、执行，都要经过确定性规则或模型的那一道闸门。比如LLM识别出“用户想退款”，但退款金额是否在免审额度内、用户是否满足退款条件，这些必须由金额规则和用户状态机来判断。这不是不信任LLM，而是因为确定性模块有可审计性，出错了顶得上你回溯逻辑链条，而LLM的“语义理解”几乎是不可回溯的。不可回溯的组件可以做感知，不能做最终决策。

第三个原则是两边共享一份可观测性数据。混合架构最难排的问题就是端到端责任界定。我的做法是，在LLM和决策模块之间埋一个统一的日志节点，每条请求都记录：原始输入、LLM输出的结构化结果、决策模块的判定结果、最终动作、两边的耗时。出了线上问题，第一件事不是看哪边的代码，而是先看这个日志节点，定位分歧发生在哪一层。有了这份数据，后面做优化、做回归测试、做影子模式评估，都有了依据。

这三个原则本质上是把LLM放在“感知层”，把专用决策模型放在“决策层”，形成一个串行的流水线。感知层负责把非结构化世界翻译成结构化事实，决策层基于结构化事实做可解释的、可控的动作。这不是架构上的妥协，反而是最能发挥各自优势的做法。LLM不用再操心动作后果，专用模型也不用再去理解自然语言，各干各的，效率和质量都上去了。

6. 给架构评审的一点实践：量化迁移价值的测算方法

讲了这么多判断和原则，最后落到一个实操问题：你怎么说服别人，尤其是那些已经对LLM投入了真金白银的人，说“这个负载该换下来”。光说“成本高、延迟大”是不够的，你需要一份能摆在评审会上的量化测算。

我自己的测算方法，通常分三步走。

第一步，先算当前LLM方案的全成本基线。别只看接口费用，要把调用量、Token消耗、重试率、缓存命中率、人工标注校正的成本全部算进去。我见过一个团队，表面上每月LLM账单是三万块，但他们为了校验LLM输出质量，养了一个两人工标团队，人力成本折算下来一个月超过四万。这种隐形成本不算进去，你很难说服任何人做迁移。

第二步，估算专用决策模型的新增固定成本。规则引擎的维护工时、传统模型的训练和上线成本、小模型的推理基建，这些都可以量化。规则引擎可能只需要每周两个小时的维护窗口，小模型推理可能需要一台单卡服务器，把固定成本算出来摊到每个月。这一步要诚实，别为了追求好看的数字把维护成本压到零，不然评审会上被人一问就露馅了。

第三步，也是最关键的一步，测算迁移的收益边界。这里我习惯用一个很粗糙但直观的公式：

节约成本 = 原方案全成本 - 新方案固定成本 - 迁移期间的一次性人力成本。

这个公式算出来如果是正的，那理由已经够了。如果算出来是负的，但你还是想迁移，那你要找的是另一类收益：正确性提升带来的隐性价值，或者延迟下降带来的业务转化率提升。这些我建议你谨慎使用，因为隐性收益很难在一个季度内被验证，评审会上引用太大胆的数字，反而会伤害你的说服力。

做完这三步，把它写成一页纸的决策备忘录。里面附上你拿到的线上日志样例、LLM错误case的例子、以及新方案在影子模式下跑出来的准确率数据。评审委员会的人不一定都懂LLM的内部机制，但他们看得懂“这个case错了会损失多少钱，而新方案能把错误率降到什么水平”这种表述。

我自己的经验是，一旦你严格走完这套测算流程，大概有六成以上的“LLM负载”会被你主动劝退。剩下四成是真的需要LLM的，而正因为你敢于说“不”，你说“要”的时候才更有分量。

最后补一句个人体会。这几年AI能力迭代很快，“什么都往上塞”的现象会一直存在，但我越来越觉得，真正成熟的架构师，不是最会把玩最新模型的人，而是最清楚“什么东西不该用模型”的人。该用规则的时候用规则，该用模型的时候用模型，该用大模型的时候再上大模型，这才是让系统活得更久的方式。