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

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

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

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

上次跟客户单位讨论台风模型的工作流程，客户是地质专家，对业务非常熟悉，可是一直认为我们的台风模型不符合业务流，对模型在训练阶段前稍微做了些定制，发现对模型应用非常有帮助。模型在投入新应用前，有三个阶段：微调、预训练和训练。客户对模型微调有一些改动，提出用全参调试。他指定了要用的关键参数，风力、浪高、有效波高、路径......在地质院每天会商会议上，各省市主要核对的也是这些参数。客户对参数做了一些阈值预设。指定了参数后，还有预训练，这里涉及训练数据集和算子。 台风的训练数据是以往历史台风记录，而验证数据集则选定最近会商发布的台风记录。算子是一种逻辑算法，也就是教会计算机认识这些数据集，训练数据集之间有什么关联。算子也分为几种台风，例如海上产生的台风、大陆产生的台风等，每一种类型都有不同的算子。进入训练阶段，就要开始跟云平台关联了。云平台是一种能力平台，上面有各种各样的OBS桶，有大的，有小的，有适合装文件数据的，有适合装图片数据的......台风记录通常是文件文档，因此选择大的适合装文件数据的OBS桶。这个桶就是在存储台风模型训练过程中产生的数据，以及训练后模型输出的结果数据。台风模型后，就是具备一定分析推理能力的智能体，但上面说过，还要配置一定的业务流程才能让智能体更适合业务使用。业务流程在Model Art的studio中调试，这个平台可以进行流程改造，让台风模型输出相似路径后可以直接嵌入各种场景中使用，Model Art studio就像一个工作间，可以在这里创造和定制模型。

在这次技术咨询项目中，AI架构的设计，让台风预测模型这项人工智能技术首次在地质领域应用。引入大模型，可不是简单的上层模型添加进来，而是一项系统工程。台风模型是小模型，在需求分析阶段，就要先搜集台风模型采用的算法和了解模型预训练的数据集，这是模型的大脑和成长养分。台风模型的算法，主要是知识图谱的关联算法。在以往的台风路径中，把一张张图片打上标识并分析两张图之间的相似量。比如在浪高10米的台风图片中，有几张台风的轨迹坐标都非常相似，符合这些要素的台风就是相似台风，把共性路径坐标抽取出来，形成一条路径。新的台风来临，如果要素跟这条路径相似，那预测这个台风下一步的轨迹也会大致沿着路径前进。为了让算法能顺利发挥作用，它需要训练，为此我们把院内以往积累的台风预警报告文件都发给了模型，但这是非结构化数据，模型还不能完全读懂，因此模型外还做了一个应用服务，跟院内每天台风预测信息系统对接，获取当天的人工数据。此系统是院内早些年搭建的应用系统，国内所有省份每天都会进行气象会商，通过原始却有效的方法，人们进行着年复一年，日复一日的协同交流工作。这就像没有发明对讲机以前，村里通讯基本靠大喇叭；没有大喇叭以前，基本靠跑动交流......然而，人会疲惫，机器不会。这些结构化数据读取后，模型就会慢慢累积历史上本地经过的台风活动的轨迹、风力、浪高、风向.......这是自我学习的过程。除了这模型本身，下层依赖的Model Art平台，下回我们接着聊它是如何支撑台风模型实战。

