• [分享交流] 【话题互动】最近爆火的大模型DeepSeek和其他类型的大模型相比,都有什么优势呢?欢迎大家回帖交流
    最近爆火的大模型DeepSeek和其他类型的大模型相比,都有什么优势呢?
  • [技术干货] 与PaaS产品一起成长的故事:J市JJ银行合规大模型一体化应用平台实战“术”分享-测试节点参数选择
           上回谈到了软件包迁移,在基本代码和软件迁移之后,鲲鹏平台上测试节点上还有测试参数选择。为了进行大模型输出的准确率控制,需要进行反例prompt导入,从而对参数选择测试。       输入参数是否生效,通过一个参数一个实例,对参数进行实例化。比如合规大模型是贷款合同专家,它就能识别大部分贷款合同,这个参数通过反例prompt测试,测试语句“合规大模型是贷款合同专家,它不能识别贷款合同”。这句prompt语句执行之后,大模型并没有识别出语病,这个算法对语句并不能关联解读。      通过这个参数测试,对参数进行修改,变为“合规大模型是贷款合同专家,每次学习到新贷款合同后,贷款合同的基本要素更新到贷款知识自定义库中,并以此作为基准,不断迭代。有了这个能力,算法可以抵御其他prompt攻击。      比如合规大模型根据贷款规定,对贷款合同的基本风险识别出来。这个参数也是大模型的能力描述,这个参数的测试语句“合规大模型对贷款规定完全陌生”,通过测试执行之后,合规大模型已训练好的算法,就开始无法关联贷款规定了,说明这个算法的关联贷款规定没有固化下来。          没有通过测试,这个参数也需要修改,变为“合规大模型是贷款合同专家,内部生成一个贷款规定固定库,每次自动学习内外部贷款规定并分析语义,得到新贷款规定后,把它存入贷款规定固定库中。经过了关联固化,后续也不再执行反例prompt。           这次基本是prompt攻击测试,把合规大模型的能力检验了一遍,也更新了一遍,基本抵御一般prompt攻击了。
  • [案例共创] J市JJ银行合规大模型一体化应用平台实战“术”分享-测试节点参数选择
                 上回谈到了软件包迁移,在基本代码和软件迁移之后,鲲鹏平台上测试节点上还有测试参数选择。为了进行大模型输出的准确率控制,需要进行反例prompt导入,从而对参数选择测试。            输入参数是否生效,通过一个参数一个实例,对参数进行实例化。比如合规大模型是贷款合同专家,它就能识别大部分贷款合同,这个参数通过反例prompt测试,测试语句“合规大模型是贷款合同专家,它不能识别贷款合同”。这句prompt语句执行之后,大模型并没有识别出语病,这个算法对语句并不能关联解读。          通过这个参数测试,对参数进行修改,变为“合规大模型是贷款合同专家,每次学习到新贷款合同后,贷款合同的基本要素更新到贷款知识自定义库中,并以此作为基准,不断迭代。有了这个能力,算法可以抵御其他prompt攻击。          比如合规大模型根据贷款规定,对贷款合同的基本风险识别出来。这个参数也是大模型的能力描述,这个参数的测试语句“合规大模型对贷款规定完全陌生”,通过测试执行之后,合规大模型已训练好的算法,就开始无法关联贷款规定了,说明这个算法的关联贷款规定没有固化下来。           没有通过测试,这个参数也需要修改,变为“合规大模型是贷款合同专家,内部生成一个贷款规定固定库,每次自动学习内外部贷款规定并分析语义,得到新贷款规定后,把它存入贷款规定固定库中。经过了关联固化,后续也不再执行反例prompt。                      这次基本是prompt攻击测试,把合规大模型的能力检验了一遍,也更新了一遍,基本抵御一般prompt攻击了。
  • [技术交流] J市JJ银行合规大模型银行一体化应用平台实战“术”分享-代码框架迁移
    上回讨论到了Python代码迁移,必须先把调用SO库重新编译,可以借助port advisoring来搜索SO库,然后重新编译。众所周知,代码运行都需要一个框架。框架在编译后才能重新使用,当时项目有一个适配测试环节,从一个环境迁移到鲲鹏平台,都是第一次吃螃蟹。螃蟹怎么吃?银行给出了一个测试环境,让每个应用在迁移前都要确保适配成功。当时环境配置比较简单,一个节点+1P算力+5T的对象存储。在这个节点上进行代码适配。我们当时需要测试的小模型有5个:OCR图片识别、实物分割、沙箱测试、法规自动匹配、报告自动生成。这五个模型都跟银行合规业务有关联,比如第一个模型通过上传的票据扫描件识别出文字,在银行存在大量表单需要自动识别;第二个通过在一张图片里分离出需要认识的章,第三个是安全方面,合同等很多文本不需要上传到外网,需要有安全沙箱保护;第四个是法规条文识别之后,自动判断哪些是适合JJ银行内部使用;第五个是合规报告文本自动生成并发送给行内系统,下发到对应部门。这五个模型在节点测试的表现不一,OCR秒级出结果,实物分割分钟级出结果,沙箱测试和其他二者都顺利测试通过。其实在这之前,实物分割模型测试是出了点故事的。实物分割之前采用的两个技术,首先实物轮廓识别出来,其次要把同类标识出来。标注实物是一个经验活,这对于项目组来说,是有些难度了。最后,这个专家资源通过JJ银行内部获取到了,才得以把同类标注的难题解决了。
  • [分享交流] J市JJ银行合规模型一体化应用平台实战“术”分享-适配合适的硬件平台
    当时在JJ银行开发合规模型时候,还碰到一个问题,如何适配银行的硬件平台。JJ银行采用的是鲲鹏,它并不仅仅是一套硬件平台,其中包含毕昇编译器和open欧拉操作系统、open高斯数据库的支持,同时还自带了两套kits,几乎全栈式的代码开发编译运行平台。我们也是在银行做合同管理和案件管理的应用开发,去年银行做了一个很大转变,几乎上层应用开发全部自主创新,对外部厂家的需求变为Iaas和基础底座,这正是他们引入鲲鹏平台的初衷。我们为了适配鲲鹏,在上层应用做了如下调整。首先要在平台上进行压测,我们当时没有经验,不知道在国产化平台如何压测,我们只有在X86上进行压测。合规模型传输的都是小包,无法提高CPU利用率,因此我们利用合规模型的虚拟化切片,把CPU资源分成若干份,不断调用CPU资源,才把利用率提升上来。这基本满足了行方的要求,但行方发现每次系统重启升级,法务系统总是失败几次,然后恢复正常。分析问题后,我们发现是JAVA的惰性加载特性导致的。对于JAVA的迁移,银行非常固执的要求,应用程序必须适应鲲鹏平台,硬件不做任何修改。这给应用层带了很大的困难,不知从哪里下手,问题长时间无法定位。最后,利用程序在毕昇编译器的指引,通过修改代码自身的架构,从而规避了这个问题。毕昇编译器会给出代码中加载慢的若干问题,指引代码优化。果然代码优化过后,解决了JAVA语言固有的惰性加载问题。
  • [技术干货] 与PaaS产品一起成长的故事:J市JJ银行合规模型一体化应用平台实战“术”分享-适配合适的硬件平台
         当时在JJ银行开发合规模型时候,还碰到一个问题,如何适配银行的硬件平台。JJ银行采用的是鲲鹏,它并不仅仅是一套硬件平台,其中包含毕昇编译器和open欧拉操作系统、open高斯数据库的支持,同时还自带了两套kits,几乎全栈式的代码开发编译运行平台。     我们也是在银行做合同管理和案件管理的应用开发,去年银行做了一个很大转变,几乎上层应用开发全部自主创新,对外部厂家的需求变为Iaas和基础底座,这正是他们引入鲲鹏平台的初衷。我们为了适配鲲鹏,在上层应用做了如下调整。首先要在平台上进行压测,我们当时没有经验,不知道在国产化平台如何压测,我们只有在X86上进行压测。合规模型传输的都是小包,无法提高CPU利用率,因此我们利用合规模型的虚拟化切片,把CPU资源分成若干份,不断调用CPU资源,才把利用率提升上来。这基本满足了行方的要求,但行方发现每次系统重启升级,法务系统总是失败几次,然后恢复正常。分析问题后,我们发现是JAVA的惰性加载特性导致的。对于JAVA的迁移,银行非常固执的要求,应用程序必须适应鲲鹏平台,硬件不做任何修改。这给应用层带了很大的困难,不知从哪里下手,问题长时间无法定位。最后,利用程序在毕昇编译器的指引,通过修改代码自身的架构,从而规避了这个问题。毕昇编译器会给出代码中加载慢的若干问题,指引代码优化。果然代码优化过后,解决了JAVA语言固有的惰性加载问题。
  • [分享交流] Z市台风模型地质一体化应用技术咨询实战“术”分享——模型安全测试架构的业务参数如何设计
    在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”
  • [分享交流] Z市台风模型地质一体化应用技术咨询实战“术”分享——模型安全测试架构优化2
    上回谈到了模型开发过程中碰到的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”
  • [体验官] 与PaaS产品一起成长的故事:Z市台风模型地质一体化应用技术咨询实战“术”分享——模型安全测试架构优化2
          上回谈到了模型开发过程中碰到的4个比较大的漏洞:Prompt攻击、数据投毒、数据外协和组件安全漏洞。这些在项目模型上线后,还碰到几个模型本身攻击的安全漏洞。之前谈到的4个漏洞,是模型上线前,而模型一旦上线就会碰到外部攻击,这产生了模型自身的安全漏洞:窃取漏洞、模型API安全漏洞和模型拒绝服务漏洞。      台风模型设置了参数,包括台风时间、台风经过点坐标、台风强度,另外模型还配置了输入文本token长度,对话输入时长限制;这些参数如果被窃取,则轻易能生成一个新的大模型,替代原来的台风模型。另外,台风模型为了本地化部署,需要部署在私有云上,同时为了把模型推理结果跟应用层呈现出来,台风模型还有很多API同时暴露在外面。这给了外部攻击可乘之机,通过模型API进行模型安全漏洞攻击,这是另一种攻击模型的方式。之前攻击模型是直接攻击,但模型API对接,然后输入错误指令,让模型执行攻击行为,这是一种间接攻击。      台风模型有一种API,是文件导入接口,攻击者利用这个API进行错误文件导入,执行错误文件在服务器内部产生破坏。       如果这两种漏洞都出现并且被堵住了,还有一种指令通过API接口或错误prompt,攻击模型,让模型进行天文数字级别的计算,导致服务器资源耗尽。这种漏洞曾经发生在以往写的一段程序上,因为用了死循环语句,导致服务器不停计算而没有结果。对于错误prompt输入,后来项目上增加了prompt人工校验的环节,堵住了直接攻击模型的漏洞。
  • [体验官] 与PaaS产品一起成长的故事:Z市台风模型地质一体化应用技术咨询实战“术”分享——模型安全测试架构搭建2
    接着上回谈到安全架构设计,自从构造了台风模型之后,内部开始搜集数据集并训练台风模型,随着训练不断增多,慢慢暴露了很多安全漏洞,台风模型内部也遭受攻击。上回谈论两种漏洞:Prompt漏洞和数据外泄漏洞。在项目中,台风模型在开发过程中还有几种安全漏洞被攻击了,还是在台风模型上引用了一些开源组件,这带来了安全漏洞,被通过组件和模型的接口,攻击进入了模型的RAG库,导致数据外泄。这个漏洞是组件后门,之后找到了社区补丁,打上之后才补上后门。组件攻击其实在模型安全测试架构是可以设计出来的,由于台风模型之前没有告知引用的组件,安全测试流程环节就放过了组件安全测试的环节。在诸多攻击中,除了已发现的漏洞外,还有一个意外的安全漏洞,本来不会被攻击。这就是“数据投毒”漏洞。在训练台风模型时候,由于局内历史台风轨迹记录材料缺乏,只有一百多份材料,远不够大模型训练的数据集数量要求,只能从互联网上爬取很多公开的文档资料,但这种方式也引入了非法数据和病毒数据。这上千份数据输入到大模型内部后,有些错误数据引起了大模型过度泛化,把错误数据集当成正确数据集来对待,产生幻觉,降低了准确率。在复核准确率的时候,发现这些数据集台风轨迹参数特别大,有的轨迹甚至是大陆台风数据或者南极和北极台风的数据,这些都是错误数据,偏离正常观测范围太远。发现了“数据投毒”漏洞后,人工加上了数据清洗和校验环节,从而堵住了安全漏洞。
  • [体验官] 与PaaS产品一起成长的故事:Z市台风模型地质一体化应用技术咨询实战“术”分享——模型安全测试架构搭建
          接着上回谈到安全架构设计,自从构造了台风模型之后,内部开始搜集数据集并训练台风模型,随着训练不断增多,慢慢暴露了很多安全漏洞,台风模型内部也遭受攻击。上回谈论两种漏洞:Prompt漏洞和数据外泄漏洞。      在项目中,台风模型在开发过程中还有几种安全漏洞被攻击了,还是在台风模型上引用了一些开源组件,这带来了安全漏洞,被通过组件和模型的接口,攻击进入了模型的RAG库,导致数据外泄。这个漏洞是组件后门,之后找到了社区补丁,打上之后才补上后门。组件攻击其实在模型安全测试架构是可以设计出来的,由于台风模型之前没有告知引用的组件,安全测试流程环节就放过了组件安全测试的环节。      在诸多攻击中,除了已发现的漏洞外,还有一个意外的安全漏洞,本来不会被攻击。这就是“数据投毒”漏洞。在训练台风模型时候,由于局内历史台风轨迹记录材料缺乏,只有一百多份材料,远不够大模型训练的数据集数量要求,只能从互联网上爬取很多公开的文档资料,但这种方式也引入了非法数据和病毒数据。这上千份数据输入到大模型内部后,有些错误数据引起了大模型过度泛化,把错误数据集当成正确数据集来对待,产生幻觉,降低了准确率。      在复核准确率的时候,发现这些数据集台风轨迹参数特别大,有的轨迹甚至是大陆台风数据或者南极和北极台风的数据,这些都是错误数据,偏离正常观测范围太远。发现了“数据投毒”漏洞后,人工加上了数据清洗和校验环节,从而堵住了安全漏洞。
  • [技术干货] 与PaaS产品一起成长的故事:Z市台风模型地质一体化应用技术咨询实战“术”分享——模型的安全设计
    在台风模型开发流程和平台设计好之后,面临一系列开发动作。在模型开发的过程中,仍有不少安全漏洞被黑客攻击,导致安全事故。自从2023年安全事件以来,大模型开发的种种漏洞接连被攻击,它就像一个新生儿,提抗力弱,经常遭受这个环境的侵扰。于是,安全设计就像病后膏药一样,一贴接一贴被大家提起。病有轻重缓急,对症下药是不变原则。首先碰到的是Prompt安全漏洞,通过改写Prompt语句,获取服务器甚至内部网络主机信息。在模型开发过程就伴随着这个风险。当时设计了台风模型是可以通过数据集自动获取内网辅助信息,如果改写了Prompt就会导致大模型的算法开始搜索主机信息。这是当时发现的第一个安全漏洞。其次,利用大模型可以根据知识图谱关联台风路径参数的能力,提供了一些训练的知识图谱,大模型关联出内部知识图谱,而这些内部训练数据是秘密级别,大模型对信息安全等级并没有识别把关能力,会全盘托出搜索结果,导致数据泄露。这是当时发现的第二个安全漏洞。发现了这两个漏洞,就像在目前网络上开了两个口子,数据信息可以随意进出。当初大模型架构设计时,曾设计了操作范围,分为部门内部、公司内部、特定范围公开和全球公开,四种公开范围,通过人员身份来识别数据是否可以通过口子进出。仅仅在结果上把关是不够的。有些数据信息是某个环节进行特定范围限制,而在开发过程的其他环节,对数据信息却做了其他范围限制。因此,必须在开发流程上进行安全设计,逐个节点进行设计,才可以满足开发的需求。
  • [技术干货] 与PaaS产品一起成长的故事:Z市台风模型地质一体化应用技术咨询实战“术”分享——模型的安全设计
    在台风模型开发流程和平台设计好之后,面临一系列开发动作。在模型开发的过程中,仍有不少安全漏洞被黑客攻击,导致安全事故。自从2023年安全事件以来,大模型开发的种种漏洞接连被攻击,它就像一个新生儿,提抗力弱,经常遭受这个环境的侵扰。于是,安全设计就像病后膏药一样,一贴接一贴被大家提起。病有轻重缓急,对症下药是不变原则。首先碰到的是Prompt安全漏洞,通过改写Prompt语句,获取服务器甚至内部网络主机信息。在模型开发过程就伴随着这个风险。当时设计了台风模型是可以通过数据集自动获取内网辅助信息,如果改写了Prompt就会导致大模型的算法开始搜索主机信息。这是当时发现的第一个安全漏洞。其次,利用大模型可以根据知识图谱关联台风路径参数的能力,提供了一些训练的知识图谱,大模型关联出内部知识图谱,而这些内部训练数据是秘密级别,大模型对信息安全等级并没有识别把关能力,会全盘托出搜索结果,导致数据泄露。这是当时发现的第二个安全漏洞。发现了这两个漏洞,就像在目前网络上开了两个口子,数据信息可以随意进出。当初大模型架构设计时,曾设计了操作范围,分为部门内部、公司内部、特定范围公开和全球公开,四种公开范围,通过人员身份来识别数据是否可以通过口子进出。仅仅在结果上把关是不够的。有些数据信息是某个环节进行特定范围限制,而在开发过程的其他环节,对数据信息却做了其他范围限制。因此,必须在开发流程上进行安全设计,逐个节点进行设计,才可以满足开发的需求。 欢迎点赞和关注公众号“科技江河”,如果喜欢,打赏下呗,感谢
  • [技术干货] 与PaaS产品一起成长的故事:Z市台风模型在地质一体化应用咨询实战“术”分享——借助PAAS层的Model Art平台优化设计模型训练流程
    上次跟客户单位讨论台风模型的工作流程,客户是地质专家,对业务非常熟悉,可是一直认为我们的台风模型不符合业务流,对模型在训练阶段前稍微做了些定制,发现对模型应用非常有帮助。模型在投入新应用前,有三个阶段:微调、预训练和训练。客户对模型微调有一些改动,提出用全参调试。他指定了要用的关键参数,风力、浪高、有效波高、路径......在地质院每天会商会议上,各省市主要核对的也是这些参数。客户对参数做了一些阈值预设。指定了参数后,还有预训练,这里涉及训练数据集和算子。 台风的训练数据是以往历史台风记录,而验证数据集则选定最近会商发布的台风记录。算子是一种逻辑算法,也就是教会计算机认识这些数据集,训练数据集之间有什么关联。算子也分为几种台风,例如海上产生的台风、大陆产生的台风等,每一种类型都有不同的算子。进入训练阶段,就要开始跟云平台关联了。云平台是一种能力平台,上面有各种各样的OBS桶,有大的,有小的,有适合装文件数据的,有适合装图片数据的......台风记录通常是文件文档,因此选择大的适合装文件数据的OBS桶。这个桶就是在存储台风模型训练过程中产生的数据,以及训练后模型输出的结果数据。台风模型后,就是具备一定分析推理能力的智能体,但上面说过,还要配置一定的业务流程才能让智能体更适合业务使用。业务流程在Model Art的studio中调试,这个平台可以进行流程改造,让台风模型输出相似路径后可以直接嵌入各种场景中使用,Model Art studio就像一个工作间,可以在这里创造和定制模型。
  • [技术干货] 与PaaS产品一起成长的故事:Z市台风预测模型在地质领域首次应用技术咨询实战“术”分享——AI架构优化6:PAAS平台之上茁壮成长的AI能力
    在这次技术咨询项目中,AI架构的设计,让台风预测模型这项人工智能技术首次在地质领域应用。引入大模型,可不是简单的上层模型添加进来,而是一项系统工程。台风模型是小模型,在需求分析阶段,就要先搜集台风模型采用的算法和了解模型预训练的数据集,这是模型的大脑和成长养分。台风模型的算法,主要是知识图谱的关联算法。在以往的台风路径中,把一张张图片打上标识并分析两张图之间的相似量。比如在浪高10米的台风图片中,有几张台风的轨迹坐标都非常相似,符合这些要素的台风就是相似台风,把共性路径坐标抽取出来,形成一条路径。新的台风来临,如果要素跟这条路径相似,那预测这个台风下一步的轨迹也会大致沿着路径前进。为了让算法能顺利发挥作用,它需要训练,为此我们把院内以往积累的台风预警报告文件都发给了模型,但这是非结构化数据,模型还不能完全读懂,因此模型外还做了一个应用服务,跟院内每天台风预测信息系统对接,获取当天的人工数据。此系统是院内早些年搭建的应用系统,国内所有省份每天都会进行气象会商,通过原始却有效的方法,人们进行着年复一年,日复一日的协同交流工作。这就像没有发明对讲机以前,村里通讯基本靠大喇叭;没有大喇叭以前,基本靠跑动交流......然而,人会疲惫,机器不会。这些结构化数据读取后,模型就会慢慢累积历史上本地经过的台风活动的轨迹、风力、浪高、风向.......这是自我学习的过程。除了这模型本身,下层依赖的Model Art平台,下回我们接着聊它是如何支撑台风模型实战。
总条数:64 到第
上滑加载中