📚 plmblog

Appearance

Code Survey

📅 发表于 2025/12/06
🔄 更新于 2025/12/06
👁️ -- 次访问
📝 0 字
⏳ 0 分钟
code
#survey

Survey 文章 ​

参考文章

背景 ​

发展历程 ​

背景

AI Coding 思想

  • 利用Github/StackOverflow/code网站资源，把多年编程经验提炼成指令跟随的工具。

相关工具

  • 【辅助插件】GitHub Copilot：VSCode 插件
  • 【IDE】Cursor：对话式编程
  • 【国产】CodeGeeX(智谱)：多语言代码
  • 【云服务】CodeWhisperer(亚马逊)：与AWS服务无缝集成，可调用Claude或Gemini。
  • 【命令行】Claude Code/Gemini CLI：命令行级别，agentic-coding-workflow。
    • AI 自助分析文件、运行命令、修正代码
Code LLM 两种分歧

两种分歧

  • 通用型LLM (广度)
    • 自然语言+编程数据 混合预训练，在上下文/意图/领域知识等理解细致。
    • 代表工作：GPT、Claude、LLaMA等。
  • 专用CodeLLM (深度)
    • 编程数据预训练+算法架构优化。
    • 代表工作：StarCoder, Code LLaMA, DeepSeek-Coder, CodeGemma, QwenCoder等。

尚未探索的领域 ​

目前尚缺乏探索的领域

1. 数据清洗策略

  • 如何平衡数据质量和数量？
    • 数据并非越多越好，顶级模型如何
  • 如何做指令跟随？
    • 让模型听懂人话。

2. 对齐技术

  • code需要能跑、符合人类习惯、是安全的，如何根据人类反馈来做对齐？

3. 高级提示范式

  • CoT、FewShot等。

4. 自主智能体

  • 自动拆解任务。

5. RAG

  • 模型会有幻觉、编写出不存在的函数。
  • 做RAG，让模型先看文档，再写代码，保证准确性。

6. 评估框架

  • 现在更多是2元的(仅看正确性)。
  • 但如何评估代码烂不烂、效率如何、可维护性如何？

通用LLM 发展和不足 ​

发展和涌现 ​

Rise of LLMs

Transformer 和 Scaling Law

  • Transformer 一统江湖
    • 通过预训练和知识迁移，把多种统一到一个支持多种任务和模态的可扩展框架。
    • NTP任务
  • Scaling Law 大力出奇迹
    • 参数、数据、计算越多，模型效果越好，可预测。
    • 出现一些涌现能力，涌现也可能是评估指标的问题。

LLM爆发出代码能力

  • OpenAI：Codex 能写代码 + HumanEval 测试集。
  • DeepMind：AlphaCode 能做竞技编程。
  • 代码结构 和人类自然语言在底层逻辑上是相通的。

LLM + 外部工具 变身 决策agent

  • 外部工具：计算器、搜索、代码解释器等等。
  • 思考行动观察Loop：思考 -> 行动 -> 观察 -> 思考 -> 行动 -> 观察 ....
  • 典型技术：ReAct，ToolFormer等。

突破、局限、CodeLLM动机

  • 突破：SWE-Agent：修bug、通过所有测试用例。需要规划+多文件操作能力。
  • 通用模型 在代码领域有局限性：
    • 准确性(复杂代码不会写)、安全性(有bug代码)、可靠性(系统级可靠性差)
  • 需要转专有的代码大模型

代码生成：HumanEval上的效果

修bug：SWE-Bench上的效果

模型架构&多模态 ​

Dense Model

1. Dense Model

2. MoE

3. Recurrent Models

4. Diffusion Models

5. Hybrid Architechures

多模态
  • 主要依赖视觉能力，需要查看图表、截图、UI元素等内容。

不足 ​

通用大模型的不足

核心缺点

  • 有广度、无深度
  • 什么都会一点，能写简单代码、能看图等。

具体表现

  • 专业和准确性不足
    • 生成表面看起来没问题的代码，但实际不能满足一些领域约束。
      • 看起来对的代码，实际可能一跑就崩
  • 安全和可靠性不足
    • 尽管功能正确能运行，但仍然不够安全、有bug
  • 仓库级理解不足
    • 模型可读长上下文，但经常lost-in-middle。
      • 关键信息藏在几万行代码中间，模型往往会忽略。
      • 跨文件的变量引用、依赖关系，模型经常搞不清楚，导致无法理解整个项目。
  • 多模态障碍/看不懂界面细节
    • 能看懂是个网页，但无法看懂具体元素细节、按钮具体交互含义等
    • 导致 AI 无法像人类一样精准地操作 GUI 界面进行编程或测试。
  • 不会用工具(Agentic限制)
    • 通用模型容易出现工具幻觉：假装调用了工具，或者编造了工具的输出。
    • 任务步骤变多(长程推理)，模型很容易这就“晕”了，忘记之前的步骤或偏离目标。

用模型写代码不够，需要

  • 数据清洗：去掉不安全的代码。
  • 预训练/微调：让模型理解代码结构和跨文件依赖
  • 强化学习：教模型如何正确使用工具和进行长期规划

代码基础大模型(开源LLM) ​

开源和闭源LLM ​

开源CodeLLM

模型训练阶段(预训练+后训练) ​

预训练相关 ​

预训练任务+预训练数据

未来趋势 ​

趋势

从通才到专才

  • 现状：GPT5-Codex、CLaude-4代码变体，都说明了特定领域优化有效果。
  • 未来：通用AI和编程助手继续分化
    • 在repo-level 任务、复杂调试、多步软件工程等场景取得突破

Agentic训练&复杂场景攻克

  • 从被动代码生成向主动软件工程转变，在复杂、多步编程场景自主操作。
  • 需要RL从执行反馈中学习，渐进式课程学习处理仓库级任务，集成外部工具和环境。
  • 需要理解整个项目、浏览代码库、执行迭代调试，和人类协作。

Scaling Law

  • 科学Scaling策略：是把钱花在模型参数、还是清洗更高质量数据。
  • MoE架构优化：保持计算效率、实现更优性能。MoE大势所趋。

评估和任务分类 ​

见笔记Code任务Bench相关 笔记

对齐 ​

对齐

  • 目的：使预训练模型能遵循指令有效完成code任务，通用llm -> codellm。

  • SFT：覆盖代码生成、修复、翻译等。

  • RL：通过奖励信号来修正模型。

SFT ​

SFT
  • 早期代码指令数据：Natrual-Instruct
    • 来源：code-comment：Github数据；question-answer：StackExchange等。
    • 缺陷：
      • 真实代码质量不一、难以过滤
      • 原始并非SFT构建，导致部分可能不满足指令要求。
        • 可能没有注释、或逻辑不一致等。
  • Self-instruct 数据方法
    • 给种子，找强力模型，生成许多示例，用示例去训小魔仙。
    • Alpaca、(2023) CodeAlpaca

