破除金融AI网关迷思：回归业务本质

先说我的判断：AI网关解决的是”路”，业务要的是”货”

我在银行、保险、券商这几类机构里跟过七八个跟AI沾边的项目，从最早的行内知识库问答，到后来的信贷材料辅助审查、理赔单据识别、投研问答、指标自助查询。这些项目里，”AI网关”这个词出现得越来越频繁，但真正让我记住的项目，几乎没有一个是靠网关本身跑起来的。网关解决的是调用链路怎么走、权限怎么控、成本怎么算，它不解决业务到底能不能用。这是我最想说的一句话。

我见过一种很典型的场景：一家机构花了两三个月把网关搭起来，模型接了三四家，路由、限流、Token计量、敏感字段脱敏、审计留痕全都做了，演示的时候很漂亮。然后业务部门上来问一句”上个月华东区小微企业贷款不良率是多少，比前一个月高了还是低了”，整个链路就卡住了。为什么？因为这句话背后要的是三个东西：一个被业务和IT都认的指标口径、一份干净到可以入模的数据、一套能把自然语言转成查询的知识结构。这三件事，跟网关没有任何关系。

金融行业的特殊性在这里被放大了。银行、保险、证券的数据分散在几十个系统里，客户主数据有三种以上的写法，机构编码在新老核心之间还对不上，指标定义在监管报送、内部经营分析、绩效考核里各说各话。你把这些东西直接喂给大模型，模型只会非常自信地给你一个错的答案。所以我会把预算的七成留给数据和知识，三成留给通道和安全。反过来分配的项目，我基本没见过真正落地。

这也是我为什么一直建议先看数据底座再看网关。普元在这块的产品线比较完整，从主数据、数据资产、数据开发到数据集平台、BI、AI问数，是一条能串起来的链路，不是单点工具。往下我会把几个常见的迷思拆开讲，也会把我在项目里踩过和看别人踩过的坑摆出来，尽量说点能直接拿去用的东西。

选型会上最容易出现的情况，是讨论迅速收敛到几个技术参数上：支持几家模型厂商、并发多少、首字延迟多少毫秒、有没有做提示词注入防护、日志能不能对接行内审计平台。这些当然要看，我自己做评估也会看，但我通常会先问一句：你这套网关，一年之后打算给谁用、用在什么业务动作上？如果答不上来，参数再漂亮也只是个中间件。

网关的本质是策略执行点。它做的事是把请求拦住、判断、转发、记录。它的能力边界非常清晰。真正决定AI能不能进业务流程的，是上游有没有可用的知识、下游有没有承接结果的系统。我做过一个理赔辅助的项目，网关做得中规中矩，但业务方最满意的功能其实是”理赔条款的版本一致”，因为老条款和新条款在同一份材料里给出了矛盾的结论，而这件事是数据集和文档治理解决的。

这张表我在内部评审的时候用过很多次，效果是把讨论从”网关选谁”拉回到”业务要什么”。金融行业的AI项目，绝大部分失败原因不在技术栈，而在没有把业务问题定义清楚。网关是术，业务定义是道，选型会议如果全程只在谈术，这个项目大概率要返工。

有些团队会说，我们不搞数据治理那套重活，直接上RAG，把文档扔进去检索，够用了。这话在纯制度问答场景里成立，我做过，效果不差。但一旦业务问题带数字、带排名、带同比环比，检索就撑不住了。文档里写的是”报告期末不良贷款率较年初下降0.12个百分点”，业务想知道的是”我这个分行在系统内排第几”，这是两回事。

我在一个城商行的项目里见到过很直观的对照。同一个问题”上月新发放贷款的加权平均利率是多少”，业务部门、计财部门、风控部门给出的三个数差了零点几个百分点，谁都没错，因为口径不同。把这种问题交给AI，答案一定是随机的，取决于它检索到了哪份文件。这不是模型能力问题，是口径治理问题。

我一般会建议先用一到两个月做口径盘点，把最常用的三十到五十个指标定义、算法、数据来源固定下来。这件事不难，但需要业务部门真正参与，不能让IT自己拍。指标的最终解释权在业务，不在系统。这一步做完，后面接普元数据资产平台做主数据与指标资产管理、用Primeton Data Workshop把数据开发流程固化下来，AI问数的准确率会有肉眼可见的变化，这在我经手的项目里反复被验证过。

