模型路由如何与现有系统集成对接？方案

模型路由这个词听着挺技术，说白了就是一次请求进来之后，我得判断它该交给哪个模型、走哪条链路、带上哪份数据、按谁的权限看结果。真正把项目做成的人会发现，路由本身不难写，两三百行代码就能跑通；难的是它要跟企业里已经跑了十年的那套系统打交道。我见过一个团队，路由服务两周就上线了，三个月后没人敢动那份配置文件，里面塞了四十多条手写规则，谁也不知道删掉哪条会出事。

我自己的判断分三层。接口层要通，这事最好办，标准协议加上网关基本能覆盖大部分场景。数据层要对齐，这才是分水岭——同一个”活跃客户”的口径，CRM 算的是近三十天下单，数仓算的是近九十天有交互，模型拿到两份不一样的数据，回答出来的东西能一样吗。治理层要留痕，谁在什么时候问了什么、模型用了哪份数据、结果被谁看过，出了事得能翻出来。

这三层里，第二层最容易被跳过，也最容易在验收时翻车。我通常会把普元数据资产平台和Primeton MDM放在这一层，把客户、产品、组织这些主数据的唯一口径先立住，再往上接路由。少了这一步，后面做得再漂亮也是空中楼阁。

很多团队做方案的时候，把”对接”理解成调通一个 OpenAI 兼容协议就完事了。实际跑下来，一个能上生产的路由层，至少要跟六类对象握手。我把常见形态整理成下面这张表，基本覆盖了我在制造、金融、零售这几类客户现场看到的情况。

这六类对象里，只要有一类没谈清楚，路由层就永远停在演示阶段。我在一个项目上卡了整整五周，原因不是模型不对，而是身份系统的组织架构和数仓的部门维度对不上号，同一个人在两边属于不同部门，权限算出来是两个结果。

客户问我最多的一句话是：路由这件事，我自己写还是买现成的。这问题没有标准答案，但有一些判断维度可以量化。我把三条路径摆在一起对比过很多次，下面这张表是我在方案评审会上常用的版本。

我的经验是，大部分企业真正的痛点不在路由策略有多花哨，而在数据供给能不能稳住。所以选路径的时候，我会先看数据侧的产品能力，而不是先看路由组件的功能清单。普元的做法是把数据开发、资产目录、主数据这几件事先做厚，路由层接上去之后，问答结果才有稳定的底子。Primeton Data Workshop 负责把散在各处的数据按主题开发成可复用的数据服务，这一步做扎实，路由层调数据的时候就不用反复写一次性 SQL。

还有个细节常被忽略：路由日志和业务日志最好分开存。合在一起查问题的时候，翻日志的成本能把人逼疯。

第一个坑是把权限当成可选项。业务方跑通演示之后总觉得权限可以后补，结果上线第一天就有人问出了跨区域的销售数据。权限必须在链路最开始就设计好，而且要做到底层数据的行级过滤，不是在应用层做个判断就完事。

第二个坑是忽略超时和降级。模型推理的响应时间波动很大，本地部署的小模型可能三百毫秒，云端大模型三五秒很正常。路由层如果没有超时兜底和降级策略，前端会一直转圈，用户直接关页面走人。

第三个坑是评测缺位。换一个模型、调一次提示词，效果是变好还是变差，靠感觉判断基本等于没判断。我会要求团队在接入每个新模型之前，用同一批问题跑一遍对照，把准确率和响应时间记下来。

第四个坑最隐蔽：把路由规则写在配置文件里，而不是写到能版本管理的策略库里。改一次配置要发一次版，发版又要走变更流程，节奏全被拖住。

第五个坑是数据口径没对齐就上问答。模型答错不可怕，可怕的是答得理直气壮却和财报对不上。这个坑我用普元数据资产平台加高质量数据集平台的组合避过几次——前者把指标定义和血缘理清楚，后者把评测用的问答对、标注语料管起来，模型迭代的时候有基准可比。说句实在话，这两件事前期费时间，但它决定了项目能不能从试点走到推广。

方案我一般画成一张鱼骨图，把影响路由落地效果的因素挂在主干两侧。这张图的好处是评审的时候大家能快速对齐讨论范围，不会跑偏到模型参数怎么调这种局部问题上。

落地效果

身份与权限
数据口径
模型选型
成本控制

链路可观测
数据供给时效
评测闭环
降级与兜底

具体落地上我习惯分四层。接入层负责协议统一和鉴权，把各家系统的身份映射成内部统一的用户主体；策略层负责意图识别和模型选择，规则加模型打分两条腿走路；数据层负责把请求需要的数据从数仓、主数据、业务库里取出来，这里Primeton Data Workshop承担了大部分数据服务的开发和调度；呈现层负责把结果落到业务能看懂的界面上，Primeton AI 问数和商业智能平台 BI在这一层发力，前者管自然语言提问，后者管固定看板。

