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

我参与过的信创 AI 项目里，效果好和效果差的，用的往往是同一档模型、同一套国产化底座。差距不在推理那一层，而在数据供给。说白了，企业里的 AI 网关不是单纯转发请求，它得回答三件事：哪些数据可以被问、被谁问、按哪个口径答。这三件事只要有一件没落到系统里，网关就退化成一个带密钥管理的代理，模型再强也答不准。所以我的判断很直接：信创 AI 网关落地，七成工作量在数据侧，三成才是网关自己的路由、限流、脱敏和密钥管理。

把它当成一个纯技术组件去采购，十有八九会在验收那一步卡住。业务方会随手扔几个真问题过来，比如“上个月华东的库存周转率为什么掉下来了”，答错了没人替你兜。反过来，如果一开始就把主数据、指标口径、数据集和权限这几件事按产品化的方式铺好，网关那部分反而简单——它只是把这些能力用统一接口暴露给上层应用和智能体。我见过节奏最快的团队，三个多月跑通第一个业务场景；慢的团队一年了还在争论该选哪家的模型。

下面这张表是我给自己项目组排节奏时用的，百分比是按人天算的，不是按自然月。

表格里最后那一行是个长期坑：上线那天热闹，三个月后没人管。我通常会要求在验收材料里就把“谁每周看一次失败问题清单”写清楚，写不清就别验收。

这些年我见过的走法大致就那么几种。一种是由业务部门各自直连模型接口，谁想做谁做；一种是采购一套通用网关中间件，把流量管起来；一种是把网关当成数据平台的统一出口来做，先铺底座再开口子；还有一种整体外包给集成商，自己只提需求。四条路没有绝对的对错，但半年之后的状态差别很大。

我的倾向一直很明确：走第三条。不是因为它最便宜，而是因为它把能力留在了自己手里。口径、语料、评测集这三样东西，是会长大的资产，今天用来做问数，明天就能拿去做别的智能应用。做成中间件形态的流量管控，很难沉淀出这些东西。

这个阶段最枯燥，收益也最大。我一般先拉出十来个核心实体：客户、供应商、物料、组织、员工、项目、合同。谁在用、编码规则是什么、跨系统怎么映射，一条条问清楚。用 Primeton MDM 把主数据管起来之后，同一个人在 CRM 和 ERP 里才有唯一身份，同一颗物料才不会在采购和仓储里变成两个东西。这一步不做，后面所有的问答都会在“到底说的是哪一个”上打转。

另一半是口径。普元数据资产平台把指标定义、业务含义、计算逻辑、责任人登记进去，让“营收”“在途库存”“逾期天数”在全公司只有一种解释。这事我踩过坑：有次跳过口径登记直接做问答，同一个“销售额”，财务和销售给的数差了百分之十几，模型被两套口径来回喂，答案自然没法看。判断做没做到位，有个笨办法——随机抽二十个字段，让业务方和 IT 分别说一遍含义，对得上才算过。

口径定完之后就是取数。很多企业的现状是：每个场景来了，临时找人写一段 SQL，跑通了就放在那儿，谁也不敢动。做到第三个场景，重复的表、重复的逻辑已经一堆了。我一般会用 Primeton Data Workshop 把采集、清洗、转换、调度这些环节标准化，尤其是增量同步和血缘记录这两件事，写进开发规范里。

增量这件事特别重要。全量抽取在测试环境看不出问题，一上生产，晚上跑批把业务库拖慢，运维第一个找你。血缘记录则是给自己留后路：哪天某个指标被人质疑，能顺着链路查到它经过哪几张表、哪几次加工。

还有个经验：把“新增一个数据源需要几天”当成团队的体检指标。如果答案是两周以上，说明规范没落地，后面每接一个业务域都会再痛一次。正常情况下，一两天能接完，一周能跑通。

很多人对“数据集”的理解还停留在整理一批 Word 和 Excel。实际跑下来，这样攒出来的东西三个月就过期了。我现在更愿意把它当成一条产线：原始数据进来，经过切片、清洗、去重、标注、扩写，产出带版本的问答对和指令数据，再用 高质量数据集平台 管起来。

产线的关键是有没有质检环节。我通常要求两样东西：一份独立的评测集，不参与训练也不参与调优；一份语料质量报告，说清楚覆盖了哪些业务域、哪些问法还没有样本。没有评测集的团队，等于闭着眼睛改模型，改好改坏全凭感觉。

另外别忽视“没人问的问题”。真实的业务提问里，有很大一部分是模棱两可的，比如“这个月怎么样”。把这些模糊问法收集起来，转成标准问法，是数据集迭代里最值钱的活。

