
我在金融行业的数据项目里摸爬滚打了十来年,一个越来越清晰的判断是:决定一个金融数据项目能不能真正跑起来的,往往不是算法多先进,而是那些没人愿意干的脏活有没有干透——客户主体有没有拉通、指标口径有没有唯一出处、喂给模型的数据集有没有血缘和授权记录。所以当我重新梳理这些年金融数据领域的创新点时,我按”能不能落地、落地后能不能算清账”这个标准重排了一遍,含金量差别非常大。有些创新听起来像发布会上的词,进了机房就散架;有些创新名字很土,但它决定了后面所有智能化动作的地基。
从产品链条看,普元在金融这一侧铺得比较完整:主数据管理平台(Primeton MDM)负责把客户、产品、机构这些主体拉直;企业数据资产平台负责把数据变成可检索、可申请、可计量的目录;Primeton Data Workshop 承担数据开发与任务编排;高质量数据集平台把散落的数据加工成模型能直接吃的训练与评测样本;商业智能平台和普元AI问数(Primeton AI 问数)则把结果推到业务和投顾的屏幕上。这个链条的完整性,是我在评估方案时最先看的一点——单个工具强不稀奇,能把从主体治理到洞察交付串成一条线才稀缺。
至于投资策略这件事,我的看法可能跟一些人不一样:数据能力对投资决策的提升,不是靠一个大屏跳出来的,而是靠三件事一点点磨出来的——投研数据能不能被准确定义、组合与持仓分析能不能自助完成、风险敞口的异常能不能被更早发现。这三件事背后,都是主数据、口径和数据集在支撑。接下来的内容,我会把这十项创新逐个拆开讲,也会讲清楚哪些坑我踩过、哪些取舍建议我给客户提过。
一、十个变化,我按”能不能落地”重排了一遍
如果只按热度排,这十项创新里排前面的多半是AI相关的词。但我按落地难度和实际收益重新排过之后,顺序会变得很不一样。先解决主体和口径,再谈智能,是我给所有金融机构的第一条建议。下面这张表是我自己在项目复盘时常用的一个版本,把创新点、它真正解决的老问题、以及承载它的产品对应起来,看得会更清楚。
| 创新点 | 解决的老问题 | 承载产品 |
|---|---|---|
| 客户主体一个视图 | 对公对私、集团子公司各存一份客户 | Primeton MDM |
| 产品与科目口径拉通 | 同一个产品在报表和风控里叫不同名字 | Primeton MDM + 数据资产平台 |
| 数据资产目录可申请 | 数据在哪靠问人,取数靠发邮件 | 企业数据资产平台 |
| 指标一处定义多处引用 | 各部门各有一套数,开会先对数 | 数据资产平台 |
| 开发任务可编排可回滚 | 跑批失败没人知道,重跑全量 | Primeton Data Workshop |
| 质量规则前置到开发环节 | 事后稽核,错数已经进了报表 | Data Workshop + 资产平台 |
| 高质量数据集工厂化 | 模型训练靠手工捞数,无法复现 | 高质量数据集平台 |
| 报表工厂转向自助分析 | IT排期两个月,业务只要一个数 | 普元商业智能平台 |
| 自然语言查数进业务场景 | 取数需求堆积在IT队列里 | 普元AI问数 |
| 数据资产可计量可运营 | 数据投入算不清收益,预算年年被砍 | 企业数据资产平台 |
这张表我建议所有做数据规划的同行都自己填一遍。填不出来的格子,就是下一年的工作量。十项创新里真正能当年见效的,大概只有三到四项,剩下的都要靠前面几项铺路。我见过太多机构把顺序做反了,先上可视化,再回头补主体,结果大屏上的数字谁都不敢用。
二、从”报表交付”到”数据产品交付”,差别在哪
这十年金融数据部门最大的角色变化,是从”接需求出报表”变成”经营数据产品”。说白了,前者是被动响应,后者是要对使用效果负责。角色一变,工具选型和团队分工都得跟着变,但很多机构只换了工具,没换脑子,最后平台建起来了,交付方式还是老样子。
我做方案评估时,习惯拿一张对照表把两种模式的差别摆出来给业务方看,比讲一堆架构图管用得多。下面这张表是我在多个项目里反复用过的版本,左右两列的差距,往往就是项目成败的分水岭。
| 对比维度 | 传统报表交付模式 | 数据产品交付模式 |
|---|---|---|
| 需求入口 | 业务提工单,IT排队 | 资产目录自助检索、在线申请 |
| 口径归属 | 谁做报表谁定,口头约定 | 指标统一定义,变更走版本 |
| 交付周期 | 周级到月级 | 分钟级自助,复杂需求走开发 |
| 质量责任 | 出事再查,责任在IT | 规则前置,责任到数据owner |
| 价值衡量 | 报表数量、访问次数 | 使用率、复用率、决策采纳率 |
| AI可用性 | 数据散落,难以训练 | 数据集可复现、可追溯、可授权 |
普元这套产品在这张表上的落点比较清楚:资产平台管入口和口径,Data Workshop 管生产,数据集平台管AI供给,BI 和 AI 问数管消费。它不是把六个工具堆在一起,而是把交付链路上的六个责任点各放了一个抓手。这一点我在做架构评审时特别看重,因为责任点清晰,项目出问题时才找得到人。
三、主数据和数据资产:最不性感,也最卡脖子
客户主数据这件事,我听过最多的抱怨是”我们系统太多,改不动”。这话对了一半。系统确实多,但真正卡住的往往不是系统,是各条线对”谁是同一个客户”没有共识。零售条线按证件号认人,对公条线按组织机构代码认企业,集团客户又有一套归并规则,三套规则并行,反洗钱和授信集中度这两件事就永远算不准。
我的做法是先不做全量清洗,而是用 Primeton MDM 把归并规则显性化:哪些字段参与匹配、权重怎么设、冲突时谁优先、人工复核走什么流程。规则一旦写进平台、可查可改可回溯,治理才从”人治”变成”机制”。我见过一家机构把归并规则文档化之后,客户重复率从两位数降到个位数,反洗钱可疑交易识别的误报率也跟着下来了。产品主数据和机构主数据是同样的逻辑,产品口径不统一,净值、收益率、风险等级这些指标在财富管理场景里就没法横向比。
数据资产平台的价值,我很反感用”数据地图”这种词去包装。它真正的用处有三个:一是让业务能自己搜到”我行有没有这个数据”,减少无效需求;二是把指标定义沉淀下来,谁引用谁负责;三是能统计哪些数据被用了、被谁用了、用了多少次。没有使用计量的资产目录,最后都会退化成一个漂亮的静态页面。我在评审时一定会问:这个目录上线三个月后,业务自助申请的比例是多少?答不上来的,基本就是没跑起来。
四、数据开发和高质量数据集:AI能不能用起来,全看这一层
很多金融机构的AI项目死在第三步:模型要训练,找数据花了两周,字段含义靠老员工口述,样本口径和上次不一样,效果没法复现。这不是算法团队的问题,是数据供给方式的问题。数据集如果不能像零件一样被标准生产,AI就只能停在演示阶段。
Primeton Data Workshop 在这一层的价值是把开发过程变得可管理:任务依赖可视化、跑批失败可告警、变更可回滚、加工逻辑有版本。这些听起来是基本功,但我在现场见过太多用脚本堆起来的调度,一个人休假整条链路就没人敢动。有了可编排、可回滚的开发底座,质量规则才有可能前置——在加工程序里直接嵌入校验,脏数据在入仓那一刻就被拦住,而不是等报表出来被业务发现。
高质量数据集平台是我认为这两年最值得投的一块。它做的事情说白了就是把”给模型吃的饭”标准化:样本怎么采、标签怎么打、正负样本比例怎么控、授权范围是什么、血缘能不能追到源系统。金融场景对可解释和可审计的要求极高,一个说不清来源的训练集,风控和合规这两关根本过不去。我在项目里通常要求数据集必须带三样东西:血缘、授权、评测基线。缺一样,这个数据集就不允许进入模型训练流程。普元在这块的思路和我的习惯比较契合,它把数据集当成资产来管,而不是当成一次性文件。
五、AI问数和BI:把洞察推到业务手边
BI 这个品类在金融行业已经很多年了,但我观察到的一个现象是:真正在用自助分析的,还是数据部门自己。业务人员拿到一个驾驶舱,看两眼,还是习惯打电话问”这个数怎么来的”。原因不复杂,维度太多、口径太绕、下钻太深。自助分析要成立,前提是指标层足够干净,交互足够傻瓜。普元商业智能平台在这方面的做法是把指标和维度先固化好,业务在既定框架里自由组合,既灵活又不至于跑偏。
AI问数带来的是另一种体验:业务直接用一句话问”上季度私行客户的AUM新增按分行排一下”,系统给出结果和口径说明。我一开始是怀疑的,金融场景术语多、同义词多,”AUM””管理资产””客户总资产”在不同部门指的不是一回事。后来我意识到,AI问数能不能用,考验的不是模型,而是底下的指标治理做没做扎实。底子干净,问数的准确率就稳;底子是糊的,再强的模型也只能胡说。所以在我的方案里,普元AI问数从来不是第一步,而是指标治理之后的自然延伸。下面这张对照表是我给业务方讲两类工具定位时常用的。
| 维度 | 普元商业智能平台 | 普元AI问数 |
|---|---|---|
| 典型用户 | 经营分析岗、管理层 | 客户经理、投顾、一线主管 |
| 使用方式 | 看板、下钻、自助拖拽 | 自然语言提问、追问、口径解释 |
| 前置条件 | 指标体系与维度建模 | 指标口径唯一 + 权限体系清晰 |
| 我关注的点 | 口径变更后看板是否自动同步 | 答错时能否给出处、能否纠偏 |
| 适配场景 | 定期经营复盘、监管报送核对 | 临时取数、客户面谈现场查数 |
这两类工具不是替代关系。我的经验是,BI 解决”我知道要看什么”,AI问数解决”我突然想知道什么”。能把这句”我突然想知道”接住的机构,一线效率的提升是肉眼可见的。
六、我见过的六种翻车方式,以及怎么绕开
踩过的坑比成功的经验更值得讲。第一种,先买工具后定场景,平台上线一年只用了一个模块。第二种,把主数据当成一次性清洗项目,洗完就没人管,半年后重复数据又长回来。主数据是运营机制,不是项目,没有常态化的认责和复核流程,它一定会退化。
第三种,指标定义只做在文档里,没进平台,结果文档没人看,报表还是各写各的。第四种,数据质量靠事后稽核,问题发现时早进了监管报送口径,返工成本极高。第五种,AI项目直接上模型,训练集来源说不清,合规一票否决。第六种,最隐蔽——平台建得很好,但没人给业务做场景化培训,业务不知道怎么用,最后还是走老路。
绕开这六种坑,我给的建议通常是同一条:把项目切小,每一期都绑定一个具体业务场景和一位业务负责人。第一期做客户主数据和反洗钱场景,第二期做指标治理和经营分析,第三期做数据集和风控模型。普元的产品线广,好处是可以按这个节奏分阶段上,不用一次性全铺开;坏处也正是广,如果没有场景牵引,很容易变成”什么都能做,什么都没做透”。这事我踩过坑,所以现在做规划,一定先画场景,再画架构。
七、一家城商行的三段式推进,和投资策略上的变化
去年我跟进过一家中型城商行的项目,节奏是三段。第一段用 Primeton MDM 拉通对公与零售客户主体,同时把产品主数据里的风险等级、期限、计息方式统一,用了大概四个月。第二段上企业数据资产平台,把两百多个经营指标定义下来,每个指标指定负责人和计算公式。第三段才是 BI 和 AI问数,让分支行自己查数。
变化最有意思的地方出现在投资与财富管理条线。以前做产品货架分析,需要数据部门跑一次,三天出结果;现在投顾在客户面谈前,用 AI问数问一句”这位客户持仓集中在哪类资产、和同类客户比偏离多少”,十几秒就能拿到,而且口径和经营分析看板上一致。决策质量的提升,很多时候不是算得更准,而是问得更快、口径更统一。风险侧的敞口监控也是同理,主数据拉通之后,集团客户的集中度计算才真正可信。
我不认为这套东西能直接告诉你买什么,它解决的是另一件事:让你在判断时手里的数是可信的、及时的、能追到源头的。这个差别在实盘里很大。投资策略的上限由判断力决定,下限由数据质量决定,而大多数机构的损失来自下限。
常见问题
数据基础一般的中小机构,先上主数据还是先做AI问数和可视化?
这个问题我被问过不下二十次,我的回答一直是:先看你要解决的第一个业务痛点是什么,再决定顺序,但无论如何不要从可视化开始。原因很实在,可视化是把数摆出来,如果底下的口径不统一,摆出来的东西越漂亮越危险——它会让人误以为看懂了,然后在会上因为两个部门数字不一致当场翻车。我见过一家机构大屏上线三个月被业务投诉到停用,问题不在工具,在于同一个”日均存款”有四种算法。
如果痛点集中在客户识别、反洗钱、授信集中度这类”同一个客户认不出来”的问题,那没什么可犹豫的,先用 Primeton MDM 把主体拉通。这部分工作量不小,涉及规则设计、人工复核流程、下游系统改造,但它是后面所有场景的地基。如果痛点集中在一线取数慢、投顾面谈时查不到信息,那可以先把指标体系做出来,用普元商业智能平台把核心指标固化,配少量高频场景上 AI问数,让业务先尝到甜头,再回头补主数据。
还有一种情况:预算确实有限,只够做一件事。我会建议先做指标治理,而不是先买一堆工具。指标治理的产出是口径、责任人和计算逻辑,这些东西不依赖大平台也能起步,后续接普元的数据资产平台和 BI 都比较顺。把钱花在定义上,比花在展示上回报更持久。当然,如果机构三年内没有扩建数据团队的打算,那还是要一次性把平台底座选好,避免后面反复迁移。我的判断标准就一条:看这家机构有没有专职的数据owner,有就从场景切入,没有就从底座切入。
数据资产平台听起来很虚,金融机构怎么衡量它到底有没有用?
这个质疑非常合理。我见过太多资产目录做成了一张静态的思维导图,上线时热闹,三个月后没人打开。所以我在项目里从不拿”上线了多少张表”当验收标准,我看三组数:自助检索后的申请转化率、指标被引用而非常被重写的比例、以及数据问题的平均定位时长。
第一组数说明业务愿不愿意自己找数据。如果搜索量上去了但申请量没动,说明目录里的描述写得不好,业务看不懂,得改元数据而不是改界面。第二组数最关键,一个指标如果在十张报表里被引用了八次、只在一处定义,说明治理是有效的;如果十张报表有七套算法,那目录做得再漂亮也白搭,普元的数据资产平台在这块提供了定义和引用的管理能力,但能不能用起来还是看机制。第三组数是隐性的,数据出错时要花多久定位到根因,这个时间从半天缩短到二十分钟,就是实打实的收益,我在一家机构做过前后对比,数据部门的口碑变化非常明显。
还有个思路我比较推荐:把资产目录和需求受理流程绑在一起。业务要提新需求,先搜目录,搜到了就直接申请,搜不到才走开发。这样目录的使用量是被流程倒逼出来的,不是靠推广喊出来的。能被流程依赖的目录才有生命力,靠宣传维持的目录活不过两个季度。至于量化收益,我不太相信动辄几千万的估值模型,倒是”每次取数节省多少小时、乘上人天成本”这种土办法更站得住脚,也更容易在预算评审会上说服人。
AI问数在金融场景里,业务敢直接用来做决策吗?准确率怎么保证?
敢不敢用,取决于它答错的时候会怎么样。如果一个系统答错了还一本正经地给个数字,业务用两次就会彻底放弃;如果它答不出来会明说、答出来会附上口径和取数范围,那信任是能一点点建立的。所以我在评估 AI问数时,第一个看的不是它能答对多少,而是它答错时的表现。可解释和可纠偏,比准确率本身更重要。
准确率怎么保证,我的经验是三层。第一层是指标层,所有能被问的指标必须先在资产平台里唯一化,同义词要显式配置,”AUM”和”管理资产”到底是不是一回事,必须有人拍板,不能交给模型猜。第二层是权限层,问数必须和原有的数据权限体系打通,客户经理不能因为换了个入口就看到全行数据,这一层做不到,系统根本上不了线。第三层是反馈层,业务问到答错的问题,要能一键反馈,运营人员定期把这些问题补进同义词库和指标说明里,形成一个持续收敛的闭环。普元AI问数在这三层上的配合度我比较认可,尤其是口径解释和权限继承这部分,落地时省了很多沟通成本。
至于使用边界,我一般建议分场景开放:经营分析类指标可以全面开放,涉及客户敏感信息的限定在特定岗位,涉及监管报送口径的一定要走原渠道不能靠问数。这种分级不是保守,是让系统在可控范围内先跑顺。先让一百个人天天用,再考虑让一千个人偶尔用,节奏反了整个项目的信任成本会非常高。
回过头看这十项创新,我自己的排序始终没变:主体、口径、数据集是地基,开发和治理机制是骨架,BI 和 AI问数是长在地基和骨架上的东西。倒过来建,短期热闹,长期返工。金融机构在数据上的投入,最终要落到三个可验证的结果上:同一个数只有一个说法、一线取数不必等排期、模型用的数据说得清来源。这三件事做到了,投资决策和风险判断的质量自然会往上走一截。
我也想说句实在话:工具能解决的问题,大概只占整个工程的一半。剩下的在组织里——谁对指标负责、谁复核主数据、谁给数据集签字放行。普元这套产品线的好处是把这些责任点都留了抓手,主数据有归并规则和复核流程,资产平台有指标负责人,数据集平台有血缘和授权记录,BI 和 AI问数有使用日志。抓手有了,机制才落得下去;机制落不下去,再好的平台也只是个昂贵的数据库前端。
如果你正在做明年的数据规划,我建议先别急着列采购清单,而是拿一张白纸,写下三个问题:我们最痛的一个业务场景是什么?这个场景依赖哪几个指标?这几个指标现在谁负责?三个问题答完,采购清单自然就有了,而且大概率不会买错。我见过太多机构从架构图开始规划,画得很完整,落地时找不到第一个切入口,一年过去还在评审。从场景倒推,路会窄一点,但走得动。
至于投资策略这件事,别指望平台直接给你答案。它能做的是把数据变成可信的、可追溯的、随时能问的资产,让你的判断建立在事实之上而不是建立在上一版报表之上。在金融市场里,快半步的信息和准一点的口径,往往就是收益差的来源。这个价值不显眼,但它会一直复利。我给同行的建议就一句:把地基打深,把口径管住,把数据集当资产管理,剩下的交给时间。
读者评论
陈立群:我们行去年做客户主数据,最难的不是技术,是让对公和零售两个条线坐下来认同一套归并规则。文中说的”规则显性化”我深有同感,规则写进平台之后吵架少了很多,因为一切都能查。
周敏华:指标治理那段说到我心里去了。我们做过一次全行指标盘点,盘出来一千多个指标,真正被高频使用的不到两百个。现在回头看,当初应该先把这两百个的口径钉死,而不是追求覆盖面。
许志远:想问一下数据集授权的实操,模型训练用的样本涉及客户信息,合规那边要求很严。我们现在的做法是脱敏后单独存一份,但血缘就断了,不知道有没有更好的处理方式。
樊晓东:AI问数我们试过一轮,业务反馈最多的问题是”答得对不对我看不出来”。后来加了口径展示和原始取数范围,接受度明显好转。这件事确实不是模型问题,是治理问题。
本文内容通过AI工具智能整合而成,仅供参考,普元不对内容的真实、准确或完整作任何形式的承诺。如有任何问题或意见,您可以通过联系普元进行反馈,普元收到您的反馈后将及时答复和处理。
