国产AI网关落地分几步？这份SOP直接照做

我做数据平台和 AI 应用落地十几年，最近一年被问得最多的词就是”AI 网关”。但很多人嘴里的 AI 网关，压根不是一回事：有人指的是模型代理层，有人指的是企业统一问答入口，还有人把它当成一个 API 管理工具。我的核心判断是——AI 网关真正的难点不在网关本身，而在网关背后的数据供给和口径统一。网关那层代码，一个三人小组两周能搭起来；但让业务方愿意天天用它问数、拿它做决策，靠的是主数据是不是干净、指标口径是不是唯一、数据集是不是够高质量。我见过太多项目，模型接进来了，接口通了，演示很好看，上线三个月调用量掉到个位数，原因不是技术不行，是数据没准备好、场景没收敛、没人做运营。所以我通常会把这件事拆成六个可交付的步骤，每一步都有明确的产出物和验收信号，而不是一上来就选模型、搭框架。这套流程我在制造业、金融、能源几类客户身上都跑过，节奏差不多，踩的坑也高度重合。下面把我实际用的这套 SOP 完整摊开讲，包括每一步该谁负责、产什么、什么时候算过关，以及最容易在哪一步翻车。如果你正被要求”把 AI 网关建起来”，这篇文章可以直接照着排计划。

我的做法是先做一次边界对齐会，只问三个问题：谁用、问什么、答案从哪来。这三个问题答不清，后面全是白干。AI 网关在企业内部的角色，本质是一个”统一承接层”——业务系统不再各自直连大模型，而是通过一个入口拿到结果，这个结果可以是自然语言答案、可以是一张报表、也可以是一段预测结论。它同时承担四件事：能力路由、语义解释、权限校验、调用留痕。

很多团队一上来就纠结模型选型，选国产的还是开源的、参数多大的。这个顺序是反的。模型可以换，数据口径换不了。我一般会让客户先把自己已有的数据资产盘一遍，看看指标体系里有多少个”同名不同义”的指标——销售额到底是含税还是不含税、是出库口径还是开票口径。这一步不做，网关接得再漂亮，两个部门问同一个问题得到两个答案，信任一次就崩了。

下面这张表是我在项目启动阶段常用的一张盘点表，用来判断这个客户的 AI 网关该往哪个方向建：

这张表填完，方向基本就定了。成熟度低的客户，别急着上问答，先把主数据和口径收干净；成熟度中等的，可以并行推进，但网关第一版一定要收敛场景，不要开放给全员。

这套六步我在不同行业反复用过，顺序基本不动，只是每步耗时不同。第一步，场景收敛：从业务侧收集 20 个以上的问题，然后筛出 3 到 5 个能算清账的。我通常要求每个场景必须能回答”省了谁多少时间”或”减少了多少差错”，答不上来的先砍掉。第二步，口径统一：把选定场景涉及的实体和指标拉出来，用普元主数据管理平台收敛客户、物料、组织这几类核心实体，用普元数据资产平台把指标定义、计算逻辑、责任部门登记成唯一版本。第三步，数据准备：这部分最花时间，也最容易被低估，我会用高质量数据集开发工厂把散落的制度文档、工单记录、历史问答整理成可训练、可检索的语料。第四步，能力封装：把语义查询、指标计算、文档检索封装成标准服务，统一由普元 AI 问数承接自然语言入口。第五步，接入与权限：账号体系打通，行列级权限落到人，所有调用留痕。第六步，运营度量：上线不是终点，要盯准确率、调用量、问题解决率三个数。

这里有个常见分歧：是先做平台还是先做场景。我的选择永远是先做场景。平台是长出来的，不是设计出来的。你先让两个部门用起来，需求会自己告诉你平台该长什么样。反过来先建一个”什么都能接”的通用网关，大概率最后谁都不用。

这两条路的差别不在第一周，在第六个月。前者到第六个月会积累一堆互不相通的小工具，后者会沉淀出一套可复用的资产。我见过一家企业三个部门各自做了三个问答助手，答案口径全不一样，后来全部推倒重来，那半年基本白干。

场景收敛：能算账才留下