单轮SFT ​

如何构造出比CodeAlpaca更好的训练数据？

单轮SFT数据构造

由浅入深：复杂性，解决太简单的问题

  • 背景：CodeAlpaca 问题太简单
  • Evol-Instruct方法 (WizardCoder 技术)
    • 通过启发式规则，让GPT4把问题变难，提升问题复杂性。
      • 增加约束条件、增加时间复杂度要求、把这个问题变成错题等。

由窄变宽：多样性，解决太重复的问题

  • 问题：Self-Instruct会生成太多重复数据。
  • 引入人类编写的数据(Natrual-Instruct)，来丰富多样性
    • Semi-Instruct：使用完整代码。
    • OSS-instruct：使用代码片段，而非完整代码，素材更碎片，发挥空间更大。
  • CodeOcean数据 严选+验真
    • 通过启发式规则和语义相似度，筛选出多样化的数据。
    • 利用CoT-like验证数据的正确性。
  • Self-Correction 逆向生成
    • 先从Evol-Instruct中清洗出output，再有个模型生成多个instruction
    • 再用模型去判断哪个指令是对的

由粗到细：精细度，解决不听话的问题

  • 问题：写代码敏感性低，如不要用什么库，但容易忽略这个要求。
  • 反事实指令(CounterFactual-Instruct)/控制变量法
    • 给模型看一对孪生指令A和B，大都相同，只有小部分不同(如输出格式)。
    • 训练：如果A和B输出相同，loss会高；如果不同，loss会低。

多轮SFT ​

多轮SFT

执行反馈

  • 实际执行，告知对错、成本效率，可以构建自我修正数据流，无需人类介入。

Multi-Agent

  • AIEV-Instruct：左右互搏，产生多轮对话数据
    • 程序员Agent：写代码；
    • 环境：执行代码，代码报错
    • 提问者Agent：看报错信息，进行提问，返回给程序员Agent，进行一轮
  • Self-Distillation：解决训练多轮 预测单轮的问题
    • 问题：训练时多轮；测试时：用户可能就一轮。
    • 数据改造：在多轮对话最后，增加总结轮。
    • 训练策略
      • 初期，模型全看，学习中间修改过程；后期：逐渐屏蔽中间过程。
      • 逼迫模型输出正确答案，从多轮向单轮的能力迁移。

仓库级SFT ​

仓库级SFT

背景

  • 仓库级SFT数据：有助于训练 跨文件依赖、多文件编辑、长上下文推理等实际软件工程的场景。

SWE 数据集

  • SWE数据是训练自主编程agent的基石数据。SWE-任务 笔记
  • SWE-smith：一套可扩展流程，从Github仓库生成大量的任务实例，数据量比之前提高一个数量级。
  • SWE-synth：对上述做补充，合成可验证的bug修复数据。
    • 生成bug修复对、测试用例和结构化的修复轨迹。
  • SWE-Gym：提供可运行的环境和python任务示实例，RL可训练。
  • SWE-Dev：针对feature功能开发，1.4万训练数据，500评估数据
  • Skywork-SWE：数据scaling law，数千个实例、多个仓库。

代码补全和仓库导航

  • RepoBench：评估跨文件理解自动补全，10k Python和14k Java库。
  • CoEDPilot：增量式代码编辑，预测编辑位置，5种语言，471项目、180k的提交。
  • RepoSFT：引入沙盒测试，832仓库，7415个函数。
  • RTL-Repo：扩展至Verlog硬件描述语言，4k样本，上下文从2k到128k token。

挑战

  • 计算成本高：执行环境成本巨大
  • 指令和规模难平衡：
  • 复杂多样性：不同项目之间仓库结构、依赖管理、编码规范不同，训练复杂
AI黑客数据

AI黑客/进攻网络安全型 数据

  • CTF(Capture The Flag)：
    • 给选手，一个有漏洞的程序或服务器，让其找到漏洞，并拿到一个特定字符串。
    • 需要极强推理、工具使用能力。
  • CyberZero：无环境也能训练(脑补)
    • 搭建训练环境麻烦，占资源。Runtime-free方法，不去运行。
    • 从公开的CTF解题报告(Writeups)，合成高质量agent轨迹数据，反向推理环境行为。
      • 根据解题报告，让大模型扮演环境，脑补输入这个命令，输出可能的结果
  • CTF-Dojo：真枪实弹演练(实战流)
    • 把几百个CTF题目，封装进Docker容器，安全隔离。自动化构建CTF-FORGE：保证环境能跑通。

推理方法 ​

提示

推理范式

  • 转变
    • 传统指令微调模型：输入 —> 输出。能力来自模仿SFT
    • 推理模型：输入 -> 思考 -> 输出。效果好。能力来自RLHF。
  • 机制
    • 计算草稿纸，强迫把思考过程写出来，相当草稿纸。
    • 不用死记硬背中间变量，注意力可以回头看之前的步骤，可以专注下一步计算。
    • SFT教模型学习推理思维模板，尽管一堆逻辑混乱答案错误的推理过程，微调后，也能提升。

面向推理的SFT

  • 三个点
    • 数据质量 > 数量
    • 选择难题，特点：包含探索、回溯、自我验证等。
    • 要干练精简。避免CoT输出废话。训练数据剔除没用的废话。

拒绝采样FT和RL

  • RFT(Rejection Sampling Fine-tuning )
    • 生成多个response，通过验证器过滤，仅保留正确case，使用正确case做SFT。
  • RLVR：强化学习。

训练策略和挑战 ​

SFT 训练策略

数据质量筛选

  • 去重：聚类、相似度等方法。
  • 难度和正确性：选择最难、最正确的题。

多任务平衡

  • 分阶段训练：
  • 并行微调：多个loss，多任务并行微调框架

去噪策略

  • 抗噪训练：把部分输出token转换成随机噪声。
挑战

数据泄露

  • 微调数据包含测试集信息。

数据偏差

  • 任务复杂性偏差，过度集中于简单任务。

多语言不足、数据不平衡

  • 主要是python、java这些。

冷启动/数据蒸馏 ​

数据源/蒸馏 ​

数据源

少数高质量比数量更重要

  • OpenThouhts3：混合少量高质量多源数据效果好。StackExchange、CodeGolf、OpenCodeReasoning
  • LIMO/s1：mini集合
  • DeepMath-103k、OpenMathReasoning：从非结构化源变结构化
  • AceReason-Nemotron、Skywork-OR1：从数学(DeepScaler,NuminaMath)和竞赛编程数据中，收集了高质量可验证数据。RL有用。

发展方向

  • 高质量、大规模数据。
推理链生成

目的

  • 生成CoT、tool-integrated等推理轨迹，提供认知模板，指导模型学习。

