Qwen3-Coder 评测体系解读以 granite-code-34b 报告为例读懂 DevQualityEval v0.5.0 基准的评分逻辑与结果数据【免费下载链接】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 基准报告 granite-code-34b/README.md 展开该报告是 symflower DevQualityEval 基准v0.5.0于 2024-06-20 12:20:38 对本地 Ollama 模型ollama/granite-code:34b生成的评测快照。读完本文你能掌握这类评测报告的完整结构分类体系、CSV 指标列、汇总文件含义、每个分数的计算公式以及如何结合基准源码正确解读 granite-code-34b 在 Go/Java 测试生成任务上的真实表现。报告是什么一份针对单一模型的 write-tests 任务评测快照报告首页给出三个关键元信息评测时间Evaluation from 2024-06-20 12:20:38生成工具DevQualityEval 基准version 0.5.0评测对象ollama/granite-code:34b通过 Ollama 本地推理服务的 34B 代码模型。报告正文包含一段必须重视的免责声明原文引用Keep in mind that LLMs are nondeterministic. The following results just reflect a current snapshot. 请注意 LLM 是非确定性的。以下结果只反映当前快照。即同一模型重跑可能得到不同分数下文所有数据都只应视为某一次运行的观测值不能当作模型的稳定能力上限或下限。该报告目录下实际保留了以下文件仓库内均可直接查看文件内容README.md人类可读报告分类定义 模型归类evaluation.csv按 模型/语言/仓库/任务 粒度的详细打分models-summed.csv按模型汇总的各项指标golang-summed.csv / java-summed.csv按语言汇总的各项指标categories.svg各分类下模型数量的条形图由报告生成器绘制需要说明的是README 中提到的./evaluation.log完整评测日志与./ollama_granite-code:34b/模型逐请求日志目录在当前仓库快照中并未保留仓库内仅保存了 CSV 与 SVG。因此本文的数据佐证全部来自四个 CSV 文件与基准源码。报告的生成机制与分类体系报告由 Go 模板渲染分类来自固定注册表从源码结构看这份 README 并非手写而是由 evaluate/report/markdown.go 中的text/template模板渲染而成模板依次输出评测时间戳、分类条形图、DevQualityEval benchmark in version X 声明、七个分类的定义列表以及每个分类下列出模型的章节。报告生成器还会调用 markdown.go 中的barChartModelsPerCategoriesSVG基于 go-chart 库绘制分类-模型数条形图即报告里的categories.svg模型日志目录名则经ModelLogName做文件系统清洗如ollama/granite-code:34b变成ollama_granite-code:34b这解释了 README 中链接路径的斜杠替换规则。详细打分数据由 evaluate/report/csv.go 的EvaluationHeader()写入 CSV前 5 列为model-id, language, repository, task, score其后按metrics.AllAssessmentKeysStrings追加全部指标列。仓库中 granite-code-34b 的 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与源码注册的指标一一对应。七个结果分类的含义与判定顺序报告列出的七个分类并非人工标签而是由 evaluate/metrics/category.go 注册的固定常量报告按注册顺序原样输出分类含义报告原文释义源码判定条件category.go 的Category()按序短路匹配category unknown无法归类任务总数为 0 时直接返回该分类response error响应出错无错误响应次数未达到全部任务的理论满分no code未产生代码响应含代码次数与可执行文件次数均未达满分源码注释说明这是为规避代码检测不总可靠的兜底见同文件 L87 处 TODOinvalid code生成了无效代码成功执行的文件数未达满分executable code生成了可执行代码语句覆盖未达满分statement coverage reached达到全语句覆盖响应无多余内容次数未达满分no excess response无多余响应以上全部达标判定逻辑的核心是一致性源码注释明确写道模型只有在所有任务上都满足某一级标准时才归入该级——例如 3 个任务中只有 1 个任务达到覆盖目标模型最高只能归到executable code。为什么 granite-code:34b 被归入 category unknowngranite-code-34b 报告的归类章节只有一节Result category category unknownModels in this category could not be categorized.ollama/granite-code:34b结合 category.go 的逻辑Category(totalTasks)在入参为 0 时返回 unknown而报告模板调用它时传入的是m.TotalScore结构体注释每任务的理论总分。v0.5.0 的其余各模型报告如 gpt-4/README.md、codeqwen/README.md、claude-3.5-sonnet/README.md同样全部落入 category unknown。因此可以推断在 v0.5.0 这一版报告生成中TotalScore传入值为 0导致分类图对所有模型都退化为 unknown——这是一个报告生成侧的问题并不表示模型本身评测失败CSV 中有完整得分可以证明。阅读 v0.5.0 报告时应以 CSV 分数为准而非首页的分类章节。评分体系每个分数是怎么算出来的奖励点定义基准 READMEqwencoder-eval/instruct/eval-dev-quality/README.md给出的奖励规则是response-no-error无错误响应 1response-not-empty响应非空 1response-with-code响应包含源码 1compiled源码编译通过 1statement-coverage-reached每达到一个覆盖对象 10transpile/code-repair任务禁用no-excess响应未包含超出要求的内容 1passing-tests每通过一个测试 10write-test任务禁用在源码侧这些指标通过 evaluate/metrics/assessment.go 的RegisterAssessmentKey注册并携带乘数files-executed成功执行文件数乘数为 1coverage乘数为 10tests-passing乘数为 10response-no-error/response-with-code/response-no-excess乘数均为 1processing-time、response-character-count等记录型指标乘数为 0只记录不计分。总分由 Score() 对所有非零乘数指标求和得到。用 granite-code:34b 的原始行验证公式evaluation.csv 中 4 行记录全部为write-tests任务score列可逐项验证为coverage files-executed response-no-error response-with-code response-no-excesslanguage / repositoryscorecoveragefiles-executedresponse-no-errorresponse-with-coderesponse-no-excess验算golang/light1870158051115883615805111588361870golang/plain2010153110153120java/light5191486050115907648605011590765191java/plain2310154310154323四个write-tests案例仓库对应 testdata 下的数据集plain是极小仓库每次 5 个请求light是稍大的仓库每次 115 个请求即逐文件生成单元测试这与各语言测试数据目录 golang/light、golang/plain、java/light、java/plain 的规模一致。基准对模型的指令形如摘自基准 README 的运行日志示例Given the following Go code file ... 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.——100% 覆盖 必须编译 只返回测试代码三个约束分别对应coverage、files-executed、response-no-excess三个指标。granite-code:34b 的指标汇总与解读汇总数据直接来自报告 CSVmodels-summed.csv 给出该模型的全量汇总指标数值说明score7104四项记录之和187020519123coverage6460覆盖对象总数×10 后即为覆盖得分files-executed103240 个请求中仅 103 个请求的测试代码成功执行约 42.9%response-no-error240240 个请求全部无 API/推理错误response-no-excess116约 48.3% 的响应满足只含测试代码response-with-code185约 77.1% 的响应中成功解析出代码processing-time45,568,338 ms全程约 12.7 小时本地 34B 推理response-character-count208,065模型输出总字符数generate-tests-for-file-character-count185,689待生成测试的源码文件总字符数按语言拆分golang-summed.csv / java-summed.csv维度GoJavascore18905214coverage15904870files-executed52 / 12051 / 120response-no-excess37 / 12030.8%79 / 12065.8%response-with-code91 / 12094 / 120processing-time25,356,039 ms约 7.0 h20,212,299 ms约 5.6 h可以得出的三点观察Java 显著强于 GoJava 总分 5214 约为 Go 的 2.76 倍两者执行成功率接近51 vs 52差距主要来自 Java 侧更高的 coverage4870 vs 1590说明该模型生成的 Java 测试更能实际跑通并覆盖语句而 Go 测试失败率更高。只输出代码约束遵守不佳Go 侧只有 30.8% 的响应不带多余内容Java 侧 65.8%response-with-code未达满分185/240也说明约 23% 的响应没能解析出有效代码。对 granite-code:34b 这类基座非 instruct 调优模型而言输出格式约束是主要失分点。推理开销大本地 Ollama 跑 240 个请求耗时约 12.7 小时这是本地大模型 逐文件生成测试这类评测的典型成本量级选型时应把processing-time列为与 score 同等重要的参考列。与同版本其他模型的横向参照v0.5.0 的总表 docs/reports/v0.5.0/evaluation.csv 记录了同批评测的多模型结果均为 write-tests 任务总分 4 行 score 之和数据直接取自该 CSV非外部来源模型总分coverage备注granite-code:34b本报告71046460Ollama 本地 34Bgranite-code:34b-instruct-f1668926220同尺寸 instruct 变体总分略低于基座版granite-code:3b-instruct-q8_0761871603B 模型反超 34B 基座版单快照勿过度解读codeqwen:latest57565190同批 Ollama 评测的 Qwen 系代码模型gpt-4OpenRouter1819817320API 模型参考线gpt-4oOpenRouter1923618300API 模型参考线几点解读需要克制表中数字只是各模型各自一次运行的快照非确定性声明适用于所有行本地 Ollama 模型与云端 API 模型的部署方式、温度等配置可能不同跨行对比只能说明量级不能得出谁更强的绝对结论。但同口径的对照同为 Ollama、同为 granite 家族仍是有价值的在 v0.5.0 这一批数据里granite-code:34b 的 7104 分位于 granite 家族基座模型的第一梯队且 Java 明显强于 Go——这与上文逐行数据的结论一致。如何复现一份这样的报告如果你希望按同样流程评测自己的模型例如 Qwen3-Coder基准的入口与命令在 README 中有完整说明核心步骤安装需要 Go 环境执行go install -v github.com/symflower/eval-dev-quality/cmd/eval-dev-quality得到eval-dev-quality二进制选择推理通道ollama前缀模型走本地 Ollama监听默认端口 11434如--model ollama/granite-code:34bopenrouter前缀走 OpenRouterPROVIDER_TOKENopenrouter:${key}也支持任意 OpenAI 兼容端点--urlscustom-${name}:${endpoint}--tokenscustom-${name}:${key}运行评测eval-dev-quality evaluate --model model-id会在所有语言仓库上跑全部任务产出逐请求日志、evaluation.csv与REPORT.md安全注意官方明确默认不在沙箱中执行 LLM 生成的代码复现时应使用--runtime dockerdocker build . -t eval-dev-quality:dev后加--runtime docker --runtime-image eval-dev-quality:dev在隔离容器中执行每个仓库可通过根目录repository.json的{tasks: [write-tests]}限定任务集——granite-code-34b 报告中的 4 行记录正是write-tests单任务在 golang/java 两个语言 × plain/light 两个仓库上的完整展开。小结granite-code-34b 的这份 v0.5.0 报告是理解 DevQualityEval 报告体系的理想样本首页的七分类与归类章节由 category.go 的注册表与短路判定生成且 v0.5.0 中因TotalScore为 0 全部退化为 category unknown应改看 CSV真实成绩在 evaluation.csv 中按覆盖×10 执行×1 三项响应质量×1可逐项验算granite-code:34b 的最终画像——Java 强于 Go、代码输出格式约束遵守约五成、本地推理约 12.7 小时/240 请求——都直接来自报告内四个 CSV而非任何外部排名。掌握了这套模板 → 指标注册 → CSV 列 → 可验算公式的阅读链路你就能同等解读仓库中 v0.5.0 目录下全部 70 余个模型的报告。【免费下载链接】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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考