企业官网建设流程全解析

1. 模型路由到底在解决什么问题

1.1 从一个真实场景说起

去年帮一家做智能客服的团队做架构评审，他们的技术负责人抛出一个问题：现在后台同时挂着三个模型，一个便宜但偶尔答非所问，一个贵但稳定，还有一个专门处理长文档。每次请求来了，代码里写死了一堆 if-else，判断用户问的是不是长文本、是不是简单寒暄、是不是需要专业领域知识，然后手动挑一个模型去调。上线三个月，这套逻辑改了十几版，每次改都提心吊胆，生怕把某个分支的判断条件写错，导致线上大面积超时。

这个场景就是典型的“模型路由”需求。所谓模型路由，说白了就是在用户请求和底层大模型之间加一层调度逻辑，根据请求的特征、成本预算、延迟要求、质量要求等条件，动态决定这次请求交给哪个模型来处理。它不是一个新概念，微服务架构里的 API Gateway 早就在做类似的事情，只不过现在调度的对象从普通服务变成了大模型。

但问题在于，很多团队一听到“路由”两个字，第一反应就是“我也要搞一个”，然后开始设计复杂的规则引擎、训练分类器、搭建 A/B 测试平台，最后发现投入了大量人力，效果却没比直接用一个中等模型好多少。所以这篇文章想聊的核心问题是：什么时候值得做模型路由，什么时候不值得。我会用四个问题来帮你判断，这四个问题不是拍脑袋想的，是我在多个项目里踩过坑之后总结出来的判断框架。

1.2 模型路由的本质是一笔经济账

很多人把模型路由当成一个技术问题，觉得只要技术够强，路由就能做好。但我的经验是，模型路由首先是一笔经济账，其次才是一个技术问题。

你想想，为什么要路由？无非是几个原因：全用贵模型成本扛不住，全用便宜模型质量扛不住，不同请求对延迟的敏感度不一样，不同任务需要的模型能力不一样。这些原因归结到一点，就是资源错配——用高成本资源处理低价值请求，或者用低能力资源处理高要求任务。

所以判断要不要做路由，核心就是算清楚：当前资源错配造成的浪费，是否大于做路由本身的成本。这个成本包括开发成本、维护成本、以及路由判断错误带来的额外损失。我见过太多团队只算了模型调用成本，没算路由系统的维护成本，结果路由上线半年，省下来的 API 费用还不够养一个专职维护路由规则的工程师。

提示：在决定做路由之前，先拉一份过去一个月的请求日志，按请求类型、token 数量、响应时间、用户反馈做个分类统计。如果发现 80% 的请求其实用同一个模型就能满足，那路由的收益空间可能非常有限。

1.3 路由不是万能药，先看清它的边界

模型路由能解决的问题是有限的。它能做的是在多个模型之间做选择，但它不能凭空变出一个又便宜又好的模型，也不能解决模型本身的能力缺陷。如果你的业务场景对准确率要求极高，比如医疗诊断辅助、法律文书生成，那路由能帮你的只是把简单请求分流出去，核心难题还是得靠一个足够强的模型来兜底。

另外，路由的效果高度依赖于你对请求特征的判断准确度。如果你连“这个请求是简单还是复杂”都判断不准，那路由就是在瞎猜。我见过一个团队用关键词匹配来判断请求难度，结果用户换个说法就判断错了，反而把复杂请求路由到了便宜模型，导致回答质量下降，用户投诉增加。所以路由的前提是你对业务请求有足够的理解和分类能力。

2. 第一个问题：你的请求分布是否足够分散

2.1 请求同质化程度决定路由天花板

这是四个问题里最基础的一个。如果你的业务请求高度同质化，比如所有请求都是“帮我写一段 Python 代码”，那路由的空间就非常小，因为所有请求需要的模型能力都差不多，你很难找到明显的分流依据。

反过来，如果你的请求分布很分散，比如有简单的问候寒暄、有中等难度的信息查询、有复杂的长文档分析、还有需要多轮推理的数学题，那路由的空间就很大。你可以把简单请求交给便宜模型，复杂请求交给贵模型，整体成本就能降下来。

怎么判断请求是否分散？我通常看三个维度：请求长度分布、任务类型分布、质量要求分布。请求长度可以用 token 数量来衡量，如果大部分请求都在 100 token 以内，那说明请求偏简单；如果有一批请求超过 2000 token，那这批请求可能需要更强的模型来处理长上下文。任务类型可以通过对请求做聚类分析来识别，比如分成问答、创作、翻译、推理等几类。质量要求则可以通过用户反馈、人工抽检来评估。

