wuyang
1389 lines
48 KiB
Markdown
1389 lines
48 KiB
Markdown
# 评测、安全与“到底强不强”：正式研究账本
|
||
|
||
> 状态：Chapter 15 首版证据核验完成，供正文、原创图与交互实验使用。
|
||
>
|
||
> 核验日期：2026-07-29
|
||
>
|
||
> 锚点：Kimi K3 §6、DeepSeek LLM §5、DeepSeekMath §5、DeepSeek-V2 §3.2 / §4.3、
|
||
> DeepSeek-V3 §4.4 / §5.3、DeepSeek-R1 Appendix D、DeepSeek-V3.2 §4、
|
||
> DeepSeek-V4 §4.3 / §5.3。
|
||
>
|
||
> 证据纪律：Grok 只做候选召回与教学问题生成；正文事实来自 P0 论文 / 技术报告或
|
||
> P1 作者官方实现。作者自报、第三方复跑、内部评测、教学推导与当前线上榜单必须分层标记。
|
||
|
||
---
|
||
|
||
## 0. 本章真正回答什么
|
||
|
||
“模型 A 在榜单上比模型 B 高 3 分”看起来是一句事实，实际压缩了至少十二个变量：
|
||
|
||
```text
|
||
observed score =
|
||
measure(
|
||
task distribution,
|
||
dataset version / split,
|
||
model checkpoint / product wrapper,
|
||
prompt / shots / chat template,
|
||
decoding / samples / seed,
|
||
reasoning and tool budget,
|
||
harness / tools / context policy,
|
||
environment / verifier version,
|
||
judge / rubric / annotator population,
|
||
aggregation / uncertainty / cost
|
||
)
|
||
```
|
||
|
||
所以本章不把“benchmark”理解为一张题单，而把它理解为一份**测量协议**。真正的问题有三个：
|
||
|
||
1. **构念效度**：我们想测“知识”“推理”“安全”，题目与指标真的测到了它吗？
|
||
2. **内部效度**：分数是否被污染、错误标签、Prompt、Harness、Judge 或样本预算劫持？
|
||
3. **外部效度**：实验室设置里的高分，能否迁移到真实用户、文化、工具和环境？
|
||
|
||
本章最终要训练的不是“背榜单”，而是拿到任意技术报告后，能独立重建它的评测协议、
|
||
识别不可比字段，并写出有限、可复核的结论。
|
||
|
||
---
|
||
|
||
## 1. 二十二张独立问题账
|
||
|
||
| # | 账本 | 本章要回答的问题 | 最常见误写 |
|
||
|---|---|---|---|
|
||
| Q1 | 构念 | 到底想测知识、推理、行动、偏好还是风险？ | 指标名就是能力本身 |
|
||
| Q2 | 测量单位 | token、题、回答、episode、任务还是完整系统？ | 不同单位直接平均 |
|
||
| Q3 | 任务分布 | 样本代表哪些用户、领域、语言、难度和时间？ | 测试集等于现实世界 |
|
||
| Q4 | 指标 | loss、accuracy、F1、win rate、resolved、Elo 各丢掉什么？ | 所有高分都同向可比 |
|
||
| Q5 | Prompt | shots、示例、CoT、模板、答案抽取是否一致？ | 同名 benchmark 自动同协议 |
|
||
| Q6 | 解码 | greedy、temperature、top-p、长度上限怎样进入分数？ | 解码只是实现细节 |
|
||
| Q7 | 重复采样 | pass@1、pass@k、cons@k、best-of-N、pass^k 测什么？ | k 只是脚注 |
|
||
| Q8 | Harness | system prompt、脚手架、工具和上下文管理贡献多少？ | Agent 分数全属于模型 |
|
||
| Q9 | 环境与版本 | 数据、容器、网站、依赖和 verifier 是哪个快照？ | 环境永远不变 |
|
||
| Q10 | 裁判 | exact match、单测、人类与 LLM Judge 谁在定义“好”？ | Judge 是透明测量仪 |
|
||
| Q11 | 聚合 | macro、micro、加权均值、子组与缺失项怎样处理？ | 一个总分没有价值判断 |
|
||
| Q12 | 不确定性 | 样本数、方差、置信区间与显著性是否足够？ | 0.1 分差就是确定排名 |
|
||
| Q13 | 污染 | 原文、答案、格式、语义与时间泄漏怎样区分？ | n-gram 无重合即无污染 |
|
||
| Q14 | 饱和与错误 | 分数高是能力强、题太易，还是标签有错？ | benchmark 永远有效 |
|
||
| Q15 | 动态性 | 怎样保持新鲜，同时保留跨时间可比性？ | 动态榜天然公平 |
|
||
| Q16 | 偏好与 Arena | 谁在投票、看见什么、被怎样匹配和排序？ | Elo 是绝对智力刻度 |
|
||
| Q17 | 成本 | 分数用了多少 token、工具调用、延迟与金钱？ | 准确率最高就是最优系统 |
|
||
| Q18 | 鲁棒与子群 | 换提示、语言、文化、长度或扰动后结论是否稳定？ | 平均数代表每个群体 |
|
||
| Q19 | 事实性 | 一篇长回答中，哪些原子事实被可靠来源支持？ | 流畅或自洽就是事实 |
|
||
| Q20 | 威胁模型 | 攻击者知道什么、能改什么、访问几次、目标是什么？ | Jailbreak 成功率可跨论文比较 |
|
||
| Q21 | 安全边界 | 不当服从与过度拒答如何同时测？ | 拒答越多越安全 |
|
||
| Q22 | 披露与审计 | 原始输出、配置、代码、版本与来源是否可复核？ | 一张表足够支持强结论 |
|
||
|
||
---
|
||
|
||
## 2. 七次历史转向：评测为什么越做越像系统工程
|
||
|
||
### 2.1 1948–2017：从概率拟合到任务代理指标
|
||
|
||
语言模型最早有一个自然的训练与评测对象：留出语料上的负对数似然。perplexity 把它指数化，
|
||
直觉上表示模型面对的平均分支数。但它有两条硬边界：
|
||
|
||
- 不同 tokenizer 的 token 单位不同，PPL 不可直接横比；
|
||
- 更会拟合文本分布不等于更会遵循指令、使用工具或避免伤害。
|
||
|
||
机器翻译与摘要随后用 BLEU、ROUGE 等参考重叠指标换取便宜、可重复的自动评测。
|
||
它们推动了大规模迭代，也把“和参考表面相似”误当成了“语义充分、事实正确、表达自然”的代理。
|
||
|
||
### 2.2 2018–2020：任务套件把“通用性”变成同表比较
|
||
|
||
GLUE、SuperGLUE、MMLU 把多个任务或学科汇成统一套件。贡献不是证明“智能是一个标量”，
|
||
而是让同一模型在更广分布上可比较。新的问题随之出现：
|
||
|
||
- 任务权重隐含价值判断；
|
||
- 多项选择可被格式、选项位置和 tokenization 影响；
|
||
- 平均分掩盖学科、语言与难度切片；
|
||
- 公开静态题会被训练生态吸收。
|
||
|
||
### 2.3 2021–2022：整体性、动态性与风险进入主流
|
||
|
||
Dynabench 用 human-and-model-in-the-loop 寻找模型当前会错的样本；BIG-bench 扩大任务覆盖；
|
||
HELM 明确要求在场景上同时看准确率、校准、鲁棒、公平、偏差、毒性和效率。
|
||
|
||
这一阶段最重要的观念变化是：
|
||
|
||
```text
|
||
evaluation ≠ one dataset + one metric
|
||
evaluation = scenario × adaptation × metric × reporting
|
||
```
|
||
|
||
### 2.4 2021–2024：代码与数学把“可验证结果”带回中心
|
||
|
||
HumanEval 用执行测试而非文字相似度判代码；DS-1000 增加真实数据科学问题与多条件检查；
|
||
EvalPlus 用自动生成与变异测试扩充测试覆盖；LiveCodeBench 用新竞赛题降低污染。
|
||
|
||
数学也从最终答案 exact match，走到程序化检查、专家题、形式化证明与工具环境。
|
||
可执行 verifier 比 LLM Judge 更硬，但仍受：
|
||
|
||
- 隐藏测试充分性；
|
||
- 题目规格是否明确；
|
||
- 运行环境；
|
||
- 超时与资源预算；
|
||
- 是否允许多次尝试；
|
||
|
||
影响。verifier 不是“天然真理”，而是更明确、可审计的判分程序。
|
||
|
||
### 2.5 2023–2024：开放回答把人类偏好与 LLM Judge 推上台
|
||
|
||
MT-Bench、Chatbot Arena、G-Eval、AlpacaEval、Arena-Hard 解决了开放回答没有唯一参考答案的问题，
|
||
同时引入位置、长度、自我偏好、Judge 能力和 rubrics 等新变量。
|
||
|
||
Length-Controlled AlpacaEval 的关键教学意义不是某个相关系数，而是证明：即使“更长”
|
||
这样可见的混杂变量，也足以改变自动偏好分；Judge 必须被元评测。
|
||
|
||
### 2.6 2023–2026：Agent 评测把模型升级为系统
|
||
|
||
SWE-bench、WebArena、AgentBench、OSWorld、τ-bench、BrowseComp 与 Terminal-Bench 把评测单位
|
||
从回答变成轨迹与最终状态。此时：
|
||
|
||
```text
|
||
system outcome =
|
||
model × harness × tool contract × environment
|
||
× context policy × retry / budget × verifier
|
||
```
|
||
|
||
2024 年 SWE-bench Verified 通过专业开发者复核，移除规格不明与测试不公平任务；
|
||
到 2026 年，OpenAI 又明确指出它已受污染并建议改用 SWE-bench Pro。
|
||
这是“基准有生命周期”的完整案例，不是某个榜单失败。
|
||
|
||
### 2.7 2020–2026：安全评测从静态毒性走向威胁模型与产品边界
|
||
|
||
RealToxicityPrompts、StereoSet、CrowS-Pairs、BBQ、ToxiGen 主要测内容、刻板印象和偏差；
|
||
红队、GCG、Jailbroken、HarmBench、StrongREJECT、JailbreakBench 开始测主动攻击与稳健拒答；
|
||
InjecAgent、AgentDojo、Cybench、Agent Security Bench 则把不可信数据、工具权限与真实行动放进环境。
|
||
|
||
AILuminate 的官方限制说明尤其重要：安全测试主要有**负向预测力**——发现失败可以证明存在漏洞，
|
||
没有发现失败却不能证明系统安全。
|
||
|
||
---
|
||
|
||
## 3. 指标不是分数皮肤：每个指标都定义了不同问题
|
||
|
||
### 3.1 Token 级：NLL、cross-entropy 与 perplexity
|
||
|
||
对 token 序列 `x_1 … x_T`：
|
||
|
||
```text
|
||
NLL = - Σ_t log p(x_t | x_<t)
|
||
cross-entropy = NLL / T
|
||
perplexity = exp(cross-entropy)
|
||
bits per byte = NLL / (ln 2 × #bytes)
|
||
```
|
||
|
||
PPL 低意味着模型对该 tokenization 下的测试分布分配了更高概率，不直接说明：
|
||
|
||
- 指令遵循；
|
||
- 长程规划；
|
||
- 事实性；
|
||
- 安全；
|
||
- 人类偏好。
|
||
|
||
PALOMA 为可比域级 LM 评测固定训练顺序、分层抽样、评测格式，并做 sub-document
|
||
decontamination；当 tokenizer 不同时使用 bits per byte。它说明“只报 PPL”之前需要先控制测量单位。
|
||
|
||
### 3.2 参考重叠：BLEU 与 ROUGE
|
||
|
||
- BLEU 聚合修正后的 n-gram precision，并用 brevity penalty 抑制过短翻译；
|
||
- ROUGE 家族主要看参考摘要与候选摘要的 recall-oriented 重叠。
|
||
|
||
它们适合快速、确定性回归，不足以独自回答语义充分、事实正确、风格恰当和多解有效。
|
||
正文必须把它们写成历史上重要的代理指标，而不是“过时所以毫无价值”。
|
||
|
||
### 3.3 分类与多项选择：accuracy / exact match
|
||
|
||
```text
|
||
accuracy = correct items / all items
|
||
```
|
||
|
||
看似最简单，却仍依赖：
|
||
|
||
- 是比较选项字母的 log-probability，还是生成答案再解析；
|
||
- 是否长度归一化；
|
||
- prompt 里是否有 few-shot；
|
||
- 选项顺序与答案 token；
|
||
- 错误标签、歧义与 multiple-valid-answer；
|
||
- 未回答、格式错误怎样计分。
|
||
|
||
MMLU-Redux 估计 MMLU 中有 `6.49%` 题目含错误，并重新标注 5,700 题；
|
||
这个作者报告结论只说明原始题集质量会影响排名，不可外推为所有学科同样错误。
|
||
|
||
### 3.4 代码与可验证任务：pass@k
|
||
|
||
HumanEval 对每题生成 `n` 个候选，其中 `c` 个通过测试。论文使用无偏估计：
|
||
|
||
```text
|
||
pass@k = 1 - C(n-c, k) / C(n, k)
|
||
```
|
||
|
||
它回答：
|
||
|
||
> 从 `n` 个样本里均匀抽 `k` 个，至少一个通过测试的概率是多少？
|
||
|
||
它不等于单次成功率，也不等于多数票。关键区分：
|
||
|
||
| 指标 | 问题 | 典型产品含义 |
|
||
|---|---|---|
|
||
| greedy / one-shot | 默认一次能否成功 | 日常单次使用 |
|
||
| mean pass@1 | 在给定采样分布下一次成功概率 | 随机一次尝试 |
|
||
| pass@k | k 次里至少一次成功 | 有 verifier 的搜索 |
|
||
| cons@k / maj@k | k 次多数答案是否正确 | 自一致投票 |
|
||
| best-of-N | Judge / reward 选出的最好答案 | 有选择器的系统 |
|
||
| pass^k | 连续 k 次全部成功的概率 | 可靠性要求 |
|
||
|
||
若独立单次成功率为 `p`：
|
||
|
||
```text
|
||
at-least-one success in k = 1 - (1-p)^k
|
||
all k runs succeed = p^k
|
||
```
|
||
|
||
二者方向相反。Agent 一次能成功 80%，连续 5 次都成功的教学独立近似只有 `0.8^5 ≈ 32.8%`。
|
||
真实运行未必独立，因此应报告经验重复分布，而不是只用公式。
|
||
|
||
### 3.5 开放回答：win rate 与 Elo
|
||
|
||
成对偏好把问题改成：
|
||
|
||
```text
|
||
P(answer A preferred over B | prompt, rater, presentation)
|
||
```
|
||
|
||
Arena 再用 Bradley–Terry 等统计模型把比较图映射成相对强度。于是排名取决于：
|
||
|
||
- 用户问题分布；
|
||
- 模型配对策略；
|
||
- 投票者与专家的一致性；
|
||
- ties 与 style bias；
|
||
- 时间窗口与模型版本；
|
||
- bootstrap / confidence interval；
|
||
- 分类榜与总榜。
|
||
|
||
Elo 差不是“智力点数”，也不应和 accuracy 的百分点相减。
|
||
|
||
### 3.6 Agent：任务成功率与最终状态
|
||
|
||
对可交互任务，优先验证：
|
||
|
||
1. 初始状态是否确定；
|
||
2. 动作权限是否相同；
|
||
3. 最终状态是否满足目标；
|
||
4. 禁止副作用是否发生；
|
||
5. 超时、重试、工具错误怎样计；
|
||
6. 环境与 verifier 是否可复现。
|
||
|
||
轨迹看起来合理不是成功；gold trajectory 也不应成为唯一正确路径。
|
||
|
||
### 3.7 安全：攻击成功率、拒答率与过拒率
|
||
|
||
至少同时记录：
|
||
|
||
```text
|
||
unsafe compliance rate
|
||
robust refusal rate
|
||
benign answer rate
|
||
over-refusal rate
|
||
attack cost / queries
|
||
utility of harmful information
|
||
```
|
||
|
||
只看拒答率会奖励“什么都不做”的系统；只看 helpfulness 会奖励危险服从。
|
||
StrongREJECT 进一步指出，有些 jailbreak 虽绕过拒绝，却让模型输出空洞、低能力内容；
|
||
因此“非拒绝”不等于有效有害输出。
|
||
|
||
---
|
||
|
||
## 4. 协议：Prompt、解码、预算和统计怎样进入成绩
|
||
|
||
### 4.1 Prompt 是评测输入的一部分
|
||
|
||
最小披露：
|
||
|
||
```text
|
||
system prompt
|
||
chat template
|
||
user prompt template
|
||
number and identity of shots
|
||
CoT / direct-answer instruction
|
||
answer format
|
||
post-processing / parser
|
||
```
|
||
|
||
DeepSeek LLM 的表格中，base model 的部分任务使用 few-shot，而 chat model 在 MMLU、
|
||
GSM8K、MATH、C-Eval、CMMLU 使用 0-shot。报告明确给出差异；读者不能把表内每个数字
|
||
理解为完全相同的 prompting。
|
||
|
||
DeepSeek-R1 又说明，原始 few-shot CoT 可能伤害 reasoning model，因此将若干任务改成 zero-shot。
|
||
这不是“作弊”或“更公平”的先验结论，而是协议适配；比较时必须披露。
|
||
|
||
### 4.2 解码不是无关紧要的尾部参数
|
||
|
||
必须记录：
|
||
|
||
- temperature；
|
||
- top-p / top-k；
|
||
- max output tokens；
|
||
- stop strings；
|
||
- samples per item；
|
||
- seed / deterministic mode；
|
||
- reasoning effort；
|
||
- timeout；
|
||
- early termination；
|
||
- invalid-output policy。
|
||
|
||
DeepSeek-R1 发现 greedy 评测长输出推理模型会出现较高重复率和 checkpoint 间变异，
|
||
因此用 `temperature=0.6`、`top-p=0.95` 采样多次，再以样本正确率均值报告 pass@1；
|
||
AIME 与 GPQA 用 64 个样本，MATH / Codeforces 用 16，LiveCodeBench 用 8。
|
||
这份“pass@1”不是一次 greedy 运行。
|
||
|
||
K3 则在其公开评测中把 reasoning effort 设为 max、temperature 设为 1.0；
|
||
无工具单步题使用 `top-p=.95`，Agent 任务使用 `top-p=1`。同名 benchmark 分数只有在这些协议字段
|
||
相同或做敏感性分析时才可强比较。
|
||
|
||
### 4.3 报点估计之前先问样本量
|
||
|
||
若 `n` 道独立二元题中正确比例为 `p̂`，教学近似标准误：
|
||
|
||
```text
|
||
SE ≈ sqrt(p̂(1-p̂) / n)
|
||
```
|
||
|
||
严格报告应使用合适的置信区间、bootstrap 或 paired test，并考虑：
|
||
|
||
- 同一题的多次采样相关；
|
||
- Arena 比较图不独立同分布；
|
||
- Agent 环境随机性；
|
||
- 多指标 / 多子组选择带来的多重比较；
|
||
- benchmark 提交次数与选择性报告。
|
||
|
||
一张表只标粗体第一名，却不给样本数和区间，不能支持“确定更强”的强结论。
|
||
|
||
### 4.4 校准回答“置信度能不能当概率”
|
||
|
||
对预测置信度 `q`，完美校准要求：
|
||
|
||
```text
|
||
P(correct | confidence = q) = q
|
||
```
|
||
|
||
准确率高不自动校准；校准好也不自动高准确率。常见工具：
|
||
|
||
- reliability diagram；
|
||
- expected calibration error；
|
||
- Brier score；
|
||
- selective risk / coverage curve；
|
||
- temperature scaling；
|
||
- semantic entropy；
|
||
- P(True) / P(IK)。
|
||
|
||
Kadavath et al. 在其任务和格式中发现较大模型能进行有希望的自评估，但 P(IK) 跨任务校准仍困难；
|
||
不能写成“模型普遍知道自己何时错误”。
|
||
|
||
Semantic uncertainty 把不同表述但同义的回答聚类后计算语义熵，解决 token 级多样性不等于
|
||
语义不确定性的问题；它依赖语义等价判断，仍需任务验证。
|
||
|
||
---
|
||
|
||
## 5. 数据：污染、饱和、错误与动态更新
|
||
|
||
### 5.1 五种污染必须分开
|
||
|
||
| 污染层 | 训练时可能看见什么 | 仅靠 exact n-gram 能否充分发现 |
|
||
|---|---|---|
|
||
| 原文污染 | 测试题或上下文原文 | 部分可以 |
|
||
| 答案污染 | 题目—答案配对、解析、测试代码 | 部分可以 |
|
||
| 格式污染 | 相同模板、选项顺序、verbalizer | 通常不充分 |
|
||
| 语义污染 | 改写题、同一事实或算法 | 通常不能 |
|
||
| 时间污染 | 发布后进入继续训练、SFT、RL、合成数据 | 需要时间与数据谱系 |
|
||
|
||
于是“没有高阶 n-gram 重合”只能是有限证据。DeepSeek-R1 明确承认 n-gram
|
||
decontamination 无法阻止测试集改写污染，这种披露应保留在正文。
|
||
|
||
### 5.2 污染检测也有混杂
|
||
|
||
训练语料中出现题目来源背景，不等于出现答案配对。GPT-3 报告对 SQuAD / DROP 等的分析就区分了
|
||
源文本与问题答案对；同时 PIQA、Winograd 出现值得标记的潜在污染。
|
||
|
||
干净子集与污染子集也可能难度分布不同，因此：
|
||
|
||
```text
|
||
score(clean subset) < score(dirty subset)
|
||
```
|
||
|
||
不能单独证明记忆导致提升。最好同时报告匹配定义、覆盖率、人工检查、效应量与不确定性。
|
||
|
||
### 5.3 题目质量与饱和是不同故障
|
||
|
||
- **标签错误 / 歧义**：正确系统也可能被判错；
|
||
- **饱和**：多数前沿模型已接近上限，无法区分；
|
||
- **范围过窄**：某一题型被优化，不代表目标构念；
|
||
- **难度失真**：只剩极端冷知识也可能偏离实际能力；
|
||
- **可博弈**：公开题与 parser 形成优化目标。
|
||
|
||
MMLU-Pro 通过增加推理题、从 4 选项扩到 10 选项并清理噪声提高区分度；
|
||
其作者在 24 种 prompt 上报告敏感度较 MMLU 更低。HLE 用专家原创、可自动判分的难题继续扩大前沿差距。
|
||
这些都是“修复当前测量”的尝试，不是永久最终考试。
|
||
|
||
### 5.4 动态 benchmark 的收益与代价
|
||
|
||
动态方法包括：
|
||
|
||
- human-and-model-in-the-loop 造难例；
|
||
- 从近期竞赛、论文、新闻或代码仓库抽题；
|
||
- 私有测试；
|
||
- 参数化生成任务；
|
||
- 定期刷新；
|
||
- 保留版本化 anchor set；
|
||
- 线上流量采样。
|
||
|
||
收益：
|
||
|
||
- 降低公开测试题被训练吸收的风险；
|
||
- 追踪最新世界知识与新型失败；
|
||
- 延长区分度。
|
||
|
||
代价：
|
||
|
||
- 不同月份题目难度不同；
|
||
- 旧模型重跑成本高；
|
||
- 私有题降低可解释性；
|
||
- 动态环境可能消失；
|
||
- 数据收集本身引入用户与地域偏差。
|
||
|
||
LiveBench 选择近期来源、客观自动判分并按月更新；FreshQA 定期更新快速变化知识与错误前提；
|
||
SWE-bench Live 从新 GitHub issue 生成可执行任务。正文必须同时讲版本化与 anchor 的需要。
|
||
|
||
---
|
||
|
||
## 6. 裁判：Verifier、人类与 LLM Judge 各自解决什么
|
||
|
||
### 6.1 不存在跨任务通用的“裁判强度全序”
|
||
|
||
可执行 verifier 在代码、数学和最终状态任务中通常更明确：
|
||
|
||
```text
|
||
exact parser
|
||
→ unit / property tests
|
||
→ independent implementation
|
||
→ formal proof checker
|
||
```
|
||
|
||
但文学风格、开放建议、同理心和复杂偏好没有现成程序真值，需要人类或模型辅助。
|
||
合理设计是按构念选裁判，并做元评测，而不是宣称某种裁判普遍最高级。
|
||
|
||
### 6.2 代码测试会漏错，也会错杀
|
||
|
||
EvalPlus 把 HumanEval 测试扩充约 80 倍，作者报告在 26 个模型上可捕获大量原测试未发现的错误，
|
||
并导致 pass@k 与模型排序变化。SWE-bench Verified 又通过人工检查发现：
|
||
|
||
- 问题描述可能规格不足；
|
||
- FAIL_TO_PASS 测试可能拒绝合理解；
|
||
- 任务环境可能不可执行。
|
||
|
||
所以“运行通过”只意味着通过当前 verifier，不自动等于满足完整用户意图。
|
||
|
||
### 6.3 人类评测需要定义人群与任务
|
||
|
||
最小设计：
|
||
|
||
- 谁是目标用户；
|
||
- 谁是标注者；
|
||
- 专业资格；
|
||
- 培训与校准；
|
||
- 单盲 / 双盲；
|
||
- 位置随机化；
|
||
- ties；
|
||
- rubric；
|
||
- 每项标注数；
|
||
- 一致性；
|
||
- 伦理与报酬；
|
||
- 分歧如何保留。
|
||
|
||
“人类偏好”不是单一客观真值；它是某组人在某种展示与 rubric 下的判断。
|
||
|
||
### 6.4 LLM-as-a-Judge 必须被当作模型
|
||
|
||
MT-Bench / Chatbot Arena 论文系统讨论：
|
||
|
||
- position bias；
|
||
- verbosity bias；
|
||
- self-enhancement bias；
|
||
- 数学与推理局限。
|
||
|
||
G-Eval 在摘要与对话任务的作者设置中提高了与人类的相关，但也指出偏好 LLM 生成文本的可能。
|
||
LLMBar 用 419 对“遵循指令 vs 具有迷惑风格”的回答测试 evaluator。
|
||
|
||
Judge 最小披露：
|
||
|
||
```text
|
||
judge model and dated version
|
||
judge system/user prompt
|
||
pair order / randomization
|
||
rubric and output parser
|
||
temperature / repetitions
|
||
reference access
|
||
human meta-evaluation
|
||
position / length / self-bias tests
|
||
```
|
||
|
||
### 6.5 Arena 需要不确定性与切片
|
||
|
||
总体 Arena 可能受：
|
||
|
||
- 英语与高频主题；
|
||
- 特定模型的用户群；
|
||
- 模型曝光量；
|
||
- 风格与长度；
|
||
- 新旧版本混合；
|
||
- 配对图稀疏；
|
||
|
||
影响。应尽量看：
|
||
|
||
- bootstrap interval；
|
||
- hard / style-controlled / category leaderboard；
|
||
- 票数与时间窗；
|
||
- exact model ID；
|
||
- 去重与异常投票策略。
|
||
|
||
K3 报告引用第三方 Arena 排名时给出日期与当时名次，这是正确方向；它仍是报告时点的外部平台结果，
|
||
不是固定模型常数。
|
||
|
||
---
|
||
|
||
## 7. 从文本到系统：代码、上下文、多模态与 Agent
|
||
|
||
### 7.1 代码评测的四级谱系
|
||
|
||
| 层级 | 例子 | 主要回答 | 主要盲区 |
|
||
|---|---|---|---|
|
||
| 函数补全 | HumanEval / MBPP | 小函数能否过测试 | 题短、测试不足、污染 |
|
||
| 真实库调用 | DS-1000 | 能否使用常见数据科学库 | 环境与 API 版本 |
|
||
| 动态竞赛 | LiveCodeBench | 新题算法、执行、修复 | 竞赛题不等于工程 |
|
||
| 仓库 / 终端 | SWE-bench / Terminal-Bench | 长程查找、编辑、运行与验证 | Harness、环境、预算 |
|
||
|
||
分数跨层级不能直接相减。K3 的 DeepSWE、ProgramBench、Terminal-Bench、
|
||
FrontierSWE、SWE-Marathon 是不同构念与系统协议。
|
||
|
||
### 7.2 长上下文：声明窗口不等于有效窗口
|
||
|
||
Needle-in-a-Haystack 主要测检索。RULER 增加多 needle、多跳 tracing 与聚合；
|
||
LongBench 覆盖双语多任务。仍需记录：
|
||
|
||
- 真实 token 数与 tokenizer；
|
||
- 重要信息位置；
|
||
- 是否截断；
|
||
- 上下文管理；
|
||
- 输出长度；
|
||
- 长度—难度曲线；
|
||
- 短上下文基线；
|
||
- 检索、推理和生成分别失败在哪里。
|
||
|
||
模型在 1M token 内找到一串 passkey，不证明它能综合 1M token 的矛盾证据。
|
||
|
||
### 7.3 多模态总分要拆成瓶颈链
|
||
|
||
```text
|
||
感知 / OCR
|
||
→ grounding
|
||
→ 跨模态融合
|
||
→ 知识 / 推理
|
||
→ 输出 / 操作
|
||
```
|
||
|
||
OCRBench、MMBench、MMMU、Video-MME 的任务与输入形态不同。对多模态题，至少披露：
|
||
|
||
- 原始图像尺寸与预处理；
|
||
- tile / crop；
|
||
- 图像数量与视频帧采样；
|
||
- OCR / tool；
|
||
- prompt；
|
||
- 是否允许重新观察；
|
||
- 文字与视觉子集；
|
||
- Judge；
|
||
- token / latency 成本。
|
||
|
||
### 7.4 Agent 的单位是“模型—脚手架—环境”
|
||
|
||
Agent 最小协议：
|
||
|
||
```text
|
||
model ID
|
||
system prompt
|
||
harness commit
|
||
tool schema and permissions
|
||
environment / image / date
|
||
context management
|
||
max steps / tokens / wall clock
|
||
retry / reset
|
||
parallel rollouts
|
||
verifier
|
||
cost
|
||
raw trajectory
|
||
```
|
||
|
||
Cybench 在顶级模型上比较 4 种 scaffold；OpenAI 对 SWE-bench Verified 的分析展示同一模型在不同
|
||
scaffold 上可产生很大差距。K3 在 DeepSWE、Terminal-Bench 等任务中使用不同模型专用 harness，
|
||
因此报告“best score across harnesses”必须和固定 harness 榜区分。
|
||
|
||
### 7.5 Final-state verifier 比轨迹模仿更适合多解任务
|
||
|
||
好的 Agent verifier 检查：
|
||
|
||
```text
|
||
required final state
|
||
forbidden side effects
|
||
permissions / authority
|
||
task invariants
|
||
external persistence
|
||
```
|
||
|
||
而不是要求和 gold trace 一步不差。OSWorld 用 task-specific execution scripts；
|
||
τ-bench 把 tool-agent-user interaction 与 policy constraints 放进任务；
|
||
AgentDojo 同时测正常任务与 prompt injection 下的安全性质。
|
||
|
||
---
|
||
|
||
## 8. 安全评测：先画威胁模型，再看分数
|
||
|
||
### 8.1 三类对象不能混为一谈
|
||
|
||
| 对象 | 例子 | 问题 |
|
||
|---|---|---|
|
||
| 裸模型能力 | checkpoint 能生成什么 | 是否拥有危险能力 |
|
||
| 行为对齐 | 面对请求会不会拒绝或安全响应 | 模型策略是否稳健 |
|
||
| 产品系统 | system prompt、过滤器、工具权限、审计与速率限制 | 部署风险是否被控制 |
|
||
|
||
同一 checkpoint 加风控 wrapper 后安全榜可能显著变化。DeepSeek-R1 Appendix D 同时给出
|
||
纯模型与风险控制系统结果，正好说明产品安全不能归给模型单层。
|
||
|
||
### 8.2 威胁模型最小字段
|
||
|
||
```text
|
||
attacker goal
|
||
attacker knowledge
|
||
attacker access
|
||
query / compute budget
|
||
allowed transformations
|
||
target model / wrapper
|
||
conversation length
|
||
tool permissions
|
||
success criterion
|
||
evaluator
|
||
attack artifacts disclosed?
|
||
```
|
||
|
||
没有这些字段的 attack success rate 不可跨论文直接比较。
|
||
|
||
### 8.3 从静态内容到主动攻击
|
||
|
||
谱系：
|
||
|
||
1. **内容分布**：RealToxicityPrompts；
|
||
2. **刻板印象 / 偏差**：StereoSet、CrowS-Pairs、BBQ；
|
||
3. **对抗数据生成**：ToxiGen；
|
||
4. **人工 / 模型红队**：Perez et al.、Ganguli et al.；
|
||
5. **自动 jailbreak**：GCG、Jailbroken；
|
||
6. **标准化拒答与攻击**：HarmBench、JailbreakBench；
|
||
7. **有效有害内容**：StrongREJECT；
|
||
8. **不可信工具数据**：InjecAgent、AgentDojo；
|
||
9. **网络安全能力**：Cybench；
|
||
10. **行业标准化套件**：AILuminate。
|
||
|
||
这不是单向“越来越安全”，而是被测攻击面不断扩大。
|
||
|
||
### 8.4 红队发现取决于资源与参与者
|
||
|
||
Red-Teaming for Generative AI 将活动拆成：
|
||
|
||
- 目的；
|
||
- 产物；
|
||
- 参与者；
|
||
- 访问权；
|
||
- 时间与计算资源；
|
||
- 决策去向。
|
||
|
||
短时 crowdworker、领域专家、内部员工与自动攻击器能发现的风险不同。
|
||
“做过红队”若没有过程披露，容易退化为 security theater。
|
||
|
||
### 8.5 Jailbreak 不能只看是否拒答
|
||
|
||
评测至少分三步：
|
||
|
||
```text
|
||
did the model refuse?
|
||
did it provide policy-violating content?
|
||
was the content specific / useful enough to realize harm?
|
||
```
|
||
|
||
StrongREJECT 的实证结论是既有自动评估可能显著高估 jailbreak 效果；
|
||
JailbreakBench 则固定 threat model、system prompt、chat template、100 个 behaviors、
|
||
scoring 与 artifact repository，使攻击成本与成功率更可比。
|
||
|
||
### 8.6 过度拒答是安全失败的一部分
|
||
|
||
XSTest 同时有：
|
||
|
||
- 250 个含敏感词但安全的 prompts；
|
||
- 200 个应拒绝的对照 prompts。
|
||
|
||
安全前沿应画成二维：
|
||
|
||
```text
|
||
unsafe compliance ↓
|
||
benign task completion ↑
|
||
```
|
||
|
||
一个模型把所有安全问题都拒绝，不应被评为“最安全且最好用”。
|
||
|
||
### 8.7 Prompt injection 是权限与数据流问题
|
||
|
||
InjecAgent 的 1,054 个案例覆盖 17 个用户工具、62 个攻击者工具，目标包括直接伤害与数据外泄；
|
||
AgentDojo 用可扩展环境同时测正常任务、攻击与防御。
|
||
|
||
核心不只是“模型有没有被一句话骗过”，而是：
|
||
|
||
```text
|
||
trusted instruction
|
||
untrusted observation / document / email
|
||
tool authority
|
||
side effect
|
||
secret
|
||
```
|
||
|
||
是否被明确分层。Instruction Hierarchy 把 system > user > tool/data 的权限优先级变成训练与评测对象。
|
||
|
||
### 8.8 网络安全能力与风险必须分层
|
||
|
||
Cybench 用 40 个专业 CTF 任务、可执行环境与中间子任务测 Agent；K3 报告内部 cybersecurity
|
||
又区分 discovery、PoC 与 end-to-end exploit tier。报告“发现漏洞”不能自动升级成
|
||
“能可靠完成真实端到端攻击”，反之低 CTF 成绩也不证明没有现实风险。
|
||
|
||
---
|
||
|
||
## 9. DeepSeek 评测谱系：为什么特别值得亮点讲
|
||
|
||
DeepSeek 系列不是只有模型结构演进；它的评测协议也逐步从静态能力表，走到多预算推理、
|
||
Agent harness、形式 verifier 与产品风控。以下只总结报告披露，不把作者结论外推。
|
||
|
||
### 9.1 DeepSeek LLM（2024）：第一次把四类评测并排
|
||
|
||
报告同时包含：
|
||
|
||
- public benchmark；
|
||
- Chinese / English open-ended evaluation；
|
||
- held-out evaluation；
|
||
- safety evaluation；
|
||
- 训练过程 benchmark curves；
|
||
- 评测格式附录。
|
||
|
||
值得教学的细节：
|
||
|
||
- base 与 chat 的 shots 并不完全一致；
|
||
- open-ended 任务温度按任务类型变化；
|
||
- held-out code 与 instruction-following 用于补公开题；
|
||
- 报告承认多项选择数据可能进入训练，并对部分集做 dedup。
|
||
|
||
错误写法：把表中全部差距归因于模型结构，忽略 base / chat 协议差异与后训练。
|
||
|
||
### 9.2 DeepSeekMath（2024）：Maj@K 上升不等于 Pass@K 上升
|
||
|
||
DeepSeekMath 报告 RL 后：
|
||
|
||
- majority / self-consistency 变好；
|
||
- Pass@K 未同步改善。
|
||
|
||
作者谨慎解释为正确答案在分布中的排序与稳定性提高，而不是已经证明基础解题支持集扩大。
|
||
这是区分“推理能力”“采样分布”“选择器收益”的经典案例。
|
||
|
||
### 9.3 DeepSeek-V2（2024）：架构、开放生成与长上下文同表出现
|
||
|
||
报告覆盖：
|
||
|
||
- MMLU / C-Eval / CMMLU；
|
||
- HumanEval / MBPP / LiveCodeBench；
|
||
- MT-Bench / AlpacaEval 2.0；
|
||
- NIAH；
|
||
- base / chat / DPO；
|
||
- 额外 math / code 分析。
|
||
|
||
NIAH 高分只支持检索式长上下文证据，不能单独证明复杂综合。
|
||
|
||
### 9.4 DeepSeek-V3（2024）：更明确的框架与新一代题集
|
||
|
||
V3：
|
||
|
||
- base 使用内部 HAI-LLM evaluation framework；
|
||
- 增加 MMLU-Redux、MMLU-Pro、MMMLU、GPQA、LiveCodeBench、SWE-bench Verified；
|
||
- open-ended 继续用 AlpacaEval / Arena-Hard；
|
||
- 长上下文仍包括 NIAH；
|
||
- tokenizer 的换行复合 token 可能影响 few-shot 边界，报告专门讨论并在训练中缓解。
|
||
|
||
这个 tokenizer 细节说明：评测 prompt 的最后一个换行也可能成为协议变量。
|
||
|
||
### 9.5 DeepSeek-R1（2025）：采样、污染、Harness 与安全 wrapper 全部显性化
|
||
|
||
最重要的四点：
|
||
|
||
1. 用非零温度多次采样计算 mean pass@1，不是 greedy；
|
||
2. 不同 benchmark 使用不同 `k`，AIME 另报 cons@64；
|
||
3. SWE-bench Verified 使用 Agentless，Aider 使用 diff format；
|
||
4. 安全结果区分纯模型与风险控制系统。
|
||
|
||
污染部分还明确承认 n-gram 无法拦截 paraphrase contamination。
|
||
|
||
R1 安全附录使用 SST、BBQ、Anthropic Red Team、XSTest、Do-Not-Answer、HarmBench；
|
||
部分来自 HELM，部分作者复现；HarmBench Judge 被替换为 GPT-4o，且被产品风险控制拒绝的请求统一按安全响应。
|
||
这些字段会改变分数，必须逐项保留。
|
||
|
||
### 9.6 DeepSeek-V3.2（2025）：Agent 与 token efficiency 成为一等字段
|
||
|
||
V3.2 评测覆盖知识、数学代码竞赛、Terminal-Bench、SWE、BrowseComp、MCP 等；
|
||
报告给出：
|
||
|
||
- temperature 与 128K context；
|
||
- thinking / non-thinking；
|
||
- 工具设置；
|
||
- Agent 任务；
|
||
- performance / token consumption 图；
|
||
- 特定竞赛的提交与验证流程。
|
||
|
||
这一步把“同分用了多少 token”带进模型比较。
|
||
|
||
### 9.7 DeepSeek-V4（2026）：多 effort、超长上下文与 500 步 Agent
|
||
|
||
V4 披露：
|
||
|
||
- Non-think / High / Max；
|
||
- reasoning / knowledge 分别使用 8K、128K、384K context；
|
||
- formal math 在 Lean v4.28.0-rc1 中最多 500 tool calls；
|
||
- code Agent 使用内部 bash + file-edit harness，最多 500 步、512K context；
|
||
- search Agent 使用 websearch + Python，同样 500 步 / 512K；
|
||
- 1M context 对竞争模型重跑以统一配置；
|
||
- Codeforces 每题生成 32 候选，再随机抽 10 形成提交序列并求期望 rating；
|
||
- strict verifier 决定 formal proof 正确性。
|
||
|
||
因此 V4 表格是“高预算系统设置下的作者评测”，不是裸模型在默认 API 下的无条件属性。
|
||
|
||
### 9.8 DeepSeek 主线的教学结论
|
||
|
||
```text
|
||
DeepSeek LLM
|
||
public / open / held-out / safety
|
||
↓
|
||
DeepSeekMath
|
||
pass@k vs maj@k
|
||
↓
|
||
V2 / V3
|
||
newer suites + open judge + long context
|
||
↓
|
||
R1
|
||
sampled pass@1 + harness + wrapper-aware safety
|
||
↓
|
||
V3.2 / V4
|
||
effort / token / tools / environment / formal verifier
|
||
```
|
||
|
||
这条谱系比背模型分数更重要：越接近 Agent，协议字段越多，单一“模型榜”越不充分。
|
||
|
||
---
|
||
|
||
## 10. Kimi K3 §6：把一张大表重新展开成协议
|
||
|
||
### 10.1 公共评测分四层
|
||
|
||
K3 §6.1 把任务分为：
|
||
|
||
- Reasoning & Knowledge；
|
||
- Coding；
|
||
- Agentic；
|
||
- Vision / multimodal。
|
||
|
||
其中可见节点包括 GPQA Diamond、CritPt、AA-LCR、HLE-Full、DeepSWE、ProgramBench、
|
||
Terminal-Bench 2.1、FrontierSWE、SWE-Marathon、BrowseComp、DeepSearchQA、
|
||
ResearchRubrics、Toolathlon-Verified、MCPMark-Verified、OSWorld-Verified、OSWorld 2.0、
|
||
SaaS-Bench、τ³-Banking 等。
|
||
|
||
任务名字很多，但真正可比较性来自下面的协议。
|
||
|
||
### 10.2 公开设置
|
||
|
||
报告披露：
|
||
|
||
- K3 reasoning effort 为 max；
|
||
- temperature = 1.0；
|
||
- GPQA / HLE / vision 等无工具单步评测 `top-p=.95`；
|
||
- Agent 任务 `top-p=1`；
|
||
- 一般按模型使用 Kimi Code / Claude Code / Codex 等模型专用 harness；
|
||
- DeepSWE 使用 v1.1；
|
||
- K3 在官方 mini-SWE-agent harness 另有 `67.3`，主表是另一协议；
|
||
- Terminal-Bench 2.1 对所有模型报告各 harness 的最好分；
|
||
- SWE-Marathon 使用截至报告时点的 H20-calibrated task branch；
|
||
- FrontierSWE dominance 用 2026-07-16 官方脚本重算；
|
||
- 部分任务用 Gemini 3.1 Pro Judge；
|
||
- AutomationBench 使用 600 题公开子集；
|
||
- BrowseComp 使用特定上下文管理策略。
|
||
|
||
这组披露直接支持本章总公式：
|
||
|
||
```text
|
||
reported benchmark score
|
||
= model + effort + sampling + harness + environment
|
||
+ context management + verifier / judge + date
|
||
```
|
||
|
||
### 10.3 作者报告值只能在协议边界内读
|
||
|
||
可作为案例、但不可外推的主表值包括：
|
||
|
||
- GPQA Diamond：93.5；
|
||
- HLE-Full：无工具 43.5 / 有工具 56.0；
|
||
- DeepSWE：67.5；
|
||
- FrontierSWE：81.2；
|
||
- SWE-Marathon：42.0；
|
||
- BrowseComp：91.2；
|
||
- OSWorld-Verified：84.8；
|
||
- OSWorld 2.0：58.3。
|
||
|
||
安全写法：
|
||
|
||
> K3 报告在其 §6 所述 max-effort、采样、Harness、工具与版本配置下报告这些结果。
|
||
|
||
错误写法：
|
||
|
||
> K3 的裸模型能力就是这些固定百分比，且可与任意来源同名 benchmark 直接比较。
|
||
|
||
### 10.4 内部评测
|
||
|
||
K3 §6.2 明确说明内部 benchmark 会频繁刷新和扩展，以追踪不断变化的 failure modes；
|
||
覆盖 capability、coding、enterprise、conversation 等。
|
||
|
||
优点：
|
||
|
||
- 能测未公开、未污染的新失败；
|
||
- 可贴近产品分布；
|
||
- 可快速迭代。
|
||
|
||
边界：
|
||
|
||
- 外部无法复现；
|
||
- 题目选择与 Judge 不透明；
|
||
- 跨时间分数未必同量尺；
|
||
- 应报告版本、覆盖、抽样和人工审计。
|
||
|
||
### 10.5 网络安全 Tier
|
||
|
||
K3 内部 cybersecurity 分层：
|
||
|
||
- discovery；
|
||
- PoC / Tier 1；
|
||
- end-to-end exploit / Tier 2。
|
||
|
||
这避免把“指出潜在漏洞”与“稳定端到端利用”混写。
|
||
|
||
### 10.6 第三方评测
|
||
|
||
K3 §6.3 披露 WebDev Arena、Text Arena、Agent Arena 等第三方时点排名；
|
||
成本—分数图的 K3 成本来自自有运行，Claude / GPT 成本取自引用来源；
|
||
baseline 分数也可能来自各自来源、各自设置。
|
||
|
||
因此“成本更低且分数更高”的图要逐点审计：
|
||
|
||
- 价格日期；
|
||
- input / output token；
|
||
- cached token；
|
||
- 平均长度；
|
||
- reasoning effort；
|
||
- tool cost；
|
||
- harness；
|
||
- 是否作者自跑；
|
||
- SLO。
|
||
|
||
### 10.7 K3 主线的教学结论
|
||
|
||
K3 §6 的价值不只是分数高，而是提供了一个真实的前沿评测“混合证据现场”：
|
||
|
||
```text
|
||
作者自跑
|
||
+ 官方 leaderboard
|
||
+ 第三方平台
|
||
+ 内部动态集
|
||
+ 不同 harness
|
||
+ LLM Judge
|
||
+ 成本引用
|
||
```
|
||
|
||
学生的任务是给每个数字贴 provenance，而不是把整张表当成同一实验。
|
||
|
||
本地证据：
|
||
|
||
- `research/sources/kimi-k3/k3_tech_report.txt:1687-1750`
|
||
- `research/sources/kimi-k3/k3_tech_report.txt:1751-1845`
|
||
- `research/sources/kimi-k3/k3_tech_report.txt:1850-1965`
|
||
|
||
---
|
||
|
||
## 11. 四个原创交互实验的教学合同
|
||
|
||
### Lab A：指标与校准显微镜
|
||
|
||
用户可调：
|
||
|
||
- tokenizer 粒度；
|
||
- 正确率；
|
||
- 置信度；
|
||
- selective threshold；
|
||
- 风险代价。
|
||
|
||
输出：
|
||
|
||
- PPL / bits-per-byte 的不可比示例；
|
||
- reliability bins；
|
||
- ECE 教学近似；
|
||
- coverage / selective accuracy；
|
||
- “高准确但过度自信”与“较低准确但可弃答”的区别。
|
||
|
||
必须标注：所有数字为教学模拟，不对应真实模型。
|
||
|
||
### Lab B：Judge 与 Arena 偏差实验
|
||
|
||
用户可调：
|
||
|
||
- A/B 顺序；
|
||
- 长度差；
|
||
- style；
|
||
- Judge 能力；
|
||
- self-family bias；
|
||
- 票数；
|
||
- ties。
|
||
|
||
输出：
|
||
|
||
- pairwise preference；
|
||
- position flip；
|
||
- length-adjusted preference；
|
||
- bootstrap 区间教学近似；
|
||
- 稀疏比较图如何导致排名不稳。
|
||
|
||
### Lab C：污染与动态基准实验
|
||
|
||
用户可调：
|
||
|
||
- 文本 / 答案 / 格式 / 语义 / 时间污染；
|
||
- n-gram threshold；
|
||
- 私有 holdout；
|
||
- 动态刷新比例；
|
||
- anchor set。
|
||
|
||
输出：
|
||
|
||
- 可检测污染；
|
||
- 漏检污染；
|
||
- 静态可比性；
|
||
- 新鲜度；
|
||
- benchmark 半衰期；
|
||
- 结论标签。
|
||
|
||
### Lab D：系统分数与安全前沿
|
||
|
||
用户可调：
|
||
|
||
- base model capability；
|
||
- harness boost；
|
||
- tool / retry budget；
|
||
- verifier strength；
|
||
- environment noise；
|
||
- jailbreak pressure；
|
||
- risk-control wrapper；
|
||
- benign refusal。
|
||
|
||
输出：
|
||
|
||
- raw capability；
|
||
- system success；
|
||
- repeatability；
|
||
- cost；
|
||
- unsafe compliance；
|
||
- over-refusal；
|
||
- “能力榜 / 系统榜 / 安全榜不能合并”。
|
||
|
||
---
|
||
|
||
## 12. 一份可复制的评测审计卡
|
||
|
||
### 12.1 构念
|
||
|
||
- [ ] 要测的能力 / 风险用一句可证伪的话定义；
|
||
- [ ] 题目与真实使用之间的差异列出；
|
||
- [ ] 不测什么明确写出。
|
||
|
||
### 12.2 数据
|
||
|
||
- [ ] dataset 名称、版本、commit、split、日期；
|
||
- [ ] 语言、领域、难度、用户群；
|
||
- [ ] 标签质量与多解；
|
||
- [ ] 污染定义、匹配阈值与人工检查；
|
||
- [ ] 动态题与 anchor 题比例。
|
||
|
||
### 12.3 模型与产品
|
||
|
||
- [ ] exact model ID / checkpoint / date；
|
||
- [ ] base、chat、reasoner；
|
||
- [ ] 裸模型还是产品 wrapper；
|
||
- [ ] system prompt、过滤器与风险控制。
|
||
|
||
### 12.4 推理协议
|
||
|
||
- [ ] prompt / chat template / shots；
|
||
- [ ] temperature / top-p / seed；
|
||
- [ ] max tokens / context；
|
||
- [ ] samples / pass@k / consensus；
|
||
- [ ] reasoning effort；
|
||
- [ ] invalid output / timeout policy。
|
||
|
||
### 12.5 Agent 协议
|
||
|
||
- [ ] harness 与 commit；
|
||
- [ ] tools、权限与 schema；
|
||
- [ ] environment image / date；
|
||
- [ ] context management；
|
||
- [ ] steps / wall-clock / retries；
|
||
- [ ] verifier 与 side effects。
|
||
|
||
### 12.6 Judge 与统计
|
||
|
||
- [ ] exact match / test / human / LLM Judge；
|
||
- [ ] Judge prompt / model / parser；
|
||
- [ ] position / length sensitivity；
|
||
- [ ] sample size；
|
||
- [ ] confidence interval / paired test；
|
||
- [ ] macro / micro / missing values。
|
||
|
||
### 12.7 经济与来源
|
||
|
||
- [ ] input / output / cached tokens；
|
||
- [ ] tool calls / rollouts；
|
||
- [ ] latency / price / hardware；
|
||
- [ ] author-reported / official leaderboard / independent rerun；
|
||
- [ ] raw outputs / logs / config 是否开放。
|
||
|
||
---
|
||
|
||
## 13. 五十个新增一手节点
|
||
|
||
下表是论文库从 400 扩充到 450 的新增节点。每项只写最小可支持贡献。
|
||
|
||
| 年 | 节点 | 本章使用方式 |
|
||
|---|---|---|
|
||
| 2002 | BLEU | 自动参考重叠指标的历史起点与代理边界 |
|
||
| 2004 | ROUGE | 摘要 recall-oriented 参考重叠 |
|
||
| 2017 | On Calibration of Modern Neural Networks | reliability、ECE 与 temperature scaling 坐标 |
|
||
| 2018 | GLUE | 多任务统一套件 |
|
||
| 2019 | SuperGLUE | 基准饱和后的加难与诊断 |
|
||
| 2020 | RealToxicityPrompts | 语言模型生成毒性的分布式测量 |
|
||
| 2020 | StereoSet | 语言模型刻板印象与语言建模能力权衡 |
|
||
| 2020 | CrowS-Pairs | 美国语境九类社会偏差的成对测量 |
|
||
| 2021 | HumanEval | 执行测试与 pass@k |
|
||
| 2021 | TruthfulQA | 模仿人类错误信念的对抗式事实性 |
|
||
| 2021 | Dynabench | human-and-model-in-the-loop 动态造题 |
|
||
| 2021 | BBQ | 有信息 / 信息不足条件下的 QA 偏差 |
|
||
| 2022 | Language Models (Mostly) Know What They Know | P(True) / P(IK) 自评与校准 |
|
||
| 2022 | ToxiGen | 对抗式、隐性仇恨数据生成 |
|
||
| 2022 | Red Teaming Language Models with Language Models | 用模型自动产生红队测试 |
|
||
| 2022 | Red Teaming Language Models to Reduce Harms | 红队流程、规模与 38,961 攻击数据 |
|
||
| 2022 | BIG-Bench Hard | 从 BIG-bench 选出困难任务并研究 CoT |
|
||
| 2022 | DS-1000 | 真实数据科学代码与多条件执行检查 |
|
||
| 2023 | MT-Bench / Chatbot Arena | LLM Judge 与现场人类成对偏好 |
|
||
| 2023 | G-Eval | rubric + CoT + form filling 的生成评测 |
|
||
| 2023 | LLMBar | 419 对迷惑性 instruction-following 元评测 |
|
||
| 2023 | EvalPlus | 扩充测试揭示 false positive 与误排序 |
|
||
| 2023 | FActScore | 长文拆成原子事实后核验支持率 |
|
||
| 2023 | SelfCheckGPT | 黑盒多样本一致性检测事实性 |
|
||
| 2023 | HaluEval | 生成并人工标注的幻觉识别集 |
|
||
| 2023 | Universal Adversarial Suffix / GCG | 自动梯度式 jailbreak 与迁移 |
|
||
| 2023 | Jailbroken | 竞争目标与泛化失配的安全失败框架 |
|
||
| 2023 | XSTest | 不当服从与过度拒答双向测量 |
|
||
| 2023 | Do-Not-Answer | 危险指令 safeguard 数据集 |
|
||
| 2023 | FreshLLMs / FreshQA | 快速变化知识与错误前提的动态 QA |
|
||
| 2023 | Semantic Uncertainty | 按语义等价类计算生成不确定性 |
|
||
| 2024 | Chatbot Arena | 众包成对比较与统计排名平台 |
|
||
| 2024 | Length-Controlled AlpacaEval | 控制长度混杂的自动偏好评测 |
|
||
| 2024 | Arena-Hard / BenchBuilder | 从现场流量构建区分性开放题 |
|
||
| 2024 | LiveBench | 近期来源、客观判分、按月更新 |
|
||
| 2024 | LiveCodeBench | 持续收集新竞赛题与多种代码能力 |
|
||
| 2024 | RULER | 超越单 needle 的长上下文诊断 |
|
||
| 2024 | HarmBench | 标准化自动红队与稳健拒答 |
|
||
| 2024 | StrongREJECT | 有害信息效用而非非拒答本身 |
|
||
| 2024 | JailbreakBench | threat model、artifact、behavior、scoring 标准化 |
|
||
| 2024 | InjecAgent | 工具 Agent 的间接 prompt injection |
|
||
| 2024 | Cybench | 可执行 CTF 环境、子任务与 scaffold 敏感性 |
|
||
| 2024 | Instruction Hierarchy | privileged instruction 的训练与评测 |
|
||
| 2024 | Global MMLU | 翻译与文化偏差导致模型排名变化 |
|
||
| 2024 | FrontierMath | 专家原创难题与自动验证 |
|
||
| 2024 | WildGuard | prompt、response 与 refusal 三项安全 moderation |
|
||
| 2024 | MMLU-Pro | 更难、更多选项、较低 prompt 敏感性 |
|
||
| 2024 | MMLU-Redux | MMLU 错误审计与人工重标 |
|
||
| 2025 | AILuminate | 12 类风险、标准与行业化安全套件 |
|
||
| 2025 | SWE-bench Live | 新 GitHub issue 驱动的动态可执行软件工程评测 |
|
||
|
||
---
|
||
|
||
## 14. 八十节点正式阅读链
|
||
|
||
页面阅读链由上述 50 个新增节点，加上 30 个项目已有节点组成：
|
||
|
||
1. Perplexity；
|
||
2. MMLU；
|
||
3. BIG-bench；
|
||
4. HELM；
|
||
5. PALOMA；
|
||
6. benchmark contamination investigation；
|
||
7. LongBench；
|
||
8. GPQA；
|
||
9. Humanity’s Last Exam；
|
||
10. RewardBench；
|
||
11. AgentBench；
|
||
12. SWE-bench；
|
||
13. OSWorld；
|
||
14. τ-bench；
|
||
15. BrowseComp；
|
||
16. AgentDojo；
|
||
17. Agent Security Bench；
|
||
18. OCRBench；
|
||
19. MMBench；
|
||
20. MMMU；
|
||
21. Video-MME；
|
||
22. DeepSeek LLM；
|
||
23. DeepSeekMath；
|
||
24. DeepSeek-V2；
|
||
25. DeepSeek-V3；
|
||
26. DeepSeek-R1；
|
||
27. DeepSeek-V3.2；
|
||
28. DeepSeek-V4；
|
||
29. Kimi k1.5；
|
||
30. Kimi K3。
|
||
|
||
顺序按章节叙事重新编排，不按“重要性”排序。
|
||
|
||
---
|
||
|
||
## 15. 事实边界表
|
||
|
||
| 可以写 | 不能写 |
|
||
|---|---|
|
||
| 作者在其设置下报告 X | X 是模型永恒、内在、跨协议的能力 |
|
||
| 自动 Judge 在该元评测中与人类相关 | LLM Judge 等同人类 |
|
||
| n-gram 方法未发现某类文本重合 | 数据绝无污染 |
|
||
| verifier 接受该输出 | 输出满足未编码的全部用户意图 |
|
||
| 安全 benchmark 未发现所覆盖的失败 | 系统安全 |
|
||
| wrapper 降低作者测试中的 unsafe response | 裸模型本身同样安全 |
|
||
| pass@k 随 k 增加 | 单次成功率提升 |
|
||
| cons@k 提升 | 解题支持集必然扩大 |
|
||
| Agent 在某 harness 成功 | 任意脚手架和环境都同样成功 |
|
||
| Arena 在某时间窗排名靠前 | 绝对、永久、全用户偏好更高 |
|
||
| 动态 benchmark 降低已知公开题污染 | 动态题无偏且永久可比 |
|
||
| K3 / DeepSeek 表格披露了协议 | 表内外所有 baseline 都被完全统一重跑 |
|
||
|
||
---
|
||
|
||
## 16. P0 / P1 来源入口
|
||
|
||
### 测量与基准
|
||
|
||
- BLEU — https://aclanthology.org/P02-1040/
|
||
- ROUGE — https://aclanthology.org/W04-1013/
|
||
- Calibration — https://proceedings.mlr.press/v70/guo17a.html
|
||
- GLUE — https://arxiv.org/abs/1804.07461
|
||
- SuperGLUE — https://arxiv.org/abs/1905.00537
|
||
- MMLU — https://arxiv.org/abs/2009.03300
|
||
- BIG-bench — https://arxiv.org/abs/2206.04615
|
||
- HELM — https://arxiv.org/abs/2211.09110
|
||
- PALOMA — https://arxiv.org/abs/2312.10523
|
||
- MMLU-Redux — https://arxiv.org/abs/2406.04127
|
||
- MMLU-Pro — https://arxiv.org/abs/2406.01574
|
||
- HLE — https://arxiv.org/abs/2501.14249
|
||
|
||
### 动态、代码与 Agent
|
||
|
||
- Dynabench — https://arxiv.org/abs/2104.14337
|
||
- HumanEval — https://arxiv.org/abs/2107.03374
|
||
- DS-1000 — https://arxiv.org/abs/2211.11501
|
||
- EvalPlus — https://arxiv.org/abs/2305.01210
|
||
- LiveCodeBench — https://arxiv.org/abs/2403.07974
|
||
- LiveBench — https://arxiv.org/abs/2406.19314
|
||
- SWE-bench — https://arxiv.org/abs/2310.06770
|
||
- SWE-bench Verified — https://openai.com/index/introducing-swe-bench-verified/
|
||
- SWE-bench Live — https://arxiv.org/abs/2505.23419
|
||
- SWE-bench Verified deprecation analysis — https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
|
||
- RULER — https://arxiv.org/abs/2404.06654
|
||
- OSWorld — https://arxiv.org/abs/2404.07972
|
||
- AgentDojo — https://arxiv.org/abs/2406.13352
|
||
- Cybench — https://arxiv.org/abs/2408.08926
|
||
|
||
### Judge、事实性与校准
|
||
|
||
- Language Models (Mostly) Know — https://arxiv.org/abs/2207.05221
|
||
- Semantic Uncertainty — https://arxiv.org/abs/2302.09664
|
||
- TruthfulQA — https://arxiv.org/abs/2109.07958
|
||
- SelfCheckGPT — https://arxiv.org/abs/2303.08896
|
||
- FActScore — https://arxiv.org/abs/2305.14251
|
||
- HaluEval — https://arxiv.org/abs/2305.11747
|
||
- MT-Bench / Chatbot Arena — https://arxiv.org/abs/2306.05685
|
||
- Chatbot Arena — https://arxiv.org/abs/2403.04132
|
||
- G-Eval — https://arxiv.org/abs/2303.16634
|
||
- LLMBar — https://arxiv.org/abs/2310.07641
|
||
- Length-Controlled AlpacaEval — https://arxiv.org/abs/2404.04475
|
||
- Arena-Hard — https://arxiv.org/abs/2406.11939
|
||
|
||
### 安全
|
||
|
||
- RealToxicityPrompts — https://arxiv.org/abs/2009.11462
|
||
- StereoSet — https://arxiv.org/abs/2004.09456
|
||
- CrowS-Pairs — https://arxiv.org/abs/2010.00133
|
||
- BBQ — https://arxiv.org/abs/2110.08193
|
||
- ToxiGen — https://arxiv.org/abs/2203.09509
|
||
- LM red teaming — https://arxiv.org/abs/2202.03286
|
||
- Red teaming lessons — https://arxiv.org/abs/2209.07858
|
||
- GCG — https://arxiv.org/abs/2307.15043
|
||
- Jailbroken — https://arxiv.org/abs/2307.02483
|
||
- XSTest — https://arxiv.org/abs/2308.01263
|
||
- Do-Not-Answer — https://arxiv.org/abs/2308.13387
|
||
- HarmBench — https://arxiv.org/abs/2402.04249
|
||
- StrongREJECT — https://arxiv.org/abs/2402.10260
|
||
- JailbreakBench — https://arxiv.org/abs/2404.01318
|
||
- InjecAgent — https://arxiv.org/abs/2403.02691
|
||
- Instruction Hierarchy — https://arxiv.org/abs/2404.13208
|
||
- WildGuard — https://arxiv.org/abs/2406.18495
|
||
- AILuminate — https://arxiv.org/abs/2503.05731
|
||
- AILuminate official limitations — https://ailuminate.mlcommons.org/benchmarks/general_purpose_ai_chat/1.0-en_us-official-ensemble
|
||
|
||
### DeepSeek / Kimi
|
||
|
||
- DeepSeek LLM — https://arxiv.org/abs/2401.02954
|
||
- DeepSeekMath — https://arxiv.org/abs/2402.03300
|
||
- DeepSeek-V2 — https://arxiv.org/abs/2405.04434
|
||
- DeepSeek-V3 — https://arxiv.org/abs/2412.19437
|
||
- DeepSeek-R1 — https://arxiv.org/abs/2501.12948
|
||
- DeepSeek-V3.2 — https://arxiv.org/abs/2512.02556
|
||
- DeepSeek-V4 — https://arxiv.org/abs/2606.19348
|
||
- Kimi k1.5 — https://arxiv.org/abs/2501.12599
|
||
- Kimi K3 — https://arxiv.org/abs/2607.24653
|
||
|
||
---
|
||
|
||
## 17. 本章完成检查
|
||
|
||
- [x] 现有 66 个评测标签节点审计；
|
||
- [x] K3 §6 公共 / 内部 / 第三方评测拆解；
|
||
- [x] DeepSeek LLM → Math → V2 → V3 → R1 → V3.2 → V4 协议谱系；
|
||
- [x] 50 个新增一手节点核验；
|
||
- [x] 22 张独立问题账；
|
||
- [x] pass@k / cons@k / pass^k 区分；
|
||
- [x] 污染五分法；
|
||
- [x] Judge / Arena 元评测主线；
|
||
- [x] code / long-context / multimodal / Agent verifier 主线；
|
||
- [x] safety threat model、jailbreak 有效性与 over-refusal；
|
||
- [x] 四联交互实验教学合同；
|
||
- [x] 评测审计卡；
|
||
- [x] 网站实现与浏览器回归；
|
||
- [ ] 生产发布与公开仓库同步。
|