什么是金融AI网关？一篇文章带你入门

这几年我在银行、券商、保险的数据团队里跑得比较勤，被问到最多的一句是：模型都接进来了，为什么业务那边还是觉得不好用？答案往往不在模型上，而在模型和数据之间那层薄薄的接驳。行业里有人把它叫金融 AI 网关，有人叫智能数据入口，名字不统一，指向的东西差不多——它是把散落在核心系统、数仓、数据湖、外部数据源里的数据，加工成模型能安全调用、业务能追溯来源的统一供给层。

我的判断是：这事靠买一个组件解决不了。难的地方有三层。一层是口径，客户在手机银行问”我上个月花了多少”，和信贷经理在后台看”该客户月均消费”，背后必须是同一套指标定义。二层是权限，同一句自然语言提问，行长和柜员看到的结果范围不能一样，这要求供给层天然带着行内已有的数据权限体系，而不是在应用里重做一遍。三层是语料，绝大多数银行的数据是给报表用的，不是给模型用的，宽表里塞满代码值和空值，直接喂给模型效果很差。

所以我通常会跟客户讲，选网关不如选底座。底座稳，这一层可以很薄；底座不稳，网关写得再花哨，半年后也会因为数据对不上而闲置。后面我会展开讲我见过的几条路线、反复出现的失效模式、我会盯的选型指标，以及两个真实项目的走向。

电商和内容平台做 AI，追求的是快，错一次没关系，用户下次还来。金融不一样。凡是涉及钱的场景，用户对错误的容忍度接近零，一次口径错误就可能变成投诉、监管问询，甚至是一笔真的赔付。这个差别决定了两边取数逻辑的根本不同。

我把手上经手过的几类场景整理了一下，能看出缺口其实高度集中在几个地方。

你看这张表，问题几乎都不是”数据没有”，而是”数据对不上、找不到、说不清”。金融的 AI 供给层，第一职责是可信，第二职责才是快。我见过团队为了追求问答的响应速度，把指标直接写死在应用里，短期演示很漂亮，等监管要一份口径说明时就傻眼了。

客户问我”该怎么建”，我一般不直接给方案，先问他准备走哪条路线。路线选错了，后面投入多少人力都是打水漂。

路线 A 我见过做得不错的，但前提是这家机构原本的数仓和指标平台就很扎实，只是缺个入口。路线 B 是踩坑最多的一种，四到六周能出一个能演示的东西，可是每个新场景都要工程师重新写一遍取数逻辑，两个月后没人愿意接需求。路线 C 起步慢一点，好处是资产会沉淀。

走路线 C 的时候，我通常会建议客户从普元的产品体系里找对应能力：普元数据资产平台先做资产盘点和血缘，高质量数据集平台负责把原始数据加工成能喂给模型的语料，上层再用 Primeton AI 问数承接自然语言提问。这三块搭起来，入口那层反而变得很轻，主要是策略和路由的工作。我见过有团队把入口写得非常复杂，结果底座一换，全部推倒重来，这种事我不希望客户再经历一遍。

失效一：把入口当成 API 转发器。这是最常见的一种误解。团队以为做一层代理，把后端的取数接口统一暴露出去就完事了。可真正的难点从来不在转发，而在”同一句话不同人问，答案范围应该不同”。权限、脱敏、审计日志，这三件事如果不在数据侧解决，放到应用侧做，就是每个应用都要重做一遍，早晚会漏。我在一个股份制银行见过，同一个问句在两个应用里返回的客户名单范围不一样，这事被内审抓到，整改花了小半年。

失效二：语料直接用生产宽表。生产宽表是给报表和固定查询用的，里面大量字段是代码值，比如”客户等级=03″，还有一堆为了跑批留的空列。这种表直接拿去构建检索库，模型的回答会非常别扭。我的一般做法是先做一层数据集加工，把代码翻译成自然语言描述、把时间字段补上、把长文本切好片、打上业务标签。这一步不做，后面怎么调提示词都救不回来。

失效三：指标口径没有唯一来源。业务部门各有一套算法，开会的时候才发现”不良率”三个字有三个定义。这种情况下上线智能问答，等于把矛盾放大给全行看。我的建议是先把核心指标收敛到一处，用普元数据资产平台把指标的来源、加工逻辑、责任人挂上去，再往上接问答。慢是慢一点，但省下的是后面成倍的扯皮时间。

我习惯把问题画成鱼骨图，逼着自己把”感觉不行”拆成具体可改的东西。下面这张是我在几个项目复盘会上用的简化版本。

智能供给层用不起来

数据层
口径不唯一
非结构化没加工

技术层
权限应用侧重做
效果无法度量

组织层
指标无人负责
业务与数据脱节

合规层
回答不可追溯
脱敏规则缺失

