1. 为什么“私有题库测评”这件事值得认真做大模型评测这件事公开榜单已经多到看不过来。MMLU、C-Eval、GSM8K、HumanEval每隔几周就有新榜单冒出来分数也一路水涨船高。但真正在企业里落地过模型选型的人都知道公开榜单的参考价值其实相当有限——它测的是“通用能力”而你要解决的是“我的业务场景下这个模型到底行不行”。私有题库测评说白了就是自己出题、自己判卷、自己排名。听起来很土但它是目前唯一能回答“哪个模型最适合我的场景”这个问题的办法。公开榜单告诉你模型会不会做高中数学题私有题库告诉你模型能不能准确识别你公司合同里的关键条款、能不能按你的格式要求输出工单分类、能不能在你那套黑话体系里不胡说八道。这套东西适合谁三类人最需要一是做模型选型的技术负责人二是要给业务方交付“为什么选A不选B”结论的算法工程师三是想持续监控线上模型效果有没有退化的运维同学。如果你只是好奇哪个模型聊天更聪明公开榜单够用了但如果你要为一个真实业务负责私有题库是绕不过去的。我前后搭过三套不同规模的私有测评体系从最初几十道题的手工表格到后来覆盖六个业务域、上千道题、自动跑分的流水线。踩过的坑不少也总结出一些公开文档里不会写的经验。下面按“设计思路—题目建设—执行流程—问题排查”这条线把整套方法拆开讲。2. 测评体系整体设计与选型思路2.1 先想清楚“测什么”再想“怎么测”很多人一上来就纠结用哪个评测框架、要不要上自动化平台这是本末倒置。私有题库的核心资产是题目和评分标准工具只是载体。我见过团队花两周搭了一套漂亮的评测流水线结果题库里只有五十道从网上抄来的选择题测出来的结论毫无决策价值。正确的顺序是反过来的先明确业务场景需要模型具备哪些能力再把这些能力翻译成可判分的题目最后才考虑用什么工具跑。工具选型的原则很简单——能自动化就自动化不能自动化的部分老实人工判不要为了“全自动”而牺牲评分准确性。具体来说我会先把业务需求拆成几个能力维度。比如一个客服场景至少涉及意图识别准确率、多轮对话的上下文保持、敏感问题的拒答边界、回复格式的稳定性。每个维度对应一批题目每个维度有独立的评分标准。这样最后出来的不是“模型A得82分”这种没用的总分而是“模型A在意图识别上强于B但在格式稳定性上明显弱于B”这种能直接指导决策的结论。2.2 评分方式的选择客观题、主观题、还是混合题目类型直接决定评分方式也决定整套体系的成本结构。客观题选择题、判断题、填空最大的好处是判分零成本、零争议适合大规模快速筛选。但它的致命缺陷是容易被“应试”——模型可能只是见过类似的题而不是真的具备能力。而且客观题很难覆盖开放式生成场景而后者恰恰是大多数业务真正需要的。主观题开放问答、长文本生成、代码实现更贴近真实场景但判分成本高。早期我们全靠人工打分一道题三个人独立评再取平均一天下来也就能评一百多道。后来引入“模型辅助评分”——用一个评分标准明确的强模型先打初稿人工只做复核和边界case处理效率提升了大概五倍。这里的关键是评分标准必须写得极其具体比如“回复中必须包含订单号、退款金额、预计到账时间三个要素缺一个扣一分”而不是“回复是否专业”这种没法执行的描述。我的建议是混合使用用客观题做初筛把明显不达标的模型淘汰掉剩下的候选模型再用主观题做精细对比。这样既控制了成本又保证了结论的可信度。2.3 题库规模与覆盖度的平衡题库是不是越大越好不是。我见过有人攒了上万道题结果跑一次测评要三天而且题目之间大量重复边际信息量极低。比较合理的规模是每个能力维度至少30道题核心维度50到100道。这个量级下单模型跑完一轮大概两到四小时取决于题目长度和模型响应速度既能保证统计上的稳定性又不至于让迭代周期长到无法接受。覆盖度上我遵循“二八原则”80%的题目聚焦核心业务场景20%的题目覆盖边缘case和对抗性输入。边缘case特别重要因为模型在常规输入上表现都差不多真正拉开差距的往往是那些“不太正常”的输入——错别字、中英混杂、超长上下文、故意诱导性的提问。注意题库不是建完就一劳永逸的。业务在变模型在更新题库必须定期维护。我一般每季度做一次题目审查淘汰过时的、补充新场景的同时检查有没有题目因为模型迭代而“失效”比如所有候选模型都能答对那这道题就没有区分度了。3. 核心细节解析与实操要点3.1 题目设计怎么出一道“好题”一道好的测评题核心标准是“有区分度”。如果所有模型都能答对或者所有模型都答错这道题就是废题。区分度怎么保证靠设计时的“难度梯度”。以意图识别为例我会把题目分成三档简单档是表述清晰、关键词明显的标准问法中等档是口语化、有冗余信息的问法困难档是包含干扰信息、需要结合上下文才能判断的问法。三档题目的比例大概是3:5:2。这样跑下来弱模型在中等档就开始掉分强模型能撑到困难档区分度自然就出来了。另一个关键是“标准答案”的制定。主观题的标准答案不能只写一个“参考答案”而要写成“评分细则”。比如一道要求模型总结会议纪要的题评分细则可能是必须包含三个决议事项每个2分、必须标注责任人每个1分、时间节点准确每个1分、语言简洁无冗余2分。这样即使两个人独立评分结果也能基本一致。3.2 评分标准把“感觉”变成“规则”主观题评分最大的坑是“凭感觉”。同一条回复上午评觉得不错给8分下午评觉得一般给6分这种波动会直接毁掉测评的可信度。解决办法是把评分维度拆到不能再拆。我通常用四个维度准确性内容对不对、完整性要素全不全、格式合规性符不符合输出要求、表达质量语言是否通顺专业。每个维度独立打分最后加权汇总。权重根据业务场景调整比如工单分类场景里准确性权重最高而营销文案场景里表达质量权重更高。评分标准还要明确“扣分项”和“一票否决项”。比如涉及安全边界的题目模型如果输出了不该输出的内容直接判零分不参与后续加权。这种硬性规则必须提前写死不能留给评分人临场判断。3.3 工具链选型够用就好别过度工程评测工具这块我的态度是“能用脚本解决就别上平台”。早期我用Python写了个几百行的脚本读题库CSV、调模型API、存结果到数据库、生成对比表格整套下来不到一天就搭好了稳定跑了半年。后来团队大了、题目多了才逐步引入一些轻量级的评测框架。选型时看三个点一是能不能方便地接入不同模型的API因为你要对比的模型肯定不止一个二是评分环节能不能灵活配置客观题自动判、主观题走人工或模型辅助三是结果能不能导出成结构化的对比表。有个细节容易被忽略并发控制和重试机制。跑大批量题目时API限流和偶发超时是常态。如果脚本没有重试逻辑跑一半挂了就得从头再来非常浪费时间。我的做法是每条题目记录一个状态字段待跑、成功、失败、重试中失败自动重试三次三次都失败就标记出来人工处理。这样即使中途中断也能从断点继续。3.4 数据隔离与结果可信度私有题库的“私有”二字意味着数据不能外泄。如果题库里包含真实业务数据那在调用外部模型API时就要格外小心。我的做法是敏感题目做脱敏处理后再入题库或者对敏感题目只跑本地部署的模型外部模型不参与这部分测评。结果可信度还涉及一个常被忽视的问题模型版本漂移。同一个模型服务商可能在你不注意的时候更新了底层版本导致分数变化。所以每次测评都要记录模型的版本号或调用时间戳否则前后两次结果没法对比。4. 实操过程与核心环节实现4.1 从零搭建题库的完整流程第一步是场景梳理。拉上业务方开一次会把模型要处理的任务类型列全每个任务类型标注优先级和调用量占比。这一步的产出是一张“能力清单”比如意图识别占比40%、信息抽取占比30%、回复生成占比20%、其他占比10%。第二步是题目编写。按能力清单分配题目数量然后由熟悉业务的同学出题。出题时要求每道题附带题目描述、输入内容、期望输出、评分细则、难度等级。这一步最耗时但绝对不能省。我的经验是一百道高质量题目两个人写一周差不多。第三步是题目评审。找另一个没参与出题的同学做交叉评审重点看题目表述有没有歧义、评分细则能不能执行、难度分布是否合理。评审通过后题目才正式入库。第四步是小范围试跑。选两到三个模型跑一遍看分数分布是否合理。如果所有模型分数都集中在90分以上说明题目太简单如果都在60分以下说明太难。根据试跑结果调整题目难度或评分标准。4.2 一次完整测评的执行记录拿最近一次测评举例候选模型有四个题库共320道题覆盖五个能力维度。整个流程分四步准备阶段确认题库版本、模型版本、评分标准版本三者都打上标签。这一步是为了保证结果可追溯。执行阶段用脚本并发调用四个模型的API每道题跑一次。这里有个细节——同一个模型对同一道题跑三次取平均分用来抵消模型输出的随机性。三次结果如果方差过大比如一次满分一次零分说明这道题对模型来说不稳定需要标记出来人工复核。评分阶段客观题自动判分主观题先用辅助模型打初稿再由人工复核。复核时重点关注两类一是辅助模型打分与人工直觉差异大的二是多个模型分数接近、难以区分的。汇总阶段生成对比表格包含每个模型在每个维度上的得分、总分、排名以及关键题目的逐题对比。表格之外还要写一段文字结论说明“推荐哪个模型、理由是什么、有什么风险”。4.3 参数计算与权重设定总分怎么算直接决定排名。我的做法是加权求和权重根据业务优先级设定。举个例子假设五个维度的权重分别是意图识别0.3、信息抽取0.25、回复生成0.25、格式合规0.1、安全边界0.1。每个维度满分100分那么总分就是各维度得分乘以权重再求和。权重的设定不是拍脑袋而是跟业务方一起定的。方法是让业务方对五个维度做两两比较排出优先级顺序再据此分配权重。这样定出来的权重业务方认账后续推结论时阻力小很多。还有一个细节安全边界维度我通常设成“门槛项”而不是“加权项”。也就是说安全边界得分低于80分的模型直接淘汰不参与总分排名。因为安全问题是零容忍的不能靠其他维度的高分来弥补。4.4 结果呈现让决策者一眼看懂测评报告不是给算法同学看的是给决策者看的。所以呈现方式要极度克制。我的报告结构固定为三页第一页是结论和推荐第二页是各维度得分对比表第三页是关键题目的逐题分析。对比表用颜色标注绿色表示该维度最优红色表示最差中间用黄色。这样即使不看具体数字也能一眼看出每个模型的强弱项。逐题分析只放那些“拉开差距”的题目也就是模型之间分差超过20分的题同分或接近的题不占篇幅。提示报告里一定要写“本次测评的局限性”。比如题库覆盖的场景有限、测评时间点的模型版本可能已更新、评分标准存在主观成分等。主动暴露局限性反而能增加结论的可信度。5. 常见问题与排查技巧实录5.1 模型输出不稳定怎么办同一个模型、同一道题跑三次给出三个不同答案这是最常见的问题。原因通常是模型的温度参数设置过高。解决办法是把温度调到0或接近0让输出尽量确定。如果业务场景确实需要一定的多样性比如创意生成那就在评分时取多次结果的平均分并在报告里注明“该维度存在随机性”。还有一种不稳定是“格式不稳定”——模型有时候输出JSON有时候输出纯文本。这种问题要在提示词里强制约束输出格式并且在评分时把格式合规性单独作为一个维度来扣分。5.2 评分标准执行不一致怎么排查人工评分时不同评分人对同一条回复给出差异很大的分数说明评分细则写得不够具体。排查方法是让两个评分人独立评同一批题然后对比差异。差异大的题目拿出来逐条分析看是细则哪里模糊补充说明后再重新评。如果用的是模型辅助评分那要检查辅助模型的提示词是否足够明确。我一般会在提示词里放两到三个“评分示例”让辅助模型照着示例的风格和尺度来打分。示例的选择很关键要覆盖高分、中等分、低分三种情况。5.3 题库泄露与污染的处理如果题库里的题目在网上出现过模型可能“背过答案”测出来的分数虚高。排查方法是把题目输入到一个明显没见过的模型里如果它答得异常好那这道题大概率泄露了。处理办法有两个一是把泄露的题目改写成新的表述二是直接淘汰。我倾向于直接淘汰因为改写后的题目可能仍然带有原题的“影子”区分度会下降。5.4 常见问题速查表问题现象可能原因排查方法解决措施所有模型分数都偏高题目太简单或已泄露检查题目难度分布用新模型试跑增加困难档题目淘汰泄露题所有模型分数都偏低题目太难或评分过严人工复核低分题看是否评分细则不合理调整评分标准补充示例同一模型多次跑分差异大温度参数过高检查API调用的温度设置温度调至0或取多次平均评分人之间分歧大评分细则模糊对比独立评分结果找出分歧题细化评分细则增加示例测评耗时过长题目过多或并发不足统计单题平均耗时检查并发数精简题库提高并发加缓存结果无法复现模型版本或题库版本未记录检查是否有版本标签每次测评记录模型和题库版本5.5 几个踩过的坑第一个坑是“用公开榜单的题目直接当私有题库”。早期我图省事从公开数据集中抽了一批题结果测出来的排名跟公开榜单几乎一样完全没有增量信息。私有题库的价值就在于“私有”题目必须来自自己的业务场景。第二个坑是“只测一次就下结论”。模型输出有随机性单次测评的结果可能受偶然因素影响。我的做法是至少跑三轮取平均分并且关注分数的波动范围。如果某个模型三轮分数波动超过10分那它的稳定性就值得怀疑。第三个坑是“忽略成本维度”。测评不只看效果还要看成本。同样效果的模型一个每次调用花一毛钱一个花一分钱那选谁不言而喻。所以我的报告里一定会加一列“单次调用成本”把效果和成本放在一起对比。第四个坑是“题库更新后没有重新基线”。题库改了之后之前的历史分数就不能直接跟新分数比了。每次题库大版本更新都要用新题库重新跑一遍所有候选模型建立新的基线。6. 持续运营与迭代建议私有题库测评不是一次性项目而是持续运营的工作。我现在的节奏是每月跑一次全量测评每周跑一次核心题目的快速回归。全量测评用于发现趋势快速回归用于及时发现模型退化。题库的迭代跟业务需求走。业务方提了新场景就先出十道题试跑看模型能不能覆盖如果能覆盖再扩充到三十道正式入库。这样题库始终跟业务保持同步不会变成一堆过时的“考古题”。还有一点经验测评结果要跟模型上线后的真实表现做对比。如果测评分数高但线上效果差说明题库跟真实场景有偏差需要调整题目方向。这个反馈闭环建立起来之后题库的预测能力会越来越准。最后分享一个实用技巧把每次测评的原始数据题目、模型输出、评分、评分人全部存档。这些数据积累起来之后可以做很多有意思的分析比如“哪些类型的题目最容易让模型翻车”“评分标准在哪些维度上最不稳定”。这些分析反过来又能指导题库的优化形成正向循环。