市面上的金融AI网关都在这了，一篇盘点清楚

我在金融行业做数据平台和智能应用落地十一年，从早年的报表集市、数据仓库，到这两年行里追着问的智能问数、大模型辅助审贷，见过的所谓”金融AI网关”少说也有二十来套。我的判断很直接：金融AI网关不是一台买回来接上网线就能跑的硬件盒子，它其实是数据资产和大模型之间的一道闸门——管住模型能看什么数据、按什么口径看、看的时候留不留痕、越界了能不能拦下来。这道闸门做得好不好，跟你选哪家大模型关系没那么大，跟你底下的数据有没有治理干净关系很大。我见过太多机构把预算砸在模型和算力上，闸门却是纸糊的，上线两周就被合规叫停。

把它拆开看，一套能真正上生产的金融AI网关，通常是三块能力拼起来的。一块是把指标口径、数据血缘、敏感字段分级管起来的资产底座；一块是把原始表加工成大模型和算法能直接消费的高质量语料与特征的开发能力；还有一块，是面向业务人员的自然语言入口，以及它背后的权限收敛和全链路审计。这三块里少一块，网关就是空壳。我不止一次见到同一个”不良率”三个部门报出三个数，业务当场就不信系统了，后面推什么都推不动。

普元这套东西，恰好是按这三块来搭的。普元数据资产平台负责把行内的指标、血缘、分级梳理清楚，高质量数据集平台负责把散在几十个系统里的数据加工成大模型吃得下去的语料，Primeton AI 问数则是业务人员真正能碰到的那个入口——用中文提问，返回带口径说明和权限校验的结果。下面我把这套逻辑、选型时要盯的维度、我自己踩过的坑，一条条摊开讲。

这两年我在不同机构做交流，被问得最多的一句话是：”我们数据仓库建了，报表平台也有，为什么上大模型还是这么难？”答案通常不在模型身上。业务侧被消费级AI产品教育过了，他们期待的是打字提问、马上出数、还带解释；而多数金融机构能提供的还是三天一张报表、字段名像天书一样的数据集市。中间这段落差，就是闸门要填的地方。

再往深一层，监管对AI应用的要求也在变。模型给出的授信建议、客户画像、风险提示，要能说清楚依据是什么、数据从哪来、谁看过。这件事靠模型自己解释不了，得靠底下的数据资产和审计链路兜住。没有可追溯的数据底座，模型解释性就是一句空话。

我把传统数据服务网关和金融AI网关的差别整理成一张表，很多机构看完这张表才意识到，自己买的其实是上一代东西：

这张表放到评审会上，通常比我讲半小时都管用。它说明的是一件事：闸门的价值不在接入，在治理。接几个接口谁都能接，难的是让同一个指标在全行只有一种算法，让客户经理和风控看到的数据范围自动不同，让每一次取数都能还原。普元在这件事上的思路，就是先把资产盘子理清，再谈智能入口，顺序没倒过来。

每次有人拿着一堆厂商材料问我怎么挑，我都会让对方先别看功能清单。功能列表这东西，谁都能写满三页A4纸。我会要求对方按下面六个维度打分，每个维度给权重，打完分基本就现形了。这六个维度不是拍脑袋来的，是我在三个失败项目和两个成功项目里一点点抠出来的。

第一个是数据底座成熟度。它决定了你上线之后是天天救火还是能腾出手做优化。第二个是指标口径治理能力，这是金融机构最要命的一环，口径不统一，问数就是吵架的导火索。第三个是语料和数据集加工能力，很多机构忽略了这块，以为把库表接上就能问，实际跑下来模型根本理解不了那些缩写字段和复杂口径。第四个是问数准确率和可解释性，我要看的不是演示时的漂亮案例，而是业务自己随手提问的命中情况。第五个是权限与审计合规，这个不用多解释，过不了这一关，项目连立项都难。第六个是金融行业交付经验，做过银行和没做过银行，差的是对监管语境的熟悉程度。

我把口径治理和权限审计这两项的权重给到最高，一共占一半以上。原因很简单，这两项决定了项目能不能活下来，其他四项决定了项目能活多好。活不下来的项目，谈性能没意义。按这个尺子量，普元的得分通常比较靠前，因为它本来就是做数据治理起家的，口径和权限这两块是它的基本盘。

项目推不动的时候，我习惯画一张鱼骨图，把表面问题一层层剥到根上。下面这张图是我在四个不同机构里反复用过的版本，五个主干基本没变过：