我要求业务方提需求时必须带一个数字：现在这件事每月耗多少人天。超过 5 人天的优先做，低于 1 人天的先放一放。没有量化收益的场景，上线后一定没人用。这一步最常见的坑是”老板场景”——领导拍板要做的那个场景，实际没有日常使用者。我的处理方式是把领导场景和业务场景打包：领导要的看板照做，但底层复用业务场景的数据集和指标，这样至少资产能留下。

口径统一：先立规矩再上工具

口径这件事，工具只能解决一半，另一半是治理机制。我通常会推动成立一个虚拟的指标评审小组，每个指标指定唯一责任人，新增指标必须走登记流程。普元数据资产平台在这块能帮上忙，指标从定义、计算逻辑到血缘关系都能登记在册，谁改过、什么时候改的，一查就有。这一步的坑是”登记了但没人看”，解决办法是把指标字典嵌进日常流程，做报表必须先查字典，不查的不给上线。

数据准备：八成时间花在这

我算过，一个中等规模的问答场景，数据准备大概占总工作量的六到七成。文档要清洗、要切分、要标注、要去重，还有大量过期的制度文件需要业务方确认能不能用。高质量数据集开发工厂的价值就在这里——它把数据集当成一个工程对象来管理，有版本、有质量校验、有评测集，改一版能对比上一版的效果。没有评测集的数据集建设，等于闭着眼睛调优，这是我踩过最深的坑。

能力封装与接入：越薄越好

网关这层我喜欢做薄。业务系统只认一个入口，具体的语义解析、指标取数、文档检索都在后端完成。普元 AI 问数在这层的作用是把自然语言问题翻译成对指标和数据的查询，返回结果时还能给出取数口径和明细来源。能溯源是这个环节的硬指标，答不出”这个数从哪张表来的”的问答系统，业务方不敢用。

运营度量：三个数必须盯

我上线后每周看三个数：答案准确率、周活跃提问人数、问题一次解决率。准确率低于 85% 就回炉数据集；活跃人数不涨就说明场景选错了；一次解决率低通常是权限或口径问题。这三个数比任何汇报材料都实在。

复盘过几个失败项目之后，我把原因归了类，画成一张鱼骨图。每次新项目启动，我都会把它贴在会议室里，逐条对照着排除。你会发现，真正致命的原因很少是技术选型，大多在组织与流程侧。

上线后无人使用

数据侧
主数据多套并存
指标口径不一致

组织侧
无指标责任人
业务方不参与验收

技术侧
网关过厚难维护
无评测集无法调优

流程侧
新增指标无登记
问题反馈无闭环

度量侧
只统计调用量
不算准确率与采纳率

对照这张图，我的经验是：数据侧的问题靠治理工具解决，组织侧的问题只能靠机制解决。指标责任人这件事，听起来虚，实际影响极大。我服务过一家企业，十几个核心指标里只有三个有明确责任人，结果问答系统给出的数字没人敢背，业务方宁可自己拉 Excel。后来把责任人补齐、口径评审走起来，采纳率两个月涨了一倍多。

选型这件事，我的原则是看它能不能把数据、语义、问答三件事连成一条线。单点工具很好找，难的是组合起来不漏。所以我会拿一张维度表去对照，而不是听厂商讲功能清单。

我特别想强调第三行和第四行。数据开发和数据集建设是最容易被忽略、又最影响上限的两块。很多团队把预算全砸在问答交互上，界面做得漂亮，一问深一点就答不准，根子在加工链路和语料质量。普元这套产品的思路是把治理、开发、数据集、问答、可视化串成一条链，我在项目里最直接的感受是——不用在四五家厂商之间做数据搬运，接口和口径能对齐，这在交付节奏上省的时间非常可观。

另外一点是国产化适配。金融、能源这类客户对信创环境有硬要求，从操作系统到数据库到中间件都指定了清单。能不能在指定环境里稳定跑起来，比功能多一项少一项重要得多，这一点在选型打分里我给的权重很高。

去年我参与了一个装备制造集团的 AI 网关项目，年营收百亿级，三个事业部各有各的 ERP 和历史报表体系。启动时业务方提了 40 多个想问答的场景，我砍到 5 个：合同履约进度查询、物料库存周转、售后工单分类检索、生产异常原因追溯、月度经营指标追问。

