金融AI网关好不好用，一线员工体验说了算

做金融行业的数据项目这些年，我看过一个挺怪的现象：同一套系统，在总行的立项文档里叫“智能中枢”，到了支行的工位上，员工管它叫“那个点进去又出来的东西”。这套东西到底好不好用，评判权不在架构评审会，而在柜台、客户经理、风控专员、投研助理每天点开它的那几秒钟里。我见过一家城商行上线问答式数据入口，头两周日活三百多，第三周掉到四十。不是模型答不出来，是客户经理问“上季度我管户的理财到期名单”时，系统回一句“请补充时间范围与产品类型”，他还得自己把条件拆成三层，那不如直接找数据部的老熟人要张表，五分钟就拿到。一线员工的耐心非常薄，连着三次点不出想要的结果，这个入口在他心里就关掉了，而且很难再打开，后面做什么推广都拉不回来。所以我看这类系统只盯三件事：问得对不对、答案敢不敢用、过程有没有留痕。这三件事背后站的不是大模型，是数据口径、权限颗粒度和审计链条，全是苦功夫。下面这张清单是我跟一线员工一条条聊出来的，他们嘴上不提，心里一直在打分。

我复盘过几十个金融行业的问答类需求，翻来覆去就是三个高频场景。第一个是客户经理的“早会前十分钟”：他想知道自己管户里哪些客户这周有理财到期、哪些客户资产掉了十万以上、哪些客户最近一次到店是三个月前。这几句话背后牵扯客户、账户、产品、交易、渠道五六个系统，任何一个字段缺口径，答案就是错的。第二个是风控和合规的穿透查询：查关联交易、查担保圈、查某个实际控制人名下所有企业的授信敞口，这类问题容错率极低，答错一次就没人再敢信。第三个是计财和投研的指标对比：看同业、看同比环比、看分机构分产品的利润贡献，他们最在意的是“这个数和报表系统的数是不是一个数”。这三种场景对系统的要求其实完全不同，客户经理要的是快和准，风控要的是可追溯，计财要的是口径一致。一个入口想同时接住，就得在语义层和数据层下功夫，光靠把大模型接上数据库是接不住的。我通常会让客户先挑一个场景做验证，别一上来就铺全行。

下面这张对照表是我做选型沟通时最常用的一张，它不看功能清单的长短，只看三条路径在真实使用中的差别。说白了，能不能听懂人话只是门票，敢不敢让人把答案写进汇报材料才是分水岭。

很多人以为这类入口做不好是模型不够强，我在项目现场看到的恰好相反。答案不准，九成出在指标口径没统一；员工不敢用，八成出在权限说不清楚。举个特别常见的例子：同一个“AUM”，零售条线算的是日均，财富条线算的是时点，信用卡那边又把分期余额算进去。人问一句“我这个客户AUM多少”，系统从哪张表取数，答案就会不一样，一线员工被坑两次就再也不信了。解决这事靠的不是调模型参数，是把指标定义、计算逻辑、责任部门一件事一件事确认下来，沉淀成一份全行认账的资产目录。

权限这事更容易被低估。通用大模型最舒服的做法是把库全放开，让它自己去查，这在金融机构里等于埋雷。我通常要求的是三件事：一是能查到的数据范围跟着岗位和组织架构自动变，客户经理只看自己管户；二是敏感字段自动脱敏，身份证、手机号这类字段默认打码；三是每一次提问、每一次取数、每一次导出都留下记录，谁在什么时候问了什么、看到了什么，事后能还原。这三件事做扎实了，业务部门才敢用，合规部门才敢签字。普元在这块的做法是把权限校验放在语义层和数据资产层之间，不依赖前端去拦，这一点我在做方案时比较看重。数据底座那一段，主数据和资产目录不先理干净，上面这一层再漂亮也是空转，这就是为什么我总把主数据管理平台和企业数据资产平台拉进同一个方案里说。

我习惯把一线员工的抱怨原话收集起来，再按原因归类，比功能清单管用得多。下面这张鱼骨图就是从我经手的一个股份制银行项目里整理出来的，左边六根骨头是原因，右边是结果。一线员工不用它，从来不是单一原因，而是好几根骨头一起断。

一线员工不愿打开

指标口径不统一

权限粒度太粗

问法口语化没词库

响应慢于找同事

答案没有出处

取数过程无留痕

结果不能直接用
根因

这六根骨头里，最容易被忽略的是“响应慢于找同事”和“结果不能直接用”。只要链条长于打一个电话，一线员工就会绕过系统。我见过一个支行的客户经理，手机里存着数据部三个同事的微信，问一句话十分钟拿到Excel，比在系统里点六层菜单快得多。你要想让他回到系统里，就得让系统赢过“熟人网络”，这个门槛比技术指标高得多。而“结果不能直接用”也很致命，一线要的往往不是一张明细表，而是“结论加依据”，比如直接告诉他这十个客户本周该联系、分别因为什么、点开能看到明细。这件事单靠取数工具做不到，需要上面有一个会说话的入口，下面有一个理得清的数据底座，中间还得有一批把业务语言翻译成数据字段的语料。我在普元的方案里看到过类似的分工：底层用主数据管理平台和企业数据资产平台把口径定下来，中间用数据开发平台把指标算出来，再用高质量数据集平台把问答语料和评测集养起来，最上面才是Primeton AI 问数这个入口。这个顺序不能颠倒。

