🔍 数据污染（Data Contamination）

指评测基准的题目（或高度相似的变体）出现在了模型的训练数据中。模型可能通过"记忆"而非"推理"来回答问题，导致基准分数无法反映真实泛化能力。研究表明，部分公开基准（如 GSM8K、MMLU）的题目已被广泛抓取并混入训练语料。

缓解措施：使用动态更新的基准（如 LiveBench）、构建闭源私有测试集、采用去污染检测工具（如 LMSYS 的 contamination detector）。

📐 过拟合风险（Overfitting）

当研发团队将基准表现作为优化目标时，可能通过调整训练数据、提示工程、或对模型进行针对性微调来"刷分"，但模型的真实通用能力并未提升。这与 Goodhart 定律吻合：一旦某个指标成为目标，它就不再是一个好的指标。

缓解措施：采用多基准交叉验证、引入未见过的私有评测集、结合人工评估进行校准。

📏 单一维度的局限

每个基准通常只测量有限的能力维度（如知识广度、数学推理），无法全面刻画模型的综合能力。此外，选择题格式天然存在猜测偏差（随机答对的概率），无法区分"真正理解"与"模式匹配"。

缓解措施：组合不同维度的基准形成评测矩阵，补充开放性生成任务评估，结合实际业务场景进行端到端评测。

🏦 银行场景的安全基准补充

除了上述通用安全基准，银行AI应用还应关注以下安全评测维度（详见本知识库的安全评测专题）：

• 数据泄露风险：模型是否会输出训练数据中包含的客户信息或内部文档内容。
• 合规拒答：对涉及理财建议、投资推荐、利率预测等受监管问题的恰当拒答。
• 价值观对齐：在金融场景下的伦理判断（如是否会给用户推荐超出承受能力的借贷产品）。
• 越狱攻击防护：通过提示注入等方式诱导模型输出违规内容的风险。

✅ 应优先使用公开基准的场景

• 模型选型的初期筛选：在候选模型较多（如 5-10 个）时，先通过公开基准快速筛选出 2-3 个候选者，再进入深度评测。
• 通用能力的横向对比：如知识广度（MMLU）、中文理解（C-Eval），这些维度公开基准已足够成熟和有区分度。
• 行业对标与汇报：需要向管理层或合作方展示"所选模型达到业界领先水平"时，公开基准提供了公认的参照系。
• 快速识别模型短板：如果某候选模型在 MATH 或 TruthfulQA 上得分异常低，可作为红线直接淘汰。

🏗️ 应投入自建数据的场景

• 业务知识准确性：公开基准无法涵盖银行的内部业务知识（如某银行的贷款产品条款、利率政策），必须自建领域知识评测集。
• 合规与安全评测：银行的合规要求有行业特殊性（如《商业银行法》、银保监会文件等），通用安全基准只能作为补充。
• 端到端场景评测：如"客户投诉处理"这种需要多轮对话、情绪识别、工单创建的复合场景，公开基准无法模拟。
• 防止数据污染：自建数据的闭源性天然避免了公开基准可能存在的训练数据污染问题，评估结果更可信。
• 持续回归评测：在模型上线后的每次更新中，自建评测集可作为回归测试套件，确保新版本不引入退化。

实战任务1：使用 lm-eval-harness 运行 MMLU 基准测试

场景：在本地环境中对开源模型运行标准化的 MMLU 评测

背景：lm-evaluation-harness 是 EleutherAI 开源的标准化评测框架，支持 200+ 基准测试。本任务以 MMLU（大规模多任务语言理解）为例，演示从安装到运行的全流程。

步骤：

1. 安装 lm-eval-harness：

# 创建虚拟环境（推荐）
python -m venv lmeval-env
source lmeval-env/bin/activate  # Windows: lmeval-env\Scripts\activate

# 安装 lm-eval
pip install lm-eval[all]

# 验证安装
lm_eval --help

2. 运行 MMLU 评测：以 HuggingFace 上的 Qwen2.5-0.5B 小模型为例进行快速验证

# 运行 MMLU（仅取前 3 个学科以节省时间）
lm_eval --model hf \
  --model_args pretrained=Qwen/Qwen2.5-0.5B \
  --tasks mmlu_anatomy,mmlu_astronomy,mmlu_econometrics \
  --device cuda:0 \
  --batch_size 8 \
  --output_path ./mmlu_results/

3. 查看结果：在 ./mmlu_results/ 目录下找到 JSON 结果文件，重点关注 results 字段中的各学科 acc,none（准确率）和整体平均分。
4. 进阶：将模型切换为其他 HuggingFace 模型（如 Qwen2.5-7B、LLaMA-3.2-3B），对比不同参数量模型在 MMLU 上的表现差异。

评估标准：成功运行并获取至少 3 个学科的评测分数，理解输出 JSON 结构

耗时：1.5 小时（含模型下载时间）

产出物：MMLU 评测结果 JSON 文件 + 简要评测记录

实战任务2：为银行场景构建简易评测数据集

场景：从 C-Eval 公开数据集中筛选金融相关题目，构建面向银行业务的定制评测集

背景：C-Eval 是一个覆盖 52 个学科的中文综合评测基准，其中包含会计学、经济学、金融学等与银行场景高度相关的学科。本任务教你如何从公开基准中提取并构建领域专属评测集，迈出从「通用基准」到「业务评测」的关键一步。

步骤：

1. 获取 C-Eval 数据：从 HuggingFace 下载 C-Eval 数据集