方法：大模型蒸馏 + 格式处理

  • 找SOTA模型蒸馏，处理成RL/SFT需要的格式。

代表工作

  • OpenThoughts3、DeepMath-103k(生成3个不同答案)、OpenMathReasoning(复杂流程、工具使用数据)
  • AceReason-Nemotron、Skywork-OR1：格式化答案、用于RL验证

数据清洗/质量评估 ​

数据清洗

具体工作

  • 去除低质量、不完整、重复样本。
  • OpenMathReasoning/OpenThouths3：LLM/N-gram去重，防止污染。
  • Skywork-OR1/AceReason-Nemotron：过滤不适合规则验证的数据，比如证明题、多选题等、无测试用例的数据。
  • DeepMath-103k：LLM-Judge做去重，去掉不可验证、去掉多次回答不一致的数据。
  • S1：去掉太简单或太难的数据，标准：Qwen2.5-32B。

总结

  • LLM去重、去掉不可验证数据、去掉多次不一致数据、去掉太简单或太难数据。
Query过滤和质量评估
  • LIMO/s1：保留中档难度，过滤弱模型轻松通过的数据，仅保留强模型少数几次通过的数据。
  • 难度分级
    • DeepMath-103k：GPT4o做难度打分(1-10分)，仅保留5分以上数据。
    • AceReason-Nemotron：pass rate作为难度，DeepSeek-R1-671B多次rollout来计算，过滤为0的数据
  • 最大化样本效率，RL需要高难度可验证的数据集。
答案过滤和修正

背景

  • 确保蒸馏生成答案的质量高。

基于元推理的评分

  • LIMO，基于3大特征评分，筛选出800条数据
    • Elaborated Reasoning：有无详细展开？
    • Self-Verification：有无自我检查？
    • Exploratory：有无常识不同解法。

一致性验证

  • 做多次(3次)，结果一致，保留。若多次结果不同，则丢掉。

反直觉：不过滤也很好

  • OpenThoughts3：尝试很多清洗方法，发现结果差不多。不如一起给到模型。

最终数据集总结 ​

最终数据集
  • 小规模、高质量数据
    • LIMO-800和 S1-1k样本
    • 优点：精心筛选数据，数据效率高、计算成本低
  • 大规模数据
    • OpenThought3：120万样本；DeepMath-103k，
    • 优点：多样性好、高质量数据多，能达天花板性能
  • 多任务-大规模数据
    • OpenMathReasoning 10w-50w，包括CoT/TIR/Generation等，多种任务。

多语言 ​

多语言CodeLLM

发展

  • 早期(2020-2021)：JavaBert, C-Bert。参数小，数据小。
  • 中期(2022-2023)：Codex, AlphaCode，12B-41B，6-12种语言。
  • 近期(2024-2025)：DeepSeek-Coder-V2：236B，338语言；StartCoder2：600+语言，4TB训练数据。

数据

  • 从单Github数据 -> 大规模多源数据 (10TB+)
  • GitHub, StackOverflow, CodeSearchNet, TheStack系列, The Pile, 合成书籍数据,执行轨迹,翻译语料。

生态

  • 开源：StarCoder, DeepSeekCoder
  • 闭源：Codex, AlphaCode
  • 指令微调：WizadarCoder, Phind-CodeLLama
  • 领域模型：CodeFuse, CodeShell(有中文数据)
  • Benchmark：VerilogEval等

近期趋势

  • 更小的模型：phi系列-1.3B，YiCoder-1.5B
  • 跨语言翻译：Transcoder、CodeTransOcean、PolyglotCode
  • 多模态融合：
  • 特定低资源/领域优化：
多语言代码评估

早期：python为主

  • HumanEval、MBPP，DS-1000、APPS等

多语言爆发

  • MultiPL-E, HumanEval-X。

趋势：复杂真实

  • HumanEval-XL：23自然语言、12编程语言，22k数据。
  • SWE-bench-multilinugal(多语言，2025), Multi-SWE-bench(多语言、多模态)，FullStackBench,。

多模态 ​

整体benchmark

VLM for Code ​

VLM发展
  • 早期：对齐和桥接
    • 通过Connector链接VisionEncoder和LLM
    • CLIP, BLIP, BLIP2：轻量adpater有好效果，桥接不同模态
    • 交错图文训练带来few-shot泛化能力：Flamingo(长上下文)、LLaVA(指令对齐训练)
  • 开源系列：高分辨率挑战
    • QwenVL系列：带来grounding(操作UI)、OCR(看清截图)、动态分辨率能力。
    • InternVL系列：模型、数据、test-time(推理) 3个维度scaling。
    • DeepSeek-VL系列：MoE架构，针对真实世界截图、文档、图表等。
  • 基座：原生多模态能力
    • LLama-3.2-Vision：为LLaMA增加图像能力
    • Geemma3/Gemini，初始源自Gemini，后期Gemini增强长上下文多模态能力、agentic能力。
    • GPT-4v / GPT-4o / GPT5：图像理解，文本-视觉-语音，GPT5更先进。
多模态code挑战和分类

多模态Code

  • 输入不仅是文本，包括图像、草图和各种交互信号。
  • 需理解视觉设计的意图、生成可执行可渲染的高质量代码

挑战

  • 保真度：能还原视觉细节、结构层级、功能语义等。
  • 可执行：语法正确、渲染正确、功能完整。

分类

  • 前端界面生成：Design2Code，要求保真度。
  • Web具身智能：Web-agent，像人一样浏览网页，侧重可执行。
  • 软件工程生成：UML、流程图转代码，侧重结构逻辑。

前端界面生成 ​

发展

Image2Code(早期)

  • Pix2code (早期)：把GUI截图生成代码，

Design2Code (标准化，意图实现)

  • Design2Code：43k <网页截图, HTML>数据，系统评估9种MLLM能力
    • 评估指标：TreeBLUE、DOM-ED
  • Prototype2Code：使用Figma API 来构建9k <真实原型, ReAct代码> 数据

Sketch2Code (草图)

  • Sketch2Code：731个高质量手绘草图Bench，2种交互评估模式：被动接受和主动提问。
  • WireGen：利用llm把简单意图自动生成中等保真度的线框图wireframes
  • 以及进一步探索在IDE中集成VLM-Code助手的可能性。

Interaction2Code (动态)

  • Interaction2Code：动态，大Bench，127网页、374个交互、31种类型。
    • 主要4种场景MLLM效果不好：事件遗漏、逻辑错误、细节混淆、视觉细节丢失。
关键技术创新

技术1：分而治之。分层生成和布局建模：

  • 核心：先画骨架、再填细节。
  • UICopilot：把HTML生成拆分2阶段，先生成粗粒度层级、再生成细粒度标签和css，降低上下文长度需求。
  • LayoutCoder：引入关系图和布局树prompt
  • DesignCoder：提出UI Group Chain，自动把设计分组为嵌套的层级结构，分而治之。