2.2 用数据说话：请求分布分析方法

具体怎么分析？我一般会写一个简单的脚本，把过去一段时间的请求日志拉出来，做几个统计。

import pandas as pd import numpy as np # 假设日志里有 request_id, prompt_tokens, task_type, user_feedback 等字段 df = pd.read_csv("request_logs.csv") # 1. 请求长度分布 print(df["prompt_tokens"].describe()) print(df["prompt_tokens"].quantile([0.5, 0.8, 0.9, 0.95, 0.99])) # 2. 任务类型分布 print(df["task_type"].value_counts(normalize=True)) # 3. 按任务类型看长度分布 print(df.groupby("task_type")["prompt_tokens"].describe()) # 4. 用户反馈与任务类型的关系 print(df.groupby("task_type")["user_feedback"].mean())

跑完这个脚本，你大概就能看出请求的分散程度。如果发现某个任务类型占了 70% 以上，而且长度分布很集中，那路由的收益可能不大。如果发现任务类型有五六种，长度分布从几十 token 到几千 token 都有，那路由就值得考虑。

注意：分析请求分布时，不要只看平均值，一定要看分位数。平均值会被极端值拉偏，分位数才能反映真实的分布情况。比如平均 token 数是 500，但 90 分位是 2000，说明有一批长请求需要特别处理。

2.3 分散度不够时，先优化提示词而不是做路由

如果你的请求分布很集中，我的建议是先别急着做路由，而是去优化提示词。很多时候，模型回答质量不稳定不是因为模型能力不够，而是因为提示词写得不够好。一个好的提示词可以让便宜模型的表现接近贵模型，这比做路由的投入产出比高得多。

我试过一个案例，一个团队用贵模型做商品描述生成，成本很高。后来我们花了两天时间优化提示词，加入了更明确的格式要求、示例、以及约束条件，然后换成一个中等价位的模型，生成质量几乎没有下降，成本直接降了 60%。这个过程中我们根本没做路由，只是把提示词打磨好了。

所以第一个问题的判断逻辑是：如果请求分布分散，路由有空间；如果请求分布集中，先优化提示词，再考虑路由。

3. 第二个问题：你的成本压力是否足够大

3.1 算清楚当前模型调用成本占比

做路由的直接收益通常是降低成本，所以第二个问题是：你当前的模型调用成本，在你的总成本里占多大比例？如果占比很低，比如不到 5%，那做路由的收益就很有限，不值得投入太多精力。

怎么算？把过去一个月的模型 API 账单拉出来，除以你的总运营成本（包括服务器、人力、市场等）。如果模型成本占比超过 20%，那路由的收益空间就比较明显；如果在 10% 到 20% 之间，可以评估一下；如果低于 10%，除非你有其他非成本原因（比如延迟优化），否则不建议优先做路由。

我见过一个团队，模型成本只占总成本的 3%，但他们花了一个季度做路由系统，最后省下来的钱还不够付那个季度的开发人力成本。这就是典型的算错了账。

3.2 不同规模下的成本敏感度差异

成本敏感度和团队规模也有关系。小团队资源有限，每一分钱都要花在刀刃上，所以对模型成本更敏感。大团队虽然总成本高，但模型成本占比可能反而更低，因为他们在其他方面的投入更大。

另外，成本敏感度还和业务阶段有关。如果是早期验证阶段，快速迭代比省钱更重要，这时候做路由可能会拖慢迭代速度。如果是成熟稳定阶段，成本优化就成了重要课题，路由的价值就体现出来了。

我通常建议团队在业务稳定、请求量达到一定规模之后再考虑路由。请求量太小的时候，路由带来的成本节省绝对值很小，但维护成本是固定的，不划算。

3.3 成本节省的量化估算方法

如果你决定评估路由的成本收益，可以用一个简单的公式来估算：

预计节省成本 = 总请求量 × 可分流比例 × (贵模型单价 - 便宜模型单价) - 路由系统维护成本

其中可分流比例是指有多少请求可以被安全地路由到便宜模型。这个比例需要通过实验来确定，不能拍脑袋。我一般会先做一个小规模实验，拿 10% 的流量做路由，观察质量变化和成本变化，然后再决定是否扩大。

提示：估算时一定要把路由判断错误的成本算进去。如果路由把复杂请求错误地分给了便宜模型，导致用户投诉或重试，这部分损失可能比省下来的钱还多。