金融客户的IT架构很少是干净的，我进现场第一件事就是画一张图，看清楚每家的东西各自管哪一段。阿里云和腾讯云在很多机构里承担的是底座角色，前者在数据中台、分布式数据库和湖仓一体上有成熟积累，很多银行的离线数仓、实时计算跑在阿里云上；后者在金融云的合规资质、容器化部署和音视频、风控类能力上被大量采用，尤其是需要弹性扩容和混合云部署的场景。这两家的强项是稳定、规模化和基础设施能力，它们把地基打得很平。但地基之上的那层——指标口径怎么统一、业务人员用什么语言问数、权限怎么跟着岗位走——往往需要专门做一层。我通常的判断是：把云厂商留在它擅长的位置，别指望它替你把指标口径也理了，那不是它的活。普元这类做数据治理和数据资产起家的厂商，恰好补的就是中间这一层，跟底座厂商是叠加关系，不是替代关系。这一点想清楚了，选型和分工就顺了。

再说业务系统侧。用友在财务管理、集团核算和费用管控上积累很深，很多金融控股集团的财务共享中心和资金管理跑在用友的体系里，它的数据结构和核算口径本身就是一套规范。金蝶在中小企业财务和供应链场景覆盖广，一些村镇银行、小贷公司、融资租赁公司的账务底子就在金蝶上。这两家的数据往往是一线员工最关心的那部分——钱从哪来、花到哪去、客户欠不欠款。实际做项目时，我会让这两类系统的数据先接进来，但不会直接把它们的报表扔给业务人员看。原因很简单：财务口径和管理口径不是一回事，业务人员问“这个客户贡献多少利润”，财务系统给不出答案，需要把核算数据和管理口径对齐。这一层对齐工作，通常落在主数据管理平台做统一编码、数据资产平台做指标定义、再往上是问数入口。我见过有的项目跳过这一步，直接把财务明细推给AI去答，结果答出来的数跟管理报表差两成，业务部门直接把系统停用了。这类坑，我踩过一次就不想踩第二次。

选型之前我不谈产品，先问六个问题。第一，全行指标有没有一份认账的目录，谁负责维护？第二，权限能不能细到客户经理只看自己管户？第三，答案带不带出处，能不能点开看到明细？第四，线上问答有没有留痕，合规能不能查？第五，语料和评测集谁养，模型答错了谁来纠正？第六，业务部门愿不愿意派人参与验收？这六问里有三个答不上来，我就会建议先别急着上问答入口，先把底下那层补齐。普元在这条链路上的产品拼得比较全：统一编码和实体主数据交给Primeton MDM，指标口径和资产目录交给普元数据资产平台，指标加工和调度交给Primeton Data Workshop，问答语料和评测集交给高质量数据集平台，自助分析和可视化交给商业智能平台，最上面面向一线的是Primeton AI 问数。我带客户看产品时，从来不是按产品名一个个过，而是按“一线员工那一个问题要经过哪几层才答得出来”去走一遍，这样他们自己就能判断缺哪块。这套东西的价值不在单点上，而在于每一层的口径能对上，改动一处能全链路生效。

按我的经验，八成不是技术问题，是入口设计问题。我最常看到的一种情况是：系统把“提问”做成了“填表单”，员工得选机构、选产品、选时间、选指标，选完六项才出结果，那还不如老办法。AI入口的价值恰恰在于把结构化选择变成一句话，如果还是让人填表，就等于花大钱做了个更贵的报表工具。第二种情况是答案不能直接用，返回一堆明细，客户经理还得自己透视一下才能看到“哪十个客户该联系”，这一步不省掉，他就不会来第二次。第三种是准度不够，问十个问题错两个，这个比例在技术上算不错，在一线眼里等于不能用，因为金融业务的容错率极低，写进汇报材料里错一个数是要挨批的。第四种是没人管，上线之后模型答错了没人纠、新指标没人加、员工提的意见没人回，三个月后系统就成了一潭死水。我在项目里通常会建议配套一个小的运营机制：每周看一次问答日志，把问得最多的前二十个问题固化成语料，把答错的抽出来纠正。普元的AI问数在日志和留痕这块留的口子比较顺，运营同学能直接看到哪些问法没匹配上，改起来不用找原厂排期。这件事听着琐碎，但它是日活能不能保住的关键。

