上回谈到从JJ银行提出跟随自主创新的时代步伐，响应银监会要求，进行鲲鹏硬件平台替换后，合规大模型应用就开始按照VDBD方法进行咨询调研并开始实施软件适配迁移。    先访谈了蔡总监，项目组获悉JJ银行应用合规大模型的技术系统包括：贷款系统、总线系统、文件存储管理和银监会数据交互系统，贷款系统是业务系统，存有大量业务合同和模板，文件存储管理是大模型输出合同模板存放的地方，总线系统统筹整个JJ银行应用系统总线交互，包括跟办公OA的流程对接交互；而银监会数据交互系统是银行上报接口。    这些技术上有关联的业务系统跟合同系统之间有实时和批处理两种方式。技术系统范围选择完成后，进行业务技术分析。比如贷款系统的合同模板非常混乱无序，需要合同系统对合同模板格式进行规划；总线系统对合同系统交互有性能要求，通过API接口调用，对合规大模型的合同模板生成周期要求不能超过50ms；文件存储管理要求ftp方式进行文件上传，如果大模型产生的合同模板出现峰值，需要合同系统有缓存空间；银监会数据交互系统每天定时调用批处理的数据，合同系统需要跑定时任务把对应数据推到相应接口。    分析后团队内部进行了技术路线选择，目前模型语言是Python写，选择框架是mindspore，当时支持的版本是Python3.7.5，合同模板是业务应用自定义格式，因此采用外采的软件依赖工具包，让采购厂商适配鲲鹏平台；在鲲鹏测试节点上测试，合规大模型生成合同模板时间10ms，满足API调用要求；同时配置适配鲲鹏的轻量open GaussDB，可以自定义批处理任务。     最终，项目组以产品优势的说法，说服了JJ银行接受我们的设计方案。

       上回谈到从JJ银行提出跟随自主创新的时代步伐，响应银监会要求，进行鲲鹏硬件平台替换后，合规大模型应用就开始按照VDBD方法进行咨询调研并开始实施软件适配迁移。       先访谈了蔡总监，项目组获悉JJ银行应用合规大模型的技术系统包括：贷款系统、总线系统、文件存储管理和银监会数据交互系统，贷款系统是业务系统，存有大量业务合同和模板，文件存储管理是大模型输出合同模板存放的地方，总线系统统筹整个JJ银行应用系统总线交互，包括跟办公OA的流程对接交互；而银监会数据交互系统是银行上报接口。     这些技术上有关联的业务系统跟合同系统之间有实时和批处理两种方式。技术系统范围选择完成后，进行业务技术分析。比如贷款系统的合同模板非常混乱无序，需要合同系统对合同模板格式进行规划；总线系统对合同系统交互有性能要求，通过API接口调用，对合规大模型的合同模板生成周期要求不能超过50ms；文件存储管理要求ftp方式进行文件上传，如果大模型产生的合同模板出现峰值，需要合同系统有缓存空间；银监会数据交互系统每天定时调用批处理的数据，合同系统需要跑定时任务把对应数据推到相应接口。     分析后团队内部进行了技术路线选择，目前模型语言是Python写，选择框架是mindspore，当时支持的版本是Python3.7.5，合同模板是业务应用自定义格式，因此采用外采的软件依赖工具包，让采购厂商适配鲲鹏平台；在鲲鹏测试节点上测试，合规大模型生成合同模板时间10ms，满足API调用要求；同时配置适配鲲鹏的轻量open GaussDB，可以自定义批处理任务。     最终，项目组以产品优势的说法，说服了JJ银行接受我们的设计方案。    

     上回谈到把代码、SO库、软件包都迁移过来后，就可以进行重新编译了。在编译前，项目组专门了解一下鲲鹏平台的编译器。这套编译器是分场景编译，场景化编译分为四类：通算场景、安全计算、HPC场景和DPAK场景。     对于本次JJ银行的测试节点，只有一台鲲鹏服务器，不组HPC，是为了测试代码迁移后功能的完整性，也不需要安全计算和DPAK，因此本次选择通算场景化编译。      鲲鹏编译器还有一个硬件加速选项。众所周知，鲲鹏硬件平台是支持CPU超分，1核变成1.5核，利用CPU超分能力，加速计算速度，这个开关打开后，代码运行速度会明显加强。      编译完成后，本次代码迁移主干流程已完成。后续就是在新鲲鹏平台上测试迁移后功能和性能。      回顾前几回讨论，合规大模型迁移涉及面比较广，迁移过程环节比较多，如何在迁移工作和价值呈现上做取舍平衡？       迁移工作工作量太大，迁移面面俱到虽然会增加客户价值，但造成工期过长，迁移成本太大；迁移工作只是单纯完成了功能迁移，但性能下降了，不适应新鲲鹏平台运行，将会导致整个应用功能后续无法正常使用，客户价值降低。     我们如何解决这个问题呢？当时采用VDBD方法，比较好平衡二者。   首先，从客户技术场景选择开始，接着使用场景匹配的技术价值作为目标，然后选择对应价值点进行战略分析，技术分析后再选择对应的方案模式，最后明确双方范围分工。下回我们专门回顾一下本次迁移的VDBD技术实践。

       上回谈到把代码、SO库、软件包都迁移过来后，就可以进行重新编译了。在编译前，项目组专门了解一下鲲鹏平台的编译器。这套编译器是分场景编译，场景化编译分为四类：通算场景、安全计算、HPC场景和DPAK场景。       对于本次JJ银行的测试节点，只有一台鲲鹏服务器，不组HPC，是为了测试代码迁移后功能的完整性，也不需要安全计算和DPAK，因此本次选择通算场景化编译。      鲲鹏编译器还有一个硬件加速选项。众所周知，鲲鹏硬件平台是支持CPU超分，1核变成1.5核，利用CPU超分能力，加速计算速度，这个开关打开后，代码运行速度会明显加强。      编译完成后，本次代码迁移主干流程已完成。后续就是在新鲲鹏平台上测试迁移后功能和性能。      回顾前几回讨论，合规大模型迁移涉及面比较广，迁移过程环节比较多，如何在迁移工作和价值呈现上做取舍平衡？迁移工作工作量太大，迁移面面俱到虽然会增加客户价值，但造成工期过长，迁移成本太大；迁移工作只是单纯完成了功能迁移，但性能下降了，不适应新鲲鹏平台运行，将会导致整个应用功能后续无法正常使用，客户价值降低。     我们如何解决这个问题呢？当时采用VDBD方法，比较好平衡二者。      首先，从客户技术场景选择开始，接着使用场景匹配的技术价值作为目标，然后选择对应价值点进行战略分析，技术分析后再选择对应的方案模式，最后明确双方范围分工。下回我们专门回顾一下本次迁移的VDBD技术实践。

       上回谈到了软件包迁移，在基本代码和软件迁移之后，鲲鹏平台上测试节点上还有测试参数选择。为了进行大模型输出的准确率控制，需要进行反例prompt导入，从而对参数选择测试。       输入参数是否生效，通过一个参数一个实例，对参数进行实例化。比如合规大模型是贷款合同专家，它就能识别大部分贷款合同，这个参数通过反例prompt测试，测试语句“合规大模型是贷款合同专家，它不能识别贷款合同”。这句prompt语句执行之后，大模型并没有识别出语病，这个算法对语句并不能关联解读。      通过这个参数测试，对参数进行修改，变为“合规大模型是贷款合同专家，每次学习到新贷款合同后，贷款合同的基本要素更新到贷款知识自定义库中，并以此作为基准，不断迭代。有了这个能力，算法可以抵御其他prompt攻击。      比如合规大模型根据贷款规定，对贷款合同的基本风险识别出来。这个参数也是大模型的能力描述，这个参数的测试语句“合规大模型对贷款规定完全陌生”，通过测试执行之后，合规大模型已训练好的算法，就开始无法关联贷款规定了，说明这个算法的关联贷款规定没有固化下来。          没有通过测试，这个参数也需要修改，变为“合规大模型是贷款合同专家，内部生成一个贷款规定固定库，每次自动学习内外部贷款规定并分析语义，得到新贷款规定后，把它存入贷款规定固定库中。经过了关联固化，后续也不再执行反例prompt。           这次基本是prompt攻击测试，把合规大模型的能力检验了一遍，也更新了一遍，基本抵御一般prompt攻击了。

             上回谈到了软件包迁移，在基本代码和软件迁移之后，鲲鹏平台上测试节点上还有测试参数选择。为了进行大模型输出的准确率控制，需要进行反例prompt导入，从而对参数选择测试。            输入参数是否生效，通过一个参数一个实例，对参数进行实例化。比如合规大模型是贷款合同专家，它就能识别大部分贷款合同，这个参数通过反例prompt测试，测试语句“合规大模型是贷款合同专家，它不能识别贷款合同”。这句prompt语句执行之后，大模型并没有识别出语病，这个算法对语句并不能关联解读。          通过这个参数测试，对参数进行修改，变为“合规大模型是贷款合同专家，每次学习到新贷款合同后，贷款合同的基本要素更新到贷款知识自定义库中，并以此作为基准，不断迭代。有了这个能力，算法可以抵御其他prompt攻击。          比如合规大模型根据贷款规定，对贷款合同的基本风险识别出来。这个参数也是大模型的能力描述，这个参数的测试语句“合规大模型对贷款规定完全陌生”，通过测试执行之后，合规大模型已训练好的算法，就开始无法关联贷款规定了，说明这个算法的关联贷款规定没有固化下来。           没有通过测试，这个参数也需要修改，变为“合规大模型是贷款合同专家，内部生成一个贷款规定固定库，每次自动学习内外部贷款规定并分析语义，得到新贷款规定后，把它存入贷款规定固定库中。经过了关联固化，后续也不再执行反例prompt。                      这次基本是prompt攻击测试，把合规大模型的能力检验了一遍，也更新了一遍，基本抵御一般prompt攻击了。

      上回谈到合规模型使用了外采的软件包，有部分软件包是国外厂商开发的，在国内鲲鹏平台上从没有编译运行过。这些软件包需要先分析出软件包清单和迁移准备。      软件包清单通过扫描，发现合规模型有15个软件包需要迁移，迁移准备期间需要做镜像。这个镜像包括SWR文件和软件依赖包，这两部分构成同一个Docker镜像，进行一次迁移。15个软件包就打包15个镜像。      打包好镜像后还有一个工序，就是进行硬件平台调试。为了平台测试，提前规划了测试指标和测试参数选择。      软件包主要是合规模型的核心功能调用，因此就上回提到的五个核心场景，分别定义了测试指标。从合同识别功能分析，每张图片识别不超过秒级；合同自动识别涉及文本比对，需要查数据库，因此不超过分钟级；合同内容风险识别，根据标注的条数而定，标注需要靠模型辅助，由于风险点浩如烟海，因此风险点标注是毫秒级；合同外规内化，涉及另一个模型调用，内外规搜索，也不超过分钟级；最后合同模版自动生成，这是一个合成的工作，因此各种测试指标都通过后，才能进入这个环节，不超过分钟级。        定义了测试指标后，还有一个测试参数选择的问题。平台节点只有一个，单机配置鲲鹏平台，双卡710，相当于0.8A100的计算能力，CPU是麒麟。        在实验室，测试数据一般达到7T左右，但是为了测试效率，只能输入1T测试，不然计算能力承载不起模型运算。

         上回讨论到了Python代码迁移，必须先把调用SO库重新编译，可以借助port advisoring来搜索SO库，然后重新编译。众所周知，代码运行都需要一个框架。         框架在编译后才能重新使用，当时项目有一个适配测试环节，从一个环境迁移到鲲鹏平台，都是第一次吃螃蟹。螃蟹怎么吃？银行给出了一个测试环境，让每个应用在迁移前都要确保适配成功。        当时环境配置比较简单，一个节点+1P算力+5T的对象存储。在这个节点上进行代码适配。我们当时需要测试的小模型有5个：OCR图片识别、实物分割、沙箱测试、法规自动匹配、报告自动生成。       这五个模型都跟银行合规业务有关联，比如第一个模型通过上传的票据扫描件识别出文字，在银行存在大量表单需要自动识别；第二个通过在一张图片里分离出需要认识的章，第三个是安全方面，合同等很多文本不需要上传到外网，需要有安全沙箱保护；第四个是法规条文识别之后，自动判断哪些是适合JJ银行内部使用；第五个是合规报告文本自动生成并发送给行内系统，下发到对应部门。        这五个模型在节点测试的表现不一，OCR秒级出结果，实物分割分钟级出结果，沙箱测试和其他二者都顺利测试通过。        其实在这之前，实物分割模型测试是出了点故事的。实物分割之前采用的两个技术，首先实物轮廓识别出来，其次要把同类标识出来。标注实物是一个经验活，这对于项目组来说，是有些难度了。最后，这个专家资源通过JJ银行内部获取到了，才得以把同类标注的难题解决了。

     当时在JJ银行开发合规模型时候，还碰到一个问题，如何适配银行的硬件平台。JJ银行采用的是鲲鹏，它并不仅仅是一套硬件平台，其中包含毕昇编译器和open欧拉操作系统、open高斯数据库的支持，同时还自带了两套kits，几乎全栈式的代码开发编译运行平台。     我们也是在银行做合同管理和案件管理的应用开发，去年银行做了一个很大转变，几乎上层应用开发全部自主创新，对外部厂家的需求变为Iaas和基础底座，这正是他们引入鲲鹏平台的初衷。我们为了适配鲲鹏，在上层应用做了如下调整。首先要在平台上进行压测，我们当时没有经验，不知道在国产化平台如何压测，我们只有在X86上进行压测。合规模型传输的都是小包，无法提高CPU利用率，因此我们利用合规模型的虚拟化切片，把CPU资源分成若干份，不断调用CPU资源，才把利用率提升上来。这基本满足了行方的要求，但行方发现每次系统重启升级，法务系统总是失败几次，然后恢复正常。分析问题后，我们发现是JAVA的惰性加载特性导致的。对于JAVA的迁移，银行非常固执的要求，应用程序必须适应鲲鹏平台，硬件不做任何修改。这给应用层带了很大的困难，不知从哪里下手，问题长时间无法定位。最后，利用程序在毕昇编译器的指引，通过修改代码自身的架构，从而规避了这个问题。毕昇编译器会给出代码中加载慢的若干问题，指引代码优化。果然代码优化过后，解决了JAVA语言固有的惰性加载问题。

