企业官网建设流程全解析

Qwen3-Coder 仓库中 DevQualityEval v0.5.0 评测报告解析:llama-3-sonar-large-32k-chat 的 write-tests 得分与指标体系

【免费下载链接】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 仓库内 qwencoder-eval/instruct/eval-dev-quality/docs/reports/v0.5.0/llama-3-sonar-large-32k-chat/README.md 这份单模型评测报告为主体,完整继承其中的结果分类体系与模型归属结论,并结合同目录下的 CSV 数据文件与 eval-dev-quality 框架源码,讲清llama-3-sonar-large-32k-chat在 DevQualityEval v0.5.0 基准中 write-tests 任务的得分构成、各指标列的确切含义、七级模型分类的判定逻辑,以及如何在本地复现这份评测。读完本篇,你可以独立解读该基准任意一份单模型报告,并能自行运行同一基准评测其他模型。

报告出处:DevQualityEval v0.5.0 系列中的单模型页面

该 README 由 DevQualityEval 基准框架(仓库内位于 qwencoder-eval/instruct/eval-dev-quality/ 的 vendored 副本)生成,报告头标注的生成时间为 2024-06-19 11:14:50,工具版本为version 0.5.0。整个 v0.5.0 系列报告位于 docs/reports/v0.5.0/,包含数十个模型的子目录(每个子目录对应一个被评测模型)以及跨模型汇总 CSV;本文聚焦的是llama-3-sonar-large-32k-chat这个模型目录,其中实际存在的文件为:

原 README 中还链接了完整评测日志./evaluation.log,但该日志文件并未随仓库保存,目录中只有上表列出的文件。报告正文特别提醒:"LLMs are nondeterministic. The following results just reflect a current snapshot."——评测结果具有随机性,数值只代表生成时刻的一次快照,引用时应保留这层前提。

评测任务定义:write-tests(生成满足覆盖率要求的单元测试)

该模型在 4 种“语言 × 仓库”组合上执行了同一任务write-tests,组合来自 evaluation.csv 的repository列:golang/plain、golang/light、java/plain、java/light。