技术2：看着改。自动反馈和自我修正Loop

  • 核心：Compile-Render-Clip流程
    • 先检查代码能不能运行，再浏览器运行截图，再使用CLIP对比相似度。
  • UICoder：
    • 编译-渲染-CLIP 3重自动反馈机制；自检模块利用浏览器截图+视觉编码器来修复样式和无效逻辑。
    • 过滤了300w合成数据做微调，7B-13B在Design2Code上提升12-18pt。
  • ChatIR：上述应用到图标生成中。通过初试生成和优化2阶段，提升代码质量。
  • ReLook：RL框架，生成-诊断-修复循环，利用MLLM做critic训练。

技术3：像产品经理一样去思考。Agentic 工作流

  • 核心：草图 -> PRD -> 代码
    • 先把草图变成PRD，再根据PRD写代码。
  • Fronted Diffusion
    • 引入外部工具，调用Pexels API 去搜索真的咖啡图，放进去。生成的页面是ready-to-use的。
    • 自我评估：代码 -> 渲染 -> 自我评估 -> 修改。
评估
  • BLEU：不太行，因为可能功能没变，但分数会下降。
  • TreeBLEU：把HTML解析成DOM数，比较两棵树的相似度。
  • DOM-Edit Distance：计算从生成树变成标准答案树，需要几步操作。
  • Snap2Code防作弊：使用未见网站来测试。
  • WebUIBench：一个综合基准和评估框架，包括元素分类、视觉定位、OCR、布局理解、代码生成等。

WebAgent ​

WebAgent

核心

  • 不仅是静态代码生成。而是在真实web里，完成复杂任务，observe-reason-act。
  • 需要推理、计划和环境交互等能力。
发展阶段1-3

阶段1：基础框架

  • ReAct、CoT。
  • ToolFormer 教Agent使用工具。

阶段2：特定任务

  • WebShop：简单购物场景，多模态、多步推理评估。
  • WebArena：更真实更复杂的场景，800个长规划任务。
  • 端到端多模态导航
    • WebGUM：使用Transformer(T4)+ViT，处理HTML和截图。
    • WebVoyager(里程碑)：通过截图，模拟人类操作网页。GPT-4v做评估。
    • WebLINX：支持多轮对话的大Bench，150+真实网站，10w专家演示。

阶段3：游戏环境

  • Minicraft (VideoPretraining)：
    • 视频预训练：从人类视频中学习如何行动，利用少量逆动力学标注数据。
    • 通过原生键盘和鼠标，实现long-horizon控制。
  • MineDojo：
    • 利用互联网攻略视频作为知识库，定义多个任务。
    • 用语言控制让agent听懂人话，知道自己做得对不对。Video-Language的Reward Shaping。
  • Voyager(里程碑)
    • 通过不断进化的可执行程序库，驱动开放探索和获得终身技能。
    • LLM增加感知和代码执行能力后，可在复杂环境获得可复用的能力。
  • V-GameGym：
    • 视觉游戏生成，2219 Pygame Benchmark。
    • 多模态评估：代码正确性、视觉质量、游戏动态方面。
发展阶段4-6

阶段4：架构升级

  • Agent-E：层次化架构
    • 复杂任务分解成 planner + browser navigator
  • WebDreamer：三思而后行
    • LLM作为世界模型，模拟思考动作结果，再做评估和选择最优路径。

阶段5：Multi-Agent：群体智能

  • AgentVerse：通用多智能体系统框架
  • Voyager：在《我的世界》实现开放、连续式学习。
  • Generative Agents：虚拟小镇，25个智能体，模拟人类行为。大规模社会行为模拟。

阶段6：工具增强的多模态推理

  • 使用专门的视觉模块，完成感知-动作任务。
  • Visual ChatGPT, MM-ReAct：LLM控制，调用视觉模型完成多步推理。
  • 代码驱动：ViperGPT：通过写python代码，来解决视觉问题。
  • 真实世界（手机&通用网页）
    • Mind2Web/AndroidWorld：网页指令跟随、安卓手机指令更随。
    • 在UI-Grounding和Long-horizon上，存在挑战。

软件工程制品生成 ​

除了代码以外，Artifacts在整个软件工程周期，都很重要

  • Artifacts：副产品，设计文档、测试用例、UML图、需求文档等。
子任务和进程

数据可视化: 最活跃领域

  • nvAgent(多Agent)：多agent、自然语言转可视化系统，四个角色。
    • insight miner、可视化推荐者、代码生成者、叙述生成者。
  • DeepVis(交互式思维了)：CoT推理的交互式视觉界面
  • Chart-to-Code：看图写代码，最前沿核心
    • Plot2Code：从科学图表 -> 代码，多模态大模型
    • VisCoder：微调，生成可视化代码
    • ChartCoder：指令微调，多模态大模型，图表->代码
    • ChartMimic：跨模态推理能力，
  • nvBench2.0：应对现实模糊指令的

软件图表和模型生成

  • DiagrammerGPT：plan+review，NL -> 开放域图表。
  • Draw-with-Thought,
  • Flow2code：流程图->代码，15种编程语言。
  • Code-Vision
  • Unified UML Generation：从UML图像生成代码。
  • MM-Coder：多语言多模态软件开发，能理解设计图和文本。

多模态软件工程任务

  • SWE-Bench-Multimodal：视觉bug修复，js开发，
  • CodeV：利用视觉数据来解决图表相关的问题
  • MMCode/HumanEval-V(Benchmark)：丰富视觉信息的编程问题
评估

问题

  • 传统pass@k，对于程序竞赛这些可以的。
  • 但不适用于网页、前端代码等。

ArtifactsBench：像用户一样评估

  • 多模态评估
    • 渲染：执行代码，浏览器渲染起来
    • 截图：捕捉动态行为、关键帧
    • 多模态评估：使用GPT-4v或Gemini多模态大模型做评估。
      • 代码正确性、视觉保真度(颜色、字体、布局)、交互完整性(选题、点击、拖拽)
  • 示例： “请看这个网页运行的截图和视频。任务要求是‘做一个点击会变色的红色按钮’。请根据 Checklist 评分：1. 按钮是红色的吗？ 2. 点击后变色了吗？ 3. 布局是否美观？”

趋势 ​

多模态趋势

广泛应用 Agentic Workflow

  • 计划 -> 执行 -> 观察 -> 反思
  • nvAgent -> Agent-E -> Frontend Diffusion 三阶段，多步骤、多模态融合。

自我修正&迭代优化

  • 自主检测和修正错误。
  • UICoder 编译-渲染-Clip 三重反馈，DesignCoder 浏览器截图自查
  • ChatIR 结构化指令，ReLook，生成-诊断-精炼。