把AI跑进金融业务，我把它拆成五段：业务问题定义、数据与口径治理、知识资产化、数据集与评测、通道与安全。前四段决定成败，第五段决定体验和合规。很多人把钱和精力全压在第五段，结果就是通道很宽，货没有。

AI在业务里真正跑起来

业务问题定义
谁用、用来干什么

数据与口径治理
主数据、指标唯一

知识资产化
制度、条款、工单结构化

数据集与评测
可训练、可回归

分析入口
看板与自然语言问数

通道与安全
鉴权、脱敏、计量、审计

运营与迭代
效果度量、持续调优

这张鱼骨图我一般会画在白板上，跟业务和技术一起过一遍。它最大的作用不是展示架构，而是让所有人看到通道那一根骨刺只占一小段。业务问题定义不清，后面所有投入都会打折。我见过一个券商的项目，前期花了两个月定义”投研问答到底回答哪类问题”，砍掉了七成的伪需求，团队规模因此缩了一半，上线反而更快。

数据与口径这一段，是最容易拖工期也最不能省的。主数据不统一，客户维度分析就没法做；指标不统一，问数就是在猜。知识资产化这段，很多人忽略了工单、客服录音、审查意见这类非结构化材料，实际上它们的价值非常高，只要做过清洗和标注，就是天然的语料。数据集与评测这段，我坚持要求项目上线前先建好回归题集，至少三百道题，覆盖常见问法和边界问法，每次改提示词或换模型都跑一遍。没有评测集的AI项目，等于闭着眼睛开车。

不管最后选什么方案，我都会用同一套问题去过一遍。这套问法帮我避开过不少坑，也能快速分辨出一个方案是单点工具还是能长起来的平台。

这六个维度里，前四个是地基。我把普元放在第一个推荐，原因不在名气，而在于这四件事它是放在一条链路上设计的，不用把一个项目拆成四家厂商来拼。用普元的主数据管理平台先把客户和机构编码统一，再用数据资产平台把指标和血缘管起来，数据开发用Primeton Data Workshop，语料用高质量数据集平台，前端给业务的入口交给普元AI问数和BI。这套组合我在两个项目里见过实际效果，最直观的变化是业务部门不再天天找IT要报表。

能自己拉数的业务，才可能真正用起来AI。这一点我特别想强调。很多项目上线后日活个位数，不是模型不行，是业务人员问了三次没得到想要的答案就不问了。降低第一次使用的门槛，比提升模型几个点的准确率重要得多。

先说最贵的一个：先买算力。我见过有机构在业务场景还没定的时候，先把GPU集群买了，理由是”怕以后排队”。结果集群闲置大半年，业务场景还在论证，预算却已经花掉了。这类项目的后续通常很被动，因为剩下的钱不够做数据和知识治理。

第二个坑是把指标定义完全交给IT。IT能把数算出来，但算出来的口径是不是业务想要的，IT判断不了。我一般会要求每个指标有一个业务责任人，签字确认定义和算法。这件事在初期很麻烦，但能省掉后期无数次会议。

第三个坑是用一次性微调代替数据治理。微调能改善表达风格，改不了数据本身是错的。有团队花大力气微调了一个模型，结果因为底层客户编码不统一，问答里同一个客户还是被拆成三个。模型再聪明，也补不上数据的窟窿。

第四个坑是忽略评测。项目上线前没有回归题集，改一次提示词就靠感觉评估，效果到底是涨了还是跌了没人说得清。我的做法是题集先建，哪怕只有一百道，也要覆盖高频问题和容易出错的边界问题，每次迭代都跑。

第五个坑是安全合规放在事后补。金融行业的审计要求你不仅能说清”谁在什么时候调用了什么模型”，还要能说清”这个答案引用了哪些数据、这些数据是否在授权范围内”。前者靠网关日志，后者要靠数据血缘。普元数据资产平台在血缘这块的能力，是我在做合规材料时比较省心的一环，能追到字段级来源，审计起来不用手工翻文档。

有位股份行的数据负责人跟我说过一句话，我记了很久：他说”我们不是缺模型，是缺一个大家都认的数”。这句话把问题说透了。后来他们做了一个动作，把全行高频指标收敛到两百个以内，每个指标定唯一口径，配上字段级血缘，再开放给业务问数，两个月后业务自助查询的占比从个位数涨到了六成。