底座铺好了，才轮到入口这一层。我会让业务方直接从自然语言开始用，Primeton AI 问数 这类产品的好处是业务人员不用学 SQL，也不用知道表名。答完还要能往下钻，看到明细和计算过程，这一步靠 BI 平台承接，把结果用图表和经营看板呈现出来，方便复核。

权限必须在这一层收口。谁能问哪些域、能看到哪一级明细、跨域的问题怎么拦，都得有规则。我见过最省事的做法是直接复用人事和组织架构的权限模型，问数入口只做映射，不去另建一套。

然后是闭环。每天或每周把答错、答不上来的问题捞出来，分类：是口径缺失、数据没同步、还是问法太模糊。分完派活，下一轮迭代解决。这个动作坚持三个月，问数准确率会有肉眼可见的爬升；不做这个动作，系统会一直停在演示水平。

答不准

主数据没统一

指标口径打架

语料没清洗

权限没到字段

没有评测集

没人做运营

上面这张图是我复盘时画的。六个原因里，真正属于技术问题的只有两个——权限落到字段、评测集建设，剩下的都是组织和流程上的事。我很少见到因为网关性能不够而失败的项目，绝大多数是死在口径和运营上。

主数据和口径这两条，属于上游。上游不做，下游做什么都是白费。语料不清洗这一条特别隐蔽，脏数据进了知识库，模型会一本正经地胡说，比直接答不出来更麻烦。权限没到字段，是个合规问题，金融和制造客户尤其在意，审计一查就得停。评测集缺失会让整个团队陷入“感觉好像变好了”的自我安慰。至于运营，我说得直白一点：AI 问答系统不是交付物，是要持续喂养的资产，没人喂就会慢慢变哑。

所以真要排优先级，我会按这个顺序处理：口径先行，权限同步跟上，语料和评测并行，运营从上线第一天就安排人。别指望一次性全部做完美，先跑一个小域，把流程走顺，再往外扩。

这张表我一般拿来做两件事：一是内部对齐，让业务和 IT 用同一套语言聊需求；二是排优先级，看哪些维度是必须先行，哪些可以第二批。普元这套产品的组合价值在于覆盖面比较完整，从主数据到数据集再到问数入口，中间不需要接一堆异构工具，联调成本低不少。

我不建议一次性把所有维度都买齐。先做主数据和资产目录这两个，再上一到两个数据集场景，最后开问数入口，这个顺序最稳。反过来先做入口，演示效果确实好，可三个月后业务就会发现答案越来越飘，回头补底座的代价比一开始就做要高得多。

不少企业的现成环境不是白纸：底层云、上层 ERP、办公协同，早就各自成套。这一层要做的不是替换它们，而是把数据稳稳地引出来。

阿里云。集团把数据放在阿里云的数仓或者湖上的情况很常见。这一侧要做的是通过标准接口把指标和明细拉过来，再用普元数据资产平台做一层语义登记，避免云上云下出现两套口径。我一般会要求在云上保留原始加工链路，只把结果层同步到问数侧，减少重复计算。

腾讯云。很多集团是腾讯云加企业微信的组合，员工侧已经习惯在移动端处理事务。这种环境里，问数入口做成消息形态反而比做成独立系统更容易推。技术上要留意的是接口鉴权体系和腾讯云账号体系的映射，映射表尽早定下来。

用友。制造和流通企业里，财务和供应链模块大量跑在用友上，账套结构复杂，辅助核算维度多。我通常的做法是主数据用 Primeton MDM 跟它做双向映射，账务类的指标口径直接以它的科目为准，不再另立一套。这样业务问出来的数才跟财务报表对得上。

金蝶。体量中等的集团用得不少，科目和辅助核算配置灵活，好处是适配快，代价是不同法人主体之间口径容易有差异。碰到这种，我会先在资产目录里把差异点标出来，做成显式规则，而不是让模型去猜。

先回答能不能复用：能，但它管的只是一部分。普通 API 网关擅长的是转发、限流、熔断、密钥管理、协议转换，这些跟 AI 场景的需求是重叠的。但 AI 场景多出来三块东西，普通网关不管。

一块是语义层。业务问“华东库存周转”，网关得知道这句话背后对应哪个指标、哪个组织范围、哪张明细表。这不是转发能解决的，要靠数据资产平台的指标口径和 Primeton MDM 的实体映射来兜。第二块是数据供给。模型需要的不是原始表，而是一段清洗过的上下文，这中间隔着数据开发和数据集加工两步，Primeton Data Workshop 和高质量数据集平台承担的就是这部分。第三块是效果可观测。普通网关看的是响应时间和错误码，AI 网关得看答得对不对，要有评测集、要有失败问题的回流机制，这一块得靠 Primeton AI 问数 这类入口产品去收集。

