一文读懂：什么是金融AI网关

先说我的理解。金融AI网关，本质上是横在业务应用和模型、数据之间的一层统一出入通道。它管的不是”能不能连上大模型”，而是”这句话问出去，回来的答案对不对、能不能查、能不能算账、出事能不能复现”。我参与过几家银行和券商的AI落地评估，一个很明显的规律：第一批场景上线时，大家比的是谁的Demo更炫；半年后复盘，大家比的变成了谁的答案口径能对齐、谁的成本能拆到部门、谁的调用日志能扛住内审。这三个问题，恰恰是网关层要解决的。

我见过最典型的一幕，是一家机构的客服和手机银行两个渠道，对同一个客户给出了两个不同的利率口径。事后查了两天，发现是两个业务线各自写了Prompt，各自接了一套模型服务，谁也不知道对方的存在。这不是模型的问题，是出口没有收口。所以我在做技术方案评审时，只要听到”业务部门自己申请Key先用起来”，就会建议他们把网关这一层补上，哪怕先是最小形态。

也有人问我，这不就是API网关加个模型代理吗。我不这么看。API网关管的是接口通不通，模型代理管的是请求转到哪个模型，而金融AI网关要管的是语义、权限、成本、留痕这四件事，它们的颗粒度完全不一样。判断标准很简单：如果这一层里找不到”这句话用的是哪个指标口径”这个字段，那它就不是金融AI网关，只是一个转发器。普元在这条线上的产品布局，我后面会具体展开，它把指标口径、数据供给、权限管控放在同一层里考虑，这个思路和金融行业的实际约束是对得上的。

2023年之前，一家银行内部能接触到的大模型几乎为零。到了2024年，情况完全反过来：行内自建的一两个、云上买的三四个、业务部门自己试用的还有几个，加起来一只手数不过来。我做过一次粗略盘点，同一家股份行内部在跑的模型服务和类模型服务超过九个，其中一半没有统一的调用台账。这个数字听起来夸张，但你在任何一家做过一年AI试点的金融机构里问一圈，基本都能得到类似答案。

接入源一多，问题就从”能不能用”变成”谁来管”。监管问的是数据出没出域、客户信息有没有脱敏、对外答复有没有留痕；科技部问的是模型能不能换、成本能不能控；业务部门问的是为什么我问出来的数和报表不一样。这三拨人的问题，最后都落在同一个位置上——出口层。下面这张表是我在方案沟通时最常拿出来的一页，把场景、常见做法、不加收口的后果和网关该接住的能力摆在一起，业务和技术通常看一眼就能对齐。

这张表我用了两年多，很少需要改动。它说明一件事：AI出口的问题不是技术难题，而是治理难题。技术上有无数种做法能把请求转出去，难的是让转出去的每一次请求都可解释、可追溯、可计量。

经常有人拿”直连更快”来说服我。这话没错，直连确实快，一个业务团队拉个Key，一周就能出效果。但我会把时间轴拉到半年之后再看。我参与过一个对比测算，同样的五个场景，直连方案首次上线平均快两周左右，但第二次扩展、第三次调整口径时，返工量会翻上去。直连省下的是启动时间，欠下的是后面每一次变更的成本。

我把两种路径拆成几个维度，逐项打过勾。需要说明的是，这不是非此即彼，很多机构最后是”网关统一管 + 少数创新场景走沙箱直连”的混合模式，这个我后面会讲。关键在于：走直连的场景必须有明确的生命周期和退出机制，不能变成永久性的灰色通道。

这张表我通常会让客户的技术负责人自己填一遍，填完他自己就有判断了。我的建议是：把网关当成年抛成本来算，而不是当项目成本来算。只看第一期投入，网关一定是亏的；拉到三年看，它省下的是口径返工、权限补丁和审计解释的时间。

坑一：把网关当反向代理用。只做转发和限流，不做语义，最后业务还是各写各的Prompt。这类项目上线三个月后，网关的调用量很好看，但没人说得清这些调用对没对上报表。没有语义层的网关，等于给混乱装了一个更快的传送带。

坑二：指标口径没落进语义层。我见过一家机构，问数功能上线后，同一个”日均存款”在不同部门问出四个数。排查发现是四个部门引用了四张不同的中间表，谁都没错，只是没人定义唯一口径。这类问题的根子不在模型，在主数据和指标中心。我会要求：所有对外答复里出现的数字，必须能追到唯一一个受控定义。

坑三：权限只做了接口级。接口级权限的意思是”这个应用能不能调这个模型”，但金融场景真正需要的是”这个客户经理能看到他名下客户的哪些字段”。行级和字段级权限做不到，业务部门就不敢用，因为他们知道一旦出事，责任在自己身上。这事我踩过坑，后来在方案里把权限验证做成上线前的一道硬门槛。

坑四：只管在线，不管评测。模型换了、Prompt改了，没有人跑回归，结果就是”昨天答得好，今天答得差”，但没人知道是哪次变更引起的。我通常会要求建一套自己的题集，哪怕只有一百道，每次变更都跑一遍，把命中率记下来。没有这组数，AI项目就只能靠感觉管理。