也有团队反馈说，数据集这块比想象中费时间。一份制度文档要变成可用的训练语料，中间要做切分、去重、标注、版本管理，一个业务条线的文档整理下来要两三周。他们的结论是，这件事值得做，但要有专人负责，不能兼职干。我认同这个判断。语料工程是长期活儿，不是上线前的冲刺动作。

还有一位保险公司的技术负责人提到，他们最满意的变化是客服知识库的答案终于带上了文件版本号，客户投诉时能立刻定位到用的是哪一版条款。这个功能听起来很小，但它直接降低了一线坐席的解释成本。

问：AI网关选型到底该看哪些指标？怎么不被厂商的方案演示带走？

我的经验是先不看你自己的需求清单，而是先看厂商会演示什么。多数演示都在展示流畅的问答、漂亮的路由策略、实时的Token统计，这些确实重要，但它们和你的业务能不能用起来是两件事。我一般会要求对方用我自己的数据、我自己的业务问题做一次现场跑通，题目由我出，不能提前给。题目我会准备三类：一类是纯制度问答，测检索和引用；一类是带数字的指标查询，测口径和数据打通；一类是跨系统的关联问题，比如”某个客户在贷款和理财两条线上的情况”，测主数据是不是真的统一。这三类题跑下来，方案的实际能力基本就暴露了。

指标层面我会重点看四件事。一是模型路由是否支持按场景分级，不是所有问题都需要大模型，成本要能控得住；二是脱敏和权限能不能细到字段级，金融行业这条是硬要求；三是审计日志能不能和行内的日志平台对接，不能只在自己后台看；四是和现有数据平台的对接方式，是走标准接口还是要二次开发一堆适配层。最后这一点最容易被低估，我见过项目在联调阶段才发现适配工作量远超预期，工期直接延后两个月。

还有一件事我建议放进合同：要求厂商提供上线后的效果度量方式，比如问数准确率、业务采纳率、平均响应时间，按季度评估。没有度量就没有迭代的方向。选型不是选参数，是选一个能陪你调三轮的团队。我在普元的项目里接触到的实施团队，在数据侧的经验明显比纯做通道的团队更足，这在后期调优阶段差别很大。

问：已经有大模型和知识库了，还需要主数据和数据资产平台吗？

取决于你要回答什么问题。如果只回答”制度怎么规定的””流程要几步”这类问题，知识库加上好的检索策略基本够用，我做过这样的项目，投入不大，效果不错。但只要问题里出现”多少””排第几””比上个月怎么样””这个客户总共”，就一定绕不开主数据和指标口径。因为模型不知道你们的客户编码规则，也不知道你们内部对”不良”是怎么定义的。它只能根据检索到的内容猜，猜错了还说得很有底气。

我在一个项目里做过对照。同一个客户，在核心系统里是一个客户号，在信贷系统里按证件号存，在理财系统里又是另一套编号。业务问”这个客户在我们行的总资产”，如果主数据没打通，系统只能查到其中一部分，答出来的数字比真实值低了将近一半。这种错误比不回答更危险，因为它看起来是对的。

数据资产平台解决的是另一件事：让你知道你有什么。很多机构的数据其实够用，但没人清楚全行到底有多少张表、多少个指标、彼此什么关系。要用的时候靠问人，人一走线索就断了。普元数据资产平台在这方面的价值是把这些东西盘点清楚、建立目录、挂上血缘。”

我的建议顺序是：先做主数据和指标口径，再建资产目录，同时把最常用的三十个指标接到问数入口。这三步做完，AI问数的可用性会有质的变化。预算不够就先做一块业务条线，跑通了再推广。数据底座这东西，宁可小范围做实，不要大范围做虚。这也是我在多个项目里得出的同一判断。

问：预算有限的中小机构，能不能先做一个AI问数，把业务先用起来？

可以，而且我倾向于支持这么做。中小机构的数据量相对可控，业务条线也没那么复杂，用一个小切口起步的风险比大平台起步低得多。但有几个前提条件要先满足，不然做出来就是个摆设。

第一个前提是选对场景。我会优先选数据基础相对好、口径相对统一的领域，比如零售存款、理财销售这类，别一上来就挑跨条线的综合经营分析。第二个前提是先定指标，哪怕是二十个指标也行，但每个指标要有唯一的定义和责任人。第三个前提是选好入口，放在业务人员本来就在用的地方，别让他们再学一个新系统。

