技术摘要：用于 IDE 内代码补全的控制模型

问题陈述

将大语言模型（LLM）集成到集成开发环境（IDE）中，在用户流和资源效率方面引入了显著挑战。虽然 LLM 提供了强大的代码补全能力，但它们经常生成与开发者当前心智状态和经验水平不匹配、时机不当或错误的建议。这种不匹配会导致干扰性的交互、不必要的上下文切换以及浪费的推理成本。

当前数据显示，仅约 31% 的 LLM 推理会产生显示的补全内容，而在这些显示的补全中，只有 31% 被用户接受。此外，许多显示的补全在生成时已不再符合代码上下文。作者认为，仅仅提高内容生成的质量是不够的；必须管理开发者与 AI 之间的交互动态，以防止对开发者的心流（flow）造成干扰。

方法论

本文介绍了控制模型（Control Models）：旨在干预代码补全流水线的轻量级机器学习分类器。这些模型并不生成代码，而是决定何时触发推理以及是否显示生成的建议。

模型架构

作者评估了两种主要的架构方法：

1. 梯度提升模型（CatBoost）： 这些模型基于表格遥测数据运行。选择它们是因为其对类别特征的鲁棒性和低推理延迟，使其适用于频繁的交互。
2. 基于 Transformer 的模型： 这些模型将标量/表格特征与原始代码上下文相结合。它们采用混合设计，利用一个 100M 参数的代码生成模型作为理解代码范围的骨干，通过多层感知器（MLP）对表格特征进行编码，并在连接前进行拼接，最后接入分类头。

数据与特征

训练和评估使用了来自 JetBrains 云端推理补全服务（Mellum）的匿名特征使用日志。

• 表格遥测： 包括类别和标量特征，如打字速度、光标作用域、先前操作以及静态分析输出。
• 代码上下文： 光标周围的原始代码片段（由于隐私限制，主要针对脱机环境下的 Kotlin 进行收集）。
• 标签： 补全被标记为正向（用户通过 Tab 键接受）或负向（通过 Escape 键、鼠标点击或移动光标被忽略或明确拒绝）。

评估策略

研究采用了三管齐下的评估方法：

1. 离线分析： 比较 Boosting 模型与 Transformer 模型在不同假阴性率（FNR）下的表现，以确定过滤掉糟糕建议与错过优秀建议之间的权衡。
2. 跨语言离线评估： 在语法多样性较高的语言（Kotlin、Python、PHP、C#）上测试 Boosting 模型，以评估其泛化能力。
3. 在线 A/B 测试： 在生产环境中部署基于 Boosting 的模型，以衡量对用户指标的实际影响。

核心贡献

本文提出了三个主要贡献：

1. 控制模型的实证验证： 通过离线分析和在线 A/B 研究证明，轻量级的、基于提升（boosting）的触发器和过滤分类器可以减少约 20% 的推理请求，同时提高 JetBrains IDE 中的补全质量指标。
2. 模型架构分析： 通过大规模实证证据，强调了 Transformer 模型结合上下文代码理解与 IDE 内特征的潜力，同时也记录了在生产环境中采用小型 Boosting 模型时面临的关于延迟、隐私和后端集成的实际障碍。
3. 未来方向讨论： 对评估指标进行了批判性审查，主张转向衡量长期生产力增益，而非仅仅是即时接受率。作者还提议探索用户个性化以及如端到端强化学习等替代架构。

结果

离线性能

• Boosting 对比 Transformers： Transformer 模型展示了在减少绝对符号完成数量方面比 Boosting 模型更小的影响下，能够过滤掉更多的生成内容。然而，在提高**接受率（AR）和取消率（CR）**方面，Boosting 模型在更高的过滤率下表现优于 Transformer。这归因于率值指标的分母（显示的补全次数）受 Boosting 方法过滤策略的影响较小。
• 语言差异： 性能在不同语言之间存在显著差异。例如，在 Kotlin 中，过滤模型更为有效；而在 PHP 中，触发模型在特定的假阴性率下提供了更好的控制。作者指出，过滤模型通常可以获得更多信息（生成的补全特征），但有时受限于较小的训练集，因为禁用这些模型在生产环境中存在风险。

在线 A/B 研究

研究在 Java、Python 和 Kotlin 的生产环境中部署了基于 Boosting 的模型。

• 过滤模型： 导致接受率显著提升（+32.9% 至 +47.6%）以及取消率降低（-15.5% 至 -36.7%）。然而，这是以**完成代码比例（RoCC）**下降（-9.6% 至 -14.0%）为代价的，证实了离线研究的发现，即激进的过滤会减少总体的代码插入量。
• 触发模型： 在触发模型消融实验中（即过滤模型在两组中均存在），该模型成功阻止了约 20% 的补全生成。然而，观察到的用户总生成补全次数的减少仅为 13.8%。作者将其归因于补全事件的依赖性：通过改变用户的交互流，触发模型无意中创造了新的补全机会，从而缓解了预期的容量减少。

意义与主张

本文将控制模型定位为将 LLM 集成到开发者工作流中的必然演进。作者主张：

• 效率与质量： 更智能的触发和过滤可以将推理成本与交付给用户的价值解耦，在节省计算资源的同时增强工具的感知质量。
• 以用户为中心的设计： 重点必须从单纯优化 LLM 的输出转向优化与 LLM 的交互。这包括使建议与开发者的心流和心理状态保持一致。
• 指标演进： 当前指标（如接受率）主要衡量感知生产力。作者主张开发能够捕捉长期生产力增益和可维护性的指标，并指出短期的“加速”并不总是等同于有效的软件交付。
• 个性化： 未来改进的“最易实现目标”在于设计能够适应个人偏好的模型，因为接受或拒绝建议往往是个人风格问题，而非客观的代码质量问题。

作者总结道，虽然 Transformer 模型提供了深度的上下文理解，但目前 IDE 中关于延迟和隐私的实际约束使得高效的基于 Boosting 的控制模型更具优势，同时也为开发更具个性化且高度集成的交互策略指明了清晰路径。