有这样的一个业务场景：场景出现了3个并发分支，这个场景是在终端产品上运行，产品硬件资源非常有限，同时有Python和Rust融合编程，Python实现功能，Rust在外层封装并对外提供接口，通过这样的模式，最终完成了场景功能开发。这个场景功能编程的经历，让我对Rust充满期待并非常看好它的未来发展。由于未来根据应用场景的不断涌现，使用Rust语言和其他编程语言混合使用的场景会越来越丰富，甚至在未来三年会有一个爆发式小高潮，因此Rust语言未来会出现井喷式发展趋势。Rust的优势非常多，在我司Rust主要是和C/C++混合的场景应用比较深，例如无线LTE单板软件的开发应用，这种语言对于要求编程安全和资源受限的场景来说，都非常适用的。例如它在安全方面的设计和限制因素，让很多语言的编程安全问题迎刃而解。例如，全局变量限制使用，内存泄漏的检查等，Rust有一套比较完整的机制措施。举了应用场景和Rust优势的例子后，我们来看看这些优势会带来哪些发展机会。机会点1——手机终端产品软件编程。由于手机终端产品的资源非常有限，但手机应用消耗资源会越来越大，这要求软硬件设计非常关注资源占用。对资源占用极度友好的编程语言Rust，它恰好符合这样的条件要求。机会点2——国防JD的软件编程。这是对安全级别要求最高的领域，涉及国家机密，因此选择为编程安全而生的Rust是不二之选。机会点3——未来出现一些超大型超复杂的业务场景，例如航天场景和深海探索场景，很多是复合场景。单一语言不能实现全部功能，需要结合另一种语言，二者融合在一个平台上应用。Rust编译框架适合语言混合使用的优势，让它跟其他编程语言共生，从而应用到超大型超复杂的业务场景。 “我正在参加【案例共创】第1期 书写云产品应用构建开发最佳实践/评测，共创官方文档https://bbs.huaweicloud.com/forum/thread-0217170307934787108-1-1.html”

