跑了一年多大模型的落地项目，我越来越认同一个判断：真正卡住AI应用落地的，往往不是模型本身的智商，而是“怎么看它到底行不行”这套评测机制。我们团队在AllData平台上集成了开源项目Coze-Loop，搭了一套大模型评测平台，核心目标就两个——把模型自动化测评跑起来，把效果量化评估落到指标上。
先说一下背景。AllData是我们一直在用的开源数据平台，覆盖数据集成、开发、调度、治理这些环节。Coze-Loop的定位比较独特，它不是又一个大模型推理框架，而是专门解决“评测流程怎么组织、怎么自动化、怎么持续回归”这件事。两者拼在一起之后，测评不再靠临时脚本和人工截图，而是变成一条从数据准备、模型推理、自动打分到报告归档的标准流水线。这篇文章就把我们落地的全过程、踩过的坑、设计取舍的经验完整记录下来。
1. 大模型评测的痛点：跑完分不敢上线的问题出在哪
1.1 人工评测的瓶颈比模型能力更早到来
很多人以为大模型落地最难的是模型能力不够，真做起来才发现，人工评测的瓶颈来得比模型能力早得多。早期我们每个版本迭代都要找业务专家人工看几十条case，从回答质量、语气、知识正确性多维度打分。一次评测动辄两三天，请三五个人评审，评到后面大家标准开始漂移，有人宽松有人严格，同一份答案在不同轮次评审里得分能差出二十分。
这还不算成本。业务专家本身有本职工作，每次评审都要占用他们时间，需求多了之后根本拉不动人。更重要的是反馈周期太长——模型微调迭代可能一天就完成了，评测却要等三天，等于整个优化闭环在评测环节被堵死。你会发现模型训练快不快已经不是主要矛盾了，“怎么快速判断这版模型到底有没有变好”反而成了卡脖子的问题。
1.2 碎片化评测带来的三种麻烦
没有平台化之前，我们团队内部自然演化出各种各样的评测脚本。有的用Postman手工请求接口，把返回结果复制到Excel里人工打标；有的用Jupyter Notebook跑一个临时评测脚本，结果散落在不同笔记本里；还有的干脆让开发自己写个简单的prompt对比工具。
这种碎片化模式带来的麻烦非常典型。第一是评测结果格式不统一，同一个模型在不同脚本里的打分口径不一样，有的用百分制，有的用五级制，有的直接主观写评语，导致横向对比完全没法做。第二是评测过程不可复现，脚本依赖本地环境，Python包版本换一个、OpenAI接口超时参数改一下，结果就变了，过两周再跑同一份case得到完全不同的分数。第三是没有历史对比，这个模型版本比上个版本到底是变好了还是变差了，没有任何数据支撑，全靠当事人口头汇报“感觉差不多”。
这三点单独看都是小问题，合在一起就是大问题：评测结果失去了决策价值。管理层问“新版模型能不能上线”的时候，你拿不出一个可靠的数据来回答，只能拍脑袋。
1.3 平台化评测真正要解决的四件事
所以我们在建设评测平台之前，先确定了平台化评测必须解决的四个问题。
一是统一数据源。所有评测case必须集中管理，有版本、有标签、有类型区分。数据不能散落在个人电脑和临时脚本里，谁污染了数据集、什么时候改过、为什么改，都要有记录。
二是统一流程。评测不应该是“跑个脚本”这种一次性动作，而是一条固定流水线：数据准备、模型推理、指标计算、结果归档、报告生成，每个环节都可以被重复执行和追踪。
三是统一指标体系。不管是谁来评测、评测什么模型，最后都要输出同一套维度的量化指标。只有口径统一了，不同模型之间、同一模型不同版本之间的对比才有意义。
四是统一结果存储与追溯。每次评测的输入数据版本、模型版本、评测环境、Raw输出、打分明细，全部落库。这样以后任何一次评测结论都可以被追溯和复核，而不是“当时跑了一下没保存”的薛定谔状态。
这四个问题想清楚之后，我们才意识到这不是写几个脚本能解决的，需要一套专门支撑评测业务的基础设施。这也是我们决定引入Coze-Loop的最初动因。
2. Coze-Loop是什么：把评测流程做成可编排流水线
2.1 从命名看定位：编排加循环
第一次看到Coze-Loop这个名字，我理解的就是两层意思。Coze在英文里有“巧妙编排、组合”的含义，对应的是评测流程的编排能力；Loop则是循环和迭代，对应的是评测体系最核心的价值——持续回归。
一般的评测工具解决的是“怎么算分”，Coze-Loop解决的是“评测这件事本身怎么组织”。它把评测拆成几个可以独立替换的环节：数据集加载、评测模板定义、执行器运行、打分器评估、报告生成。这些环节通过一套配置化的方式来组合，而不是靠改代码。你想换一份评测数据，改配置即可；想换一个打分模型，替换打分器；想把线上的真实对话记录拉回来做评测，那就再加一个数据源适配器。
这个设计思路跟我们想要的平台化评测高度一致。我们不希望评测逻辑写死在某个业务代码里，我们希望评测是一个可以编排、可以复用、可以沉淀的基础能力。
2.2 Coze-Loop的核心模块与数据流
从落地使用来看，Coze-Loop核心模块大致可以分成五块。
数据加载模块负责从不同数据源拉取评测用例，文件、数据库表、对象存储都可以作为数据来源。评测用例本身有标准格式，一般包含输入、期望输出、类别标签、难度标记等字段，比较灵活的还支持自定义扩展字段。
评测模板模块定义了一次评测任务的“玩法”：选用什么数据集、用什么评测模式（单模型评测还是多模型对比）、调用什么打分逻辑、最终输出哪些指标。模板的作用是沉淀评测方案，不同团队可以维护各自的评测模板。
执行器模块负责真正调用模型接口进行推理，拿到原始输出。执行器同时负责并发控制、超时管理、失败重试这些脏活累活。在Coze-Loop里可以配置并发度、超时时间、重试次数，这些参数直接影响评测效率。
打分器模块是核心中的核心，负责把模型输出转成量化分数。打分器可以是简单的规则脚本，比如算BLEU、ROUGE、准确率；也可以是调用大模型来给结果打分；还可以是人工评审队列，打完分之后回填。打分器的结果统一组织成标准指标结构，方便后续聚合和对比。
报告模块把本次评测的所有信息聚合成一份评测报告，包括模型基本信息、数据集信息、各项指标得分、case级明细、失败样例等。报告可以推送到通知渠道，也可以归档到存储系统作为历史记录。
数据流其实很清晰：评测用例从数据源进入模板，执行器批量调用待测模型获取输出，打分器对输出进行量化评估，最后报告模块汇总所有结果。整条链路具备可重入性，任意一个环节失败，恢复之后可以继续跑，不需要从头再来。
2.3 它和主流评测框架的差异
说到大模型评测，很多人会想到OpenCompass、lm-evaluation-harness这类学术评测框架。这些框架在跑公开benchmark方面确实很强，几十个数据集一次跑完，各类指标齐全。但我们在调研之后认为，这类框架更适合做研究阶段的横向对比，不太适合直接嵌入生产环境做持续评测。
区别主要在几个地方。学术评测框架通常面向“跑分”，追求在标准数据集上的横向可比性，但评测用例跟实际业务场景脱节，你很难把线上真实的用户问题灌进去跑。Coze-Loop更强调评测数据来源的灵活性，既能跑公开数据集，也能挂载业务库里的真实case。
学术评测框架的执行单元大多是“批处理任务”，跑完一个数据集就结束了，缺少评测任务与调度系统的集成能力。Coze-Loop在设计上更像是被集成的一方，评测任务可以被外部调度系统触发，也能被编排进更大的数据流水线。这一点对我们要建设平台化评测非常关键，因为评测不是一次性活动，而是每次模型迭代、每次数据更新时都要自动触发的事情。
还有一点，学术评测框架的分值计算相对固定，偏向于标准答案匹配、统计指标这类方法。Coze-Loop对打分器做了抽象，可以轻松接入大模型评分、规则引擎、人工评审等多种模式。在真实业务场景里，很多质量维度很难用标准答案匹配来判断，比如“回答是否解决用户问题”“是否包含安全风险”，这类判断用大模型当裁判往往更贴近真实使用体验。
3. AllData为什么选Coze-Loop：四个核心集成点拆解
3.1 AllData的架构刚好缺一块拼图
AllData本身解决的是数据工程问题，集成、开发、调度、治理都是围绕“数据怎么管”展开的。但在实际使用中我们发现，数据工程问题解决完之后，数据变成模型服务、模型服务上线之后的质量管理，成了一个新的真空地带。
这个真空地带就是模型的可观测性与可度量性。我们花了很多精力清洗数据、构建特征、开发调度任务，但模型更新上线之后效果有没有提升，回归是不是引入了新问题，这个数据链路是断的。可以说我们缺少的是一块“模型质量观测”的拼图，而大模型评测平台正是用来补上这一块的。
Coze-Loop进入我们的视野，正是因为它能跟AllData形成互补关系。AllData提供数据和调度基础设施，Coze-Loop提供评测编排能力，二者结合后，评测能够从业务数据出发，经过模型推理、打分评估、再把结果回流到数据仓库，形成完整的闭环。
3.2 为什么不自研评测引擎
选型的时候团队内部认真讨论过要不要自研评测引擎，理由也很简单：评测平台的核心逻辑看上去不复杂，无非就是“发请求、收结果、算分、出报告”。但深入拆解之后就发现，自研的风险并不低。
评测平台真正的复杂度在细节里。评测数据如何版本化管理、模型服务超时怎么办、打分结果不一致如何处理、并发调度怎么控制、评测历史如何追溯，每一个都是小坑，攒起来就是一坨大坑。社区项目在真实场景里被反复使用过，这些坑大多已经被填平了。
Coze-Loop虽然是开源项目，但它的模块化设计给了我们足够的自定义空间。数据集格式可以按我们的数据模型扩展，打分器可以对接我们已有的评测方法，报告输出可以改造为写入我们的数仓表结构。与其从零开始重复造轮子，不如把编排层和数据层已有的能力拿来复用，我们重点做模型接入和与AllData的集成适配，这样整体交付周期大大缩短。
3.3 四个集成点：数据、模型、调度、回流
落地的时候，我们主要做了四个方向的集成改造。
第一个是数据打通。AllData平台上有完善的数据集成链路，业务库的问答记录、人工标注的评测集、运营整理的bad case，都通过数据集成任务汇聚到数仓。Coze-Loop需要能直接读取这些评测数据集，而不是像独立部署那样只读本地文件。我们在Coze-Loop的数据加载模块上增加了AllData数据源适配器，配置好数仓表名和过滤条件，评测任务就能直接拉取数据。
第二个是模型接入。评测平台必须支持被测模型的统一注册。我们的模型服务不完全统一，有的是自研模型走内部推理平台，有的是通过网关访问外部大模型API。Coze-Loop的模型接入模块采用适配器模式，我们为内部推理平台写了一个专用适配器，统一封装鉴权、超时、流式处理逻辑，让评测框架能以统一接口调用不同来源的模型。
第三个是调度复用。AllData自带调度中心，本来就在调度各种数据任务。评测任务天然适合挂到调度系统里，每天凌晨定时跑一轮线上case回归，版本发布时按需触发评测。我们开发了调度中心到Coze-Loop的任务触发插件，一条评测流水线跟一个普通数据任务一样，可以被配置依赖关系、设置执行频率、监控运行状态。
第四个是结果回流。评测报告的指标数据、case明细、失败样例，最终都需要沉淀回AllData的数仓。我们写了一套结果同步任务，评测完成后自动将结果表写入数仓对应分区，再挂到AllData的数据资产目录里。这样下游的分析团队、运营团队都能基于统一的评测数据做进一步分析，而不是各看各的报告截图。
这四个集成点做完之后，Coze-Loop在AllData里就不再是一个孤立的外部组件，而是长在数据基础设施之上的一个评测能力层。
4. 评测平台的落地方案：架构、工作流与量化指标设计
4.1 平台总体架构：五层模型一次说清
整个评测平台我们按五层来设计。
最底层是数据层，包含AllData数仓里的评测数据集、模型输出原始记录、人工标注结果表、评测历史明细表。所有与评测相关的数据都通过数据资产目录统一管理，保证可追溯。
第二层是执行层，跑的是Coze-Loop执行引擎，负责评测模板解析、数据加载、模型调用、打分调度。这一层所有动作都通过配置驱动，不写死任何业务逻辑。
第三层是能力层，提供各类可插拔能力组件：模型适配器、打分器、报告模板、通知渠道。能力层的作用是把多变的需求以配置方式接入，业务上要支持新的模型类型或者新的打分方法，不需要改框架代码，只需要加一个适配器或者替换一个打分器配置。
第四层是服务层，对外提供评测任务相关的API和UI入口，运营人员可以创建评测任务、查看评测进度、查看报告、配置告警。服务层同时负责权限控制和多团队隔离。
最上面是应用层，面向不同角色提供不同视图：模型负责人看评测分值和趋势，业务方看case级明细和bad case占比，管理层看模型迭代的整体效果变化。
这套分层的核心价值在于职责清晰：数据层只管存，执行层只管跑，能力层只管可扩展，服务层管交互，应用层管角色化呈现。每一层改动不影响其他层。
4.2 自动化评测工作流怎么串起来的
一次完整的自动化评测流程，在我们平台上这样走。
第一步是评测数据准备，从数仓选取评测数据集，指定数据版本，可以带上过滤条件，比如只看最近三个月线上命中的问答case，或者只选择某个业务线标注过的场景。选完数据后，平台会自动打一个数据集快照，防止后续数据变更影响评测结果。
第二步是评测模板配置，选择用哪个模板，指定评测模式是单模型评测还是双模型对比，选定打分器组合和指标输出要求。
第三步是模型配置，选择待测模型版本，配置模型服务地址、推理参数、超时阈值。这一步还有个隐藏逻辑，就是模型服务在评测前必须处于发布隔离状态，不能直接打到线上生产环境，一般都用独立推理实例或影子环境。
第四步是前置校验，平台会做一次小样本试跑，比如抽5条case验证模型接口通不通、输出格式是否符合预期、打分器能不能正常计算。前置校验通过后才启动正式评测，避免由于模型服务挂了导致整个评测任务白跑。
第五步是任务执行，Coze-Loop批量调用模型服务，获取输出后交给打分器打分。执行过程中记录每个case的状态，成功、失败、超时都有标记。
第六步是结果汇总，所有case得分聚合后，生成各维度指标，同时进行一次稳定性校验，看样本量和得分方差是否在合理区间。
第七步是报告生成，平台输出评测报告，包含核心指标、趋势对比、bad case列表。报告生成后自动推送到配置好的通知渠道，同时把结构化结果写入数仓。
第八步是后续动作，根据评测结果自动触发下游任务。设置过阈值的，如果指标跌破阈值，自动创建工单并通知负责人；如果评测通过，可以触发下一步上线审批流程。
这八步合在一起就是一个完整的“评测闭环”，全部自动化执行，人工只在需要时会介入看bad case和做最终决策。
4.3 量化评估指标体系的设计思路
量化评估指标是评测平台最核心的输出，设计得好不好直接决定评测结论是否可信。我们的指标体系分三层。
第一层是基础指标层，对应具体评测case的计算结果。按场景不同，基础指标会不一样：有标准答案的用准确率、F1、ROUGE、BLEU这类传统指标；没有标准答案的用语义相似度打分；偏生成式场景的用大模型评分结果。每个指标都保留明细，方便追溯具体是哪条case导致分数波动。
第二层是维度评分层，把case级指标汇总到质量维度上。我们实际使用中定义了一套通用维度：准确率维度衡量答案是否正确；完整性维度看回答是否覆盖了用户所有关注点；安全性维度判断是否包含风险内容；稳定性维度通过多次运行结果对比看输出是否抖动；效率维度记录响应时间和推理成本。每个维度都有单独的得分，不混在一起。
第三层是综合评分层，把各维度得分按权重合成一个整体评分。权重根据场景配置，比如客服场景安全性权重可能更高，研发辅助场景准确性权重会更高。综合评分不是简单平均，而是带权聚合，权重配置同时留档，保证历史对比口径可解释。
这套三层指标的思路，主要是为了避免只看一个总分导致的信息损失。总分高不代表每维度都好，维度分高不代表每条case都好，所以每一层的数据都保留，按需取用。
4.4 评测报告要让人看得懂、能决策
评测报告这个环节，很多平台不重视，但我们踩了坑之后发现这是用户感知最强的地方。早期我们的报告就是一串指标数字堆在一起，模型负责人看完了还是不知道“所以呢”，业务方看半天也不知道该不该放量。
现在我们的报告按照“结论先行、证据递进”的原则来组织。报告第一页展示核心结论，包括综合评分、较上版本变化幅度、是否达到上线阈值，用红黄绿状态标色直观表达结论。第二页展示维度得分，以雷达图或柱状图呈现各维度横评对比，让读者一眼看出哪块变好了、哪块变差了。第三页往下是case明细和bad case举例，每个bad case都附上输入、模型输出、打分依据和原因标签。
除了结果，报告还必须有元信息和置信度信息。样本量多大、数据来自哪个版本、评测时间、模型服务版本，都必须在报告上写清楚。如果本次评测样本量太小，报告会给出“置信度偏低”的提示，避免读者把偶然波动当成真实变化。
报告另有趋势视图，展示同一个数据集上最近多次评测的分数走势。趋势比单次分数更有说服力，因为单次评测可能有随机性，持续走势能看出模型迭代是否在稳步提升。
5. 关键环节实现：模型适配、任务调度与测评阻断
5.1 部署与初始化：先打通最小闭环
部署过程这里不展开所有细节，重点说几个容易踩坑的点。Coze-Loop依赖一个数据库来存评测配置和历史记录，我们用的是MySQL，初始化时要先建好库和表结构，表结构初始化工具一般项目里会自带迁移脚本，直接执行即可。
第二个关键依赖是对象存储，评测任务的中间输出和最终报告都要归档，我们对接了AllData已有的对象存储，不需要额外搭建。环境变量里配置好存储访问凭证之后，Coze-Loop就能正常读写评测产物。
第三个点是网络打通，评测平台要能访问被测模型服务、数据库、对象存储。如果部署环境跟模型服务不在同一网段，要提前配置代理或放通防火墙，否则会浪费一整天在排查“配置看起来都对但任务一直失败”的问题上。
初始化完成后的第一件事不是急着配复杂模板，而是先跑一个最小闭环：准备3条测试用例，配一个最简单的模板，选一个模型，跑完整个流程确认“数据能进来、模型能被调用、分数能算出来、报告能生成”这四个环节全部畅通。打通最小闭环之后再去扩展模板和集成，问题排查会容易得多。
5.2 模型接入适配器怎么写才不容易乱
模型适配器是评测平台面对“模型碎片化”的核心手段。我们的经验是，适配器必须严格遵循统一接口，不要为了某一个模型特性破坏通用性。
一个标准的模型适配器，至少要提供三个方法。初始化方法负责读取模型配置信息，建立连接或认证；推理方法接收评测输入，返回模型输出，内部处理超时、重试、流式聚合；健康检查方法在评测启动前被调用，用来确认模型服务是否可用。
这里分享一段简化版适配器伪代码，展示接口设计的思路：
class ModelAdapter: def __init__(self, config: dict): self.endpoint = config["endpoint"] self.api_key = config.get("api_key", "") self.timeout = config.get("timeout", 30) self.max_retries = config.get("max_retries", 2) async def check_health(self) -> bool: # 轻量探测模型服务是否可用 try: resp = await self._call("ping") return resp.get("status") == "ok" except Exception: return False async def infer(self, messages: list) -> str: # 调用模型服务获取输出 payload = self._build_payload(messages) result = await self._request_with_retry(payload) return result["output"] async def _request_with_retry(self, payload): # 包裹重试逻辑，每次重试之间做指数退避 for attempt in range(self.max_retries): try: resp = await self._post(payload) return resp except TimeoutError: if attempt == self.max_retries - 1: raise await asyncio.sleep(2 ** attempt)适配器写完之后，要做一次专门的“异常注入测试”。我们把超时时间调到极小，把接口地址改成错误地址，强迫适配器走各种失败分支，确认错误能被清晰捕获并能反馈到评测任务状态里。很多评测任务运行失败后日志信息莫名其妙，多半就是适配器缺乏合理的异常处理。
5.3 任务调度、并发限流与资源控制
评测任务挂到调度系统之后，引发的第一个问题是并发控制。Coze-Loop默认的并发策略比较简单，评测任务内部会按配置并发调用模型，但我们接了调度系统之后，同时跑多个评测任务会互相争抢模型服务资源，导致评测结果大面积超时。
我们的做法是在评测任务入口增加一个统一限流层。每个模型服务配置一个最大并发数，评测任务启动时先去限流层申请配额，拿到配额才继续执行，拿不到就排队等待。这个限流层跟模型推理平台本身的限流是两层逻辑，评测框架层的限流主要是防止评测任务之间互相拖垮。
资源控制还有另外一面，就是推理参数的规范。评测模型服务必须固定温度参数，一般设置成0或者接近0，保证输出尽量确定。温度参数不一致的评测结果没有可比性，这一点必须强制在模型配置里校验，否则不同评测任务之间没法做趋势对比。
执行过程中还要设计“执行批次”的概念。一次评测数据集可能包含几千条case，不要一次性全部塞给打分器去聚合，而是分批执行、分批汇总。这样中途如果出现批量失败，可以只重跑失败批次，不需要整个评测任务全部重来。
5.4 回归测试与阈值阻断的实现
评测平台最有价值的能力之一是回归测试。模型每次迭代之后，自动跑同一套评测数据集，对比新版本和旧版本的指标差异。这个功能实现起来逻辑不复杂，但有一个关键点：每次评测都必须记录完整的“评测指纹”。
评测指纹包括数据集版本号、评测模板ID、模型服务版本、打分器版本、运行时依赖版本。有了指纹，两次评测的结果才能被认定为可对比，合并进同一个趋势序列。如果一个评测任务数据集的case数量变了都不知道，那趋势图上的分数变化就可能是假的。
阈值阻断是我们后期加上去的一个机制。模型负责人可以给每个指标配置一个阈值，例如“综合评分不得低于上一版本2个百分点”或“安全性维度得分不得低于90分”。评测完成之后，系统自动进行阈值判定，未通过的评测报告会有明显标注，并且可以联动阻断后续的上线流程。
这里有一个实现细节：阈值判定不能只看平均值，还要看分布。某些case得分极低但平均分还过得去，这时候阈值判定体系里可以加一项“低分case占比”，超过一定比例就判定为不达标。这种异常分布往往比平均分下降更能暴露真实问题。
6. 真实踩坑记录：六个典型评测问题与排查思路
6.1 分数抖动：评测结果为什么不可复现
我们遇到过最头疼的问题，是同一个模型版本、同一份数据集，前后两次评测分数差了五个百分点。排查了很长时间才定位到根因：模型服务端的推理温度没有固定，默认值下的随机性导致输出波动，尤其在生成式任务上差异非常明显。
另一个抖动来源是评测数据顺序影响。模型服务如果是有状态的，case顺序变化可能导致输出变化，比如上下文缓存影响、限流排队影响等。解决办法是评测任务固定case顺序，并且数据集快照按固定顺序排列，保证每次执行顺序一致。
还有个更隐蔽的坑是打分器本身的稳定性。用大模型打分时，同一个case被同一个打分模型在不同时间调用，可能出现不同分数。处理办法是同一个case打三次取均值或中位数，同时固定打分模型的温度和系统提示词。
6.2 模型超时：流水线中断的根因与恢复
有一次评测任务跑到60%的时候大面积超时，表面上看是模型服务出问题，最后排查发现是评测计划任务恰好跟业务高峰重叠，模型服务被线上流量打满了。正好那次评测任务还把所有case串行处理，超时重试又逐个叠加，最终整个任务一崩到底。
这个问题的解决分了三步。第一步是模型服务拆分，评测流量单独走一个推理实例，或者配置独立的QPS配额，不跟线上流量抢资源。第二步是评测任务改成批次执行加断点续跑，失败批次自动标记，重跑时从失败批次开始而不是全量重跑。第三步是超时参数的合理设置，不是越大越好，超时时间应该根据模型输出长度和推理时间分布来自动计算，比如取P95推理时间加缓冲值。
6.3 数据版本混乱：评测基准被人为污染
评测数据集一旦不好好管理，危害非常大。我们曾经遇到过业务同学往评测集里补充了一批新case之后，模型得分突然“大幅提升”，看起来模型变强了，实际只是评测数据变简单了。
这个问题的本质是评分基准被污染，必须从机制上杜绝。现在我们的评测数据集都走版本管理，任何修改都生成新版本，历史版本永久保留并可以被重新引用。评测报告必须记录数据集版本号，趋势图只允许展示同一数据集版本下的历史对比。如果数据集版本换了，趋势图必须断开，不能直接跨版本连线。
另外，数据集要定期做质量体检，检查case难度分布、重复case、标注一致性。我们用了一段脚本统计每个case的历史得分方差，得分长期异常稳定且接近满分的case会拉出来人工复核，确认是不是评测集里混入了太简单甚至送分题。
6.4 自评打分失真：大模型打分要避开几个坑
我们用大模型打分器之后，有一段时间发现安全维度得分高得离谱，后来测试才发现打分模型跟被测模型在某些知识体系上高度相似，倾向给“同类”输出高分。这就相当于把运动员和裁判安排成了同一批人，打分结果自然失真。
给出的解决方案有几个。第一，打分模型尽量选用与被测模型不同源的模型，降低偏好偏置。第二，打分提示词里不要透露被测模型的名称和来源，避免身份信息影响判断。第三，定期做人工抽检校准，从大模型打分结果里抽5%到10%交由人工复核，计算人机一致率，如果一致率低于阈值就触发打分器配置调整。
还有一点经验是，大模型打分时给出的数值型分数容易存在“整数偏好”，打分结果大量集中在1、3、5这类整数上，不利于精细区分。现在我们的打分器统一用百分制并要求输出小数部分，打分后还要做归一化处理，保证分数分布尽量合理。
6.5 并发探底：评测任务挤掉线上资源
评测任务对资源的需求往往比预期的猛。我们有次同时启动了三组对比评测任务，每组几百条case，并发数都拉满，直接导致线上模型服务响应出现明显波动。评测本来是安全动作，结果变成了事故源。
这次之后我们给评测任务设置了默认的资源上限，新建评测任务时强制要求填写预计并发数并获得审批。评测任务执行过程中还会监控模型服务的响应延迟，如果延迟超过安全水位，评测任务会自动降级并发，甚至暂停等待。
资源隔离除了模型服务实例隔离，还包括评测执行资源的隔离。现在评测调度任务固定跑在独立的执行器分组上，不会跟AllData的常规数据任务抢占计算资源。宁可评测跑得慢一点，也不能让评测本身影响生产链路。
最后再分享一点个人体会
这套平台从立项到跑通，大概用了两个多月的时间。如果让我复盘最核心的收获，那就是评测平台的本质不是“工具”，而是“流程和标准的载体”。真正值钱的地方不只是自动跑分那一下，而是把评测数据、评测模板、打分逻辑、结果归档这些环节标准化，让每一次模型迭代都有可靠的数据来支撑决策。
另一个体会是不要一开始就追求评测体系的完备。我们最开始只接了准确率和响应时间两个指标，先跑通自动化，再用起来之后逐步把安全性、完整性、稳定性这些维度加进去。一步到位做一套宏大体系，大概率会卡在细节里出不来。先把最小闭环转起来，让评测结果能稳定复现，再去扩展场景和指标，整个过程会顺畅得多。
如果你也在做大模型应用落地，正在被“测评全靠人工、结果说不清楚”困扰，建议尽早把自动化评测平台的架子搭起来。不用很复杂，数据集加模板加打分器加报告，这四个组件就能撑起一个很好用的评测闭环。上面提到的那些坑，希望你能绕过去。
