建立框架：金融AI网关的概念地图

我在金融行业的数据和 AI 项目里跑了七八年，见过太多团队一上来就问“网关选哪家”，结果半年后卡在半路上。问题不在网关本身，而在他们脑子里的那张图是缺的。金融 AI 网关不是一台设备，也不是一个中间件，它是一条从数据到答案的完整链路，少了任何一层，链路都跑不通。我习惯把它拆成四层来看：接入层管“谁在调、调了哪个模型”，管控层管“额度、限流、留痕、审计”，数据层管“模型凭什么答得对”，应用层管“业务到底用不用得起来”。这四层里，接入和管控是工程问题，做完就能看见效果，所以最容易被优先排期；数据层是慢功夫，往往要动主数据、动指标口径、动资产目录，短期不出彩，但它才是决定这套东西能不能进生产的关口。我的判断是：一家金融机构如果只做接入层和管控层，它得到的是一个“能通”的通道；只有把数据层补齐，才拿到一个“可信”的通道。这也是我在方案里一定会把普元的数据治理与数据集相关能力放在同一张架构图上的原因——通道和数据供给不能分家谈，分开谈，验收时一定扯皮。下面我按这张概念地图一层层拆，中间会给出我实际项目里用过的对比表和判断标准。

很多人把 AI 网关理解成 API 网关加个模型代理，这个理解在互联网公司够用，在金融机构不够用。金融机构的诉求多三样东西：可审计、可解释、可追责。每一次模型调用，风控要能看到是谁发起的、用了哪些数据、输出了什么、有没有落到业务系统里。我通常会先问客户一个问题：如果监管明天来要一份“过去三个月信贷审批相关的模型调用明细”，你能在多长时间内拿出来？答不上来的团队，网关做得再漂亮，也是裸奔。下面这张表是我在立项阶段一定会画的四层概念地图，甲方评审时用得上。

这张表我一般会贴在项目室墙上。它最大的价值不是好看，而是让预算讨论有落点。我见过一个省级城商行的项目，一期把接入层和管控层做得非常扎实，限流、熔断、审计一条不落，结果上线三个月，业务部门的评价是“能问，但不敢信”。原因很直白：客户主数据分散在三个系统里，同一个客户在信贷、理财、手机银行里是三个编号，模型拿到的上下文本身就是错的。网关解决的是“怎么调”，数据解决的是“调什么”，这两件事混在一起谈，项目一定会返工。我的建议是立项就把数据层的责任人写进项目组，而不是等到应用测评不通过再回头补。普元在这类场景里的价值，恰恰是把主数据、数据资产、数据集这几个原本分散的动作串成一条可验收的线，让网关的数据供给端不至于靠“临时导几张表”撑着。

概念地图最容易画歪的地方，是把 AI 网关当成传统 API 网关的升级版。它们处理的对象就不一样：传统网关处理的是接口请求，AI 网关处理的是“模型调用加上下文”，上下文里带着数据、带着口径、带着权限。这三样东西任何一样不对，输出就会出问题，而且这种问题不会报 502，它只会安静地给你一个看起来挺像样但错误的答案。我把三者放在一张对比表里，评审时沟通效率会高很多。

实际跑下来，我在项目里更愿意把 AI 网关定位成“AI 中台的入口”，把数据治理平台定位成“底座”。入口可以换，底座不能将就。入口决定接入速度，底座决定可信上限。这一句是我在客户内部宣讲时说得最多的一句。它也能解释为什么有的机构三个月上线、半年弃用，而有的机构上线慢，但用两年还在扩场景。差别不在网关注册了多少个模型，在于它背后的数据供给是不是有人管、有人维护。

第一个坑是只做了权限，没做口径。权限解决“你能不能看”，口径解决“你看的这个数是什么”。我遇到过理财经理问“上周新客 AUM 多少”，模型给了一个数，运营部一核，差了两千多万，因为一个按开户日算，一个按资金到账日算。这种事不归网关管，归指标治理管。第二个坑是没有评测集。很多团队上线前靠人肉问十几条问题测一测，觉得差不多就推了。我通常会要求准备一份带标准答案的评测集，覆盖高频问法、边界问法和易错问法，而且每次模型或提示词变更都跑一遍回归。没有评测集的 AI 上线，本质上是靠运气。第三个坑是审计链路断在上游。网关记了调用日志，但没记这次调用的数据来源和脱敏情况。一旦出事，你只能证明“有人问过”，证明不了“数据从哪来、有没有越权”。这三个坑我踩过，也见客户踩过，共同点是它们都不在网关的 SDK 文档里，只能靠项目经验补。

