DevQualityEval v0.5.0 评测报告解读：Qwen3-Coder 评测仓库中 goliath-120b 的测试生成基准成绩与计分体系

DevQualityEval v0.5.0 评测报告解读：Qwen3-Coder 评测仓库中 goliath-120b 的测试生成基准成绩与计分体系

【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder

本篇以 Qwen3-Coder 评测仓库中归档的一份 DevQualityEval v0.5.0 评测报告（qwencoder-eval/instruct/eval-dev-quality/docs/reports/v0.5.0/goliath-120b/README.md）为主体，完整还原该报告的结果分类、原始 CSV 数据与汇总口径，并结合基准源码说明评分倍率与类别判定逻辑。读完后你可以独立复现一次eval-dev-quality评测，并能读懂仓库中所有 v0.5.0 版模型报告的每一列数字意味着什么。

一、报告从何而来：DevQualityEval 基准速览

该报告由 DevQualityEval（eval-dev-quality）基准在version 0.5.0时点自动生成，生成时间为2024-06-19 08:43:56（见报告首行标题）。本仓库的 qwencoder-eval/instruct/eval-dev-quality/ 目录是这套 Go 语言编写评测框架的完整归档，其 主 README 说明：

An evaluation benchmark and framework to compare and evolve the quality of code generation of LLMs.

即它为 LLM 开发者提供一套标准化基准来改进代码生成的实际使用质量，同时为 LLM 用户提供衡量"某个 LLM 是否适合自己的任务"的指标与横向对比。基准的核心任务类型是write-tests（编写测试）：从源码仓库中取一份代码文件，要求模型生成一份能编译、且达到 100% 语句覆盖率的测试文件，然后真实执行该测试并统计结果。主 README 中给出的示例提示词即为：

Given the following Go code file "plain.go" with package "plain", provide a test file for this code. The tests should produce 100 percent code coverage and must compile. The response must contain only the test code and nothing else.

复现一次评测的标准流程（引自主 README 的 Installation/Usage 章节）：

# 1. 安装 Git 与 Go 后安装命令行工具 go install -v github.com/symflower/eval-dev-quality/cmd/eval-dev-quality # 2. 配置模型供应商凭证（以 openrouter 为例） export PROVIDER_TOKEN=openrouter:${your-key} # 3. 运行全部基准任务（或仅评测指定模型） eval-dev-quality evaluate eval-dev-quality evaluate --model=openrouter/meta-llama/llama-3-70b-instruct

主 README 同时给出重要安全提示：该基准默认不在沙箱中执行模型生成的代码，建议在隔离环境中运行（例如--runtime docker）。执行结束后会产出一份evaluation.csv结果文件以及报告文件REPORT.md（含各模型结果与明细文件链接），eval-dev-quality evaluate --help可查看全部参数。测试输入来自 testdata/ 目录下的golang/、java/、ruby/三个语言子集；本报告涉及的golang/light、golang/plain、java/plain即其中的具体仓库。

二、goliath-120b 报告的结构与文件清单

本次评测对象为openrouter/alpindale/goliath-120b，报告目录 docs/reports/v0.5.0/goliath-120b/ 下保留 6 个文件：

文件	作用
README.md	报告正文：生成时间、结果分类说明、模型分类清单
categories.svg	柱状图，按类别对所有被评模型可视化
evaluation.csv	逐任务明细（model/language/repository/task 及各指标）
golang-summed.csv	按语言（golang）汇总
java-summed.csv	按语言（java）汇总
models-summed.csv	按模型（跨语言）汇总

需要注意两处引用缺失：报告正文链接的./evaluation.log（完整执行日志）与模型子目录./openrouter_alpindale_goliath-120b/（每个模型的全部输出）并未随仓库保留，仓库中仅存上述 CSV 与 SVG。此外报告开头特别声明：

Keep in mind that LLMs are nondeterministic. The following results just reflect a current snapshot.

即所有数字只是某次运行快照，LLM 输出具有非确定性，复跑可能出现波动。

三、结果分类体系：7 个类别的定义与判定逻辑

报告将模型结果划入以下类别（原文逐条定义）：

