在过去几年中，自动化机器学习（AUTOML）工具的普及有所增加。机器学习（ML）从业人员使用自动工具来自动化和优化功能工程，模型培训和超参数优化的过程。最近的工作对从业人员使用汽车工具的经验进行了定性研究，并根据其性能和提供的功能比较了不同的汽车工具，但是现有的工作都没有研究在大规模实际项目中使用Automl工具的实践。因此，我们进行了一项实证研究，以了解ML从业者如何在其项目中使用汽车工具。为此，我们在GitHub上托管的大量开源项目存储库中研究了最常用的十大汽车工具及其各自的用法。我们研究的结果表明1）ML从业人员主要使用哪种汽车工具，以及2）使用这些汽车工具的存储库的特征。此外，我们确定了使用Automl工具的目的（例如，模型参数采样，搜索空间管理，模型评估/错误分析，数据/功能转换和数据标记）以及ML管道的阶段（例如功能工程）使用工具。最后，我们报告在同一源代码文件中使用Automl工具的频率。我们希望我们的结果可以帮助ML从业人员了解不同的汽车工具及其使用情况，以便他们可以为其目的选择正确的工具。此外，Automl工具开发人员可以从我们的发现中受益，以深入了解其工具的用法并改善其工具以更好地适合用户的用法和需求。

Recent advances in deep learning (dl) have led to the release of several dl software libraries such as pytorch, Caffe, and TensorFlow, in order to assist machine learning (ml) practitioners in developing and deploying state-of-the-art deep neural networks (DNN), but they are not able to properly cope with limitations in the dl libraries such as testing or data processing. In this paper, we present a qualitative and quantitative analysis of the most frequent dl libraries combination, the distribution of dl library dependencies across the ml workflow, and formulate a set of recommendations to (i) hardware builders for more optimized accelerators and (ii) library builder for more refined future releases. Our study is based on 1,484 open-source dl projects with 46,110 contributors selected based on their reputation. First, we found an increasing trend in the usage of deep learning libraries. Second, we highlight several usage patterns of deep learning libraries. In addition, we identify dependencies between dl libraries and the most frequent combination where we discover that pytorch and Scikit-learn and, Keras and TensorFlow are the most frequent combination in 18% and 14% of the projects. The developer uses two or three dl libraries in the same projects and tends to use different multiple dl libraries in both the same function and the same files. The developer shows patterns in using various deep-learning libraries and prefers simple functions with fewer arguments and straightforward goals. Finally, we present the implications of our findings for researchers, library maintainers, and hardware vendors.

机器学习（ML）研究出版物通常在GitHub上提供开源实现，使他们的受众可以复制，验证甚至扩展机器学习算法，数据集和元数据。但是，到目前为止，关于此类ML研究存储库的协作活动程度知之甚少，特别是（1）此类存储库从叉子获得贡献的程度，（2）此类贡献的性质（即类型，变化），以及（3）变更的性质，这些变化未归还给叉子，这可能代表了错过的机会。在本文中，我们对1,346毫升研究存储库及其67,369叉进行了验证，无论是定量还是定性（通过Hindle等人的构建代码更改的开创性分类法）。我们发现，尽管ML研究存储库是大量分叉的，但只有9％的叉子对叉子存储库进行了修改。后者的42％发送给家长存储库的更改，其中一半（52％）被父家存储库接受。我们对539个贡献的定性分析和378个本地（仅叉）变化，扩展了Hindle等人的分类法，其中一个与ML（数据）相关的新顶级变更类别和15个新的子类别，包括9个ML--特定的（输入数据，输出数据，程序数据，共享，变更评估，参数调整，性能，预处理，模型培训）。虽然没有由叉子造成的更改主要是涉及域特定于域的定制和本地实验（例如，参数调整），但原点ML存储库确实错过了不可忽视的15.4％文档更改的13.6％的功能更改，而功能更改的13.6％和11.4％的错误修复更改。本文中的发现将对从业者，研究人员，工具匠和教育者有用。