Code-in-the-Loop 评估

  • UICoder, ArtifactsBench 多模态渲染评估。

分层生成

  • UICopilot 两阶段生成，DesignCoder分层感知生成，WebDreamer 先思考再选择最佳路径。

面向RL的任务 ​

SWE Agents ​

各生命周期 ​

需求分析 ​

需求分析

痛点：需求是模糊的

  • 最难的是搞清楚到底要写什么。人类客户说的话往往是模糊、矛盾、不完整的。

  • 传统做法： 靠产品经理（PM）和业务分析师（BA）去开会、吵架、画图、确认。

  • Agent 做法： 用 AI 扮演不同角色来模拟这个过程。

Agent 如何解决四个阶段的问题

  • 第一阶段：获取（怎么知道用户想要什么？）
    • 思路： 既然找不到那么多真实用户来访谈，那就造虚拟用户。
    • 黑科技 (Elicitron)： AI 扮演挑剔的用户，去试用产品原型，然后 AI 采访 AI，问它“你觉得哪里不爽？”。这样可以挖掘出人类可能没想到的隐性需求。
  • 第二阶段：审查（需求打架了怎么办？）
    • 思路： 既然人类团队通过开会吵架来达成一致，那就搞个虚拟团队来吵架。
    • 黑科技 (MAD - Multi-Agent Debate)： 一个 Agent 扮红脸（提需求），一个 Agent 扮白脸（挑刺），还有一个 Agent 当法官。通过“左右互搏”，把逻辑漏洞和不合理的需求在写代码之前就辩论清楚。
  • 第三阶段：形式化（怎么把话变成图？）
    • 思路： 程序员喜欢看图（UML、UI设计稿），不喜欢看长篇大论的文档。
    • 黑科技 (PrototypeFlow)： 给 AI 一段文字描述，它直接生成 UI 设计图，甚至生成代码结构。实现了从“自然语言”到“工程语言”的翻译。
  • 第四阶段：确认（做出来的东西对不对？）
    • 思路： 上线前需要大量测试，但请人测试很贵。
    • 黑科技 (UXAgent)： 这是一个“人海战术”。生成 1000 个性格、背景各异的 AI 虚拟用户，让它们去疯狂点击你的 App。它们不仅不会累，还能给出详细的“用户体验报告”。

总结：AI 在软件工程中的角色跃迁

  • 软件工程 Agent 正在向左移（Shift Left）。

    • 以前的 AI（如 Copilot）：帮你补全代码（开发阶段）。

    • 现在的 AI（如 SWE-Agent）：帮你修 Bug（测试/维护阶段）。

    • 未来的 AI（本节内容）： 帮你做产品设计、需求分析（需求阶段）。

这意味着 AI 开始具备了同理心（模拟用户）、批判性思维（多智能体辩论）和全局规划能力（端到端流程）。

软件开发-程序合成 ​

程序合成

程序合成 AI写的

程序合成 Agent 远不止是我们在 IDE 里见到的代码补全（如 Copilot）。它们通过引入多步推理、基于测试的验证和反馈驱动的优化循环，试图从零开始构建完整的程序，而且尽量不需要人插手。

1. 问题定义（图 28）：

  • 输入： 需求文档（自然语言描述、图表）+ 测试用例。
  • 输出： 一个能跑通所有测试的完整程序。
  • 要求： 自主完成，中间可能需要自己推理、自己改错。

2. 架构设计：一个好汉 vs 三个帮 目前的 Agent 架构主要分两派：

  • 单智能体迭代系统 (Single-Agent Iterative Systems)：
    • 原理： 一个 AI 分饰多角。自己想、自己写、自己测、自己改。
    • 代表作 (AlphaCodium)： 它不急着写代码，而是先用自然语言写个草稿，分析潜在坑点，然后再写代码。写完自己跑测试，报错了再自己改。
    • 优点： 简单，思维连贯（毕竟是同一个脑子在想）。
    • 缺点： 容易当局者迷，很难发现自己思维的盲区。
  • 多智能体流水线 (Multi-Agent Pipelines)：
    • 原理： 术业有专攻。
    • 代表作 (PyCapsule, MapCoder, ChatDev)：
      • 程序员 (Coder)： 只管写代码。
      • 测试员 (Executor/Tester)： 只管跑代码，报错了把错误信息甩给程序员。
      • 产品经理/规划师 (Planner)： 负责拆解任务。
    • 优点： 分工明确，测试员的反馈更加客观，能模拟真实团队协作。
    • 缺点： 沟通成本高（Token 消耗大），容易出现信息传递误差。

3. 核心引擎：反馈驱动的代码搜索 (Feedback as the Engine) Agent 成功的秘诀不在于一次写对，而在于怎么改对。反馈（Feedback）就是把“生成”变成“搜索”的关键。 文中提出了四种“改代码”的策略：

  • 策略 A：并行采样 (Parallel Sampling / Best-of-N)
    • 做法： 既然 AI 每次发挥不稳定，那就一次性生成 100 个不同的版本。
    • 筛选： 挑出那个能跑通最多测试用例的版本。
    • 代价： 费钱（算力消耗大）。
  • 策略 B：迭代优化 (Iterative Refinement)
    • 做法： 写完一版 -> 跑测试 -> 报错 -> 根据错误信息修改 -> 再跑测试。
    • 经验： 通常改 1-3 轮效果最好，改多了还没对，说明思路彻底错了，再改也是徒劳。
  • 策略 C：混合搜索 (Hybrid Search)
    • 做法： 结合 A 和 B。先生成几个版本，然后对每个版本进行几轮小修小补。最后搞个“比武招亲”，看谁最强。
    • 效果： 这种方法最强，能在 LiveCodeBench 这种高难度榜单上拿高分，甚至让小模型战胜大模型。
  • 策略 D：基于一致性的重排序 (Consistency-based Re-ranking)
    • 做法： 让模型用不同的方式思考同一个问题（比如先写文档再写代码，或者先写测试再写代码）。如果殊途同归，得出的结果一致，说明这个结果大概率是对的。

4. 进阶挑战：从函数到仓库 (Scaling to Repository-Level) 写一个函数容易，写一个完整的 GitHub 仓库（Repository）很难。

  • 难点： 依赖关系复杂（A文件调用B文件），上下文太长（塞不进 Prompt）。
  • 解决方案：
    • 依赖图 (Dependency Graph)： Agent 需要先画出代码的依赖关系图，按照拓扑顺序（先写底层的，再写上层的）来写代码。
    • 环境集成 (Tool-Integrated)： 必须把 Agent 扔进真实的 IDE 或沙箱环境里（如 OpenHands），让它能像人一样浏览文件、运行终端命令。

程序分析

软件开发-程序编辑 ​

分为补丁生成(Patch Generation)和问题解决(Issue Resolution)。

Patch Generation

