NES 模型训练的探索

1. NES 模型训练的探索逐云

2. 目录 01 我们做了什么 02 数据工作 03 模型训练 04 模型评测 05 未来展望 06

3.

4. 01 我们的工作 NES场景的探索

5. 我们做了什么 Aone 大图

6. 我们做了什么应用入口产品能力基础能力底层依赖

7. 常规补全和NES 对比常规补全 NES

8. 补全的问题 •无法修改既有代码：补全范围被严格限制在光标位置，对于修改、重构前文代码的需求束手无策。 •触发方式单一死板：仅在用户输入字符或回车后触发。当用户希望在代码的任意位置（尤其是存在语法错误处）获得智能提示时，往往需要额外输入或删除字符来“唤醒”Copilot。 •难以应对连续性任务：当一项修改涉及多处代码时（例如，为方法增加一个参数，并更新所有调用点），传统补全需要用户手动跳转、多次触发，过程繁琐且效率低下。

9. 数据格式探索格式需要满足以下功能 •修改范围：由指定位点->全文可控 •能力范围：续写->增、删、改待解决问题 • 有效信息片段选择 • 格式设计选择 • 输出样式满足修改范围和能力要求输入格式： ### User Import Files 代码片段 ### Similar snaps: 代码片段输出格式： ### User Edits: User edited "file_path_1": Edit diff_1 <| editable region start |> ### Lint Error: Error信息 <|editable region end|> ### User Excerpt: ```file path ---origin code <| editable region start |> --编辑区域代码 -- cursor位置<cursor is here> --编辑区域代码 <| editable region end |> ----原始代码 ``` ### Response: Rewrite code snippet

10. 数据格式探索- 输出格式输出格式1：输出格式2： <| editable region start |> Code diff: -start line num -end line num -code Rewrite code snippet <|editable region end|> 主要问题： • 是否支持多处修改操作 • 模型推理要求 • 模型对数字敏感程度低输出格式3： Rewrite code file

11. 数据格式探索- 输出格式串联组合模型方案： • 模型由location model + rewrite model 单行模型 NES模型并联模型组合方案方式 FIM（fill in the middle） Rewrite • 模型由常规补全模型+NES模型能力续写增、删、改输出token avg 20token avg 500token 单模型方案 • 单一rewrite模型实现NES功能，同时具备单行补全和多行改写的能力。单行模型功能是NES功能的子集，续写是改写的特殊情况，其次效果上看，当前模型同时具备查找代码错误并修改代码错误的能力，且rewrite可避免行号偏移问题。

12. 推理方式 speculative decoding（投机采样） • 推理速度1000token/s • 基于字符串/token匹配的投机采样模型

13. 方案确定 1. 有效信息 2. 推理速度 3. 迭代方案

14. 02 数据构建 NES场景的探索

15. 数据构建 NES（next edit suggestion）：根据用户输入的内容，预测代码文件中需要修改的内容，预测的动作是用户时间序列操作队列的延续，同时也是对用户编写代码中引入问题的修正，是一个功能更全面的代码辅助工作模型。关键要素： • 用户编辑历史（时间序列） • 完整的代码独立单元（代码操作实现一个功能点） • Repo级别代码（跨文件修改代码）

16. 数据构建- 单行补全扩充方案 1.用户pair数据：有用户拒绝数据和用户拒绝之后修改的数据，可以作为多行编辑的修改内容，用户从错误的数据修改为正确数据 2.用户采纳数据： 1. 以行为单位，如果采纳数据是原本数据扩写，我们可以认为是增删改中改场景。 2. 以行为单位，如果采纳数据是完整行生成，可以认为是NES中增场景 3.用户拒绝数据：可以作为删除场景的数据。

17. 数据构建- AST 构建方案 AST：抽象语法树（Abstract Syntax Tree，AST），或简称语法树（Syntax tree），是源代码语法结构的一种抽象表示。它以树状的形式表现语言的语法结构，树上的每个节点都表示源代码中的一种结构。场景分类： 1. 变量名修改 2. 增加函数体 3. 函数入参变更优点：快速、规则化缺点：场景泛化能力不够，同意代码表现不佳

18. 数据构建- PR 构建方案 PR数据：使用高质量pull request数据，每条数据满足单一功能开发需求。问题： • 如何构建用户编辑顺序 • 如何构建编码顺序优点：方案简单高效、数据源头广缺点：数据不真实、依赖模型能力和数据复杂度

19. 数据构建- 日志构建方案用户日志数据：数据包含用户编辑历史、代码lint error,可以获取repo级别用户日志数据。优点：数据真实缺点：依赖模型能力、工程链路复杂

20. 数据构建- 日志构建方案用户日志数据：插件端打点用户编辑历史，记录用户编辑历史事件序列，聚合最小操作单位，截取片段时间序列作为输入，后续代码片段作为目标。优点：数据真实缺点：聚合逻辑复杂，用户type时机和跳转逻辑不符合用户编辑历史产出结果。

21. 02 模型训练 NES场景的探索

22. 模型训练

