feat: add evaluation and safety chapter
This commit is contained in:
wuyang
@@ -0,0 +1,225 @@
|
||||
# 评测与安全：Grok 候选线索账
|
||||
|
||||
> 状态：**未核验候选，不可作为正文证据。**
|
||||
>
|
||||
> 生成日期：2026-07-29
|
||||
>
|
||||
> 调用约束：`--no-plan --verbatim --no-subagents --disable-web-search`
|
||||
>
|
||||
> 使用纪律：Grok 只负责扩大候选召回和提出教学问题；论文年份、标题、指标、数值、
|
||||
> 因果解释与 K3 / DeepSeek 细节必须回到 P0 论文、技术报告或 P1 作者官方实现核验。
|
||||
|
||||
---
|
||||
|
||||
## 0. 为什么保留这份文件
|
||||
|
||||
这份文件不是“第二套参考文献”，而是防止研究过程失忆的候选池。它同时保留：
|
||||
|
||||
1. Grok 建议调查但尚未核验的节点；
|
||||
2. 已经进入一手核验队列的候选；
|
||||
3. 可能被拒绝、合并或降级为旁注的线索；
|
||||
4. 一组适合做成视觉与交互实验的协议比较问题。
|
||||
|
||||
正式证据账见 `EVALUATION_SAFETY_RESEARCH.md`。
|
||||
|
||||
---
|
||||
|
||||
## 1. 二十条候选主线
|
||||
|
||||
| # | 候选主线 | Grok 提出的核心矛盾 | 核验状态 |
|
||||
|---|---|---|---|
|
||||
| 1 | 困惑度与 next-token loss | 语言分布拟合不等于任务能力 | 已进入一手核验 |
|
||||
| 2 | 静态基准饱和 | 难度、区分度与题目质量会随模型进步失效 | 已进入一手核验 |
|
||||
| 3 | 数据污染 | 文本不重合不等于语义、答案或格式没有泄漏 | 已进入一手核验 |
|
||||
| 4 | 动态评测 | 更新题目能减轻污染，但会改变跨时间可比性 | 已进入一手核验 |
|
||||
| 5 | 代码执行 | 单元测试是强于文字相似度的 verifier，但测试也可能不充分 | 已进入一手核验 |
|
||||
| 6 | 数学验证 | exact match、数值检查、形式化证明不是同一强度 | 已进入一手核验 |
|
||||
| 7 | 人类偏好 | 偏好受用户群、抽样、顺序与呈现影响 | 已进入一手核验 |
|
||||
| 8 | LLM-as-a-Judge | 位置、长度、自我偏好与能力上限会进入分数 | 已进入一手核验 |
|
||||
| 9 | Arena / Elo | 排名是比较图与统计模型的产物，不是绝对能力刻度 | 已进入一手核验 |
|
||||
| 10 | 长上下文 | 声明窗口不等于有效理解长度 | 已进入一手核验 |
|
||||
| 11 | 多模态 | 总分可能掩盖 OCR、感知、知识与推理瓶颈 | 已进入一手核验 |
|
||||
| 12 | Agent / harness | 分数同时属于模型、脚手架、工具、环境和预算 | 已进入一手核验 |
|
||||
| 13 | 校准与弃答 | 准确率不回答“何时应该相信或拒答” | 已进入一手核验 |
|
||||
| 14 | 红队 | 红队发现什么取决于参与者、时间、访问权和目标 | 已进入一手核验 |
|
||||
| 15 | Jailbreak | “没有拒绝”不等于输出真的有害、具体且可用 | 已进入一手核验 |
|
||||
| 16 | Prompt injection | Agent 读取不可信数据后，权限与控制流成为评测对象 | 已进入一手核验 |
|
||||
| 17 | 网络安全双重用途 | 解题能力、真实攻击能力与部署风险必须分层 | 已进入一手核验 |
|
||||
| 18 | System / model card | 评测披露本身是可审计对象 | 已进入一手核验 |
|
||||
| 19 | 成本归一化 | 同一分数可能用了不同 token、工具调用和重复采样预算 | 已进入一手核验 |
|
||||
| 20 | 跨语言、文化与公平 | 翻译题不自动成为目标文化的有效测量 | 已进入一手核验 |
|
||||
|
||||
---
|
||||
|
||||
## 2. 候选节点池
|
||||
|
||||
### 2.1 测量与综合基准
|
||||
|
||||
- BLEU、ROUGE；
|
||||
- GLUE、SuperGLUE；
|
||||
- MMLU、BIG-bench、BIG-Bench Hard、HELM；
|
||||
- MMLU-Redux、MMLU-Pro、GPQA、Humanity’s Last Exam；
|
||||
- PALOMA、LiveBench；
|
||||
- Dynabench、Dynaboard；
|
||||
- Global MMLU。
|
||||
|
||||
### 2.2 校准、事实性与不确定性
|
||||
|
||||
- On Calibration of Modern Neural Networks；
|
||||
- Language Models (Mostly) Know What They Know；
|
||||
- Semantic Uncertainty；
|
||||
- TruthfulQA；
|
||||
- SelfCheckGPT；
|
||||
- FActScore；
|
||||
- HaluEval；
|
||||
- conformal abstention 候选。
|
||||
|
||||
### 2.3 开放生成、偏好与 Judge
|
||||
|
||||
- MT-Bench / Chatbot Arena；
|
||||
- Chatbot Arena 正式平台论文；
|
||||
- AlpacaEval 与 length-controlled AlpacaEval；
|
||||
- G-Eval；
|
||||
- LLMBar；
|
||||
- Arena-Hard / BenchBuilder；
|
||||
- RewardBench；
|
||||
- CoBBLEr、JudgeBench 等元评测候选。
|
||||
|
||||
### 2.4 代码、数学、上下文与 Agent
|
||||
|
||||
- HumanEval、DS-1000、EvalPlus、LiveCodeBench；
|
||||
- SWE-bench、SWE-bench Verified、SWE-bench Live / Pro；
|
||||
- FrontierMath；
|
||||
- LongBench、RULER；
|
||||
- AgentBench、WebArena、OSWorld；
|
||||
- τ-bench、BrowseComp、Terminal-Bench；
|
||||
- AgentDojo、InjecAgent、Agent Security Bench、Cybench。
|
||||
|
||||
### 2.5 安全、拒答与红队
|
||||
|
||||
- RealToxicityPrompts、StereoSet、CrowS-Pairs、BBQ、ToxiGen；
|
||||
- Red Teaming Language Models with Language Models；
|
||||
- Red Teaming Language Models to Reduce Harms；
|
||||
- GCG adversarial suffix；
|
||||
- Jailbroken；
|
||||
- XSTest、Do-Not-Answer；
|
||||
- HarmBench、StrongREJECT、JailbreakBench、WildGuard；
|
||||
- Instruction Hierarchy；
|
||||
- AILuminate；
|
||||
- Red-Teaming for Generative AI。
|
||||
|
||||
---
|
||||
|
||||
## 3. Grok 提出的十二张“协议护照”
|
||||
|
||||
下列内容只作为教学设计候选。每一项都必须在正式材料中用一手来源重新填写。
|
||||
|
||||
| # | 审计问题 | 容易产生的误读 | 必须披露的证据 | 候选视觉隐喻 |
|
||||
|---|---|---|---|---|
|
||||
| G1 | 同名 benchmark 是否用了相同题面、shots、示例与答案抽取？ | 分数更高就是模型更强 | 完整 prompt、shots、示例选择、CoT、parser | 同名考试，不同答题纸 |
|
||||
| G2 | 是 greedy、单次采样、pass@k、best-of-k 还是多数票？ | “90%”就是日常一次回答有 90% 正确率 | temperature、top-p、样本数、聚合、seed | 一次考试对十次取最好 |
|
||||
| G3 | max tokens 与 reasoning effort 是否相同？ | 架构更聪明，而不是测试时算得更多 | token cap、effort 档、停止规则、平均输出 | 草稿纸不限量的选手 |
|
||||
| G4 | 是裸模型，还是带代码、搜索、计算器与 Agent loop？ | 工具增强分数等于裸模型能力 | harness、工具清单、sandbox、重试、baseline 工具 | 开卷计算器对闭卷口试 |
|
||||
| G5 | 谁判对：字符串、程序、单测、人还是 LLM Judge？ | 不同裁判仍产生可移植的同一准确率 | judge 模型与 prompt、verifier、human audit | 不同终点传感器 |
|
||||
| G6 | 评的是裸 checkpoint 还是带风控的产品 API？ | 产品分数可同时代表模型能力与安全 | system prompt、过滤器、过拒率、wrapper ablation | 装有限速器的赛车 |
|
||||
| G7 | 长上下文是否被截断、摘要、检索或重新打包？ | 长上下文榜等于纯上下文理解 | window、截断方向、RAG、chunk、实际可见 token | 有人读全文，有人只看目录 |
|
||||
| G8 | benchmark 版本、split、commit 和日期是否一致？ | 名字相同就是同一套题 | hash、日期、decontamination、private holdout | 不同年份的马拉松赛道 |
|
||||
| G9 | 分数用了多少成本、延迟、token 与工具调用？ | 最高准确率自然是最佳生产选择 | 输入/输出 token、价格、P50/P95、硬件、重复采样成本 | 烧完整个车队油量的冠军 |
|
||||
| G10 | 数字来自作者自报、第三方重跑还是营销图？ | 出现在榜单上的数字同样可审计 | raw logs、config、seed、代码 commit、provenance | 实验室标签对自印标签 |
|
||||
| G11 | base、chat、reasoner 是否被同一协议公平地激发？ | 代际或架构独自解释全部差距 | 训练阶段、chat template、system role、CoT、默认解码 | 短跑、马拉松与徒步同榜 |
|
||||
| G12 | 拒答在当前任务里算失败、成功还是剔除？ | helpfulness 与 safety 可以压成单轴 | 拒答 rubric、过拒套件、政策版本、人工复核 | 门打不开是故障还是防盗 |
|
||||
|
||||
Grok 给出的候选总句：
|
||||
|
||||
```text
|
||||
leaderboard entry
|
||||
≠ intrinsic model property
|
||||
= model × prompt × sample budget × tools × judge × wrapper
|
||||
× data vintage × cost
|
||||
```
|
||||
|
||||
这句话仍需在正式正文中改写为“测量模型”，而不是引用 Grok。
|
||||
|
||||
---
|
||||
|
||||
## 4. 候选教学实验
|
||||
|
||||
### Lab A：协议护照
|
||||
|
||||
给两份公开技术报告，不看模型名，只填写：
|
||||
|
||||
```text
|
||||
dataset / split / prompt / shots / decode / samples
|
||||
/ budget / harness / tools / judge / verifier / provenance
|
||||
```
|
||||
|
||||
看字段是否足以支持横向比较。
|
||||
|
||||
### Lab B：Judge 偏差
|
||||
|
||||
保持答案语义不变，改变：
|
||||
|
||||
- 顺序；
|
||||
- 长度；
|
||||
- 风格；
|
||||
- 是否来自与 Judge 同族的模型；
|
||||
- rubric；
|
||||
|
||||
观察“偏好”怎样变化。
|
||||
|
||||
### Lab C：污染与动态基准
|
||||
|
||||
模拟五种污染：
|
||||
|
||||
- 原文；
|
||||
- 答案；
|
||||
- 格式；
|
||||
- 语义改写；
|
||||
- 时间泄漏；
|
||||
|
||||
再比较静态、私有、动态和可执行 verifier 四种补救。
|
||||
|
||||
### Lab D：系统分数
|
||||
|
||||
固定模型，改变：
|
||||
|
||||
- harness；
|
||||
- 工具；
|
||||
-步数；
|
||||
- 上下文；
|
||||
- 重试；
|
||||
- verifier；
|
||||
- 成本；
|
||||
|
||||
让学生看到 Agent 分数为何不能只归给模型。
|
||||
|
||||
---
|
||||
|
||||
## 5. 拒绝或降级规则
|
||||
|
||||
以下候选即使最终看起来“有趣”，也不直接进入正文结论：
|
||||
|
||||
1. 找不到 P0 / P1 原始来源的榜单数字；
|
||||
2. 只在聚合博客中出现的 benchmark 描述；
|
||||
3. 没有 threat model 的 jailbreak 成功率；
|
||||
4. 没有 Judge prompt / model 的自动偏好分；
|
||||
5. 没有 harness、工具和环境版本的 Agent 分数；
|
||||
6. 没有样本数与解码配置的 reasoning 分数；
|
||||
7. 把“未发现危险行为”写成“模型安全”；
|
||||
8. 把 n-gram 无重合写成“绝无污染”；
|
||||
9. 把作者单一设置下的相关性外推为 Judge 普遍可靠；
|
||||
10. 把安全 wrapper 的产品表现归因于裸模型。
|
||||
|
||||
---
|
||||
|
||||
## 6. 当前核验去向
|
||||
|
||||
- 测量与历史：BLEU、ROUGE、GLUE、MMLU、BIG-bench、HELM；
|
||||
- 基准修复：MMLU-Redux、MMLU-Pro、HLE、EvalPlus、SWE-bench Verified；
|
||||
- 污染与动态：PALOMA、FreshQA、LiveBench、LiveCodeBench、SWE-bench Live；
|
||||
- Judge 与 Arena：MT-Bench、Chatbot Arena、LLMBar、length-controlled AlpacaEval；
|
||||
- 校准：Guo et al.、P(IK) / P(True)、semantic uncertainty；
|
||||
- 安全：XSTest、HarmBench、StrongREJECT、JailbreakBench、AILuminate；
|
||||
- Agent 安全：InjecAgent、AgentDojo、Cybench、Agent Security Bench；
|
||||
- 锚点报告：DeepSeek LLM / Math / V2 / V3 / R1 / V3.2 / V4 与 Kimi K3 §6。
|
||||
|
||||
Reference in New Issue
Block a user