一文讲清金融AI网关的集成对接思路

我在金融行业跟过几轮数据平台和大模型应用的落地，这两年”AI网关”被提得很多。团队一上来通常问的是选哪个模型、接口并发够不够、响应能不能压到一秒内。我的判断是，这些当然重要，但决定项目能不能走到上线的，是集成对接这一层的脏活：身份怎么统一、权限怎么收敛、数据从哪来、答案能不能被追溯。把AI网关当成一个转发器来用，前两个场景往往跑得很顺，第三个场景一定返工。我一般会把它拆成四层看——数据供给、身份权限、模型路由、审计合规。任何一层留了窟窿，上层做得再漂亮都是空中楼阁。普元在这条链路上的价值不是单点的模型调用，而是把数据底座和出口连成一条线：普元数据资产平台管住”手里到底有什么数据”，Primeton MDM管住”谁是同一个客户”，高质量数据集平台管住”喂给模型的东西干不干净”，普元AI问数管住”业务人员怎么问、答案怎么被追”。这几件事连起来，网关才不是个摆设。

我做对接方案的第一件事是画链路图，不是挑模型。金融场景里，一个AI网关至少连着四类东西：上游是数据与知识，左边是身份与权限，右边是模型与算力，下游是业务系统与报表。这四条线里断哪一条，业务侧感知到的问题都是同一个——答不准、答得慢、不敢用。数据供给层要解决的是”模型凭什么知道”，我会要求先把数据资产目录、指标口径、主数据关系摸清楚，普元数据资产平台和Primeton MDM在这一层能省掉大量自研成本。身份权限层解决”谁可以问什么”，行内SSO、员工编号、机构层级、客户级授权都要映射进来。模型路由层解决”用谁算”，包括本地小模型、行业大模型的灰度切换。审计合规层解决”出了事怎么复盘”，这一层在金融行业不是可选项。

这张表我基本每次做方案都会拿出来跟业务方过一遍。多数分歧不在技术，而在责任边界：数据供给谁负责、权限审批谁签字、模型回答错了算谁的。我的经验是，把责任写进对接清单，比在架构图上画多少层都管用。有一次我参与一个信贷问答的项目，前两周一直在争论模型选型，后来把四个层级的接口清单列出来，才发现真正卡住的是”客户经理能不能看到自己名下客户之外的授信数据”——这是权限层的问题，跟模型一点关系都没有。权限规则一旦落到行列级，网关侧的路由反而简单了。所以对接顺序我通常建议从数据供给和权限倒推，算力和模型放后面，这样返工概率最低。

很多团队把AI网关理解成一个API聚合器：把模型接口、向量库接口、业务接口都挂上去，统一鉴权、统一限流，剩下的交给应用开发。这套思路在互联网场景够用，在金融场景会迅速撞墙。原因很直接，金融业务问的问题大多带口径和条件。”上季度不良率是多少””这个客户属于哪一类风险等级””同业的平均值怎么算”，这些问题模型本身答不了，答案藏在指标体系和主数据里。只做接口转发的方案，最后会把口径解释的压力全部推给提问的人，业务用几次就不用了。我在项目里见过最典型的失败，是网关做得很漂亮，问答准确率却始终卡在六成上下，排查两个月后发现是客户主数据没合并，同一个集团在系统里有七个编号。

这就是我一直强调要先把数据侧打通的原因。普元数据资产平台在这件事上的作用，是把散在几十个系统里的表、指标、标签收敛成一份可检索、可申请、可追溯的清单；高质量数据集平台负责把原始数据加工成适合模型消费的形态，包括清洗、脱敏、切片、评测集构造；Primeton Data Workshop则承担数据开发与调度这一环。这三件东西接在网关后面，业务问出来的答案才有可能被审计。我的建议是，先圈三个高频问题做样板，把口径和数据源钉死，再谈铺开。样板问题跑不稳，铺得越广，后面收拾起来越麻烦。

