许清风1. 大模型评测集构建的核心挑战与解决思路
在构建大模型评测集的过程中，我们常常会遇到几个典型问题：样本混杂导致结论不稳定、标注口径漂移影响结果可靠性、线上目标与离线指标脱节等。这些问题往往不是模型本身的问题，而是评测集构建方法不当导致的。
我在实际项目中遇到过这样的情况：模型迭代了三版，Prompt调整了五轮，最终发现问题出在评测集上——离线评测分数高的方案，线上工单转人工率反而更高。根本原因在于评测集没有按照业务目标进行合理拆分，困难样本占比失真。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 业务目标拆解与评测维度定义
2.1 从业务目标到可执行评测维度
很多团队在构建评测集时犯的第一个错误就是直接从日志中抽取几千条数据就开始标注。这种做法虽然快速，但很难回答"这个模型对业务是否有实际帮助"这个核心问题。
我通常会先制作一张目标拆解表，以智能客服问答场景为例：
| 业务目标 | 对应评测问题 | 样本来源 | 指标类型 |
|---|---|---|---|
| 降低转人工率 | 是否能直接解决用户问题 | 历史会话、转人工工单 | 任务成功率 |
| 降低错误回答风险 | 是否出现事实性错误 | 风险工单、投诉样本 | 风险错误率 |
| 提升响应体验 | 输出是否简洁、可执行 | 高频问答、标准流程问题 | 响应质量分 |
| 提升召回效果 | 检索上下文是否覆盖答案依据 | RAG日志、知识库命中记录 | 证据覆盖率 |
关键经验：业务目标和模型能力不要混为一谈。比如"推理能力强"这种表述在评测集设计中很难落地，而"多条件退款规则判断是否正确"则非常明确。
2.2 定义可标注单元
将业务目标进一步拆解为可标注单元非常重要。例如"客服问答质量"这个概念过于宽泛，标注员很难统一标准。我们可以将其细化为：
- 是否回答了用户主问题
- 是否引用了错误规则
- 是否遗漏关键限制条件
- 是否输出了不可执行建议
- 是否暴露不该说的信息
只有细化到这个程度，评测维度才能真正进入数据构建阶段。
3. 评测单元设计与样本池构建
3.1 评测单元的结构设计
很多团队默认"一轮用户输入+模型回答"就是一条样本，这在单轮问答中可行，但在真实业务场景中往往不够。我建议先固定评测单元的结构，否则后续抽样、标注和统计都会出现问题。
对于通用LLM应用，我推荐以下JSON结构：
json复制{
"sample_id": "cs_000001",
"biz_scene": "refund_consult",
"user_query": "商品拆封后还能退吗？",
"dialog_context": [
{"role": "user", "content": "我上周买的耳机到了"},
{"role": "assistant", "content": "请问有什么问题？"}
],
"retrieved_context": [
"规则1：非质量问题，拆封后不支持7天无理由退货",
"规则2：质量问题需提供检测依据"
],
"reference_answer": "若为非质量问题，商品拆封后通常不支持7天无理由退货；若存在质量问题，可按售后流程申请处理。",
"meta": {
"source": "online_log",
"date": "2026-03-21",
"difficulty": "medium",
"risk_level": "high"
}
}
重要经验：字段设计不要贪多。我曾经在一个早期项目中塞入了20多个字段，结果标注员抓不住重点，标注一致性反而下降。精简到必需字段后，IAA（标注者间一致性）从0.62提升到了0.79。
3.2 样本池构建与处理
评测集如果只来自历史线上正常流量，通常会遇到两个问题：
- 样本过于"平均"，高频简单问题占比过高，模型差异被稀释
- 风险样本不足，而线上最容易出问题的恰恰是这些边