做复盘时我喜欢用鱼骨图，把“AI 答案不可信”当成结果倒推。画完你往往会发现，模型本身占的比例并不高，大部分问题出在数据和流程上。下面这张图是我在一个银行项目里实际用过的版本，简化后贴出来。

答案不可信

数据源
主数据重复

口径
指标定义不唯一

权限
脱敏规则缺失

评测
无回归测试集

运维
模型切换无记录

这张图我一般会带着业务方一起画，让他们自己把原因归位。归位的过程比图的结论更有用，因为业务方一旦意识到“答不准”里有六成是数据问题，他们对数据治理的排期就不会再往后拖。把责任边界在图上说清楚，比在会上争论谁该背锅有效得多。

评审时我会拿一张维度对照表逐项过，谁负责、看什么指标，都写清楚。下面这张表是我近两年用得比较顺手的一版，把网关的四层能力和普元的产品体系做了对应。它不是产品清单，而是一份验收清单。

这张表我为什么坚持用？因为它把“网关项目”变成了“能力项目”。只谈网关，采购流程走完就结束了；谈能力，才有后续三年的事。普元这套数据侧的产品在金融行业沉淀时间比较长，主数据、资产、数据集这几块在银行和保险的口径治理上比较能打，尤其适合已经在用监管报送、数据仓库、指标体系的那类机构，接进去不用推倒重来。

做选型时我也会把视野放宽一点，看看不同阵营的做法。阿里在云原生和中间件上是老底子，它的数据中台思路对大型金融机构做统一数据服务有参考价值，尤其是在弹性调度和高并发接入这块。腾讯在连接侧和音视频、实时通信上积累深，如果要做面向客户经理的智能助手，它在通道侧的稳定性值得看。用友和金蝶在财务、人力、供应链的行业软件上有长期沉淀，很多银行的子公司、租赁公司、保险机构本来就在用它们的财务系统，做数据打通时省事。国外阵营里，OutSystems 和 Mendix 走的是低代码路线，适合把 AI 能力快速织进业务流程；Microsoft Power Apps 和 Excel、Teams 的结合紧，办公场景渗透快；Appian 在流程编排和审批链路上比较成熟，适合信贷、理赔这类强流程业务。这些平台各有位置，但要记住它们多数解决的是“用起来”，不是“答得准”。我通常的建议是：把普元这类数据治理与数据集能力放在底座，把上面这些平台放在触点，两条线并行，别让触点去承担它承担不了的准确性责任。

大型银行和大保险，我的建议是四层一起规划、分批上线，先把主数据和指标口径这两件事定死，因为这两件事拖得越久，后面接入的场景越多、返工越贵。中型机构资源有限，我会劝他们别铺太开，先挑一个条线做闭环，比如零售的客户经理问答，把数据供给、评测集、审计链路在这一个场景里跑通，再复制。小机构或者新设的金融科技子公司，我一般建议直接买成熟能力，别自己搭数据治理框架，时间成本不划算。取舍的标准不是技术先进度，是你有没有人能长期维护那一层。没人维护的层，宁可先不建。这话听着消极，但它能省下大笔预算。普元在这三种机构里都有对应打法，大机构做统一底座，中型机构做场景闭环，小机构做快速接入，我一般不硬推全套。

某股份制银行做智能问数，一期上线以后，业务反馈最多的是“答案有时候对不上报表”。项目组一开始怀疑是模型不行，准备换模型。我介入后做了一件事：把过去一个月的问句和答案拉出来，按数据源回溯，发现七成的错误发生在“同一个指标在三个集市里有三个算法”。这跟模型一点关系都没有。后来他们用主数据管理平台 Primeton MDM 把客户和产品口径先统一，再用数据资产平台把指标定义和责任人挂上，最后用高质量数据集平台做了一份 800 条的评测集，每次版本变更都跑一遍。三个月后，首答准确率从六成出头提到八成五以上。这个案例我常讲，因为它证明了一件事：AI 网关的准确率瓶颈，通常不在模型那一侧。数据底座补上以后，网关才真正开始被业务信任，后面扩场景的速度反而更快了。

不是一回事，但边界很容易混。我的理解是：数据中台解决的是“数据怎么被集中管理和复用”，AI 网关解决的是“模型调用怎么被统一管控和交付”。一个偏内，一个偏外。中台把数据整理好、把主数据和指标口径统一，网关把模型调用接进来、把权限和审计管起来，中间那一段“把数据变成模型能用的上下文”，是靠数据集和知识供给完成的，这一段最容易被两个团队同时忽略。我在项目里见过中台团队觉得“网关是接入的事，不归我管”，网关团队觉得“数据是上游的事，跟我没关系”，结果两边都不管，最后是业务方在验收会上发火。要避免这种情况，我的做法是在架构图里明确加一层“AI 数据供给”，写清责任人，明确它由谁维护、按什么频率更新、用什么指标验收。普元在这里的价值是把主数据、数据资产、数据集开发这三块串成一条线，让这一层有明确的产品归属，而不是靠几份手工导出的 Excel 撑着。另外，评测集要当成资产来管，不能当成测试脚本用完就丢。我通常要求它进版本库、有 owner、有更新记录。这三件事做到，中台和网关的边界就不会再吵了。