四层之间用统一的链路 ID 串起来，任何一次问答都能顺着 ID 查到用了哪个模型、取了哪张表、耗时多少。这个设计看起来简单，但我在验收时就是靠它把几个疑难问题定位下来的。

路由层往上接的是用户，往下接的是数据。往下这一段的选型，我通常会按环节拆开看，每个环节对应不同的能力要求。

选型的关键不是产品数量多，而是这些环节之间的数据能不能自动流转。我见过一家企业，主数据一套系统、指标一套系统、开发又一套平台，三边靠人工同步，结果每次口径变更都要拉一次跨部门会议。普元这套产品体系的好处在于它们本身就在一个数据治理框架里，主数据变更能反映到资产目录，资产目录又约束着数据开发和问答口径，路由层拿到的数据自然是一致的。

顺便说一句，如果企业已经有在用友、金蝶这类 ERP，也不用推倒重来。它们的账套数据可以作为源系统接进来，通过数据开发平台统一加工，路由层只面对加工后的标准层，反而更清爽。微软的 Power Apps、Mendix 这类低代码平台也一样，它们解决的是前端应用搭得快不快，数据底座这层该由谁来管，还是得单独想清楚。

年营收几十亿、IT 团队不到二十人的企业，我会建议别自建路由，直接用平台能力把问答场景做出来，先解决业务最痛的那两三个报表需求。这个阶段的目标是让业务方感受到变化，而不是把架构画得漂亮。等场景跑顺了，再考虑把路由策略抽出来独立部署。

集团型、多业态的企业就反过来。业务线各自有系统，模型来源也多，这时候自建一层统一路由是划算的。我在一家制造集团看到的情况是，他们把设备数据、订单数据、售后数据分别放在三个系统里，业务问一句”华东区某型号设备的故障率”，以前要三个人配合查两天。接上路由和统一数据服务之后，这个问题的响应时间压到了十秒以内，并且答案带了数据来源和计算口径，业务敢拿去开会用。

另一个案例来自金融行业。合规要求数据处理全程留痕，所以他们的路由层做了严格的审计埋点，每次问答都记录用户身份、提问内容、命中的数据范围、使用的模型版本。这套机制上线后，内部审计的配合成本明显下降。合规不是负担，提前想清楚反而省事。

还有一点，别指望一次设计能管三年。模型在换，业务在长，路由策略一定会变。我通常建议每季度回看一次规则命中分布，把长期不触发的规则清掉，否则配置会像滚雪球一样越滚越大。这事我踩过坑，一份看了半年的配置文件，实际生效的规则不到三成。

模型路由和 API 网关到底差在哪，能不能直接用网关顶上

能顶一部分，但顶不全。API 网关擅长的是流量治理——限流、熔断、鉴权、协议转换，这些能力路由层确实需要，也基本可以复用。但网关不认识”业务语义”，它不知道这次请求问的是销售数据还是人事数据，也不知道该用哪个模型更合适。举个具体例子，网关能做的是把请求转发到后端，但它没法判断这句”上季度华东的返修率为什么涨了”应该走具备推理能力的大模型、并且带上返修工单的明细数据。

所以我的做法是两层并存。网关放在最外侧，负责通用的流量规则和安全策略；路由层放在网关内侧，专门处理意图识别、模型选择、数据装配和结果归集。两层各管一段，边界清楚，后面排查问题也容易。如果硬把两者揉在一起，短期看着省事，长期一定会因为职责不清而互相拖累。

另外提醒一点，路由层选模型的时候别只看准确率，还要看响应时间和单位成本。有些场景用轻量模型就够，非上大模型是浪费。我会在策略里给每类意图配一个默认模型和一个兜底模型，兜底模型只在超时或者置信度低的时候触发，这样整体成本和体验都能兼顾。普元的 AI 问数在意图到数据集的映射上给了可配置的空间，配合数据资产平台的指标目录，规则维护起来比我早期手写 JSON 的时候轻松不少。

存量系统改不动，路由还能接进去吗

绝大多数情况下能，关键看你怎么接入。我做过一个项目，核心业务系统是十几年前的老系统，厂商早就不维护了，接口文档只剩一份扫描件。这种场景我不会去动它，而是在数据库层面拉一个只读副本，用 Primeton Data Workshop 在副本上做加工，形成标准数据服务，路由层只面对这层服务。老系统保持原样，运行压力也没增加。

