评测基准深入

面试里问“你知道哪些大模型评测基准”“榜单分数能不能直接相信”“怎么给业务选择模型”时，真正考察的不是你能背出多少 benchmark 名字，而是你是否理解：每个基准测的是什么能力、没测到什么风险、分数为什么会失真，以及如何把公开榜单转化为自己的业务评测体系。基础评估方法见 模型评估与幻觉治理。

一句话回答

大模型评测基准是用标准化任务衡量模型能力的测试集。它能帮助我们横向比较模型，但不能直接等价于生产效果。成熟的回答应该是：

我会把 benchmark 当成模型选型的第一层筛选，而不是上线决策。公开基准看知识、推理、代码、长上下文、工具调用、安全等通用能力；业务上线还要构建自己的 golden set、bad case 集、成本延迟指标、人工抽检和线上 A/B。榜单分数要警惕数据污染、prompt 口径不一致、过拟合刷榜、LLM Judge 偏差和单指标误导。

这段回答包含了三层意思：

• 知道基准：能说出主流 benchmark 的能力维度。
• 会批判：知道榜单不是绝对真理。
• 能落地：能把公开评测转成业务评测闭环。

为什么需要 benchmark

如果没有评测基准，我们只能靠主观体验说“这个模型好像更聪明”。Benchmark 的价值在于把能力拆成可重复的任务，用统一指标比较不同模型、不同版本、不同推理策略。

它主要解决四个问题：

问题	benchmark 的作用	局限
模型横向对比	同一套题测多个模型	不一定代表你的业务场景
版本迭代追踪	新旧模型跑同一评测集	可能对评测集过拟合
能力短板识别	按知识、数学、代码、安全拆分	维度仍然不完整
上线门禁	作为回归测试的一部分	还要结合成本、延迟、稳定性

面试里要强调：benchmark 是信号，不是结论。它能告诉你模型在某类题上表现如何，但不能保证模型在真实用户、真实知识库、真实工具权限下可靠。

评测基准的能力地图

常见大模型能力可以按下面几类组织：

能力维度	典型基准	主要看什么
综合知识	MMLU、MMLU-Pro、C-Eval、CMMLU	学科知识、常识、多选题能力
高难知识推理	GPQA、HLE	博士级或专家级问题
数学推理	GSM8K、MATH、AIME	多步计算、代数、竞赛数学
代码能力	HumanEval、MBPP、LiveCodeBench、SWE-bench	函数生成、编程题、真实 issue 修复
指令遵循	IFEval	格式、约束、严格执行指令
对话偏好	MT-Bench、Chatbot Arena	人类偏好、多轮对话体验
长上下文	Needle-in-a-Haystack、LongBench、RULER	长文档读取、定位、推理
RAG	RAGAS、自建问答集	检索召回、忠实度、引用正确性
Agent / 工具	BFCL、ToolBench、GAIA、AgentBench	工具选择、参数生成、任务完成
安全与诚实	TruthfulQA、ToxiGen、越狱红队集	幻觉、毒性、拒答和安全边界
多模态	MMMU、MMBench、MathVista	图文理解、视觉推理、图表问答

记忆技巧：不要按名字硬背，而是按“知识、推理、代码、指令、对话、长上下文、工具、安全、多模态”九个维度背。面试官换一种问法，你也能稳定组织答案。

综合知识类：MMLU、MMLU-Pro、C-Eval、CMMLU

综合知识基准通常由多学科选择题组成，用来观察模型是否掌握广泛知识。

MMLU

MMLU 覆盖数学、物理、历史、法律、医学、经济等多个学科，是最常被引用的通用能力指标之一。它适合回答“模型是否具备广泛知识基础”，但并不能完整代表推理、对话、代码和生产可靠性。

常见追问：

MMLU 高就一定好吗？

不一定。MMLU 是选择题，很多题接近静态知识问答。它可能受到训练数据污染影响，也不能反映模型在开放生成、工具调用、复杂项目、结构化输出、安全拒答上的表现。

MMLU-Pro

MMLU-Pro 是更难的变体，通常通过增加选项、提高题目难度、增强推理要求来缓解 MMLU 接近饱和的问题。它比 MMLU 更适合区分较强模型，但仍然不能替代真实业务评测。

C-Eval 与 CMMLU

C-Eval 和 CMMLU 更关注中文语境和中国教育体系下的学科知识，对中文模型选型更有参考价值。面向中文政企、教育、客服、知识库项目时，不能只看英文榜单，还要关注中文理解、中文长文本、中文术语和本土知识。