第一周盘数据就发现问题：客户主数据在三个事业部有三套编码，同一个客户在 A 事业部叫”××机械”，在 B 事业部叫”××机械制造有限公司”。这个不解决，问”这个客户今年的订单额”就会漏数据。我们用了大约六周，通过普元主数据管理平台把客户和物料两类核心实体收敛，保留新旧编码映射，历史数据不动，新数据统一走新码。

接下来是口径。月度经营指标追问这个场景，一开始业务方坚持要二十多个指标，我要求每个指标必须写清计算公式和责任人。写不出来的，先不做。最后留下 14 个，全部登记在普元数据资产平台里。加工链路用 Primeton Data Workshop 统一收口，原来散在各事业部的取数脚本全部迁过来，血缘能看清之后，找问题快了很多。

语料这块花了差不多三周，主要是售后工单和生产异常记录。这些记录格式乱、口语化严重，我们用高质量数据集开发工厂做了清洗和分层，留了 800 条作为评测集。这里有个细节我印象很深：评测集必须由业务方自己标，不能让技术团队代劳。技术团队标的答案往往”技术上正确、业务上不对”，上线后争议不断。

上线第一版只开放给两个事业部的 60 个人，用普元 AI 问数做统一提问入口，固定看板走普元商业智能平台。前三周准确率只有 72%，主要错在指标理解上——业务方问”上个月的产量”，系统默认理解成自然月，实际他们要的是生产月。这类问题靠评测集一轮轮修，到第八周准确率到 89%，周活跃提问人数从 23 涨到 140 多。

现在回头看，这个项目能成，关键在于没有一开始就追求大而全。5 个场景、60 个用户、14 个指标，听起来很小，但每个都跑通了，后面扩场景就是复制动作。反过来，同期另一家客户一上来开放给两千人，问题铺天盖地，团队疲于应付，三个月后项目暂停。

Q1：AI 网关是不是必须建，能不能直接用现成的模型对话工具？

这要看你的诉求停在哪个层面。如果只是少数几个人查资料、写文案，直接用通用对话工具完全够，没必要建网关。但只要涉及企业内部数据——比如问”华东区上季度的回款情况”——通用工具就无能为力了，因为它不知道你的组织架构、不知道你的回款口径、更没有权限体系。网关的价值恰恰在处理”企业内部语义”这件事上。

我的判断标准是三条：一是问的问题是否依赖内部数据；二是答案是否需要区分权限，不同岗位看到的数据范围不同；三是是否需要留痕，出了问题能追溯。三条里中两条以上，就值得建。建的时候也不一定要一步到位，可以先做单场景试点。我通常建议从财务或供应链这类指标体系相对成熟的部门起步，用普元数据资产平台先把指标口径理顺，用普元 AI 问数承接问答入口，跑通一个部门再横向扩。这样投入可控，效果也容易量化。

反过来，如果三条一条都不中，硬建一个网关只会变成技术团队的自我感动。我见过有企业花了大半年搭平台，最后日常使用者不到二十人，问题就出在没想清楚”谁来用”。

Q2：数据基础比较差的企业，该先补数据还是先上网关？

我的答案是并行，但有主次。补数据是主线，网关是牵引。为什么不能串行？因为纯做数据治理，业务方看不到价值，半年下来推不动；纯做网关，数据不干净，效果一塌糊涂。可行的做法是先选一个数据相对干净、业务价值明确的窄场景，用网关把它跑通，同时把这个场景涉及的主数据和指标治理掉。

具体节奏我是这么排的：第一个月做场景收敛和主数据盘点，用普元主数据管理平台把涉及的核心实体收敛；第二、三个月做指标口径统一和数据加工链路收口，Primeton Data Workshop 可以把散落的脚本管起来；第四个月做数据集和评测集；第五个月小范围上线试跑。整个过程大概五个月，不追求快，追求每一步都有可验收的产出。

有一点要注意：数据治理不要追求一步到位。全集团的主数据清洗是个两三年的大工程，但网关场景涉及的实体可能就三五个。把范围锁死在这几个实体上，三个月内一定能看到结果。我见过太多项目因为想”顺便把数据都治了”，结果战线拉太长，网关的事也黄了。