4. 第三个问题：你的质量容忍度有多高

4.1 不同业务场景的质量底线差异

这是最容易被忽视但最关键的问题。模型路由本质上是在质量和成本之间做权衡，所以你必须清楚你的业务能容忍多大的质量波动。

有些场景质量容忍度很高，比如内部工具、草稿生成、创意头脑风暴，这些场景下用户对偶尔的不准确有较高的容忍度，路由的空间就大。有些场景质量容忍度极低，比如对外客服、金融咨询、医疗建议，这些场景下一次错误回答就可能造成严重后果，路由就必须非常保守。

我通常会把业务场景分成三档：高容忍（内部使用、非关键决策）、中容忍（对外但可纠错、有兜底）、低容忍（对外且不可纠错、影响重大）。高容忍场景可以大胆路由，中容忍场景需要谨慎验证，低容忍场景建议不做路由或者只做非常保守的路由。

4.2 质量评估体系的搭建

要判断质量容忍度，你得先有一套质量评估体系。没有评估体系，你就不知道路由之后质量到底降了多少，也就无法判断是否可接受。

质量评估体系可以分三层：自动指标、人工抽检、用户反馈。自动指标包括回答的完整性、相关性、格式正确率等，可以用规则或小模型来打分。人工抽检是定期抽样，由人工评估回答质量。用户反馈包括点赞点踩、投诉率、重试率等。

我一般会先建立自动指标，因为成本低、速度快，可以覆盖全量请求。然后每周做一次人工抽检，抽样比例不用太高，1% 到 5% 就够了。用户反馈作为辅助参考，因为用户反馈往往有偏差，不能完全依赖。

4.3 路由降级策略的设计原则

如果决定做路由，一定要设计好降级策略。所谓降级，就是当路由判断不确定或者便宜模型回答质量不达标时，如何回退到更可靠的方案。

常见的降级策略有三种：置信度阈值降级、重试降级、人工兜底。置信度阈值降级是指当路由判断的置信度低于某个阈值时，直接走贵模型。重试降级是指先用便宜模型回答，如果用户不满意或系统检测到质量不达标，再用贵模型重试一次。人工兜底是指对于特别重要的请求，直接转人工处理。

我个人的经验是，置信度阈值降级最实用，因为它可以在请求发出之前就做出判断，避免浪费一次便宜模型的调用。重试降级虽然简单，但会增加延迟，而且用户可能已经看到了低质量回答，体验不好。

5. 第四个问题：你的技术团队是否具备维护能力

5.1 路由系统的隐性维护成本

这是最后一个问题，也是最现实的问题。模型路由不是做完就完了，它需要持续维护。模型会更新，业务会变化，用户行为会漂移，路由规则也需要跟着调整。如果你的团队没有足够的精力来维护这套系统，那它很快就会变成一个技术债。

我见过太多团队兴冲冲地做了路由，上线初期效果不错，但过了几个月就没人管了。路由规则还是老的，模型已经更新了好几代，结果路由判断越来越不准，最后不得不把路由下线，回到单一模型。

所以判断要不要做路由，一定要问自己：我的团队有没有人能持续关注这套系统？有没有机制来定期评估路由效果？有没有流程来更新路由规则？如果答案是否定的，那建议先别做，或者做一个非常简单的版本。

5.2 从简单规则到智能路由的演进路径

如果你决定做路由，我建议从简单规则开始，不要一上来就搞复杂的机器学习模型。简单规则虽然不够智能，但胜在可解释、易维护、出问题好排查。

一个典型的演进路径是：静态规则路由→动态阈值路由→分类器路由→强化学习路由。静态规则路由就是写死几个条件，比如 token 数超过多少走贵模型。动态阈值路由是根据实时监控数据调整阈值。分类器路由是训练一个模型来判断请求难度。强化学习路由是根据反馈自动优化路由策略。

大多数团队做到动态阈值路由就够了，分类器路由和强化学习路由的投入产出比不一定高。我个人的建议是，先把静态规则路由做好，跑一段时间，积累数据，再考虑要不要升级。

5.3 团队能力自检清单

在决定做路由之前，可以用下面这个清单自检一下：

如果超过两项是“否”，建议先补齐这些基础能力，再考虑做路由。

6. 四个问题的综合判断与实操建议

6.1 判断矩阵：什么情况下值得做路由

把四个问题的答案组合起来，可以得到一个判断矩阵：

