AI 评测系列（07）：自建 Benchmark——从业务需求到评测集

作者：袖梨 2026-07-29

公开 Benchmark 无法满足需求的三类情况

MMLU、HELM、BIG-Bench 评估的是通用能力，并不覆盖你的业务场景。以下三种情况需要进行自定义：

情况 1：业务场景非常特殊

以企业汽车售后知识库问答系统为例，用户可能会问大众迈腾 B8 车型 2023 款的 DSG 变速箱保修期是多少。这类问题没有任何公开 Benchmark 能够覆盖，因为领域专业度、客户提问方式和答案格式都具有企业自身特点。

情况 2：数据禁止出域

由于医疗、金融和政务场景的评测数据含有敏感信息，无法上传至第三方评测平台，因此评测集必须在内部完成构建与运行。

情况 3：质量变化需要持续监控

公开 Benchmark 属于静态评测，运行一次即结束；自定义 Benchmark 则能持续加入新问题、更新 ground_truth，并追踪模型或知识库每次变更之后的质量 Delta。

建设流程

Step 1：确定评测场景

首先明确这个 Benchmark 需要覆盖的用户意图，不必尝试囊括所有可能出现的问题。

以企业文档问答为例，可采用以下典型场景分类：

# eval_scenarios.yamlscenarios:- id: S01name: 事实查询description: 用户问文档中明确存在的事实examples:- "退款政策是什么？"- "产品质保期多长？"target_metric: Faithfulness (答案不能超出文档内容)- id: S02name: 流程指引description: 用户询问如何完成某个操作examples:- "怎么申请发票？"- "如何修改收货地址？"target_metric: Answer Relevancy + Completeness- id: S03name: 比较判断description: 用户需要比较多个选项examples:- "普通配送和快递配送有什么区别？"- "黄金会员和铂金会员的区别？"target_metric: Context Recall (两个选项的信息都要检索到)- id: S04name: 边界测试description: 知识库中没有答案的问题examples:- "你们支持加密货币支付吗？"（实际不支持）target_metric: Rejection Rate (拒答而不是幻觉)

一个实用的 Benchmark 通常覆盖 4-8 个场景，每个场景 10-20 个问题，总量 50-150 个。太少不统计显著，太多构建成本高。

Step 2：产出问题

方法 A：由人工编写（准确度最高，成本也最高）

优点：覆盖真实用户问法，无数据污染风险缺点：慢，每道题需要领域专家审核适合：高安全要求场景，评测集 < 50 题

方法 B：通过LLM 生成 + 人工审核（推荐）

QUESTION_GEN_PROMPT = """根据以下文档内容，生成 {n} 个测试问题。要求：- 问题要模拟真实用户的问法，使用自然口语- 覆盖以下场景类型：{scenarios}- 不要问文档中没有答案的问题（边界测试除外）- 不要重复问同一个信息点文档内容：{document}输出格式（每行一个问题）：1. [问题]2. [问题]..."""

生成后人工做两件事：

把存在歧义、语法错误或重复等明显问题的题目过滤掉
进行抽样验证：随机抽取 20% 的问题，核实知识库内确实存在答案

方法 C：挖掘生产日志（真实性最高）

系统已经投入运行时，最有价值的来源是从真实用户查询中取样，因为这些内容确实是用户提出的问题，并非我们的主观猜测。

# 从 Langfuse 或应用日志采样def sample_from_production_logs(logs, n=100):"""采样生产日志中的真实用户查询作为测试问题"""# 去重（相同问题只保留一个）unique_queries = deduplicate(logs)# 按场景类型分层采样stratified = stratified_sample(unique_queries, n)return stratified

Step 3：准备 ground_truth

ground_truth 的质量直接决定评测的可信度。

不合格的 ground_truth（表述过于模糊）：

问题：退款政策是什么？ground_truth：可以退款

合格的 ground_truth（内容足够具体，并与 FAQ 对齐）：

问题：退款政策是什么？ground_truth：购买后 7 天内可全额退款，7-30 天退 50%，30 天后不退款。退款申请需在订单详情页提交，处理时间 3-5 个工作日。

ground_truth 的编写规范：

直接摘引文档原文，不进行改写或概括
写入数字、名词等明确细节，因为它们是 Faithfulness 评测的重要锚点
问题存在多个正确答案时，应将其全部写入
边界测试对应的 ground_truth 写为该信息在知识库中不存在

Step 4：划分难度层级

通过难度分层，可以判断系统在哪个难度级别发生问题，其价值高于单独观察一个通过率数字。

划分为三个难度层：

Easy（应该接近满分）：单文档、单段落能直接找到答案例：问题和答案在同一个 chunk 里，直接检索就能命中Medium（评测真实能力）：需要整合同文档的多个段落，或者答案表述与问题用词差异较大例：问题用"申请发票"，文档里用"开具发票凭证"Hard（暴露系统瓶颈）：需要跨文档推理，或者隐式推断，或者边界情况例："购买了 A 和 B 两个产品，分开退款和合并退款哪个合算？"

初始难度的分配方法：

先运行全部问题，再依据系统的实际表现校准难度：通过率高的问题划入 Easy，通过率低的问题划入 Hard，处于中间的划入 Medium。不要凭直觉判断哪一道题属于 Hard。

def calibrate_difficulty(eval_results: list[dict]) -> dict:"""根据实际通过率校准难度"""for result in eval_results:score = result["avg_score"]if score >= 0.85:result["difficulty"] = "Easy"elif score >= 0.60:result["difficulty"] = "Medium"else:result["difficulty"] = "Hard"return eval_results

Step 5：版本管理

评测集需要版本控制，原因是：

防范标准漂移：一旦 ground_truth 被悄然修改，例如发现这道题写错了便改一下，历史数据就会失去可比性
记录问题集的演变过程：包括新增和删除了哪些问题，以及变更原因
提供回溯能力：能够使用旧版本评测集检验旧版系统

# eval_dataset_v1.2.yamlmetadata:version: "1.2.0"created_at: "2026-06-01"last_updated: "2026-07-01"total_questions: 52breakdown:easy: 20medium: 22hard: 10changelog:v1.2.0:- added 5 questions covering new payment method (Apple Pay)- updated ground_truth for Q023 (refund policy changed)v1.1.0:- calibrated difficulty based on 1000-run baseline- removed 3 duplicate questionsquestions:- id: Q001scenario: S01difficulty: Easyquestion: "退款政策是什么？"ground_truth: "购买后 7 天内可全额退款，7-30 天退 50%，30 天后不退款。"added_in: "1.0.0"last_updated: "1.0.0"

版本号规则：

MAJOR：场景结构重大变化（删除了某个场景类别）MINOR：新增问题，或修改了问题的 ground_truthPATCH：修改元数据、注释、格式，不影响评测结果

评测集质量检查

正式使用评测集前，需要完成以下检查：

问题质量：□ 每道题都有唯一的正确答案？（避免主观题）□ 问法多样，不全是"X是什么"格式？□ 没有 leading question（问题里已经给出答案暗示）ground_truth 质量：□ 直接来自文档，没有概括改写？□ 包含足够的具体细节（数字、名词）？□ 边界测试的 ground_truth 明确标注"知识库中不存在"？难度分布：□ Easy 比例不超过 50%（防止整体数字虚高）□ Hard 比例不低于 15%（能暴露真实问题）□ 难度来自实际表现校准，不是主观判断？覆盖度：□ 每个场景（S01-S04）都有至少 5 道题？□ 包含边界测试（知识库中无答案）？□ 生产日志里的高频问题有覆盖？