直接回答:建立自己的大模型评测集,应从真实任务和真实失败开始,先定义成功标准,再选择程序校验、单元测试、人工评分或模型裁判。第一版不需要几千道题:50到100条覆盖高频与高风险任务的样本,往往比大而泛的公开题库更能指导选型和回归。[1][2]
资料核验日期:2026-08-05。该选题要求建立并运行真实评测集;完成原始数据和评分校准后再发布实测结果。

核心结论
- 评测对象是完整工作流。记录模型、提示词、工具、参数和产品入口。
- 真实任务优先。公开基准只能补充,不能替代业务样本。
- 多指标而非单总分。质量、严重错误、成本和延迟要一起看。
- 自动评分按任务选择。能程序校验的不要全部交给模型裁判。
- 保存原始输出和失败案例。只有分数无法定位问题。
评测集应该来自真实任务,而不是网上抄题
最有价值的样本来自客服工单、内容编辑、代码Issue、合同字段、研究问题和工具调用失败记录。公开基准可以补充通用能力,但不能代表你的业务。HELM的核心原则是覆盖多个场景、使用多指标并控制评测条件,同时明确尚未覆盖的部分。[1][2]
评测集的最小数据结构
| 字段 | 说明 |
|---|---|
| case_id | 稳定唯一编号 |
| task_type | 分类、抽取、写作、代码、研究等 |
| input | 完整输入与附件引用 |
| constraints | 格式、禁止项、工具和时限 |
| reference | 参考答案、关键点或通过条件 |
| risk_level | 低、中、高风险 |
| grader | 程序、人工或模型评分方式 |
| metadata | 来源、语言、日期、版本 |
自动评分有哪几类?
| 评分器 | 适用任务 | 注意事项 |
|---|---|---|
| 精确匹配/正则 | 分类、固定字段 | 对同义表达不友好 |
| Schema/程序校验 | JSON、工具参数、计算结果 | 只能验证结构和规则 |
| 单元测试/执行测试 | 代码、SQL、工作流 | 需要安全沙箱 |
| 相似度指标 | 翻译、摘要的辅助评估 | 不等于事实正确 |
| 模型裁判 | 开放写作、成对比较 | 会有偏差,必须人工校准 |
| 人工评分 | 高风险与主观质量 | 成本高但不可完全替代 |
从50条样本开始
- 收集过去30天最常见的真实任务。
- 按频率与风险挑选50条。
- 为每条写清“什么算成功”。
- 先让两名人工独立评分一部分样本,统一标准。
- 能程序化的先程序化,剩余任务再使用模型裁判。
- 保存所有原始输出,不只保存总分。
模型裁判为什么必须校准?
模型裁判可以按自定义标准进行点式或成对评分,Google和OpenAI都提供相关评测能力。[3][4] 但裁判可能偏好更长的回答、自己的写作风格或特定模型。至少应抽样人工复核,测试位置交换、匿名模型名和重复评分一致性。
评测集如何持续更新?
- 线上严重错误必须进入回归集;
- 按月补充新任务,但保留稳定核心集;
- 防止评测答案泄漏到生产提示词;
- 对版本、模型、提示词和工具分别编号;
- 旧样本失效时标注原因,不要静默删除。
结果怎么呈现?
不要只给一个总分。至少按任务类型、风险、语言和错误类型分组,展示任务成功率、严重错误率、成本、延迟和人工偏好。总分只用于快速浏览,原始样本和失败案例才是改进依据。
一个评测样本的完整示例
| 字段 | 示例 |
|---|---|
| 任务 | 从合同中提取付款日期、违约金和自动续约条款 |
| 输入 | 固定版本PDF与OCR文本 |
| 成功条件 | 字段完整、数字与原文一致、提供页码引用 |
| 自动评分 | JSON Schema、日期格式、金额精确匹配 |
| 人工评分 | 条款含义是否正确、是否遗漏限制条件 |
| 风险 | 高;结果不得直接替代法律审查 |
评测集质量检查
- 是否覆盖高频、低频但高风险和历史事故样本;
- 参考答案是否由领域人员确认;
- 不同样本是否重复或答案泄漏;
- 评分规则能否让两名评审得到接近结果;
- 附件、链接和外部数据是否仍然可访问;
- 是否明确哪些能力尚未覆盖。
评测集不是一次性文件,而是产品质量系统的一部分。每次线上事故、用户投诉和业务规则变化,都可能触发新增或更新样本。
评测集的版本管理
建议使用“eval-v1.0、v1.1”这类版本,并为每次变更写明新增样本、删除样本、评分规则变化和原因。核心样本应长期保留,用来判断模型与提示词是否持续进步;临时热点样本可以设有效期。每次报告必须绑定评测集版本,否则不同日期的分数不能直接比较。
防止数据泄漏与过拟合
- 不要把全部评测参考答案写进生产系统提示;
- 保留一部分隐藏测试集,只用于发布前验证;
- 定期加入新失败样本,避免只优化旧题;
- 模型裁判的评分提示也要版本化;
- 对异常高分进行人工抽查,确认没有利用答案格式漏洞。
评测报告应包含失败样本
只展示平均分和成功案例,会让团队忽略真正需要修复的问题。每次报告至少列出最严重的十个失败样本、错误分类、业务影响、是否可自动检测和下一步责任人。评测的目标是改进系统,而不是制造一个好看的排行榜。
常见问题
需要多少条评测样本才够?
MVP可从50条开始;正式采购或高风险系统需覆盖更多任务、边界和长期变化。
参考答案必须只有一个吗?
不一定。开放任务可以使用关键点、禁止项、评分量表和成对偏好。
能否让被测模型自己评分?
不建议作为唯一裁判。应使用独立评分器并进行人工校准。
每次模型更新都要跑全部样本吗?
核心回归集应全部运行;大规模或低频样本可分层定期运行。
文章局限
- 模型裁判与自动指标都可能偏离真实用户价值,高风险样本必须人工复核。
- 本文给出评测集设计方法,不提供当前模型排名。
参考来源
- Stanford CRFM:HELM框架(核验于 2026-08-05)
- HELM论文:Holistic Evaluation of Language Models(核验于 2026-08-05)
- Google Cloud:Gen AI Evaluation Service API(核验于 2026-08-05)
- OpenAI API:Graders(核验于 2026-08-05)
更新记录
- 2026-08-05:首次整理并核验官方或一手资料,建立可复用流程与检查清单。
© 版权声明
文章版权归作者所有,未经允许请勿转载。