开源评测框架是怎么用的？机制细节全梳理

想给一批大模型跑横评，手搓脚本费时费力，开源评测框架把跑题、判分、汇总的流程打包好了。本文按机制细节梳理它的用法：装环境、选题集、配判分、出报告，四步各自有什么讲究。

一句话定位：框架负责流程与复现，题目和判分标准仍要你自己把关，工具不替你做判断。

用框架之前先想清楚一件事：框架解决的是「跑得稳、跑得省」，它不负责判断题目好坏、分数该信几分。把这两件事分开，工具才用得顺手，也才不会把框架当裁判。

第一步：环境与配置

主流框架基本都支持本地部署，按文档装好运行环境，把待测模型的接口地址、并发数、超时策略写进配置文件。比如把豆包接口和 Kimi 接口写进同一份配置，方便对跑。并发与超时要按接口的实际承受力设置：并发过高触发限流，超时设太短正常作答被判失败，都会造成大面积假性低分。配置文件要进版本管理，跑完的每一份分数都能追溯到当时用的哪份配置，这是复现性的底线。

第二步：题集怎么喂

框架一般按固定格式吃题集：题目、参考答案、判分方式、分组标签。自攒的题转成标准格式入库；官方内置题集属于固定集，长期沿用会被针对性优化，取舍见固定集和动态集有什么区别，其来源与授权操守在评测自身的伦理问题里也有讨论。格式转换写个校验脚本：字段缺失、编码错误、答案为空的题在入库前拦下，别等跑批时才发现一半题喂不进去。

第三步：判分规则配置

客观题用规则判分，命中要点或通过测试用例即得分；开放题走模型判分或人工判分，框架通常留好接口。机判要用固定提示词模板并锁定参数，判分模型的输出格式要校验，防止解析失败悄悄变成零分。两种判分方式的分工差异，可对照人评和机评有什么区别。判分先在小样本上试跑一轮，把机判结果与人工判的二十来份答案对一遍，偏差在可接受范围再上全量。

第四步：跑批与出报告

先小批量试跑验证链路，再全量跑批；报告除了总分，保留每题明细与运行日志。多语言题集要逐语言单列成绩，口径见多语言评测是怎么保证公平的；日常迭代把跑批挂进定时任务，接入方法见评测自动化是怎么搭的。报告里留两样东西：原始输出与判分依据，前者方便复查，后者让看报告的人知道每分怎么来，省掉大量来回解释。

三个常见坑

第一坑是版本漂移：框架和依赖库更新后，同一配置跑出的分数可能变化，锁版本并在报告里记下环境信息能省掉大量扯皮。第二坑是超时与截断：生成长文本时接口超时被记成空答案，分数被低估，重试策略要写进配置。第三坑是并发过高触发限流，跑批中途大面积失败却只看到分数下滑。上线前用小批量验证一遍链路，比事后排查便宜。框架的扩展点也别乱改，插件化的判分脚本要跟主程序一起纳入版本管理。

开源框架上手速查

• 配置文件进版本管理，可追溯
• 题集转标准格式，内置题集核对授权
• 机判模板与参数锁定，输出格式校验
• 先小批量试跑，再全量出报告

带一句实操建议：选框架先看判分接口的灵活性，再看题集格式是否顺你的数据结构，最后看社区活跃度，顺序反了容易返工。另外留意框架的更新节奏，长期不维护的项目谨慎引入，出问题没人管。

开源评测框架快问快答三则

• 框架选型看什么？：先看判分接口灵活度与题集格式，再看社区活跃度，功能清单漂亮不等于合手。
• 内置榜单分数能直接对比吗？：同框架内可比，跨框架要核对判分规则与题目版本，否则差值没有意义。
• 机判结果偏差大怎么办？：先抽人工复核定位偏差题型，再改判分模板，必要时该题型改回人工判。