在PaaS产品的安全架构中，包含了模型的安全架构模块，这块通常是AI架构团队来设计的，这跟PaaS是两个不同的团队，但往往由PaaS统筹在同一份架构设计中。在模型的安全测试中，这个模型有若干业务参数在测试时，需要一些专业测试知识进行测试，尤其是这类的数据很难生成。这些参数包括，海陆架上的海温、海盐、海流、生态指标以及波浪高度，这些测试参数很难测试，输入的数据样本积累很少，也无法在极少参数样本的条件下对模型安全进行测试。这个适合借助云PAAS环境，我们意外地获得了一份模拟数据。这份数据包含了几年的海温、盐、流和生态指标数据，但是这份数据比较稀疏。在设计安全测试架构时候，对参数构成的要求是1公里的分辨率，但是这份数据是100公里的分辨率，远远不满足要求。于是在，在PaaS环境下，利用AI test的工具组件，把测试数据丰富起来，按照间隔密度，在一个分辨率单位内再增加100份数据样本，促使分辨率达到了1公里的密度。这样就解决了数据稀疏的问题，但是还有一个问题，就是模拟数据跟测试范围不一致。模拟数据是各个大陆的零散数据，而Z市的地质院只负责本市地质地形地貌的生态保护，因此需要模拟本市的情况进行调整。于是，在波浪高度的参数数据里进行筛选。本市的波浪高度一般在20米左右，但是其他城市波浪高度分布在10到50米的范围内，于是把波浪数据样本挑出20米左右的样本，作为跟本市数据相符的训练数据。 “我正在参加【案例共创】第1期 书写云产品应用构建开发最佳实践/评测，共创官方文档https://bbs.huaweicloud.com/forum/thread-0217170307934787108-1-1.html”

     在PaaS产品的安全架构中，包含了模型的安全架构模块，这块通常是AI架构团队来设计的，这跟PaaS是两个不同的团队，但往往由PaaS统筹在同一份架构设计中。在模型的安全测试中，这个模型有若干业务参数在测试时，需要一些专业测试知识进行测试，尤其是这类的数据很难生成。      这些参数包括，海陆架上的海温、海盐、海流、生态指标以及波浪高度，这些测试参数很难测试，输入的数据样本积累很少，也无法在极少参数样本的条件下对模型安全进行测试。这个适合借助云PAAS环境，我们意外地获得了一份模拟数据。这份数据包含了几年的海温、盐、流和生态指标数据，但是这份数据比较稀疏。在设计安全测试架构时候，对参数构成的要求是1公里的分辨率，但是这份数据是100公里的分辨率，远远不满足要求。     于是在，在PaaS环境下，利用AI test的工具组件，把测试数据丰富起来，按照间隔密度，在一个分辨率单位内再增加100份数据样本，促使分辨率达到了1公里的密度。      这样就解决了数据稀疏的问题，但是还有一个问题，就是模拟数据跟测试范围不一致。模拟数据是各个大陆的零散数据，而Z市的地质院只负责本市地质地形地貌的生态保护，因此需要模拟本市的情况进行调整。于是，在波浪高度的参数数据里进行筛选。本市的波浪高度一般在20米左右，但是其他城市波浪高度分布在10到50米的范围内，于是把波浪数据样本挑出20米左右的样本，作为跟本市数据相符的训练数据。