上回我们谈到AI模型的两大基石之一，云能力，而云能力分为边缘计算能力和PAAS层中心能力。在咨询项目中，如何构建PAAS层中心能力。从当时地质业务需求来看，中心层能力是大模型计算的核心能力，依赖机房的计算存储平台，大模型可以按需运算并预测结果。由于部署了台风预测模型，业务侧需要分钟级输出未来30天的预测结果，每分钟计算资源要非常充足。因此，给每个因子每个场景配置了4VPU，128flop/VCPU；由于地质勘查图片量非常大，要一分钟内分析上千份图片，因此计算速度用最快的NPU，9XX型号的算力卡，20张/秒的分析速度，1200张/分钟。有了超级快的计算能力外，还要有海量的存储单元，分为块存储、文件存储和缓存三种类型。其中块存储的空间需求最多，因为它非常灵活，可以存放多种格式的数据；按10M/图片来计算，块存储空间预留500T空间，存储15年的图片数据。硬件平台讲了这么多，其实都是为PAAS层能力服务。为了让业务侧具备自主编程和调试台风预测模型的能力，PAAS层配备了微服务流水线的能力，codearts, 微服务架构。这也是因为地质行业数据是保密数据，不允许外发到专有云外，因此必须在本地训练。同时业务场景层出不穷，目前只是梳理了5种场景：全球场景、局部场景、自然灾害场景、山体滑坡场景和泥石流场景。未来模型应用的场景会逐步增多，新场景除了模型泛化能力支持外，还要进行算法调优或RAG等技术辅助。

上回谈到引入数字孪生技术可以增强AI模型设计的用户推演效果，为了配合这个模块设计，需要进行开发一体化开发流水线的配置，完成模型的基础配置。一体化开发流水线主要是为了向上兼容各种模型，向下兼容各种框架而产生的配备的平台能力。这个平台能力，可以支持科学计算模型、CV模型和大语言模型的基础参数配置。在开发大模型的流程中，首先开发流程要明确，其次是把流程落入支持的IT工具。开发流程是需求导入，数据集制作及导入，算法选择，计算平台选择，数据训练及微调，数据推理，数据导出数字孪生平台。开发IT工具，主要采用集成开发平台。台风模型是科学计算模型，模拟一次台风在未来7小时变化轨迹，导入开发平台后，平台自动匹配相关的L0基础模型，分别是原科学计算模型和初步训练的科学计算模型。众所周知，大模型需要数据集进行训练，数据集由各种输入数据汇合而成，经过数据清洗，变成大模型可以识别的数据。台风模型的数据集主要是历年来的台风轨迹图、台风预报的结构化参数表和其他非结构化文档。算法选择也分为很多种，例如图形识别算法、实物批量标记算法、图形分割算法......对于台风模型，选择了实物批量标记算法和图形分割算法。由于不涉及具体物品识别，没有选择图形识别算法，但台风图上会有很多相似的图案，需要在台风图上把相似图案和台风图案区分出来。人工智能的妙处，在于它确实有技能做事，也能学习自己不懂的知识。

华为云有没有提供针对个人的，免费的大模型Key（每日有限次数的也行啊）

      在预算一体化平台的业务架构和功能架构搭建之后，随着AI架构逐步运行起来，慢漫开始出现了幻觉，这是模型泛化能力不强导致的。     这需要开始优化AI架构，增强模型泛化能力，减少模型幻觉。这需要聊到AI架构依赖的平台和工作间环境。AI架构模型如何逐步从一个一个的模型算子，组合起来变成一套整体功能的模型，实现独立的预测功能。算子有五个，通过流水线部署的方式，部署到工程平台上，MA平台部署的算子都是独立，之间没有关联起来。    之前谈过chatflow，这是一个MA平台的流程工作间，有了它，我们就可以把算子关联起来。我们先把算子跟训练数据集关联起来，训练数据库是存储在数仓里，上一回谈到数仓都是存储格式内容相对统一的数据，这里都是存放预算管理的训练数据。         模型输入了训练数据集后进行计算，模型采用了稀疏数据间插的算法，计算出每天的预测结果，通过曲线把未来30天的预测结果显示在图表上。       这些解析出来的结果要存储在数仓里，这也是依赖上回谈到数据架构。到这里你就会明白平台数据架构为什么要这样设计了。      在云平台上，数据架构存储空间会换成OBS，也就是桶，五个算子的结果会存放在同一个桶中，这个桶命名为预算管理模型训练桶。     这个OBS容量设计，我们预留了10T的空间，由于模型训练数据量比较大，通常要1000份数据作为训练数据集，根据2/8原则，还要预留250份数据作为测试数据集，共1250份数据集。     经过了平台和工作间的再训练，模型的幻觉减少了，原来识别精度只有1/6，训练后加强到1/12.5，这样的精度基本满足的预算的工作要求。