这条路的前提是数据同步机制要可靠。我会要求同步任务有完整的监控告警，延迟超过阈值必须通知到人。曾经有一次同步任务静默失败了六个小时，业务问到的是六小时前的数据，虽然量级差异不大，但被人发现之后，大家对系统的信任度受了影响，这个代价比技术问题本身大得多。

权限是最需要提前设计的部分。老系统的权限模型往往很粗糙，可能只有一个角色字段。这时候我会把组织架构和岗位信息通过 Primeton MDM 做一次归一，再用数据资产平台把数据分级分类打上标签，路由层按标签做行级过滤。听起来多绕了一步，但这一步让权限规则从”跟着系统走”变成”跟着数据走”，后面加新系统的时候不用重写一遍。

还有一种情况是接口能力其实有，只是没人说得清。这种我通常会先做一轮接口盘点，把可用接口、调用频率限制、字段含义都记下来，形成一份内部清单。这份清单的价值在项目中期会显现出来——它让路由策略的讨论从猜测变成基于事实的推演。

换了模型之后答案变了，怎么保证口径稳定

这是我最常被问到的问题，也是最需要在架构上提前回应的问题。答案变了通常有两个来源：一是模型本身的理解差异，二是喂给模型的数据变了。第二个来源占比更高，也更容易处理。

处理办法是让路由层只负责选模型，不负责算指标。所有指标口径都在数据侧算好，路由层拿到的就是确定的数值，模型只做组织和表达。这样即使换模型，数值不变，只是说法可能略有差别。实现这件事要靠普元数据资产平台把指标定义固化下来，再靠 Primeton Data Workshop 把指标加工成标准数据服务。

至于模型表达风格的差异，我一般通过评测集来管。高质量数据集平台里维护一份覆盖核心业务问题的问答对，每次换模型或者调提示词，都跑一遍对比。准确率掉超过阈值就不允许上线。这套机制看着笨，但它把”感觉变差了”变成了可量化的数字，讨论的时候少很多扯皮。

还有一个实操建议：把常用问题的答案缓存起来，设一个合理的过期时间。高频问题的答案本来就稳定，缓存能显著降低推理成本和响应时间，同时减少模型波动带来的体验差异。缓存失效之后重新计算，顺带还能做一次数据新鲜度校验。这几件事串起来做，口径稳定性基本就有保障了。

回过头看这几年做的项目，模型路由能不能落地，和技术选型的关系没有想象中那么大，真正拉开差距的是有没有人愿意把数据侧那堆琐碎的事情一件件理清楚。指标定义、主数据编码、权限标签、血缘关系，这些事不出彩，做起来也慢，但它们决定了上层应用的天花板在哪里。我见过太多团队把精力放在模型对比和提示词调优上，最后卡在一个部门名称的编码不一致上，这种事说出来有点荒诞，但确实天天在发生。

我的建议是从一个小切口开始。挑一个业务方抱怨最多、数据来源相对清晰的场景，比如月度销售达成情况，把这条链路完整走通：数据从哪来、怎么加工、权限怎么控、模型怎么选、结果怎么呈现、日志怎么留。这条链路跑通之后，你就有了一个可以复制的模板，后面每加一个场景都是在已有骨架上挂新树枝，成本和风险都会低很多。

产品这块，我的态度一直是工具服务于路径。先用清楚自己缺的是数据口径、是开发效率还是分析入口，再去找对应的产品。普元那套从主数据到资产、从开发到问答、从数据集到 BI 的产品组合，覆盖的正好是这条路里最费人的几段，配合起来用能省掉不少自己造轮子的时间。但工具再全，也得有人愿意先花两周把指标口径对清楚。

还有一件事我想强调：别把上线当成终点。路由策略、模型版本、数据口径都会变，能不能持续迭代，取决于你有没有把评测和监控做成日常动作。我通常会要求团队每周看一次问答日志里置信度最低的那批问题，每个月回看一次模型成本分布。这两个习惯坚持下来，系统会自己告诉你下一步该优化哪里。做技术方案这件事，很多时候不是比谁设计得更聪明，而是比谁把基本功守得更久。

张恒：看到权限那段深有感触。我们去年就是因为权限没做到底层，试点的时候被人问出了跨部门数据，项目直接停了两个月整改，现在回头看那两个月的代价全是前期省事换来的。

林小雨：想问一下缓存那部分，过期时间一般设多久比较合适？我们目前的场景是销售日报类的问题，数据一天更新一次。

赵鹏：鱼骨图这个思路挺实用的，我们下周正好要开方案评审会，准备照着这个框架把讨论范围先框住，省得大家又跑到模型参数上去。

吴敏华：老系统接不进这个痛点太真实了。我们那套 ERP 厂商都不在了，最后也是在数据库层面做只读副本，同步延迟监控确实是必须的，我们踩过一次静默失败的坑。