在 11.1 节中，我们梳理了 MMLU、CEval 等通用评测基准。这些“综合卷”能快速筛出模型的通用知识储备和基础推理水平，但在实际落地时，一个模型通识考试拿了 90 分，并不意味着它能写好一段工业级代码、开出一张合规处方，或者判断一份合同里的违约责任是否成立。
垂直领域评测的核心价值，在于把模型从“通才考场”拉进“专科手术室”。不同领域对“正确性”的定义截然不同：代码要能编译运行，医疗要兼顾安全与循证，法律要精确援引条文，数学要验证中间推理步骤。本节聚焦四个高频落地场景，拆解各自的评测集、指标陷阱与工程化评估方法。
一、代码能力评测：从“语法正确”到“工程可用”
代码是 LLM 当前落地最成熟的垂直场景之一，但评测难度远高于“看起来对”。
1.1 主流基准与分工
| 基准 | 核心测什么 | 关键指标 | 实用要点 |
|------|-----------|----------|----------|
| HumanEval | 手写函数级代码（164 道 Python 题） | Pass@k | 最经典的“入门级”代码基准，但题量小、语言单一，已接近饱和 |
| MBPP（Mostly Basic Python Problems） | 更接近真实需求的 Python 编程 | Pass@k | 描述更自然，适合测模型对模糊需求的理解 |
| MultiPL-E | HumanEval/MBPP 的多语言扩展（C++/Java/JS/Go 等） | Pass@k | 若你的业务不是纯 Python，必须加测此项 |
| LiveCodeBench | 随时间更新的代码题（防数据污染） | Pass@k / 覆盖率 | 训练数据截止日期后的新题，能检验模型是否真懂编程逻辑而非背题 |
| SWE-bench | 真实 GitHub Issue 修复（端到端软件工程） | 解决率 | 要求模型在真实代码库中定位 Bug、修改文件、通过单元测试，是目前最接近“程序员日常”的硬核基准 |
1.2 评测指标的工程真相
Pass@k：生成 k 个候选答案中至少有一个通过测试的概率。行业通常报 Pass@1（一次生成即对）和 Pass@5/10（多次采样后对不对）。
陷阱警示：很多技术报告只报 Pass@10 甚至 Pass@100，配合高采样温度，数字好看但对实际产品意义有限——生产环境的 Copilot 类产品通常只给用户一个首推荐（Pass@1）。
可执行性 ≠ 正确性：模型可能生成一段能编译但逻辑错误的代码；也可能生成一段逻辑对但缺少依赖导入的代码。评测时必须运行在隔离沙箱（如 Docker）中，真实执行单元测试，而不能只做静态语法检查。
1.3 给开发者的建议
- 如果你做 AI 编程助手，除了 HumanEval，必须自建私有代码库评测集：用你们公司内部的框架、私有 API 和编码规范出题，公开基准的高分在这里可能归零。
- 关注 Context Length 利用率：SWE-bench 类任务往往涉及数千行代码上下文，模型能否在“大海捞针”中定位关键函数，比单纯写小函数更能反映工程价值。
二、医疗能力评测：在“答对”与“不答”之间走钢丝
医疗领域对 LLM 的要求是双重底线：既要具备扎实的医学知识，又要在不确定时果断拒绝回答，避免给出有害建议。
2.1 主流基准与维度
| 基准 | 语言 | 侧重能力 | 注意事项 |
|------|------|----------|----------|
| PubMedQA | 英文 | 生物医学文献理解（问答） | 基于 PubMed 摘要的 Yes/No/Maybe 判断，测科研文献理解 |
| MedQA / MedMCQA | 英文 | 医学执业考试选择题 | 类似美国/印度医师执照考试，选项通常 4–5 个，测知识广度 |
| CMB（Comprehensive Medical Benchmark） | 中文 | 覆盖执业医考、医学考研、临床案例分析 | 中文医疗模型的必测项，含单选、多选、开放式问答 |
| CMExam / MLEC-QA | 中文 | 中国执业/主治医生考试真题 | 数据更接近中国临床实际 |
| 鉴别诊断与用药安全评测 | 多语言 | 临床决策支持（CDS） | 多为研究型数据集，测试模型是否能根据症状给出合理鉴别诊断，并识别禁忌用药 |
2.2 医疗评测的特殊维度
准确率之外，必须测“安全拒绝率”：
在通用评测中，模型“尽力回答”是加分项；但在医疗场景中，面对超纲问题（如“我该吃多少片安眠药”）、非专业边界问题（如需要影像/化验结果才能判断的疾病），模型应明确拒绝或建议就医。目前这一维度缺乏统一公开基准，需要企业自建红队测试集。
时效性与证据等级：
医学指南更新快（如高血压用药标准、肿瘤 NCCN 指南版本）。评测时要关注模型是否引用了过时的治疗方案。部分先进评测方法开始要求模型给出证据等级（如“基于 2023 AHA 指南”），但这目前仍依赖人工评判。
2.3 给开发者的建议
- 不要只看选择题准确率。执业医师考试 80% 分可能 impressive，但剩下的 20% 错误若涉及禁忌症，代价不可接受。
- 落地医疗场景时，建议采用 “LLM + 医学知识图谱/检索” 的混合架构，评测也应覆盖RAG 链路的端到端准确性，而非仅测基座模型。
- 中文医疗务必测 CMB + CMExam，并引入临床专家人工评审，因为医学术语的中英文语境差异极大。
三、法律能力评测：记忆、推理与援引的三重考验
法律领域的核心挑战是逻辑严密性与法条精确性并存。一个模型能把案情说得头头是道，但援引了已废止的法条，在实际业务中就是灾难。
3.1 主流基准与分工
| 基准 | 语言 | 核心测什么 |
|------|------|-----------|
| JEC-QA（国家司法考试真题） | 中文 | 中国法律职业资格考试选择题，覆盖民法、刑法、诉讼法等 |
| LawBench | 中文 | 中国法律领域的综合能力评测，包括法条记忆、案例推理、判决预测、司法考试题 |
| LegalBench | 英文 | 美国法律场景，涵盖合同分析、法规解释、判例推理 |
| COLIEE | 多语言 | 法律信息抽取与案例检索，测信息检索与匹配能力 |
| LexGLUE | 英文 | 法律自然语言理解综合基准（类似法律版 GLUE） |
3.2 法律评测的关键指标
法条援引准确率：在开放式问答中，要求模型明确写出依据的法条编号（如《民法典》第 1165 条），然后人工或自动比对是否真实存在、是否适用当前案情。这比单纯判断“说得通”要严格得多。
推理可解释性：法律领域通常要求“结论 + 要件分析 + 法条依据”三段论结构。评测时不仅看最终选项对不对，还要看推理链条是否符合法律逻辑（大前提、小前提、结论）。
时效性陷阱：法律修订频繁（如中国《公司法》2023 年大修）。旧题库中的正确答案，今天可能已因法条变更而错误。评测集必须定期更新，或至少标注所依据的法律版本。
3.3 给开发者的建议
- 做合同审查类产品时，不要只跑 LawBench 选择题。建议自建真实合同条款抽取与风险识别测试集，测模型能否在 20 页合同中定位“不对称管辖权条款”或“自动续约陷阱”。
- 法律模型建议加测 幻觉率（见 11.5 节）：编造不存在的法条、虚构判例是法律 LLM 的高频风险点，需专项打击。
四、数学能力评测：结果对 ≠ 过程对
数学是检验模型严格逻辑推理的试金石。不同于文学生成可以“大致对就行”，数学要求每一步都精确可验证。
4.1 主流基准与分工
| 基准 | 难度/阶段 | 核心测什么 | 关键特点 |
|------|-----------|-----------|----------|
| GSM8K | 小学数学应用题 | 多步算术推理 | 11.1 节已提及，最经典的“思维链”测试场，要求 8 步左右推理 |
| CMath | 中国小学数学（中文） | 中文语境下的算术与初等数学 | 若面向国内教育场景，必须加测，避免英文模型在中文数学题上因表述差异失分 |
| MATH | 高中竞赛级数学 | 代数、几何、数论、组合、微积分 | 5 选 1 或开放式，难度显著高于 GSM8K，是区分顶尖模型的分水岭 |
| SVAMP | 小学数学（变体） | 对问题表述扰动的鲁棒性 | 改变叙事结构但保持数学本质，测模型是否真正理解题意而非套模板 |
| MiniF2F / LeanDojo | 形式化数学 | 用 Lean 等形式化语言证明定理 | 最前沿方向，测模型能否生成可被严格验证的形式化证明 |
4.2 数学评测的核心指标
答案准确率（Accuracy）：最常用。对选择题可直接比对；对开放式题需提取最终数字/表达式与标准答案比对。
过程可验证性：这是数学评测区别于其他领域的关键。业界开始采用 MATH 的步级标注或 PRM（Process Reward Model） 方法，对中间步骤打分。一个模型最终答案对了，但中间过程胡编（如“因为 3+5=9，所以…”），在严格评测中应被降权。
工具使用能力：允许模型调用 Python/计算器时（如 GSM8K + Code），要分别测纯推理和工具辅助两种模式，避免把“代码执行正确”误当成“模型数学好”。
4.3 给开发者的建议
- 教育类应用务必区分“诊断”与“解题”：评测时不仅看能不能做对，还要看能不能指出学生错在哪一步。这需要更细粒度的过程评测，而非只看最终答案。
- 中文数学场景，GSM8K 翻译版 + CMath 混合测试更可靠。纯英文基准高分，不代表能处理好“甲乙两人相向而行”这类中文应用题表述。
五、垂直评测的共性陷阱与规避方法
无论哪个领域，做专项评测时都要警惕以下四个坑：
1. 数据污染（Contamination）
公开基准题极大概率已混入模型的预训练语料（尤其是 GitHub、考试真题、竞赛题）。看到 95% 以上的 HumanEval 或 GSM8K 得分，应保持警惕。缓解方法：
- 使用 LiveCodeBench、动态更新的私有题；
- 对公开基准做改写和变体（如改变数值、变量名、案情细节）；
- 查看模型技术报告中是否报告了污染检测方法。
2. 指标单一化
只报一个准确率容易掩盖结构性缺陷。建议至少组合：
- 总体准确率 + 分难度/分子领域准确率（如法律分民法/刑法，数学分代数/几何）；
- 拒绝回答率（医疗、法律尤其重要）；
- 幻觉率（编造法条、编造医学指南、数学过程胡编）。
3. 静态题库的局限
真实世界的问题会不断演化。建议每季度用领域专家新命题补充评测集，保持压力测试的时效性。
4. 评测与落地的脱节
基准测试通常是“单轮、干净输入、标准答案”；而真实业务是“多轮对话、模糊输入、边界开放”。务必在通过基准筛选后，再做端到业务场景的人工评估。
六、小结
垂直领域评测是通用基准确认“能用”之后，判断“敢用”和“好用”的分水岭：
- 代码：看 Pass@1 和真实工程任务（SWE-bench），而非只看语法；
- 医疗：在准确率之上，必须锚定安全拒绝能力与证据时效；
- 法律：记忆法条只是起点，精确援引、推理可解释性和法条时效才是命门；
- 数学：结果正确是底线，过程可验证才是区分“真推理”与“模式匹配”的试金石。
在 11.3 节中，我们将从“能力”转向“品性”，讨论如何评测模型的安全性、有用性与诚实性——这些维度不直接对应某个垂直业务指标，却决定了模型能否在开放环境中被人类信任。