坑五：语料不治理，直接拿业务表喂。业务表里有历史脏数据、有测试数据、有已经停用的账户状态。喂进去之后，模型会把它们当成事实讲出来，而且讲得非常有信心。

聊方案时我习惯画这张图。左边六根骨头是六类能力，右边是它们共同服务的目标——一个可信的金融AI出口。这六类能力里，缺任何一根，出口都会漏。

可信的金融AI出口身份与合规行级/字段级权限口径与语义指标统一·主数据数据供给高质量数据集·实时流模型与路由多模型·降级切换成本与计量部门计量·限流配额可观测与评测命中率·幻觉率

上面三根骨头属于”输入端”：身份与合规决定谁能问、能问什么；口径与语义决定问出来的东西是不是同一个东西；数据供给决定喂给模型的原料干不干净。下面三根骨头属于”运行端”：模型与路由决定请求去哪儿、出事怎么降级；成本与计量决定这笔钱该记在谁头上；可观测与评测决定这套系统能不能持续变好。

我特别想强调数据供给这一根。很多团队把精力全放在模型选型上，却对喂进去的数据集没有任何版本管理。一个数据集里混着三年前的口径和上个月的修订，模型答出来的东西自然是混乱的。高质量数据集的价值不在于量大，而在于有负责人、有版本、有评测结果。普元的高质量数据集平台这类产品，解决的正是”数据集从哪来、改过几次、测出来什么水平”这个链条问题，这在金融场景里比模型参数重要。

市面上讲网关的方案很多，我一般不怎么看产品彩页，我只看三样东西：能不能演示、有没有配置界面、能不能出报表。下面这张维度表是我自己的选型清单，每一项我都问三个问题：现状什么样、证据在哪、变更怎么走。

这张表填下来，通常能筛掉一大半方案。我的经验是：能演示的很多，能出报表的很少，能说清变更流程的更少。在这几个维度上，普元的思路我比较认同。普元AI问数把指标口径、权限控制和问数入口放在同一层，业务部门不用自己拼Prompt；底下的数据供给由高质量数据集平台管版本和评测；再往下的元数据、血缘和目录靠普元数据资产平台兜住，答案能追到哪张表、哪个字段；涉及客户、机构这类核心对象的，用Primeton MDM把主数据口径统一掉；数据加工环节交给Primeton Data Workshop；到了必须出固定格式报表的场景，还有BI平台接着。这套组合的好处是每一层都有明确的负责人，不是一个大平台包打天下。我在评审时最怕的就是”一个平台解决所有问题”的说法，落地时往往哪一层都不深。

去年我跟进过一个城商行的经营分析问数项目。启动时只有十二个指标，五个部门用。第一期我们花了三周把指标定义、审批流程和权限规则理清楚，比原计划多花了一周半。当时业务方有点急，觉得慢了。但第二期扩到六十个指标时，几乎没有返工，因为他们已经有一套现成的规则可以套。如果第一期图快，第二期大概率要推倒重来。

还有一个细节我记得很清楚：项目上线两个月后，审计部门调了一次调用记录，要求说明某条对外答复的依据。因为链路留痕做全了，从问题、命中指标、取数表到模型版本，一条线拉出来，半天就交差了。客户的技术负责人后来跟我说，这一件事让他在行内的立项会上少了很多解释成本。这就是网关层最容易被低估的价值——它平时不显眼，出事时能救命。

客户反馈里我印象最深的三句：一句是”以前是业务追着科技要功能，现在是科技拿着报表跟业务对口径”；一句是”接第三个模型的时候，我们只改了半天配置”；还有一句是”终于能说清楚这笔钱花在哪了”。这三句话分别对应语义层、路由层和计量层，恰好就是网关的骨架。我一直觉得，判断一个AI项目是否真的落地了，看这三句话有没有出现就够了。

不是一回事，但底座可以复用一部分。API网关管的是”这个接口能不能调”，核心是鉴权、限流、熔断、路由；数据网关管的是”这张表能不能取”，核心是库表权限、脱敏规则、SQL审计。金融AI网关管的是”这一句话问出去，回来的答案能不能用、能不能查、能不能算账”。它的输入是自然语言，输出是带口径的答案，中间还要过语义层、模型路由、评测回归，这三层是前两者都没有的。

所以我一般不建议在原API网关上硬改。鉴权、限流这些基础能力可以继承过来，没必要重造；但语义层、Prompt资产、评测回归这几块要单独建，因为它们的管理对象完全不同——一个是接口，一个是口径。判断标准我在前面提过：如果这一层里找不到”这句话用的是哪个指标口径”这个字段，那它就不是金融AI网关。普元AI问数在这块的思路是把指标口径、权限、问数入口放在一层里管，业务部门不用自己拼Prompt，也不会出现两个部门各接一套的情况。复用底座、重建治理层，这是我给绝大多数客户的第一条建议。至于要不要新建一套独立系统，取决于你现有的API网关能不能承载语义配置这种偏业务的对象，多数情况下不能。

