ML-Bench：评测大模型在仓库级代码上的机器学习任务能力

ML-Bench 评测框架概览

背景：当大模型遭遇真实代码仓库

一个真实的痛点场景是：你想用 GPT-4 帮你在一个陌生的开源项目里完成某个功能——比如给 scikit-learn 提交一个参数优化补丁。你把整个仓库扔给模型，结果它生成的代码根本跑不通：参数名对不上、依赖没装、路径找不到。这不是模型的错，而是现有评测基准太简单——它们只考"写一个函数"，而真实工作需要"理解整个仓库的上下文"。

ML-Bench 正是为解决这个gap而生。它由耶鲁大学 Gerstein 实验室发布，核心目标是：在真实的 GitHub 仓库上，评测 LLM 和 AI Agent 完成端到端机器学习任务的能力。论文入选 NeurIPS 2024 的 D&B（Demonstration & Benchmarking）track，说明其学术影响力得到认可。

任务分布图

核心设计：两个评测维度 + 一个数据集

ML-LLM-Bench：评测纯文本能力

这个赛道测试的是：给 LLM 提供任务描述 + 代码上下文，它能否直接生成可执行的代码片段？评测采用三种输入设置，难度递增：

• Oracle Segment（理想条件）：人工标注员从 README 中标注出"最优代码段落"作为上下文，模型闭眼拿标准答案。
• BM25 Retrieval（半自动）：用 BM25 检索器自动从仓库文档中抽取相关内容，模拟更真实的场景。
• Code（极限条件）：直接把整个代码仓库（README 置顶）喂给模型，不做任何信息筛选。

结果表明，GPT-4o 在 **Pass@5（5次尝试内成功）**指标上超过 50%，是唯一突破这道线的模型。而人类标注员（计算机专业研究生）的成功率是 86.76%，说明当前模型还有约 35 个百分点的提升空间。

更值得深思的是错误分析：LLM 最常见的问题是幻觉输出（hallucination）——生成根本不存在的参数名、引用不存在的文件路径。生成 Bash 脚本比生成 Python 代码更困难，这暴露了模型在非主流语言上的能力短板。

ML-Agent-Bench：评测自主执行能力

这个赛道更硬核：模型不是生成代码就完事，而是要在 Linux 沙盒中自主完成整个任务——安装依赖、配置环境、编写代码、执行测试。GPT-4o 在 OpenDevin Agent 环境下达到 76.47% 成功率，说明通过"行动-反馈-迭代"机制，模型可以显著提升复杂任务表现。

数据集规模

ML-Bench 数据集包含 9,641 个评测样例，覆盖 18 个真实 GitHub 仓库，涵盖代码理解、文档理解、跨文件检索、包安装、数据下载等 5 类子任务。这比此前最大的 HumanEval（164 题）和 MBPP（974 题）在复杂度和规模上都高出一个数量级。

技术架构解析

代码结构

ML-Bench/
├── evaluation/        # OpenDevin 集成评测代码
├── envs/             # 评测环境配置（Linux 沙盒）
├── repos/            # 被测目标仓库（作为 submodule）
├── scripts/          # 评测脚本
│   ├── api/          # API 调用封装
│   ├── finetune/     # 开源模型微调流程
│   ├── openai/       # OpenAI 模型评测
│   └── post_process/ # 数据后处理
├── utils/            # 执行引擎、模型下载脚本
└── requirements.txt

依赖生态

项目以 Python 为核心，配套使用 PyTorch 生态（torchrun 分布式训练）、HuggingFace 工具（datasets、transformers、llama-recipes）、OpenAI API。评测框架支持 Docker 容器化（AWS ECR 镜像），保证环境一致性。

AI/ML 组件

ML-Bench 本质上是一个评测工具，而非 AI 模型。它评测的对象包括 GPT-4o、Claude 3 系列、CodeLlama、DeepSeek-Coder 等主流 LLM。自身代码不含训练/推理组件，所有 AI 能力通过调用外部 API 实现。

上手体验：评测流程详解

快速启动（ML-LLM-Bench）

# 1. 克隆仓库（带 submodule）
git clone --recurse-submodules https://github.com/gersteinlab/ML-Bench.git
cd ML-Bench

# 2. 安装依赖
pip install -r requirements.txt

# 3. 拉取 Docker 评测环境（推荐）
docker pull public.ecr.aws/i5g0m1f6/ml-bench
docker run -it -v ML_Bench:/deep_data public.ecr.aws/i5g0m1f6/ml-bench /bin/bash

# 4. 下载模型权重（耗时约 2 小时）
bash utils/download_model_weight_pics.sh

# 5. 配置并运行评测
# 修改 exec.sh 中的 --input_path 和日志路径
bash utils/exec.sh

评测结果会输出到 output/ 目录，包含每次执行的 JSONL 结果文件。

微调开源模型

如果你想用 ML-Bench 的训练数据微调 CodeLlama：

torchrun --nproc_per_node 2 finetuning.py \
    --use_peft --peft_method lora --enable_fsdp \
    --model_name codellama/CodeLlama-7b-Instruct-hf \
    --context_length 8192 --dataset mlbench_dataset \
    --output_dir OUTPUT_PATH --task TASK

值得注意的是，在分布内数据上微调后，CodeLlama-7B 从 8.85% 提升到 15.76%（Pass@5），但仍未超越 GPT-4o，说明模型规模带来的差距不是微调能弥补的。

争议与局限性

1. 评测 API 成本：评测 GPT-4o 需大量 OpenAI API 调用，成本不菲；评测开源模型需下载权重+配置推理服务，门槛同样不低。
2. 环境依赖复杂：repos/ 目录作为 Git submodule，首次克隆耗时久；Docker 镜像是 AWS ECR 地址，国内访问可能受限。
3. 评测粒度问题：ML-Bench 主要评测"任务完成率"，但未深入分析代码质量、可维护性等维度。
4. Agent 评测的黑盒性：ML-Agent-Bench 依赖 OpenDevin 框架，Agent 的决策过程缺乏可解释性。

行业意义与趋势

ML-Bench 揭示了一个重要规律：当前 LLM 的核心瓶颈不是"生成代码"，而是"理解长上下文代码"。平均每个仓库的上下文长度约 150k tokens，现有模型的上下文窗口虽然够大，但真正理解和利用的能力仍不足。

从趋势看，ML-Bench 代表的"真实仓库 + 端到端评测"路线正在成为新标准——它比函数级评测更能反映模型的实际可用性，也更能指导开发者在真实场景中选择合适的模型。

总结

维度	评价
学术价值	⭐⭐⭐⭐⭐（NeurIPS 2024 收录，填补仓库级评测空白）
工程完整度	⭐⭐⭐⭐（Docker + 脚本完备，文档清晰）
上手难度	⭐⭐⭐（依赖复杂，需要 OpenAI API 或 GPU 资源）
实用价值	⭐⭐⭐⭐⭐（直接指导模型选型和 Prompt 优化）
局限性	仅评测 Python 项目，Agent 评测依赖 OpenDevin 框架

一句话评价：ML-Bench 是目前最接近真实场景的 LLM 代码能力评测基准，尤其适合想客观评估"我的模型能不能干实际工程活儿"的团队。