面试表达：

综合知识基准适合做模型初筛，但它们大多是静态题库和选择题。中文业务要补 C-Eval、CMMLU 和自建中文业务集；上线决策还要看幻觉、引用、格式遵循、成本和延迟。

高难知识与专家级问题：GPQA、HLE

当通用榜单接近饱和后，行业会不断推出更难的基准来区分顶尖模型。

GPQA

GPQA 面向研究生或专家级知识题，强调“即使搜索也不容易直接找到答案”的高难问题。它常用于区分强推理模型和普通聊天模型。

它的价值在于：

• 题目难度高，不容易被简单模式匹配解决。
• 对科学知识、严谨推理和不确定性处理要求更高。
• 更能区分顶尖模型之间的差距。

局限是：它仍然是题库型评测，不代表模型在企业工具、私有知识和复杂流程里的表现。

HLE

HLE 常被视为高难综合评测，用大量专家级问题观察模型在极难知识和推理任务上的上限。它适合判断模型“天花板”，但不适合直接判断一个客服 RAG、合同审核、投研 Agent 是否上线可用。

面试里可以补一句：

GPQA、HLE 这类高难基准更像能力上限测试，而业务系统更关心稳定下限。选型时既要看模型上限，也要看普通请求、长尾请求和失败模式。

数学推理类：GSM8K、MATH、AIME

数学评测关注多步推理、符号操作和计算准确性。它是区分普通语言流畅性和真正推理能力的重要维度。

GSM8K

GSM8K 是小学数学应用题，主要测试自然语言数学推理。早期它很有区分度，但强模型在该数据集上逐渐接近饱和，因此现在常作为基础参考。

MATH

MATH 难度更高，覆盖代数、几何、数论、概率等竞赛级问题。它比 GSM8K 更考验多步推理、公式变换和错误恢复。

AIME

AIME 是数学竞赛题，常被用于观察推理模型的高难数学能力。它对“慢思考”、多路径尝试、自我验证、test-time compute 非常敏感。

数学基准的坑：

• 有些模型靠训练中见过题或相似题得分。
• 输出格式稍错可能导致自动判分失败。
• 多采样和自一致性会显著提高分数，但成本也会上升。
• 数学能力强不等于业务能力强。

面试追问可以这样答：

数学 benchmark 适合看模型的多步推理能力，但要区分“单次稳定答对”和“多次采样总能蒙对”。生产系统更关心 pass@1 或稳定正确率，而不是高成本采样后的最好结果。

代码类：HumanEval、MBPP、LiveCodeBench、SWE-bench

代码评测是 LLM 面试和岗位要求里非常高频的方向，尤其是 AI Coding、Coding Agent、代码审查、自动修复等岗位。

HumanEval

HumanEval 给出函数签名和描述，要求模型补全函数，通过单元测试判定正确性。它常用 Pass@k 指标。

优点：

• 自动判分清晰。
• 能衡量基本代码生成能力。
• 易于横向比较。

局限：

• 题目规模小，多是独立函数。
• 不能代表真实仓库理解、依赖管理、调试和重构。
• 容易被训练数据污染。

MBPP

MBPP 更偏入门级 Python 编程题，适合测基础代码生成，但对真实工程能力区分有限。

LiveCodeBench

LiveCodeBench 的价值在于持续更新题目，降低数据污染风险。它更适合评估模型在新题上的泛化能力。

SWE-bench

SWE-bench 更贴近真实软件工程：模型需要理解 GitHub issue，在真实仓库中修改代码并让测试通过。它比函数级 benchmark 更难，也更接近 Coding Agent。

SWE-bench 的考察点包括：

• 能否理解大型项目结构。
• 能否定位 bug 根因。
• 能否做最小修复。
• 能否运行和解释测试。
• 能否避免破坏无关行为。

面试表达：

HumanEval 看的是函数级代码生成，SWE-bench 看的是仓库级问题修复。真正的 Coding Agent 不能只会写函数，还要会读项目、定位依赖、修改多文件、跑测试、处理失败和保持最小变更。

Pass@k 怎么理解

代码评测常用 Pass@k：同一题采样 k 个答案，只要其中有一个通过测试，就算该题通过。

常见指标：

• Pass@1：一次生成就通过，代表稳定性。
• Pass@10 / Pass@100：多次采样中能否出现正确答案，代表潜力上限。
• pass^k：连续 k 次都成功，更接近生产可靠性。