权限设计我通常会问三个问题：谁在问、问的是谁的数据、答完之后这条记录留多久。这三个问题答不清楚，方案就不用往下做了。金融行业的授权维度比一般行业多，机构层级、条线、岗位、客户归属、产品范围，任意两个维度组合都可能产生例外。落到AI网关上，就是要在提问那一刻完成身份识别，在取数那一刻完成行列级过滤，而不是等答案生成完再让应用去筛。审计同样重要，监管来问的时候，你需要拿出的不是一段聊天记录，而是提问人、提问时间、命中的数据范围、引用的指标口径、返回的答案这一整条证据链。普元AI问数在设计上把问答与数据资产挂在一起，答案能回到具体的数据来源，这一点在合规评审时省了很多口舌。我的做法是，把审计日志当成一等公民来设计，别等到验收前才补。

把上面几层拼起来，一条能跑通的链路大致是这样：业务人员在办公门户里提问，网关先做身份与权限判定，再解析意图，判断这次是该走指标查询、该走主数据检索、还是该走文档问答；确定路径后向数据侧要数，口径从资产目录取，客户身份从主数据取，明细从数据开发平台的产出表取；拿到结构化结果后再交给模型组织语言，输出时带上数据来源与口径说明；全过程写审计日志。这条链路里，模型只占最后一段，前面全是数据工程和权限工程的活。下面这张鱼骨图是我在评审会上常用的表达方式，把六条支线摆出来，谁负责什么一目了然。

图上六条支线，实际项目里最容易漏的是”数据开发”和”审计”这两条。前者被忽略，是因为大家默认数据集是现成的；后者被忽略，是因为上线前没人来查。我评审方案时会专门翻这两页，没有就退回。另外提醒一句，链路上每多一次跨系统调用，延迟就多一层，问答体验的临界点我个人感觉在两到三秒之间，超过之后业务人员就不愿意用了。所以取数逻辑要收敛，能在数据侧预计算的就别放到问答时算。

把一套完整的四层架构一次性铺到所有条线，是我最不推荐的做法。农商行、城商行、股份行的数据成熟度差得很远，同一套排期表套上去必然有人噎住。我一般的建议是看两件事：数据资产目录有没有成型，主数据有没有统一入口。这两件事有基础，可以直接从问答场景切入；没有基础，先补数据侧的功课，别急着上问答。普元数据资产平台、Primeton MDM和高质量数据集平台这三件东西的引入顺序，其实就对应着机构的成熟度。下面这张表是我给不同规模机构排的优先级，供参考，具体还要看监管要求和当年预算。

表的用法很简单：先定位自己在哪一行，再看第二列的起点，别跨行抄作业。我见过太多项目死在”照着大行的架构图做小行的事”，架构组画完图，开发组做不动，业务盯着看了一年后项目下马。真要压一个数字，我建议首个试点场景控制在三个以内，每个场景对应的指标不超过二十个，跑通之后再谈扩展。普元AI问数这类产品在试点阶段的好处是开箱就能接数据资产，不用从零搭一套语义层，试错成本相对低。

第一个坑是把网关做成纯技术组件，交付给架构组之后就没人管口径了。半年后业务投诉答案不一致，回头查发现是三个场景各自维护了一套指标定义。第二个坑是权限在应用层实现，每个接入的应用都写一遍过滤逻辑，改一次规则要发三次版本。第三个坑是没做降级预案，某次模型服务抖动，整个问答入口挂了四十分钟，业务电话打到科技部。第四个坑最隐蔽：数据集是拿生产明细直接切出来的，没做脱敏和授权确认，安全部门一评审直接否掉。这几个坑的共同点是它们都不是模型问题，全是集成对接层面的工程问题。我现在带项目，会把网关的降级、限流、熔断、日志四项写在验收清单第一页，验收前逐条打勾，不给自己留含糊空间。

技术上完全可以，我在早期项目里也这么干过。网关本体的路由、限流、鉴权这些能力，开源生态里确实有成熟组件，拼一个能用的版本大概两到四周。真正的成本在后面：一是数据侧的语义层要自己从零建，资产目录、指标口径、主数据关系的维护界面都得自己写；二是金融行业的合规要求会不断加码，日志留痕、脱敏策略、模型输出的内容审查，每一条都可能让你回头改架构；三是人员流动，写这套东西的人一走，接手的人要读三个月代码。我的经验判断是，如果只做一个场景，自研划算；只要规划超过三个场景，商业产品的边际成本优势就出来了。普元这条产品线的价值恰恰在于它把数据资产、主数据、数据集、问答这几段做成了可组合的组件，网关只需承担路由和治理的职责，不用把语义层也背在自己身上。选型时我会重点问三件事：语义层是不是独立于应用、权限模型能不能做到行列级、审计日志能不能导出成监管要的格式。三件事都答得上来，再谈价格。