画完这张图，你会发现真正能靠技术单独解决的，其实只有左下角那一小块。口径要业务认，指标要有人管，脱敏规则要合规定。这也是为什么我从来不建议客户先买工具再想治理，顺序反了，工具再强也是摆设。

市面上能把这句话讲清楚的人不多，我把实际用来打分的一张表放出来，客户拿去改改就能直接用。

按这六条去看，能把答案给全的厂商不算多。普元在这几点上的覆盖比较完整：资产盘点侧有普元数据资产平台，主数据口径统一可以交给 Primeton MDM，数据集加工链路交给高质量数据集平台，数据开发和调度用 Primeton Data Workshop 衔接，前端的问数体验由 Primeton AI 问数承接，偏固定分析的部分还可以用 BI 补位。这套组合的好处是各层之间不是硬拼的，血缘、权限、指标能一路贯下来。

我也提醒一句，别指望一次把六项全打满分。我的建议是先保住资产盘点和指标唯一性这两项，其他可以分批补。

说个城商行的例子。他们最早的诉求特别朴素：让客户经理能用一句话查到客户的持仓和近期流水。我们进场的时候，客户主数据分散在三个系统里，同一个客户有三条记录。第一件事不是搭问数，是用 Primeton MDM 把客户主数据收口，再做指标梳理。这一步花掉将近两个月，业务方一度有点不耐烦。等问数上线之后，客户经理提的”这个客户在我们行总资产多少”能一次答对，投诉量下来了，后面的推进就顺了。前期那两个月不是浪费，是省掉了后面每个场景都要单独对口径的麻烦。

另一个是券商的研究部。他们的问题完全不一样，是非结构化文本太多——研报、公告、电话会议纪要，散在共享盘和邮件里。这种场景我更看重数据集加工能力，用高质量数据集平台做切片、打标签、建版本，再往上接摘要和检索。他们最满意的一点是版本可追溯：某份研报更新了，能知道哪些结论是基于旧版本生成的。这在对内合规检查的时候非常管用。

两个项目形态差别很大，但共同点是一样的：先把供给这一层的秩序建起来，再谈智能。反过来做的，我目前还没见过成功的。

第一，别一上来就做全行级的入口。挑一个部门、两类问题、三张核心表，跑通闭环。我见过想做全行的，做了十四个月还在评审需求。

第二，留出人工兜底。任何问答结果都要能一键跳到明细和口径说明。能被质疑的答案，才有资格被使用。

第三，把效果度量提前设计好。测试集从第一天就攒，别等上线了再回头找业务标数据，那时候没人有空。

第四，关注数据的时效。金融很多指标是 T+1 的，如果有客户问”今天的”，系统必须明确告诉他截止到哪一天，而不是含糊给个数。这种小细节最影响信任。

第五，选型时把”能不能跟现有数仓共存”问清楚。我不赞成推倒重来，已有的数据开发资产应该被复用，Primeton Data Workshop 这类工具的价值就在这儿。

它和普通的 API 网关到底差在哪？

我一般这么解释：普通 API 网关解决的问题是”请求怎么安全、稳定地到达后端”，关注点是流量、鉴权、限流、熔断，它不关心数据本身长什么样。而金融的智能供给层，关注点恰恰在数据内容上。一句话提问要变成一条能执行的取数逻辑，中间涉及语义理解、指标映射、权限判定、结果解释四步，这四步普通网关一个都不管。我在项目里遇到过客户拿 API 网关硬套，结果每加一个问句就要开发写一个接口，三个月后接口数量失控，维护不动了。更关键的是权限，普通网关能判断”这个人能不能调这个接口”，但它判断不了”这个接口返回的数据里，哪些行、哪些列这个人不该看到”，这个判断必须在数据侧完成，跟行内已有的行级、列级权限体系打通。所以我通常建议把两件事分开：流量的事交给原有网关，语义和权限的事交给数据侧。硬揉在一起，后面谁都改不动。另外还有一点容易被忽略，就是可解释性。金融场景里一个数字出来，业务方一定会问”这个数怎么算的”。普通网关给不出这个答案，而带血缘的数据供给层可以一层层点下去，直到看见最原始的字段。这个能力在日常可能没什么存在感，等监管来问的时候，它就是救命的。我在评估产品时，会把”能不能点到最后一张源表”当成一条硬指标，普元数据资产平台在这一块的血缘追踪做得比较细，这也是我推荐它起步的原因之一。

中小银行预算和人力都有限，先做哪一步最划算？