如今，由于最近在人工智能（AI）和机器学习（ML）中的近期突破，因此，智能系统和服务越来越受欢迎。然而，机器学习不仅满足软件工程，不仅具有有希望的潜力，而且还具有一些固有的挑战。尽管最近的一些研究努力，但我们仍然没有明确了解开发基于ML的申请和当前行业实践的挑战。此外，目前尚不清楚软件工程研究人员应将其努力集中起来，以更好地支持ML应用程序开发人员。在本文中，我们报告了一个旨在了解ML应用程序开发的挑战和最佳实践的调查。我们合成从80名从业者（以不同的技能，经验和应用领域）获得的结果为17个调查结果;概述ML应用程序开发的挑战和最佳实践。参与基于ML的软件系统发展的从业者可以利用总结最佳实践来提高其系统的质量。我们希望报告的挑战将通知研究界有关需要调查的主题，以改善工程过程和基于ML的申请的质量。

Machine Learning for Source Code (ML4Code) is an active research field in which extensive experimentation is needed to discover how to best use source code's richly structured information. With this in mind, we introduce JEMMA, an Extensible Java Dataset for ML4Code Applications, which is a large-scale, diverse, and high-quality dataset targeted at ML4Code. Our goal with JEMMA is to lower the barrier to entry in ML4Code by providing the building blocks to experiment with source code models and tasks. JEMMA comes with a considerable amount of pre-processed information such as metadata, representations (e.g., code tokens, ASTs, graphs), and several properties (e.g., metrics, static analysis results) for 50,000 Java projects from the 50KC dataset, with over 1.2 million classes and over 8 million methods. JEMMA is also extensible allowing users to add new properties and representations to the dataset, and evaluate tasks on them. Thus, JEMMA becomes a workbench that researchers can use to experiment with novel representations and tasks operating on source code. To demonstrate the utility of the dataset, we also report results from two empirical studies on our data, ultimately showing that significant work lies ahead in the design of context-aware source code models that can reason over a broader network of source code entities in a software project, the very task that JEMMA is designed to help with.

在各个域中应用机器学习（ML）的快速升级导致更多关注ML组件的质量。然后，旨在提高ML组件质量并安全地将其集成到基于ML的系统中的技术和工具的增长。尽管这些工具中的大多数都使用Bugs的生命周期，但没有标准的错误来评估其性能，比较它们并讨论其优势和弱点。在这项研究中，我们首先研究了基于ML的系统中错误的可重复性和可验证性，并显示了每个错误的最重要因素。然后，我们探索在基于ML的软件系统中生成错误基准的挑战，并提供一个错误基准缺陷4ML，该缺陷4ML满足标准基准的所有标准，即相关性，可重复性，公平性，可验证性和可用性。该故障负载基准测试包含ML开发人员在GitHub和堆栈溢出上报告的113个错误，使用两个最受欢迎的ML框架：TensorFlow和Keras。缺陷4ML还解决了基于ML的软件系统软件可靠性工程的重要挑战，例如：1）框架的快速变化，通过为不同版本的框架提供各种错误，2）代码便携性，通过在不同的ML框架中提供相似的错误，3 ）错误可重复性，通过提供有关所需依赖关系和数据的完整信息，以及4）通过介绍指向错误的起源的链接来提供有关所需依赖性和数据的完整信息。基于ML的系统从业人员和研究人员可以评估其测试工具和技术的缺陷4ML。

自主机器人结合了各种技能，形成越来越复杂的行为，称为任务。尽管这些技能通常以相对较低的抽象级别进行编程，但它们的协调是建筑分离的，并且经常以高级语言或框架表达。几十年来，州机器一直是首选的语言，但是最近，行为树的语言在机器人主义者中引起了人们的关注。行为树最初是为计算机游戏设计的，用于建模自主参与者，提供了基于树木的可扩展的使命表示，并受到支持支持模块化设计和代码的重复使用。但是，尽管使用了该语言的几种实现，但对现实世界中的用法和范围知之甚少。行为树提供的概念与传统语言（例如州机器）有何关系？应用程序中如何使用行为树和状态机概念？我们介绍了对行为树中关键语言概念的研究及其在现实世界机器人应用中的使用。我们识别行为树语言，并将其语义与机器人技术中最著名的行为建模语言进行比较。我们为使用这些语言的机器人应用程序挖掘开源存储库并分析此用法。我们发现两种行为建模语言在语言设计及其在开源项目中的用法之间的相似性方面，以满足机器人域的需求。我们为现实世界行为模型的数据集提供了贡献，希望激发社区使用和进一步开发这种语言，相关的工具和分析技术。