如果一个模型 Pass@1 低但 Pass@100 高，说明它“会做但不稳定”。这类模型在竞赛刷分时可能好看，但生产环境要小心，因为用户通常不会给它一百次机会。

和 Agent 系统相关时，还要看：

• 平均尝试次数。
• 每次尝试成本。
• 成功前是否产生副作用。
• 失败时能否回滚。
• 是否需要人工接管。

面试可以这样说：

Pass@k 不是免费能力。k 越大，成本和延迟越高。线上系统更关心在预算内的成功率，比如 pass@1、pass@3、或者限定 token 和时间后的任务完成率。

指令遵循：IFEval

IFEval 评估模型是否严格遵循可验证指令，例如：

• 回答必须正好 3 段。
• 必须包含某个关键词。
• 不能使用某些词。
• 必须输出 JSON。
• 字数、格式、语言必须满足约束。

这类能力对工程落地非常重要。很多业务系统不是“回答得大概对”就可以，而是必须符合 API、表单、流程和审计格式。

典型失败：

• 内容对，但 JSON 不合法。
• 答案有价值，但多输出解释文字。
• 忘记用户要求的语言。
• 多轮对话后丢失格式约束。
• 工具参数类型不匹配。

面试追问：

为什么指令遵循很重要？

因为 LLM 应用往往嵌在工程系统里。格式不稳定会导致解析失败，约束不稳定会导致审批、风控、客服流程出错。工程上要结合低温度、schema、结构化输出、重试、解析校验和 fallback。

对话偏好：MT-Bench 与 Chatbot Arena

对话质量很难用唯一标准答案衡量，所以常用人类偏好或 LLM-as-a-Judge。

MT-Bench

MT-Bench 用多轮问题评估模型对话质量，常由强模型当裁判。它适合快速比较对话体验，但会受到 judge 模型偏差影响。

Chatbot Arena

Chatbot Arena 让真实用户对两个匿名模型回答做盲评，再用 Elo 或 Bradley-Terry 类方法排序。它更接近人类偏好，但也不是完美答案。

优点：

• 来自真实用户。
• 匿名对比能降低品牌偏见。
• 覆盖开放式对话体验。

局限：

• 用户偏好不等于事实正确。
• 更长、更自信、更会排版的回答可能占优。
• 题型分布受用户群体影响。
• 更新慢，不能覆盖每个行业细分场景。

面试表达：

Arena 更像“用户体验偏好榜”，不是事实正确率榜。客服、医疗、法律、金融等场景不能只看 Arena，还要看领域准确性、合规性、拒答边界和可追溯证据。

长上下文评测：Needle、LongBench、RULER

长上下文能力不只是“模型支持多少 token”。评测要回答三个问题：

1. 放得下吗：上下文窗口长度是否足够。
2. 找得到吗：模型能否在长文里定位关键信息。
3. 用得好吗：模型能否跨多段信息推理，而不是只复制局部句子。

Needle-in-a-Haystack

大海捞针评测把一个关键信息插入长文不同位置，看模型能否找回。它简单直观，但容易被刷，也不能代表复杂长文推理。

LongBench

LongBench 覆盖长文问答、摘要、多文档推理等任务，比单纯 needle 更接近真实长上下文。

RULER

RULER 关注长上下文中检索、聚合、多跳和干扰信息处理，适合观察长窗口模型是否真的有效。

长上下文常见坑：

• 模型能处理 128K，不代表 128K 内所有信息都能用好。
• 中间位置内容可能被忽略，即 lost in the middle。
• 长 prompt 会显著增加成本和延迟。
• RAG 和长上下文不是替代关系，常常需要组合。

面试回答：

长上下文评测要区分窗口长度和有效利用率。上线时我会测不同长度、不同位置、不同干扰强度下的答案质量，同时记录 token 成本、TTFT、TPOT 和引用准确率。

RAG 评测：从检索到生成拆开看

RAG 评测不能只看最终回答，因为失败可能来自检索，也可能来自生成。

建议拆成两层：

检索层指标

• Recall@K：正确证据是否进入前 K 个结果。
• Precision@K：前 K 个结果里有多少是相关内容。
• MRR：第一个正确结果排得多靠前。
• nDCG：综合考虑相关性和排序位置。
• Context Precision：放进上下文的片段是否真的有用。

生成层指标

