谷歌内部的 AI 智能粘贴，有 6.9%使用了智能粘贴，接受率为 42.5%

译自 https://research.google/

大多数开发人员在日常工作中经常复制和粘贴代码，以避免不必要的重复转录。虽然这加快了代码开发的进程，但它不仅仅是简单的复制粘贴。

对 Google 的代码存储库的分析揭示了用户行为中有趣的模式，这些模式是提高效率的潜在目标。

例如，根据编辑历史记录，约 25% 的粘贴会被立即修改，编辑范围从小的语法修复（例如，添加缺失的分号）到对周围代码上下文的更复杂的调整（例如，重命名变量并更改其类型）。

进行此类更改通常会打断代码编写的流程并减慢开发过程。

考虑到这一点，我们推出了 Smart Paste，这是 Google 现已广泛提供的一种工具，它可以预测代码环境的下一个状态，并使用生成式 AI 对粘贴的代码进行上下文感知调整。

利用大型序列模型的最新进展（例如DIDACT，它使代码审查、构建修复等工具成为可能），Smart Paste 简化了代码修订期间的复制粘贴过程。

在一项涉及约 4 万名采用该功能的工程师的使用研究中，我们发现 IDE 中所有粘贴中有 6.9% 使用了 Smart Paste，接受率为 42.5%，这大大简化了用户工作流程。

在粘贴Floor时，Smart Paste 会检测Ceil缺少的逻辑，并建议修改函数名称和运算符。

对于模型训练，我们从 Google monorepo 和相关的综合日志中获取了粘贴后编辑的数据。由于这些数据的质量至关重要，我们设计了一套简单的启发式方法，将粘贴后调整的概念限制在靠近原始粘贴位置的调整范围内。

利用这些启发式方法，我们从前几个月中提取了一个训练数据集，并手动评估了生成的示例，不断迭代，直到达到提取启发式方法的最佳状态。在此过程中，我们注意到 28% 的粘贴没有后续编辑（不同编程语言之间的差异从 23% 到 41% 不等）。我们将这些示例保留在训练数据集中，因此模型也可以学习输出“无需编辑”。

我们使用了来自DIDACT 的针对编码相关任务进行预先训练的模型，并使用带注释的数据集对其进行了微调。

对于模型训练，我们从Google的单一代码库中获取了粘贴后编辑的数据以及相关的全面日志。由于这些数据的质量至关重要，我们设计了一套简单的启发式规则，将粘贴后调整的概念限定在原始粘贴位置附近。

正确地平衡速度与准确性之间的关系

为了让开发人员保持流畅的工作状态，该模型必须既快速又准确。

它需要在提出完全准确的编辑建议和展示可能具有一定价值但需要后续更改的推测性建议之间找到恰当的平衡。

我们的探索始于随意选择的一个模型基线，该模型被调整到 65%的精确匹配精度，即建议与我们评估集中预期目标完全匹配的百分比。

在离线实验中，对不同大小和不同属性的模型进行迭代，我们仅以显著的延迟增加为代价，实现了边际质量改进。经过多次实验迭代和训练数据的细化，我们确定了约 150 毫秒的延迟是合适的。

找到合适的用户体验（UX） 我们的目标是设计一个简单的交互模型，它能以清晰且及时的方式提出高置信度的编辑建议。

建议置信度由一个分数阈值设定，该阈值是在离线评估阶段获得的，被设置为与原始训练数据中 65%的建议完全匹配。

如果一个建议超过了这个阈值，它就会在编辑器中用装饰性的用户界面元素显示出来。为了避免打断流程，如果用户除了接受建议之外做了任何其他操作，建议就会自动被丢弃。

让建议显示足够长的时间我们在内部向大约 3000 名工程师推出了智能粘贴的测试版，并观察他们的交互行为。我们注意到在大约 27%的情况下，建议在用户甚至没有注意到它们（即在显示后不到 500 毫秒）就被丢弃了。为了缓解这个问题，我们在显示一个建议后增加了 1.5 秒的窗口，在此期间简单的光标移动不会丢弃它。我们发现这让用户能够注意到这些建议，同时又不会用过时的信息污染用户界面。

这一改变使接受率提高了约 15%。

最初，在我们的集成开发环境（IDE）中有两种用户界面模式可用于显示建议的编辑：变灰的文本（类似于用于代码补全的那种）或完整的差异视图。

前者无法显示删除，而后者给用户带来了显著的认知负担，导致不必要的干扰。

所以，我们转而决定探索各种新颖的模式来可视化这些建议。

我们考虑“自动应用这些提示”，并突出显示这些变化，使用户能够审查并可能撤销它们。

Auto-apply displays the inserted / modified flagfile in bold and underlined.

虽然在我们这群人工智能爱好者早期测试者中，对这种模式的总体反应非常积极，但在我们随后的用户体验研究中接受采访的其他用户表达了担忧，并对未被注意到的不想要的代码变化的可能性感到不舒服。

默认情况下，在这种模式下不显示建议的删除，这一问题更加突出。

我们得出结论，自动应用模式不仅可能会降低用户对智能粘贴的信任，也可能会降低对其他人工智能功能的信任，所以我们决定不采用它。

最后，我们考虑以一种内联差异的形式直接在编辑器中显示插入和删除的代码片段，用户必须通过既定的 TAB 快捷方式（用于内联代码补全和智能感知）明确接受。

内联差异突出显示了对“tryfromenv”的删除（删除线）以及“flagfile”的插入（斜体且透明度较低）。

总体积极的用户反馈（从内部论坛、讨论和用户体验研究中收集）表明，这种模式做出了正确的权衡，即它允许用户保持控制，同时对建议的变化提供了足够的概述。我们在谷歌为智能粘贴选择了这种方法。

未来的思考

在未来，我们计划重新审视针对小的高置信度变化的自动应用模式。

少于 10 个字符的建议的接受率与包含 10 到 100 个字符的建议相比几乎低了一半。

我们假设这可能是因为用户在粘贴后立即自己添加了建议的变化（例如，在粘贴一整行后添加一个缺失的分号），从而使建议过时。智能粘贴的下一步是探索该模型在复制粘贴交互之外提供有用建议的能力。

受到该功能在实际使用中的启发，例如，在重命名和复制粘贴后自动适应对一个属性的所有引用（如下所示），我们计划研究不同的触发机制和用户体验解决方案。

结果

在对大约 4 万名工程师的用户行为进行检查时，我们发现集成开发环境中所有粘贴操作中有 6.9%使用了智能粘贴，接受率为 42.5%，这节省了开发人员大量的精力。

进一步仔细检查发现，在所有粘贴事件中，该模型在 48.4%的情况下生成具有足够高置信度的建议。

我们仅当一个建议在屏幕上可见超过 500 毫秒时，才将其视为“在屏幕上显示”，这样用户就有时间阅读和考虑它。

目前，生成的建议中有 33.6%满足这一标准（占所有粘贴事件的 16%）。

在这些显示的建议中，有 42.5%被用户接受，因此相当于集成开发环境中所有粘贴事件的 6.9%。

有趣的是，随着时间的推移，接受率有所增加，而模型或用户体验没有任何重大变化。我们假设这是由于学习曲线和对智能粘贴的熟悉程度，因为代码作者随着时间的推移学会了信任和使用它。 

结论

我们推出了智能粘贴，这是一项新颖的功能，它为粘贴的代码提供人工智能生成的、上下文感知的调整。

它现在在谷歌最常用的集成开发环境中默认启用，谷歌员工每周接受其数十万条建议。

原文链接：https://research.google/blog/smart-paste-for-context-aware-adjustments-to-pasted-code