背景。机器学习（ML）应用程序的迅速流行已导致对MLOP的兴趣越来越多，即ML启用ML的系统的连续集成和部署（CI/CD）的实践。目标。由于更改不仅可能影响代码，还会影响ML模型参数和数据本身，因此需要扩展传统CI/CD的自动化以管理生产中的模型再培训。方法。在本文中，我们对从GitHub检索的一组启用ML的系统中实施的MLOP实践进行了初步研究，重点是GitHub Action和CML，这是两种解决开发工作流程的解决方案。结果。我们的初步结果表明，在开源GitHub项目中采用MLOPS工作流程目前相当有限。结论。还确定了问题，可以指导未来的研究工作。

社交媒体有可能提供有关紧急情况和突然事件的及时信息。但是，在每天发布的数百万帖子中找到相关信息可能很困难，并且开发数据分析项目通常需要时间和技术技能。这项研究提出了一种为分析社交媒体的灵活支持的方法，尤其是在紧急情况下。引入了可以采用社交媒体分析的不同用例，并讨论了从大量帖子中检索信息的挑战。重点是分析社交媒体帖子中包含的图像和文本，以及一组自动数据处理工具，用于过滤，分类和使用人类的方法来支持数据分析师的内容。这种支持包括配置自动化工具的反馈和建议，以及众包收集公民的投入。通过讨论Crowd4SDG H2020欧洲项目中开发的三个案例研究来验证结果。

GitHub是Internet上最大的开源软件主机。这个大型，可自由访问的数据库吸引了从业人员和研究人员的注意。但是，随着Github的增长的继续，越来越难以导航遍布广泛领域的大量存储库。过去的工作表明，考虑到应用程序域对于预测存储库的普及以及有关项目质量的推理的任务至关重要。在这项工作中，我们建立在先前注释的5,000个GitHub存储库的数据集上，以设计自动分类器，以通过其应用程序域对存储库进行分类。分类器使用最先进的自然语言处理技术和机器学习，根据五个应用程序域从多个数据源和目录存储库中学习。我们用（1）自动分类器贡献，该分类器可以将流行的存储库分配给每个应用程序域，至少具有70％的精度，（2）对该方法在不流行的存储库中的性能进行调查，以及（3）这种方法对这种方法的实际应用程序，用于回答软件工程实践的采用如何在应用程序域之间有何不同。我们的工作旨在帮助GitHub社区确定感兴趣的存储库，并为未来的工作开放有希望的途径，以调查来自不同应用领域的存储库之间的差异。

本文是机器学习操作（MLOPS）区域的概述。我们的目标是通过突出目前的问题和趋势来定义这些系统的操作和组件。在这种情况下，我们展示了不同的工具及其有用性，以提供相应的指导方针。此外，识别了MLOPA和Automl（自动化机器学习）之间的连接，以及如何提出该组合如何工作。

背景：机器学习（ML）系统依靠数据来做出预测，与传统软件系统（例如数据处理管道，服务管道和模型培训）相比，该系统具有许多添加的组件。现有关于软件维护的研究研究了针对不同类型的问题（例如绩效和安全问题）的问题报告需求和解决过程。但是，ML系统具有特定的故障类别，报告ML问题需要特定于域的信息。由于ML和传统软件工程系统之间的特征不同，我们不知道报告需求在多大程度上不同，并且这些差异在多大程度上影响了问题解决过程。目的：我们的目标是调查ML和非ML问题之间分辨率时间的分布以及某些ML问题的分配时间是否存在差异。我们进一步研究了ML问题和非ML问题的修复大小。方法：我们在GitHub的最新活动应用ML项目中提取问题报告，提取请求和代码文件，并使用自动方法过滤ML和非ML问题。我们使用已知的深度学习错误分类法手动标记这些问题。我们测量了受控样本上ML和非ML问题的解决方案的分辨率时间和大小，并比较每个类别的分布。