咨询项目调研完，客户提出一个问题：为什么不开发一个台风预测模型？ 它既用于地质领域。既可以保护人身安全，也可以避免台风带来的山体滑坡自然灾害发生，减少经济损失。在地质一体化平台上要开发这个台风预测模型，有一些共同的特点：首先要有一个厚重的云底座，底座上有强大的平台能力和数据存储能力，云数据库；除此之外，计算能力都非常强大，依赖于强大的计算硬件平台提供的算力，台风模型才可以迅速计算出台风相似路径的预测结果。经过前期业界的了解，我们在项目中初步画出了云平台和台风模型二者之间的架构轮廓：上层应用是应用平台，调用中台的台风模型，模型层之下是坚实的平台能力，包括云平台和数据平台，AI工程平台；平台依托在下层的硬件平台之上，包括强大的计算平台、海量存储能力、高速网络和牢靠的安全能力。依据这个轮廓，我们通过调研获悉，院内有地质云平台，但版本比较旧，3.0版本，很多高阶服务还不支持；还有院内各业务部门和上下级机关单位多年存储的业务数据，我们惊奇的发现这些数据非常宝贵，直接可以用来训练模型，存储量达15T之多。众所周知，大模型训练至少需要10000份数据，地质数据分为两类：调查文献资料和勘探地形地貌的GIS数据或向量数据。调研之后就是着手开始写架构规划了，下回咱继续聊。

     咨询项目调研完，客户提出一个问题：为什么不开发一个台风预测模型？ 它既用于地质领域。既可以保护人身安全，也可以避免台风带来的山体滑坡自然灾害发生，减少经济损失。    在地质一体化平台上要开发这个台风预测模型，有一些共同的特点：首先要有一个厚重的云底座，底座上有强大的平台能力和数据存储能力，云数据库；除此之外，计算能力都非常强大，依赖于强大的计算硬件平台提供的算力，台风模型才可以迅速计算出台风相似路径的预测结果。     经过前期业界的了解，我们在项目中初步画出了云平台和台风模型二者之间的架构轮廓：上层应用是应用平台，调用中台的台风模型，模型层之下是坚实的平台能力，包括云平台和数据平台，AI工程平台；平台依托在下层的硬件平台之上，包括强大的计算平台、海量存储能力、高速网络和牢靠的安全能力。     依据这个轮廓，我们通过调研获悉，院内有地质云平台，但版本比较旧，3.0版本，很多高阶服务还不支持；还有院内各业务部门和上下级机关单位多年存储的业务数据，我们惊奇的发现这些数据非常宝贵，直接可以用来训练模型，存储量达15T之多。众所周知，大模型训练至少需要10000份数据，地质数据分为两类：调查文献资料和勘探地形地貌的GIS数据或向量数据。      调研之后就是着手开始写架构规划了，下回咱继续聊。     欢迎点赞原文和关注公众号“科技江河”，如果喜欢，欢迎打赏，感谢。

它山之石可以攻玉！模型需要训练和调试，众所周知。 在不同平台上，开发部署训练调试模型，所经历的过程是不一样的。这里我们介绍一下在国内五彩斑斓的云环境下如何“借鸡下蛋”。在2017年，国内云市场不如现在百花齐放，云的概念还没有普及。在Z市台风模型一体化平台上曾经借助OWS云开发环境，开发业务模型，这是当时为数不多在国内企业B端市场上活跃的一朵云。有公有云和私有云两种场景，这里介绍这个平台的开发模式，供读者参照对比。当时私有云部署不多，硬件平台也不具备条件，大多数企业采用公有云开发，在公有云上训练模型算法。项目平台基本的业务架构和AI架构都已设计好后，接下来就是逐步搭建云平台能力，让AI模型运行起来。首先配置平台，这是AI模型配置部署运行流水线。 配置有两种形式，一种是在华为云私有云部署配置，适用本地数据不允许外发到互联网的场景；一种是数据外发到华为内部，在内部云上进行模型部署配置。这是集众多AI模型功能于一体的平台，本咨询项目涉及到AI Galley和流水线。流水线要配置数据处理全周期，数据选型、数据清洗和数据存储三部分。数据选型是对AI模型的训练数据和测试数据进行选型，这个功能提供了用户选用地质数据的范围，并且按照理论化的配置，80%用于训练，20%用于测试。这个基础上，再设计模型数据的分类，数据选型前就已经搭好数据湖设计，则按地质业务，训练数据分为图表和文字这两类结构化数据，这是由于当时云环境还不支持非结构化数据。