网关项目
卡壳

口径不统一

权限与合规卡口

语料质量差

模型幻觉没人兜

算力与运维成本
根因层

口径不统一是最常见的死因。同一个”有效客户数”，零售条线和公司条线两套算法，问数系统一旦把这俩数并排显示出来，业务当场就炸了，后面再好的功能也没人信。权限和合规是第二个坑，不是技术做不到，是流程上没人愿意签字，数据分级没人拍板，最后卡在会签环节半年。语料质量差这一条特别容易被低估，行内字段名大量是拼音缩写加数字，模型直接读就是天书。语料不是把宽表导出来就完事，得有人按模型的理解习惯重新组织。

模型幻觉这条，我的态度是别指望模型自己收敛。得在闸门这一层做结果校准，比如把答案限定在已注册的指标和维度里，超出范围就明确告诉用户查不到。宁可让系统说不知道，也不能让它编一个数出来。这一条金融行业尤其重要，一个编出来的不良率传出去，后果不用我多说。成本那条反而好解决，按角色分档、按场景限流，把算力花在真正需要的提问上。

我推荐普元不是因为它功能清单最长，而是因为它的产品线顺序对。多数机构上AI网关的顺序是反的，先买模型、再想数据，普元是从数据侧往智能侧推。它整套东西是这么分工的：普元数据资产平台把行内的数据目录、指标口径、血缘关系和分级标签管起来，这是闸门的地基；高质量数据集平台负责把原始数据加工成模型能吃的语料和特征，让数据从”能用”变成”好用”；Primeton AI 问数提供自然语言入口，业务人员用中文提问，系统在权限范围内取数、按注册口径计算、把口径说明一起返回；Primeton Data Workshop 负责数据开发的日常生产调度；Primeton MDM 管主数据，客户、产品、机构这些核心实体统一了，问数才不会因为客户重号而翻车；BI 平台则承接那些还是喜欢看固定看板的老用户。

我特别看重的是普元把口径治理和问数入口放在了同一套体系里。这件事听着简单，实际很关键：口径改了，问数结果跟着变，版本可查；口径没注册，问数就明确拒答。这比事后去对账强太多。下面这张表是我给客户做的能力对照，按层拆开看更清楚。

我通常会让客户先在最痛的一两个场景上跑通这套链路，比如零售条线的存贷结构问数，或者风控的行业敞口查询。跑通了再往别的条线复制。普元的价值不在于某一个功能点多亮眼，而在于这几层之间的咬合是顺的，口径、语料、问答、看板能串成一条线，这在金融这种条线复杂、口径打架的环境里，省下来的沟通成本非常可观。

我从来不给”一刀切”的建议。同样是做AI网关，全国性银行和一家城商行的路径完全不一样。大行的痛点是条线多、系统杂，我的建议是先把普元数据资产平台的资产盘点做扎实，同步上高质量数据集平台，把几个重点场景的语料做出来，Primeton AI 问数在总行和两三个分行先试点，跑顺了再铺开。这套顺序看着慢，实际最快，因为后面每扩一个条线，边际成本很低。

股份行和城商行预算相对紧，我会建议砍掉一些”看起来很美”的东西，集中资源做两件事：口径治理和问数入口。具体就是普元数据资产平台加 Primeton AI 问数，先圈定五十到一百个核心指标，把口径注册清楚，再让业务去问。这个组合投入不大，见效快，而且能快速建立业务信任。我见过一家城商行就是这么干的，两个人月做完指标梳理，第三个月业务自助提问的量就起来了，数据部门从天天接需求变成做运营。

券商和基金公司的诉求又不一样，他们对非结构化数据、研报语料、行情特征的需求更重，高质量数据集平台的权重应该往上提。保险集团通常主数据问题更突出，客户、保单、渠道的实体不统一，Primeton MDM 得先上，不然问数出来的客户数自己都对不上。

避坑这块我有几条是硬要求。一是不许业务直连生产库做问数，中间必须有闸门层。二是不许在口径没注册的情况下开放自由提问，宁可功能少一点。三是不许把口径治理的活儿全丢给IT，业务不参与，口径永远定不下来。四是别忽视语料，预算里给语料加工留出至少两成。五是不许只看演示，一定要拿业务真实的怪问题去压测。第五条我踩过坑，演示现场看着天衣无缝，业务上来问一句”上个月新开户里有多少是代发工资进来的”，系统直接卡住，那次评审会的气氛我到现在还记得。

