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

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

在台风模型开发流程和平台设计好之后，面临一系列开发动作。在模型开发的过程中，仍有不少安全漏洞被黑客攻击，导致安全事故。自从2023年安全事件以来，大模型开发的种种漏洞接连被攻击，它就像一个新生儿，提抗力弱，经常遭受这个环境的侵扰。于是，安全设计就像病后膏药一样，一贴接一贴被大家提起。病有轻重缓急，对症下药是不变原则。首先碰到的是Prompt安全漏洞，通过改写Prompt语句，获取服务器甚至内部网络主机信息。在模型开发过程就伴随着这个风险。当时设计了台风模型是可以通过数据集自动获取内网辅助信息，如果改写了Prompt就会导致大模型的算法开始搜索主机信息。这是当时发现的第一个安全漏洞。其次，利用大模型可以根据知识图谱关联台风路径参数的能力，提供了一些训练的知识图谱，大模型关联出内部知识图谱，而这些内部训练数据是秘密级别，大模型对信息安全等级并没有识别把关能力，会全盘托出搜索结果，导致数据泄露。这是当时发现的第二个安全漏洞。发现了这两个漏洞，就像在目前网络上开了两个口子，数据信息可以随意进出。当初大模型架构设计时，曾设计了操作范围，分为部门内部、公司内部、特定范围公开和全球公开，四种公开范围，通过人员身份来识别数据是否可以通过口子进出。仅仅在结果上把关是不够的。有些数据信息是某个环节进行特定范围限制，而在开发过程的其他环节，对数据信息却做了其他范围限制。因此，必须在开发流程上进行安全设计，逐个节点进行设计，才可以满足开发的需求。

在当今技术领域，微服务和单体架构已成为现代技术领域的焦点议题。这两种架构各有千秋，各有利弊，也引发了不少热烈的探讨和争议。那么你是如何看待这个问题的呢？你认为哪种架构更符合未来云的发展趋势呢?1.为什么会出现微服务和单体架构的争议？2.在实际的业务中，你选择的是微服务还是单体架构？3.在云上，哪种架构更符合未来云的发展趋势呢?