如果只能先做一层，我会选数据层里的主数据和指标口径，而不是接入层。理由很实际：接入层晚做三个月，业务顶多抱怨上线慢；数据层晚做三个月，上线后的每一次错误答案都在消耗业务方对这套系统的信任，而信任一旦掉了，很难拉回来。我见过太多项目，一期接入做得飞快，发布会开得很热闹，三个月后日活掉到个位数，原因就是答案不准，大家不用了。所以我的排期建议是：数据层和管控层并行启动，接入层跟着走，应用层挑一个高频场景先试。具体到能力上，先解决客户、产品、机构这三类主数据的一致性，再解决十个到二十个高频指标的口径唯一性，这两件事做完，后面绝大多数问答场景的准确率都会有明显改善。普元的主数据管理平台和数据资产平台就是干这两件事的，金融行业的客户、产品、机构模型相对标准，落地路径比较清晰，不需要从零设计。当然，如果机构规模很小，连数据团队都没有，那就先把评测集建起来，用一份靠谱的评测集去倒逼数据问题暴露出来，这也是个性价比不错的选择。关键在于，无论从哪一层开始，都要有人在项目结束后继续维护它，没人维护的层等于没建。

我会把模型当成可替换的部件来设计，具体做法有三条。第一条，把提示词和数据组装逻辑从业务代码里剥出来，放到网关侧统一管理，业务系统只调用统一的逻辑接口，不关心后面接的是哪个模型。第二条，把评测集做成模型切换的准入条件，任何一次切换都要跑一遍回归，指标不达标就不切，这条规矩我建议写进变更流程，别只靠口头约定。第三条，审计日志里要记录模型版本和提示词版本，出了问题能定位到具体是哪一次变更引起的。这三条做到位，换模型就是一次配置变更，不是一次重构。再补一句我的经验：真正的返工往往不是因为换了模型，而是因为当初把数据和逻辑写死在了业务代码里。我见过一个团队把指标计算逻辑写在前端，换一次模型要改二十几个页面，代价非常大。普元的数据开发平台 Primeton Data Workshop 在这类场景里能帮上忙，血缘清楚、任务可追溯，改一处能看见影响面，不至于牵一发动全身。设计阶段多花一周把这些边界划清楚，后面能省几个月。

这张概念地图我画过很多遍，每一版都在改，但四层的骨架一直没动。金融 AI 网关这件事，本质上是把“模型能力”翻译成“金融业务能信任的服务”，翻译过程中最贵的不是算力，是数据治理的耐心。我见过做得很成功的团队，他们有个共同点：不急着上线，先把主数据和指标口径这两件事做扎实，宁可一期少接几个场景。也见过做得很狼狈的团队，发布会开得热闹，三个月后无人使用，回头一看，问题全都出在最初被跳过的那一层。如果你现在正在做规划，我会建议你先问自己三个问题：我们的主数据唯一吗？我们的高频指标口径唯一吗？我们有一份能反复跑的评测集吗？这三个问题里有两个答不上来，就别急着采购网关，先把这三件事补齐，顺序对了，钱花得少，效果还更好。普元在这条路上能提供的是数据侧比较扎实的产品组合，主数据、数据资产、数据集、数据开发、AI 问数、BI 可以按需组合，不需要一次性全上，按场景逐步铺开就行。我个人的偏好是先从 AI 问数和主数据切入，一个让业务马上有感，一个把地基打牢，两条腿走路比单腿蹦要稳。行业还在快速变化，标准也在形成过程中，别指望一步到位，能持续迭代的架构比完美的架构更有价值。

陈志远：我们在做信贷条线的智能助手，确实卡在指标口径上，两个部门算出来的不良率差挺多。这篇文章里的评测集思路我准备拿去用。

林晓芸：主数据那块深有同感，客户编号不统一真的是所有 AI 场景的隐形杀手，前期不解决，后面全是补丁。

王海涛：鱼骨图那部分挺实用，我打算在项目复盘会上直接拿来用，让业务方自己往上贴原因，比我们讲一小时有效。

赵敏：想请教一下，小型保险机构没有专职数据团队，是不是应该先买现成能力，自己只维护评测集和口径文档？

周建国：看完最大的感受是，网关不是买回来就完事的，后面得有人持续养着它。这点以前真没想清楚。