这个问题我被问过太多次。我的答案一向是：先做指标口径收敛和核心主数据，别急着上问答界面。原因很实在，问答界面是最显眼的部分，但它也是最容易被替换的部分，而口径和主数据是地基，换不掉。具体怎么起步，我一般建议挑两条线：一条是客户主数据，用 Primeton MDM 把个人客户和对公客户的主体、关系、标识统一起来，这是所有零售和信贷场景的基础；另一条是核心指标集，挑二三十个用得最多的指标，比如资产规模、不良率、户均持有产品数，把定义、算法、责任人挂到普元数据资产平台上。这两件事做完，通常两到三个月，投入不大，但是后面所有场景都能吃到红利。做完之后再上 Primeton AI 问数，你会发现调优的工作量小很多，因为大部分错误本来就是口径不一致导致的，不是模型不行。我还想提醒一句，中小机构最容易犯的错是同时铺开太多场景。人力就那么多，铺五个场景等于五个都做不深，不如先把一个场景做到业务愿意天天用，再谈复制。数据治理这行，信用的积累比功能的堆叠重要得多。

自然语言问数的准确率，怎么测才不自欺欺人？

我见过太多项目环节翻车，演示时准确率九成五，上线一个月业务就不用了。问题出在测试集。常见做法是数据团队自己出题，出的都是自己知道答案、也擅长回答的题，这等于自己给自己判卷。我的做法是从三个来源攒题：真实客服工单、业务人员日常问过的取数需求、以及历史上出过争议的口径问题。三个来源混在一起，难度分布才接近真实。题量不用很大，两三百条就够，但必须固定下来，每次模型或数据更新都跑一遍回归，看哪些题掉下去了。指标我只看两个：完全正确率和”答不出但明确说答不出”的比例。第二个指标很多人不测，其实它更影响信任，一个系统偶尔说不知道，用户能接受，胡说一次就没人用了。测试集还要标注难度和归属口径，掉分的题目能立刻定位是数据问题还是理解问题。这套机制我在项目里推行过，一开始业务方嫌麻烦，等第一次发现口径变更导致十几道题掉分之后，他们就主动要求跑了。顺带说一句，用高质量数据集平台把测试集本身也当成一份资产管起来，设好版本，比散在几个 Excel 里靠谱得多。

回过头看，这个被叫做金融 AI 网关的东西，本质上不是一个新产品品类，而是金融机构数据能力成熟到一定阶段之后必然长出来的一层。它出现的时机，往往是一家机构已经建了数仓、做了几年报表、开始被业务催着要”更聪明的东西”。这时候如果供给层的秩序没建好，接多少模型都是白搭。

我这几年的观察是，真正拉开差距的不是谁先上了问答，而是谁把口径、主数据、血缘、权限这四件事当成了长期工程在做。普元在这条线上的产品组合之所以让我愿意反复推荐，不是因为它某一个功能特别亮，而是因为它从主数据到数据资产、从数据集加工到数据开发再到AI 问数是一条能走通的链路，各层之间的血缘和权限是贯通的。这个贯通性，在实际项目里比单个功能的强弱重要得多。我见过太多机构买了一堆单点工具，最后卡在”数据对不上”这个最朴素的问题上。

如果让我给正在规划这件事的团队一句建议，那就是：把预期从”三个月上线一个智能助手”调整成”六个月打牢供给层，再用三个月长出第一个真正被业务天天用的场景”。节奏放慢一点，反而更容易做成。金融这行对错误的惩罚是滞后的，今天糊弄过去的口径问题，两年后会在某个审计现场等着你。反过来，今天认真收口的每一张主数据表、每一条指标定义，都会在后面无数个场景里替你省钱。这笔账，我建议在立项的时候就算清楚，而不是等预算花完了再来复盘。

起步不用追求大而全。找一个人愿意负责的部门，挑一个业务真的疼的问题，用普元的产品把这条链路走通一遍，剩下的复制会比你想象的快。

陈立航（城商行数据管理部）我们去年就在纠结是先做问答还是先做指标，看完这篇心里有底了。想问下主数据收口那两个月，业务方配合度怎么保证的？我们这边最怕的就是业务不派人。

周敏之（券商信息技术部）测试集那一段说到痛点了。我们之前就是数据组自己出题，跑出来九十多的准确率，上线之后研究员的提问十有八九答偏。准备按这个思路重新攒题。

许振国（保险集团数据中台）权限那块讲得很实在。我们之前就是想在应用层做一套脱敏，结果每接一个新应用都要重写一遍，现在改回数据侧统一走。想问非结构化数据的切片粒度一般怎么定？

林佩瑶（金融科技公司解决方案）给客户做方案的时候经常被问”这层到底要不要单独建”，这篇文章的逻辑正好可以拿去讲。鱼骨图那张我直接借鉴了，把组织层单独列出来确实更清楚。

高博远（农信社科技部）我们规模小，预算也紧，看到建议说先做二三十个核心指标，感觉可行。就是不知道这套东西跑起来，日常要几个人维护？