• Faithfulness：回答是否忠实于检索上下文。
• Answer Relevance：回答是否真正回应问题。
• Citation Accuracy：引用是否指向正确证据。
• Completeness：是否遗漏关键点。
• Refusal Correctness：资料不足时是否知道拒答。

典型面试追问：

RAG 答错了怎么定位？

可以按链路排查：

问题理解 -> query 改写 -> embedding 召回 -> rerank -> chunk 质量
-> 上下文拼接 -> prompt 约束 -> 生成忠实度 -> 引用校验

如果正确证据没召回，是检索问题；正确证据召回了但模型不用，是上下文组织或生成问题；证据不足却编答案，是拒答和忠实度问题。

Agent 与工具调用评测

Agent 评测比普通问答更难，因为它不是只看最后一句话，还要看过程。

BFCL

BFCL 常用于评估函数调用能力，包括工具选择、参数抽取、多工具组合和结构化调用。它对 Function Calling、MCP、企业工具接入非常重要。

ToolBench

ToolBench 更关注模型使用真实或模拟 API 完成任务的能力，适合评估工具规划和调用链路。

GAIA

GAIA 强调真实世界任务，需要模型检索、推理、使用工具并给出最终答案。它更接近“能不能像助理一样完成复杂任务”。

AgentBench

AgentBench 通过多类交互环境评估 Agent，包括网页、终端、数据库、游戏或操作环境等，关注行动序列和反馈利用。

Agent 评测建议拆成四层：

层级	评什么	例子
结果层	任务是否完成	成功率、正确率、用户满意度
轨迹层	步骤是否合理	是否少走弯路、是否重复调用
工具层	工具调用是否正确	函数名、参数、权限、错误处理
安全层	是否越权或造成副作用	删除数据、发邮件、转账、泄露隐私

面试表达：

Agent 不能只评 final answer。生产里要记录 trajectory，评估计划质量、工具选择、参数正确性、错误恢复、权限边界和副作用控制。对于高风险工具，还要有人审、沙箱、幂等和审计。

安全、诚实与拒答评测

安全评测常被低估，但企业场景里非常关键。

常见维度：

• 毒性输出：是否生成歧视、辱骂、仇恨内容。
• 越狱成功率：是否能被 prompt injection 绕过安全规则。
• 隐私泄露：是否输出训练记忆、日志、个人信息。
• 错误拒答：无害请求是否被过度拒绝。
• 危险能力：是否帮助攻击、诈骗、恶意代码、规避监管。
• 诚实性：不知道时是否承认不知道，是否编造引用。

代表性基准包括 TruthfulQA、ToxiGen、红队越狱集，以及企业自建安全集。

回答安全评测时要强调“双向指标”：

• 该拒的要拒：危险请求拒答率。
• 不该拒的别拒：正常请求误拒率。

只追求拒答率会导致模型过度保守；只追求帮助性会导致安全边界失守。生产系统要在风险分级下设置不同门槛。

多模态评测

多模态模型不仅要会看图，还要能把视觉信息和语言推理结合起来。

常见评测：

• MMMU：多学科多模态理解，题目通常需要图文结合。
• MMBench：综合视觉问答和多模态理解。
• MathVista：图表、几何、数学视觉推理。
• OCRBench：文字识别、文档理解、截图阅读。

多模态评测要注意：

• OCR 能力和视觉推理能力要分开看。
• 图表问答需要精确读数，不只是描述图片。
• 截图 Agent 还要评估 UI 定位、点击、状态变化。
• 生成式图像/视频还要看一致性、安全和版权风险。

如果岗位是多模态 Agent、智能文档、票据识别、质检巡检，这部分就非常高频。

数据污染：评测可信度的头号风险

数据污染指测试题或答案出现在训练数据中，导致模型像“考前背题”一样拿高分。

污染会带来三个问题：

• 分数虚高。
• 不能反映真实泛化能力。
• 模型选型被误导。

常见检测方法：

• 训练语料和测试集做 n-gram 重复检测。
• 改写题目后看分数是否大幅下降。
• 使用发布时间晚于模型训练截止的数据。
• 使用私有 held-out 测试集。
• 关注持续更新 benchmark。

面试表达：

我不会只看静态公开榜单。关键任务会维护私有评测集，并定期从线上 bad case 回流新样本，降低刷榜和污染带来的误判。

LLM-as-a-Judge 的偏差

很多开放式评测用强模型当裁判，但裁判模型也会偏。

常见偏差：