这个矩阵不是绝对的，但可以作为一个快速判断的参考。核心逻辑是：路由的收益来自请求分散度和成本压力，路由的风险来自质量容忍度和维护能力。收益大于风险时才值得做。

6.2 小规模验证：先跑通再推广

如果你判断值得做，我的建议是先做小规模验证。不要一上来就全量路由，先拿 5% 到 10% 的流量做实验，观察一周到两周，看看成本降了多少、质量降了多少、有没有意外问题。

小规模验证的关键是做好对照组。把流量随机分成两组，一组走路由，一组不走路由，然后对比两组的成本和质量指标。这样才能准确评估路由的效果，避免被其他因素干扰。

我试过的一个项目，小规模验证发现路由确实能降成本，但质量下降比预期大。后来我们调整了路由规则，把质量要求高的请求排除在路由之外，再跑了一轮验证，效果就好多了。如果直接全量上线，可能就会出问题。

6.3 上线后的持续监控要点

路由上线之后，监控是重中之重。我一般会关注这几个指标：路由分流比例、各模型调用量、质量指标变化、成本变化、延迟变化。这些指标要做成看板，每天看一眼，有异常及时排查。

另外，建议设置自动告警。比如当路由分流比例突然大幅变化，或者质量指标下降超过阈值，就触发告警。这样可以第一时间发现问题，避免影响扩大。

注意：路由上线初期，建议保留快速回滚开关。一旦发现严重问题，能在一分钟内切回单一模型。这个开关一定要在路由系统之外，不能依赖路由系统本身。

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

7.1 路由判断不准怎么办

这是最常见的问题。路由判断不准通常有几个原因：特征提取不够好、阈值设置不合理、模型能力评估不准确。排查时先看特征，再看阈值，最后看模型评估。

特征提取方面，我见过团队只用 token 数来判断请求难度，这显然不够。请求难度还和任务类型、领域、语言等有关。建议至少加入任务类型和领域特征。阈值设置方面，不要拍脑袋定阈值，要用数据来定。比如你可以画一个 token 数和质量得分的散点图，看看在哪个 token 数附近质量开始明显下降，那个点就是阈值。模型评估方面，要定期用测试集评估各个模型的能力，因为模型会更新，能力会变化。

7.2 路由导致延迟增加怎么优化

路由本身会引入额外延迟，因为要多做一次判断。如果路由判断逻辑复杂，延迟可能达到几十毫秒甚至上百毫秒。优化方法有几个：缓存路由判断结果、异步预判断、简化判断逻辑。

缓存路由判断结果是指对于相似的请求，复用之前的判断结果。异步预判断是指在请求到达之前就提前判断好，请求来了直接用结果。简化判断逻辑是指减少不必要的特征和规则，只保留最关键的几个。

我一般会先看路由判断的耗时分布，找出耗时最长的环节，然后针对性优化。大多数情况下，简化判断逻辑效果最明显。

7.3 模型更新后路由失效怎么处理

模型更新是路由系统的一个大坑。模型更新后，能力可能变强也可能变弱，原来的路由规则可能就不适用了。所以每次模型更新后，都要重新评估路由效果。

我的做法是，模型更新后先跑一轮回归测试，看看各个模型在新版本下的表现。如果发现某个模型的能力有明显变化，就调整路由规则。另外，建议在路由系统里记录模型版本，这样出问题时可以快速定位是哪个版本的问题。

7.4 常见问题速查表

8. 我个人的实操体会

做了几个路由项目之后，我最大的体会是：路由的价值不在于技术多先进，而在于判断多准确。一个简单的规则路由，如果判断准确，效果可能比复杂的机器学习路由还好。因为简单规则可解释、易维护、出问题好排查，而复杂模型一旦判断错误，你很难知道为什么错。

另外，路由不是一劳永逸的事情。业务在变，模型在变，用户行为在变，路由规则也要跟着变。所以做路由之前，一定要想清楚有没有持续维护的能力。如果没有，宁可先不做，把精力放在优化提示词和选择更合适的模型上。

最后分享一个小技巧：在路由系统里加一个“影子模式”，就是让路由判断跑起来，但不真正影响请求分发，只是记录如果按路由判断会走哪个模型。这样可以在不影响线上质量的前提下，积累路由判断的数据，验证路由规则的准确性。等影子模式跑一段时间，数据积累够了，再正式启用路由。这个技巧帮我避免了好几次潜在的质量事故。