from datasets import load_dataset

# 加载 C-Eval 验证集
dataset = load_dataset("ceval/ceval-exam", split="val")
print(f"总样本数: {len(dataset)}")
print(f"学科列表: {dataset.unique('subject')}")

2. 筛选金融相关学科：选出会计学、金融学、经济学、税法等学科题目

# 定义金融相关学科
finance_subjects = [
    "accounting",      # 会计学
    "finance",         # 金融学
    "economics",       # 经济学
    "tax_law",         # 税法
    "business_admin"   # 工商管理
]

# 筛选题目
finance_dataset = dataset.filter(
    lambda x: x["subject"] in finance_subjects
)
print(f"金融相关题目数: {len(finance_dataset)}")

3. 格式化导出：转换为统一评测格式并保存

import json

# 转换为统一格式
eval_data = []
for item in finance_dataset:
    eval_data.append({
        "id": item["id"],
        "subject": item["subject"],
        "question": item["question"],
        "choices": [item["A"], item["B"], item["C"], item["D"]],
        "answer": ord(item["answer"]) - ord("A")  # 转为 0-index
    })

# 保存
with open("banking_eval_set.json", "w", encoding="utf-8") as f:
    json.dump(eval_data, f, ensure_ascii=False, indent=2)

print(f"银行场景评测集已保存，共 {len(eval_data)} 条")

4. 验证题目质量：随机抽查 10 道题目，人工确认题目相关性和答案正确性

评估标准：成功筛选 ≥100 条金融相关题目，导出的 JSON 格式规范、可直接用于评测

耗时：1 小时

产出物：banking_eval_set.json 数据集文件 + 数据处理脚本

实战任务3：分析评测分数——识别模型强弱项

场景：基于一组模型的评测得分，分析各模型的强弱项并给出选型建议

背景：以下是 5 个主流模型在 MMLU、GSM8K、HumanEval 三个基准上的得分（数据为 2025 年公开基准的近似参考值）。请据以分析，回答后续问题。

请分析以下问题：

1. 知识广度分析：哪两个模型在 MMLU（综合知识）上表现最强？这些模型适合承担什么类型的银行业务场景？
2. 数学推理分析：GSM8K 得分最高的模型与最低的模型之间差距是多少？对于银行场景中的利率计算、财务报表分析等任务，至少需要多高的 GSM8K 分数？
3. 代码能力分析：为什么 DeepSeek-V3 和 LLaMA-3.3 在 HumanEval 上得分明显低于 MMLU 和 GSM8K？这说明什么？银行场景中哪些任务需要代码能力？
4. 选型建议：如果为以下两个银行子场景选型，你会推荐哪个模型？请说明理由：
   • 场景A：智能客服（重知识广度 + 中文理解 + 安全性）
   • 场景B：自动化测试脚本生成（重代码生成能力 + 性价比）
5. 维度组合：仅凭 MMLU、GSM8K、HumanEval 三个基准能充分评估一个面向银行场景的模型吗？如果不能，还应补充哪些评测维度？

评估标准：分析逻辑清晰、选型建议有理有据、能识别基准的局限性并提出补充维度

耗时：1 小时

产出物：模型对比分析报告（含强弱项分析表 + 场景选型建议 + 补充评测建议）

📋 案例研究：用公开基准评估模型在银行场景的适用性

背景：某银行计划为智能客服系统选型大模型，候选模型为 DeepSeek-V3 和 Qwen2.5-72B。测试团队需在两周内给出选型建议。

评估方案：

• 选取 MMLU（知识广度）、GSM8K（数学推理）、C-Eval（中文理解）、TruthfulQA（安全性）四个基准
• 附加银行自建 20 题场景评测（含制度问答、业务推理等）

评估过程：

• 在 lm-eval-harness 上运行 4 个基准
• 记录各模型得分、推理延迟、API 成本
• 对比公开排行榜数据与实际测试结果

结果分析：

模型强弱项分析：

• DeepSeek-V3：知识广度和数学推理表现突出，适合复杂业务逻辑处理和数据分析场景；但中文理解（C-Eval）和安全性（TruthfulQA）相对薄弱，在中文客服对话中可能出现理解偏差或幻觉。
• Qwen2.5-72B：中文理解和安全性表现优秀，更适合面向终端客户的中文对话场景；知识广度和数学推理略逊于 DeepSeek-V3，但在可接受范围内。

选型建议：

• 质量优先方案：选用 DeepSeek-V3，其综合知识能力更强，在银行场景自测中得分更高（85.0 vs 80.0）。适合对回答准确率要求极高的核心业务场景。
• 成本优先方案：选用 Qwen2.5-72B，其中文理解能力更强，TruthfulQA 安全性更高，且通常推理成本更低。适合高并发的客服场景，在保证基本质量的同时控制成本。
• 混合方案（推荐）：简单 FAQ 类问题由 Qwen2.5-72B 处理，复杂业务推理问题路由至 DeepSeek-V3，兼顾质量与成本。

启示：

• 公开基准不能完全代表银行场景表现——DeepSeek-V3 在公开基准上全面领先，但 C-Eval 得分反而不如 Qwen2.5-72B，实际中文场景需重点考量。
• 必须附加场景化评测才能做出准确判断——银行自建的 20 题场景测试揭示了两个模型在真实业务环境中的差异。
• 评测过程本身是对团队能力的锻炼——从基准选型、环境搭建到结果分析，团队建立了完整的评测方法论，可复用于后续模型选型。