23. 模型训练- sft 模型微调任务： 1. 输入信息是什么，模型要学习的知识是什么？信息和知识能否支撑起这个任务？ 2. 如何在尽可能少的变动（训练）下完成任务，除非存在大量(100k+)的数据，比如模型输入输出 format变化，对话格式变更等。 3. 模型训练中loss下降是必然的，算法收敛并不意味着现实中有效，反应业务实际能力的评测至关重要。 4. 数据顺序，数据质量 > 数据种类 > 数据数量，引入低质量数据杀伤力远大于高数据量，如果loss 一直剧烈波动，有理由怀疑数据质量较差，数据方差太大。

24. 模型训练- 数据质量数据质量： 1. LLM模型执行判别任务精度高于 rewrite任务。 2. 结果汇总阶段，可以通过调整权重策略，控制数据精度 3. 自训练判别模型7B够用，经多组 LLM判别之后数据的人工查验准确率高达90%，SFT之后的小模型准确率能到达92%

25. 模型训练- SFT Base model: Qwen coder 参数迭代方式：全量微调数据量：20W 目的：模型输出符合设计样式，模型最终满足三个要求 1. 模型按照指定区域输出rewrite代码片段 2. 输出pattern满足设计需求 3. 离线指标符合要求（EM和ES）

26. 模型训练- sft 1. Model size 不是越大越好。 2. 数据量少的时候，instruct模型效果要优于base，尤其是泛化能力会更强一些 3. 此场景epoch最优在5

27. 模型训练 Bad case修复: • 模型roll back问题（概率上符合模型当前推理内容，但是用户编辑历史中已经删除此处操作） • 模型修改用户确信操作 • 不符合用户习惯数据目的： • DPO使用pair对数据，修复bad case，实现bad case 解决率提升50%，且原模型性能下降可控，3%以内 • KTO使用用户采纳数据和拒绝数据，拟合用户采纳习惯，采纳率提升 10%

28. 模型训练- RL GRPO调整模型规则设计 • Format一致性：根据special token的位置和出现准确率设置打分。 • Reward model 判别：判别模型能做到90%的准确率，可以使用判别模型作为打分依据。 • 语法正确性:使用AST工具，判断产出代码是否存在语法异常问题。经验： 1. 冷启动SFT效果很重要，需要使模型具有格式和基本能力，保证sample多样性和输出稳定 2. Rollout采样数据尽量多一点。 3. 效率很重要，资源分配、异步等。

29. 02 模型评测 NES场景的探索

30. 模型评测离线评测 AB Test 线上评估

31. 模型评测- 离线评测评测手段评测方式优点缺点模型评测 LLM对产出结果打分评测快速高效评测结果依赖LLM能力和inference质量语法正确率抽取评测集后检查补全结果的语法正确率评测比较简单上限很低 Exact Match&Edit Similarity 抽取评测集并标注正确结果后，检查补全结果是否一致/编辑距离比较完善的评测补全效果，尤其是bad case 评测尚无法反映文本不同但语义相同的写法全链路复现根据用户操作历史，在插件端回放输入，完整端到端的评测，除了结果质量还考计算补全占比虑到延时的因素影响结果的参数较多，无法完美复现

32. 模型评测

33. 模型评测构建用户报表，持续跟踪模型能力，主要包含以下几点 • 采纳率：用户采纳请求数（去重）/展示请求数（去重） • 采纳行：用户实际采纳的代码行数（包括修改和新增的行数 • 推理耗时：推理耗时在650ms，最符合用户习惯 • 用户完全采纳率：用户采纳之后没有修改，完全保留模型推荐数据 • 采纳行为分析：包含代码语言、代码行数、用户行为分类（增删改）。

34. 02 未来展望 NES场景的机遇与挑战

35. SLLM VS LLM 业务满足： 1. LLM能力冗余，至少到60%以上能力 2. 业务有清晰规则可以验证结果准确性在内部多个场景中验证，在1B～14B的SLLM上相较于 LLM均有50%以上的效果提升，且推理成本远低于大模型

36. 业务模型 1. 连续过程行为数据：需要增加用户行为数据，训练中考虑用的采纳和拒绝等行为，增加模型的拒答能力，尤其是多次错误提示之后的拒答能力 2. 模型泛化能力提升，构建agentic RL环境。 3. 模型推理速度提升 a) 增加数据格式探索，比如行号信息，模型能清晰输出需要修改的行号信息，降低推理负担。 b) Diffusion模型推广：现阶段SP edit 的推理速度满足模型部署需求，但是会存在资源消耗量大等问题，需要在diffusion的基础上

37. 问题用户群体A：深度使用LLM产品，认为模型只能完成自己70%的工作，尤其是复杂项目，模型很难一次性做好工作，会出现多个bug间反复拉扯的情况，甚至出现设定好的test case多次不通过之后被模型强行修改test case的情况。用户群体B：现阶段已经很少用IDE写代码，使用Claude code、augment、Aone Agent等agent工具，能够做到vibe 编程，认为机写的代码比手写的代码好，且程序员的工作即将被LLM取代

38. 最佳实践 Agent + NES 组合编码方式 • 针对大项目使用remote agent，创建项目并完成需求 • 小需求使用ide agent去产出初版修改 • 用户自身根据自己理解使用 NES进一步迭代自己需求

39.

40. THANKS 大模型正在重新定义软件 Large Language Model Is Redefining The Software