任务定义

  • 给一个有bug的代码片段，自动生成一个修复补丁Patch。
  • 自动程序修复最核心步骤。

技术演进1：微调和Prompt工程

  • 核心：使用bug-patch数据做SFT提升能力，或使用CoT Prompt引导模型一步步推理Bug原因。
  • 相关工作：RepairLLaMA、AlphaRepair。

技术演进2：任务转化

  • 核心：把修Bug转为其他形式的问题。
    • 完形填空：Mask bug代码，让模型填空Infilling。
    • 机器翻译：把Bug代码翻译成正确代码。
  • 相关工作：Recoder、NSEdit。

技术演进3：静态分析和模板指导

  • 背景：LLM有时会乱改，破坏原有逻辑。
  • 核心方法：很多bug有固定模式，先让工具做匹配，再让LLM填空。

技术演进4：RAG增强

  • 背景：可能之前有人遇到过类似的bug
  • 核心：遇到bug时，先去代码库、StackOverFlow等地方，检索到类似方案，再作为Prompt给到LLM。
  • 相关工作：InferFix、RAP-Gen

技术演进5：多智能体和对话流

  • 核心：像人类一样修bug，一个交互的流程。最前沿方向。
  • 1：对话式修复
    • ChatRepair, Conversational APR
    • AI 写代码 -> 跑测试 -> 报错 -> AI 读报错信息 -> AI：“哦，我懂了，这里越界了” -> AI 再写代码。
    • 利用对话来维护上下文，报错信息变成线索
  • 2：闭环反馈
    • 整合bug定位、Patch生成、测试验证到一个循环，协调多个agent或工具去动态修复。
    • 该代码、找bug、跑测试，一个闭环。
    • 相关工作：RepairAgent、ITER
    • RepairAgent：把修bug编程一个Agent的自主任务，可以调用工具、定位错误、搜索方案。
  • 3：仓库级多Agent协作
    • 相关工作：AutoCoderRover、PathPilot、MarsCodeAgent。
    • 仓库级修复、多agent规划、全项目代码搜索、执行验证，模拟开发工作流。
  • 4：带记忆的持久学习
    • 结合记忆组件，之前的修复经验，进行修复。
    • 相关工作：ExpeRepair、SpecRover(规范判断)。
Issue Resolving 问题定义

问题定义

  • Patch 生成：给一段代码，修好它，局部的。
  • Issue 解决：给一个Github Issue，自己仓库里找代码、找定位、修复、测试、提交PR。全局的。
  • 核心流程：
    • Fault Localization：在几百个文件里，找到哪一行代码导致bug。最难。
    • Program Editing：修改代码，生成补丁。
    • Validation：跑测试用例，确保bug修好、且没有新bug。

技术演进

  • 基础：AI使用工具
  • 进阶：AI学会分工，多智能体架构
  • 高级：AI拥有记忆和反思能力。
Issue Resolving - Code Agent

基础接口层

  • SWE-Agent、OpenHands：LLM as agent 概念，把LLM作为新用户，设计了ACI接口。
  • Agent-Computer Interface
    • 简化命令：设计了一套LLM容易理解且不容易写错的特殊指令。
    • 环境反馈优化：筛选关键错误信息给到模型，并非给全部错误，解决上下文爆炸问题。
    • 保护机制：
      • 自动回滚：AI改坏代码导致环境崩溃，ACI能自动检测并恢复到上一个版本。
      • 动态历史折叠：历史记录会变长，ACI可以自动总结隐藏不必要历史操作，只保留关键记忆。

架构层

  • 单Agent难以管理多文件、依赖、复杂工作流，需要模块化协作架构。
  • 模块化：代码理解、依赖分析、故障定位、补丁生成、验证。
  • 多角色协作方法
    • (2403) Magis：经理、仓库管理员、开发、QA。
    • 优点：利用记忆和检索工具(BM25)，适合处理多文件复杂修改。
  • 设计Pipeline：简化和专业化
    • (2406) CodeR：使用预定义好的任务图来协调agent。
    • (2404) AutoCoderRover, (2409) MarseCode Agent：
      • 使用高级工具和复杂数据结构，辅助AI理解代码。代码知识图谱、LSP、AutoDiff等。
    • (2407) AgentLess：写死流程，三阶段：定位、修复和验证。
    • (2501) SWE-Fixer：侧重于检索策略，先粗找、再精细找。
    • (2505) Co-PatchR：小模型协作。

知识层

  • 背景：加深对代码语义和依赖关系的理解。因此结构化知识建模，特别是把代码库表示成图，有用。
  • 方法
    • (2408) CodexGraph：把代码存进图数据集，写sql去查询出相关代码。
    • (2503) KGCompass：图谱有代码和Issue，能通过图连接，找到相关代码节点。
    • (2505) CGM：Graph-RAG，修改注意力，关注看图谱部分。
    • (2406) LingmaAgent：MCTS搜索数。

语义层

  • 背景：传统代码生成只关注代码正确性，即没有编写错误。但没有考虑语义即逻辑错误。
  • 作用：通过语义层分析，理解根本愿意和意图，避免模型骗过测试用例来生成代码，而是真正修复bug。结果更鲁棒和泛化。
  • 工作
    • (2506) SemAgent：多维语义融合(问题+代码+执行结果)
    • (2408) SpecRover：分析现有测试用例程序结构，反向推断出代码规范，强调可解释性，告知为何补丁是对的。
    • (2504) Nemotron-CORREXA：通过AST+LSP等工具构建代码关系图谱。利用集成学习和多步推理。

智能层

  • 背景：基础修复解决后，希望系统持续学习和自我进化。
  • 工作
    • (2507) SWE-EXp：从成败经验中学习，构建多维经验库，使用MCTS推演可能性，做出最优决策。
    • (2507) SWE-Debate：多视角对抗，通过辩论排除错误路径，定位更精准。
    • (2508) SE-Agent：通过3步迭代，修改-重组-完善，不断打磨。

ACI 接口 示意图

Issue Resolving 典型workflow示例：

软件测试 ​

软件测试

背景

  • 验证成本低：LLM写测试代码，运行，即可返回对不对。
  • 反馈闭环明确：报错信息和覆盖率报告很清晰，LLM擅长阅读这些反馈并做自我修正。