偏差	表现	缓解
位置偏差	更偏向第一个或第二个答案	交换顺序评两次
长度偏差	更喜欢长答案	rubric 明确简洁优先
格式偏差	更喜欢 Markdown 和表格	剥离格式或单独评分
自我偏好	偏向同源模型风格	多裁判、第三方裁判
权威偏差	被模型名称或暗示影响	匿名评测
解释偏差	看起来有逻辑就给高分	要求证据和事实核查

使用 LLM Judge 前要做 meta-evaluation，也就是先评估裁判是否靠谱：

• 抽样人工标注。
• 计算 judge 和人工一致率。
• 比较 pointwise 与 pairwise 结果。
• 对高风险样本人工复核。
• 固定 judge prompt 和版本。

面试里可以说：

LLM Judge 是规模化评测工具，不是最终真理。它适合提高效率，但必须用人工抽检校准，并对偏差做治理。

怎么批判性看榜单

看榜单时不要只看第一名，要问八个问题：

1. 测的任务和我的业务是否匹配？
2. 评测是 zero-shot、few-shot 还是 CoT？
3. 是否允许工具、检索、多采样？
4. 解码参数和输出长度是否一致？
5. 是否存在数据污染或刷榜嫌疑？
6. 是否看了成本、延迟和上下文长度？
7. 是否覆盖安全、拒答、隐私和合规？
8. 是否有中文、本行业、本公司数据验证？

举例：一个模型在 Arena 排名高，可能非常适合通用聊天，但未必适合法律条款抽取；一个模型在 AIME 高，可能数学强，但未必能稳定输出 JSON；一个模型在 SWE-bench 高，可能代码修复强，但在中文客服上未必有优势。

公开基准到业务评测集的转化

生产系统不能只用公开 benchmark，需要建设自己的评测集。

第一步：定义任务边界

先明确系统要解决什么问题：

• 是客服问答、知识库 RAG、合同审核、投研摘要，还是 Coding Agent？
• 输出是开放问答、结构化 JSON、工具调用，还是操作任务？
• 失败代价是什么？
• 是否涉及隐私、金融、医疗、法律或权限操作？

第二步：构建 golden set

golden set 是人工确认的高质量评测样本。建议从真实场景收集：

• 高频用户问题。
• 高价值业务问题。
• 历史 bad case。
• 边界和异常输入。
• 安全和越权请求。
• 长尾行业术语。

每条样本最好包含：

• 输入问题。
• 必要上下文或检索材料。
• 参考答案或判分 rubric。
• 标签：场景、难度、风险、期望行为。
• 是否允许拒答。
• 是否要求引用或结构化输出。

第三步：分层评测

不要只给一个总分。推荐拆成：

层级	指标
质量	正确性、完整性、相关性、可读性
忠实	是否依据材料、是否编造、引用是否正确
格式	JSON 合法性、字段完整性、schema 通过率
安全	越权、泄露、危险建议、误拒
工程	TTFT、TPOT、P95 延迟、token 成本、失败率
业务	解决率、转人工率、用户满意度、转化率

第四步：接入 CI 和发布门禁

每次改模型、prompt、RAG 参数、reranker、工具 schema，都要跑回归评测。

变更提交
  -> 跑离线 golden set
  -> 检查质量/安全/成本门槛
  -> 小流量灰度
  -> 线上指标观察
  -> bad case 回流评测集

这就是评测驱动开发。没有这套闭环，模型优化就会变成“感觉变好了”。

不同岗位怎么讲 benchmark

LLM 应用开发

重点讲业务评测集、结构化输出通过率、成本延迟、Prompt 回归和线上 bad case。

可以说：

我会先用公开榜单做初筛，再用业务 golden set 对比模型。上线门禁不只看回答质量，还看 JSON 通过率、P95 延迟、token 成本和安全拒答。

RAG 工程

重点讲检索和生成拆分评估。

可以说：

RAG 评测要把 Recall@K、rerank 后命中率、faithfulness、引用准确率拆开，否则最终答案错了不知道是没检索到，还是检索到了但模型编了。

Agent 工程

重点讲任务完成率、轨迹、工具调用和副作用。

可以说：

Agent 的 benchmark 要看 trajectory。最终答对不代表过程安全，尤其是调用企业系统时，要评估权限、幂等、重试、错误恢复和人工审批。

AI Infra / MaaS

重点讲 benchmark 的复现、模型服务指标和成本。

可以说：

平台侧会统一评测口径，固定 prompt、参数、版本、硬件和并发条件，同时记录 TTFT、TPOT、吞吐、显存和失败率，避免只看质量分忽略推理成本。