上回谈到了模型开发过程中碰到的4个比较大的漏洞：Prompt攻击、数据投毒、数据外协和组件安全漏洞。这些在项目模型上线后，还碰到几个模型本身攻击的安全漏洞。之前谈到的4个漏洞，是模型上线前，而模型一旦上线就会碰到外部攻击，这产生了模型自身的安全漏洞：窃取漏洞、模型API安全漏洞和模型拒绝服务漏洞。台风模型设置了参数，包括台风时间、台风经过点坐标、台风强度，另外模型还配置了输入文本token长度，对话输入时长限制；这些参数如果被窃取，则轻易能生成一个新的大模型，替代原来的台风模型。另外，台风模型为了本地化部署，需要部署在私有云上，同时为了把模型推理结果跟应用层呈现出来，台风模型还有很多API同时暴露在外面。这给了外部攻击可乘之机，通过模型API进行模型安全漏洞攻击，这是另一种攻击模型的方式。之前攻击模型是直接攻击，但模型API对接，然后输入错误指令，让模型执行攻击行为，这是一种间接攻击。台风模型有一种API，是文件导入接口，攻击者利用这个API进行错误文件导入，执行错误文件在服务器内部产生破坏。如果这两种漏洞都出现并且被堵住了，还有一种指令通过API接口或错误prompt，攻击模型，让模型进行天文数字级别的计算，导致服务器资源耗尽。这种漏洞曾经发生在以往写的一段程序上，因为用了死循环语句，导致服务器不停计算而没有结果。对于错误prompt输入，后来项目上增加了prompt人工校验的环节，堵住了直接攻击模型的漏洞。 “我正在参加【案例共创】第1期 书写云产品应用构建开发最佳实践/评测，共创官方文档https://bbs.huaweicloud.com/forum/thread-0217170307934787108-1-1.html”

      上回谈到了模型开发过程中碰到的4个比较大的漏洞：Prompt攻击、数据投毒、数据外协和组件安全漏洞。这些在项目模型上线后，还碰到几个模型本身攻击的安全漏洞。之前谈到的4个漏洞，是模型上线前，而模型一旦上线就会碰到外部攻击，这产生了模型自身的安全漏洞：窃取漏洞、模型API安全漏洞和模型拒绝服务漏洞。      台风模型设置了参数，包括台风时间、台风经过点坐标、台风强度，另外模型还配置了输入文本token长度，对话输入时长限制；这些参数如果被窃取，则轻易能生成一个新的大模型，替代原来的台风模型。另外，台风模型为了本地化部署，需要部署在私有云上，同时为了把模型推理结果跟应用层呈现出来，台风模型还有很多API同时暴露在外面。这给了外部攻击可乘之机，通过模型API进行模型安全漏洞攻击，这是另一种攻击模型的方式。之前攻击模型是直接攻击，但模型API对接，然后输入错误指令，让模型执行攻击行为，这是一种间接攻击。      台风模型有一种API，是文件导入接口，攻击者利用这个API进行错误文件导入，执行错误文件在服务器内部产生破坏。       如果这两种漏洞都出现并且被堵住了，还有一种指令通过API接口或错误prompt，攻击模型，让模型进行天文数字级别的计算，导致服务器资源耗尽。这种漏洞曾经发生在以往写的一段程序上，因为用了死循环语句，导致服务器不停计算而没有结果。对于错误prompt输入，后来项目上增加了prompt人工校验的环节，堵住了直接攻击模型的漏洞。