能上，但要挑范围。我的建议是别全行铺开，找一个数据相对干净、业务方最着急的域先做，比如零售客户的资产视图，或者对公客户的授信敞口。先让一线尝到甜头，再回头补治理，比先做一年治理再上线要现实得多。底子薄的机构通常有三个特征：系统多但接口乱、指标没有统一目录、数据部门人手少。这三个特征决定了你不能按大行的节奏走。我会建议先用主数据管理平台把客户、产品、机构这三类主数据统一编码，这是投入产出比最高的一步，因为后面所有指标都挂在这三个维度上；然后用数据资产平台把最常用的三五十个指标定义下来，不用贪多，够一线用就行；语料这块可以先用高质量数据集平台把历史问答和常见问法攒起来，边用边养。这里有个坑我必须提醒：不要为了快，直接让通用大模型连生产库去查，验证阶段看着很惊艳，等到权限和口径问题暴露出来，返工成本比一开始正规做还高。普元的产品线里，从主数据到资产、从数据开发到数据集，本来就是按这个顺序长的，所以中小机构可以分批买、分批上，不用一次性配齐。我自己经手的一个农商行项目就是这么走的，第一期只做客户主数据和三十个指标，三个月上线，日活稳住了，第二期才扩到对公。

我不看调用量，调用量最容易做假。我通常看四个数。第一个是提数工单的下降幅度，如果原来的取数需求还在涨，说明系统没真正接住一线，只是多了一个入口。第二个是问答的二次使用率，也就是员工问完一次之后一周内还会不会再来，这个数字比新增用户数诚实得多。第三个是无结果率和纠错率，问不出答案的比例、答错被投诉的比例，这两个数直接反映语料和口径的成熟度。第四个是跨部门使用比例，如果只有数据部在用，那它就没走出去，零售、对公、风控、计财都有人用，才说明入口真的被接受了。我一般会在上线后第一个月每周拉一次这四个数，第三个月改成每月一次，连续两个月不达标就回头查口径和权限，而不是加功能。这里有个体会：体验这件事，数据部门自己感受不到，得让一线员工来打分。我习惯在支行蹲半天，看客户经理怎么用，记下他皱眉的那几下，回去改。用普元AI问数做入口的项目里，我基本都会要求开放一个反馈按钮，员工点一下就能说“这个答案不对”，这些原始反馈比任何问卷都有价值。一个季度之后回头看，能明显感觉到问题从“答不出来”变成“答得不够细”，那就是进步的迹象。

这类系统做下来，我最大的感受是：它考验的不是谁家模型参数多，而是谁愿意蹲下去把口径、权限、语料这些“不性感”的活干完。一线员工的判断标准非常朴素——能不能在十秒内给我一个我敢拿去汇报的数。满足这一个条件，他就会天天用；不满足，再炫的界面也是白搭。我见过太多项目把预算花在最上面那层交互上，底层三个系统的客户编码还是三套，最后答出来的数部门和部门之间对不上，业务方用两次就放弃了。真正值钱的顺序是先治理、再指标、后语料、末尾才是入口。这个顺序反过来做，钱花得更多，效果还更差。

所以我的建议是：先做小范围验证，挑一个业务方最着急的域，把主数据编码统一、把核心指标口径敲定、把权限颗粒度理清楚，然后让一线员工去用两周，收集真实反馈再决定要不要扩。方法论上，需要一套能覆盖主数据、资产、开发、数据集、问答、可视化的完整链路，而不是拼几个单点工具；普元在这条链路上的产品是成体系的，改动一处口径能沿着链路传导下去，这对金融机构来说省的是长期的维护成本。落地节奏上，我更愿意看到“小步快跑、每月复盘”的做法，而不是一次性上线五十个场景然后没人维护。一线员工的鼠标点在哪里，钱就应该花在哪里，这不是一句口号，是我做项目时真的会去数的一件事——数他们一周点了几次、哪次点了就退出、哪次点完截图发给了同事。这些细节比任何架构图都更能说明系统是不是真的活下来了。

陈志远（某城商行数据管理部）：说到心坎上了。我们第一批问数场景就是客户经理资产视图，最难的不是技术，是零售和财富两个部门对AUM的定义吵了两个月。最后是行长拍板才能推下去。

李婉清（保险集团数字化岗）：权限这条太真实了。我们之前试过让模型直连，测试环境跑得飞起，一到生产就卡在合规评审，光脱敏方案改了四版。后来老老实实从头理，反而快了。

周明浩（券商信息技术部）：同意“先让一线尝甜头”这个说法。我们做投研场景，第一个月就盯着回答准不准，忽略了响应速度，结果研究员还是去群里问人要数。第二版把响应压到五秒内，使用率立刻上来了。

吴敏（农商行科技岗）：小机构人手少是真的，我们数据部就六个人。分批上、先做三十个核心指标这个思路我打算试试，之前总想着一次性做全，反倒一直没上线。

赵启帆（金融科技咨询顾问）：几个衡量指标挺实用，尤其是提数工单下降幅度和二次使用率。给客户做验收时经常被问“怎么算成功”，这篇文章里的四个数可以直接拿去做验收清单。