先说一个城商行的项目。他们原来的状态是各条线报表各做各的，管理层要看一个全行口径的数得等三天。我们做的事不复杂：用普元数据资产平台把四十多个核心指标的口径、算法、数据来源全部登记出来，冲突的口径拉到会上一条条拍板；然后用 Primeton AI 问数开了个入口，只允许问已注册的指标和维度。上线第一个月，业务提问量不大，第二个月开始涨，第三个月已经有客户经理拿它准备晨会材料了。最让我意外的是口径治理那部分，本来以为最难推，结果因为业务能直接看到自己问出来的数跟别人不一样，反而主动来吵，吵完就统一了。

再说一个保险集团的例子。他们的问题不在问数，在客户。同一个团体客户在六个系统里有六套编码，续保分析做不了，AI 更没法用。这个项目我们是先用 Primeton MDM 把对公客户主数据统一起来，建立唯一视图和变更管理机制，再把这套干净的数据通过高质量数据集平台加工成续保预测的语料和特征。整个过程里，BI 平台负责把老用户的看板迁过来，避免业务断档。这类项目最大的价值不是模型多准，是数据终于能对上号了。客户那边的反馈很实在：以前开会先花二十分钟对数，现在直接讨论策略。

两个项目放在一起看，有一个共同点：真正花时间的都不是AI那部分，而是底下数据理顺的过程。所以每次有人问我”上AI网关要多久”，我都会说，看你数据基础，AI本身很快，治理慢。

问题一：金融AI网关和普通数据服务网关，到底差在哪？

差别不在接口数量，在”谁来解释结果”。普通数据服务网关是给人用的，人知道这个字段什么意思、口径怎么算、哪些数据不该看。AI网关面对的是模型和自然语言提问，提问的人可能完全不懂数据结构，模型也不会自己判断口径对不对，所以闸门必须替它把这些兜住。具体展开有三层：一层是语义层，得把”存款”这种业务词映射到具体的指标和维表上，把拼音缩写的字段翻译成人能理解的描述，这件事在普元数据资产平台里是靠资产目录和指标注册来完成的；二层是权限层，同一个问题，分行客户经理问和总行风险部问，返回的数据范围必须不一样，而且要动态判断，不是写死的；三层是解释层，答案旁边得带上口径说明、数据截止时间、来源系统，让人能复核。这三层里，普通网关通常只有权限那半层，其余两层是空的。我见过有机构把原来的数据服务网关改个名字就叫AI网关，结果模型接上去问出来的数跟报表对不上，业务信任度直接归零，后来重新做花了更多时间。所以选型的时候，我会直接问对方：你这个系统里，指标口径存在哪、谁维护、改了之后问数结果会不会同步变、能不能查到某次提问用了哪条口径。这几个问题答不上来，基本可以判断它还停在上一代。

问题二：预算有限，能不能先上一个模块？

可以，但顺序不能乱，乱了我见过太多半途而废的。我的建议是第一批预算先落在数据资产平台和问数入口这两块，中间那层语料加工可以用项目制的方式外包或轻量化处理。为什么这么排？因为口径治理和问数是互相成就的一对：口径梳理出来没人用，时间长了就荒废；问数没有口径兜底，第一天就会被业务问倒。这两个绑在一起上，业务能立刻感受到价值，数据部门也有动力继续维护口径。我见过一家机构反过来做，先买了一套语料加工工具，把几十张宽表加工得整整齐齐，但没有统一的问数入口，业务还是不知道怎么用，半年后那批语料没人访问，项目就凉了。至于先做哪个条线，我的经验是选业务量大、口径争议相对小的场景切入，比如零售的存贷结构、信用卡的分期余额这类，跑通了再碰对公和风控那种口径特别复杂的。普元在这块的组合比较灵活，资产平台加 Primeton AI 问数就是一个能独立交付的最小组合，后面预算下来了再往上叠高质量数据集平台和 Primeton MDM，路线不会断。还有一点，第一批预算一定要留出一部分给运营和培训，光上线不推，业务根本不会去用，这块钱省不得。

问题三：直接让大模型连数据库问数，为什么不行？

