Workflow
代码智能
icon
搜索文档
北航领衔发布300页代码智能综述:从基础模型到智能体,一次读懂Code LLM全景图
量子位· 2025-12-05 13:33
编程范式演进 - 编程范式正从手动编码、IDE辅助、框架驱动,向AI辅助的协作式开发演进,开发者更习惯于用自然语言表达意图,由模型完成更大比例的实现[4] - 随着模型上下文窗口增大和工具调用能力增强,开发的起点转变为组织需求与意图,这种范式变化比以往任何工具升级都更深刻[5][6][7] - 行业正处在编程方式发生跃迁的关键节点上[8] 代码基础模型技术底座 - 代码基础模型的训练依赖于GitHub代码、Issue讨论、StackOverflow、API文档等语料,共同构成模型的工程世界知识[10] - 预训练中大量使用填充中间内容与多Token预测等任务,使模型能处理跨行、跨段落的复杂代码结构[10] - 模型架构从CodeBERT、CodeT5演进到当前主流的仅解码器与混合专家架构,体现了对代码任务需求的不断适配,整个训练体系在长期协同演进[11][12] 代码任务与评估体系 - 代码模型的评测体系按任务粒度系统整理,从函数级、跨文件到工程级和智能体级,每一层都有对应的基准[14] - HumanEval、MBPP等是基础指标,但只反映模型的底层能力,更真实的工程语境需要仓库级长上下文任务、SWE-Bench、跨文件补全等基准来评估模型对软件结构的理解[15][16] - 评估方法包括大语言模型即评委、多智能体评测、执行级校验等,使评估更接近实际开发场景,模型能否写好代码取决于其处理真实项目复杂依赖的能力[17][18] 模型对齐与能力增强 - 模型对齐与增强通过监督微调、推理数据蒸馏、多语言与多模态扩展等方法,目标是让模型更理解工程,而非仅生成看似代码的文本[19][20] - 仓库级训练是关键,模型必须理解模块间依赖、目录结构和项目组织方式,才能在真实场景中表现稳定,单个函数的数据远远不够[22] - 增强推理能力方面,多轮提示、链式思考数据、自动生成高难度样本成为新趋势,强化学习中的基于可验证奖励的强化学习通过单元测试作为奖励信号,是近两年性能提升最显著的方向之一[23][25][26] 软件工程智能体 - 当模型以智能体身份参与软件工程流程时,其潜力被放大,涉及需求理解、代码定位、跨文件生成、自动测试、自动程序修复、日志分析等任务,并为每一步构建了对应的智能体框架和案例[27][28] - 智能体不再是单纯的代码生成器,而是需要连续决策、实时利用环境反馈的工程参与者,当前最大瓶颈是如何有效利用测试结果、工具调用反馈、IDE状态等环境信号[28] - 在更通用的智能体生态中,代码不仅是输出物,更是一种用于表达工具调用、逻辑执行和状态管理的通用语言,这意味着未来的智能体体系可能会越来越依赖以代码为核心能力的模型[30][31][32] 安全与治理 - 代码模型的安全问题比自然语言模型更复杂,风险涵盖数据安全、模型安全和执行安全三个层面,包括训练数据许可证风险、模型生成潜在漏洞、提示攻击、环境操控及代码执行带来的系统级风险[34][35] - 对应的治理手段包括数据审计、安全微调、偏好对齐、红队测试、静态与动态检测、安全沙箱等机制,随着模型集成进工程环境,这些安全能力正成为基础设施的一部分[35] 训练方法论 - 论文总结了高价值的训练经验,包括预训练的数据设计、监督微调的关键超参数、混合专家模型的稳定性策略、强化学习的展开与奖励设计等,结合扩展定律和敏感性实验,将分散的经验凝结成一套可系统复用的方法论[36][40] - 这些方法论揭示了数据投入最划算的阶段、可能出现收益下降的阶段、对性能影响巨大的超参数、可灵活调整的超参数,以及不同规模和架构模型在训练中的性能拐点[45] 应用落地与未来方向 - 代码大模型应用正在加速落地,已进入集成开发环境插件、协作编码、自动测试、自动修复、形式化验证等软件工程多个关键环节[41] - 随着智能体框架与工具链不断成熟,代码智能正从辅助工具逐渐成为开发流程的一部分,未来的软件工程可能会继续朝意图驱动、协作式编码的方向演化,模型的角色将越来越重要[42][43] - 这篇超过300页的论文将代码智能的关键模块串联,勾勒出一张完整、系统、可实践的技术地图,对关注模型训练、工具开发或未来软件工程演化方向的从业者具有重要参考价值[43][44]
Agentic Coding表现创新高,全新KAT系列模型上榜SWE-Bench
机器之心· 2025-09-26 18:35
模型发布与性能表现 - 快手Kwaipilot团队推出KAT系列两款Agentic Coding大模型:开源32B参数模型KAT-Dev-32B与闭源旗舰模型KAT-Coder [2] - KAT-Dev-32B在SWE-Bench Verified上取得62.4%的解决率,在所有不同规模的开源模型中排名第5 [2] - KAT-Coder在SWE-Bench Verified上以73.4%的解决率取得极佳的单模型表现,比肩全球顶尖闭源模型 [2] - KAT-Dev-32B已在Hugging Face上线,KAT-Coder的API密钥在“快手万擎”企业级大模型服务与开发平台上开放申请 [7] 核心技术路线与创新 - 模型训练分为四个关键阶段:Mid-Training阶段、监督微调(SFT)阶段、强化微调(RFT)阶段以及大规模智能体强化学习(RL)阶段 [9] - Mid-Training阶段增强了模型与“LLM-as-Agent”相关的全方位能力,包括工具使用能力、多轮交互和指令遵循 [10] - SFT阶段精心策划了八种任务类型和八种编程场景,以确保模型的泛化能力和综合能力 [12] - RFT阶段创新性地引入人类工程师标注的“教师轨迹”作为训练指导,提升了强化学习阶段的效率和稳定性 [12] - 大规模Agentic RL阶段通过自研的工业级规模强化学习训练框架SeamlessFlow解决了非线性轨迹历史高效学习等挑战 [12] 训练数据与能力构建 - 构建了在沙盒环境真实执行工具的调用方法及执行结果交互数据,用于提升模型工具调用能力 [12] - 构建了最长数百轮的人类、模型、工具交互数据,用于提升长文本情况下模型的多轮交互能力 [12] - 加入了高质量的编码相关领域知识数据,用于进一步增强模型在编码场景下的性能 [12] - 加入了大量来自真实Git仓库的PR数据,用于提升模型在真实编程任务下的表现 [12] - 除了开源数据,还收集并利用了来自真实世界工业系统的匿名企业级代码库进行RL训练 [23] 模型效果与涌现能力 - KAT-Coder模型具备强大的代码生成能力,可独立完成完整的项目开发,用户仅需描述需求,模型即可交付完整的代码解决方案 [26] - 经过大规模Agentic RL训练后,模型平均对话轮次下降了32%,展现出效率偏好的形成 [35] - 模型展现出同时调用多个工具的能力,而非传统的串行调用,体现了并行化的自然选择 [35] 未来发展方向 - 计划增强工具集成,与流行的IDE、版本控制系统和开发工作流深度集成,创建无缝的编码体验 [35] - 将扩展KAT模型能力以覆盖新兴的编程语言和框架,确保全面的语言支持 [35] - 探索多智能体系统,让KAT模型能够在复杂的软件项目上协同工作,实现协作编码 [35] - 计划集成视觉理解能力,处理架构图、UI设计、调试截图和文档图像以及代码,实现多模态代码智能 [35]
从Debugger到Developer : 低代码时代新基准NoCode-bench,SWE-Bench作者力荐
机器之心· 2025-08-08 15:53
研究背景与核心观点 - 论文由浙江大学研究员刘忠鑫团队联合香港科技大学、德国斯图加特大学等机构共同完成,聚焦代码智能与AI在软件工程中的应用 [2] - 核心观点:当前LLM在「自然语言驱动功能添加」任务上的成功率仅20%,远低于Bug修复任务(SWE-bench成功率70%+),揭示AI在真实软件开发中的能力短板 [3][26] - 提出全新基准NoCode-bench,填补现有评测体系空白,推动AI从「修理工」向「开发工程师」转型 [6][27] NoCode-bench基准设计 - 数据来源:从开源项目的发行说明(Release Notes)提取开发者确认的功能添加条目,确保高质量与真实性 [8] - 构建流程: - 阶段1:筛选文档齐全且明确标记功能更新的开源项目 [10] - 阶段2:收集关联PR,要求必须包含文档修改以提供自然语言输入 [10] - 阶段3:采用Docker镜像+虚拟环境构建可扩展的测试环境 [16] - 阶段4:通过测试用例状态转变验证功能有效性,保留开发过程中的错误实例以反映真实场景 [16] - 阶段5:静态分析提取「标识符提示」减少评估偏差,屏蔽PR编号防数据泄露 [16] - 子集NoCode-bench Verified包含114个经人工验证的高质量实例,提升评估信度 [11] 基准任务挑战性分析 - 输入复杂度:文档变更平均长度为Bug报告的2倍,需更强文本理解能力 [12] - 定位难度:需修改的文件数和代码块数量远超Bug修复任务,涉及大量文件增删 [13] - 编辑量:平均修改代码行数为SWE-bench数倍,20%任务修改量超200行 [14] 模型性能评估结果 - 测试模型:涵盖Claude-4-Sonnet、GPT-4o、Gemini-2.5-Pro等6种SOTA模型 [18] - 最佳表现:Claude-4-Sonnet在NoCode-bench Verified上成功率仅15.79%,Agent框架下提升至15.79%但仍远低于Bug修复任务 [18][26] - 开源模型对比:DeepSeek-v3表现最优(14.91%),闭源模型中Claude-4-Sonnet领先 [18] 失败原因与改进方向 - 跨文件编辑能力缺失:模型倾向单文件修改,无法处理多文件协同编辑 [20] - 代码库理解不足:直接修改核心代码破坏软件架构,导致回归测试失败 [21] - 工具调用缺陷:Agent框架下无法稳定生成正确指令格式 [22] - 未来方向:需重点突破跨文件编辑、代码库整体理解和工具调用三大瓶颈 [27] 行业影响与开源贡献 - 行业价值:软件维护成本60%用于功能增强,NoCode-bench直击核心需求 [6] - 开源资源:完整数据集、构建流程和评估代码已开源,推动社区协作 [25] - 研究意义:首次系统评估LLM在无代码功能添加任务的能力,为AI软件工程师发展提供路线图 [27]