# 评测、安全与“到底强不强”：正式研究账本 > 状态：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_ 从 `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] 网站实现与浏览器回归； - [ ] 生产发布与公开仓库同步。