AI与数据技术在金融机构的落地进展

原创爱分析ifenxi 2023-12-04 18:10

【应用手册】TI 全新MCU及C29内核的电动汽车应用方案 构建AI未来，Arm计算平台无处不在

爱分析自从去年年底，开始与国有银行、股份制银行、头部的城商行交流大模型的落地进展。近期看到已经有开始落地的项目了。

本文主要分享爱分析看到的， AI 和数据技术在金融机构的落地进展，以及从银行决策层领导的视角，是如何看待大模型以及数据技术的。

分享嘉宾｜张扬爱分析联合创始人兼首席分析师

内容已做精简，如需获取专家完整版视频实录和课件，请扫码领取。

整个银行业在 23 年上半年，除了中行收入有接近8%的增长，绝大部分的头部银行收入增速基本上都不高，这可能也是未来一两年的情况。但是在这个情况下，再去看利润的时候，会发现利润仍在增长。去年其实这个情况会更明显，去年银行的利润增长基本上在 10% 以上，但是收入增长可能是个位数。

回归到银行领导关心的业务问题上，其实就是增量在缩小。过去做的消费金融的业务，基本上市场要接触天花板了，之后转去做财富，也碰到天花板了。在这个背景下，领导更关心如何去降本的问题。

降本不一定是简单粗暴的砍人和砍资源，更有意义的其实是，降本之下的精细化运营怎么做。

在服务银行期间，尤其是IT部门向行领导讲业务收益的时候，落脚点会落到精细化运营上。目前很多银行的用数理念已经比较成熟了，头部的国股行，行内差不多 50% - 60% 的人，都需要用数决策。用数决策包括自助的BI，包括直接看报表等，这个渗透率很高。

其次，做数据开发的渗透率也很高。头部银行，每个月数据开发平台的月活会过万，包括数据开发的员工，业务的员工，数据科学家等。所以用数决策的理念已经不用太多强调。在整个过程当中，如何低成本用数，是后面比较重要分享的内容。

另外，除了底层的取数和用数，还会涉及很多的底层技术设施，尤其在服务营销领域的时候。比如邮储银行案例，只有先完成底层标签的精细化，才有可能实现业务的精细化管理。那这些数据基础怎么建设，也需要跟行领导从精细化运营讲起，才能比较细致的讲清楚需求，落地思路等。

上述分享了银行的业务围绕降本目标，使用精细化运营，以数据为抓手，如何协助精细化运营的思路。实际在数据应用建设的过程当中，IT部门会产生很多困惑。

举个例子，搭建一个数据中台，领导一定关心有什么效果， ROI 是什么？除了领导能使用的管理驾驶舱以外，其他的数据应用对领导感知比较低。这里就是底层做了数据能力的建设，但是上层的应用建设，包括数据运营没跟上。总结来说，数据在金融机构落地时，有两个比较大的问题，第一是从行领导角度看 ROI 太低，第二是数据运营跟不上。

再回归到用数的过程中，业务部门经常反馈响应速度太慢，一个数据开发的需求可能要排期到一到两周后。其实这里经常是不得已而为之，因为数据开发工作量很大，数据结构多、系统复杂，导致找数都要找很久，经常找到了又发现是错的，不是业务部门想要的。这里在跟业务部门协作时，涉及如何更好的沟通，才能提高数据的准确性，提高效率，达到及时响应，解决问题的目的。

所以我们建议在实际跟行领导讲之前，可以先找一些数据应用，比如指标平台。原来的管理层驾驶舱都是固定的，那些数据可能跟不上业务变革，有的数据领导已经不看了，如果再开发一个新指标，又要响应很久。但如果是一个指标平台，就有很强的可组合性，响应速度也会增快。尤其指标平台里边有指标库，能使用的指标更多。对于领导来讲，会觉得这个指标平台就是数据中台。这就是比较有效果的落地，领导感知度也比较高。

除了指标平台，DataOps也是关于业务部门快速取数，用数的实践。

DataOps现在实际落地比较少，国股行里边落地项目也还不是很多，这个是我们看到的一个比较好的落地案例。

DataOps核心可以解决两个问题，都跟降本有关。第一，过去分行所有的数据需要T+1时段传到总行，这个过程中相当于存了两份。第二，各个分行都在做自己的数据开发，对于数据的定义和标准就不是完全一致的，导致数据上传到总行后要做二次治理，而且分行之间也不通用，复用性很低。可以发现这当中有大量的资源浪费。

这家股份制银行想解决的问题有两个，首先就是总分行的数据对齐问题，这背后除了数据标准需求外，还有降本的需求。其次就是取数和用数，业务部门和 IT 部门怎么去协作的问题。

当时总行解决这个问题的时候，由于是自上而下想要做的，所以如上图的左边所示：

