A Survey on Large Language Models for Code Generation

重点关注

5.3 主流模型架构

Mixture-of-Experts (MoE)

一种通过多个专家模型（Experts）协作提升性能的架构，常用于大规模模型中。

Depth-Up-Scaling (DUS)

一种通过扩展模型深度提升性能的技术，旨在突破传统模型的深度限制。

Causal Language Modeling (CLM)

CLM 是自回归模型的一种特定形式，用于语言建模任务，其损失函数定义如下： 特点：仅依赖历史上下文预测下一个词，适用于生成文本和代码。

Denoising Autoencoding

通过随机掩码输入并重建原始数据来训练模型，此处略。

---

Emergent Abilities（涌现能力）

| 能力类型 | 定义 | 与Emergent Abilities关系 | | — | — | — | | Instruction Following | 能够理解和执行自然语言指令 | 需要足够大规模的LLM具备理解能力 | | In-Context Learning | 通过输入示例学习新任务，无需微调 | 仅在大模型中出现，表明LLM具备泛化能力 | | Step-by-Step Reasoning | 能够进行分步骤推理，提高复杂任务的正确率 | 依赖Chain-of-Thought技术，增强逻辑推理 |

关键点：这些能力不会在小模型中直接出现，但随着LLM规模增大，会自然涌现，反映规模化后的非线性能力增长。

---

5.5 RL+feedback（强化学习+反馈）

研究方法总结

| 研究方法 | 核心思想 | 关键技术 | 评估方式 | 主要贡献 | | — | — | — | — | — | | CodeRL [139] | 使用Actor-Critic框架进行代码生成 | - LLM作为Actor生成代码
- Token级奖励预测器作为Critic
- 单元测试反馈评估 | - 编译错误、运行时错误、单元测试结果 | 提出基于Actor-Critic的代码强化学习方法 | | DPO [216] | 提高训练稳定性，无需PPO | - 最大化条件概率对比损失
- 使用LLM生成的偏好/拒绝响应优化模型 | - 偏好学习（Preferred vs. Rejected） | 避免PPO的不稳定性，提升训练效率 | | RRHF [303] | 排名反馈优化代码生成 | - 通过响应排序生成奖励信号 | - LLM生成不同版本并排名 | 提供无需PPO的RL方法，减少超参数调整 | | sDPO [129] | 改进DPO的收敛稳定性 | - 改进DPO目标函数 | - 对比标准DPO实验 | 提升RL训练效率 | | PanGu-Coder 2 [234] | 结合测试和教师反馈优化生成 | - RRTF（测试与教师反馈结合）
- 排名奖励策略 | - HumanEval pass@1=62.20% | 显著提升代码生成质量 | | CompCoder [266] | 提高代码可编译性 | - 编译器反馈微调
- 可编译性强化学习 | - 编译器可编译性检查 | 生成符合语法的代码 | | PPOCoder [238] | 优化语法和语义一致性 | - 执行反馈评估
- AST/DFG结构匹配奖励 | - AST和DFG结构匹配 | 提升代码的语法和语义正确性 | | RLTF [163] | 基于编译器错误和测试的在线强化学习 | - 细粒度编译器错误反馈
- 自适应调整奖励 | - 编译器错误分析和测试通过率 | 提高代码的可调试性和正确性 |

---

5.6 Prompt enhancement

---

5.7 Repository-level code（仓库级代码生成）

挑战点

| 挑战点 | 描述 | | — | — | | 代码库的复杂依赖 | 模块化设计导致跨文件依赖（如共享工具、API调用）。 | | 代码库结构与风格多样性 | 每个仓库有独特的结构、命名约定和编码风格。 | | LLM上下文长度限制 | 仓库级上下文超出LLM的上下文窗口。 | | LLM训练数据不足 | 专有或未发布的项目数据缺失。 |

现有方案进展

| 方法 | 核心思想 | 关键技术 | 优势 | 潜在挑战 | | — | — | — | — | — | | RepoCoder [309] | 基于相似度的检索生成迭代框架 | - 相似度检索相关代码片段
- 迭代生成补全代码 | 提高补全的上下文关联性 | 可能引入无关上下文 | | CoCoMIC [69] | 跨文件上下文检索 | - CCFINDER模块查找相关代码 | 解决跨文件依赖问题 | 计算复杂度高 | | RepoHyper [209] | 语义图（RSG）驱动的检索 | - RSG编码全局结构
- Expand and Refine策略 | 结合语义信息 | 语义图构建成本高 | | RLPG [240] | 生成仓库级Prompt | - 结构化Prompt整合全局信息 | 补全质量更高 | Prompt可能超出上下文长度 | | Repoformer [282] | 选择性检索增强生成（Selective RAG） | - 自监督学习评估检索有效性 | 减少冗余检索 | LLM评估可能误判 | | RepoFusion [239] | 融合多源上下文 | - 多源上下文合并 | 提高全局一致性 | 处理冲突困难 | | CodePlan [22] | 规划全局任务 | - 多步编辑计划生成 | 适用于大型仓库修改 | 可能存在长程依赖问题 |

仓库级代码生成基准

• RepoEval [309]
• Stack-Repo [239]
• Repobench [167]
• EvoCodeBench [144]
• SWE-bench [123]
• CrossCodeEval [68]
• SketchEval [308]

---

5.10 Evaluate Metric（评估指标）

自动度量（Metrics）

| 类别 | 方法 | 核心思想 | 关键技术 | 优势 | 局限性 | | — | — | — | — | — | — | | 基于Token匹配 | Exact Match, BLEU, ROUGE, METEOR | 字符串匹配计算相似度 | 简单高效 | 计算成本低 | 无法捕捉语法/语义正确性 | | CodeBLEU [221] | 在BLEU基础上引入代码语义 | - AST匹配
- DFG匹配
- 执行精度 | 更好体现代码正确性 | 仍无法完全解决执行错误 | | 基于执行的度量 | pass@k, n@k | 运行代码测试功能正确性 | 直接评估功能正确性 | 更贴近实际需求 | 依赖测试用例质量 |

人工评估（Human Evaluation）

| 类别 | 方法 | 核心思想 | 关键技术 | 优势 | 局限性 | | — | — | — | — | — | — | | 主观质量评估 | 人工评分 | 评估可读性、风格一致性 | 适用于复杂任务 | 可靠性高 | 成本高、效率低 | | 人工验证自动度量 | 相关性分析 | 检验自动度量与人工评分的一致性 | 验证度量有效性 | 需人工参与 |

LLM-as-a-Judge（LLM评估）

| 类别 | 方法 | 核心思想 | 关键技术 | 优势 | 局限性 | | — | — | — | — | — | — | | LLM代理评估 | AlpacaEval, MT-bench [320] | 使用LLM替代人工评分 | Prompt指导GPT-4等评分 | 减少人工依赖 | 可靠性待验证 | | ICE-Score [332] | 无参考评分 | 直接评估代码质量 | 无参考评分 | 与功能正确性相关性高 | 处于早期阶段 |

RL反馈驱动评估

| 方法 | 核心思想 | 关键技术 | 优势 | 局限性 | | — | — | — | — | — | | CodeRL, PPOCoder等 | 强化学习优化生成 | 编译器/解释器反馈 | 自动优化生成 | 反馈来源有限（依赖编译器） |