金融AI网关如何与现有系统集成对接？方案

第一个场景是华东某城商行的信贷条线。他们最初的诉求很朴素：客户经理不想在四五个系统之间来回切页面查授信和用信情况。我们先用普元 AI 问数接上数仓里的授信、用信、逾期三张主题表，两周内让三十多个客户经理用上自然语言查询；一个月后开始补口径，把”用信率””净敞口”这类容易吵架的指标在普元数据资产平台里做了唯一定义；第三个月才把信贷系统和影像平台的合同数据通过 Primeton Data Workshop 接进来，实现”问一句额度，顺带把相关合同列出来”。项目组复盘时，科技部的一位负责人跟我说了句让我印象很深的话：”我们一开始以为是在做 AI 项目，做到一半发现是在补数据治理的课，只不过这次业务方愿意配合了。”第二个场景是一家寿险公司的客服与运营。他们的痛点不在取数，而在客服人员每天要翻几十份条款和制度文件。做法是把制度文档和结构化指标一起挂到同一层服务上，客服问”这个险种的犹豫期怎么算”，回答里能直接引用条款原文，问”上月这类保单的退保率”，又能直接给数并标出取数范围。运营负责人反馈说，最有价值的不是回答快了多少，而是每个回答都能点开看来源，投诉处理时能拿出依据。这两个案例有个共同点：先跑通一个小切口，再顺着数据血缘往回补，而不是一开始就做大而全的接入清单。

我的答案取决于你的时间窗和时效要求，但方向上我强烈建议往中转这一侧靠，只不过中转不是简单地把数据抽到一个大仓库里，而是要有治理层。直连最大的问题不是技术风险，而是它把”谁能看什么数据”这件事留在了每个接口的实现细节里，接口一多，权限就失控。我在一个项目里见过网关直连了十七个系统的只读库，其中三个库的账号权限是开发期为了方便直接给的高权限账号，上线半年后审计发现，这几个账号一直被生产环境沿用。后来改造时，我们把所有访问统一收口，源系统只对数据开发平台开放，业务的问答请求全部走服务层，权限按登录人身份在服务层动态过滤，才把这个问题彻底解决。具体的分层是这样：底层由 Primeton Data Workshop 负责把源系统数据按主题接入，做清洗、标准化和调度；中层用普元数据资产平台登记资产、维护指标口径和血缘，让每个对外提供的数据都有一个可追溯的出处；上层由 Primeton AI 问数承接自然语言请求，把用户的问法翻译成对指标和维度的查询，同时把权限和口径说明一起带出来。这样做的额外好处是，模型或问答逻辑变更时，只要指标定义不变，业务看到的结果就不会漂移。当然，如果遇到分钟级的实时场景，比如交易反欺诈的辅助判断，我的处理办法是在中转架构上开一条实时通道，只让少数经过评审的实时指标走这条路，其余仍走批量层，避免把整个链路都做成实时而推高成本。要不要直连，本质是问一句：这个场景出错一次的代价有多大。代价高，就别图快。

这件事的关键不在模型，而在”可解释”。我给客户做方案时有一条硬性要求：任何一句数字型的回答，都必须能展开看到三样东西——指标定义、取数范围、数据更新时间。缺一样，这个回答在业务眼里就是不可信的。做到这一点，靠的是把指标口径沉淀在普元数据资产平台里，并且让问数服务在生成答案时把口径信息一起带出来。我没有见过哪个金融客户是第一天就完全信任 AI 数字的，信任都是靠一次次”我抽查了一下，跟报表对得上”累积起来的。所以我在方案里通常会安排一个抽查机制：上线初期，由数据团队每周随机抽二十个真实问法，人工核对结果，对有偏差的问法做归因，归因结果分三类——口径理解错、数据质量问题、问法本身有歧义。第一类补指标定义，第二类回到数据开发平台加质量规则，第三类则沉淀成问法示例，进入高质量数据集平台的评测集，作为后续迭代的回归基线。这个闭环跑上两三个月，准确率提升往往比换模型明显得多。另外还有个小细节值得做：把高频问法做成引导，别让业务人员对着空白输入框发愣。我在一个项目里统计过，前二十个高频问法覆盖了七成以上的访问量，把这二十个问法做成卡片式入口，用户满意度立刻不一样。信任这件事没法一次性解决，它是一套机制持续运转的结果。