任务实现位于 evaluate/task/task-write-test.go:框架遍历仓库中的每个实现文件,要求模型“为给定文件生成一个测试文件,使测试达到 100% 代码覆盖率、能够编译,且响应中只包含测试代码本身”。框架 README 中保留了一条真实的请求/响应日志,可以看到下发给模型的提示词原貌(以 Go 为例):

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. ```golang package plain func plain() { return // This does not do anything but it gives us a line to cover. }

Java 侧的变体则要求使用 JUnit 5 作为测试框架(见 [qwencoder-eval/instruct/eval-dev-quality/README.md](https://link.gitcode.com/i/4117936ed1c0851d364970bb9e73f206) 中的 Java 提示词示例)。从 `response-no-error` 列(每语言 120,合计 240)可以推断,每个语言组合下共有 120 个待生成测试的文件:`plain` 仓库是极小的样本(5 个文件),`light` 仓库则是文件数更多的轻量仓库(115 个文件)。生成后的测试代码通过 `symflower test --language <lang> --workspace <path>` 之类的命令实际执行,以此判定是否编译、是否通过并统计覆盖率。 ## 原始结果:逐仓库得分与汇总 ### 按“语言 × 仓库”的逐行结果 [evaluation.csv](https://link.gitcode.com/i/eeff19ab998f101e2a14eb407c81500b) 完整内容如下(model 列统一为 `openrouter/perplexity/llama-3-sonar-large-32k-chat`,task 均为 `write-tests`): | language | repository | score | coverage | files-executed | generate-tests-for-file-character-count | processing-time | response-character-count | response-no-error | response-no-excess | response-with-code | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | golang | golang/light | 3979 | 3540 | 102 | 78680 | 794481 | 80473 | 115 | 107 | 115 | | golang | golang/plain | 70 | 50 | 5 | 370 | 5524 | 424 | 5 | 5 | 5 | | java | java/light | 13071 | 12700 | 98 | 125732 | 867300 | 132028 | 115 | 43 | 115 | | java | java/plain | 68 | 50 | 5 | 1357 | 10949 | 1562 | 5 | 3 | 5 | ### 按语言与全量汇总 - [golang-summed.csv](https://link.gitcode.com/i/983be460e1a0ca1dbee63069f860904c):score=4049(3979+70),coverage=3590,files-executed=107(102+5),response-no-error=120,response-no-excess=112,response-with-code=120,processing-time=800005(ms)。 - [java-summed.csv](https://link.gitcode.com/i/55101fdd00c52f16d28b743a076662d8):score=13139,coverage=12750,files-executed=103(98+5),response-no-error=120,response-no-excess=46,response-with-code=120,processing-time=878249(ms)。 - [models-summed.csv](https://link.gitcode.com/i/ab029e4c201c3325ecbfbd4aeea75afe):score=**17188**,coverage=16340,files-executed=210,generate-tests-for-file-character-count=206139,processing-time=1678254(ms,约 28 分钟),response-character-count=214487,response-no-error=240,response-no-excess=158,response-with-code=240。 从这两份按语言汇总的数据可以直接读出该模型的强弱分布:Java 任务得分(13139)远高于 Go(4049),但 Java 侧的 `response-no-excess` 只有 46/120(Go 侧为 112/120)——即在 Java 任务中,模型有约 60% 的响应“附带了超出测试代码本身的内容”,触发了框架对“多余响应”的扣分项。 ## CSV 各列口径:指标定义与 score 的构成 这些列并非随意命名,每一列都对应 [evaluate/metrics/assessment.go](https://link.gitcode.com/i/7860bc92f4f81678cca202c63a482231) 中注册的一个 `AssessmentKey` 及其打分乘数(multiplier): | CSV 列 | 源码中的 key 与乘数 | 含义 | | --- | --- | --- | | `score` | 各乘数非零项之和(见 `Assessments.Score()`) | 总分 | | `coverage` | `coverage`,乘数 10 | 已执行的覆盖率对象数,每 1 个对象计 10 分,上不封顶 | | `files-executed` | `files-executed`,乘数 1 | 生成的测试文件能成功执行的文件数 | | `generate-tests-for-file-character-count` | 乘数 0 | 被测实现文件的字符数(仅作规模参考,不计分) | | `processing-time` | 乘数 0 | 完成任务耗时(毫秒),仅作效率参考,不计分 | | `response-character-count` | 乘数 0 | 模型响应字符数,仅作参考,不计分 | | `response-no-error` | 乘数 1 | 无请求/响应错误的任务数 | | `response-no-excess` | 乘数 1 | 响应未包含多余内容的任务数 | | `response-with-code` | 乘数 1 | 响应中确实包含代码的任务数 | 用这些定义可以完整验算出总分:`16340 (coverage) + 210 (files-executed) + 240 (response-no-error) + 240 (response-with-code) + 158 (response-no-excess) = 17188`,与 `score` 列完全一致。这也说明该模型在“无错误响应”和“响应含代码”两项上满分(240/240),失分点集中在覆盖率未打满(16340 分,而 240 个文件的文件执行数只有 210,即有 30 个文件的测试未能执行)与 Java 侧的多余响应(158/240)两处。 ## 七级分类体系与该模型的归属 报告正文给出的分类定义与 [evaluate/metrics/category.go](https://link.gitcode.com/i/3a2074a152935636483366a540624d42) 中注册的 `AssessmentCategory` 一一对应(名称与描述逐字一致): | 分类 | 源码 ID | 含义 | | --- | --- | --- | | category unknown | `category-unknown` | 无法归类的模型 | | response error | `response-error` | 响应过程中出现错误 | | no code | `response-no-code` | 响应中没有产生代码 | | invalid code | `code-invalid` | 生成的代码执行时报错 | | executable code | `code-executed` | 产生了可执行的代码 | | statement coverage reached | `code-coverage-statement` | 达到 100% 语句覆盖 | | no excess response | `code-no-excess` | 未产生超出请求的内容 | 分级判定由 `Assessments.Category(totalTasks)` 实现([category.go](https://link.gitcode.com/i/3a2074a152935636483366a540624d42) 第 79-98 行):它按“response-no-error → 有代码/文件可执行 → files-executed → coverage → response-no-excess”的顺序逐项检查,模型必须**在全部任务上一致地**达到某一级,才会被归入该级或更高级;返回的分类永远非 nil。分类条形图则由 [evaluate/report/markdown.go](https://link.gitcode.com/i/96cc345e71fae216193af728bd3e2ec9) 的 `barChartModelsPerCategoriesSVG` 用 go-chart 渲染成 SVG 并写入报告目录,即本目录中的 [categories.svg](https://link.gitcode.com/i/733594692279fa613ae97371cbc5488d)。 这份报告的结论是: > ### Result category "category unknown" > Models in this category could not be categorized. > - `openrouter/perplexity/llama-3-sonar-large-32k-chat` 即报告快照把该模型归入了“无法归类”一档。需要说明两点:其一,报告头部只打印了 `version 0.5.0` 而没有 revision,而当前仓库中的 markdown 模板会同时打印 `version` 与 `revision` 两个字段,说明该报告由早于当前源码修订的 v0.5.0 版本生成;其二,从当前仓库源码结构看,按 `Category()` 的顺序判定逻辑,该模型 `response-no-error` 与 `response-with-code` 均为 240/240,而 `files-executed` 只有 210/240,可以推断在当前版本的分类逻辑下,它会更可能落入 "invalid code" 分支而非 "category unknown"。因此,引用这份“category unknown”的结论时,应把它理解为“v0.5.0 该次运行快照下的归类结果”,其具体判定细节以报告生成时的工具版本为准。 ## 横向参照:该模型在 v0.5.0 总榜中的位置 v0.5.0 系列顶层的 [models-summed.csv](https://link.gitcode.com/i/e5d633256f4f109ff06e9976fce0bcd1) 汇总了全部 89 个参评模型的聚合结果。按 `score` 列降序,`llama-3-sonar-large-32k-chat` 的 17188 分位列第 7,其前为:deepseek-coder(19980)、claude-3-opus(19954)、claude-3.5-sonnet(19664)、gpt-4o(19236)、gpt-4(18198)、gemini-flash-1.5(17679);紧随其后的是 claude-3-sonnet(17104)。作为对照,同系列的较小模型 `llama-3-sonar-small-32k-chat` 得分 6658,coverage 6290,files-executed 仅 50。这些对比仅反映 v0.5.0 单次快照下的相对位次,不构成对模型能力的永久性定论。 ## 复现这份评测 框架 README([qwencoder-eval/instruct/eval-dev-quality/README.md](https://link.gitcode.com/i/4117936ed1c0851d364970bb9e73f206)) 给出了完整的安装与运行方式。该框架为 Go 实现,依赖 Git 与 Go 环境: ```bash go install -v github.com/symflower/eval-dev-quality/cmd/eval-dev-quality

