yet-another-applied-llm-benchmark
用真实编程问题测试LLM的实用主义评测框架,通过自定义DSL管道实现端到端自动化评估
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
用真实编程问题测试LLM的实用主义评测框架,通过自定义DSL管道实现端到端自动化评估
加载项目详情…
本应用为开源项目,仅供学习研究,请遵守其开源协议。
图1:项目作者 Nicholas Carlini,著名AI安全研究者,现任FAR AI研究总监
2024年,AI研究员 Nicholas Carlini 在工作中遇到了一个尴尬的现实:他发现自己在日常编程中频繁向大语言模型提问,但当他真正需要解决问题时,却发现这些模型给出的答案远不如他预期的可靠。更让他困惑的是,现有的评测基准——MMLU、HumanEval、GSM8K——都无法真正反映模型在他真实工作场景中的表现。于是,他决定自己动手,用自己实际提问过的真实问题构建一个评测集。这就是 Yet Another Applied LLM Benchmark(YAALB)的诞生背景。
YAALB 是一个完全基于真实编程需求构建的LLM评测框架,通过一套自定义数据流DSL,让评测者可以轻松定义「提问→执行代码→验证输出」的端到端测试流程,衡量模型在程序员日常工作中的真实可用性。
YAALB 的核心创新在于其评测 DSL(Domain Specific Language)。Carlini 设计了一套直观的管道操作符 >>,将评测流程分解为若干步骤:
# 简单示例:问模型写hello world,运行代码,检查输出
"Write a \"hello world\" program in python" >> LLMRun() >> PythonRun() >> SubstringEvaluator("hello world")
# 进阶示例:让模型画国旗,用另一个LLM评判输出
"Write a C program that draws an american flag to stdout." >> LLMRun() >> CRun() >> \
LLMRun("What flag is shown in this image?") >> ...
这种设计的精妙之处在于:评测者可以用极少的代码表达复杂的端到端验证逻辑——提问、代码执行、输出比对,全部自动完成。模块化的设计让添加新测试用例变得极其简单,只需几十行代码即可覆盖一个真实编程场景。
从 main.py 和 evaluator.py 的源码可以清晰看到 YAALB 的执行架构:
tests/ 目录,动态加载所有 .py 文件中的 Test* 类docker_controller.py 管理容器生命周期LLM:被测模型EVAL_LLM:裁判模型(用于评估代码质量、图像内容等主观判断)VISION_EVAL_LLM:视觉裁判(用于涉及图像生成的测试)create_results_html.py 将评测结果渲染为可交互的网页报告llm.py 显示项目原生支持以下模型适配器:
| 适配器 | 对应服务 |
|---|---|
| OpenAIModel | OpenAI GPT 系列 / o1 |
| AnthropicModel | Anthropic Claude 系列 |
| MistralModel | Mistral AI |
| VertexAIModel | Google Gemini (via Vertex) |
| CohereModel | Cohere Command |
| MoonshotModel | Moonshot Kimi |
| OpenRouterModel | OpenRouter 聚合 |
| GroqModel | Groq 推理服务 |
值得注意的是,项目注释中有一行被注释掉的 LLAMAModel,说明作者曾尝试接入本地 Llama 模型,但当前版本中该支持处于未完成状态。
evaluator.py 中的 Env 类负责管理容器环境,每个测试在独立的 Docker 容器中执行代码。这意味着即使是恶意或意外的代码行为,也会被严格限制在沙箱内。docker_controller.py 提供了 invoke_docker 和 DockerJob 等接口,支持容器内进程的标准输入/输出交互。
项目内置了覆盖多种编程场景的测试集,类型包括:
README 透露作者写了近 100 个测试用例,这些用例均来自他本人 2023-2024 年间实际向 LLM 提问的问题。从测试用例命名(直接引用原始提问措辞)可以看出,这些测试并非精心设计的「最优问题」,而是保留了真实的模糊性和复杂性。Carlini 刻意不进行提示工程优化,他想知道的答案是:当你用最自然的语言提问时,模型能答对多少?
基于项目文档,各主流模型的评测结果如下:
| 模型 | 通过率 |
|---|---|
| o1-mini | 62% |
| Claude 3.5 Sonnet | 56% |
| GPT-4o | 48% |
| Gemini 1.5 Pro | 43% |
| Claude 3 Opus | 42% |
| GPT-4o Mini | 36% |
| Mistral Large | 28% |
| GPT-3.5 | 26% |
这一排名与主流基准(如 MMLU、HumanEval)的结果有显著差异。例如,Claude 3.5 Sonnet 在 YAALB 中领先 GPT-4o 8个百分点,而 Claude 3 Opus 反而低于 Gemini 1.5 Pro。这种差异揭示了:真实编程任务的表现与学术基准的排名并不完全一致。
项目提供了 Dockerfile,但需要明确其用途:Dockerfile 构建的是一个沙箱执行环境,而非 Web 服务本身。用户需要:
docker build -t ubuntu-python-app . 或通过 setup.shconfig.json:填写 OpenAI、Anthropic、Mistral 等 API 密钥pip install -r requirements.txtpython main.py --test-llm gpt-4o由于测试用例中的代码执行(Python/C/Rust编译)均在沙箱容器内完成,评测过程不需要 GPU。CPU 性能影响主要体现在代码编译步骤,但整体资源需求较为轻量。磁盘空间主要用于存放评测结果和缓存数据,2GB足够。
1. 非学术基准:Carlini 明确表示,这不是严谨的学术评测,不适用于评估模型的「知识储备」「安全性」「偏见」等维度。
2. 提示词未经优化:评测中的提问是原始措辞,未经少样本提示、思维链等技巧优化。可能存在表述不够清晰的问题。
3. 失败原因不明确:当模型答错时,无法判断是模型能力不足、提问表述歧义,还是环境配置问题。
4. 仅覆盖编程场景:测试集100%围绕编程任务,对语言理解、常识推理、数学等场景完全没有覆盖。
YAALB 最适合以下场景:
对于追求学术严谨性的基准测试需求,建议转向 MMLU-Pro、GPQA 等专业学术评测集。
| 维度 | 技术选型 |
|---|---|
| 核心语言 | Python 3.12+ |
| 沙箱隔离 | Docker |
| 评测框架 | 自定义 DSL(>> 管道操作符) |
| 模型接口 | OpenAI/Anthropic/Mistral/Vertex/Cohere/Moonshot/Groq/OpenRouter |
| 缓存 | Pickle |
| 报告生成 | Python + HTML |
| 依赖 | numpy, scipy, numba, Pillow, jax, torch, docker-py |
项目采用 GPL-3.0 开源许可证,代码结构清晰,模块化程度高,对于希望扩展自定义测试用例的开发者非常友好。
Yet Another Applied LLM Benchmark 最大的价值在于诚实:它不追求完美的评测设计,而是忠实地呈现模型在真实编程场景中的表现。对于开发者而言,这个项目最大的启发是:不要只看基准分数,要用你自己的问题来测试你的模型。
项目地址:https://github.com/carlini/yet-another-applied-llm-benchmark | GPL-3.0 License | 1059 Stars | 80 Forks