KoCo-Bench: Can Large Language Models Leverage Domain Knowledge in Software Development?¶
会议: ACL 2026
arXiv: 2601.13240
代码: https://github.com/jiangxxxue/KOCO-bench
领域: 信息检索
关键词: 领域代码生成, 基准测试, 领域特化, 知识语料库, 软件工程
一句话总结¶
KoCo-Bench 提出首个包含显式领域知识语料库的代码基准,覆盖 6 个新兴领域(RL、Agent、RAG 等)的 11 个框架和 25 个项目,评估 LLM 从知识语料库中获取和应用领域知识进行代码生成和知识理解的能力,揭示即使最强 coding agent Claude Code 也仅达 34.2%。
研究背景与动机¶
领域现状:LLM 在通用编程任务上表现优异,但在领域特定软件开发中需要专门的领域知识(API、规则、约束等)。领域特化方法(SFT、RAG、kNN-LM)被用于帮助 LLM 学习和使用领域知识。
现有痛点:现有领域特定代码基准(如 EvoCodeBench、DomainEval)只评估 LLM 已经知道什么知识,而非如何获取和应用新知识。它们仅提供测试集而无显式知识语料库,无法支持领域知识学习和建模的研究。
核心矛盾:领域特化方法的研究需要基准来评估效果,但现有基准缺乏知识语料库组件,导致这个方向的研究无法规范化发展。
本文目标:构建包含知识语料库+测试集的完整基准,支持评估领域特化方法在真实软件开发中的效果。
切入角度:利用软件框架的天然生态——框架自带文档、源码、示例(知识语料库),基于框架的项目实现(评估任务),形成知识获取→知识应用的完整链路。
核心 idea:以 11 个 2024 年后的新兴框架为基础,构建多来源知识语料库(文档+源码+示例),配合多粒度代码生成任务(函数级到项目级,含单元/集成测试)和领域知识理解 QA,模拟开发者基于不熟悉框架进行开发的真实场景。
方法详解¶
整体框架¶
KoCo-Bench 把「开发者上手陌生框架」这一真实场景拆成两半:一半是可供学习的知识语料库,由 11 个新兴框架的官方文档、源码和用例汇聚而成;另一半是检验学习成效的评估任务。给定一个开发需求,模型先从语料库中获取领域知识,再落到具体产出上——要么按项目/模块/函数三层描述写出能过单元与集成测试的代码,要么回答针对语料库知识点的多选题。整条链路因此覆盖了「知识获取 → 知识应用」的完整闭环,而不只是考查模型预训练里碰巧记住了什么。
关键设计¶
1. 多来源知识语料库:用时间窗口堵住数据泄漏
领域代码评估最怕的不是题难,而是答案早就背进了模型权重里。KoCo-Bench 的对策是只挑 2024 年 3 月之后才创建、且文档完善的 Python 框架,从时间上确保它们不可能出现在主流 LLM 的训练语料中,覆盖 RL、Agent、RAG、模型优化、具身 AI、昇腾生态六个新兴领域。对每个框架,语料库不只收录官方文档(平均高达 77K 行),还把源码与用例一并纳入——三类来源互补,既给出「该怎么用」的规范说明,也给出「实际怎么写」的范例,模拟开发者真正能拿到的全部学习材料。
2. 多粒度代码生成:三层需求加严格测试套件
领域开发既有「实现一个函数」的微观任务,也有「搭起整个项目」的宏观任务,单一粒度无法刻画不同代码生成技术的能力边界。为此基准提供项目概述 → 模块划分 → 核心函数的三层需求描述,把宏观意图逐级落到 131 个核心函数上,并为它们配备 978 个测试(平均每个函数 8.6 个单元测试,外加集成测试)。需求文本先经多轮多 agent 歧义消除、再过人工审核,避免模型因描述含糊而被误判失败;所有评测都在 Docker 环境中执行,保证结果可复现。密集的测试覆盖让「碰巧编译通过」很难蒙混过关。
3. 领域知识理解 QA:原子化多选题精准定位知识缺口
代码生成是个混合信号——写错可能源于知识缺失,也可能只是工程实现失误,难以单独归因到某个知识点。QA 任务用 107 道原子性多选题补上这块:每题只考一个知识点(支持多选),先由 3 个 LLM 预过滤掉过于简单的题目、再经人工审核,使得答错能直接映射到「模型不掌握这条领域知识」。它与代码生成任务形成互补——前者定位「知不知道」,后者检验「会不会用」。
实验关键数据¶
主实验¶
| 方法 | 函数级 Pass@1 | 项目级 Pass | QA 准确率 |
|---|---|---|---|
| Claude Sonnet 4.5 直接生成 | ~20% | 极低 | ~60% |
| + RAG | 边际提升 | 边际提升 | - |
| + SFT | 边际提升 | 边际提升 | - |
| Claude Code (agent) | 34.2% | - | - |
消融实验¶
| 配置 | 效果 | 说明 |
|---|---|---|
| 知识语料规模增加 | 学习效果递减 | SFT 在大语料上收益递减 |
| 跨领域持续学习 | 灾难性遗忘 | 学新领域后旧领域退化 |
| 无知识语料(直接生成) | 极差 | 证明领域知识不在预训练中 |
关键发现¶
- 即使 SOTA 闭源 LLM 在领域代码生成上也表现挣扎,Claude Code 仅 34.2%
- 现有领域特化方法(SFT、RAG、kNN-LM)仅带来边际提升,跨领域效果不一致
- Agent 方法(Claude Code)当前最有效,但仍有巨大改进空间
- 最常见错误是误用领域 API 和违反领域数据约束
- 知识语料库越大,学习效果反而递减——现有方法无法有效消化大规模领域知识
亮点与洞察¶
- "知识语料库+测试集"的双组件设计是基准设计的范式创新——使基准不仅能评估性能,还能支持领域特化方法的开发
- 选择 2024 年后的新兴框架避免数据泄漏,这种时间控制策略确保了评估的公平性
- 多轮 agent 辅助的需求歧义消除流程值得其他基准构建借鉴
局限与展望¶
- 仅覆盖 6 个 AI 相关领域,非 AI 领域(金融、医疗等)待扩展
- 131 个核心函数的规模相对较小
- 框架选择偏向 Python 生态,其他语言待覆盖
- 随着时间推移,框架知识可能逐渐进入 LLM 训练数据
相关工作与启发¶
- vs EvoCodeBench/DomainEval: 仅提供测试集,无知识语料库,只能评估已有知识而非知识获取能力
- vs SWE-bench: 聚焦 issue 修复,不涉及领域知识学习。KoCo-Bench 模拟"学新框架+开发新项目"的真实场景
评分¶
- 新颖性: ⭐⭐⭐⭐⭐ 首个包含知识语料库的领域代码基准,填补重要空白
- 实验充分度: ⭐⭐⭐⭐⭐ 覆盖多种方法(SFT/RAG/Agent)、多种 LLM、多维分析
- 写作质量: ⭐⭐⭐⭐ 结构清晰,构建细节详尽
- 价值: ⭐⭐⭐⭐⭐ 为领域特化方法研究提供了关键基础设施