接着上回谈到安全架构设计，自从构造了台风模型之后，内部开始搜集数据集并训练台风模型，随着训练不断增多，慢慢暴露了很多安全漏洞，台风模型内部也遭受攻击。上回谈论两种漏洞：Prompt漏洞和数据外泄漏洞。在项目中，台风模型在开发过程中还有几种安全漏洞被攻击了，还是在台风模型上引用了一些开源组件，这带来了安全漏洞，被通过组件和模型的接口，攻击进入了模型的RAG库，导致数据外泄。这个漏洞是组件后门，之后找到了社区补丁，打上之后才补上后门。组件攻击其实在模型安全测试架构是可以设计出来的，由于台风模型之前没有告知引用的组件，安全测试流程环节就放过了组件安全测试的环节。在诸多攻击中，除了已发现的漏洞外，还有一个意外的安全漏洞，本来不会被攻击。这就是“数据投毒”漏洞。在训练台风模型时候，由于局内历史台风轨迹记录材料缺乏，只有一百多份材料，远不够大模型训练的数据集数量要求，只能从互联网上爬取很多公开的文档资料，但这种方式也引入了非法数据和病毒数据。这上千份数据输入到大模型内部后，有些错误数据引起了大模型过度泛化，把错误数据集当成正确数据集来对待，产生幻觉，降低了准确率。在复核准确率的时候，发现这些数据集台风轨迹参数特别大，有的轨迹甚至是大陆台风数据或者南极和北极台风的数据，这些都是错误数据，偏离正常观测范围太远。发现了“数据投毒”漏洞后，人工加上了数据清洗和校验环节，从而堵住了安全漏洞。