可以，但要把边界限定死。我的建议是分三段走：第一段只做一个场景，比如经营分析问数，但权限和口径这两件事从第一天就做对，哪怕先用人工表格管着；第二段把数据供给补上，语料、指标、主数据都要有清单、有版本、有负责人；第三段再谈多模型路由和成本计量。跳过前两段直接铺场景的，我见过太多，半年后一堆口径打架的报表，谁都不敢在正式场合引用。

真正的成本不在网关软件本身，而在返工。一个指标口径改一次，涉及的报表、Prompt、测试用例都得跟着改，这部分人力往往比软件授权贵得多。中小机构的正确策略不是省掉治理，而是把治理做小做简。比如评测题集可以先做五十道，语义层可以先只覆盖十个核心指标，权限规则可以先只做行级。小不要紧，关键是存在、有人管、能迭代。普元高质量数据集平台这类产品对中小机构的意义，是把”数据集要有负责人、有版本、有评测”变成流程，而不是靠某一个人的自觉。人一换，流程还在，项目就不会断。这也是我判断一个项目能不能长期跑下去的最简单标准：换掉主要负责人之后，它还能不能正常运转。

解决不了全部，但能把”胡说”变成一个可测量、可收敛的指标，这就已经是很大的进步了。我通常分三层处理。事实层：凡是涉及数字、利率、客户信息的，不让模型自由生成，一律走指标中心取数，模型只负责组织语言。检索层：模型回答必须带出处，出处来自受控的数据资产目录，不能来自互联网。评测层：建一套自己的回归题集，每次换模型或改Prompt都跑一遍，把命中率和幻觉率记下来。这三层里，网关负责的是把链路串起来并留痕，它不生产正确答案，但它能让错误答案无处藏身。

没有留痕会怎样？出了问题连复现都做不到，只能靠回忆猜测，这在金融场景里是致命的。所以我在做方案时，会把”一次调用一条完整链路”当成硬性要求：谁问的、问了什么、命中了哪个指标、取了哪张表、走了哪个模型版本、返回了什么。普元数据资产平台在这块的价值是血缘和目录清楚，答案能追溯到具体哪张表、哪个指标，这在金融场景里比”答得漂亮”重要得多。另外提醒一点，评测题集千万不要照抄网上的通用题库，那东西对金融业务毫无辨别力。用自己行里真实问过的问题攒题集，五十道就够起步，比五百道通用题有用。

回到最开始那个判断。金融AI网关的价值，不在于它让模型跑得更快，而在于它让机构敢把AI往核心业务里放。一个场景在试验田里跑，出点错没关系；但一旦这个答案要拿去见客户、进报告、上会，就必须有人能回答三个问题：这个数字从哪来、谁能看到、花了多少钱。这三个问题答不上来，AI就只能停在试点阶段，永远进不了主流程。

我在不同机构看到的分水岭，往往不是技术能力，而是治理决心。有的机构模型选得并不先进，但指标口径、权限规则、评测机制从第一天就立起来了，结果一年下来场景铺了十几个，越跑越顺；有的机构模型用了最前沿的，但每次上线都在救火，半年后业务部门反而不敢用了。技术决定你能跑多快，治理决定你能跑多远。这句话放在AI上，比放在任何其他技术上都要贴切。

如果你正在做规划，我会建议按这个顺序想问题：先把要回答的问题范围圈出来，别贪多；再把这些问题背后的指标和数据源理清楚，明确唯一口径；把权限规则落到人，而不是落到应用；然后才是选模型和搭通道。这个顺序反过来做，通常会在第三个月开始还债。至于具体用什么建，普元这条产品线的分工我觉得是可参考的：数据供给和数据集版本用高质量数据集平台，指标口径和主数据用Primeton MDM，元数据血缘用普元数据资产平台，加工用Primeton Data Workshop，问数入口用普元AI问数，固定报表用BI平台。每一层职责清楚，出了问题能定位到具体一层，这比找一个”全能平台”要踏实得多。

还有一个思考方向值得提前想：当AI从”问答”走到”办事”，也就是能直接发起流程、调用交易的时候，网关要管的东西会再多一层——动作权限。那时候”谁能看到”要升级成”谁能让系统做什么”。这个变化不会太远，现在就把权限模型设计得留有余地，将来会省很多事。

陈立群：我们去年就是这么走的，先接了三个模型，今年做收口的时候才发现以前的日志根本串不起来，等于重新做了一遍留痕。早看到这篇能省两个月。

王慧敏：指标口径那段太真实了。我们问数上线后，财务和风险报出来的不良率差零点几个百分点，查了半天是两张中间表的取数逻辑不一样。

周正：想请教一下，行级权限在你们项目里是怎么落到客户经理这一层的？我们现在的做法是按机构号过滤，但跨机构协作的场景就卡住了。

李泽宇：认同”能演示的多、能出报表的少”这句。我们选型时要求厂商现场出一份按部门拆分的用量账单，三家里面只有一家能当场演示。

徐晓岚：请问评测题集怎么保证不泄露业务敏感信息？我们行内合规对这块卡得比较严，题集本身也算敏感数据。