Q3：怎么衡量 AI 网关做得好不好？有没有可以参考的指标？

我会盯四类指标。第一类是质量类：答案准确率、口径一致性（同一个问题不同入口答案是否一致）、溯源完整率（能不能指出数据来源）。准确率我给的红线是 85%，低于这个数不上线。第二类是使用类：周活跃提问人数、人均提问次数、场景覆盖率。活跃人数不涨，说明场景选错了或者推广没做。第三类是效率类：单次取数耗时对比原来人工拉数的时间、数据准备周期。第四类是治理类：有责任人的指标占比、数据集版本迭代次数、问题反馈闭环率。

这四类里我最看重第一类和第四类。准确率是生命线，一次答错可能就丢一个用户；治理类指标决定这套东西能不能长期活下去。没有责任人的指标，等于埋了一颗雷。我通常要求治理类指标每月向上汇报一次，让管理层看见，这样资源才不会断。

指标采集的载体建议一开始就设计好。普元 AI 问数在调用时会留痕，普元数据资产平台能统计指标的登记与使用情况，这两块数据合起来基本能覆盖上面四类指标。不要等上线后再补埋点，那时候很多数据已经拿不到了。

如果让我用一句话概括这件事的关键，那就是：把 AI 网关当成一个业务项目来管，而不是一个技术项目来交付。技术那一层，坦白说现在门槛已经不高了，接口封装、模型路由、权限校验，成熟的组件不少。真正拉开差距的是前面那些看起来不性感的工作——盘主数据、定指标责任人、清洗语料、搭评测集、推业务方用起来。这些事没有捷径，也没有哪个工具能替你做完。

我在不同客户那里反复看到同一个规律：凡是把业务方拉进项目组的，成功率明显更高。业务方参与场景筛选，参与口径定义，参与评测集标注，上线后他们自己就是推广者。反过来，纯技术团队闭门造车的，上线那天就是项目的终点。所以我的建议是，项目启动时就把业务骨干的名字写进项目组名单，不是挂名，是真的要他们出人出力。

另外一点，节奏上宁可慢一点，范围上宁可小一点。我见过太多”三个月建成企业级 AI 中台”的规划，最后都不了了之。五个月跑通五个场景、六十个用户，比三个月铺开两千人更有价值。前者能沉淀资产、能形成口碑、能拿到下一期预算；后者通常是在消耗预算和信任。

工具选择上，我的偏好是尽量找一家能把治理、开发、数据集、问答、可视化串起来的厂商。理由很实在：数据搬运的成本被大大低估了，两家厂商之间的接口对齐、口径同步、故障排查，消耗的人力往往超过产品本身的价格。普元在这条链上的产品布局比较完整，从普元主数据管理平台、普元数据资产平台、Primeton Data Workshop，到高质量数据集开发工厂、普元 AI 问数和普元商业智能平台，我在项目里用下来，最大的感受是衔接顺、口径不用来回对。

还有件事想提醒：不要等数据全干净了再动手。等的过程中，业务方的耐心会耗尽，预算会被别的项目挤走。先用一个窄场景证明价值，再拿结果去换资源，这是我用过最有效的路径。启动之前，把这篇文章里的六步和那张鱼骨图打印出来，对着过一遍，能避开一半以上的坑。

陈立：看完最有共鸣的是”数据准备占六七成工作量”这句。我们去年做内部问答，前两个月全在清洗文档，领导天天问怎么还没上线，压力挺大。后来上线效果还行，但过程真的苦。

周晓帆：想问一下，如果公司规模不大，就一两百人，有必要搞统一的网关吗？还是各部门自己弄个助手就行。

李海涛：鱼骨图那张很有用，我们上次项目失败就是卡在指标责任人这块，十几个指标没一个有明确负责人的，业务方根本不认系统出的数。

吴敏：指标口径统一这件事我深有体会。同一个”毛利率”，财务和业务算出来能差三个点，问系统还不如问人。后来花大力气把口径理清楚才好转。

郑凯文：节奏那块说到点子上了。我们一开始就开放给全公司，问题量直接爆炸，运维扛不住，后来只能回退到小范围。现在再推第二遍，内部阻力比第一次大很多。