谷歌内部工具中基于人工智能的软件工程辅助的进展以及我们对未来的预测。
2019 年，无论是谷歌还是其他任何地方的软件工程师，都会听说过机器学习的进步，以及深度学习在计算机视觉或语言翻译等领域的卓越表现。然而，他们中的大多数人不会想象，更不用说体验到机器学习如何使他们的工作受益。
仅仅五年后，也就是 2024 年，软件工程师们对人工智能如何帮助编写代码产生了普遍的热情。其中相当一部分人已经使用了基于机器学习的自动完成功能，无论是使用大型公司的内部工具（例如Google 的内部代码完成功能），还是通过市售产品。
在这篇博客中，我们在 Google 内部软件开发工具持续转型的背景下介绍了我们最新的 AI 驱动改进，并讨论了我们预计在未来 5 年内会看到的进一步变化。我们还介绍了如何构建可为专业软件开发带来价值的 AI 产品的方法。我们的团队负责 Google 工程师花费大部分时间的软件开发环境，包括内部循环（例如 IDE、代码审查、代码搜索）以及外部循环界面（例如错误管理、规划）。我们说明，这些界面的改进可以直接影响开发人员的生产力和满意度，这两个指标都是我们密切监控的。
挑战
这一领域的一个持续挑战是，人工智能技术发展迅速，很难预测首先要探索哪些想法。技术上可行的演示与成功的产品化之间往往存在巨大差距。我们遵循以下三条准则将想法部署到产品中：
按技术可行性和影响力确定优先顺序：研究已经建立技术可行性并且预计对工程师的工作流程产生高（可衡量）影响的想法。
快速学习，提高用户体验和模型质量：专注于快速迭代和吸取经验教训，同时保障开发人员的生产力和幸福感。用户体验与模型质量同样重要。
衡量有效性：由于我们的目标是提高生产力和满意度指标，因此我们需要广泛监控这些指标。
将法学硕士 (LLM) 应用于软件开发
随着Transformer架构的出现，我们开始探索如何将 LLM 应用于软件开发。基于 LLM 的内联代码补全是 AI 应用于软件开发的最流行应用：使用代码本身作为训练数据是 LLM 技术的一个自然应用。由于单词级自动补全多年来一直是 IDE 的核心功能，因此开发人员对用户体验感觉很自然。此外，还可以使用粗略的影响衡量标准，例如 AI 编写的新字符的百分比。出于这些原因以及其他原因，将 LLM 的这一应用作为第一个部署是有意义的。
我们之前的博客描述了我们通过代码补全改善用户体验的方法以及我们如何衡量影响。从那时起，我们看到了与其他企业环境类似的持续快速增长，软件工程师的接受率为 37%[1]协助完成50%的代码字符[2]换句话说，现在通过人工智能辅助完成的代码字符数量与开发人员手动输入的字符数量相同。虽然开发人员仍然需要花时间审查建议，但他们有更多的时间专注于代码设计。
关键改进来自模型（具有改进的编码能力的更大模型、用于构建提供给模型的上下文的启发式方法，以及针对包含接受、拒绝和更正的使用日志调整模型）和用户体验。这个循环对于从实际行为而非合成公式中学习至关重要。
AIforSE-Hero1
利用跨工具的历史高质量数据以及捕获用户偏好和需求的使用数据来改进编码工具（例如，在 IDE 中）中基于 AI 的功能。
AIforSE-LineGraph2
通过代码补全利用人工智能辅助编写的代码比例持续增加，定义为从基于人工智能的建议中接受的字符数除以手动输入的字符数与从基于人工智能的建议中接受的字符数之和。值得注意的是，分母中不包括复制粘贴的字符。
我们使用多年来精心策划的跨多种工具的大量高质量内部软件工程活动日志。例如，这些数据使我们能够表示细粒度的代码编辑、构建结果、解决构建问题的编辑、代码复制粘贴操作、粘贴代码的修复、代码审查、修复审阅者问题的编辑以及对存储库的更改提交。训练数据是一个对齐的代码语料库，在输入和输出中都有特定于任务的注释。我们的 DIDACT 博客描述了数据收集过程的设计、训练数据的形状以及基于这些数据进行训练的模型。我们将继续使用可用的新一代基础模型（下面将详细讨论）探索这些强大的数据集。
我们的下一个重要部署是解决代码审查注释（其中 8% 以上现在通过基于 AI 的帮助解决）并自动将粘贴的代码调整到周围环境中（现在负责 IDE2 中约 2% 的代码）。进一步的部署包括指示 IDE 使用自然语言执行代码编辑并预测构建失败的修复方法。其他应用，例如，按照类似模式预测代码可读性的提示也是可能的。
总的来说，这些已部署的应用程序在 Google 内部都是成功的、使用率很高的应用程序，对真实的工业环境中的生产力产生了可衡量的影响。
演示各种基于 AI 的功能如何协同工作以协助 IDE 中的编码。
我们学到了什么
迄今为止的工作教会了我们几件事：
我们通过自然融入用户工作流程的用户体验取得了最大的效果。在所有上述示例中，都会向用户显示建议，只需一个选项卡或点击即可将他们带到工作流程的下一步。需要用户记住触发该功能的实验未能扩展。
我们观察到，通过基于人工智能的建议，代码作者越来越多地成为审阅者，在审阅成本和附加值之间找到平衡非常重要。我们通常通过接受率目标来解决这一权衡问题。
通过在线 A/B 实验进行快速迭代是关键，因为离线指标通常只是用户价值的粗略代表。通过在内部工具上展示基于 AI 的功能，我们能够轻松启动和迭代、测量使用数据并通过 UX 研究直接询问用户的体验，从而受益匪浅。
来自 Google 工程师在软件工具中的活动（包括与我们的功能的交互）的高质量数据对于我们的模型质量至关重要。
我们通过观察发现，优化从机会（主要是用户活动，显示在下方漏斗顶部）到影响（应用人工智能辅助，在漏斗底部）的转化非常重要，同时通过利用用户体验和模型改进来消除漏斗中间步骤的瓶颈。
AIforSE-FunnelFinal4
从 SWE 操作到实际应用基于 ML 的建议，这是一个机会漏斗。如果模型预测不够准确、模型没有响应或响应太晚、预测不理想、用户没有注意到预测等，机会就会丢失。我们使用 UX 和模型改进来收获尽可能多的机会。
下一步
受迄今为止所取得的成功的鼓舞，我们正在加倍努力，将最新的基础模型（Gemini 系列）与开发人员数据（作为上面提到的DIDACT的一部分）融合，为 Google 软件工程中现有和新的 ML 应用提供支持。
在整个行业中，基于 ML 的代码补全为软件开发人员提供了巨大的推动力。虽然仍有机会改进代码生成，但我们预计下一波好处将来自 ML 在更广泛的软件工程活动中的帮助，例如测试、代码理解和代码维护；后者在企业环境中尤其令人感兴趣。这些机会为我们正在进行的工作提供了参考。我们还强调了我们在行业中看到的两个趋势：
人机交互已经转向以自然语言作为通用方式，我们看到人们正在转向使用语言作为软件工程任务的界面以及软件开发人员信息需求的门户，所有这些都集成在 IDE 中。
基于机器学习的大型任务自动化（从问题诊断到解决问题）已开始显示出初步可行性。这些可能性是由代理和工具使用的创新推动的，这些创新允许构建使用一个或多个 LLM 作为组件来完成大型任务的系统。
为了将上述成功扩展到下一代功能，从事此主题的从业者和研究人员社区将受益于通用基准，以帮助将该领域推向实际工程任务。到目前为止，基准主要集中在代码生成（例如HumanEval）。然而，在企业环境中，针对更广泛任务的基准可能特别有价值，例如代码迁移和生产调试。一些基准，例如用于错误解决的基准（例如SWEBench），以及针对这些基准的原型（例如来自Cognition AI）已经发布。我们鼓励社区团结起来，建议更多的基准，以涵盖更广泛的软件工程任务。
致谢
该项目是 Google 核心系统和体验团队以及 Google Deepmind 许多人共同努力的成果。本文由 Boris Bokowski（Google 编码工具总监）、Petros Maniatis（研究）、Ambar Murillo（UXR）和 Alberto Elizondo（UXD）共同撰写。衷心感谢各专题的贡献者：Adam Husting、Ahmed Omran、Alexander Frömmgen、Ambar Murillo、Ayoub Kachkach、Brett Durrett、Chris Gorgolewski、Charles Sutton、Christian Schneider、Danny Tarlow、Damien Martin-Guillerez、David Tattersall、Elena Khrapko、Evgeny Gryaznov、Franjo Ivancic、Fredde Ribeiro、Gabriela Surita Guil、 Herme Herzog、Henrik Muehe、Ilia Krets、Iris Chu、Juanjo Carin、Katja Grünwedel、Kevin Villela、Kristóf Molnár、Lera Kharatyan、Madhura Dudhgaonkar、Marcus Revaj、Nimesh Ghelani、Niranjan Tulpule、Pavel Sychev、Siddhant Sanyam、Stanislav Pyatykh、Stoyan Nikolov、Ugam Kumar、 Tobias Welp、Vahid Meimand、Vincent Nguyen、Yurun Shen 和 Zoubin Ghahramani。感谢 Tom Small 为本文制作图形。还要感谢贡献者 DIDACT、 构建修复、 可读性修复和 解决代码审查评论。
评论