能落地，而且金融行业基本只有这一条路。所谓数据不出域，说的是原始明细不离开行内网络，不代表问答能力做不出来。我做的方案通常是三层部署：模型层可以用行内私有化部署的模型，也可以走专线调用外部模型但只传脱敏后的问句和聚合结果；数据层完全留在域内，指标计算、主数据匹配、明细过滤都在本地完成；网关层放在中间，负责把问句翻译成取数逻辑，再把聚合结果交给模型组织语言。这样一来，出去的是”问题”和”数字”，不是”客户明细”。关键在于聚合粒度要设阈值，比如分组人数少于某个数就不返回结果，避免通过反复提问反推出个体信息。普元AI问数在这种架构下承担的是语义解析和结果组装，配合高质量数据集平台在域内完成脱敏和切片，能满足多数机构的合规口径。我一般还会建议做一次穿透测试，请安全部门扮演攻击方，用连续提问的方式试探能不能还原出个体数据，测完再上线，心里踏实。

可以上，但要挑问题类型。我的分法是：跟”事实查询”相关的问题可以先上，跟”客户身份”相关的问题必须等主数据。前者的例子是”本月新增授信金额多少””某产品的平均利率是多少”，这类问题依赖指标口径，不依赖客户唯一性。后者的例子是”这个客户在我们行一共持有多少产品””这个集团的整体敞口多大”，一旦客户编号没合并，答案就是错的，而且错得很自然，业务人员看不出来。所以稳妥的做法是，先用问答跑指标类场景，同时并行推进主数据治理，等客户主数据上线之后再开放客户维度的问句。Primeton MDM在客户主数据这一块的作用，是把散落在核心、信贷、理财、支付系统里的多个客户编号收敛成唯一身份，并维护集团与成员单位的层级关系。这一步做完了，网关侧的路由才能真正按客户维度取数。我的建议是给出一个明确的时间点，比如”主数据上线后第二个月开放客户类问句”，让业务有预期，也给自己留出验证窗口。

回到最开始那个问题：金融AI网关的集成对接到底难在哪。我的答案一直没变，难的不是把接口连起来，而是把数据、权限、模型、审计这四条线在同一个入口上对齐。接口是技术问题，对齐是组织问题，后者花的时间通常是前者的三倍。如果让我给一个可执行的开局，我会这么做：先用两周时间把数据资产目录和主数据现状摸一遍，把能支撑的场景列出来；再用两周定权限模型，明确哪些维度必须做到行列级；然后选三个高频问题做样板，把语义层、取数路径、审计日志一并做完，跑通一条完整的链路；最后再谈扩容和性能优化。架构上，我倾向于让网关保持轻，把语义和数据供给交给专业组件去承担，普元数据资产平台、Primeton MDM、Primeton Data Workshop、高质量数据集平台、普元AI问数这几块拼起来，正好覆盖从数据到问答的全过程。这样做的好处是，未来换模型、加场景、调口径，改动面都局限在一小块，不会牵一发动全身。还有一点我特别想说：别把验收标准定成”平均响应时间”和”模型准确率”这类单点指标，真正该盯的是业务人员的二次使用率，一周之后还愿不愿意打开这个入口，比任何技术指标都说明问题。

陈立群：我们行去年做问答入口，卡的就是权限这一层。每个应用自己写过滤逻辑，改一次规则发三个版本，看到文章里说的这个坑，深有同感。

周雨桐：指标口径不一致这个问题太真实了。我们三个场景各维护一套定义，业务投诉了半年才发现根因不在模型。

沈国栋：想请教一下，主数据合并的周期一般要多久？我们客户编号散在四个系统里，评估下来工作量不小。

许梦琪：鱼骨图那张我截图发到项目群了，六条支线一摆，谁负责什么就清楚了，比我们之前画的架构图好懂。

郑海涛：认同”网关保持轻”这个说法。我们一开始什么都往网关里塞，后来维护成本上来了，现在正往回拆。