核心技术

  • Level 1: 能写出来 (Capability)
    • 代表：直接把代码扔给 GPT-3，让它生成测试。
    • 问题：生成的测试可能跑不通，或者只是样子货（没有断言，Assert True）。
  • Level 2: 写得好 (Quality & Coverage)
    • 代表：CodaMosa。
    • 逻辑：传统 Fuzzing 工具（如 AFL）擅长生成随机数据，但不擅长通过复杂的 if (x == "magic_string") 检查。LLM 擅长理解代码逻辑。CodaMosa 结合两者，当传统工具卡住时，让 LLM 生成代码来突破覆盖率瓶颈。
  • Level 3: 自主修测试 (Iterative / Feedback-loop)
    • 代表：ChatUniTest, HITS。
    • 逻辑：人类写测试从来不是一次写对的。AI 也是。现在的 Agent 会先写一个版本，运行，发现报错 NameError，然后自己读取报错，修正代码，直到测试通过。这就是文中提到的从 One-shot 到 Multi-step 的转变。
  • Level 4: 安全与攻击 (Fuzzing)
    • 逻辑：不仅要测“功能对不对”，还要测“能不能被黑掉”。LLM 被用来生成更有针对性的攻击数据（恶意输入），比随机生成的乱码更有效。

软件维护 ​

软件维护 (AI写的)

A. 从“翻译”到“理解”：反编译与日志分析

  • 日志分析的进化：以前的日志分析是“关键词搜索”（出现 Error 就报警）。现在的 Agent 是**“运维侦探”**。它看到报错后，会自己去查知识库、去对比历史日志、去分析代码变更，然后告诉你：“这个错误是因为昨天张三提交的 DB 配置改动导致的。”
  • 反编译的进化：以前的反编译是“硬翻译”。现在的 LLM 是**“脑补大师”**。它看到 v1 = v2 + v3，结合上下文发现这是个银行转账逻辑，它会把代码重构成 balance = old_balance + deposit。这极大地降低了逆向工程的门槛。

B. 编译器优化：AI 的“炼丹炉”

编译器优化本质上是一个在一个巨大的搜索空间里找最优解的问题。

  • LLM 和 RL（强化学习）在这里表现出色，因为它们可以像下围棋一样，探索成千上万种编译器参数的组合，往往能发现人类专家都想不到的优化路径。这是 AI for Systems（AI 用于系统优化） 的经典案例。

C. DevOps：从脚本到“数字员工”

  • 在传统的 DevOps 中，如果构建失败了，流水线就停了，得等人来修。
  • 在 Agentic DevOps 中，AutoDev 这样的系统就像一个数字员工。构建失败了？它会自己看报错日志，如果是环境问题它就重启环境，如果是代码语法错误它甚至能尝试自动修复，然后再次提交构建。它变被动为主动。

端到端软件agent ​

特性瀑布流模式 (Waterfall)敏捷迭代模式 (Agile)
代表ChatDev, MetaGPTAgileCoder, LCG
工作方式线性流水线 (A -> B -> C -> D)循环迭代 (Plan -> Code -> Test -> Plan...)
优点结构清晰，SOP 标准化，适合明确的小任务灵活，容错率高，适合复杂、需求模糊的任务
缺点上游犯错，下游买单；缺乏灵活性流程复杂，Token 消耗大，管理难度高
人类隐喻传统外包工厂现代互联网创业团队

SWE中的通用Agent ​

希望构建一个Agent，能跨越整个软件开发周期，而不是只为一个任务做的agent。

SWE-通用Agent

核心能力

  • 多轮交互：和人类对话、确认需求、汇报进度。
  • 上下文跟踪：记住项目结构、修改记录、用户偏好配置等等。
  • 工具调用：需要操作终端、读写文件、运行git命令、调用编译器等。
SWE-通用Agent 主要工作
  • (2402) CodeAct：Code as Action，直接让模型写代码，再结合解释器去执行代码。
  • (2407) OpenHands：标准化的交互环境，Docker沙盒环境。可写代码、操作终端和浏览。
  • (24) OpenCode：SOP 多智能体，Plan+Build+General Agent，推理和行动解耦，提高稳定性。
  • (24) Aider：极致的工程化，构建代码地图解析文件依赖关系、提交代码前先运行和测试，自己修复，提高可用性。
  • (24) Augment：极致上下文引擎，实时的语义化的索引系统。个性化记忆+工业级速度准确性。
  • (2507) Trae Agent：Code Generation as Search，生成-剪枝-选择。同时生成多个方案，选择最合适的。
  • (25) Refact Agent：全生命周期和隐私安全。自托管和全流程集成。

训练SWE-Agent ​

SFT 微调 SWE-Agent ​

数据

整体思想

  • 不直接使用原数据，而是对数据做精炼合成。
    • 过滤噪声，通过执行来验证正确性，从0开始构建完整结构化实例。
    • 结构化实例：用户需求->需求拆解->代码实现->测试用例->修复bug。

数据过滤

  • 过滤：paper
    • 背景：PR中充满许多 “Thanks、Great Job”这种无效评论。
    • LLM作为分类器，去掉不可操作/无实质内容的，仅保留明确指出错误的comment。

数据合成

  • 从真实commit历史里，合成逼真的bug，故障定位-bug修复 ，来增强数据集。

  • 执行验证的数据增强

    • Rollout多个轨迹，通过执行反馈来筛选正确数据。
    • 相关工作：CodeS、SPICE、RewardRepair。

  • 端到端数据合成

    • (2503) OminiSQL：先造库、造答案，再造问题，再CoT思考解题思路，最后做过滤。
    • (2506) SWE-Flow：把大任务拆解成多个步骤。step2依赖step1，动态演进代码库。
    • (2305) DIDACT
训练目标

多任务和课程学习

  • Comment生成前，先混合训练：MLM、Diff Tag 预测、Code 去噪等任务。
  • Patch 生成：也会使用多任务学习

结构感知：分而治之

  • 比如SQL：先生成骨架，再填空。

专门的学习范式

  • 故障定位：用对比学习来区分bug相关和不相关的代码，拉进正样本距离，拉开负样本距离。
训练模式
  • LoRA
  • 多阶段训练、持续学习。
  • 直接微调/特定任务。依赖特定数据集。

RL 学习 SWE-Agent ​

RL 算法

策略梯度

  • ITER/RepairAgent：根据当前状态，来确定下一步动作。(retest、尝试不同patch、重新定位故障等)

Offline RL

  • 背景：在线可能太慢了，比如编译代码1分钟、跑Benchmark 10分钟。
  • 核心技术：
    • 世界模型：基于历史数据训练世界模型，从世界模型中学习，避免真实交互。CompilerDream。
    • 从历史数据中学习：把历史数据构建成一个大的数据集，从中学习。RewardReapair。
      • 包括bug报告、代码变更、测试结果等。

Value-based & 偏好学习

  • RLHF：训练一个奖励模型，偏好/主观打分。如CodeMentor。
  • Multi-agent 辩论：使用裁判模型，来判断谁的论据更扎实。
奖励设计

自动程序修复 Auto Program Repair

  • RewardRepair, Relfxion, ITER：连续生成和验证的循环

编译器优化

  • 不同排序优化对代码编译速度有影响。
  • 奖励：代码编译速度提升。

安全和漏洞管理

  • 基于模糊测试的循环，Fuzzing
  • 多智能体辩论，Audit-LLM