• category unknown：Models in this category could not be categorized.（无法归类）
• response error：Models in this category encountered an error.（响应出错）
• no code：Models in this category produced no code.（未产出代码）
• invalid code：Models in this category produced invalid code.（产出代码不可执行）
• executable code：Models in this category produced executable code.（产出可执行代码）
• statement coverage reached：Models in this category produced code that reached full statement coverage.（达到完整语句覆盖率）
• no excess response：Models in this category did not respond with more content than requested.（未输出多余内容）

这 7 个类别与源码 evaluate/metrics/category.go 中注册的AssessmentCategory一一对应（ID 分别为category-unknown、response-error、response-no-code、code-invalid、code-executed、code-coverage-statement、code-no-excess）。

类别判定函数Category()（category.go#L79-L97）遵循一个"一致达成"原则，其注释原文为：模型的整体类别对应于它在所有任务上都稳定拿满分数的最高档标准——例如 3 个任务中代码全部能执行、但只有 1 个任务达到覆盖率目标，则类别只能算到 "executable code"，因为覆盖率目标未被一致达成。实现上是一个级联switch，按顺序检查各评估项的累计值是否等于totalTasks × 该项倍率：未全部达成"响应无错误"判response-error；未全部达成"含代码且文件可执行"判no code；未全部达成"文件可执行"判code-invalid；未全部达成覆盖率判executable code；未全部达成"无多余输出"判statement coverage reached；全部达成则判no excess response。

需要说明版本差异：从当前源码看，category unknown是totalTasks == 0（没有任何任务可评估）时的兜底分支；而 goliath-120b 报告由 v0.5.0 生成，该模型在 CSV 中实际有 3 条任务记录，却仍被归入 "category unknown"。可以推断这是 v0.5.0 时的判定口径与当前源码存在差异所致，解读归档报告时应以报告自身记录的分类为准，而把源码逻辑作为理解各类别语义的参考。

四、goliath-120b 的原始评测数据

evaluation.csv 完整内容如下（表头为model,language,repository,task,score,coverage,files-executed,generate-tests-for-file-character-count,processing-time,response-character-count,response-no-error,response-no-excess,response-with-code）：

model	language	repository	task	score	coverage	files-executed	输入文件字符数	processing-time (ms)	响应字符数	response-no-error	response-no-excess	response-with-code
openrouter/alpindale/goliath-120b	golang	golang/light	write-tests	277	100	4	73757	2177772	81587	115	17	41
openrouter/alpindale/goliath-120b	golang	golang/plain	write-tests	22	10	1	1550	63083	2659	5	2	4
openrouter/alpindale/goliath-120b	java	java/plain	write-tests	9	0	0	3055	90529	4305	5	0	4

三个汇总文件则给出按语言与按模型的加总：

汇总文件	score	coverage	files-executed	processing-time (ms)	响应字符数	no-error	no-excess	with-code
models-summed.csv	308	110	5	2331384	88551	125	19	49
golang-summed.csv	299	110	5	2240855	84246	120	19	45
java-summed.csv	9	0	0	90529	4305	5	0	4

汇总口径可以直接验证：score 上 277+22=299（golang）、277+22+9=308（模型总计）；coverage 100+10+0=110；files-executed 4+1+0=5；processing-time 2177772+63083+90529=2331384 ms（约 38.9 分钟）；各计数字列同样逐列相加吻合。也就是说，语言级与模型级 CSV 就是明细 CSV 的简单累加，没有任何加权或截断。

从数据可以读出这份快照的画像：

1. Go 语言表现尚可：golang/light任务有 4 个文件成功执行、coverage 记为 100，golang/plain也有 1 个文件执行且 coverage 为 10，两条 Go 任务合计贡献 299 分。
2. Java 任务完全失手：java/plain任务 0 个文件可执行、coverage 为 0，9 分全部来自"响应无错误"（5）与"响应含代码"（4）这类格式分，没有任何代码真正跑起来。
3. 输出冗长且不稳定：模型总响应约 8.8 万字符，其中response-no-excess（无多余输出）仅 19，明显低于response-with-code（49）；即大量回复夹带了请求之外的内容，这与任务提示词"must contain only the test code and nothing else"的要求相违背。
4. 最终类别：报告将openrouter/alpindale/goliath-120b列入 "category unknown"，正文原话为 "Models in this category could not be categorized."。结合 CSV 看，Java 任务未产出任何可执行文件、Go 任务覆盖率也未在所有任务上一致达标，模型未稳定达到任何一档类别的"全部达成"标准。