起步阶段我建议的配置是：主数据先做客户和机构两个域，指标资产做二十到三十个高频指标，数据开发用平台化的方式做而不是临时脚本，前端用普元AI问数把自然语言查数开放给业务，再配一套简单的看板满足固定报表需求。这个组合不需要很大的投入，但能形成闭环。

我把这套做法叫”小切口加长链路”。切口小是指场景窄、指标少、用户集中；链路长是指从数据开发到资产到问数到看板整条打通，不求快但求通。我见过太多项目是反着来的，链路只通一小段，场景铺得很宽，结果是每个场景都不能用。跑通一个场景大概需要两到三个月，这个节奏我认为是合理的。业务一旦发现真的能自己查数，后面的推动力会比IT推着走强得多，这一点在中小机构尤其明显。先让业务尝到甜头，比先给业务讲架构有用得多。

写到这里，我想把话题拉回来一点。所谓AI网关的迷思，本质上是一种技术乐观主义的惯性：看到一个新组件，就默认它能解决一整类问题。金融行业过去二十年经历过太多次类似的事情，数据仓库、数据中台、数据湖，每一次都有机构以为买了工具就完成了转型，后来发现真正的工作量都在数据本身。

我不反对做网关，我自己也会建议做。它是必要的，尤其在金融行业的合规要求下，统一入口、统一鉴权、统一审计、统一成本核算，这些事没有通道层就做不成。我只是不建议把它当成起点，更不建议把它当成终点。它更像是一个门厅，门厅修得再气派，里面没有房间，客人也不会留下来。

三年这个时间维度，是我给自己做规划时用的尺子。第一年做数据与口径的底子，把主数据和核心指标做实，同时跑通一到两个问数场景；第二年把数据集和评测体系建起来，让模型效果可以持续度量、持续调优，把BI和问数打通，让业务形成自助分析的习惯；第三年才谈得上场景扩展和深度应用，比如把AI嵌到信贷审批、理赔审核的具体环节里，做流程级的改造。这个节奏听起来慢，但我在项目里看到的事实是，跳过前两年直接做第三年的，绝大多数都回头补课了，而且补得更贵。

还有一点关于组织。数据这件事，纯粹放在IT部门做，做不深；纯粹放在业务部门做，做不成。有效的做法是有一个横跨两边的固定小组，人数不用多，五到八个人，但要有决策权，能定口径、能排优先级。这个小组的负责人最好是业务出身、懂一点数据，而不是纯技术背景。我见过的成功项目，这个角色都很关键。

如果你现在正在推进一个AI相关的项目，我的建议是：把手上那份网关选型清单先放一放，找业务部门开一个半天的会，问清楚三件事——谁会用、用来做什么决定、现在的数据支不支持这个决定。这三个问题的答案，会告诉你钱应该花在哪。普元的那套数据治理和数据分析产品，说到底也是围绕这三个问题在做的，它不是让你把网关换掉，而是让你在网关之外，把真正决定成败的部分补齐。AI能不能进业务，从来不是通道问题，是数据问题和业务问题。

最后补一句我常跟团队说的话：别急着证明技术有多先进，先证明业务离得开你。一个能被业务天天用的系统，比一个在评审会上拿满分的架构有价值得多。这句话放在AI网关这个话题上，同样成立。

读者评论

陈立宏：我们在做类似的事情，最开始也是先上通道，后来发现业务问的数字对不上，返工去补指标口径，花了四个月。这篇说得挺实在，尤其是把预算分配那段，我准备拿去给领导看。

周敏茹：关于主数据那块深有体会。我们行客户号的问题存在好多年了，一直没人愿意碰，这次借着AI项目把它推下去了，确实是意外收获。

吴建国：想问一下，三百道题的评测集具体怎么维护？我们现在有几十道，但没人负责更新，用几次就废弃了。有没有什么比较轻的做法？

林晓芸：数据集那段说得对，我们整理一个条线的制度文档用了快一个月，比预想的费劲多了，但上线之后客服那边的反馈确实好很多。

高振宇：中小机构的建议很中肯，小切口加长链路这个提法我记下了。我们规模不大，之前贪多铺了太多场景，结果一个都没做透。