算法 / 微调

重点讲训练前后回归、泛化和污染。

可以说：

微调后不能只看目标任务涨分，还要测通用能力回归、安全集、格式遵循和 held-out 数据，防止过拟合和灾难性遗忘。

高频面试问答

Q：MMLU 分数高就一定是好模型吗？

不一定。MMLU 主要测多学科选择题，不能代表开放生成、复杂推理、工具调用、代码修复、中文业务和安全合规。它适合初筛，不能作为上线结论。

Q：为什么 Chatbot Arena 被很多人重视？

因为它来自真实用户匿名两两对比，比较接近人类偏好。但它也有偏差：用户偏好不等于事实正确，长而流畅的回答可能更占优势，而且题型分布不一定匹配你的业务。

Q：Pass@1 和 Pass@100 差很多说明什么？

说明模型有潜力但不稳定。多次采样能撞出正确答案，但单次成功率低。生产更关心预算内稳定成功率，而不是无限采样后的最好结果。

Q：怎么判断一个 benchmark 是否被污染？

可以看题目发布时间和模型训练截止时间，做 n-gram 重复检测，改写题目看掉分幅度，或者使用私有 held-out 集。公开静态题库越流行，污染风险越高。

Q：LLM-as-a-Judge 有哪些坑？

常见有位置偏差、长度偏差、格式偏差、自我偏好和事实核查不足。缓解方式是匿名、交换顺序、多裁判、人工抽检、固定 rubric，并评估 judge 与人工的一致率。

Q：如何给企业知识库 RAG 设计评测？

先构建真实问题集和参考证据，再拆检索指标和生成指标。检索看 Recall@K、MRR、Context Precision；生成看忠实度、答案相关性、引用准确率、拒答正确率；最后加成本、延迟和线上满意度。

Q：如何给 Agent 设计评测？

看四层：任务是否完成、轨迹是否合理、工具调用是否正确、安全边界是否守住。还要记录调用次数、失败恢复、权限审批、幂等和副作用。

Q：公开 benchmark 和业务评测集是什么关系？

公开 benchmark 用于通用能力初筛，业务评测集用于上线决策。真正的生产评测应来自真实用户问题、历史失败案例和高风险边界样本。

Q：为什么模型榜单会和真实体验不一致？

原因包括任务不匹配、评测口径不同、数据污染、成本延迟未计入、中文和行业数据不足、线上工具链差异，以及用户真实问题比 benchmark 更混乱。

Q：模型升级时应该跑哪些评测？

至少跑 golden set、bad case 回归、格式遵循、安全集、成本延迟、关键业务指标。RAG 还要跑召回和忠实度，Agent 还要跑工具调用和轨迹安全。

系统设计追问：设计一个模型评测平台

如果面试官让你设计一个模型评测平台，可以按下面结构回答：

数据层：评测集、标签、参考答案、rubric、历史 bad case
执行层：模型适配器、prompt 模板、参数配置、并发调度
评判层：规则指标、LLM Judge、人工复核、统计显著性
报告层：模型对比、版本趋势、失败聚类、成本延迟
门禁层：CI 集成、灰度策略、回滚策略、审批流

关键设计点：

• 评测样本要版本化，避免改题后历史结果不可比。
• 模型调用参数要记录，避免 temperature、max tokens、system prompt 不一致。
• Judge prompt 和 judge 模型要版本化。
• 结果要保存原始输入、输出、上下文、工具轨迹，便于复盘。
• 高风险任务要引入人工复核。
• 报告不只给总分，还要给失败分类和可行动建议。

一句话总结：

好的评测平台不是跑榜工具，而是模型变更的发布门禁和线上质量反馈系统。

复习清单

面试前确认自己能回答这些问题：

• 能否按能力维度列出主流 benchmark？
• 能否解释 MMLU、GPQA、GSM8K、HumanEval、SWE-bench、IFEval、Arena 分别测什么？
• 能否说清 Pass@k、Elo、LLM Judge、数据污染？
• 能否批判性分析榜单为什么不等于真实业务效果？
• 能否设计一个企业 RAG 或 Agent 的评测集？
• 能否把评测接入 CI、灰度和线上 bad case 回流？
• 能否解释为什么评测要同时看质量、安全、成本、延迟和业务指标？

如果这些问题都能讲清楚，你就不是在背 benchmark 名字，而是在用评测思维做大模型工程。