评测需要模型访问凭证,以 OpenRouter 为例:

export PROVIDER_TOKEN=openrouter:${your-key}

只评测本文主角模型:

eval-dev-quality evaluate --model=openrouter/perplexity/llama-3-sonar-large-32k-chat

运行完成后,结果写入evaluation.csv等文件,与本文解析的文件形态一致;更细的选项(语言、仓库、运行时等)见eval-dev-quality evaluate --help。README 同时明确警告:默认不在沙箱中执行模型生成的代码,务必在隔离环境中运行(例如--runtime docker),不要在生产机器上直接执行评测产出的代码。

小结

这份单模型报告的信息量远超一行总分:它把一次 write-tests 基准运行拆解为“逐仓库明细(evaluation.csv)→ 按语言聚合 → 全量聚合(models-summed.csv)”三层数据,配合 category.go 的七级分类与 assessment.go 的指标注册,构成了一套可完全验算的评分口径。对llama-3-sonar-large-32k-chat而言,可验证的事实是:240 个任务全部无错误且都产出了代码,总分 17188 中覆盖率占 16340;短板在于 30 个文件的测试未能执行、Java 侧大量响应带有超出要求的多余内容;报告快照将其归入 "category unknown"。掌握了上述口径与复现步骤,你就可以用同一基准评测、比较任意其他模型。

【免费下载链接】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