2024年服贸会专题活动之一——“第六届中国金融科技论坛”9月12日-13日在北京举行，主题为：科技赋能——金融业数字化转型与应用。数字金融研究院副院长薛春雨出席并演讲。
薛春雨指出，银行业落地大模型时与通用行业有比较大的区别，需要面临很多挑战点，其中数据安全、数据质量是最突出的挑战点。
“尤其在数据安全方面，在银行这块来说，首先面临着信创的要求，也就是谈到GPT或者外部公有云上的一些大模型，基本上不可能去直接使用的”，薛春雨认为，应该在本地私有化部署，这是跟其他行业最大的区别。
以下为演讲实录：
薛春雨：各位来宾，大家下午好，刚才前面几位嘉宾或多或少都谈到跟大模型相关的东西，我这个主题从实战的角度给大家做一些分享。刚才高首席提到了，大模型在落地过程中跟我们想象中还是有较大区别，我们这一年多的实战取得了一些成绩也遇到了不少挑战，所以今天和大家来分享一下。
从这个图可以看到（PPT图），银行业落地大模型时与通用行业还是有比较大的区别，这里面列了很多挑战点，其中数据安全、数据质量是最突出的点。尤其在数据安全，在银行这块来说，我们首先面临着信创的要求，也就是谈到GPT或者外部公有云上的一些大模型，基本上不可能去直接使用的，所以首先要求是在本地私有化部署，这是跟其他行业最大的区别。
这一年多来，银行业在大模型的场景探索方面有18个大的典型场景，从业务价值和技术可行性两个维度我们能够看到，大部分场景的可行性还是相对弱一些，前四个场景落地相对较多，我们经常谈到的智能投顾、智能风控这些场景，在大模型之前也谈这个东西，大模型有了之后也谈这个东西，但现在来看，这些场景还是一个相对初级阶段。
从整个行业实战情况来看，左边图是今年前半年金融科技产业联盟组织的一个大模型应用案例的评奖，这里面挑了前6个场景，智能问答、代码辅助基本上排前两位。其中智能问答有5-6个银行客户和金融机构做实战。右边是我们公司在将近一年时间里接触到的客户需求，从这里面大家能够看到，排名一样：知识问答和代码生成两块排前两位，代码审计、功能测试、代码转译也是代码生成范畴。所以从整个角度来看，银行业在整个大模型落地时基本上可以理解是在知识问答或者代码生成两个大的场景进行实战。我们经常提到的很多新的业务价值比较高的场景，落地的相对少一些。
然后看一下神州信息的指导思想。大模型的生态体系分为底层的基础大模型、再上一层的行业模型，以及跟企业关联性比较强的企业级大模型和场景大模型，对我们银行来说银行内部大模型也是一个特殊的企业大模型。我们神州信息是从场景大模型切入，比如代码辅助或者知识问答两个场景去切入，逐步由这边沉淀出企业级的大模型。对于下面基础大模型来说，行业内有很多厂商来做的，我们相对更关注生态偏上层，跟金融行业结合比较深的，这是整个大的思路。
在整个这个思路的指导下，我们有五个大的战略来考虑：第一降本增效，第二知识问答，这和行业是一样的。第三对于多种AI技术的融合，智能投顾、智能营销不仅是生成式AI的问题，还有传统的AI算法，这些模型融合在一起解决场景问题，不是单独的生成式来解决的问题。第四、第五相对比较远期一些。
从现阶段回顾我们的年初规划来看，我们原来规划2026年希望达到AIBank目标，现在来看这个目标还要往后延。多种AI技术融合，高首席成熟度曲线大家看到了，现在生成式在最上面，慢慢会经过一段时间的沉淀和磨炼才能产生一定的价值，我们也遇到类似的问题。这是我们整体的规划（PPT图），定义为金融企业级大模型。基础大模型这一层我们并不涉及，银行落地的时候，银行客户可以选择腾讯、阿里、华为这种大厂大模型私有化部署，当然你也可以选择开源大模型，只要满足业务场景需要都可以。但我们更强调基于这个技术大模型之上，面向企业场景去做跟这种大模型相关的行内数据、语料训练及微调这些工作，甚至包括跟传统AI的能力融合。最后在上面体现两个发力点：一个是基于AI的软件研发全生命周期智能体，一个是知识问答智能体。未来我们都希望把这两块发展成智能体目标，但现阶段还没有到这个阶段。在运行平台来说，我们希望有一个智能体的技术平台去支撑上面两个大的一个发展，最终这两个智能体具有为银行内部多种场景提供基础支撑。
下面我拿CodeMaster谈一下我们一些实战的历程。对于CodeMaster来说，定位是企业级软件全生命周期研发的辅助工具，我们通过内部设计文档、需求文档包括现有代码这些数据，包括对银行的业务知识都做了预训练，模型训练完之后，最终是要在设计文档到代码生成、代码到单元测试，还有代码反向去把设计文档去做一个补全或者保鲜的一些环节。当开发软件在开发过程中对代码的问答可以通过这个方面去配合。
从这个过程里面来说，其实整个完整的赋能闭环是这样的，从整个需求开始然后是概要设计、详细设计，每个业务功能点跟代码形成知识库的沉淀，这中间根据沉淀去生成一个代码。过程中代码还要去做单元测试，然后反向进入业务逻辑的归纳和总结，再反向到文档这一块，是一个完整的闭环过程。这个过程中我想强调深蓝色的这个点，我们刚开始想落地的时候就是按照这个体系去执行的，但是你会发现真正落地的时候，我们一般都强调整个完整地方过程需要人机交互，就是需要人的参与，当代码生成的质量稍微弱一些或者达不到你的要求，你可能需要修改，修改完、调整完会把最新知识记录下来。包括单元测试，业务逻辑的归纳同样需要人员修正，这在AI专业领域其实就是数据标注的过程，这个环节一定是不能忽略的，如果忽略了这块会发现它一直在初级阶段。很多客户做的时候，很多相关人员忙得很，顾不上这个事，最后一直在低维度去转，这个是落地过程中非常关键的一个环节。
我们在公司内部去实战的时候，现在在银行核心领域做的比较多，现在在全国同时实施的有小20家核心，我们希望在内部先做一个降本增效，在整个内部全生命周期，从需求差异化分析到整个过程里面，我们刚开始选择的是单元测试、接口测试、设计文档。下一个阶段我们希望正向代码+功能型测试做深度应用。但真正实战过程中还是有很多酸甜苦辣，这里面效果最好的是单元测试，为什么？因为单元测试对于大模型来说输入就只有代码，给你一个代码可以把他的业务逻辑拆分出来，包括分支、判断，自动生成相关的功能单元测试，这个覆盖还是蛮高的。从实操来说基本上能降低开发人员60%左右的工作量。接口测试是从业务功能角度把你的业务功能测完整，所以需要需求文档、设计文档完备，还有接口、数据样例配合，在这层面我们做一定的尝试，现在最多能到10%-20%的贡献度，因为你的设计文档里面是不是写的特别细，能不能把各种关键点、关键分支、算法说的非常清楚，如果这个说不清楚，大模型也不会把你搞出来。所以这个与数据质量有很大关系。还有代码生成，代码生成我们希望你通过设计文档，给代码不断积累，有前期做一些数据标注之后再去做代码正向，效果是很好的。但设计文档跟代码之间的关系需要做前期工作，大模型把你的自然语言描述的需求和设计文档可以学习，可以基于这个生成这个生成那个；代码学习完生成代码也没有问题。但是自然语言描述的业务跟我们开发语言的代码怎么去衔接，这一层必须需要人工配合做很多事情，否则贡献就会有限。
我们还在外部跟一个股份制银行做了联合研发，大家能看到，也是基于行内的开发运行框架之上代码的一个辅助，不是直接生成通用代码的东西。包括跟数据库配套的场景，2SQL的操作做了不少工作，这个从技术角度来说已经达到了，但在行内去推广和真正达到价值产出，路还是比较长的。
我们也在思考，代码生成或者代码辅助这个领域在银行业去落地的时候，确实还是有一些挑战。因为我们从金融科技公司来说，比如我们同时实施一二十家银行的核心，每一个核心降低5%、10%，10个就可以乘10倍的价值贡献。作为银行、一个甲方客户来说，他们每一个系统短时间内只建一次，你的切入点，你的大模型帮助他做这个事时，切入点到底是哪个，你切入某一个业务性建设时，大模型的算力、资源、基础模型再加上业务、内部数据的训练、匹配这些东西，可能比你用传统模式开发出来的成本还要高。关键是在另外再去做的时候也不是完全复制，基础模型是否通用，你的算力可能还要再加，你的语料训练还要再做，要做深度的定制。
对数据质量的问题，一定对你的设计文档、需求文档有非常高的关系，如果你的需求、设计文档质量比较低，或者你描述的东西对于大模型来说达不到要求时需要做很多工作，甚至很多前提要件是不具备的。我们在单元测效果更好，因为只需要代码作为输入，其他输入质量行业内还是比较低的。
最低满意度，行业在AIGC方面来说，对于生成内容的满意度一般来说要达到92%左右的接受度时，基本上才能觉得还OK，想继续用，如果低于这个满意度就不太想用。代码生产这个方面，开发人员也有个数，但肯定是92%，我帮助你提升3%、5%，对项目经理来说没有问题，可以降低工作量，但对于开发人员来说3%、5%就觉得没太大用处，代码生成对g开发人员也有个心理接受度，从现在角度来说基本上能到30%以上，开发人员才会积极地陪你做这个事。
另外，这个模式对传统模式有比较大的冲击，在银行真正做好，涉及到该怎么平衡这两者之间的关系。
长远来说，银行人工智能技术应用落地有很多挑战和风险，但是我们认为AI大模型这个场景、方向没有问题。比如在银行来说，如果基于刚才谈的数字金融角度来看，大模型只是AI里面的一个子集，在银行要全面实现智能化的时候，不仅需要大模型，还需要具体业务场景关联数据量比较小的小模型，甚至传统某个领域的算法，一定要衔接在一起才能共同解决你的问题，不是一个单一问题，是一个面。另外一个，从这个角度来说，我们在应用分布式转型过程中也一样，在行内来说尤其在股份制大行来说，未来一定是一体化、平台化考虑这个问题，你不能说我这个部门用一套，另外一个部门用一套，在AI方面同样未来也可以走向中台考虑，否则就不能形成全行一盘棋的目标。
基于上述的理解，神州信息有一个叫“乾坤”的数智底座。云原生的技术底座为服务、数据和模型算法三个视角提供一个完整的支撑，分别在这三个方面对应三个中台，分布式技术中台、数据中台、AI中台。对应到今天话题，在AI方面来说，我们在AI中台是这样的考虑，也就是对于一个金融客户，或者对我们银行来说，未来不仅要有大模型，还有传统AI模型，我们从人工智能角度上对数据的加工处理，对传统的算法和大模型相关算法的构建，包括训练、评估，再到形成有传统的、大模型相关的模型资产库及其对应的生命周期管理，管起来之后对上述提供各种不同的模型服务，再结合上大模型的提示工程，在上面形成相关业务领域的智能体，再为上面去赋能。这就形成了完整的覆盖大模型、小模型、算法，及平台化的完整布局，这个也是供咱们行业做一个参考。
现在来谈AI中台稍微有点早，工行等大行已经有布局，这方面未来在智能化一定会走的比较靠前。谢谢大家。
新浪声明：所有会议实录均为现场速记整理，未经演讲者审阅，新浪网登载此文出于传递更多信息之目的，并不意味着赞同其观点或证实其描述。
还没有评论，来说两句吧...