五、计分体系：评估项、倍率与 Score() 函数

理解 CSV 中 score 一列的来源，需要看 evaluate/metrics/assessment.go 中注册的评估项及其倍率：

评估项（CSV 列名）	倍率	语义
files-executed	1	成功编译/执行的文件数，每文件 1 分
coverage	10	执行覆盖统计，倍率 10（按点累积）
tests-passing	10	通过测试的比例（代码修复类任务使用）
response-no-error	1	模型响应无错误
response-with-code	1	响应中检测到代码
response-no-excess	1	响应未包含超出请求的内容
processing-time、response-character-count、generate-tests-for-file-character-count	0	仅作统计记录，不计分

Score()函数（assessment.go#L107-L120）的实现就是"遍历所有评估项，把倍率非 0 的项的值累加起来"。主 README 示例日志中的一行完整打分示例可直接对照理解（见 README.md#L131）：

Evaluation score for "openrouter/meta-llama/llama-3-70b-instruct" ("code-no-excess"): score=12, coverage=2, files-executed=2, response-no-error=2, response-no-excess=2, response-not-empty=2, response-with-code=2

即 2+2+2+2+2+2=12，该模型最终类别为code-no-excess。需要指出：该日志示例出自较新版本，包含response-not-empty一项，而 v0.5.0 的 goliath-120b CSV 表头没有这一列；从源码结构看，不同版本间 CSV 的列布局并不完全一致，逐列核对分数时应对照报告自身版本的表头。

报告的物化（Markdown、CSV、SVG）由 evaluate/report/ 下的markdown.go、csv.go、collection.go等模块完成；具体任务实现（write-tests、code-repair、transpile 等）位于 evaluate/task/ 目录，基准版本号则记录在 evaluate/version.go。这也解释了为何每个模型目录下总是同时出现README.md + categories.svg + 若干 *-summed.csv的固定组合。

六、如何复现这样一份报告

前提：安装 Git 与 Go，并建议在隔离环境（如 Docker）中运行，因为基准默认直接执行模型生成的代码。步骤：

1. 按上文命令安装eval-dev-quality二进制；
2. export PROVIDER_TOKEN=...配置模型访问凭证（如 openrouter 的 key）；
3. 执行eval-dev-quality evaluate --model=openrouter/alpindale/goliath-120b，仅评测该模型；不带--model则跑全部模型、语言与仓库组合；
4. 运行结束后查看工作目录生成的evaluation.csv与REPORT.md，日志会逐条打印请求提示词、模型响应、symflower test --language <lang> --workspace <tmp>的执行输出（测试是否 PASS、coverage: 100.0% of statements等）以及最终各类别判定。

两点使用限制：其一，模型响应非确定，复跑结果会与本报告快照存在差异；其二，v0.5.0 是当前仓库docs/reports/下保留的最完整版本之一（另有 v0.2.0/、v0.4.0/、v0.6/），跨版本对比时需注意类别判定与 CSV 列布局可能不同。

七、小结

这份 goliath-120b 报告是 DevQualityEval v0.5.0 对约 100 个模型做横向评测时产出的归档之一：它用 7 个由源码 category.go 定义的类别刻画模型能力档位，用 assessment.go 中的倍率体系（files-executed×1、coverage×10、tests-passing×10 等）量化打分，并以逐任务 CSV 加按语言/按模型累加的形式留档。对 goliath-120b 而言，308 分里 Go 任务贡献了 299 分，Java 任务因 0 个文件可执行只拿到 9 分格式分，模型最终落入 "category unknown"。若你要在 Qwen3-Coder 的评测流程中参照这套基准，可直接复用eval-dev-quality的安装与运行方式，并对自家模型生成同样结构的报告进行归档对比。

【免费下载链接】Qwen3-CoderQwen3-Coder is the code version of Qwen3, the large language model series developed by Qwen team.项目地址: https://gitcode.com/GitHub_Trending/co/Qwen3-Coder