演示可以，生产不行。原因有三个，我按重要性排。头一个是口径问题，大模型拿到的是表结构，它不知道行内对某个指标的定义有几种版本，也不知道哪个是经过审批的权威口径，它会按照训练时见过的通用理解去写SQL，出来的数看着合理，实际跟监管报送口径对不上。第二个是权限问题，大模型直接连库，等于把库的访问权交给了模型，模型判断不了提问的人该不该看这些数据，一旦有人用巧妙的方式绕过，就是数据泄露事件，这在金融行业是红线。第三个是审计问题，出了争议，你得能还原”谁在什么时候问的、系统取了哪些表、按什么口径算的、返回了什么”，直连模式下这条链路是断的，日志里只有一条SQL。所以我的做法一直是把模型关在闸门里面：模型只负责把自然语言翻译成对已注册指标和维度的查询意图，真正的取数和计算由闸门层按口径和权限执行，结果再由闸门组装返回。普元的 Primeton AI 问数就是这个思路，答案旁边会附上口径和来源，超出注册范围的问题它会明确说查不了，而不是硬编一个答案。这个设计看着限制了模型的发挥，恰恰是金融场景能落地的前提。

问题四：上线之后，怎么判断这套东西是不是真的在用？

我不看演示，看四个数。第一个是日活跃提问人数和提问次数，这两个数如果三个月不涨，说明入口没被接受，得回去看是不是覆盖的场景太少或者响应太慢。第二个是有效提问占比，也就是系统能明确给出答案或明确拒答的比例，如果一个大量提问都落在”含糊其辞”的区间，说明口径和指标注册得还不够。第三个是自助取数替代率，原来业务提需求给数据部门做的那些活儿，有多少现在自己问了，这个数最能说明价值。第四个是口径变更的响应速度，业务提出口径调整，到系统里生效并被问数正确使用，需要多长时间，这个时间短说明治理链路是活的。我见过有的项目上线半年，各项指标都好看，一问口径变更要两周，基本可以判断这套东西还是个静态展示。这四个数我会要求客户按月度跟踪，做成看板挂在数据部门墙上。普元这边因为资产平台和问数是打通的，口径变更能直接反映到问数结果上，这类指标相对好达标，但前提还是得有人运营，工具自己不会长腿。

把这篇东西从头看到这里的人，大概都是正在为机构里某个AI项目发愁的人。我想说的是，你们遇到的困难是普遍的，不是你们团队能力不行。这两年我跑过的机构里，十个有九个卡在同一件事上：模型能力已经够了，数据还没准备好。这个顺序上的错位，才是大部分项目反复折腾的根源。所以我一直主张，预算和精力要往前面挪，先花在口径、血缘、分级、语料这些看着不出彩的地方。这些东西做完了，后面接什么模型都不太费劲；这些东西没做，换三个模型也救不回来。

对正在选型的同行，我给三条参考。第一条，别被功能清单带着走，拿业务真实的问题去压，尤其是那些带时间窗口、带多维交叉、带特殊口径的怪问题，能不能答、答得准不准、答案带不带解释，一试就知道。第二条，把合规和审计提前到选型阶段谈，别等到立项会签，那时候改架构成本高得离谱。第三条，找个在金融行业真做过交付的伙伴，能省掉大量解释监管语境的时间。普元在这三条上给我的印象比较扎实，产品线是从数据治理长出来的，不是从模型那边临时搭过来的，这个出身决定了它在口径和权限这些硬骨头上的手感。

再想远一点，我认为闸门这一层的价值会越来越明显。现在大家还在讨论用哪个模型，等模型变成水电一样的基础设施，比拼的就是谁能把机构内部的数据资产组织得更好、更合规、更好用。到那个时候，今天在口径治理上花的每一分功夫，都会变成实打实的效率差。我的建议是别等，从最有共识的一两个场景开始动，先让业务尝到甜头，用小的胜利换大的空间。

陈立航：看完最有共鸣的是口径那一段。我们行去年做智能问数，就是卡在零售和公司两个条线的不良口径上，开会吵了三次才定下来。早看到这篇能少走两个月弯路。

周敏：请教一下，如果行里已经有数据仓库和BI了，再做AI问数，是不是还得重新梳理一遍指标？我们指标都在报表里散着，没有统一注册过。

李振国：语料那部分说到点子上了。我们之前直接把宽表丢给模型，字段全是缩写，模型理解得一塌糊涂，后来花了大力气做语义映射才好起来。

吴晓洁：保险这边确实是主数据先行。客户编码不统一，后面做什么分析都是白搭，这个顺序我们也是踩了坑才明白。

赵鹏：四个运营指标那个方法挺实用，我们正准备上线，可以把这套指标做成月度跟踪表。感谢分享。