diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.1 GPT大模型软件开发辅助.md b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.1 GPT大模型软件开发辅助.md index cf3207f1..34cd78c1 100644 --- a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.1 GPT大模型软件开发辅助.md +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.1 GPT大模型软件开发辅助.md @@ -243,13 +243,14 @@ CodeWisdom 是中国复旦大学的软件工程研究团队。我们的研究兴 #### 2. GPT4 生成的代码 -而在 GPT4 上进行相同的尝试，我们发现 GPT4 在面对最初的长篇需求时，就直接按照要求进行了代码的生成。 +而在 GPT4 上进行相同的尝试，我们发现 GPT4 在面对最初的长篇需求时，就直接按照要求进行了代码的生成。以下是 GPT4 的回复。 -```java +```txt 由于篇幅有限，我将为您提供部分功能的代码实现，并给出实现思路，您可以参考这些代码和思路来实现其它功能。 首先，创建实体类，包括 User、College、Major、Course 等。 - +``` +```java User.java: @Entity @@ -270,7 +271,8 @@ public class Major{ @ManyToOne private Major major; } - +``` +```java College.java: @Entity @@ -283,7 +285,8 @@ public class College{ @OneToMany(mappedBy = "college") private List majors; } - +``` +```java Major.java: @Entity @@ -296,7 +299,8 @@ public class Major{ @ManyToOne private College college; } - +``` +```java Course.java: @Entity @@ -319,16 +323,17 @@ public class Course { @ManyToOne private User techer; } - +``` +```java 然后，创建相应的 Repository 接口，继承在JpaRepository: public interface UserRepository extends JpaRepository{} public interface CollegeRepository extends JpaRepository{} public interface MajorRepository extends JpaRepository{} public interface CourseRepository extends JpaRepository{} - +``` +```java 接下来，创建相应的 Service 接口及其实现类： - public interface UserService{ // ... } @@ -337,7 +342,8 @@ public interface UserService{ public class UserServiceImpl implements UserService{ // ... } - +``` +```java 创建相应的Controller类，处理HTTP请求： @RestController @@ -347,9 +353,9 @@ public class UserController{ private UserService userService; // ... } - +``` +```java 以个人信息维护功能为例，在UserService接口和UserServiceImpl实现类中添加get和update方法： - public interface UserService{ User getUser(Long id); User updateUser(Long id, User user); @@ -378,9 +384,9 @@ public class UserServiceImpl implements UserService{ return userRepository.save(existingUser); } } - +``` +```java 在UserController类中添加相应的HTTP处理方法： - @RestController @RequestMapping("/api") public class UserController{ @@ -466,13 +472,15 @@ GPT4 不仅进行了完成了从需求分析、设计、实体抽取到代码框 spring-boot-starter-data-redis - +``` +```java 2. 在application的properties中配置Redis连接信息 properties: spring.redis.host=localhost spring.redic.post=6379 - +``` +```java 3. 在你的Spring Boot主类或者一个配置类上，添加@EnableCaching注解以启用缓存 @EnableCaching @@ -482,7 +490,8 @@ public class Application{ SpringApplication.run(Application.class, args); } } - +``` +```java 4. 配置Redis做为缓存管理器 @Configuration @@ -497,7 +506,8 @@ public class CacheConfig{ .cacheDefaults(redicCC).build(); } } - +``` +```java 5. 在需要缓存的方法上添加@Cacheable注解。例如，对一个学生信息查询方法添加缓存： @Service diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.3 软件行业的混合办公模式.md b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.3 软件行业的混合办公模式.md index eedc8a13..cccfab2b 100644 --- a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.3 软件行业的混合办公模式.md +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.3 软件行业的混合办公模式.md @@ -1,9 +1,9 @@ ## 17.3 软件行业的混合办公模式 -本小节摘录了来自微软亚洲研究院 DKI 组的一份研究报告，它调查了新冠疫情对软件行业人员的影响，尤其是新型的混合办公模式的体验情况，有助于帮助软件行业的企业管理者进行更合理的决策。 +本小节摘录了来自微软亚洲研究院 DKI 组的一份研究报告，它调查了 COVID-19 对软件行业人员的影响，尤其是新型的混合办公模式的体验情况，有助于帮助软件行业的企业管理者进行更合理的决策。 -标题：新冠肺炎疫情恢复期间重返办公室—来自中国的早期指标 +标题： COVID-19 恢复期间重返办公室—来自中国的早期指标 原文标题：Returning to the Office During the COVID-19 Pandemic Recovery: Early Indicators from China 原文链接：https://dl.acm.org/doi/10.1145/3411763.3451685 原文作者： @@ -27,53 +27,53 @@ ### 摘要 -新冠肺炎疫情迫使许多人在2020年初突然转向远程工作。但随着各国从疫情中复苏，正如中国从 2020 年春天开始的那样，公司经历了重新开放办公室的过程。人们以混合模式（Hybrid mode）工作，在这种模式下，他们可以决定如何分配在家和办公室工作的时间。在这项研究中，我们探讨了影响员工决策的关键因素是什么。我们对一家全球科技公司在中国的员工进行了调查和采访。这些数据展示了人们在家和办公室之间的工作时间安排，他们在家工作的经历，以及他们喜欢的工作模式。通过访谈，我们确定了人们在混合工作阶段决定在哪里工作的不同策略和原因。 + COVID-19 迫使许多人在2020年初突然转向远程工作。但随着各国从 COVID-19 中复苏，正如中国从 2020 年春天开始的那样，公司经历了重新开放办公室的过程。人们以混合模式（Hybrid mode）工作，在这种模式下，他们可以决定如何分配在家和办公室工作的时间。在这项研究中，我们探讨了影响员工决策的关键因素是什么。我们对一家全球科技公司在中国的员工进行了调查和采访。这些数据展示了人们在家和办公室之间的工作时间安排，他们在家工作的经历，以及他们喜欢的工作模式。通过访谈，我们确定了人们在混合工作阶段决定在哪里工作的不同策略和原因。 概念：以人为中心的计算—协作和社交计算的实证研究。 -关键字：远程工作、在家工作、远程工作、混合工作、新冠肺炎。 +关键字：远程工作、在家工作、远程工作、混合工作。 ### 17.3.1 引言 -新冠肺炎疫情迫使许多知识工作者在 2020 年初突然转向全球范围的远程工作。对疫情的应对方法使人们在远程工作方面有了大量自然发生的经验，因此这为研究人员提供了一个机会，可以在不同于传统情况的远程工作的背景下研究远程工作主题。 + COVID-19 迫使许多知识工作者在 2020 年初突然转向全球范围的远程工作。对 COVID-19 的应对方法使人们在远程工作方面有了大量自然发生的经验，因此这为研究人员提供了一个机会，可以在不同于传统情况的远程工作的背景下研究远程工作主题。 -由于疫情形势和应对措施的不同，各国目前从疫情中恢复的进展情况差异很大。一些国家领先于其他国家，冠状病毒的传播已基本得到控制，社会和经济正在从新冠肺炎疫情中恢复。在中国，疫情恢复过程始于 2020 年春季，当时公司经历了重新开放办公室的过程，员工从强制在家工作过渡到在家和办公室工作的混合模式。员工被允许返回办公室，同时仍保持必要时在家工作的灵活性。在混合模式下，员工可以根据各种因素决定如何在家和办公室之间分配工作时间。 +由于 COVID-19 形势和应对措施的不同，各国目前从 COVID-19 中恢复的进展情况差异很大。一些国家领先于其他国家，病毒的传播已基本得到控制，社会和经济正在从 COVID-19 中恢复。在中国， COVID-19 恢复过程始于 2020 年春季，当时公司经历了重新开放办公室的过程，员工从强制在家工作过渡到在家和办公室工作的混合模式。员工被允许返回办公室，同时仍保持必要时在家工作的灵活性。在混合模式下，员工可以根据各种因素决定如何在家和办公室之间分配工作时间。 -尽管最近发表了许多研究以检验新冠肺炎疫情背景下的远程工作经验$^{[5–7,9,25,27,30]}$，但缺乏针对疫情恢复期间混合工作阶段的研究。在这项研究中，我们旨在填补这一空白，以了解员工在混合工作模式下的实践和经验，并探讨影响他们在家和办公室之间工作时间安排的关键因素是什么。具体而言，我们对一家全球科技公司在中国三个城市的知识工作者进行了一项在线调查（N=475）和半结构化访谈（N=12）。在我们进行调查和采访时，他们已经在混合模式下工作了三个多月，因此随着时间的推移，他们的实践和经验基本上稳定了下来。从我们的研究中，我们发现，与完全在家工作相比，参与者在混合工作模式下总体上感知到更高的生产力和更高的满意度。 +尽管最近发表了许多研究以检验 COVID-19 背景下的远程工作经验$^{[5–7,9,25,27,30]}$，但缺乏针对 COVID-19 恢复期间混合工作阶段的研究。在这项研究中，我们旨在填补这一空白，以了解员工在混合工作模式下的实践和经验，并探讨影响他们在家和办公室之间工作时间安排的关键因素是什么。具体而言，我们对一家全球科技公司在中国三个城市的知识工作者进行了一项在线调查（N=475）和半结构化访谈（N=12）。在我们进行调查和采访时，他们已经在混合模式下工作了三个多月，因此随着时间的推移，他们的实践和经验基本上稳定了下来。从我们的研究中，我们发现，与完全在家工作相比，参与者在混合工作模式下总体上感知到更高的生产力和更高的满意度。 -由于全球一些地区的许多工作场所仍处于关闭状态，我们的研究结果有助于为决策者和组织提供信息，帮助他们规划和准备新冠肺炎疫情恢复期间的混合工作模式阶段。此外，这种前所未有的混合工作模式可能会影响人们对远程工作的态度和策略，这可能表明不同工作模式的优缺点，并为未来的工作规范形成最佳实践。因此，我们的研究可以补充其他研究，并有助于在这种新的实践中全面理解对于远程工作研究。 +由于全球一些地区的许多工作场所仍处于关闭状态，我们的研究结果有助于为决策者和组织提供信息，帮助他们规划和准备 COVID-19 恢复期间的混合工作模式阶段。此外，这种前所未有的混合工作模式可能会影响人们对远程工作的态度和策略，这可能表明不同工作模式的优缺点，并为未来的工作规范形成最佳实践。因此，我们的研究可以补充其他研究，并有助于在这种新的实践中全面理解对于远程工作研究。 ### 17.3.2 相关工作 -远程工作，也称为远程工作、远程办公或在家工作（WFH，Working From Home），为员工提供了灵活的工作安排，他们不需要在中心办公工作场所工作。远程工作已经越来越多地被许多公司所采用。根据盖洛普的一项调查，超过 43%的员工报告称，2017 年每周至少有一天远程工作$^{[17]}$。然而，在现实中，远程工作并不总是被认为是有益的。例如，为了更好的沟通和协作，雅虎禁止员工在家工作$^{[21]}$。远程工作是未来工作的一个重要方面，但其长期影响仍不确定。 +远程工作，也称为远程工作、远程办公或在家工作（Working From Home，WFH），为员工提供了灵活的工作安排，他们不需要在中心办公工作场所工作。远程工作已经越来越多地被许多公司所采用。根据盖洛普的一项调查，超过 43%的员工报告称，2017 年每周至少有一天远程工作$^{[17]}$。然而，在现实中，远程工作并不总是被认为是有益的。例如，为了更好的沟通和协作，雅虎禁止员工在家工作$^{[21]}$。远程工作是未来工作的一个重要方面，但其长期影响仍不确定。 先前的研究从各个方面调查了远程工作的好处和缺点$^{[1-3,11,13,20,24]}$。总的来说，许多研究表明，远程工作可以提高生产力并带来更高的工作满意度$^{[4,8,10,18]}$，因为远程工作为员工提供了更灵活的工作时间和更好的工作与生活平衡。另一方面，远程工作可能会对生产力产生负面影响。例如，在家工作可能会降低软件开发中开发人员沟通的效率$^{[29]}$。研究人员还发现了在远程工作期间影响人们幸福感的具体挑战，如模糊工作与生活的界限$^{[2]}$和与同事的社会隔离$^{[15]}$，并且可能因不同类型的工作而有所不同$^{[14,26,28]}$。创造性工作、新的工作流程和需要广泛协作的任务可能比容易编码的工作更难通过远程工作实现。 -以前的研究大多是关于非正常情况下的远程工作体验，在这种情况下，远程工作通常只涉及一小部分劳动力和有限的工作角色。对冠状病毒的初步反应要求大多数知识工作者在家工作，并实施了各种健康和社会限制。这些疫情可能改变了在家工作的动态，这表明有必要研究它与传统远程工作的区别。 +以前的研究大多是关于非正常情况下的远程工作体验，在这种情况下，远程工作通常只涉及一小部分劳动力和有限的工作角色。对冠状病毒的初步反应要求大多数知识工作者在家工作，并实施了各种健康和社会限制。这些 COVID-19 可能改变了在家工作的动态，这表明有必要研究它与传统远程工作的区别。 -新冠肺炎疫情应对为研究人员提供了一个独特的时间窗口，以检查大规模远程工作的基本全球实验。研究人员迅速做出反应，及时提出了关于疫情期间远程工作经历的重要发现。例如： + COVID-19 应对为研究人员提供了一个独特的时间窗口，以检查大规模远程工作的基本全球实验。研究人员迅速做出反应，及时提出了关于 COVID-19 期间远程工作经历的重要发现。例如： -- 几项研究$^{[5,12,25]}$关注的是疫情期间在家工作的软件开发人员的生产力。 +- 几项研究$^{[5,12,25]}$关注的是 COVID-19 期间在家工作的软件开发人员的生产力。 - Yang 等人估计了新冠肺炎期间在家工作对团队协作的影响$^{[30]}$。 - Nolan 等人探讨了远程工作对幸福感方面的影响$^{[23]}$。 -这些研究主要考察了新冠肺炎疫情封锁期间完全在家工作的经历。 +这些研究主要考察了 COVID-19 封锁期间完全在家工作的经历。 -我们的研究侧重于新冠肺炎疫情恢复混合工作阶段的经验。我们探讨了在疫情恢复期间，员工如何以混合工作模式在家和办公室之间分配工作时间，以及哪些潜在因素影响了他们的决策。有的研究讨论了人们在正常时间远程工作的原因$^{[3,16,19]}$。无论如何，我们的研究说明了疫情期间的差异，即人们首先在疫情应对期间无法选择来办公室，然后经历混合工作阶段，在办公室重新开放后，他们必须决定是否返回办公室。 +我们的研究侧重于 COVID-19 恢复混合工作阶段的经验。我们探讨了在 COVID-19 恢复期间，员工如何以混合工作模式在家和办公室之间分配工作时间，以及哪些潜在因素影响了他们的决策。有的研究讨论了人们在正常时间远程工作的原因$^{[3,16,19]}$。无论如何，我们的研究说明了 COVID-19 期间的差异，即人们首先在 COVID-19 应对期间无法选择来办公室，然后经历混合工作阶段，在办公室重新开放后，他们必须决定是否返回办公室。 ### 17.3.3 研究方法 -在本研究中，我们旨在了解中国人在新冠肺炎疫情恢复的混合工作阶段的经验和做法。具体来说，当人们在混合模式下工作时，我们对三个方面感兴趣： +在本研究中，我们旨在了解中国人在 COVID-19 恢复的混合工作阶段的经验和做法。具体来说，当人们在混合模式下工作时，我们对三个方面感兴趣： -1）他们如何安排在家和办公室之间的工作时间？ -2）在家工作对他们的工作和幸福感有何影响？ -3）人们在多大程度上更喜欢混合工作模式？ +（1）他们如何安排在家和办公室之间的工作时间？ +（2）在家工作对他们的工作和幸福感有何影响？ +（3）人们在多大程度上更喜欢混合工作模式？ 我们对一家全球高科技公司在中国的员工进行了在线调查和后续采访。 #### 1. 背景 -2020 年 1 月 23 日凌晨 2 点，武汉发布了封锁通知以防止疫情蔓延。公司很快关闭了中国大陆的办公设施，最初关闭到 2 月 9 日，但后来根据情况的严重性两次延长到 2 月 17 日。2 月 17 日，当情况急剧缓解时，中国的公司逐渐开始欢迎员工回到办公室。 +2020 年 1 月 23 日凌晨 2 点，武汉发布了封锁通知以防止 COVID-19 蔓延。公司很快关闭了中国大陆的办公设施，最初关闭到 2 月 9 日，但后来根据情况的严重性两次延长到 2 月 17 日。2 月 17 日，当情况急剧缓解时，中国的公司逐渐开始欢迎员工回到办公室。 我们调查的公司是一家跨国科技公司，在中国的好几个城市都有办公室。根据政府的政策和指导方针，该公司于 2 月 17 日谨慎地开放，允许员工重新进入办公室工作场所，尽管仍鼓励人们在家工作以将风险降至最低。从 3 月 13 日起，员工可以在家或办公室以混合工作模式工作。到我们进行调查时，他们已经在混合模式下工作了三个多月。因此，他们可以分享他们的混合工作模式。 #### 2. 调查 @@ -92,9 +92,9 @@ #### 3. 专访 -我们在 2020 年 7 月和 8 月对该公司的 12 名员工进行了半结构化采访。采访进一步深入探讨了他们的决策和策略的根本原因。有意从我们的调查对象中邀请参与者，涵盖不同的性别、学科、角色和地点（表 17.3.1）。 +我们在 2020 年 7 月和 8 月对该公司的 12 名员工进行了半结构化采访。采访进一步深入探讨了他们的决策和策略的根本原因。有意从我们的调查对象中邀请参与者，涵盖不同的性别、学科、角色和地点（表 17-1）。 -表 17.3.1 访谈参与者 +表 17-1 访谈参与者 |采访人序号|性别|训练|角色|地方| |-|-|-|-|-| @@ -156,9 +156,9 @@ - 一位受访者（P3）提到，起初他们不确定如何使团队会议足够有效，并评论道：“我的队友经常认为在线会议太正式，所以他们更不愿意谈论琐碎的话题。”但经过一段时间的尝试和错误，他们学会了如何更好地利用远程团队会议。 - 我们调查的参与者报告的数字甚至更高。新冠肺炎期间在家工作的满意度（22%非常满意，45%稍微满意，15%既不满意也不满意，14%稍微不满意，5%非常不满意）。他们解释说，在家工作可以降低健康风险，同时仍然保持令人满意的生产力水平。一位参与者（P7）告诉我们，“我觉得WFH对我和我的家人来说都很有价值。我和家人可以在一起，我自己也可以继续工作。” -为了了解在家工作的体验因素如何与感知的生产力和满意度相关，我们计算了与在家工作体验有关的特定问题与生产力和满意度感知之间的皮尔逊相关性。表 17.3.2 和表 17.3.3 显示了在家工作时，体验问题与感知生产力和满意度之间的相关性高于 0.3 或低于 -0.3。一些有趣的相关性：对工作的更好控制感、更高效的会议和更多的时间完成工作与更好的整体生产力有关；在家工作时，更好的工作与生活平衡和更少的花钱与更高的满意度有关。 +为了了解在家工作的体验因素如何与感知的生产力和满意度相关，我们计算了与在家工作体验有关的特定问题与生产力和满意度感知之间的皮尔逊相关性。表 17-2 和表 17-3 显示了在家工作时，体验问题与感知生产力和满意度之间的相关性高于 0.3 或低于 -0.3。一些有趣的相关性：对工作的更好控制感、更高效的会议和更多的时间完成工作与更好的整体生产力有关；在家工作时，更好的工作与生活平衡和更少的花钱与更高的满意度有关。 -表 17.3.2 与工作效率的相关度绝对值大于 0.3 的WFH体验问题 +表 17-2 与工作效率的相关度绝对值大于 0.3 的WFH体验问题 |WFH 体验问题|相关度|p 值| |-|-|-| @@ -174,7 +174,7 @@ |很难与同事沟通和协调|-0.35327|p<0.001 |很糟糕，因为缺乏规则和流程|-0.35664|p<0.01 -表 17.3.3 与满意度的相关度绝对值大于 0.3 的WFH体验问题 +表 17-3 与满意度的相关度绝对值大于 0.3 的WFH体验问题 |WFH 体验问题|相关度|p 值| |-|-|-| @@ -198,7 +198,7 @@ 在采访中，我们还询问了参与者对未来工作的展望。 -- 大多数参与者倾向于将混合工作模式作为新冠肺炎疫情后的一种工作选择，因为通过混合模式，知识工作者通常可以结合在家和办公室工作的优点，以最大限度地提高生产力和灵活性。正如我们的一位受访者（P12）告诉我们的那样，“在家工作时，我感觉更有效率。在家工作对我来说唯一的缺点是缺乏社交机会。这就是为什么我喜欢混合模式。” +- 大多数参与者倾向于将混合工作模式作为 COVID-19 后的一种工作选择，因为通过混合模式，知识工作者通常可以结合在家和办公室工作的优点，以最大限度地提高生产力和灵活性。正如我们的一位受访者（P12）告诉我们的那样，“在家工作时，我感觉更有效率。在家工作对我来说唯一的缺点是缺乏社交机会。这就是为什么我喜欢混合模式。” - 一位项目经理（P2）喜欢办公室的工作氛围不喜欢远程工作。但她仍然支持混合动力模式。她评论道：“我不认为长期在家工作会奏效，但我相信混合工作可能是未来的最佳解决方案。它可以为我们提供很大的灵活性，以利用远程工作和办公室工作的好处。” @@ -206,18 +206,18 @@ ### 17.3.5 讨论和限制 -应该注意的是，这一混合工作阶段的背景是人们在长期封锁后首次体验到的。人们在混合模式下的行为、感知和偏好可能是由刚刚摆脱封锁的反弹效应决定的。人们在家工作的经历也可能与其他国家的远程工作政策和疫情进展有关。例如，一位受访者（P7）表示，由于美国（公司总部所在地）有大量同事在家工作，因此美国在晚上可以举行更多会议。 +应该注意的是，这一混合工作阶段的背景是人们在长期封锁后首次体验到的。人们在混合模式下的行为、感知和偏好可能是由刚刚摆脱封锁的反弹效应决定的。人们在家工作的经历也可能与其他国家的远程工作政策和 COVID-19 进展有关。例如，一位受访者（P7）表示，由于美国（公司总部所在地）有大量同事在家工作，因此美国在晚上可以举行更多会议。 调查参与者和受访者普遍对在家工作感到满意。然而，我们也发现，在家里缺乏适当的工作场所设置是影响体验的一个重要因素。对于那些有私人安静的工作场所和不间断的时间，他们更喜欢在家工作。如果人们很容易被打扰，那么在家工作时的高生产力可能更难实现。 通信技术是另一个可能有助于有效远程工作的重要因素，尤其是对于需要大量协作的信息工作者来说。由于人们无法在会议室面对面交流，也无法利用白板讨论问题，因此在家工作的效率降低了。因此，人们选择进入办公室来弥补这些不利因素。为了支持更好的远程工作，应该增强通信工具，以弥补由于无法见面而导致的通信效率低下，尤其是在提供共享绘图工具的情况下。 -重要的是要记住我们重新研究人们对混合工作模式的行为和态度的不同寻常的背景。在疫情的特殊情况下，有许多因素也影响了人们的判断和决策。例如，在疫情初期，一些公共交通受到限制，这可能会直接影响人们通勤到办公室的决定。此外，公共卫生官员鼓励人们保持社交距离，减少旅行，这可能会让人们在家工作时感到更安全。此外，在混合工作模式下，幼儿园和学校没有开放，因此家长在家工作时可能需要积极管理孩子。 +重要的是要记住我们重新研究人们对混合工作模式的行为和态度的不同寻常的背景。在 COVID-19 的特殊情况下，有许多因素也影响了人们的判断和决策。例如，在 COVID-19 初期，一些公共交通受到限制，这可能会直接影响人们通勤到办公室的决定。此外，公共卫生官员鼓励人们保持社交距离，减少旅行，这可能会让人们在家工作时感到更安全。此外，在混合工作模式下，幼儿园和学校没有开放，因此家长在家工作时可能需要积极管理孩子。 这项研究的重点是中国一家信息技术公司的工作经验，我们曾接触过该公司调查并采访其员工。必须承认数据仅来自一家公司的局限性。这家公司专注于信息技术产品及其技术基础设施，使得大部分工作都可以在家远程进行。作为一家总部设在美国的全球性公司，中国的工作政策涉及与全球企业政策的一些协调，这可能与总部设在中国的公司不同。 ### 17.3.6 结束语 -我们列出了对中国一家全球科技公司员工进行的在线调查和访谈的结果，以了解他们在新冠肺炎疫情恢复期间的混合工作模式经历。这项研究展示了中国知识型员工如何在家和办公室之间安排工作时间，还揭示了可能影响人们在家工作和返回办公室的体验的各种因素，以及他们为时间安排所采取的策略。这些数据可以将中国的做法与世界其他地区收集的数据进行比较。此外，这些结果有助于改善其他地区的混合重返工作岗位体验，特别是关注所列因素如何影响人们在工作场所重新开放时选择重返工作岗位。 +我们列出了对中国一家全球科技公司员工进行的在线调查和访谈的结果，以了解他们在 COVID-19 恢复期间的混合工作模式经历。这项研究展示了中国知识型员工如何在家和办公室之间安排工作时间，还揭示了可能影响人们在家工作和返回办公室的体验的各种因素，以及他们为时间安排所采取的策略。这些数据可以将中国的做法与世界其他地区收集的数据进行比较。此外，这些结果有助于改善其他地区的混合重返工作岗位体验，特别是关注所列因素如何影响人们在工作场所重新开放时选择重返工作岗位。 *由于篇幅有限，参考文章链接没有列出，有兴趣的读者可以阅读原文。* diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.4 深度学习平台质量问题实证研究.md b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.4 深度学习平台质量问题实证研究.md index 1979b9ed..cb8ceb3c 100644 --- a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.4 深度学习平台质量问题实证研究.md +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.4 深度学习平台质量问题实证研究.md @@ -37,8 +37,6 @@ Platform-X 是⼀个内部使用的深度学习平台，为数千名开发⼈员 ### 17.4.1 引言 -近年来，深度学习（DL）在许多应⽤领域得到越来越多的采⽤，例如⾃然语⾔处理$^{[1,2]}$、强化学习游戏 $^{[3]}$、计算机编程 $^{[4]}$ 和卫星图像$^{[5]}$。IT 企业已经构建了专⽤的多租户平台（例如，Microsoft Azure Machine Learning $^{[6]}$、Amazon SageMaker $^{[7]}$ 和Google Cloud AI $^{[8]}$），为开发⼈员提供便捷的深度学习训练和推理服务。这些 DL平台配备了⼤量计算设备（如 CPU、GPU 或 TPU），并在内部与⾼速⽹络互连（如通过 InfiniBand $^{[9]}$），⽀持各种 DL 框架和PyTorch $^{[10]}$、TensorFlow $^{[11]}$ 和 Hugging Face $^{[12]}$等库。 - 在 Microsoft 内部，数千名开发⼈员和研究⼈员每天使⽤内部⽣产 DL 平台 Platform-X 来训练和测试他们的模型，以完成⼴告和机器翻译等各种任务。 Platform-X 是⽤⼴泛使⽤的开源软件（例如 Kubernetes $^{[13]}$）和商⽤计算硬件（例如 GPU）搭建的，并且在架构上与上述公开的 DL 平台相似。对于Platform X，其核⼼任务之⼀是在遇到意外的硬件和软件故障时，根据它的服务⽔平协议（SLA）保证每个⽤户的服务质量。尽管采取了很多质量保证措施，但实际上，许多 DL 作业仍然存在严重的质量问题，⽆法提交、运⾏速度很慢、挂起，甚⾄意外失败。这些质量问题不仅会影响⽤户体验，还会影响企业⽣产⼒。⽤户在遇到质量问题时，通过问题管理系统反馈，希望服务站点的可靠性⼯程师（SRE）尽快诊断并解决，这也给平台⽀持团队带来了沉重的运维负担。因此，了解 Platform-X 中提出的质量问题，包括它们的故障、根本原因和缓解措施，对于帮助平台⽀持团队最⼤限度地提⾼效率和帮助平台⼯程团队改进系统设计和实施变得尤为重要。 - 以前有很多关于传统软件系统质量问题的⼯作$^{[14...22]}$。例如，Zhou 等⼈$^{[19]}$ 研究了来⾃微软内部⼤数据分析平台的 210 个随机选择的质量问题。 @@ -67,9 +65,9 @@ Microsoft 使用通用的硬件和广泛使用的开源软件构建 Platform‑X -图 17.4.1 Platform-X 概览 +图 17-1 Platform-X 概览 -图 17.4.1 简要说明了 Platform‑X 的工作流程。 Platform‑X 的系统架构和作业管理与Microsoft Azure Machine Learning $^{[6]}$、Amazon SageMaker$^{[7]}$ 和 Google Cloud AI $^{[8]}$ 等公共 DL 平台非常相似。用户首先操作门户网站或用于将所有材料（包括输入数据、Python 程序、shell 脚本和可能的模型检查点）上传到分布式存储（例如，Azure Blobs）的命令行工具。接下来，用户为他们的作业指定资源配额（例如，GPU 型号和数量）、Docker镜像、启动 shell 脚本、主要 Python文件、输入/输出路径和其他配置。 +图 17-1 简要说明了 Platform‑X 的工作流程。 Platform‑X 的系统架构和作业管理与Microsoft Azure Machine Learning $^{[6]}$、Amazon SageMaker$^{[7]}$ 和 Google Cloud AI $^{[8]}$ 等公共 DL 平台非常相似。用户首先操作门户网站或用于将所有材料（包括输入数据、Python 程序、shell 脚本和可能的模型检查点）上传到分布式存储（例如，Azure Blobs）的命令行工具。接下来，用户为他们的作业指定资源配额（例如，GPU 型号和数量）、Docker镜像、启动 shell 脚本、主要 Python文件、输入/输出路径和其他配置。 用户还可以指定预装了所有依赖库的自定义 Docker 镜像。一旦提交的作业被选择运行，Platform‑X 的调度程序使用群调度 $^{[36]}$ 算法立即分配所有请求的资源，并在一个或多个 GPU 计算节点上实例化容器。Platform‑X 中的计算节点是配备了GPU、CPU、主内存、磁盘和网络接口卡的物理服务器或虚拟机。之后，此类作业的 DL 训练代码会迭代更新可学习参数（即权重和偏差），直到模型学习性能（例如预测准确性）达到我们的预期。最后，当模型训练完成后，作业将最终的模型文件和评估结果保存到分布式存储中。 @@ -81,9 +79,9 @@ Platform‑X 采用标准且定义明确的流程来处理质量问题。 - 然后，问题管理系统将新的质量问题交付给适当的站点可靠性工程师（Site Reliability Engineer, SRE），以根据问题类型和历史统计数据进行调查。SRE 调用一个集成工具来自动发现以前重复的、相似的或相关的质量问题。如果没有找到，SRE 将遵循正式的故障排除指南在自上而下的过程中逐步调查问题。SRE 通过审查错误消息或异常性能指标，从受影响作业流程的故障或异常站点开始。在分析了程序和运行时日志之后，她试图推断出问题的关键路径。在故障排除决策规则的指导下，SRE 深入研究关键路径中的瓶颈或失败阶段，以确定根本原因。 -- Platform‑X 为上述问题诊断记录了各种遥测数据。这些数据包含作业元数据、性能指标和运行时日志，其中大部分列在表 17.4.1 中。作业元数据包括时间统计信息（例如，作业/进程开始和结束时间）、分配的资源（例如，GPU 规格和数量）和依赖软件。性能指标包括各种资源的使用（例如，GPU/CPU 的平均利用率）和节点状态（即，健康或故障）。运行时日志包括由用户代码、运行时、系统组件和硬件驱动程序打印的常规和失败消息。 +- Platform‑X 为上述问题诊断记录了各种遥测数据。这些数据包含作业元数据、性能指标和运行时日志，其中大部分列在表 17-4 中。作业元数据包括时间统计信息（例如，作业/进程开始和结束时间）、分配的资源（例如，GPU 规格和数量）和依赖软件。性能指标包括各种资源的使用（例如，GPU/CPU 的平均利用率）和节点状态（即，健康或故障）。运行时日志包括由用户代码、运行时、系统组件和硬件驱动程序打印的常规和失败消息。 -表 17.4.1 质量问题分析所依据的日志数据 +表 17-4 质量问题分析所依据的日志数据 |维度|分类|举例| |-|-|-| @@ -120,7 +118,7 @@ Platform‑X 采用标准且定义明确的流程来处理质量问题。 #### 3. 有效性顾虑 -Threats to Validity，直译为有效性威胁，意为该研究的有效性是不是会被质疑，所以笔者以为“有效性顾虑”。 +*Threats to Validity，直译为有效性威胁，意为该研究的有效性是不是会被质疑，所以笔者译为“有效性顾虑”。* - 内部有效性的顾虑 @@ -135,9 +133,9 @@ Threats to Validity，直译为有效性威胁，意为该研究的有效性是 ### 17.4.5 常见故障是什么？ -在本节中，我们将研究质量问题的常见故障。故障是用户观察到的质量问题的主观证据，可以在问题标题和描述中发现。表 17.4.2 列出了故障分类，共包括七类。 +在本节中，我们将研究质量问题的常见故障。故障是用户观察到的质量问题的主观证据，可以在问题标题和描述中发现。表 17-5 列出了故障分类，共包括七类。 -表 17.4.2 故障分类 +表 17-5 故障分类 ||分类|数量|比例| |-|-|-|-| @@ -159,9 +157,9 @@ Threats to Validity，直译为有效性威胁，意为该研究的有效性是 此外，我们对质量问题的严重程度进行分类。 -如第 17.4.3 节所述，用户在向 Platform‑X 支持团队提交质量问题时需要根据业务影响声明严重级别。问题管理系统和 SRE 参考用户提出的严重性来确定问题处理的优先级（例如，确定缓解措施所需的时间）。请注意，SRE 可能会根据以前/类似的质量问题和她的领域知识来调整严重性级别，以反映更准确的情况。Platform X 采用三个严重级别：高、正常和低。表 17.4.3 显示了所有问题的严重程度分布。 +如第 17.4.3 节所述，用户在向 Platform‑X 支持团队提交质量问题时需要根据业务影响声明严重级别。问题管理系统和 SRE 参考用户提出的严重性来确定问题处理的优先级（例如，确定缓解措施所需的时间）。请注意，SRE 可能会根据以前/类似的质量问题和她的领域知识来调整严重性级别，以反映更准确的情况。Platform X 采用三个严重级别：高、正常和低。表 17-6 显示了所有问题的严重程度分布。 -表 17.4.3 严重程度分布 +表 17-6 严重程度分布 |严重程度|数量|比例| |-|-|-| @@ -173,9 +171,9 @@ Threats to Validity，直译为有效性威胁，意为该研究的有效性是 ### 17.4.6 常见的根本原因是什么？ -在本节中，我们将对 360 个问题的常见根本原因进行分类，我们将它们分为三个主要维度：硬件、平台端和用户端，表 17.4.4 显示了这些维度的总体分布。 +在本节中，我们将对 360 个问题的常见根本原因进行分类，我们将它们分为三个主要维度：硬件、平台端和用户端，表 17-7 显示了这些维度的总体分布。 -表 17.4.4 故障的总体分布 +表 17-7 故障的总体分布 ||维度|数量|比例| |-|-|-|-| @@ -186,11 +184,11 @@ Threats to Validity，直译为有效性威胁，意为该研究的有效性是 #### 1. 硬件故障 -Platform‑X 由 NVIDIA GPU 和 InfiniBand 网络等异构商品硬件构建，可能会遇到相对较高的硬件故障概率。表 17.4.4 表明硬件故障是主要的根本原因类型，导致近三分之一（102/28.33%）的质量问题。 +Platform‑X 由 NVIDIA GPU 和 InfiniBand 网络等异构商品硬件构建，可能会遇到相对较高的硬件故障概率。表 17-7 表明硬件故障是主要的根本原因类型，导致近三分之一（102/28.33%）的质量问题。 -硬件故障有 11 分类，我们进一步将它们分为三组：GPU、网络和节点。硬件故障的详细分类和分布如表 17.4.5 所示。 +硬件故障有 11 分类，我们进一步将它们分为三组：GPU、网络和节点。硬件故障的详细分类和分布如表 17-8 所示。 -表 17.4.5 硬件故障（Hardware Fault）分类 +表 17-8 硬件故障（Hardware Fault）分类 |分组|分类|数量|比例| |-|-|-|-| @@ -209,7 +207,7 @@ Platform‑X 由 NVIDIA GPU 和 InfiniBand 网络等异构商品硬件构建， |2|Node Damage|5|1.39%| |3|Node Preemption|2|0.55%| -1）GPU +（1）GPU GPU 是深度学习工作的主要计算设备。长时间和繁重的工作量可能导致各种 GPU故障 $^{[38...41]}$。 @@ -227,7 +225,7 @@ GPU 是深度学习工作的主要计算设备。长时间和繁重的工作量 ``` - 在第 4 个类别中，两个（0.55%）质量问题根源于 Broken GPU Driver，通常需要重启节点或重新安装驱动程序，因为NVIDIAGPU驱动程序无法正常工作。 -2）网络 +（2）网络 跨多个计算节点的分布式深度学习训练在 Platform‑X 中非常普遍。这些节点在内部与高速网络互连（例如，通过 InfiniBand $^{[9]}$）。我们观察到25个（6.95%）质量问题是由四类网络故障引起的，其中三类与 InfiniBand 相关。 InfiniBand 是“一种用于高性能计算的计算机网络通信标准，具有非常高的吞吐量和非常低的延迟”$^{[9]}$，广泛应用于各种领域基于云的平台。 @@ -236,7 +234,7 @@ GPU 是深度学习工作的主要计算设备。长时间和繁重的工作量 - 其他 InfiniBand 故障有 6 个（1.67%），包括适配器初始化失败、平台侧故障驱动程序损坏、写入事务错误和内存注册失败。 - 第 4 个类别，以太网故障。以太网在 Platform‑X 中也大量使用，用于连接分布式存储和内部服务，并方便用户通过安全外壳协议（SSH）调试失败的作业。此类别有 8 个（2.22%）案例，包括瞬态以太网故障、名称解析错误和对等方重置连接等。 -3）节点 +（3）节点 Platform‑X 中的计算节点（或简称节点）是一个独特的可调度单元，用于使用GPU、CPU、主内存、磁盘和网络接口卡进行计算。它可以是物理服务器或虚拟机（VM）。由于 Platform‑X使用商品硬件，节点故障在所难免，导致57个（15.83%）质量问题，超过其他两组的总和。 - 其中 50 个（13.89%）是节点中断，例如操作系统内核崩溃和临时磁盘错误，导致 DL 作业失败或挂起。需要注意的是，临时磁盘被创建并附加到计算节点作为临时存储（例如，一个作业拉取并存储其远程输入数据以供以后快速数据访问）。这一类在节点组中是最大的，远超其他两类。 @@ -248,9 +246,9 @@ Platform‑X 中的计算节点（或简称节点）是一个独特的可调度 #### 2. 平台侧（Platform-side Fault）故障 -在本节中，我们描述了平台侧故障的研究，其中包括102个（28.33%）案例，并进一步分为六类。表 17.4.6 显示了详细的分类和分布。 +在本节中，我们描述了平台侧故障的研究，其中包括102个（28.33%）案例，并进一步分为六类。表 17-9 显示了详细的分类和分布。 -表 17.4.6 平台侧故障统计 +表 17-9 平台侧故障统计 ||分类|数量|比例| |-|-|-|-| @@ -262,7 +260,7 @@ Platform‑X 中的计算节点（或简称节点）是一个独特的可调度 |6|Regression 旧伤复发|9 |2.50%| ||Subtotal| 102| 28.33%| -1）System Defect +（1）系统故障（System Defect） 系统缺陷是最大的类别，结果为37（10.28%）质量问题。典型缺陷包括： @@ -271,23 +269,23 @@ Platform‑X 中的计算节点（或简称节点）是一个独特的可调度 - 错误的访问控制。如前所述，分布式存储上的输入数据文件夹在没有警告的情况下消失了。 根本原因是 Platform‑X 错误设置了这样一个文件夹的访问控制，导致同组的另一个同事不小心删除了。 -2）Resource Overload +（2）资源超负载（Resource Overload） 对于某些系统资源，Platform‑X 对用户和 DL 作业没有明确的配额控制。因此，如果用户没有意识到这样的系统设计限制并过度使用资源，就会触发资源过载故障。此类有 21 例（5.83%）。例如，用户试图将所有输入数据加载到主内存中以获得最佳性能。然而，数据太大了，主内存很快就用完了。再举一个例子，用户将他们的临时数据（例如模型检查点、评估结果、软件缓存甚至输入数据）存储在计算节点的本地磁盘上是一种常见的做法。有时，用户忘记清理旧文件，磁盘空间很快就会用完。 -3）Platform Maintenace +（3）平台维护（Platform Maintenace） Platform‑X 定期对 GPU 集群进行平台维护，以进行硬件更换、节点重映像、软件升级和其他任务，这导致了 14 个（3.89%）质量问题。如果用户不进行主动的作业迁移，现有正在运行的DL作业将被 Platform-X 自动终止。偶尔，一些用户不知道维护通知，因此无法持久提交作业。 -4）Resource Contention +（4）资源争抢（Resource Contention） 由于多个 DL 作业可能会竞争计算节点上的相同资源，因此它们可能会相互干扰并触发 Resource Contention 故障。此类别包括 10 个（2.78%）案例。例如，DL 作业意外减速。SRE 发现这样的作业获得的 CPU 时间比平时少得多，因为另一个作业同时创建了太多 CPU 任务。Resource Contention 与上面的 Resource Overload 类似，都可以通过采用更合适的系统设计（例如，应用资源隔离和配额控制）来缓解。 -5）Transient Service Outage +（5）暂时性服务中断（Transient Service Outage） 第五类是暂时性服务中断，占所有根本原因的 3.05%（11）。例如，由于 SSH 服务暂时不可用，用户无法连接到分配的计算节点。这些服务中断是暂时的，可以在一段时间后自动恢复。但是，我们没有进一步的细节来推断更根本的原因。 -6）Regression +（6）旧伤复发（Regression） Platform‑X 的工具、运行时和服务的旧伤复发（笔者译）导致 9 个（2.50%）质量问题。例如，更新的作业提交工具更改了某些环境变量，从而破坏了向后兼容性。回归来自 Platform‑X 采用的推出政策。目前，新功能和更新正在逐步推出， Platform-X 逐渐扩大部署范围。所以新旧版本都要维护，需要用户注意。一旦发生回归，用户可以将软件或服务回滚到旧版本以缓解问题。 @@ -297,9 +295,9 @@ Platform‑X 的工具、运行时和服务的旧伤复发（笔者译）导致 #### 3. 用户侧故障 -虽然通常认为⽤户不应该报告⾃⼰造成的任何问题，但我们惊讶地发现有 156 个（43.34%）质量问题实际上是⽤户⽅⾯的故障造成的。我们进⼀步将它们分为五类，并在表 17.4.7 中显⽰详细信息。 +虽然通常认为⽤户不应该报告⾃⼰造成的任何问题，但我们惊讶地发现有 156 个（43.34%）质量问题实际上是⽤户⽅⾯的故障造成的。我们进⼀步将它们分为五类，并在表 17-10 中显⽰详细信息。 -表 17.4.7 用户侧（User-side Fault）故障分类 +表 17-10 用户侧（User-side Fault）故障分类 ||分类|数量|比例| |-|-|-|-| @@ -310,7 +308,7 @@ Platform‑X 的工具、运行时和服务的旧伤复发（笔者译）导致 |5|Misoperation|11|3.05%| ||Subtotal|156|43.34%| -1）Buggy Code +（1）有缺陷的代码（Buggy Code） 第⼀⼤类是 Buggy Code，涉及 54 例（15.00%），占⽤户端故障总数的近⼀半。这些代码错误存在于深度学习程序、Shell 脚本、配置⽂件和⾃定义 Dockerfile 中，其中许多Zhang 等人在实证研究中已经提到$^{[27]}$。例如，许多错误来自“本地和平台执行环境之间的差异”。$^{[27]}$ @@ -340,23 +338,23 @@ Platform‑X 的工具、运行时和服务的旧伤复发（笔者译）导致 我们还注意到一些软件挂起错误$^{[48,49]}$，这些错误使作业无处可去；例如，一项作业在源代码中错误配置了 InfiniBand，挂在了 NVIDIA NCCL通信上。 -2）Policy Violation +（2）策略限制（Policy Violation） Platform‑X 强制执行多项政策规则，以保证用户更恰当、更高效地使用宝贵的平台资源。 Platform‑X 虽然提供了政策说明文档和培训课程，但部分用户仍不了解这些规则，从而引发Policy Violation故障，导致质量问题42起（11.66%）。此类别是第二大类别，约占所有用户侧故障的四分之一。例如， Platform‑X 会自动终止 GPU 在指定时间段内空闲的用户作业，以减少资源浪费并最大限度地提高平台利用率。 我们还注意到一些用户向 Platform‑X 提交交互式深度学习程序（例如， Jupyter $^{[50]}$ notebooks）用于开发和测试目的。由于非确定性交互，无法提前知道 GPU 的使用时间和使用时长。最后，Platform-X 因闲置时间过长而终止了这些交互式作业。其他违反策略规则包括，例如，平台X临时存储上的数据在几天后到期（因此用户需要尽快将它们移动到持久存储）和DL作业没有启动与某些内部服务的太多连接。违反后者会触发服务节流并导致作业放缓甚至服务终止。 -3）Improper Permission +（3）不恰当的权限（Improper Permission） 用户及其 DL 作业需要适当的权限才能访问 Platform‑X 的资源；否则，会引发 Improper Permission 错误，导致 35（9.72%）个质量问题。例如，用户无法向某个GPU集群提交任何作业。事实上，他的集群访问请求仍在处理中，因此用户此时没有访问权限。另一个例子是，由于缺少正确的凭据，DL 作业无法从中心拉取 Docker 镜像。 -4）Software Incompatibility +（4）软件不兼容（Software Incompatibility） 第四类是软件不兼容，由14个（3.89%）案例组成。随着越来越多的应用领域采用深度学习，与 DL 相关的软件，例如 NVIDIA 运行时、框架、库和优化工具包，最近一直在快速发展。但是，由于它们是由不同的社区独立开发的，因此不匹配的组件之间可能会出现不兼容的情况。 例如，由于标准 DL Docker映像使用的 NVIDIA CUDA 运行时版本低于本地开发版本，因此作业卡住了。通常，DL 作业会在初始化阶段安装依赖库。如果用户忘记明确指定库版本，他们可能会获得尚未经过自己测试的最新软件，这可能会引发软件不兼容。例如，一个作业安装了一个较新的不兼容版本的 Microsoft DeepSpeed $^{[51]}$（一个优化工具包），然后由于网络吞吐量的下降而明显变慢计算节点。为了减少软件不兼容，用户需要更深入地了解各种 DL 软件组件，并使用预装所有依赖库的自定义 Docker 镜像。 -5）Misoperation +（5）误操作（Misoperation） 用户操作不当造成质量问题的原因有 11 起（3.05%），原因可能是用户不熟悉操作流程。 @@ -369,9 +367,9 @@ Platform‑X 强制执行多项政策规则，以保证用户更恰当、更高 站点可靠性工程师（SRE）有责任在报告新的质量问题时迅速采取缓解措施。缓解措施的目的是在尽可能短的时间内使受影响的工作恢复工作或恢复 Platform-X 的服务；否则，业务将受到不利影响，宝贵的资源将被严重浪费。缓解措施通常是一种变通方法，而不是最终修复解决方案，因为后者需要长时间的彻底调查、无错误实施和广泛测试，因此可能无法承受。 -在本节中，我们研究了 SRE 采取的常见缓解措施，并将它们分为十类。表 17.4.8 显示了分类详细信息。请注意，22/6.11% 的质量问题缺乏关于如何缓解的明确细节；因此，我们将他们的缓解措施标记为其他。 +在本节中，我们研究了 SRE 采取的常见缓解措施，并将它们分为十类。表 17-11 显示了分类详细信息。请注意，22/6.11% 的质量问题缺乏关于如何缓解的明确细节；因此，我们将他们的缓解措施标记为其他。 -表 17.4.8 缓解措施 +表 17-11 缓解措施 ||分类|数量|比例| |-|--|-|-| @@ -388,33 +386,33 @@ Platform‑X 强制执行多项政策规则，以保证用户更恰当、更高 |11|Others∗ |22| 6.11%| ||Total |360| 100.00%| -1）Job Resubmission +（1）任务重新提交（Job Resubmission） -工作重新提交是最大的类别，包含125（34.72%）个案例。正如我们在第VI节中看到的，许多作业失败和速度减慢是由各种硬件和平台端故障引起的，其中大多数实际上只影响一个或几个计算节点。一旦SRE识别出一个故障节点，或者Platform‑X 自动检测到一个节点，它就会从所属集群中取消提交以进行离线修复。因此，在不修改任何配置和参数的情况下重新提交受影响的作业将很可能避免出现故障的节点并成功完成作业。 +任务重新提交是最大的类别，包含125（34.72%）个案例。正如我们在第VI节中看到的，许多作业失败和速度减慢是由各种硬件和平台端故障引起的，其中大多数实际上只影响一个或几个计算节点。一旦SRE识别出一个故障节点，或者Platform‑X 自动检测到一个节点，它就会从所属集群中取消提交以进行离线修复。因此，在不修改任何配置和参数的情况下重新提交受影响的作业将很可能避免出现故障的节点并成功完成作业。 -2）User Code Improvement +（2）用户代码改进（User Code Improvement） 用户代码改进是第二大类别，适用于89（24.72%）个质量问题。很多是用户端的问题，确实不应该报告给平台支持团队。但是，为了不妨碍我们的业务，SRE积极帮助用户完善他们的代码、访问权限和提交参数。例如，SRE指示用 户针对 InfiniBand 相关问题增加源代码中的 NCCL 超时值。对于部分由 Resource Overload和Resource Contention引起的问题，代码改进也是一种有效的缓解方法。 -3）Operation Correction +（3）纠正误操作（Operation Correction） 26（7.22%）质量问题由于误操作、违反政策和不当许可可以通过操作纠正来缓解。例如，正如我们提到的，用户应用了错误的查询过滤器。SRE指导用户如何在 Web 门户上正确查询信息并建议正确的过滤器。 -4）System Reconfiguration +（4）系统重新配置（System Reconfiguration ） 包括 23 个（6.39%）质量问题，主要由 Resource Overload、 Policy Violation 和 Improper Permission 引起。SRE 需要重新配置访问权限、策略规则或服务参数。例如，一个问题报告说存储用完了。为了缓解它，SRE 和集群管理员增加了总存储量并执行了数据清理。 -5）Software Rollback +（5）软件版本回滚（Software Rollback） 由软件不兼容、回归和系统缺陷（一个案例）引起的 22 个（6.11%）质量问题通过软件回滚到最后一个有效版本得到缓解。对于系统工具、组件和服务， Platform‑X 保留了几个最新的工作版本。 -6）Automatic Healing +（6）自动恢复（Automatic Healing） 一些服务中断和硬件故障是暂时的，或者可以由 Platform‑X 自动恢复。因此，有 22 个（6.11%）质量问题通过自动修复得到缓解，这意味着用户无需执行特定操作。 -7）System Hotfix +（7）系统补丁（System Hotfix） 许多系统缺陷可能表现出潜在的广泛影响，并且没有简单的缓解措施。因此， Platform‑X 和其他系统服务的支持团队共同努力，尽快交付系统修补程序。例如，由于轻微的不兼容问题，操作系统升级导致存储服务无法正常工作。支持团队很快修复了不兼容问题，然后应用了系统修补程序。该类共计 19 例（5.28%）。请注意，修补程序在成为正式系统补丁之前需要进一步验证和压力测试。 @@ -442,7 +440,7 @@ Platform‑X 强制执行多项政策规则，以保证用户更恰当、更高 基于我们的研究，我们提出了以下未来的研究方向。 -1）工具支持 +（1）工具支持 - 硬件故障预测 @@ -460,7 +458,7 @@ Platform‑X 强制执行多项政策规则，以保证用户更恰当、更高 在我们的研究中，我们已经看到许多质量问题是由用户代码错误、不当许可和违反政策引起的。因此，我们可以开发基于静态分析的代码顾问，主动检测用户程序、Shell 脚本、Dockerfile 和配置/凭证文件中的各种问题。此外，这些代码顾问可能会提供高级修复建议或自动程序修复功能。 -2）平台改进 +（2）平台改进 - 故障感知作业调度 在检查所有问题记录并与一些SRE讨论后，我们观察到某些特定的计算节点在重负载下具有更高的中断概率。目前，深度学习平台主要根据所需资源为作业分配节点。这样的平台可以从计算节点的历史故障数据中学习，并将故障意识整合到它们的作业调度程序中。未来可能的工作是使平台能够估计作业工作量并将长时间运行的作业调度到更稳定的节点而不是容易出错的节点。这样，可以减少潜在的工作问题。 diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.5 基于大模型的代码生成.md b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.5 基于大模型的代码生成.md new file mode 100644 index 00000000..13ded784 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.5 基于大模型的代码生成.md @@ -0,0 +1,151 @@ + +## 17.5 基于大模型的代码生成的调查 + +原文标题：Large language Models Meet NL2Code: A Survey +原文链接：https://arxiv.org/pdf/2212.09420.pdf +原文作者： +```txt +· Daoguang Zan, Chinese Academy of Sciences, daoguang@iscas.ac.cn +· Bei Chen, Microsoft Research Beijing China, beichen@microsoft.com +· Fengji Zhang, Microsoft Research Beijing China, v-fengjzhang@microsoft.com +· Dianjie Lu, Shandong Normal University, ludianjie@sdnu.edu.cn +· Bingchao Wu, Chinese Academy of Sciences, bingchao2017@iscas.ac.cn +· Bei Guan, Chinese Academy of Sciences, guanbei@iscas.ac.cn +· YongJi Wang, Chinese Academy of Sciences, ywang@itechs.iscas.ac.cn +· Jianguang Lou, Microsoft Research Beijing China, jlou@microsoft.com +``` + +主要作者简介： + +昝道广，中国科学院软件研究所博士研究生，曾在微软亚洲研究院数据知识与智能组实习，实习导师为楼建光和陈蓓研究员。研究兴趣为人工智能和软件工程，特别聚焦于基于超大语言模型的代码生成研究工作。微软实习期间在面向第三方代码库的超大语言模型领域中了做了多篇研究工作，并且已发表在人工智能领域顶级会议上，例如IJCAI，EMNLP，ACL，ICLR等。 + +### 摘要 + +从自然生成代码的任务语言描述，或称为 NL2Code（Natual Language to Code），是代码智能中的一个紧迫而重大的挑战。由于预训练技术的快速发展，大型语言模型被用于生成代码，激发了 NL2Code 的进步。在本文中，我们对现有的 27 种大型语言进行了全面的调查，比较它们的基准和指标，直观地在 HumanEval 基准上比较所有现有模型。通过深入的观察和分析，提供了一些观点并得出结论，促成 NL2Code 大型语言模型成功的关键因素是“大量的优质数据和专家调优”。此外，我们基于模型和人类之间的差距讨论了挑战和机遇。我们还创建了一个网站 https://nl2code.github.io 跟踪最新进展。据我们所知，这是针对大型语言模型的首次调查 NL2Code，我们相信它将有助于该领域的持续发展。 + +### 17.5.1 引言 + +新手程序员，甚至是那些没有任何编程经验的程序员，是否有可能仅仅通过用自然语言描述他们的需求来创建软件?实现这一设想将对我们的生活、教育、经济和劳动力市场产生前所未有的影响。自然语言-代码（NL2Code）因其广阔的应用场景，是一项重要的研究任务，在学术界和工业界都引起了广泛的兴趣。 + +关于 NL2Code 的发展，其实和自然语言理解的发展类似，一开始，基本都是基于专家规则进行算法设计，但是此类方法需要对不同编程语言进行设计，泛化性差；随着技术发展，人们逐步开始使用静态语言模型，并使用向量空间来描述文字，此类方法在初期一般向量空间比较稀疏，不能建立长期的依赖关系；再后来，就用到了我们比较熟悉的神经网络，例如 CNN、RNN、LSTM，此类方法通过标记数据进行训练来构建自然语言（NL）和代码（Code）之间的关系，但实际效果对 NL2Code 任务的能力有限；现在，在 ChatGPT 风靡全球的背景下，越来越多的大型语言模型（Large Language Models，LLMs）如雨后春笋一样出现，通过语言指令，它们可以在零样本状况下生成代码，并在NL2Code任务上中取到了惊人的成绩。具有标志性的一个 LLM 模型就是Codex，它拥有 120 亿个参数，在 Python 编程任务上测试，可解决 72.31% 的问题，并且该模型已经商用可在实践中提高开发人员的工作效率。 + +### 17.5.2 可以完成 NL2Code 的大模型 + +对于 NL2Code 任务，其主要目的是基于给定自然语言问题描述生成所需要的代码。以下是一个关于 Python 编程问题的示例。其中有问题描述、模型生成代码、测试用例。 + +问题描述： +```python +from collections import Counter +def MostCommon（lst）: + ''' + Find the most common element from lst. + ''' +``` +模型生成的代码： +```python + data=Counter（lst） + return data.most_common（1）[0][0] +``` +测试用例： +```python +def check（）: + assert MostCommon（[1,2,1]）==1 + assert MostCommon（[4,0,0]）==0 + ... +``` + +针对 NL2Code 任务对 27 个具有代表性的 LLMs 进行了全面调研，表 17-12 总结了每个模型的详细信息，其中主要包括：模型架构、模型大小、模型层数（L）、注意力头数量（A）、隐藏维度（H）、模型参数是否开放（P）等五个方面。 + +表 17-12 可以完成 NL2Code 任务的 27 种大模型的总结 + + + +为了更好地可视化，图 17-2 按时间顺序展示了这些模型，绘制了最大的模型大小。观察到的一个趋势是，随着研究领域的发展，这些大型语言模型的规模也在不断扩大。此外，只有解码器的架构更适合于规模较大的预训练模型。 + + + +图 17-2 大模型时间表 + +### 17.5.3 LLMs 成功的原因 + +上面总结了 NL2Code 现有的大型语言模型（LLMs），但是这些模型在架构、模型规模等方面各不相同，无法进行统一的评估。为此，作者在 HumanEval 基准上进行了 Zero-shot 统一评估，其中 HumanEval 基准由 164 个手写的 Python 编程问题组成，对于每个编程问题都提供了测试用例，以评估生成代码正确性。使用 pass@k 作为评估指标，即通过k次尝试可以正确回答的问题的比例。表 17-13 显示根据模型大小进行分组，在该测试集上的测试结果。 + +表 17-13 在 HumanEval 上的性能指标 + + + +从表 17-13 可以看出，这些LLM在该数据集上的性能差异很大，尽管模型参数相似但效果差异也是很大。可以发现 Codex 在各种尺寸上都处于领先地位。为什么会存在这个问题呢？影响模型效果的关键因素是啥呢？作者经过分析给出的结论有：模型大小、数据质量、专家调优。 + +#### 1. 模型大小 + +根据前面的整理用于 NL2Code 的 LLMs 时间发展图可以发现，只要模型参数越多性能就越好。为了进一步说明模型参数大小和模型效果之间的关系，作者整理了 10 个比较有代表性的模型，在 HumanEval 基准上的 pass@1 结果，如图 17-3 所示： + + + +图 17-3 在 HumanEval 上的语法错误率 + +根据上图，很明显的可以发现较大的模型通常会产生更好的结果。此外，当前模型无论大小，仍然可以通过进一步增加模型参数来实现性能的提升。 + +#### 2. 数据质量 + +随着 LLMs 模型参数的增加，其训练数据规模也在不断的增加。这在数据选择和预处理方面也有更高的要求。早期的模型，例如 CodeSearchNet、CoST、XLCoST等都是基于人工标注数据对进行训练（耗时耗力）；GPT系列模型（GPT-3 、GPT-Neo、GPT-J ）开始在大规模无监督数据集上进行训练，但是由于代码数据限制，并没有显示出很强的代码生成能力。由于 LLMs 模型的出现，它们可以在更大规模的未标记代码数据集上进行训练，最终模型效果惊人。 + +在惊叹于 LLMs 效果的同时，也要知道LLMs在训练之前通常会对数据进行预处理。为此作者调研了 Codex、AlphaCode、CodeGen、InCoder和PyCodeGPT 等 5 个强大模型的数据预处理方法。发现它们具有几个共同的特点：一是删除可能自动生成或未完成的代码文件，二是使用特定的规则来过滤不常见的代码文件。总之，这些预处理策略的目标是实现一个不重复的、完整的、正确的、干净的和通用的代码语料库。 + +#### 3. 专家调优 + +训练一个优秀的模型需要认真考虑模型训练阶段的各个参数。通过对 27 个 LLMs 模型的研究发现，它们都有一些共同的设置，比如都应用了 Adam 相关优化器并在初始化阶段相差不大。除此之外，还有需要调节的超参数，如学习率、批大小、窗口大小、预热、梯度累积和温度参数。对于学习率来说，随着模型的增大，学习率会逐步变小。如图 17-4 所示： + + + +图 17-4 六个大模型上的学习率 + +对于温度参数，这里对比了两个模型在 HumanEval 任务上使用不同温度参数后模型的性能。结果发现，更高的温度参数产生更低的 pass@1 和更高的 pass@100，这表明更高的温度参数使 LLM 产生更多样化的预测，反之亦然。如图 17-5 所示： + + + +图 17-5 在 HumanEval 上的温度参数的影响 + +此外，有研究表明窗口大小也是一个关键因素，具有大窗口的小模型会有时优于具有小窗口的大模型。此外，强大的 LLMs 通常主要使用两种技术在代码语料库上训练新的标记器：字节级字节对编码和句子片段。新的标记器可以更有效和准确地将代码内容拆分为 Tokens。这些经过验证的调优技术将为培训更强大的 LLM 提供有价值的参考。 + +### 17.5.4 评估基准指标 + +对 NL2Code 任务的评估，高质量的基准和可靠的度量是基础和必要的。我们总结了 17 个 NL2Code 基准测试，每个基准测试在大小、语言、复杂性和场景方面都有自己的特点，如表 17-14 所示。 + +表 17-14 NL2Code 的 17 个指标总结 + + + +但大多数基准测试只包含有限数量的实例。例如，HumanEval 和 MBPP 分别有 164 和 974 个实例。这是因为这些基准通常是手写的以防数据泄露。在大型语言模型时代，在创建新基准时避免数据泄漏至关重要。此外，大多数当前的基准测试都有英文的问题描述和 Python 的代码解决方案。最近，已经提出了几个多语言基准，例如涵盖多种编程语言的 MBXP，HumanEvalX 和 MultiPL ，以及涵盖多种自然语言的ODEX。多语言基准测试的详细信息如表 17-15 所示： + +表 17-15 多语言测试指标 + + + +手动评估生成的代码是不切实际的，这就需要自动度量。上述基准均提供了基于执行的评估的测试用例，其中指标如 pass@k、n@k、测试用例平均值和执行精度。但是，这种方法对测试用例的质量有严格的要求，并且只能评估可执行代码。对于不可执行的代码，使用了 BLEU 、ROUGE 和 CodeBLEU 等指标，无法准确评估代码的正确性。到目前为止，在设计指标来评估代码的各个方面（例如漏洞、可维护性、清晰度、执行复杂性和稳定性）方面存在许多开放性挑战。 + +### 17.5.5 NL2Code 挑战与机遇 + +大预言模型在 NL2Code 的应用对学术界和工业界都有相当大的影响。虽然取得了惊人的进展，但仍然有很多挑战需求解决，这也为研究人员提供了充足的机会。下面作者总结了 NL2Code 任务的五个挑战和机会。 + +#### 1. 理解能力 + +自然语言固有的灵活性允许多种表达方式来传达功能需求，人类能够理解不同抽象层次的各种描述。相比之下，当前的 LLM 往往对给定的上下文敏感，这可能会导致性能下降。我们认为探索LLM 的理解能力是一个重要的研究方向，一种可能的解决方案是将复杂问题分解为多个步骤，这在推理任务中很常见。 + +#### 2.判断能力 + +人类能够判定一个编程问题是否被解决。当前模型不论输入什么都会给出答案，而且该答案正确与否都不能确定，这在实际应用中会存在一定的问题。目前为了提高 LLM 的判断能力，需要根据用户反馈采用强化学习的方式进行调优。我们认为探索 LLM 自我判断能力，也是一个比较重要的研究方向。 + +#### 3.解释能力 + +人类开发人员能够解释他们编写的代码，这对教育的和软件维护至关重要。最近的研究表明，LLM 具有自动生成代码解释的潜力。作者认为针对该能力也需要进一步的研究和探索，以充分发挥 LLM 在这方面的潜力。 + +#### 4. 自适应能力 + +当前的大型语言模型与人类之间的一个根本区别是它们适应新知识和更新知识的能力。人类开发人员能够根据文档资料实现 API 的快速开发，而 LLM 需要大量的知识和训练。我们认为如何提高 LLM 快速自学习能力也是一个比较大挑战。 + +#### 5. 多任务处理能力 + +大型语言模型已应用于各种与代码相关的任务，例如代码修复，代码搜索和代码审查，以及可以以类代码形式格式化的非代码任务方式，例如数学和化学。然而，LLM 和人类之间在多任务处理方面的能力存在差异。人类可以在任务之间无缝切换，而 LLM 可能需要复杂的提示工程。另一个证据是 LLM 缺乏能够像人类一样快速掌握多种编程语言。这些局限性揭示了未来研究的方向。 + +*由于篇幅有限，对原文有所删减，参考文章链接没有列出，有兴趣的读者可以阅读原文。* diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.6 测试代码生成.md b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.6 测试代码生成.md new file mode 100644 index 00000000..703b63f6 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/17.6 测试代码生成.md @@ -0,0 +1,178 @@ + +## 17.6 基于测试用例生成的代码生成方法 + +原文标题：CODET: Code Generation with Generated Tests +原文链接：https://arxiv.org/pdf/2207.10397.pdf +原文作者： +```txt +· Bei Chen, Microsoft Research Beijing China, beichen@microsoft.com +· Fengji Zhang, v-fengjzhang@microsoft.com +· Anh Nguyen, anhnguyen@microsoft.com +· Daoguang Zan, v-dazan@microsoft.com +· Zeqi Lin, Microsoft Research Beijing China, zeqi.lin@microsoft.com +· Jian-Guang Lou, Microsoft Research Beijing China, jlou@microsoft.com +· Weizhu Chen, wzchen@microsoft.com +``` +主要作者简介： + +陈蓓，微软亚洲研究院主管研究员。博士毕业于清华大学计算机系，师从张钹院士及朱军教授。她的研究兴趣主要为自然语言处理、大规模语言模型及其应用，例如语义解析、对话系统、代码智能等。在领域顶级会议如 NeurIPS，ICLR，ACL，EMNLP，IJCAI，AAAI，KDD 等发表论文 30 余篇。近年来在语言模型与软件工程交叉领域发表多篇论文，包括代码生成，代码修复等任务。 + +### 摘要 + +得益于预训练语言模型如 CodeX 等的发展，我们能够为给定的编程问题自动生成代码代码解决方案（以下简称为“代码解”）。一般来说，预训练语言模型会生成多个不同的代码解，而从中选择出最为准确的代码解仍然是一个很大的挑战（例如，pass@100 通常比 pass@1 高很多）。验证一个代码解准确性最简单的方法是使用一组测试用例来执行它。然而，人工构建这样的测试用例是费时费力的。本报告旨在探索这样一个问题：预训练语言模型可以进行自我验证吗？我们提出了一个有趣的方法 CODET，它能够利用相同的预训练语言模型为代码解生成多个测试用例，从而降低人工成本。CODET 将生成的多个代码解在测试用例上执行，并进行双向执行一致性判断，从而挑选出最为准确的代码解。我们使用 5 个不同大小和能力的预训练语言模型，在 4 个有名的代码生成数据集上做了试验。试验结果证实 CODET 能够极大地提升代码生成的性能，其中 CODET 将 HumanEval 数据集的 pass@1 分数提升至 65.8%，比现有最高分数还要高 20+%。 + +### 17.6.1 引言 + +尽管代码生成的预训练技术取得了显着进步，但从大型语言模型生成的多个候选者中选择正确的代码解仍然是一个难题。例如，CodeX，一种最先进的代码预训练语言模型生成，可以实现 pass@100（如果给定的 100 个生成的代码解中有一个或多个可以通过相应的测试用例）为 77.4%，但在 HumanEval 基准上的 pass@1（单个代码解的正确率）仅为 33.5%。这个巨大的差距限制了代码生成模型的实用性，并激励我们探索如何选择正确的或多个候选的最佳代码解。 + +验证代码解正确性的一种直接方法是执行代码并检查它是否通过所有相应的测试用例。这种以执行为导向的方法已在各种领域得到广泛采用与代码相关的任务，例如代码生成、代码翻译、和程序合成。然而，这种方法在很大程度上依赖于测试用例的质量和数量，而这通常是昂贵的创建和维护非常耗时。此外，在像 Copilot2 这样的真实应用中，辅助开发者编写代码的代码生成工具，指望用户提供每个问题的测试用例是不现实的。因此，我们建议自动生成任意编程问题的测试用例，并使用它们快速验证任何代码解。 + + + +图 17-6 CODET 协议 + +在本文中，我们提出了 CODET 协议，如图 17-6 所示。首先，我们利用相同的预训练语言模型生成代码解，例如 CodeX，通过提供详细说明作为提示，为每个编程问题生成大量测试用例。接下来，受经典 RANSAC 算法启发，使用双向执行协议（Dual Execution Agreement）和测试用例，在每个生成的代码解上运行测试用例，并迭代地找到多组代码解和测试用例对。每组代码都能通过相同的测试用例，表明它们具有相同的功能，即使它们在实现上不同。我们期望能通过更多测试用例的代码解是更正确的，并且具有更多相似的代码解，比如，同一共识集中的代码解与问题描述更一致。因此，我们根据其中的测试用例和代码解的数量对每个共识集进行排名，并从排名最高的共识集中选择最佳代码解。 + +这种方法简单高效，因为它不需要任何标记数据或额外的排序器，但它实现了令人惊讶的卓越性能。我们在五个预训练语言模型使用这种方法做评估：三个 OpenAI CodeX 模型，INCODER 和 CODEGEN，以及四个已建立的代码生成基准：HumanEval、MBPP、APPS 和 CodeContests。试验结果表明该方法可以有效地从多个候选者中选择正确的代码解，提高了 pass@1 在所有基准测试中的得分。例如，CODET 实现了使用 code-davinci-002 的改进：HumanEval (47.0% → 65.8%)，MBPP (58.1% → 67.7%)，APPS (27.2% → 34.6%) 和 CodeContests (0.7% → 2.1%)。此外，当我们将最强大的预训练模型 code-davinci-002 和 CODET 结合起来，大幅领先于之前最先进的方法，例如 HumanEval：42.7% → 65.8%。 + +### 17.6.2 方法 + +代码生成的任务是解决一个编程问题：在上下文 $c$ 中生成代码 $x$。 如图 17-7 所示，上下文 $c$ 中包含自然语言问题描述代码注释的形式，以及包含 imports 和 function 等语句的代码片段标头。通常，我们采样一组代码解，表示为 $X = \{x_1, x_2, ..., x_N \}$，基于在上下文 $c$ 上使用预训练的语言模型 $M$，可以表示为 $X = M(c)$。我们的目标是从一组生成的代码解 $X$ 中选择最佳代码解 $\hat{x}$，其中 $\hat{x}$ 是正确解决给定编程问题的最有可能的代码解。为此，我们提出 CODET，希望利用预训练语言模型 $M$ 的力量。具体来说，我们使用 $M$ 为编程问题生成测试用例（17.6.1-1），然后根据双向执行协议选择最佳代码解 $\hat{x}$（17.6.2-2）。 + + + +图 17-7 代码生成与测试用例生成 + +#### 1. 测试用例生成 + +除了生成代码解，还需要生成测试用例来评估其正确性。测试用例是定义在上下文函数中的一对输入和预期输出。例如，在图 17-7 中，测试用例列表中是否存在小于阈值的近似值。为了生成测试用例，我们使用与生成代码解相同的预训练语言模型 $M$，但我们添加了一条指令 $p$ 到上下文 $c$ 作为提示，表明需要测试用例而不是代码解。指令 $p$ 由三部分组成： +（1）一个“pass”语句作为占位符，这表明不需要为函数生成代码。 +（2）一条注释语句“检查入口点的正确性”，以阐明生成测试用例的意图，其中“入口点”是函数的名称。 + (3) 一条“assert”语句启动测试用例生成，指定测试用例的格式为输入-输出对。 + +然后，我们将连接的上下文和指令 $concat(c, p)$ 提供给语言模型 $M$，并从模型输出中抽取一组测试用例，表示为 $Y = \{y_1, y_2, ..., y_M\}$。测试用例的生成过程可以表示为 $Y = M(concat(c, p))$。语言模型会尝试通过为函数生成合理的输入输出对来完成指令。注意在生成代码解之前，我们从上下文 $c$ 中删除所有示例输入输出案例，以避免将真实的测试用例暴露给语言模型，并增加多样性和生成的测试用例的难度。 + +#### 2. 双向执行协议 + +在本小节中将解释如何使用生成的测试用例集 $Y = \{y_1, y_2, ..., y_M\}$ 作为一个标准从生成的代码集 $X = \{x_1, x_2,..., x_N \}$ 中选择最佳代码解 $x$。我们可以在测试用例 $y$ 上执行代码解 $x$，这意味着使用 $y$ 的输入运行由 $x$ 定义的函数，并将输出与 $y$ 的输出部分进行比较。如果代码解 $x$ 可以无错误地执行并且输出与预期输出匹配，那么代码解 $x$ 可以通过测试用例 $y$。此外，两个代码解 $x_i$ 和 $x_j$ 如果可以通过 $Y$ 中的同一组测试用例，则认为它们之间有一个功能协议（即两个函数的实现不同但具有相同的功能）。我们的方法基于以下假设： + +（1）给定某个编程问题，代码解和测试用例是独立的，并且是从预训练语言模型 $M$ 中随机抽样的。 +（2）不正确的代码解往往是多种多样的，并且在两个错误代码解之间具有功能协议的出现概率非常低。 + +这些假设是类似于经典的 RANSAC 算法，这是一个稳健的在嘈杂数据中找到共识的方法。受 RANSAC 的启发，我们提出了我们的方法 CODET 执行双向执行协议，这是一种迭代方法，如下所示： + +- 从所有可能的 $D = \{(x, y)|x ∈ X, y ∈Y\}$ 中随机选择 $(x,y)$。然后尝试在测试用例 $y$ 上执行代码解 $x$。如果 $x$ 可以通过 $y$，那么我们说 $(x, y)$ 对是一个假设解（hypothetical inlier，直译为假设的内点），因为它假设地描述了编程问题的正确功能。否则，我们说 $(x, y)$ 是异常解，因为它没有描述正确的功能。图 17-8 显示了一个简单的示例编程问题“返回数字的平方”。$(x_1, y_1)$ 和 $(x_3, y_2)$ 是两个假设解，而 $(x_1, y_4)$ 和 $(x_3, y_1)$ 是两个异常解。 + + + +图 17-8 代码解和测试用例的对应关系 + +- 如果 $(x, y)$ 是一个假设解，我们从 $D$ 中收集所有与它一致的对，形成一个集合 $S$，称为共识集。为了找到一致的对 $(x, y)$，首先找到 $x$ 可以通过的所有测试用例，记为 $S_y$。然后，我们找到所有可以通过与 $x$ 完全相同的测试用例的代码解，表示为 $S_x$。最后，共识集是包含来自 $S_x$ 的代码解和测试用例的所有对的集合来自 $S_y$，即 $S = \{(x, y)|x ∈ S_x, y ∈ S_y\}$。例如在图 17-8 中，我们可以得到 $S_x = \{x_1, x_2\}, S_y = \{y_1, y_2, y_3\}$ 来自假设解 $(x_1, y_1)$（上方绿色部分）和 $S_x = \{x_3\}，S_y = \{y_2, y_3, y_4, y_5\}$ 来自 $(x_3, y_2)$（下方紫色部分）。 + +- 我们将共识集评分为 $f(S) = |S_x||S_y|$，其中 $|S_x|$ 是 $S_x$ 中的生成代码数，$|S_y|$ 是 $S_y$ 中的测试用例数。这个分数等于在共识集中的成对的数量。直觉是，与假设一致的对越多，此功能越有可能是正确的。按照图 17-8 中的示例，$(x_1, y_1)$ 的假设共识集分数为 $2 \times 3=6$，因为 $|S_x| = |\{x_1, x_2\}|=2$，$|S_y| = |\{y_1, y_2, y_3\}|=3$；而 $(x_3, y_2)$ 的假设分数为 $1\times4=4$，因为 $|S_x| = |\{x_3\}|=1$，$|S_y| = |\{y_2, y_3, y_4, y_5\}|=4$。 + +我们重复上述过程某个次数，每次产生一个共识集和它的分数。最后，通过从共识中选择有最高分的任意代码解来获得最佳代码解 $\hat{x}$。如果我们想要获得 $k$ 个代码解，我们可以选择 Top $k$ 个得分最高的集合，并从 $k$ 个共识集合中的每一个中挑选一个代码解。 + +实际中，当 $D$ 中的代码解数不多时，我们可以简化上面的方法通过检查 $D$ 中所有可能的对，而不是从 $D$ 中采样。特别地，对于每个代码解 $x ∈ X$，我们运行 $Y$ 中的每个测试用例，并跟踪它通过了哪些测试用例。将通过相同测试用例的代码解组合在一起，因为它们具有相同的功能。这样将 $X$ 中的所有代码解分成几组，记作 $X = \{S^1_x, S^2_x,···,S^K_x \}$，其中 $K$ 是代码解组的数量。每个组 $S_x$ 都有一个集合，是它通过的测试用例的数量，我们将其写为 $S_y$。然后，我们得到 $K$ 个共识集，每个共识集都有形式 $S = \{(x, y)|x ∈ S_x, y ∈ S_y\}$。我们可以对由 $f(S) = |S_x||S_y|$ 设置的每个共识进行评分，如前。这个朴素的版本捕捉到了相同的下线直觉，但发现所有共识集都是正确的，无需重复采样。 + +### 17.6.3 试验步骤 + +#### 1. 模型 + +我们的试验基于 CodeX、INCODER 和 CODEGEN。 +- CodeX 是 GPT-3 的后代，并且能够理解所提供的上下文并生成功能程序。我们用三个 OpenAI 提供的具有不同功能的 CodeX 模型：code-cushman-001、code-davinci-001 和 code-davinci-002。 +- INCODER 是一个统一的生成模型，可以执行从左到右代码生成和代码填充，使用 INCODER 6.7B 版本 (INCODER 6B)。 +- 而 CODEGEN 是一个大型语言模型家族执行会话程序合成，使用 16B 的单语版本 (CODEGEN-MONO-16B)。 + +#### 2. 指标和基线 + +我们使用 pass@k（有 $n$ 个样本）进行性能评估和利用真实测试用例来确定代码解的功能正确性。对于每个问题，我们采样 $n$ 个代码解，然后选择其中的 $k$ 个进行评估。如果有的话 $k$ 个代码解中的一个通过了所有地面实况测试用例，则认为问题已解决。然后 pass@k 是已解决问题的百分比。我们使用 pass@k 的无偏定义作为我们的基准，其中 $k$ 个代码解是从 $n$ 个样本中随机选取的。CODET 使用双向执行协议机制从 $n$ 个样本中选择 $k$ 个代码解。此外，我们还使用包括了 Li 等人的聚类方法作为比较，表示为 AlphaCode-C。我们的复制是使用 CODET 生成的测试输入，在测试输入，按测试输出对代码解进行分组，并按大小对集群进行排序。 + +#### 3. 基准 + +我们对四个公共代码生成基准进行了试验。基准的统计数据如表 17-16 所示。 + +表 17-16 统计基准 + + + +(1) HumanEval 由手写的 Python 编程问题组成。原始上下文包括示例输入输出案例，这些案例在我们的试验中被删除以避免暴露真实的测试案例。附录 B 中的试验表明，这种去除操作是合理且必不可少的。 +(2) MBPP 包含众包 Python 编程问题，我们遵循 HumanEval 为其构建上下文。 +(3) APPS 包括从开放访问编码网站收集的编码问题，这些网站有不同的难度级别。 +(4) CodeContests 包括从 Codeforces 平台上抓取的竞争性编程问题。 + +为了启用零样本推理，我们为 APPS 和 CodeContests 构建上下文如下：原始问题描述为被视为删除输入输出示例的注释，以及一个简单的函数头“def solution(stdin : str) → str :” 放置在注释之后以容纳输入/输出数据格式。 + + +### 17.6.4 试验结果 + +在本节中，我们在五个不同的预训练模型和四个基准上评估 CODET 验证其有效性，然后通过测试用例分析和案例研究提供更多的发现。 + +#### 1. HumanEval 和 MBPP 的结果 + +各种模型在 HumanEval 和 MBPP 基准上的试验结果总结在表 17-17 中。如果我们比较基准列上的 pass@100 和 pass@1，前者明显优于后者，表明选择最佳代码解的潜力来自 100 个生成的样本。 + +表 17-17 HumanEval 和 MBPP 试验结果 + + + + +对于三个 CodeX 模型，当我们将 CODET 列与基准列进行比较时，CODET pass@1 比基线 pass@1 实现了大约 10% 的绝对改进。HumanEval 的改进始终超过 10%。令人惊讶的是，即使是最强的基线，code-davinci-002，改进为 18.8%，将 pass@1 提高到 65.8%，这比之前报告的最佳结果绝对改进了 20+%。我们将此归因于对 code-davinci-002 生成的更高质量的测试用例进行了更大的改进，提供了在第 17.6.4-3 节中进行更深入的分析。CODET 在 MBPP 基准测试中也取得了卓越的性能，尽管改进幅度略小于 HumanEval。使用以 code-davinci-002 为例，pass@1 提升了9.6%。我们还报告 pass@2 和通过 CODET 的 pass@10 进一步显示其优越性。CODET 的 pass@2 结果接近基线 pass@10 结果。同时，对 pass@10 的改进也始终高于 HumanEval 基准测试的 10%。 + +INCODER-6B 和 CODEGEN-MONO-16B 的试验结果进一步验证了 CODET 的有效性。很明显，CODET 可以显着提高 pass@1，绝对提高范围为 4.2% 到 13.1%。INCODER-6B 实现了最大的改进，比 MBPP 基准上涨 13.1%。与 CodeX 的试验结果相似，pass@2 结果接近基线 pass@10。所有结果都表明 CODET 可以提高各种预训练语言模型的性能一致。 + +至于 AlphaCode-C，它在使用不同模型的两个基准测试中始终不如 CODET，证明了我们采用测试用例信息的双向执行协议的优越性考虑在内。 + +#### 2. APPS 和 CodeContests 的结果 + +我们还在两个更具挑战性的基准测试 APPS 和 CodeContests 上进行了试验。我们构建 APPS 和 CodeContests 的零样本版本，以符合我们对 HumanEval 的设置和 MBPP 通过删除问题描述中的示例输入输出案例。我们使用 code-davinci-002 用于代码解和测试用例生成。APPS 采样数设置为 50 以节省计算成本，一共 5000 个测试问题上。而对于 CodeContests，采样数设置为 1000 以解决特别难的问题。结果总结在表 17-18 中，我们可以清楚地观察到一致的性能改进在使用 CODET 的两个基准测试中。APPS 中的问题的 pass@1 改进为 7.4%，而对于竞争基本问题，APPS 和 CodeContest 改进并不大。此外，我们注意到代码-davinci-002由于这两个基准的难度更高。 + +表 17-18 APPS 和 CodeContests 的试验结果 + + + + +#### 3. 测试用例分析 + +测试用例对 CODET 至关重要，因为其核心思想是基于测试驱动的执行协议。因此，在本小节中，我们通过回答以下研究问题来分析测试用例。 + +**（1）Q1：生成的测试用例的质量如何？** + +我们使用规范代码解评估生成的测试用例的正确性。一个测试用例是如果规范代码解可以通过它，则认为是正确的。图 17-9a 总结了分布 HumanEval 上的测试用例准确度，其中横轴表示每个的准确度值问题，纵轴表示对应问题的概率密度精度值。我们可以看到 CodeX 模型生成的测试用例要高得多，准确率高于 CODEGEN/INCODER。除了准确率，我们还引入了测试用例毒性率作为质量的衡量标准。如果任何生成的代码解都可以，我们认为测试用例是“有毒的”通过它而规范的代码解不能。有毒的测试用例可能会阻碍共识的评分设置并导致 CODET 失败。如图 17-9b 所示，我们可以发现毒性率与不同模型的测试用例准确性高度相关，其中比例 CodeX 模型的毒性测试用例数量小于CODEGEN/INCODER。我们还评估了使用附录 H.2 中的两个覆盖标准生成的测试用例的代码覆盖，其中 CodeX 模型仍然优于 CODEGEN/INCODER，平均覆盖率超过 95%。比较表 17-7 所示的测试用例质量和 CODET 的性能，我们可以发现质量测试用例的数量与使用关于不同模型的 CODET 的性能增益密切相关。 + + + + +图 17-9 测试用例准确率与毒性率 + +**（2）Q2：更好的测试用例能否进一步提升平庸模型的性能？** + +从上面与图 17-9 的讨论，可以发现 code-davinci-002 是最有能力的生成高质量测试用例的模型。因此，我们进行了一项试验，通过使用 code-davinci-002 生成的测试用例，以提高其他四种模型（code-cushman-001、ode-davinci-001、INCODER 和 CODEGEN）的性能。表 17-19 总结了性能改进是基于 HumanEval 和 MBPP 基准的不同模型。一般来说，使用测试 code-davinci-002 生成的案例可以显着提高使用测试的性能由能力较差的模型本身生成的案例。对于 code-cushman-001 和 code-davinci-001，pass@1 的绝对改进在 1.8% 到 4.3% 之间，而对于 INCODER 和 CODEGEN，范围从 6.2% 到 15.9%。以上结果表明正确的代码通过采用更好的测试用例，可以进一步利用平庸模型生成的代码解。 + +表 17-19 使用 code-davinci-002 生成的测试用例的代码解性能 + + + + +**（3）Q3：当测试用例较少时，CODET 的效果如何？** + +在为 HumanEval 基准生成测试用例时，我们对每个问题抽样 100 次，每个样本可能包括多个断言语句（即测试用例），记为Sampling Number = 100。然后我们提取第一个来自每个样本的 5 个句法正确的测试用例，表示为as Limit = 5. 这意味着每个问题都配备了最多 500 个测试用例。提取测试的实际数量案例总结在附录 H.1 中。我们通过减少采样数和限制来对测试用例的数量进行消融研究。如表 17-20 所示，我们可以得出结论，在 CODET 中使用更多的测试用例通常可以导致更好的性能，而当 Sampling Number ≥ 50 且 Limit ≥ 3 时，性能差距缩小。此外，CODET 将 pass@1 提高了 9.5%，仅 10测试用例使用 code-davinci-002，建议高考案例效率。我们可以在中使用较小的采样数实际应用程序以平衡性能和计算成本。 + +表 17-20 较少的测试用例时的 CODET 方法的性能 + + + + +#### 4. 案例研究 + +在 CODET 中，我们基于好的代码解可以通过最多的测试用例并同意最多的相同功能的代码解。我们使用“双”因为代码解和测试用例都很关键。图 17-10a 显示了一个案例使用 code-cushman-001 的 HumanEval 基准测试。得分最高的共识集具有正确的如果列表中的所有数字都低于阈值 t，则返回 true 的功能，而共识集排在第 2 位的人并没有完全理解边界条件。第二次共识中的代码解共识集可以通过比第一个共识集（即 218）更多的测试用例（即 226）。然而，考虑到代码解和测试用例，CODET 可以成功地对共识集进行排名，并且找到正确的代码解。这种情况并不少见，说明我们设计的双向执行协议的合理性。为了进一步的统计证明，我们进行了一项消融研究来评分通过仅考虑代码解或测试用例的数量来达成共识。 + + + + + +图 17-10 案例 + +CODET 由预训练的语言模型赋能，但也受到它们的限制。所以，第 2.2 节中的第二个假设并不总是成立，导致错误情况8个生成了正确的代码解，但不在前 1 个共识集中。对于在 HumanEval 基准测试中代码为 cushman-001 的 CODET，我们发现 164 个编程问题中有 53 个是属于这种情况。我们手动调查了这些问题，发现其中 20% 可以被归咎于诸如问题描述不明确、角落案例未被发现和缺乏导入语句，而其余问题归因于模型的失败理解问题描述。图 5b 显示了由歧义引起的错误情况。这正确理解描述“sum(first index value, last index value)”是把第一个加起来和最后一个值，而将所有值从第一个到最后一个求和的代码解排名第一。 + +*由于篇幅有限，对原文有所删减，参考文章链接没有列出，有兴趣的读者可以阅读原文。* diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-1.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-1.png new file mode 100644 index 00000000..3b96527d Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-1.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-2.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-2.png new file mode 100644 index 00000000..774f0606 Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-2.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-3.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-3.png new file mode 100644 index 00000000..1dc5718b Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-3.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-4.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-4.png new file mode 100644 index 00000000..ce5843d6 Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-4.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-5.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-5.png new file mode 100644 index 00000000..10f2d3d4 Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-5.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-6.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-6.png new file mode 100644 index 00000000..6cb0e8d9 Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-6.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-7.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-7.png new file mode 100644 index 00000000..b2fc92cd Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-7.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-8.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-8.png new file mode 100644 index 00000000..7ba00667 Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-5-8.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-1.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-1.SVG new file mode 100644 index 00000000..cdbcd681 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-1.SVG @@ -0,0 +1 @@ +Test CaseGenerationPre-trained Language ModelDualExecutionAgreementCode Solution1Code Solution2……Test Case1Test Case2……CodeGeneration+InstructionA Programming ProblemThe Best Code Solution \ No newline at end of file diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-1Table.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-1Table.png new file mode 100644 index 00000000..247ecb5e Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-1Table.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-2.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-2.SVG new file mode 100644 index 00000000..2797b9b0 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-2.SVG @@ -0,0 +1 @@ +fromtypingimportListdefhas_close_elements(numbers:List[float],threshold:float)->bool:"""Check if in given list of numbers,are any two numbers closer to each otherthan given threshold."""pass# check the correctness ofhas_close_elementsassertContext𝑐Instruction𝑝foridx,eleminenumerate(numbers):foridx2,elem2inenumerate(numbers):ifidx!=idx2:distance=abs(elem-elem2)ifdistance< threshold:returnTruereturnFalseCode GenerationCode Solution𝑥1Code Solution𝑥2Code Solution𝑥𝑁…asserthas_close_elements([1.0,2.0,3.9,4.0,5.0,2.2],0.3) ==TrueTest Case GenerationTest Case𝑦1Test Case𝑦2Test Case𝑦𝑀… \ No newline at end of file diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-2Table.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-2Table.png new file mode 100644 index 00000000..0495de1a Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-2Table.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-3.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-3.SVG new file mode 100644 index 00000000..59cc8aa2 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-3.SVG @@ -0,0 +1 @@ +ELT layoutCode Solutionsreturna**2returna*areturna*2Test Casesassertnum_square(1) ==1assertnum_square(2) ==4assertnum_square(1) ==2assertnum_square(3) ==6assertnum_square(0) ==0𝑥1𝑥2𝑥3𝑦1𝑦2𝑦3𝑦4𝑦5returna𝑥4 \ No newline at end of file diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-3Table.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-3Table.png new file mode 100644 index 00000000..9834e2eb Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-3Table.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4Table.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4Table.png new file mode 100644 index 00000000..13297e6b Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4Table.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4a.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4a.SVG new file mode 100644 index 00000000..1764b5b5 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4a.SVG @@ -0,0 +1,113 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +0.0 + + +0.1 + + +0.2 + + +0.3 + + +0.4 + + +0.5 + + +0.6 + + +0.7 + + +0.8 + + +0.9 + + +1.0Test Case Accuracy + + +0.0 + + +0.1 + + +0.2 + + +0.3 + + +0.4 +Problem Probability Density + + + + + + + + + + + + +cushman-001 +davinci-001 +davinci-002 +I +N +C +ODER +C +ODE +G +EN + diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4b.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4b.SVG new file mode 100644 index 00000000..2717c4b2 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-4b.SVG @@ -0,0 +1,107 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +0.0 + + +0.1 + + +0.2 + + +0.3 + + +0.4 + + +0.5 + + +0.6 + + +0.7 + + +0.8 + + +0.9Test Case Toxicity Rate + + +0.0 + + +0.2 + + +0.4 + + +0.6 +Problem Probability Density + + + + + + + + + + + + +cushman-001 +davinci-001 +davinci-002 +I +N +C +ODER +C +ODE +G +EN + diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5Table.png b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5Table.png new file mode 100644 index 00000000..2e47457f Binary files /dev/null and b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5Table.png differ diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5a.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5a.SVG new file mode 100644 index 00000000..c12292bc --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5a.SVG @@ -0,0 +1 @@ +defbelow_threshold(l:list,t:int):"""Return True if all numbers in thelist l are below threshold t."""ifl== []:returnTruereturnl[0] <tandbelow_threshold(l[1:],t)foreinl:ife>t:returnFalsereturnTrueRank #1: The consensus set has61solutionsand218test cases.Rank #2: The consensus set has30solutionsand226test cases.CorrectIncorrect \ No newline at end of file diff --git a/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5b.SVG b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5b.SVG new file mode 100644 index 00000000..30308f49 --- /dev/null +++ b/基础教程/A5-现代软件工程（更新中）/第8步 - 前沿与探索/第17章 - 前沿探索/img/17-6-5b.SVG @@ -0,0 +1 @@ +defsort_array(array):"""Given an array of non-negative integers, return a copy ofthe given array after sorting, you will sort the givenarray in ascending order if the sum( first index value,last index value) is odd, or sort it in descending orderif the sum( first index value, last index value) is even."""Rank #1: The consensus set has4solutions and138test cases.Rank #2: The consensus set has3solutions and158test cases.Correctinitial_sum=sum(array[0:1])+sum(array[-1:])ifinitial_sum%2==0:returnsorted(array,reverse=True)else:returnsorted(array)sum=0foriinrange(len(array)):sum+=array[i]ifsum%2==0:array.sort(reverse=True)else:array.sort()returnarrayIncorrect \ No newline at end of file