随着研究人员和从业人员将机器学习应用于越来越多的软件工程问题，他们使用的方法变得更加复杂。许多现代方法都以抽象语法树（AST）或其扩展形式使用内部代码结构：基于路径的表示，复杂的图将AST与其他边缘结合在一起。即使可以使用不同的解析器来从代码中提取AST的过程，但选择解析器对最终模型质量的影响仍然没有研究。此外，研究人员经常省略提取特定代码表示的确切细节。在这项工作中，我们在方法名称预测任务中评估了两个模型，即Code2Seq和Treelstm，由八个不同的解析器用于Java语言。为了将数据制备的过程与不同的解析器统一，我们开发了SuperParser，这是基于Pathminer的多语言解析器 - 不合Snostic库。 SuperParser促进了适用于培训和评估ML模型的数据集的端到端创建，这些模型与源代码中的结构信息合作。我们的结果表明，不同解析器建造的树木的结构和内容各不相同。然后，我们分析这种多样性如何影响模型的质量，并表明两种模型最不合适的解析器之间的质量差距非常重要。最后，我们讨论了解析器的其他功能，研究人员和从业人员在选择解析器时应考虑这些特征，以及对模型质量的影响。 SuperParser代码可在https://doi.org/10.5281/zenodo.6366591上公开获得。我们还发布了Java-Norm，即我们用于评估模型的数据集：https：//doi.org/10.5281/zenodo.6366599。

通过机器学习的人工智能越来越多地用于数字社会。基于机器学习的解决方案带来了巨大的机会，从而创造了“软件2.0”，而且为工程界提供了巨大的挑战。由于数据科学家使用的实验方法在开发机器学习模型时，敏捷是一个重要的特征。在这个主题演讲中，我们讨论了两种当代开发现象，这是机器学习开发的基础，即笔记本界面和MLOPS。首先，我们提出了一种解决方案，可以通过支持对集成开发环境的简单过渡来解决笔记本电脑中工作的一些内在弱点。其次，我们通过在MLOPS语境中引入隐喻障碍和钢筋来提出AI系统的加强工程。基于机器学习的解决方案是动态的本质上，我们认为强化连续工程是质量保证明天可信赖的AI系统。

组织依靠机器学习工程师（MLE）来操作ML，即部署和维护生产中的ML管道。操作ML或MLOP的过程包括（i）数据收集和标记的连续循环，（ii）实验以改善ML性能，（iii）在多阶段部署过程中评估，以及（iv）监视（iv）性能下降。当一起考虑这些责任似乎令人震惊 - 任何人如何进行MLOP，没有解决的挑战，对工具制造商有什么影响？我们对在包括聊天机器人，自动驾驶汽车和金融在内的许多应用程序中工作的18个MLE进行了半结构化的民族志访谈。我们的访谈暴露了三个变量，这些变量控制了生产ML部署的成功：速度，验证和版本。我们总结了成功实验，部署和维持生产绩效的共同实践。最后，我们讨论了受访者的痛点和反图案，对工具设计产生了影响。

Today's software is bloated leading to significant resource wastage. This bloat is prevalent across the entire software stack, from the operating system, all the way to software backends, frontends, and web-pages. In this paper, we study how prevalent bloat is in machine learning containers. We develop MMLB, a framework to analyze bloat in machine learning containers, measuring the amount of bloat that exists on the container and package levels. Our tool quantifies the sources of bloat and removes them. We integrate our tool with vulnerability analysis tools to measure how bloat affects container vulnerabilities. We experimentally study 15 machine learning containers from the official Tensorflow, Pytorch, and NVIDIA container registries under different tasks, (i.e., training, tuning, and serving). Our findings show that machine learning containers contain bloat encompassing up to 80\% of the container size. We find that debloating machine learning containers speeds provisioning times by up to $3.7\times$ and removes up to 98\% of all vulnerabilities detected by vulnerability analysis tools such as Grype. Finally, we relate our results to the larger discussion about technical debt in machine learning systems.