这个问题在金融行业太常见了，我几乎每个项目都会遇到。折中办法是有的，但要有取舍。我的原则是：不动老系统的内核，在它外面加一层适配。具体做法分三种情况处理。第一种，系统还有数据库直连的可能，那就用数据开发平台做准实时或批量的数据同步，把原始表落到中间的贴源层，加工逻辑全部放在外层，老系统一行代码都不用改。第二种，系统只提供文件导出或者消息通道，那就按文件周期或消息主题接入，接受一定的时效延迟，把这部分数据标注成 T+1，问答时明确提示用户数据的截止时间——我宁可告诉业务这个数截止到昨天，也不要含糊其辞。第三种，系统连导出都困难，只能人工操作，那就先不接，把这类需求暂时排除在首期范围之外，等业务价值验证之后再推动系统侧的改造，用实际使用数据去说服科技部门立项。这三种情况的共同点是：接入工作尽量集中在 Primeston Data Workshop 一侧完成，源系统保持不动。同时要注意一个容易忽略的点——老系统的字段含义往往没有文档，我在项目里会要求做一份字段映射表，由熟悉该系统的老员工逐字段确认含义，这份表后来通常会变成数据资产平台里最有价值的资产之一。改造预算有限的时候，把钱花在”让数据可被理解”上，比花在”接更多系统”上划算得多，这是我做了几个项目之后最实在的一条体会。

回到最初那个问题，一个金融行业的 AI 网关要跟现有系统接上，真正需要的能力其实分布在三处。一处是对源系统的低侵入接入能力，让老系统不必为了 AI 而大改；一处是对数据资产和指标口径的管理能力，让同一个问题只有一个答案；一处是面向业务人员的服务出口能力，让不会写 SQL 的人也能拿到数据。这三处任何一处缺位，项目都会在某个阶段停住。我在实际项目里观察到的规律是，第一年大家比拼的是模型效果和问答体验，第二年开始比拼的就是数据资产的厚度和口径的清晰度，因为体验层面的差距很快会被拉平，而数据底子的差距会越拉越大。所以如果让我给正在规划这件事的团队一条建议，那就是把对接方案写成两半，一半写网关和服务，一半写数据治理，两半的预算不要悬殊太大。前半部分可以比较快出成果，用来争取业务方的持续支持；后半部分见效慢，但它决定了这套系统三年后还有没有人在用。选型上，我的偏好是找一家在数据治理和数据分析上都有产品积累的厂商，把接入、治理、问数、报表这几层放在同一套体系里，减少后期集成和口径对齐的沟通成本，普元在这条线上的产品覆盖相对完整，从 Primeton Data Workshop 的数据接入，到 Primeton MDM 的主数据统一，再到普元数据资产平台的口径管理，最后由 Primeton AI 问数和商业智能平台 BI 承接业务出口，链条是通的，这在实施阶段能省掉很多解释工作。还有一点我想提醒：别把对接当成一次性工程。源系统会升级，机构会调整，监管口径会变，这套链路必须留出持续维护的空间，所以文档、血缘、评测集这些东西，从第一天就要当成交付物来管，而不是等出问题了再补。

陈立航：我们行去年也在做类似的事，最深的感受就是文章里说的口径问题。业务部门问”贷款余额”，三个部门给三个数，光是对齐这个指标就开了四次会。后来把口径登记到数据资产平台上，谁改谁负责，争议少了一大半。

苏晓雯：权限那一块写得很实在。我们一开始只在应用层做过滤，结果开放问答之后发现分行的人能查到别的分行的数，赶紧停下来返工。权限真的不能后补，得在设计阶段就跟数据服务层绑在一起。

周牧云：请教一下，文章里提到老系统没有文档、字段含义靠老员工确认，我们这边就卡在这，老员工不太愿意配合做映射表，有没有什么推进的经验？

林嘉禾：我们是保险这边的，跟第二个场景几乎一模一样。制度文档加结构化指标放在同一层服务上，客服问条款能直接引用原文，这个体验提升比想象中大，投诉处理的时候终于拿得出依据了。

赵砚秋：比较认同”先定出口再补入口”这个顺序。我们反过来做的，先把十几个系统都接进来了，结果业务那边没人用，因为问的问题系统答不好。现在回头补指标和问法引导，等于绕了一圈。