[论文] 使用开发者行为遥测进行预过滤代码建议以优化 LLM 辅助编程
发布: (2025年11月24日 GMT+8 15:42)
7 min read
原文: arXiv
Source: arXiv - 2511.18849v1
概览
大型语言模型(LLM)如今已成为现代 IDE 的标配,提供即时代码补全和整段函数建议。然而,大量基于 AI 的提示从未被使用,导致计算资源浪费、延迟升高以及开发者体验噪声增多。
论文《使用开发者行为遥测进行代码建议预过滤以优化 LLM 辅助编程》提出了一种体积小、保护隐私的模型,决定是否调用 LLM,仅依据实时编辑器遥测(打字速度、光标移动、文件切换等)。在一次为期四个月、使用 VS Code 插件的现场研究中,该过滤器几乎将建议接受率翻倍,同时削减了 35 % 的不必要 LLM 调用。
关键贡献
- 仅行为的预过滤器: 一个轻量级分类器,仅使用非代码遥测预测建议接受率,绝不检查源码或 LLM 提示。
- 生产规模评估: 在真实的 VS Code 插件中部署,服务数千名开发者四个月,提供了稳健、自然的数据。
- 显著的用户体验与效率提升: 接受率从 18.4 % 提升至 34.2 %;削减了 35 % 的低价值 LLM 调用,降低了延迟和云计算成本。
- 隐私优先设计: 所有特征均来源于本地交互信号,保持用户代码和意图私密。
- 开源参考实现: 作者公开了遥测收集管道和预过滤模型,供社区实验。
方法论
- 遥测收集: 插件将轻量级编辑器事件(按键时间戳、光标跳转、文件打开/关闭、焦点变化)流式传输到本地特征提取器。没有源码或文本片段离开开发者机器。
- 特征工程: 在滑动的 5 秒窗口内,系统计算汇总统计(如平均打字速度、暂停频率、导航熵),捕捉开发者当前的“流状态”。
- 模型训练: 使用历史日志(下游 LLM 建议被接受或被忽略),作者训练了一个二分类器(梯度提升树)来预测接受概率。
- 运行时决策: 在每次可能的 LLM 调用前,过滤器评估当前遥测窗口。如果预测的接受概率低于可配置阈值,则跳过 LLM 请求;否则正常进行。
- A/B 现场实验: 两组用户(基线 vs. 过滤)并行运行四个月。记录并统计比较建议接受率、延迟和云计算使用等指标。
结果与发现
| 指标 | 基线(无过滤) | 使用预过滤器 |
|---|---|---|
| 建议接受率 | 18.4 % | 34.2 % |
| 每用户每小时 LLM 调用次数 | 12.8 | 8.3 (‑35 %) |
| 平均建议延迟 | 420 ms | 310 ms (‑26 %) |
| 每千用户云计算成本 | $1,200 | $780 |
- 更高的接受率 来源于仅在开发者表现出接受意愿时(如打字稳定、导航波动低)展示建议。
- 延迟降低 是因往返 LLM 服务的次数减少的直接副作用。
- 成本节约 与 API 调用下降成正比,为大规模 IDE 供应商提供了明确的商业案例。
实际意义
- IDE 供应商 可嵌入类似的基于遥测的门控器,使 AI 助手不再显得侵扰,同时降低运营费用。
- 开发者 将收到更少打断注意力的“弹窗”,从而获得更流畅的编码体验和更快的反馈循环。
- 团队负责人 & DevOps 可通过展示不必要 API 使用的可衡量下降,合理化 LLM 服务的云支出。
- 开源插件作者 现在拥有一个即用型模式,可在不进行代码分析或收集用户提示的前提下实现隐私保护的自适应。
- 未来的 AI 辅助工具(如测试生成、文档机器人)也可以采用相同的预过滤概念,以提升时机和相关性,贯穿软件开发全生命周期。
局限性与未来工作
- 遥测范围: 模型仅看到短期交互信号;更长期的上下文(项目历史、开发者经验)可能进一步提升预测准确度。
- 通用性: 本研究聚焦于 VS Code 与特定 LLM 后端;在其他编辑器或模型族上结果可能不同。
- 阈值调优: 选择接受概率阈值会在召回率与精确率之间权衡;未探索针对每位用户的自适应阈值。
- 用户同意与透明度: 虽然保护隐私,但仍需明确的选择加入机制和 UI 提示,以避免“黑箱”行为。
未来的研究方向包括多模态信号(如眼动追踪、语音指令)、跨编辑器联邦学习以在不共享原始遥测的前提下实现个性化过滤,以及将预过滤扩展到其他 AI 驱动的开发者辅助功能,如 bug 修复建议或重构机器人。
作者
- Mohammad Nour Al Awad
- Sergey Ivanov
- Olga Tikhonova
论文信息
- arXiv ID: 2511.18849v1
- 分类: cs.SE, cs.AI, cs.HC
- 发布日期: 2025 年 11 月 24 日
- PDF: Download PDF