机器学习和深度学习模型已广泛应用于电子商务、社交网络、智能汽车、智能安全、金融服务等领域AI软件系统。在该系统中，机器学习和深度学习模型与传统软件模块紧密集成，形成了完整的软件系统。机器学习和深度学习模型具有数据驱动和不确定性的特点，其开发、测试和演变与传统软件模块大不相同。另一方面，如何在软件系统层面设计整体架构，使不同的机器学习和深度学习模型及其不同版本与其他软件模块形成有机整体，实现持续的部署、更新和运维，也是一个需要探索的问题。
针对这些问题，本次微访谈邀请了来自学术界和工业界的多位专家围绕AI讨论软件架构和开发实践的主题，总结行业实践，分析相关技术问题和未来发展方向。
复旦大学计算机科技学院教授
南洋理工大学领导论坛首席教授
讯飞研究院副院长，AI工程院院长
加拿大阿尔伯塔大学副教授
加拿大国家AI战略CIFAR AI Chair
国防科技大学副研究员
鹏城实验室开源研究所技术总师
复旦大学计算机科学技术学院副教授、博士生导师
南京大学计算机系助理研究员
携程旅游研发部算法专家
你能介绍一些你熟悉的典型例子吗？AI软件系统，这些系统采用了哪些机器学习和深度学习模型？实现什么样的能力？机器学习与深度学习模型以及与软件模块的交互与合作关系是什么？机器学习和深度学习模型以及不同版本与其他软件模块之间的组织结构和交互关系（类似于传统的软件设计模式和架构风格）是否存在一些通用的架构模式和策略？
当前AI什么样的软硬件技术栈用于软件系统中的机器学习和深度学习模型开发？形成什么样的技术生态？由此产生的环境和生态依赖AI与传统软件开发中的环境依赖和依赖管理有什么区别？
在企业发展实践中，机器学习和深度学习模型的功能和非功能测试、分析和调试通常采用什么方法和技术？AI软件系统层面的整体测试通常采用什么策略和技术？
AI软件系统，特别是机器学习和深度学习模型，如何评估其效果、提出改进需求、实施改进和更新？AI如何管理软件系统的版本，特别是机器学习和深度学习模型？
在用户端和云端运行AI软件系统通常采用什么样的部署结构和方法？云端的AI软件系统是否采用了流行的云原生和微服务架构？机器学习和深度学习模型如何进行服务包装、部署、动态更新和持续运维管理？动态伸缩、熔断、限流等可用性保障策略广泛应用于云原生和微服务系统AI软件系统有应用吗？
AI软件系统的架构设计及其开发、测试、运维和长期进化存在哪些问题和挑战？AI学术界需要进一步关注和探索软件系统工程的实践？
以人脸匿名系统为例。人脸匿名（Face anonymization or Face De-ID）通过去除原来的人脸ID并生成新的信息ID隐私保护技术在隐私保护软件系统(如街景软件、疲劳驾驶检测软件)和公共数据集(去除敏感性ID广泛应用于信息)。
人脸匿名系统一般采用机器学习或深度学习模型，如人脸检测、人体关键检测和人脸生成。其中，人脸检测是定位人脸区域的位置，方便后续人脸更换；人体关键检测是确定人体关节（头部、肩膀等）的位置，使新生成的人脸与原始人体姿势协调；人脸生成是合成自然逼真的新人脸，替代原始人脸。传统的机器学习模型和深度学习模型可用于人脸检测和人体关键点检测；目前流行的对抗生成网络广泛应用于人脸生成（GAN）。
在人脸匿名系统中，模型之间的互动和合作分为平行关系和串行关系。其中，人脸检测与人体关键点检测并行，相互独立；人脸检测/人体关键点检测与人脸生成串行。前者的输出（去除人脸区域的头部图像和人体关键点坐标）作为后者的先验信息，生成符合先验条件的人脸。
基于深度学习的软件系统根据具体任务有不同的架构模式。以人脸匿名系统为例，最常见的分层模式是表示层、应用层、业务逻辑层、数据访问层，因为它通常是本地操作。该模型用于构建可分解为多组子任务的程序。每个子任务都在一个抽象层，每个层都为更高层提供服务。对于简单的任务，如简单的人脸检测系统，模型可以通过构建端到端的深度学习模型自动学习人脸检测策略。对于复杂的任务，多个模型往往需要相互交互来完成，比如人脸匿名系统中三个模型之间的合作关系。
讯飞在AI这个领域已经做了很多年了，从语音到NLP，再到CV涉及的领域很多，积累了很多AI软件系统。
以语音交互AIUI以系统为例，是一套全双工语音交互解决方案，包括麦克风阵列拾音、语音唤醒、语音识别、语义理解、对话管理、语音合成等核心技术模型，贯穿系统创新理念，实现更自然的人机交互。
在讯飞的AI工程化中，我们分3个阶段。第一阶段是核心引擎工程，将机器学习和深度学习模型转化为能力引擎模块。根据软件版本的管理模式，关注不同版本的新产品feature，bugfix，以及性能优化；第二阶段是平台工程，分为几个部分，第一部分是将能力引擎转化为分布式服务，提供API/SDK快速接入方便，API能力引擎的版本将跟随能力引擎feature映射；第二部分是将多个能力发动机的分布式服务转化为平台，实现无服务架构，适应各种能力发动机。该架构本身将有一个版本号；第三阶段是做大型应用软件项目，如人机交互系统，涉及使用各种能力发动机服务，最终形成新的API/SDK版本。
我们在这些软件系统的开发过程中，整体也是沿用了软件工程中的微服务架构范式，平台化部分参考无服务低代码的范式。
观点讨论
：刘杨老师的这个AI系统的实例已经包含多个模型之间的组合了。后面还可以看下AI模型与软件模块之间的交互关系。
潘青华老师讲的AI应用开发中的微服务架构和低代码很棒，后面可以展开讨论下。
：已经有一些文章看model和框架的关系，尤其是debug的时候做错误定位。这些其实是很难的。
我们早期 (2016~2019)工作主要聚焦在AI模型(Unit Level ) 层面，围绕着Model的质量，可靠性，安全，可解释等进行了一系列初步的探索。2020年开始，我们工作逐步转向关注AI复杂软件系统，也做了一些初步探索也; 对一些典型的AI软件系统有了一些了解。通常，一个AI软件系统会包含多个功能模块与支撑代码（chaining code），通常连接支撑代码一般是传统Rule based软件形式（对数据流进行预处理或后处理，或用来链接模块输入输出）。子功能模块通常根据具体系统任务与功能不同，可以是完全采用AI模型组合，或者是AI模型与传统Rule-based 软件模块结合的方式。
我们初步的了解是AI软件系统大体结构与传统软件既有相似又有不同，相似之处是AI也可以采用多种结构化，模块化构成方式。不同之处是处理的具体子任务模块通常是AI模型比传统软件模块块更具有优势的一些任务(比如，物体分类，障碍物检测)。此外，AI系统也可以采取end-to-end模式，整个系统都是由AI模型组成。
我们在FSE 20的一个初期工作，A First Look at the Integration of Machine Learning Models in Complex Autonomous Driving Systems - A Case Study on Apollo 对百度apollo无人车系统做了一个初步架构的分析与探索。大体架构与工作采取了perception, planning, control等一个流程 (架构如下图所示), 其中 perception 过程中主要用来处理camera, lidar, radar信号感知车载周围环境，一共采用了20余个深度学习模型，模型之间有串联，并联 包括前后信号预处理与后处理，也包括信号整合fusion模块 (比如 Kalman filter)，为后端环境感知（行人感知，障碍物检测，红绿灯检测等）以及planning 与control做支撑。在具体子任务中采取了不同专门设计的AI模型模块，但是预处理与后处理在apollo中也大量采用了大量传统软件方式。另外一种是类似Tesla无人驾驶系统采用的更为激进的做法，感知模块尽量采取end-to-end的方式，这样使得维护起来相对容易，但是也存在AI黑盒带来的安全可靠性等质量层面挑战。
其次，我们也分析了语音语言等交互等系统，比如siri,alex，百度小度，DeepSppech Rasa等一般采取下图架构流程: 从语音识别, 自然语言理解, 语义关联与对应智能反馈文本生成，再到语音合成。每个步骤都是高度AI依赖任务模块，前后各模块子系统通过串接或并行连接，形成复杂复合任务AI软件系统。
此外, 作为智能制造, 工业4.0的重要支撑，我们最近的ICSE-SEIP 2022 工作When Cyber-Physical Systems Meet AI: A Benchmark, an Evaluation, and a Way Forward中对AI-enabled cyber-physical system 尤其涉及到典型重工业领域AI(控制)系统进行了大规模调研，并对AI在智能制造为主的工业领域潜力进行了分析，建立了一套AI-CPS benchmark。 我们发现，在重工业工业过程中，大部场景都对系统质量，安全，可靠性有极高要求. 目前，AI模块一般在智能环境状态预测与智能控制和传统软件模块会采用冗余(Redundancy)方式，并行互补使用，一方面提升系统性能，同时降低安全与可靠性风险。我们也发现，AI软件系统在重工业领域应用还有许多技术值得进一步研究与探索。 比如下面 AI 风力控制系统。如何设计，开发，并为AI-CPS 提供质量，安全可靠性保障或许是一个重要方向。
马老师这个太高级了，我说个简单点的吧。我个人日常也在用，我相信也是大家比较熟悉的，也是现在比较典型的AI软件系统：一类是我们现在常见的例如今日头条、大众点评等结合了UGC系统和推荐系统的这类软件。另外一类是带强化学习、博弈等模块的游戏，比如王者荣耀。里面的AI技术主要提供一个是精准建模用户和内容之间的关系，实现资源个性化推荐等功能。另一类就是模拟真实用户形成智能体，有点像在特点场景下的强人工智能。这些系统应该都是比较典型的人机协作的智能系统。对于模型和软件模块来说，数据其实是桥梁。一个是通过软件功能从用户侧或者系统侧产生各类数据，然后进入到AI模型持续提高模型能力，然后软件再结合模型的输出（比如推荐结果）与实际场景，去服务用户。这样形成一个闭环，其实这个软件、数据、算法与模型这种持续相互作用的模式还是很鲜明的。
观点讨论
：@马雷 AI应用软件应该也存在一些典型的参考架构和设计模式。
刘老师和马老师都提到了AI应用有时候适合采用end-to-end模式，即整个系统都是由一个AI模型组成，有时候适合采用多个模型同时与软件模块组合成完整系统。
另外，AI模型与传统Rule-based 软件模块也可以相互结合使用，后者虽然“智能性”略弱但是应该更加稳定、资源需求更低。
：非常赞同！
：AI系统里应能有不少规则进行模型输出的修正。
：非常赞同，工业界很需要。
：我们在做的一个题目就是把数学方法的决策和AI的决策的结合。这个很有意思。
：同意，对模型行为有更好的理解基础上，可以设计出更加可靠的规则。
：应该可以做一些值范围或取值关系检测，相当于对AI模块加了一点contract检测。
我们目前主要调研了百度无人驾驶系统Apollo和开源对话系统RASA。Apollo使用了基于CNN的模型进行目标检测、基于RNN的模型进行车辆、行人轨迹预测等。RASA使用了基于Transformer的模型进行命名实体识别、意图分类、上下文预测等。
模型之间的交互包括上下游关系与组合使用关系等。前者即一个或多个模型的输出作为后一个或多个模型的输入。后者包括针对不同场景使用不同模型、 以及多个模型的输出被综合使用。例如，Apollo针对不同的红绿灯（横的红绿灯、竖的红绿灯等）切换不同的模型进行识别，并使用Kalman Filter综合LiDAR、camera和 radar的检测障碍物结果。而模型与代码间的交互主要是代码模块对模型输入输出进行预处理与后处理，也有预先编写代码逻辑综合模型输出或根据场景切换模型。
目前我们团队主要在研究四种智能系统：自动驾驶系统，自然语言翻译系统，智能对话系统和语音识别系统。这些系统从架构和设计上各有特点。以智能对话系统和语音识别系统为例，这两种系统中通常采用循环神经网络模型 (RNN)，包括RNN的变体如LSTM,GRU, BiLSTM 等等。RNN模型在智能对话系统中的主要功能是做语句的意图识别和实体槽位填充；RNN模型在语音识别系统中的主要功能是将输入的语音分类成对应的文本单词。对于大部分AI软件系统，机器学习/深度学习模型往往是作为一个核心的分类功能模块，而从系统接收到的数据信号，转化为模型可以读取的数据格式，还需要一系列预处理过程；系统基于模型输出的预测结果生成最终的输出，同样涉及到大量传统软件模块。因此，如果一个AI软件系统中嵌入了一个或多个已经训练好的模型，可以认为是一个或多个封装好的黑盒功能模块，AI软件系统内部的数据预处理模块、智能模型与其他处理模块之间都存在交互和协作关系。而对于自动驾驶系统，则相对更加复杂一些。自动驾驶系统是一个由感知，决策，预测，控制等多个模块组成的复杂系统。其中涉及到智能模块的组件主要是感知、预测、决策部分，其中感知部分相关的，而其中的感知又涉及到雷达，摄像头等传感器。深度学习模型在其中主要扮演的是一个获取外界信息输入的角色。
这是我们当时去调研了Apollo，Autoware等四个开源的自动驾驶系统之后，绘制的自动驾驶系统的reference architecture的图。我们发现这四个自动驾驶系统不仅架构很相似，甚至于包和模块的名字都很接近，但是代码还是有较大的差异。
我介绍下两个AI软件系统。
其中之一是我们携程自主研发的客服机器人背后的对话系统，这套对话系统使用的对话框架和前面的嘉宾提到的开源框架：RASA，有一些相同点和不同点，我们的系统比RASA要早（RASA诞生于2017年，我们的系统诞生于2016年）。
我们的框架更适合企业应用，而RASA更通用，我主要介绍下我们的系统框架：
我们的系统主要有三个模块，NLU，DM和NLG，和RASA类似，整体上将NLU、DM、NLG模块进行了集成，通过pipeline进行功能整合
NLU：自然语言理解，主要包含意图识别和词槽抽取。意图识别，负责将自然语言解析成意图，采用了两种模型，基于预训练模型（比如BERT）的分类模型，和基于预训练模型的匹配模型，根据场景的不同而灵活选择。输入是对话文本，输出是意图的语义表示。词槽抽取，主要采用BERT+CRF，输入是对话文本，输出是词槽。
DM：对话管理，一般分为DST（Dialog State Tracking）和DPL（Dialog Policy Learning）两个子模块。DST接收NLU的结果并跟踪对话状态，DPL接收DST的当前状态并选择接下来采取的action，DST记录action并更新状态
DPL有两种模式，基于规则和基于模型，规则适配于开放式平台，相当于把对话流程控制权交给平台使用方，这种适合对话流程严格控制的场景。基于模型类似于RASA，使用模型来学习对话流程，通俗的讲就是训练一个有监督模型来预测机器人下一步对用户说什么，这种适合对话流程宽松的场景。两种模式适合不同的场景，不能说哪种更好，只能说哪种更合适
NLG：自然语言生成，主要负责答案生成。有三种模式，平台配置答案、知识图谱查询答案和算法生成答案，和对话管理类似，适合不同的场景。
三个模块都有使用机器学习或深度学习模型，在我们的架构里模型全部单独提供服务（RASA同样支持本地模型，也支持接入模型服务），遵从AI即服务的思想，单独在云端部署，即当前流行的微服务(Microservice)架构。
采用这种架构的原因是：
可以将算法建设和系统开发分离，算法迭代更新很快而系统相对稳定。
模型灵活可复用在其他场景。
最重要的一点：模型服务往往是python编写，而携程在线应用是java编写。通过Service Mesh (简单通俗来讲，Service Mesh 是微服务时代的 TCP/IP 协议)，服务可以用任何语言编写，只需和Service Mesh通信即可。
软件开发人员和算法研究人员各有所长，通过这种架构设计，使各发挥所长，高效协作，提高整个系统开发生命周期的开发效率。
模型是如何训练和部署的？
其中之一就是通过EMOSS，EMOSS是基于MLFlow，携程自主研发的系统。因为不是我们团队研发，所以我简单介绍下：
先说下MLFlow主要特点：
支持大部分现有的机器学习库
跟踪实验记录和比较参数和结果
模型打包，跨平台迁移
支持模型远程存储
支持模型管理和部署
提供模型生命周期管理
Tracking Server是MLFlow最核心和关键的组件，相当于模型管理中心。
训练阶段，训练好的模型序列化之后保存到Tracing Server，统一管理。
部署阶段，从Tracking Server下载模型文件并反序列化。
EMOSS在MLFlow基础上改进了模型部署，并增加了水平扩容、性能压测、监控告警和AB测试功能，更加适配于企业应用。
EMOSS的模型可以快速部署运行在docker，这样的好处是可水平扩展。Docker模型集群需要自主运维。
观点讨论
：@冯洋 听起来有点像传统软件工程中的软件产品线了。
： @冯洋 这个可以做对比分析，然后看看哪个系统更靠谱。
： 谢谢刘老师指导~~~我们近期就开展相关工作。
： 可以合作一下，我们有个地图生成工具，可以做黑盒测试用例生成。
： 看起来随着AI在各种软件系统中的深入应用，AI模型之间以及AI模型与软件模块之间都出现了很多典型的组合结构和交互方式，同时AI软件系统也开始大量采用微服务和云原生架构
： EMOSS、MLFlow等平台对AI模型的训练、部署甚至运维都有了支持，看起来AI模型的DevOps和AIOps有点那意思了。
当前AI软件系统采用的软硬件技术栈主要分为算力、数据和计算平台三类。其中算力属于硬件，比如CPU、GPU和TPU等；数据则是训练机器学习和深度学习模型所需要的数据信息，例如著名的ImageNet；计算平台则是运行或部署机器学习和深度学习模型的系统环境，例如TensorFlow、Pytorch、PaddlePaddle等。
Nvidia、Google、Facebook都围绕自家的AI产品形成了各自的技术生态。例如Nvidia以GPU为核心，形成了的技术生态包括：通用并行计算架构CUDA、专为模拟量子电路设计的加速库cuQuantum、用于实时全数据包检测的数据中心安全平台Nvidia Morpheus，用于企业级AI应用和服务的GUI工作流程驱动框架TAO，等等。Google和Facebook分别围绕TensorFlow和Pytorch都形成了各自的一系列技术产品。
环境和生态依赖给AI软件开发带来的困难：
与大厂深度绑定。例如深度学习所需要的算力几乎只能依赖NVIDIA的GPU；计算平台虽然百花齐放，但也都是各大厂商的产品。
开发成本巨大。例如OpenAI 在2020年发布的预训练语言模型GPT-3 具有 1750 亿参数， 训练所用的数据量达到 45TB， 训练费用超过 1200 万美元。
刘老师说的很全面了，我站在讯飞角度说一下我们的现状和问题。
深度学习模型的开发，现在大多数还是依赖英伟达的GPU硬件，不过我们最近这几年也做了很多基于国产AI芯片的训练框架和工具的开发适配工作，比如在华为、寒武纪的AI加速卡上，已经取得了一些阶段性成果。
训练框架方面，讯飞内部会使用自研深度学习框架+各种主流开源框架，例如Pytorch、TF等，而模型推理端的实现跟目标硬件平台强相关，所以我们做了适配很多端NPU的深度神经网络推理引擎，另外我们也积累了语音、图像、NLP等领域的各种算法组件库，现在搭建一个新的AI软件，基本是使用一套框架，集成推理引擎和算法组件库。
不过，不论是端侧NPU还是国产化GPU，现在各家生态不兼容，而且生态还很不完善，导致根据硬件特性优化模型推理实现，有非常多的适配优化工作。
观点讨论
： @刘杨 讲的相当系统。
： 尽早实现多元化支持，尤其对AI底层软件国产生态系统至此太关键了。
：如果有模型大数据，不知道有没有自动模型优化的可能。
：自动模型优化，是一个值得探索的方向，现有的一些方法，还是偏“大力出奇迹”。
前面两位老师已经做了非常全面分析，我这里补充一下。
当前主流AI软件系统中的模型(监督式)开发主要包含了数据收集处理、标记(Labelling)、模型设计与训练等多个流程，训练好的模型对指定输入或场景进行预测与推断(inference)。为了支撑这一过程，目前AI深度学习模型开发一般采取一些主流的深度学习框架，如Tensorflow, PyTorch, PaddlePaddle，Mindspore等。机器学习模型开发过程通常与深度学习较为类似，也采取一些特定的平台框架或Library作为支撑(如Scikit-learn, Weka)。这些框架一方面简化开发流程，与learning library和底层GPU, NPU, CPU等硬件进行交互，形成自上而下的软件Stack (如下图)：
我们近期也开展了一部分针对深度学习框架层面研究。与我们企业伙伴合作过程中，我们发现一个巨大的挑战就是过去几年整个软件Stack各层软件的版本迁移十分迅速，而stack的各层之间的依赖很难适应这种变化，导致版本兼容性比较差 (不同深度学习框架，不同CUDA版本，不同操作系统版本，不同硬件指令集版本等)。比如早期Tensorflow 2.0 比1.0版本进行了很大的调整，导致版本限制和约束明显，早期开发的AI模型很快就会随着新的框架版本迁移变得难以适用。
此外，AI高度的计算图与算子计算或许是和传统软件一个较大的区别，在AI全栈开发过程中，底层指令集和支持的算子也往往会因为企业自身的优势和考量优先选择级逐步开发，所以很容遇到一些模型在一个框架上工作性能指标很高，但是在更换一个框架，平台或者硬件时，包括准确性等性能指标会降低甚至断崖式下降。因此，构建AI stack 软件供应链依赖图谱，对安全，可靠性进行分析或许是一个重要方向。同时，针对深度学习stack设计专门的compiler或许也可以帮助减轻版本兼容问题，并大幅提升AI模型在各个平台与硬件的应用与适应性。
观点讨论
：看来AI模型可迁移性很差。
补充一点吧，现在AI技术栈大概是：芯片-》编译与驱动-》集群-》计算框架-》领域框架-》算法。不同芯片对应的底层计算平台不一样，比如英伟达CUDA、华为昇腾CANN等，再有就是一些推理芯片，刚刚前面的专家也提到了比如寒武纪加速卡等。在此之上就是如何将芯片形成集群的系统软件，进而为用户提供单机多卡、多机多卡等并行训练的能力，以及实现智能计算集群虚拟化后的云服务能力。在上层就是计算框架，比如大家熟悉的pytorch、TensorFlow、paddlepaddle、mindspre等，还有计算框架之上方便编程的编程框架比如Keras、tensorlayer等。这些计算框架会跟硬件相关，比如华为mindspore对于昇腾芯片更友好。在一般意义上的计算框架之上呢，现在出现好的领域算法和模型框架，比如CV、NLP、AutoML等，比如商汤的OpenMMlab、MMDetection等，实现了很多一个领域的一些通用功能，比如图像分割。然后就是各类AI算法、网络与模型这些更广泛的生态。
另外，马老师的图很高级啊。
模型开发主要采用了NVIDIA GPU作为硬件设施，其它也有包括AMD GPU、Google TPU、华为昇腾芯片等。而软件栈自下而上包括操作系统和容器（Linux、Windows、Docker等）、GPU驱动（Nvidia GPU Driver、AMD GPU Driver）、并行计算平台（NVIDIA CUDA、AMD ROCm）、机器学习和深度学习开发加速库（cuDNN、cuFFT、cuBLAS、rocFFT、rocBLAS等）、开发语言运行时库（Python、Javascript、Java等）、DL开发框架（Tensorflow、PyTorch、MindSpore、PaddlePaddle）、以及上层应用和第三方工具库。形成了以GPU硬件平台为中心、Python语言为主流开发语言、以Tensorflow、PyTorch、MindSpore、PaddlePaddle等为流行开发框架的技术生态。
AI软件系统正处于快速增长阶段，不断有新的架构、新的功能、新的技术，从硬件到软件的迭代速度都非常快。厂商新出的硬件所需要的软件，从底层的硬件驱动和开发工具包，到上层的框架和模型代码，都需要AI软件生态版本迭代，快速跟进并支持新的功能，而厂商在快速支持新功能的同时也引入了后向兼容问题。例如，GPU硬件厂商NVIDIA因为GPU的架构不断推陈出新，对自家的显卡定义了“compute capability”用来评估显卡的计算能力，型号为GTX 1080的显卡compute capability为6.1，相应的并行计算平台CUDA如6.5，支持的compute capability范围为1.1到5.x，CUDA 10.0 支持的范围为3.0-7.5。也就是说在使用新的GPU硬件的同时，需要上层软件栈的同步更新才能配合使用。我们也试图在理解和刻画整个软硬件技术栈中的依赖关系，建立软硬件供应链网络进行分析，从而检测AI软件系统对环境依赖的耦合关系，从而预知不同的AI软件版本兼容性给系统带来的影响，包括系统的可靠性和运行结果的准确性。
观点讨论
： 这是Linux AI&DATA基金会的技术栈。
： @余跃 这个太有意思了，未来5年的科研题目都包括了。
： @陈碧欢 最直接的感觉就是发展速度太快了，几个月就一个版本迭代。
各位专家从生态和系统方面都谈得很深入了，我就补充一点：相较于传统软件开发而言，机器学习和深度学习模型的开发工作对技术人员的统计知识、相关的深度学习算法等提出了更高的要求；此外，以Pytorch、Tensorflow为主流的人工智能模型开发框架也是当前连接人工智能软硬件技术栈的一个重要组成部分。
AI系统中智能模型更多的是数据驱动的编程范式，换言之，开发者需要的是根据数据分布、任务类型，结合自身的统计、人工智能技术知识，选择恰当的模型架构与模型迭代方法。
在我们的工作中，AI软件开发与传统软件开发最大的区别在于其构建过程高度依赖于数据。传统软件开发的依赖管理，通常是关注于环境依赖；而AI软件开发的则需要考虑数据依赖。同时，通常情况下，AI软件所依赖的数据量是非常大的，小则几个GB，大则数十个TB（例如雷达点云数据等）。我个人很关注数据方面的问题。我认为数据依赖的管理存在很多问题，例如，数据仓库的维护，清洗；数据的选择，标记等。这些问题也为我们软件工程的研究者带来了新的挑战。目前已经有一些相关的研究，来支撑各种模态数据的管理。
观点讨论
： 我个人认为对数据的依赖，也是基于深度学习的软件系统开发的一个重要依赖因素。对数据的分析，管理，更新等，也是一个直接影响到深度学习系统质量的关键因素。前不久看到了一个study调研结果发现imagenet上也有4%左右的标注错误。这些问题我认为也是需要解决和处理的。
：同意，数据也是AI软件开发非常关注的一块。
： 同意，前几年都过度关注模型，一定程度上忽略了数据。
： 从余老师发的图片上看，数据依赖位于第二层？也有相关的生态正在快速形成并成长。
： 这个好像分了好几个大模块，一层也有几个block。
直观看上去，好像数据是最大的一个block。
前面几位专家基本上已经说的很完整了，我稍微补充几句。
AI软件开发与传统软件开发中的环境依赖和依赖管理的区别：传统软件开发依赖于系统及开发语言，AI软件开发更多依赖于生态。
目前生态很多，AI云平台诞生前：过多的生态使得选型变得困难，没有统一的管理方案。各生态彼此独立，迁移或者更换生态成本高。AI云平台诞生后，解决了上述问题，但各家云平台不互通，所以只能选取一家。较大的公司往往会选择自研，小公司只能采用大公司的平台。
据我们所知，企业开发阶段还没有比较成熟或者标准的测试方法，而且主要是集中在模型级别。可能公司内部有些标准化流程，但是大多数公司还没有形成比较一致或者统一的方法。比如说，大部分公司仍然是基于测试数据来评估性能的。不同公司的测试数据来源可能有区别，有些数据是真实世界收集的，有些数据是标准数据集，有些可能是根据自己的场景生成的（比如语音识别，会生成各种场景的语音信息；无人车会直接在现实场景中去跑）。我们也收到了好多公司的咨询，主要是关于讨论现有的模型测试方法以及是否可以将其加入到公司内部的开发流程中。最近我们就在和新加坡一个做社交APP的公司合作，把我们的一些方法尝试集成到他们的pipline中，使得他们的AI算法有一定的保障。同时我们还在新加坡推进一些关于可信AI标准的制定，也是在尝试标准化这些流程。对于分析和调试，我所了解的目前还是靠人多一点，人去观察数据的好坏，试不同的模型以及参数，通过设置多种实验来去定位问题，比如需要补充哪些数据，需要去掉哪些数据等。
对于AI软件系统的测试，主要是模型的测试，特别是效果、效率这样的非功能性测试，因为软件一旦设计好，功能基本不会改变了，但是模型变化特别频繁，AI模型测试本质上是通过测试集验证模型的效果。AI模型测试与传统软件测试存在着比较大的差异。测试标准的不确定性和结果可解释性是AI模型测试和传统的软件测试主要的差异。传统的软件一般测试人员根据业务特点设计用例，输入输出是比较确定性的，AI模型测试的预期结果则存在着不确定性，不能像传统软件测试用每条用例的对错来衡量系统的正确性。
传统软件测试有一个完备的测试体系，但是AI模型目前没有一个良好的体系来保障它的质量。模型测试有两种不同的思路，一种是偏黑盒测试，在模型上运行验证数据集，计算效果指标（比如召准率，F1-score），这是目前行业主要的测试方法，这种测试主要挑战在于对数据集的把握以及badcase的分析，整体是把模型系统当做一个黑盒子在看待；另外一种是偏白盒测试，例如对抗测试是通过算法对样本增加一些扰动来生成新样本，以达到验证模型安全和鲁棒性的目的,这类白盒测试对验证数据集能很好进行优化和裁剪，同时对badcase的分析更具有针对性。
从另一个视角看，AI软件系统测试有两种，一种是分层的集成验证，包括集成模型后的引擎测试、集成引擎的服务测试和产品端的测试，每一层会有自己的侧重点，这种方式会保障各层的软件质量。另外一种是系统测试，从终态产物进行端到端的测试，这种测试对分层集成测试是一种很好的补充，有时能发现集成测试不能复现的效果问题（麦克风拾音影响等）。这个需要结合产品特点和阶段来综合考量。
观点讨论
： @刘杨 从测试到标准，以后AI软件要认证才能上线。
： 好像企业内部都有自己的AI开发平台，提供研发全生命期的能力保障，例如阿里PAI这样的平台。这是企业内部的工程化能力的体现。我也是准备听听企业专家的介绍，学习一下。
： @潘青华AI测试也有白盒测试方法了， 不过看起来跟传统的软件白盒测试方法还是很不一样的。
： 上次去讯飞参观，其实看到了很多AI的开发与测试工具。
：讯飞内部也有AI研发平台和AI质量平台，基本实现一些流程的自动化。
： @潘青华看来AI软件也存在“集成”相关的bug。
：不过我觉得真正自动化测试还没有实现，需要来自学术界更多的新技术新思想。
： @潘青华其实包括刚刚提到的很关键，数据与数据集，标注数据质量检测的工具和平台。
：潘院长您好，工业界在对AI软件进行系统测试时，如何定义系统的测试覆盖度?因为系统不仅包括一般的代码模块，还有模型模块，会把模型覆盖度与传统的代码覆盖度指标综合考虑吗?
： AI软件的测试覆盖度，更多是我刚才说的，作为模型输入的测试数据， 对于场景的输入的覆盖度。
：好的，基于场景的输入覆盖度就需要领域知识，或者根据系统上线后的真实数据了。
：我理解“模型覆盖度”其实是训练数据和测试数据在概率空间分布的匹配度，我们一般不直接去比较这个
： 潘老师的这个思路太好了！我们后续会往这个方向进行探索。我们目前正在研究“概率空间分布的匹配度”的可行性。
：以前不用深度学习的时候，考虑思考过这个问题，用深度学习之后，这个数据的分布不知道怎么表示了。
： 那如何度量测试的效果好不好了？
： 看最终统计指标。
：在开发每一轮迭代过程中是否有具体，比如指标提升的一些指导和建议呢？ 还是黑盒训练或者finetune一下再看统计指标？
：用开发集调参，黑盒训练，用不可见的测试集评估，不然肯定overfitting。
从学术界来看，目前对单一模型的测试与调试研究很多，而对整个AI软件系统端到端的测试与调试的研究较少。对模型的测试很大一部分是生成有效的测试数据，包括定义度量模型测试充分性的指标、提出新的测试数据生成技术、测试数据集约减技术等。这类测试检测出来的问题基本都是通过模型重训练解决。另外一部分是模型结构问题的检测，试图寻找出需要修改模型结构的问题。有着明确test oracle的模型结构问题包括shape bug、numerical bug，所以已经有一些静态、动态分析的方式去检测。另外一些问题没有那么明确的test oracle，跟ML训练的领域知识比较相关，例如ICSE2021的 AutoTrainer与DeepLocalize检测梯度、损失函数、网络层输出值等训练过程中的指标的异常情况，并提出一些常见的修复方式去尝试修复模型结构。
我最近和一些专家学者探讨关于AI系统质量保障的问题，其中谈到了一些指标的定义，我从这个角度出发讨论这个问题。现在基于机器学习和深度学习的软件质量评估，主要包括正确性和实时性；其中非功能特性包括鲁棒性、安全性、泛化性和可解释性。
正确性是指深度学习模型在规定的条件下、规定的时间内正确的完成预计功能且不引起模型失效或异常的可靠性。实时性是指实时嵌入式系统中，DNN模型推理运行时间应当小于该任务所指定的时限以及系统可以纳入新的数据并实时更新模型。鲁棒性旨在算法模型部分参数略微改变或控制量稍微偏离最优值时，算法仍然保持稳定性和有效性的能力；安全性旨在测试算法模型在受到外界攻击时，能否进行合理的防御和攻击检测；泛化性是指根据有限样本得到的网络模型对其他变量域也有良好的预测能力，验证算法模型在分布规律与训练数据有偏差的测试集上的预测准确性；可解释性是针对算法模型的黑盒特性，评估模型的输出是否具有高置信度，以及输出结果是否可靠。
在对模型进行测试分析时，一般根据模型结构、任务类型、数据格式，基于蜕变关系和领域规则生成大量测试用例，并根据一些预定义指标进行测试和分析。在进行AI软件系统层面上的测试时，一般是将训练好的智能模型封装为黑或者灰盒功能模块，根据系统的功能需求设计测试用例，评估系统的准确性、可靠性、稳定性。
目前的AI系统测试的技术方法还在构架中，近些年来有很多这方面的工作。但是我认为最基础的还是测试指标。当然这方面有很多的工作可以做，目前我们组也投入了大量的精力在这个方面。
我认为AI系统的质量保障，由于其原生的行为不确定性等特性，其质量保障相关工作更加困难；另外一方面，由于其通常被应用于安全攸关领域，其安全性也非常重要。
我个人认为，就AI 系统的测试充分性指标的构建而言，我们就可以从覆盖，多样性等多个角度入手进行分析讨论。
我主要从事NLP领域，所以我只说下工业界在NLP领域的测试
带有深度学习模型的软件测试和传统软件测试的不同在于，深度学习更关注于模型效果测试，即对返回结果的准确率、精确率和召回率（或者别的指标）的测试。因为即使功能上没有问题，但如果模型预测的有很多错的，也无法满足需求。
首先会测试模型在提前准备好的标准测试集上的各项指标，其次会测试各自情况下模型的性能
除了利用测试集进行测试，为了精确还原线上的真实结果，某些情况还需要提供测试窗模拟真实环境进行效果测试，或者采用灰度测试。一般会采用抽样进行测试。
因为测试量巨大，因此会采用一些减少人工的方法，这里举两个非常现实的例子：
1、回归测试，已上线部分，每天定时在生产流量里边拿昨天不同类型的数据，运行模型服务，记录当前返回值和昨日返回值的对比结果
2、针对nlp模型，采用算法批量生成句子，作为测试句子输入，其他参数手动填写，批量跑，把结果输出，给测试工程师验收
观点讨论
： @陈碧欢 同意，感觉是个比较重要的方向。
：冯老师高见，讯飞也是这么考虑的，以前叫AI测试，现在也重新定义了问题，叫AI质量。
： @潘青华 @冯洋AI模型存在不确定性，所以是不是更像是评测而不是测试？因为测试更像是有个确定性的标准，而评测则可以强调评价而非绝对的测试通过或不通过。
：@彭鑫 一般会定义一个达标的标准，就类似质量标准。
：@彭鑫 也可以这么理解，不过我们定义好一个测试集之后，统计数据的指标也可以作标准，从这个统计结果可以代表软件性能。
： 我再追问一个问题：AI系统的系统级测试与传统软件系统的测试有什么区别？AI模型的测试存在不确定性，但到了AI系统级别是不是会更强调确定性？因为AI系统内部有多种AI模型、规则推理等其他补充性的决策模块以及一些异常处理模块，系统整体上会追求与传统软件系统类似的稳定性和确定性。
：这里非常考验测试集的设计能力，是否能覆盖全应用场景。
：@鞠剑勋 回归测试中，上一个版本预测对的但在当前版本预测错了，对于你们来讲是个问题哇？
：@陈碧欢 对于客服来说，需要保证线上给客人的答案的稳定性，保证服务质量，因此错误率不能有很大的波动
：@彭鑫 彭老师高见，我个人认为这方面的测试/评测确实是一个很有意思的问题。目前的AI系统通常都集成了很多防御与适应性增强的机制，我认为在这个机制下，是可以通过设定一个比较高的标准，来完成测试或者评测某个AI系统是否达标，或者说是否健壮。
： @潘青华 我个人认为这个问题有一定挑战难度，我们近期的研究发现现在AI系统的适应性都比较差。
： @鞠剑勋，错误率应该是个整体的概念，但是如果是整体错误率下降但某些个案（如某些具体的问题）上出现原来回答正确现在回答不正确的情况呢？
：每种场景的要求不一样，看具体的需求。如果对于模型预测答案非常严苛，那么需要达到不能有badcase的程度。如果是一个不严格的场景，比如情绪识别，这种情况是允许的。
： 所以会出现，统计指标提升，但是增加一些不可接受的badcase...是个比较麻烦的问题。
：不可接受的badcase可以加入到固定的回归测试集。
：@潘青华 意味着不同的case预测正确与否的价值和重要性是不一样的？这样AI模型评测也许要考虑权重问题了。
：@彭鑫 是的，我们定义有一些错误是一定不能出现的，比如我说不是，识别成是
： 不知道这样做是否可以有些学习到一些badcase规律， 感觉很难完全穷举所有badcase。
@：@马雷 这确实是很多公司面临的挑战，之前也找冯洋博士交流过，希望学术界能有所突破。
我们可以根据传统软件工程思路来看AI软件系统，但是区别于传统软件设计流程，AI 软件系统面临新的挑战，例如AI模型的训练依赖于训练数据和不同的模型机构，AI模型部署到不同的平台上可能需要进行必要的网络压缩。 这些过程都有可能造成AI软件系统的缺陷。 为了使得AI软件系统能够实用落地，在设计流程中，我们主要关注AI软件系统评估、缺陷的分析与检测，及AI软件系统的修复 三个方面问题，并引入特殊的设计来解决AI软件系统特有的问题。例如在AI软件系统评估方面，我们主要是从软件测试思路出发，并考虑物理世界中可能出现的各种真实干扰 （例如，光照、相机成像和数据后处理方法），探索AI模型的鲁棒性评估问题，最终希望构建面向场景和用户定制的AI软件系统评估方法。 在需求和改进方面，我们尝试引入了AI领域最新的技术和理念例如自动化的数据增广和网络结构搜索等。
在AI软件系统版本管理方面，目前，有很多公开的平台，提供了AI模型库和标准测试结果，为广大的科研工作人员提供了方便的测试和实验基础。但是目前的模型库仅仅提供了最终的训练模型并没有提供模型版本管理的功能。区别于传统的软件版本管理，AI软件系统版本的更新应该要考虑训练数据的更新、模型结构的更新、以及训练数据的更新。这也是我们正在做的事情。
这是个好问题。一方面，新的深度神经网络模型在不断的被提出，新的模型优化技术（主动学习、预训练、少样本学习等）也在不断升级，这些演进离不开核心技术的前沿创新突破。另外一方面，基于数据涟漪效应（讯飞习惯的说法）的闭环迭代也是模型效果升级演进的重要一环。这些演进需要依据一些符合应用场景的评价标准来落地到工业界的软件系统中去。评价方法其实需要结合AI技术的应用场景来选择不同当时，举例来说，有时候需要构建贴合实际应用的离线测试集合进行测试验证，有时候需要进行线上的A/B Test，通过统计指标进行定量对比。那么怎么及时发现算法应该需要被改进呢？这个时候还是需要从产品、从用户使用的角度去定期的监测和分析我们已有算法的效果，提出需要改进的问题以及改进方向。
模型的更新与实施，其实和传统的软件系统相似，都需要关注兼容性、稳定性、模型版本等，做好相关的应急预案，比如灰度、回滚等。与传统软件系统相比，特别之处在于，模型结果有一定的不确定性，不是所有的结果都可能会满足用户期望，这是比较常见的情形。这个时候AI软件系统通常需要配套一些“人工干预”模式，以解决少量单点问题，而不似传统系统中直接组件回滚。
观点讨论
：与传统软件新版本往往可以取代老版本不同，AI模型的多个不同版本有时是不是有共存的价值？
：我理解是有的，不过商用一般不敢这么干，多系统融合一般比单系统好，但费钱
：@彭鑫 model和数据都需要做版本控制，数据比model可能更重要
：@潘青华 这个时候AI软件系统通常需要配套一些“人工干预”模式，以解决少量单点问题：这个是不是就是人机协作的智能了？
：如果只是人工干预，我觉得只是 人机协作做到一半，人工干预之后，怎么驱动软件的迭代改进，完成整个迭代过程，才是完整的人机协作智能。
：就是类似的问题人工干预一次，机器举一反三，而不是次次都要靠人。
：是的，对这个问题的认识，我们也是逐步加深的，包括一个不同的人工干预结果如何融合使用。
首先Unit level，模型层面:
机器学习模型与深度学习模型是典型的Data-driven AI开发模式，Data, Source Code, Model 都是重要的软件Artifacts。因此持续演化也涉到Data, Source Code, Model等多个层面，持续演化在AI软件周期中或许比传统软件更加具有挑战。 这里引用EvidentlyAI公司的一个AI模型CI/CD过程中需求的考量和需要解决的各种问题与需求的概括图，比如 Data drift, concept drift 都是目前导致的模型性能下降的常见因素，因此通过演化维护连续提升也是紧急而迫切的需求。具体的评估指标也需要从多个角度，针对各类可能存在的问题与需求，进行迭代式提升。
在连续演化过程中，数据，代码，以及模型架构等或许都需要进行相应的调整，升级与维护。比如，在Matin Fowler近期的个人博客中对演变流程进行了相关讨论与总结，如下图，可以看出，开发，部署，动态监测，与持续的演变提升也是AI软件工程的重要生命周期阶段，同时不同开发阶段，也需要提出特定的各类技术方法，数据与评测指标，比如，数据层面会涉及到 训练数据演化，训练阶段测试数据演化，部署前测试数据变化，部署后实际应用数据检测与变化等等。
从AI System 系统level角度:
根据AI 采取架构的不同，也会存在多种演变方式。
如果采取完整end-to-end的AI模型架构，AI子模块之间通常有较强耦合性，通常可通过一次完整训练或者fine tune进行演化；
如果是类似智能语音系统这样复杂复合的AI系统，存在多个较为独立AI子系统模块，可以对每个模块单独提升；
如果AI系统采用AI模块与传统模块结合的架构，通常也可以采用(2) 的方式，对单模块或者临近相关模块进行组合提升，从而整体提升系统性能。
其中(1) (2) (3)各种架构演化的优缺点也都比较明显，(1) 对于开发维护人员相对容易，不需要对系统模块进行太多手动改动。 (2)(3)中，模块演化过程中一般也会需要临近模块进行相应的手动调整，模块较多的情况会比较难于维护。
AI软件系统尤其模型管理方面，早期也出现了ModelZoo, ModelDepot这样的平台对AI模型进行管理，方便模型搜索，推荐等。 版本管理则需要数据，代码，模型多方面同时从多个粒度进行管理，近期，有了一些初期的工具 比如DVC等在进行相关尝试。
我快速想到的模型演化的方向主要有：
新的数据进来之后，各类参数刷新。
表达能力提升，比如NLP模型中的词表空间，再难一点持续增加参数、或者演化模型结构等。
新的应用场景下，如何有效适配和迁移，如一开始的fine-tuning、prompt等。
部署和应用环境的扩展，模型需要做比如压缩剪枝迁移等。
我们现在在做这样一种版本管理工具，做好了会开源出来：特定的代码或者算法，在特定数据集和运行环境（软硬件环境）下训练部署的模型，在特定测试集上的执行效果（比如AUC、MRR等）。这里其实设计到一组技术的组合，比如代码管理git、git-LFS、数据版本管理DVC等。我们会提供上面提到的《模型：代码、数据、训练环境、测试集》这样的版本。这个网站上面也给出了一些MLOps的思路，感兴趣的同行可以看看。https://ml-ops.org/
观点讨论
： 刚才大家谈到的版本管理似乎更多是训练前的模型和数据等的版本管理。那么训练后的模型是否也有版本管理呢，特别是结合容器化镜像。同一个静态模型是否会有多个训练好的模型备用？
：彭老师说的其实应该有的，训好的模型其实想复现还是挺困难的，应该把整个运行环境也纳入到版本当中。
：嗯，那应该可以连同运行环境一起做容器化镜像了。
：可以参考MLFlow，或者我们的EMOSS。
这个问题应该属于MLOps方向，最近出现了不少开源或商用的MLOps工具，包括KuberFlow、MLFlow等。它们的一个总体思路就是要将系统的每一次变动（包括模型、代码、数据）都进行版本化管理，接入CI/CD流程，自动化模型训练并评估功能与非功能指标，发布后持续监控模型并收集真实场景下的用户交互数据，对异常交互数据进行可解释性分析，从而针对性地改进模型结构或扩增训练数据。
版本管理主要为了可复现，可以对历史版本的指标进行对比并且支持回滚。已有的版本管理工具包括DVC、modelDB、pachyderm等。但是这些工具在实际AI系统中的使用情况还不太清楚，例如Apollo还是指定模型路径后加载模型，这样可能会带来版本管理问题。
观点讨论
：自动化模型训练并评估功能与非功能指标：这个相当于传统软件的CI中的自动构建和自动测试了。
我个人认为AI软件系统由于其核心功能模块往往是通过机器学习算法或者是深度学习算法在特定模型框架与模型算法下，基于大量数据训练构建的，通常被视为一个具有复杂内部逻辑结构的黑盒。因此对于AI软件中的机器学习和深度学习模型部分的迭代与更新，通常会从运算性能与数据分布差异两个角度出发。
AI系统对于已有功能需求，按照算法模型的最新研究发展情况，更改已有的模型结构重新训练并生成具有更强性能的新模型，进而实现核心功能的持续演化。例如，近年来新晋提出的基于自注意力机制的算法模型得到了广泛的关注，其通过减少对于外部环境信息的依赖，对于捕捉数据和特征的内部相关性有着更强的能力，因而实现了在多个文本处理任务上相较于已有方法的显著提升，因此被该领域的AI软件系统广泛应用。
另一方