SFT & RL

SFT 是RL的地基/冷启动

  • 通过高质量标注数据，初始化策略，缩小搜索空间。但是会导致探索不足吗？
  • SFT引导，教会模型目标任务的基本语法语义等内容，缩小RL空间。AlphaRepair、RewardRepair。

SFT 和 RL的战略平衡

  • SFT训太久，就会死记硬背，不探索，导致RL无效。

循环式改进数据驱动

  • SFT -> RL -> 高质量探索样本 -> SFT -> RL

未来趋势 ​

全能+记忆好+会成长+听话+安全

专用agent到全周期的通用Agent

  • ChatDev, MetaGPT, AgileCoder

实现深度上下文和长期记忆

多智能体、自我进化

人机协作

信任、安全、可验证

Code 通用助手 ​

Code作为交互协议 ​

Tool Use ​

MCP 协议 ​

Multi-Agent协议 ​

Code 作为 Agentic 能力 ​

Thinking in Code ​

Acting in Code ​

Memory with Code ​

Code作为环境接口 ​

模拟Gym环境 ​

Computer-Use Agent ​

代码安全 ​

训练技巧 ​

Code LLM 训练

代码模型的挑战

  • 严格语法限制。
  • 长距离依赖：代码一个变量，可能几百行以后才被调用。模型需要记住这种逻辑关系。
  • 可验证性：需要能跑通，也是一个特点。

训练流程

  • 预训练：打基础
  • SFT：学指令
  • RL：提质量

训练框架 ​

训练框架

Megatron-LM

  • 核心：TP + SP，支持超长上下文。PP 1F1B策略，降低气泡。
  • 场景：超大规模、极致性能

DeepSpeed

  • 核心：ZeRo1-3 + Offload
  • 场景：显存有限

Pytorch-FSDP

  • 原生支持，兼容性好

TorchTitan

  • 核心：4D并行，Megatron 也有。
  • 场景：超大模型。

Colossal-AI

预训练 技巧 ​

Scaling Law

Scaling Law

  • 代码比通用模型需要更高的数据参数比，参数敏感。

  • N：模型参数；D：训练tokens；

  • L∞：不可约减loss；

  • αN,αD： 模型敏感度、数据敏感度，决定loss随N/D增加而下降的速度。

  • 每种语言的Scaling Law

    L(N,D)=(NcN)αN+(DcD)αD+L∞

  • python最难学，比其他语言更吃算力，形式灵活。

多语言混合和预训练策略

多语言混合

  • 混合语言会让单语言提升，整体利大于弊，但非对称：
    • python作为辅助语言能帮助其他语言。
    • 混合其他语言，会对python有微小的负面影响。

预训练策略

  • 不同语言有不同的tken预算。
    • Python/TS等不规范语言： 数据要多一些。
    • Java/GO/C+规范语言：数据少一些。
    • 实操：总100B，Python 40B, TypeScript 20B, Java 15B, Go 10B, C+ 15B
  • 相似语言语料库构建
    • Java+C+, JavaScript+TypeScript, Rust+Go，相似正向，可以混在一起。
    • Python：非对称，要加多。
  • 基于复杂度做算力分配
    • L∞低，总算力需求小；L∞高，总算力需求高。
  • 默认采用多语言预训练。
    • 涌现能力。
    • 资源有限：Python-Java-C#，或 JavaScript-TypeScript。

SFT 技巧 ​

SFT 实验

基础配置

  • 模型：Qwen2.5-Coder-14B
  • 数据集：Magicoder_OSS_Instruct_75k
  • 超参：
    • 3epoch, global bs=256, max_len=8k, lr=1e6, warm_up=0.03，64GPU
    • 设备批大小=2，梯度累积=2
    • Global-BS = N_GPU * 2 * 2。即64*4=256
  • 框架：QwenCoder-SFT, LLaMA-Factory, MS-Swift, VERL

框架说明

  • QwenCoder-SFT (HF Trainer)：Pytorch DDP，吃显存。
  • LLaMA-Factory (DeepSpeed ZeRO-3)
    • 全精度，好用。50分钟训完。
  • MS-Swift (Megatron)：
    • TP+PP。20分钟。
  • VERL (FSDP v2)
    • 2小时。重复的All-Gather 通信开销。
超参经验
  • Global BS 在SFT里和敏感，超过256会下降，不能太大。
  • 学习率和模型相关。
    • 14B：2e-6 - 5e-6
    • 30B：1e-6欠拟合，2e-6平衡，峰值5e-6
  • 训练时长
    • 14B：3-5个epoch
    • 30B：需更多epoch才能稳定
  • warmup
    • 14B：还好
    • 30B：需要预测，0.03-0.1
模型架构经验

Dense：更稳健

  • Epoch：1-5逐渐提升，随后饱和
  • Batch size：64-256都可，>1024下降也较少。
  • 学习率：平滑，2e-6～5e-6之间

MoE：超参敏感

  • 潜力高：特定条件下才能达最优分数
    • 10 epoch HumanEVal=0.836，Batch size=64时，MBPP=0.86
  • 不稳定：
    • bs>512 或者 学习率低于1e-6时，性能急剧下降。
  • 训练时间：更长。
数据集影响
  • 可执行、函数级的数据，对MBPP有效果。比如KodCode系列。
  • 竞赛风格的题对HumanEval有效，但对MBPP无效。
    • 如code_contests 更利于提升算法推理能力，而非入门函数生成能力。
  • 缺乏执行反馈、纯聊天数据效果不行。
  • 50k数据配比：主力 可执行数据 + 辅助算法竞赛题 + 丢弃纯文本垃圾数据。
  • 质量 > 数量。

RL 技巧 ​

RL 实验

基础配置

  • 模型：Qwen2.5-Coder-14B
  • 数据集：codecontest_plus
  • Reward信号：sandboxfusion
  • 超参：bs=64, max_len=4k, lr=1e6, 64GPU
  • 框架：VERL
优势估计 验证
  • RLOO
    • 分数最高。
  • Reinforce++
    • 训练快，比RLOO低一点点。
  • GRPO
    • 表现平平，收敛慢
  • GRPO_PASSk：效果差
Response长度 验证
  • 16k：pass@1最高
  • 2k：pass@5最好，较短上下文、在训练期间探索更多样。
rollout.n 验证
  • rollout.n 太大也会崩溃。比如128,256,512
    • 可能是太多低质量样本，导致方差过大。？
  • pass@1 对N=4和N=64没区别。
  • 考虑各方面平衡，16比较均衡。

Code 应用 ​

IDE集成 ​

云原生代码平台 ​

Terminal-based ​

代码修复和程序验证 ​

PR Revoew和质量检验 ​

总访客数：   ·   总访问量：
PLM's Blog @ 2016 - 2026