第一步是建规范，核心是流程和制度的改变。以前的流程都是先数据开发，到一定阶段跑不动了，再去做治理。现在新的方式是先做一个完整的数据标准，不一定是全行级的，针对某个业务域也可以，然后在各个分行落地。解决了数据口径的问题，T+1更新的数据就不会有太多错误。

第二步是针对数据开发的问题，总行做了一个云平台，这个云平台是给所有分行做数据开发用的。在这个云平台中，解决了权限的问题，哪些数据哪些分行能看，哪些不能看，包括跨业务系统调数据的审批等。其次，建立了一套标准数据开发流程，最后分行所有的供应商都要根据统一的开发流程做数据开发，所以最后数据标准都是统一的。

整个项目虽然前期建标准的过程中投入了比较多的人力，但是实际上省去了很多分行自己做数据开发的资源。总体上是一个降本的过程，并且解决了总分行数据流通的问题。

上图右边解决的是取数和用数过程的问题。过去取数和用数需要一两周做完数据开发，最后可能拿到的还不是业务部门需要的。这个过程当中最好办法就是能够基于数据地图，方便快速地找到想要的数，并且能及时地跟业务部门确认是不是需要的数，另外一个比较好的路径就是借鉴之前做的数据开发，分行之间业务部门的需求会有相似之处，思路可以复用，这里主要解决的是业务和 IT沟通的问题。

整体项目做完后，上述的云平台每个月的月活都在万级别，数据作业开发量还是比较大的。这里既解决了降本的问题，又解决了业务部门需要及时数据响应的问题。之前使用一到两周做的数据开发，现在是能够降到天级别的，这样是能够达到敏捷相应的要求的。

实际现在看，银行里做到全行级数据字典的也不多。8 月份兴业银行发布了企业级的数据字典，大概用了500 人 10 个月去构建。类似这种重投入的项目，如果不是自上而下去推进的话，IT部门自己很难推进。

除了DataOps，另外一个银行业比较核心的需求是数据的实时分析。主要涉及流批一体的问题，同样也是与降本提效有关。

降本相关的内容是，过去如果是批处理一套，流处理一套，两个分开去做的话，至少从存储的角度来讲是两大套。换成流批一体的话，整体能够很好的支持上层的应用，另外很核心的是降低了存储的成本和维护的成本。另外流批一体还需要统一计算，主要是解决上层的实时应用场景，尤其偏风控类和营销类。比方说实时订单出来以后，有没有营销机会。风控里，尤其反欺诈会用到。

从行领导的角度去看，基本将大模型作为 AI 的一个延伸技术，基于从产品设计到运营管理的全链路价值链里找应用场景。图中有传统的AI和大模型应用探索性场景的举例，当前比较多集中于市场营销环节，比如客服、营销物料、话术辅助等。

现在看到的一个比较新颖比较好的案例与营销策略相关。比如沉睡客户唤醒场景是绝大部分银行比较头疼的问题。有些银行现在做的是首先把沉睡客户统一放到一个部门，比如放到客服部门，之前通常是人工做了两三套激活策略之后，效果不好，就放弃了。现在可以将整个营销策略作为prompt，放到大模型里，大模型可以给一些新策略出来，靠prompt可以生成一个闭环。

这样做首先策略生成比过去靠人工经验要快很多，其次想验证效果也验证得比较快。最后每一个营销策略都会配大模型自动生成的文案。

比如现在有 2000 万沉睡用户，先做人群圈选分了 10 个组，每组 200 万，做 10 个策略去测试，实际效果不好。现在有了大模型，可以生成可能 100 个甚至更多的策略，这些策略可以映射不同圈选人群。因为它是自动化执行的，在执行过程中可以阶段性地筛选出来一些转化效率好一些的策略。这是以前靠人做不到的一个事情。

所以沉睡客户唤醒的营销策略生成应用，是目前看到的比较贴近核心业务，且业务价值比较大的一个应用。目前这个场景还在验证的阶段。

其次在风控领域，大模型的落地很多是偏贷后报告生成的应用，但实际上生成类的应用价值度比较小，且实际落地时，智能风控方面银行不太会考虑大模型，因为可解释比较弱。现在在尝试的多是偏交易的反欺诈，反欺诈拦截方面，但是目前和传统 AI的区别不大，所以总体来说，风控应该是比较难落地的场景。

另一个落地比较多的场景在运营管理，包括知识库，大模型客服等。

这里面比较有价值的落地场景是跟数据结合，做对话式数据分析。有三个方面能用到大模型，第一是意图识别，第二是取数阶段生成SQL语句，第三是做数据下钻分析。

现在看到的已经落地的对话式数据分析，做的比较好的取数准确率能做到90%，业务部门反馈还比较正常。目前意图识别和生成 SQL 语句已经不难了，但是在下钻分析的时候，问题比较多，比如有一个消费品方向的案例，库存突然少了30万，到底是什么原因。这些还需要人工查，问题是出在数据本身，数据同步，还是计算等方面。

最后分享一个银行大模型的落地案例。