# Lecture 12 · 评估 > **CS336: Language Modeling from Scratch** · Stanford · Spring 2025 > 📅 May 8 · 💻 [可执行讲义](https://github.com/stanford-cs336/spring2025-lectures/blob/main/lecture_12.py) · 讲者 Percy Liang --- ## 承上启下 **上一讲（[[Lecture 11 · 缩放定律 II：细节]]）**：学会了用 scaling law 和小规模实验规划大模型训练——但那套方法优化的目标是 loss。训练出一个模型之后，还要回答一个更根本的问题：它到底好不好？「好」由谁定义、怎么测量？ **与 [[Lecture 10 · 推理]] 的关联**：评估本身就是一个大规模推理 workload——跑一遍完整 benchmark 是成千上万次模型调用，test-time compute（长思维链）更让单题成本涨一个数量级。推理效率决定了评估的成本预算，而评估的调用方式（是否允许 CoT、采样多少次）反过来是推理成本的主要变量。 **本讲（评估，evaluation）**：评估不是机械地跑 benchmark，而是把一个抽象目标（「模型好不好」）翻译成一套具体的游戏规则。不同人评估模型的目的不同——用户做购买决策、研究者测原始能力、监管者估安全风险、开发者要训练反馈——目的不同，正确的评估就不同。指标、输入分布、调用方式、成本、真实性、数据污染，每一项都会改变结论。 > [!abstract] 本讲一句话总览 > 没有「唯一正确的评估」。评估必须先问目的，再依次定义输入、调用方式、输出判分和结果解释。Perplexity 平滑通用但不等于有用；benchmark 可比较但容易失真；真实流量有价值但有隐私与混杂因素；安全评估更是能力（capability）与倾向（propensity）的混合体。 --- ## 1. 如何思考评估 先看动机：为什么不能「一个排行榜打天下」？因为评估至少服务四种不同的目的—— - **购买决策**：某公司想选一个模型做客服，它关心的是自家场景下的表现，不是 MMLU； - **测量原始能力**：研究者想知道模型「智力」的边界，关心难题上限； - **理解收益与危害**：监管者/社会关心模型会不会被滥用、幻觉率多高； - **开发反馈**：训练团队要一个能高频迭代、灵敏反映改动的信号。 无论哪种目的，一次评估都要回答四个问题： 1. **输入是什么？** - 覆盖哪些 use cases？分布是否代表真实用户？ - 有没有长尾困难样本，还是全是「平均难度」？ - 是否适配模型真实的交互形式（多轮对话、工具调用、RAG）？ 2. **怎么调用模型？** - zero-shot 还是 few-shot？prompt 模板是什么（模型对格式极其敏感）？ - 是否允许 chain-of-thought？是否允许工具？采样多少次？ - 评估的对象到底是 base model、chat model，还是整个 agent 系统？ 3. **怎么评价输出？** - 有无标准答案？标准答案本身可靠吗？ - 指标选什么：accuracy、pass@k、win rate，还是 cost-adjusted score（把推理成本折进去）？ - 错误是否对称？医疗场景里「漏诊」和「误诊」的代价天差地别，一个 accuracy 数字掩盖了这种不对称； - 开放式回答（写作、对话）没有唯一答案，靠人判还是靠模型判？ 4. **怎么解释结果？** - 91% 的 accuracy 是否代表可部署？（取决于剩下 9% 错在哪、错的代价多大） - 是否存在 train-test overlap，让分数虚高？ - 你在评估的是模型本身，还是训练方法，还是整套系统？（见第 9 节） > [!tip] 直觉 > 把评估想成设计一场比赛：规则（输入 + 调用方式 + 判分）决定了什么策略会赢。规则没写清楚，选手就会针对规则的漏洞优化（刷榜、过拟合 prompt 格式），而不是针对你真正关心的能力。所以「定义游戏规则」不是官僚程序，而是评估的全部内涵——不定义游戏规则的排行榜，只是热闹，不是科学。 > [!warning] 易错点 > 讲义反复强调的一条实操建议：**永远要亲眼看具体样例和模型的具体输出**（look at individual instances and predictions）。聚合分数会掩盖判分脚本的 bug、题目本身的错误和模型「答对但格式不符」被误判的情况。 --- ## 2. Perplexity：最基础但不万能 语言模型定义序列上的概率分布。对序列 $x_1, \dots, x_T$，按链式法则分解： $$p(x_1, \dots, x_T) = \prod_{t=1}^{T} p(x_t \mid x_{ [!tip] 直觉 > PPL 的直观含义是**有效分支因子**：PPL = 30 意味着模型每一步的不确定性相当于在 30 个等可能的 token 里瞎选。历史坐标：在 One Billion Word 等经典基准上，2016 年前后的 LSTM/CNN 系模型把 PPL 从 51.3 压到约 30；今天的大模型在同类语料上早已远低于此。「PPL 最大主义」（perplexity maximalist）观点认为把 PPL 压到底最终会通向 AGI——预测下一个 token 足够好就必须理解世界——即便这未必是最高效的路径。 ### 2.1 为什么 perplexity 有用？ - **平滑**：任务准确率是跳变的（对/错），PPL 是连续的，小的模型改进立刻反映出来，因此适合拟合 scaling laws、做训练中的监控； - **通用**：不依赖任何具体任务的定义，覆盖了任务准确率捕捉不到的细微差别； - **与训练目标一致**：优化的就是它，信号不失真； - **可以测 conditional perplexity**：把下游任务写成「给定 prompt 时答案的 PPL」，用它当轻量下游信号。 ### 2.2 为什么 perplexity 不够？ - 低 PPL 不保证指令跟随好——base model 的 PPL 可以很低，但让它「用 JSON 回答」照样失败；这中间隔着 [[Lecture 15 · 对齐 I：SFT 与 RLHF]] 的整个后训练阶段； - 不直接衡量推理、工具使用、安全等用户真正关心的能力； - **需要评估者信任模型给出的概率分布**：历史上有模型对罕见词输出 UNK token 来「作弊」压低 PPL；今天的闭源 API 常常根本不返回 logprobs，PPL 无从算起； - **tokenizer 不同则 PPL 不可比**（参见 [[Lecture 1 · 概览与分词]]）：per-token 的平均 loss 依赖分词粒度，词表大的模型每个 token「更难猜」。跨模型比较应换算成 bits-per-byte 这类与分词无关的单位； - 对用户价值不直接：没有用户在乎 PPL 降了 0.1。 > [!tip] 直觉 > Perplexity 是温度计，不是体检报告。它能灵敏地告诉你模型的语言建模能力是否在变好（所以训练时人人盯着它），但不能告诉你这个模型能不能当产品。评估体系需要 PPL 这样的「连续内部信号」和 benchmark 这样的「离散外部信号」互相配合。 --- ## 3. 知识与考试型基准 ### 3.1 MMLU MMLU（Massive Multitask Language Understanding）覆盖 57 个学科（数学、美国历史、法律、伦理等），全部是四选一选择题，由研究生/本科生从**公开网络资料**中收集，GPT-3 时代的标准用法是 few-shot（5-shot）提示。 问题在于：题目既然来自公开资料，就很可能出现在预训练语料里（数据污染，见第 9 节）；且选择题形式更像知识考试——测的是「记没记住」，不一定是「理解」；随着模型变强，头部模型分数逼近上限，基准趋于饱和，失去区分度。 ### 3.2 MMLU-Pro 针对 MMLU 的饱和与噪声做的改进：清洗掉有噪声/过于简单的题目；选项从 4 个扩到 10 个（瞎猜基线从 25% 掉到 10%）；用 chain-of-thought 评测。效果立竿见影——同一批模型的准确率比在原 MMLU 上下降 16~33 个百分点，基准重新获得区分度。 ### 3.3 GPQA GPQA（Graduate-Level Google-Proof Q&A）：由 61 位从 Upwork 招募的 PhD 级标注者编写研究生水平的科学题，并刻意做到「Google 免疫」——**非专家开着 Google 花 30 分钟也只能答对 34%**，而领域内 PhD 专家能到 65%，成文时的 GPT-4 是 39%。它测的是深度专业知识与推理，而非可检索的表面知识。 ### 3.4 Humanity's Last Exam HLE 的定位是「考试型基准的终点」：2500 道题，多模态、多学科，选择题 + 简答混合；出题有 50 万美元奖金池加合著者署名激励；题目先用 frontier model 过滤（模型能直接答对的题不收），再经多阶段人工审查。 > [!warning] 易错点 > 越难的 benchmark 越贵——出题要专家、审题要流程、判分要仔细，且一旦公开就开始被污染、被过拟合。「难」和「可信」是两个独立维度：难题库若审查不严，错误答案率反而更高（专家题的标准答案也会错）。 > [!tip] 直觉 > 这条演化线（MMLU → MMLU-Pro → GPQA → HLE）是模型与基准的军备竞赛：模型每逼近天花板一次，社区就造一个更难、更防污染、更贵的考试。但再难的考试仍是考试（quizzing）——它测知识上限，不测真实使用价值，后者要靠第 8 节的「真实性」评估补上。 --- ## 4. 指令跟随与开放式回答 考试型基准有标准答案；聊天、写作等开放式任务没有。判分只能靠「人类偏好」或「模型偏好」。 ### 4.1 Chatbot Arena 流程：真实用户输入自己的 prompt → 两个匿名模型分别回答 → 用户投票选更好的一个 → 汇总海量 pairwise comparison，用 Bradley-Terry 模型（Elo 风格）估计每个模型的 Arena 分数。 优点：输入是活的（用户真实问题，非静态题库，难以污染）；直接测人类偏好；新模型可以随时加入比较。 缺点：投票用户不是任何特定产品用户群的代表，且分布随时间漂移；偏好受**风格混杂因素**影响严重——更长、格式更漂亮、更礼貌的回答更容易赢，与内容质量无关（官方后来推出 style-controlled 排名试图剥离）；只给一个总分，不适合细分能力诊断。 ### 4.2 IFEval IFEval（Instruction-Following Eval）的思路是绕开主观判分：给指令附加**可程序化验证的约束**，如「必须包含某关键词」「用 JSON 输出」「不少于 N 条」，判分只检查约束是否满足，完全自动。 优点是客观、便宜、可复现；缺点是只测了「守规矩」，回答的语义质量不在测量范围内，且约束是人工构造的，与真实指令分布有距离。 ### 4.3 AlpacaEval / WildBench **AlpacaEval**：805 条开放式指令，让被测模型与基线模型（GPT-4 Preview）分别回答，再用 GPT-4 Preview 当裁判（LLM-as-judge）判胜负，指标是 win rate。裁判和基线是同一个模型，存在明显的自我偏爱风险；后续的 length-controlled 版本对「裁判偏爱长回答」做了回归校正。 **WildBench**：从 100 万条真实人机对话（WildChat）中精选 1024 个任务，用 GPT-4-Turbo 当裁判，但配上**逐题 checklist**引导裁判先分析再打分。它与 Chatbot Arena 的相关系数高达 0.95——说明设计得当的 LLM-as-judge 可以廉价地逼近昂贵的人类投票。 > [!warning] 易错点 > LLM-as-judge 便宜好用，但会系统性继承裁判模型的偏见：偏长、偏格式化（markdown、列表）、偏某些表达风格、偏自家模型。缓解手段：换多个裁判交叉验证、length-control、checklist 约束裁判的注意力、与人类投票（Arena）对齐校准。永远别忘了裁判本身也是个有偏的模型。 > [!tip] 直觉 > 开放式评估的三条路线各有取舍：Arena 用真人投票（最真实、最贵、最慢）、IFEval 用程序验证（最客观、覆盖面最窄）、AlpacaEval/WildBench 用模型裁判（最便宜、有偏见）。实践中三者互为校验：模型裁判的可信度就是用「与 Arena 的相关性」来论证的。 --- ## 5. Agent Benchmarks Agent = 语言模型 + 工具/环境/控制逻辑（scaffold）。评估前必须先问清楚： **是在评估模型，还是评估整个 agent scaffold？** 同一个模型换一套 scaffold（更好的检索、重试逻辑、环境提示）分数可以差出几十个点——排行榜上比的经常是 scaffold 工程，不是模型能力。 ### 5.1 SWE-bench 任务：给模型一个真实 GitHub issue 和对应的完整代码库，让它提交一个 patch，用仓库自带的单元测试判断是否真的修好。共 2294 个任务，来自 12 个流行 Python 仓库。 优点：贴近真实软件工程，单元测试提供客观判分。难点：环境复现繁琐；不少 issue 描述本身含糊（人也修不了）；测试可能不充分（patch 错了也能过）或过严（正确的等价修法过不了）；scaffold 差异对分数影响巨大。这些质量问题催生了 SWE-bench Verified——由人工逐题审查筛出的 500 题可信子集（见第 9 节）。 ### 5.2 CyBench 40 个来自真实 CTF（Capture the Flag）竞赛的网络安全任务，要求工具使用与多步探索。难度用**首解时间**（first-solve time，人类选手第一次解出该题所花的时间）客观标定。它是双重属性的典型：既是能力评估（安全从业者的渗透测试助手），也是风险评估（同样的能力可以用来攻击）——见第 7 节的 capability vs propensity。 ### 5.3 MLE-bench 75 个 Kaggle 竞赛构成的机器学习工程基准：数据处理、模型训练、实验迭代，以竞赛奖牌线为客观标尺。它测的是长周期、多步骤的 agent 能力——一次任务可能要跑几小时的真实计算。 > [!tip] 直觉 > Agent benchmark 的共同设计原则是**用环境本身当裁判**：单元测试、CTF 的 flag、Kaggle 的排行榜都是现成的、无法争辩的判分器。这与 [[Lecture 16 · 对齐 II：RLVR]] 的可验证奖励是同一个思想——凡是能自动验证的任务，既好评估，也好拿来做 RL 训练。 --- ## 6. 纯推理与抽象任务 ARC-AGI（Abstraction and Reasoning Corpus，Chollet 2019 年随论文 On the Measure of Intelligence 提出）：每道题给几个「输入网格 → 输出网格」的变换示例，要求推断规则并应用到新输入。它刻意最小化语言与世界知识成分，只假设人类共有的核心先验（objectness、对称、计数），试图测量**流体智力**——从少量例子中习得新规则的效率，而不是复述训练中见过的知识。ARC-AGI-2 是更难的后继版本。 难点与争议： - prompt/scaffold 对分数影响极大——网格如何序列化成文本、允许多少次采样，都能改变结论； - 视觉抽象先验对人类几乎免费，转成 token 序列后对模型未必公平； - 题目数量少，统计稳定性有限，几道题的波动就能改变排名； - 2024 年底 o3 用极高的 test-time compute 大幅突破 ARC-AGI-1，但单题推理成本高达数千美元——这凸显了「成本折算后的分数」（参见 [[Lecture 10 · 推理]]）应该成为一等公民指标。 > [!tip] 直觉 > ARC-AGI 想把「智力」从「知识」中剥离出来：考试型基准测的是晶体智力（积累了多少），ARC 测流体智力（学新规则多快）。它未必是完美的测量，但作为「模型是否只是在检索记忆」的反例探针非常有价值。 --- ## 7. 安全评估 ### 7.1 安全不是单一指标 「安全」在实践中是一大族彼此异质的问题：有害指令的鲁棒拒绝、幻觉率、隐私泄露、网络安全滥用、生物安全滥用、政治/法律/文化敏感内容，以及医疗等高风险领域的准确性。各自的评估方法与阈值完全不同，不存在一个「安全分」。 ### 7.2 HarmBench / AIR-Bench **HarmBench**：510 种违反法律或规范的有害行为，配套标准化的自动评估框架，统一衡量各种 red-teaming 攻击方法与模型拒绝能力——在它之前，各攻击论文的评估口径互不可比。 **AIR-Bench**：自上而下地从 8 部政府法规和 16 家公司政策中提炼出 314 个风险类别，构造 5694 条 prompt——让安全评估对齐监管者与企业实际关心的风险分类学，而不是研究者拍脑袋的类别。 ### 7.3 Jailbreak 与 GCG GCG（Greedy Coordinate Gradient）展示了对齐的脆弱性：用梯度信息贪心地逐坐标优化一段**对抗性后缀**（adversarial suffix，通常是乱码样的 token 串），拼在有害请求后面就能让对齐过的模型绕过拒绝。更麻烦的是**可迁移性**：在开源权重模型（如 Llama）上优化出的后缀，直接拿去攻击 GPT-4 等闭源模型也常常奏效——攻击者不需要你的权重。 ### 7.4 Capability vs Propensity 安全评估必须分清两个概念： | 概念 | 含义 | | :--- | :--- | | Capability（能力） | 模型有没有能力做某件（危险的）事 | | Propensity（倾向） | 模型会不会主动/愿意去做这件事 | API 模型可以靠拒绝策略与系统级防护压低 propensity，即使 capability 存在；而开源权重模型的安全微调可以被几步 fine-tuning 轻易剥除，propensity 防线形同虚设——因此**对开源权重模型，capability 本身才是需要评估的底线**。 > [!warning] 易错点 > CyBench 这类基准既是能力评估也是安全评估（dual-use，两用性）。写评估报告时必须说清楚你在测哪一个：测 capability 时模型拒绝回答会让分数虚低（低估风险），测 propensity 时用越狱手段逼模型回答又会让分数虚高。别装糊涂。 --- ## 8. 真实性：Benchmark 离真实使用有多远？ 很多 benchmark 本质是「**quizzing**」：出题人知道答案，只是在考模型——像考试。真实使用更像「**asking**」：用户自己不知道答案（否则不会问），想从系统获得真帮助——像问诊。两者的输入分布、难度构成、错误代价都不同，quizzing 上的高分不能直接外推到 asking 场景。 ### 8.1 Clio Anthropic 的 Clio 系统：用语言模型对真实用户对话做**隐私保护**的聚类与摘要（个体对话不暴露，只输出聚合后的主题分布），从而知道用户实际在问什么——结果显示编程、写作等用途占比远超 benchmark 里的题型分布。这是「用真实流量校准评估方向」的代表做法。 ### 8.2 MedHELM 医疗评估的演化：早期医疗 benchmark 基本是执业医师资格考试题（quizzing 的极致），MedHELM 则由 29 位临床医生参与定义了 121 个真实临床任务（病历摘要、临床决策支持等），混合公开与私有数据集，让评估对准医生的真实工作流。 现实难点：真实数据涉及隐私，无法随意公开；专家标注极贵；高风险领域错误代价不对称（漏诊 ≠ 误诊）；benchmark 一旦公开就开始被爬取、被污染——真实性与可复现性存在内在张力。 > [!tip] 直觉 > Benchmark 是真实需求的代理（proxy），而一切代理指标都会被 Goodhart 定律侵蚀：「当指标成为目标，它就不再是好指标」。Clio 和 MedHELM 代表了解药的方向——定期回到真实分布，重新校准代理。 --- ## 9. 效度：评估是否可信？ **效度（validity）**：分数真的测量了你以为它在测量的东西吗？三个主要威胁：污染、数据质量、比较对象错位。 ### 9.1 Train-Test Overlap 传统 ML 有干净的 train/test split；现代 LM 在整个互联网上训练且训练数据不公开，**你无法证明测试题不在训练集里**。后果：benchmark 题目（连同答案）被爬进语料，模型「背过题」，分数虚高，且无法区分泛化与记忆。 应对手段： - **n-gram / 近重复检测**：模型开发者自查训练集与测试集的字符串重叠（GPT 系列技术报告的做法），但只能抓字面重复，改写过的题抓不到； - **黑盒污染检测**：利用数据点的可交换性（exchangeability）做统计检验——如果模型对 benchmark 题目的**原始排列顺序**表现出偏好（logprob 显著高于打乱后的顺序），说明它在训练中见过这份数据集本身； - **推动报告规范**：要求模型开发者随发布报告 train-test overlap（本讲义作者 Liang 组的主张）； - **动态 benchmark**：持续更新题目（如 Arena 的活流量、按时间切分的 LiveBench 类基准），让「背题」失效； - **private eval**：保留不公开的测试集（如 ARC-AGI 的私有集），代价是外界无法审计题目质量。 ### 9.2 Dataset Quality Benchmark 本身也会错：题目有歧义、标准答案错误、单元测试覆盖不了真实修复、数据过时。当模型的错误率已经低于题库自身的错误率时，排行榜排名比的是「谁更会迎合错误标签」。 修复的实例： - **SWE-bench Verified**：对原始 SWE-bench 逐题人工审查，剔除 issue 描述不清、测试不公平的题，得到 500 题可信子集； - **Platinum benchmark**：对趋于饱和的经典基准（GSM8K 等）人工清洗标签错误，制作「白金版」，让顶部模型之间的差异重新可测； - 通用做法：人工审查抽样、发布高质量子集、报告题目级别的错误分析。 ### 9.3 评估模型还是方法？ 前基础模型时代，研究评估的是**方法（method）**：固定数据 + 固定训练预算 + 固定规则，谁的算法好谁赢——可复现、可归因。 现在的排行榜大多评估的是**模型/系统（model/system）**：任何数据 + 任何训练 + 任何后训练 + 任意 scaffold，只看最终输出——对下游用户有用，但「分数高」无法归因于任何单一技术，也无法指导科学结论。 两种范式都合理，但不能混淆。仍在坚持「评估方法」的例子： - **nanoGPT speedrun**：固定训练数据与目标验证 loss，比谁的训练代码到达目标最快——纯粹比训练方法； - **DataComp-LM**：反过来固定训练配方，比谁的数据筛选策略在标准 pipeline 下训出的模型最好——纯粹比数据方法（与 [[Lecture 13 · 数据 I]] 直接相关）。 > [!tip] 直觉 > 「比方法」与「比系统」的区别，类似受控实验与产品评测的区别：前者改变一个变量、回答科学问题（哪个算法/数据更好），后者端到端比较、回答消费决策（该买哪个）。读任何排行榜前先判断它属于哪一种，否则会从产品评测中错误地得出科学结论。 --- ## 总结 ```mermaid mindmap root((评估)) Framework inputs model call outputs interpretation Perplexity smooth universal not enough Benchmarks MMLU GPQA HLE ARC Open-ended Chatbot Arena IFEval AlpacaEval WildBench Agents SWE-bench CyBench MLE-bench Safety HarmBench AIR-Bench jailbreak capability vs propensity Validity contamination dataset quality method vs system ``` **关键要点**： 1. **没有唯一评估** - 评估取决于你要回答的问题：购买、测能力、估风险、要反馈，各有正确答案。四个设计维度：输入、调用方式、判分、解释。 2. **Perplexity 重要但远远不够** - 它平滑、通用、与训练目标一致，是 scaling law 与训练监控的支柱；但它不测指令跟随与下游能力，且跨 tokenizer 不可比、依赖模型给出可信概率。 3. **考试型基准在与模型军备竞赛** - MMLU 饱和 → MMLU-Pro 加难 → GPQA 做到 Google 免疫 → HLE 用 frontier model 过滤出题。越难越贵，且「难」不等于「可信」。 4. **开放式评估会引入 judge 偏见** - 人类投票受风格混杂影响，LLM-as-judge 继承裁判模型的偏长/偏格式偏见；checklist、length-control 与跨裁判校验是缓解手段。 5. **Agent benchmark 测的是系统** - scaffold、工具、执行环境都会大幅改变分数；好在环境本身（单元测试、flag、奖牌线）可以充当客观裁判。 6. **安全评估要区分能力与倾向** - API 模型靠拒绝策略压 propensity；开源权重模型的安全微调可被轻易剥除，必须直接评估 capability。GCG 说明越狱可跨模型迁移。 7. **效度是硬问题** - 污染让分数虚高（n-gram 检测、黑盒检测、报告规范、动态/私有题库应对），benchmark 自身的标签错误需要 Verified/Platinum 式清洗，「比方法」与「比系统」不能混为一谈。 **下一讲预告（[[Lecture 13 · 数据 I]]）**： 评估告诉我们模型哪里强弱；下一讲回到源头：预训练数据从哪里来，为什么开源模型最不愿公开的就是数据，Common Crawl、C4、The Pile、Dolma、DCLM 等数据集如何演进。 --- ## 复习自测 > [!question]- Q1：写出 perplexity 与交叉熵的关系式。为什么不同 tokenizer 的模型不能直接比 PPL？该怎么办？ > $\text{PPL} = \exp\bigl(-\frac{1}{\lvert D\rvert}\sum_t \log p(x_t \mid x_{ [!question]- Q2：某模型 MMLU 拿到 91%，能否得出「可以部署到我的产品」的结论？列出至少三个理由说明为什么不能。 > 不能。(1) 可能有 train-test overlap，分数含记忆成分；(2) MMLU 是四选一知识考试（quizzing），与产品的真实输入分布（asking）不同；(3) 聚合分数掩盖了错误的位置与代价——剩下 9% 若集中在你的关键场景或高代价错误上则不可接受；(4) 分数依赖 prompt 格式与调用方式，换到产品的调用形态未必复现。 > [!question]- Q3：概念辨析：capability vs propensity。为什么对开源权重模型来说 capability 评估更关键？ > Capability 是「有没有能力做」，propensity 是「会不会去做」。API 模型部署方可以用拒绝策略、系统提示和外围防护把 propensity 压低，即使 capability 存在。开源权重模型则不同：任何人拿到权重后用少量微调就能剥除安全对齐，propensity 防线不可依赖，所以危险能力本身（capability）是否存在成了唯一有意义的安全底线。 > [!question]- Q4：LLM-as-judge 有哪些系统性偏见？WildBench 用什么手段让模型裁判变得更可信，其可信度又是如何论证的？ > 偏见：偏爱更长的回答、偏爱 markdown/列表等格式化输出、偏爱特定表达风格、偏爱与裁判同源的模型（AlpacaEval 用 GPT-4 当裁判又当基线即是风险）。WildBench 的手段：任务取自真实对话（分布真实）、逐题 checklist 引导裁判先分析再打分；可信度论证靠外部校准——与 Chatbot Arena 人类投票的相关系数达 0.95。 > [!question]- Q5：「评估方法」与「评估模型/系统」有何区别？nanoGPT speedrun 和 DataComp-LM 分别固定了什么、比较什么？ > 评估方法 = 控制变量的受控实验：固定数据/预算/规则，比较算法，结论可归因；评估系统 = 端到端比较最终产物，服务购买决策但无法归因。nanoGPT speedrun 固定训练数据与目标验证 loss，比谁的训练方法最快到达；DataComp-LM 固定训练配方与预算，比谁的数据筛选方法训出的模型更好。 --- ## 参考资料 - 💻 [lecture_12.py（官方可执行讲义）](https://github.com/stanford-cs336/spring2025-lectures/blob/main/lecture_12.py) - 📄 [MMLU](https://arxiv.org/pdf/2009.03300.pdf) - 📄 [MMLU-Pro](https://arxiv.org/abs/2406.01574) - 📄 [GPQA](https://arxiv.org/abs/2311.12022) - 📄 [Humanity's Last Exam](https://arxiv.org/abs/2501.14249) - 📄 [Chatbot Arena](https://arxiv.org/abs/2403.04132) - 📄 [IFEval](https://arxiv.org/abs/2311.07911) - 📄 [AlpacaEval（length-controlled）](https://arxiv.org/abs/2404.04475) - 📄 [WildBench](https://arxiv.org/abs/2406.04770) - 📄 [SWE-bench](https://arxiv.org/abs/2310.06770) - 📄 [CyBench](https://arxiv.org/abs/2408.08926) - 📄 [MLE-bench](https://arxiv.org/abs/2410.07095) - 📄 [On the Measure of Intelligence（ARC）](https://arxiv.org/abs/1911.01547) - 📄 [HarmBench](https://arxiv.org/abs/2402.04249) - 📄 [AIR-Bench 2024](https://arxiv.org/abs/2407.17436) - 📄 [Universal and Transferable Adversarial Attacks on Aligned Language Models（GCG）](https://arxiv.org/abs/2307.15043) - 📄 [Clio: Privacy-Preserving Insights into Real-World AI Use](https://arxiv.org/abs/2412.13678) - 📄 [Language Models Should Report Train-Test Overlap](https://arxiv.org/abs/2410.08385) - 📖 [HELM](https://crfm.stanford.edu/helm/latest/)