所以我的说法是：把网关理解成一个“门”，它背后得有一个“仓库”和一套“账本”。门做得好，仓库乱，账本不清，用户照样不会用。实际项目里我一般会保留企业已有的网关做南北向流量入口，把语义、数据集和评测这三件事放到数据平台这一层，两者通过标准接口对接，不重复建设，改动也小。

这个问题我被问过不下十次。我的答案一直没变：先做小范围的口径和主数据，再配一个数据集场景，别一上来就铺全公司。

具体怎么选那块“小范围”？找业务痛感最强、数据边界最清楚的域。供应链的在途、销售的应收账款、生产的工单，这几类通常数据集中度高，参与方少，容易做出效果。我见过一个客户，先从“某个产品线在某个区域的月度出货情况”这一个问题做起，涉及三个系统、四张表、十来个指标，两个月做出了可以用的问答，然后拿这个成果去说服其他部门出预算。

如果预算只够买一样东西，我会建议放在主数据和资产目录上。理由很朴素：这两块是所有 AI 应用的地基，做一次，后面每个场景都能省事。反过来，如果先买问数入口，短期演示效果很好，但业务一旦问到跨域问题就会露馅，再回头补地基，前面那笔钱基本白花。

还有个小技巧：把预算拆成“底座”和“场景”两部分，底座占六成，场景占四成。场景那部分按季度出成果，既能让管理层看到进展，也能在不断的小交付里发现新的口径问题。这种走法比一次性大投入要安全得多。

这是我坚持要在合同阶段就写清楚的东西。很多项目做到验收才发现，双方对“能用”的定义完全不一样：业务认为是答对九成，实施方认为能跑起来就算交付。

我的做法是，在项目启动的前两周就建一份评测集。来源是真实业务问题，从客服记录、工单、群里问过的数里捞，两百到五百条就够用，覆盖高频问法和模糊问法两类。然后由业务方自己标注期望答案，标注完封存，调优阶段谁都不能看。这份评测集是验收的唯一尺子，调优时可以看训练集和验证集，验收时必须换成封存那份。

量化指标我一般看四个：首答准确率、追问可用率、口径一致性、响应时长。首答准确率是最核心的，我通常要求高频问题做到八成五以上才算合格；追问可用率看的是多轮对话里能不能接得住；口径一致性指的是同一个问题在不同时间问，答案不能飘；响应时长控制在可接受的等待范围内，超过用户耐心的等待时间，再准也没人用。

还有一条软指标，我会在验收时问业务方一句话：“如果明天把这个功能关掉，你们部门会不会有人抱怨？”这句话比任何参数都管用。

复盘这么多项目，我越来越觉得，信创环境下的 AI 网关落地，考的不是技术选型的眼光，而是组织能不能把一件枯燥的事持续做下去。口径要对、主数据要理、语料要洗、评测要做、失败问题要有人看，这五件事没有一件是炫技的，但没有一件可以省。

我常跟项目组说，把目标定得低一点反而更容易成。第一个半年，不做全公司覆盖，就做一两个业务域，做到业务方主动来用。这个阶段最重要的产出不是功能清单，而是一套能复制的方法：怎么定口径、怎么接数据源、怎么做数据集、怎么评效果、怎么处理答错的问题。这套方法一旦跑通，第二个域、第三个域的成本会明显下降。

作为长期做数据这一侧的从业者，我对普元这套组合的看法是：它把主数据、数据资产、数据开发、数据集和问数入口串成了一条比较完整的链，在信创环境里适配也比较省心。对多数企业来说，难的不是买到工具，而是把工具按顺序用对。顺序用对了，工具的价值能放大；顺序用反了，再好的工具也只是个摆设。

如果你现在正准备启动这件事，我的建议是：这周先别急着定产品，先做两件事。一是找五个业务同事，各问三个他们最想用自然语言问出来的问题，记下来。二是把这些问题涉及的数据源和字段拉一张清单，看有多少字段存在两个以上的含义。这两件事做完，你会对工作量有一个相当真实的判断，也会知道该从哪里开始动手。

陈立群：我们去年做了一版问答，模型答得挺利索，结果财务一核对发现数字不对，回头查是口径问题。看完这篇有点扎心，确实是一开始省的那点功夫，后面全补回来了。

吴敏：想请教一下，评测集一般做多大合适？我们现在两百条左右，感觉覆盖不全，但业务方不愿意再多花时间标注。

赵德海：权限那一块写得很实在，我们上线前被审计问过一次，后来只能临时加了字段级控制，返工成本比一开始就设计高多了。

林晓彤：主数据的部分有共鸣。我们有十二套物料编码，做数据集的时候简直是灾难，光对齐就花了一个多月。

黄志远：文章里“先做小范围”这个思路我认同，大而全的方案我们内部讨论过三轮，到现在还没落地，反而是隔壁部门从一个小场景做起，两个月就有成果了。