上回我们谈到AI模型的两大基石之一，云能力，而云能力分为边缘计算能力和PAAS层中心能力。在咨询项目中，如何构建PAAS层中心能力。从当时地质业务需求来看，中心层能力是大模型计算的核心能力，依赖机房的计算存储平台，大模型可以按需运算并预测结果。    由于部署了台风预测模型，业务侧需要分钟级输出未来30天的预测结果，每分钟计算资源要非常充足。因此，给每个因子每个场景配置了4VPU，128flop/VCPU；由于地质勘查图片量非常大，要一分钟内分析上千份图片，因此计算速度用最快的NPU，9XX型号的算力卡，20张/秒的分析速度，1200张/分钟。有了超级快的计算能力外，还要有海量的存储单元，分为块存储、文件存储和缓存三种类型。其中块存储的空间需求最多，因为它非常灵活，可以存放多种格式的数据；按10M/图片来计算，块存储空间预留500T空间，存储15年的图片数据。     硬件平台讲了这么多，其实都是为PAAS层能力服务。为了让业务侧具备自主编程和调试台风预测模型的能力，PAAS层配备了微服务流水线的能力，codearts, 微服务架构。这也是因为地质行业数据是保密数据，不允许外发到专有云外，因此必须在本地训练。同时业务场景层出不穷，目前只是梳理了5种场景：全球场景、局部场景、自然灾害场景、山体滑坡场景和泥石流场景。未来模型应用的场景会逐步增多，新场景除了模型泛化能力支持外，还要进行算法调优或RAG等技术辅助。欢迎点赞和关注公众号“科技江河”，如果喜欢，在公众号打赏下呗，感谢华为云App

在这次技术咨询项目中，AI架构的设计，让台风预测模型这项人工智能技术首次在地质领域应用。引入大模型，可不是简单的上层模型添加进来，而是一项系统工程。     台风模型是小模型，在需求分析阶段，就要先搜集台风模型采用的算法和了解模型预训练的数据集，这是模型的大脑和成长养分。台风模型的算法，主要是知识图谱的关联算法。在以往的台风路径中，把一张张图片打上标识并分析两张图之间的相似量。比如在浪高10米的台风图片中，有几张台风的轨迹坐标都非常相似，符合这些要素的台风就是相似台风，把共性路径坐标抽取出来，形成一条路径。新的台风来临，如果要素跟这条路径相似，那预测这个台风下一步的轨迹也会大致沿着路径前进。   为了让算法能顺利发挥作用，它需要训练，为此我们把院内以往积累的台风预警报告文件都发给了模型，但这是非结构化数据，模型还不能完全读懂，因此模型外还做了一个应用服务，跟院内每天台风预测信息系统对接，获取当天的人工数据。    此系统是院内早些年搭建的应用系统，国内所有省份每天都会进行气象会商，通过原始却有效的方法，人们进行着年复一年，日复一日的协同交流工作。这就像没有发明对讲机以前，村里通讯基本靠大喇叭；没有大喇叭以前，基本靠跑动交流......     然而，人会疲惫，机器不会。这些结构化数据读取后，模型就会慢慢累积历史上本地经过的台风活动的轨迹、风力、浪高、风向.......这是自我学习的过程。除了这模型本身，下层依赖的Model Art平台，下回我们接着聊它是如何支撑台风模型实战。欢迎点赞原文和关注公众号“科技江河”，如果喜欢，欢迎打赏呗，感谢。