负责任的AI被广泛认为是我们时代最大的科学挑战之一，也是释放AI市场并增加采用率的关键。为了应对负责任的AI挑战，最近已经发布了许多AI伦理原则框架，AI系统应该符合这些框架。但是，没有进一步的最佳实践指导，从业者除了真实性之外没有什么。同样，在算法级别而不是系统级的算法上进行了重大努力，主要集中于数学无关的道德原则（例如隐私和公平）的一部分。然而，道德问题在开发生命周期的任何步骤中都可能发生，从而超过AI算法和模型以外的系统的许多AI，非AI和数据组件。为了从系统的角度操作负责任的AI，在本文中，我们采用了一种面向模式的方法，并根据系统的多媒体文献综述（MLR）的结果提出了负责任的AI模式目录。与其呆在道德原则层面或算法层面上，我们专注于AI系统利益相关者可以在实践中采取的模式，以确保开发的AI系统在整个治理和工程生命周期中负责。负责的AI模式编目将模式分为三组：多层次治理模式，可信赖的过程模式和负责任的逐设计产品模式。这些模式为利益相关者实施负责任的AI提供了系统性和可行的指导。

上下文：测试气味是开发测试用例时采用的亚最佳设计选择的症状。先前的研究证明了它们对测试代码可维护性和有效性的有害性。因此，研究人员一直在提出基于启发式的自动化技术来检测它们。但是，此类探测器的性能仍然有限，并且取决于要调整的阈值。目的：我们提出了基于机器学习来检测四种测试气味的新型测试气味检测方法的设计和实验。方法：我们计划开发最大的手动验证测试气味数据集。该数据集将被利用来训练六个机器学习者，并在跨项目内和跨项目内评估其功能。最后，我们计划将我们的方法与最新的基于启发式的技术进行比较。

机器学习（ML）系统的开发和部署可以用现代工具轻松执行，但该过程通常是匆忙和意思是结束的。缺乏勤奋会导致技术债务，范围蠕变和未对准的目标，模型滥用和失败，以及昂贵的后果。另一方面，工程系统遵循明确定义的流程和测试标准，以简化高质量，可靠的结果的开发。极端是航天器系统，其中关键任务措施和鲁棒性在开发过程中根深蒂固。借鉴航天器工程和ML的经验（通过域名通过产品的研究），我们开发了一种经过验证的机器学习开发和部署的系统工程方法。我们的“机器学习技术准备水平”（MLTRL）框架定义了一个原则的过程，以确保强大，可靠和负责的系统，同时为ML工作流程流线型，包括来自传统软件工程的关键区别。 MLTRL甚至更多，MLTRL为跨团队和组织的人们定义了一个人工智能和机器学习技术的人员。在这里，我们描述了通过生产化和部署在医学诊断，消费者计算机视觉，卫星图像和粒子物理学等领域，以通过生产和部署在基本研究中开发ML方法的几个现实世界使用情况的框架和阐明。

在过去的二十年中，几个机器学习（ML）库已自由使用。许多研究都使用此类图书馆对预测软件工程（SE）任务进行实证研究。但是，使用一个库在另一个库上使用的差异被忽略了，隐含地假设使用这些库中的任何一个都会为用户提供相同或非常相似的结果。本文旨在提高人们对使用不同ML库进行软件开发工作估算（见）时所产生的差异的认识，这是研究最广泛的SE预测任务之一。为此，我们研究了3个最受欢迎的ML开源库（即不同语言）（即Scikit-Learn，Caret和Weka）提供的4个确定性机器学习者。我们进行了一项彻底的实证研究，比较了机器学习者在5个最常见的数据集上的性能，请参见方案（即，盒子内ML和TUNED-ML）以及深入的分析其API的文档和代码。我们的研究结果表明，在总共研究的105例病例中，这3个文库提供的预测平均为95％。在大多数情况下，这些差异明显很大，并且误容最多。每个项目3,000小时。此外，我们的API分析表明，这些库为用户提供了可以操纵参数的不同级别的控制，并且总体上缺乏清晰度和一致性，这可能会误导用户。我们的发现强调，ML库是参观研究的重要设计选择，这可能会导致性能差异。但是，这种差异不足。最后，我们通过强调开放式挑战，对图书馆的开发商以及使用它们的研究人员和从业者提出建议。