从“模型看着都还行一上线就翻车”到“每次迭代都能讲清楚哪里变好、哪里变差”我们团队折腾了大半年最终靠 AllData 和开源项目 Coze-Loop 把大模型评测这件事从人工抽样例变成了一条可重复、可量化的自动化流水线。这篇文章我会把整个大模型评测平台的建设思路、技术选型、量化指标和实操中踩过的坑完整写出来适合正在搭评测体系、做模型选型对比、或者在 CI 里卡模型上线质量的同学参考。先交代一下背景我们内部有多个业务场景在用大模型包括客服问答、文档摘要、代码注释生成、知识库问答。之前每个场景都是算法同学自己拉几条评测集肉眼看一下效果然后拍板说“行”或者“不行”。同一个模型在不同场景下结论对不上两个模型之间也说不清差多少。后来我们决定把评测平台化数据底座用 AllData评测执行用 Coze-Loop 这个开源项目形成一套“数据统一管、用例自动跑、指标量化出”的闭环。这篇文章就是围绕这套平台展开的。1. 为什么非要把大模型评测做成平台1.1 模型选型与迭代的最大痛点效果说不清大模型落地和传统软件有个很大区别传统功能有明确的测试用例和预期结果大模型很多场景没有标准答案。同样是“总结这段文章”一个人总结和另一个人总结都有差异更别说让模型每次都保持一致。这就导致早期我们团队一直在“口说无凭”的状态里打转。模型升级之后运营同学说“回答好像变啰嗦了”算法同学说“变啰嗦但知识点覆盖更全了”两边谁都说服不了谁。这种状态下做模型选型非常危险因为大家靠的是抽几条 demo 后的感觉而不是完整数据集上的统计结果。我们需要的是一套固定的评测集、固定的评测环境、固定的评分规则让模型好不好变成可以回放、可以对比、可以审计的量化结论而不是开会时的主观感受。1.2 AllData 和 Coze-Loop 各自解决什么问题AllData 在项目里的角色是数据底座。它把散落各处的评测数据、历史结果、业务语料统一纳管起来保证每次评测用的数据是同一个版本评测结果可以追溯。之前我们评测数据存在不同的地方有人放本地 Excel有人放在线文档有人写在代码仓库里版本一多就分不清哪个是“当前有效集”。接入 AllData 之后数据集有了版本、来源、标签和权限管理至少不会再出现“数据更新了但没人知道”的情况。Coze-Loop 的角色是评测执行引擎也是这次集成的主角。它负责接收评测任务定义、拆解用例、并行调用模型、触发评分器、汇总指标。你可以把它理解成一套“循环跑测试跑打分”的流水线框架专门为大模型场景设计。我们当初选它不是因为功能有多花哨而是它的任务编排模型非常直观一个评测任务由一个或多个评测场景组成每个场景包含模型接入、数据集、提示词模板和评分方式配置清晰二次开发成本也不高。2. 评测平台的整体设计与模块拆解2.1 五层架构让评测流程可复用我们在设计平台时没有搞复杂的微服务而是把整个系统分成了数据层、任务定义层、执行层、评估层和展示层。每层做一件事层与层之间通过标准数据结构通信这是 Coze-Loop 能快速集成进来的关键。数据层就是 AllData负责管理数据集、标注答案、历史跑分结果。任务定义层用 YAML 描述评测任务包括模型列表、数据集引用、提示词模板、评测指标。执行层由 Coze-Loop 调度它会把一个任务拆成很多条独立的请求并发发给不同的模型服务。评估层负责判分规则类的用脚本算分开放类的用评分模型打分。展示层生成报表并且把结果回写到 AllData供后续看趋势、做回归对比。这个分层方式的好处是任何一个层做替换都不影响其他层。比如从开源模型切到商用 API只需要在任务定义层改模型接入配置评测集和评分标准完全不用动。后面如果要加入新的数据源也只要在数据层接入 AllData 的数据连接器不用改执行逻辑。2.2 评测任务流水线的关键环节一条完整的评测流水线包含从“定义评测任务”到“生成评测报告”七个环节我按实际跑的先后顺序列一下数据准备从 AllData 拉取指定版本的评测数据集确认数据格式和标注内容。任务定义编写任务配置文件绑定要测的模型、数据集、提示词模板、并发数和评测指标。任务校验Coze-Loop 对配置做完整性检查比如模型地址是否可达、数据集字段是否存在。任务执行将评测用例拆分并发调用模型采集原始响应和耗时、token 消耗等元信息。结果判分根据评测指标对模型输出打分子项规则类和模型评分类分开处理。指标聚合把多条用例的结果聚合成场景级和模型级指标并计算置信区间。报告归档生成 JSON/HTML 报告同时把原始结果写回 AllData便于历史对比。第 3 步很容易被忽略但非常重要。有一次任务配置里的数据集字段名写错了二十多个模型服务白白跑了一个多小时跑完才发现所有请求都拿不到正确输入。后来我们把校验步骤前置配置发起来之前强制检查字段、模型连通性、模板渲染结果大大减少了半夜跑任务跑一半才发现问题的尴尬。2.3 为什么数据底座用 AllData 而不是自己写文件管理早期有人提议“评测数据集也不大直接用 Git 管理不就行了”。但实际用下来会发现Git 只适合管理静态数据不适合管理经常变化的标注数据和评测结果。AllData 提供了元数据管理、数据集版本控制、血缘追踪和访问审计这些能力在等评测平台越来越大时会变得至关重要。比如同一份业务语料可能被三个评测集引用。如果没有统一的数据管理某天有人改了基础语料三个评测集的结果可能悄悄变化但没人知道根因。AllData 会把数据集之间的引用关系记录下来评测报告中也能反查用到了哪个版本数据问题定位效率高了不少。另外评测结果也是数据把历史跑分存到 AllData我们就能画出模型效果随版本变化的曲线这个能力在模型回归测试里价值极高。3. 模型自动化测评的落地实现3.1 评测数据集接入与字段标准化评测数据集是整个平台的“考题”考题质量直接决定分数有没有意义。我们用 AllData 定义了统一的数据集格式核心字段包括指令、上下文、参考答案、评测维度、适用场景。不同业务只要把数据转换成这个标准格式就能接入评测平台。以客服问答为例一条评测数据包含用户问题、标准答案、追问列表、恶意输入标记。以文本摘要为例包含源文档、参考摘要、长度限制。把不同任务统一成“指令上下文参考答案”的结构之后Coze-Loop 就不需要为每个任务写一套数据读取逻辑模板渲染和判分阶段也都能共用同一套数据通路。这里要特别提醒数据集接入时做好去重和去污染。我们曾经发现一批考题材是从网上爬下来的而某个模型在预训练阶段很可能见过原题导致那个模型分数虚高。现在接数据时会先做 MD5 去重凡是和已入库数据重复的自动告警同时尽量不直接使用公开 benchmark 原文而是基于业务场景做改写。3.2 评测用例的结构正向、反向、边界一个都不能少评测平台说白了就是“用一堆题目测模型”但题目不能只挑容易的。我们设计用例时强制要求一个评测集里包含三类用例。正向用例验证模型“答得对”比如“用一句话总结这篇文章”。反向用例验证模型“知道什么不该做”比如客服场景中用户反复追问、辱骂、诱导泄露隐私时模型应该拒绝而不是配合。边界用例验证模型在极端情况下的表现比如超长文本、空输入、模糊指代、中英文混杂等。三类用例比例根据场景调整但反向用例最低不低于 15%。我们的教训是很多模型正向用例跑分很漂亮一遇到越权问题就崩。没有反向用例的评测平台本质上是给模型“送分”。3.3 自动化执行引擎并发、超时、重试、限流Coze-Loop 执行层最核心的是对模型调用的控制。大模型推理同一个问题每次输出可能不一样而且不同模型接口能力差异很大有的支持高并发有的弱接口一压就 429。我们通过几项设置把执行过程磨稳了并发数每个模型单独配置商用 API 从 5 开始逐步加压自建模型看推理服务实际负载动态调整。超时时间首包超时和总超时分开设避免一个慢请求把整个执行队列卡死。重试机制只对可重试错误重试比如网络抖动和 429对模型返回空内容的错误不盲目重试。限流策略按模型的 RPM/TPM 配额做令牌桶限流防止触发服务端熔断。举个例子某个开源模型部署的推理服务单实例吞吐在 10 路左右一开始我们直接把并发调到 20结果大量请求排队等待P99 响应时间从 4 秒飙到 30 秒。后来调整为最多 12 并发同时加上请求排队等待时间上限整体评测耗时反而缩短了约三分之一。评测耗时不只看发得快不快更要看服务能不能稳定扛住。3.4 把评测接入 CI/CD形成模型发布门禁自动化测评真正发挥作用是在和发布流程打通之后。现在每次新模型或新 prompt 上线之前都必须跑一遍核心评测集通过分数门槛才能合并发布。我们定义了一套质量门禁规则比如综合得分低于上一版本 0.5% 的必须人工复审核心指标降幅超过 1% 的默认不允许上线。这样可以拦住大部分无意的效果回退。平台会对比历史基线自动生成“哪些维度变好、哪些维度变差”的差异报告。刚开始接入 CI 时免不了“误伤”因为评测本身有随机性模型讲了多次结果会有波动。后来我们引入重复采样评测每条用例至少跑 3 次取平均分做判断。这样虽然多花了 token但门禁稳定了很多。评测门禁不是用来卡人的本质上是把以前靠人肉记忆的“这次到底行不行”变成可查询的客观记录。4. 效果量化评估指标体系4.1 通用指标准确率、F1、BLEU、ROUGE、METEOR不同任务要配不同的量化指标不可能一套指标打天下。我们的评测平台把指标分成三类分类/抽取类、生成类和综合对话类。分类与抽取类任务用准确率、精确率、召回率和 F1。比如“从工单中抽取客户反馈的类别”这种任务模型输出必须映射到预定义标签才能算分。生成类任务常用的有 BLEU、ROUGE、METEOR它们本质上是看模型输出和参考答案之间的字面重合程度。BLEU 偏重于精确性适合机器翻译ROUGE 偏重召回适合摘要METEOR 兼顾同义词和词形变化比前两者稍微“懂人话”一点。但字面重合指标有天然的局限性模型回答语义正确但表达方式和参考不同分数往往不高。所以我们定量指标只作为参考的一部分最终判定还会叠加模型评分和人工抽检防止“指标好看体验很差”。指标名称适用场景主要考察点注意问题准确率 / F1分类、抽取标签预测是否准确类别不均衡时准确率有误导性BLEU翻译、固定句式生成n-gram 精确匹配不奖励同义改写ROUGE摘要、文本压缩参考内容的召回覆盖长文本上数值波动大METEOR翻译、摘要同义词、词形变化计算较慢不适合超大规模人工评分开放问答、创意生成语义、逻辑、体验耗时耗力需要多人打标4.2 对话与指令场景遵循度、无害性、鲁棒性客服、助手这类对话场景单靠 ROUGE 和 BLEU 完全不够。我们结合 Coze-Loop 的评分器扩展点加入了几个定制指标。指令遵循度用来评价模型有没有照着要求做事。比如要求“只回复不超过 20 个字”模型如果写了一大段就算内容正确也要扣分。我们通过规则加评分模型混合判断。无害性针对安全场景检测模型是否会输出不当内容、是否会被诱导作出危险建议。鲁棒性则看模型在输入有错别字、口语化表达、噪声干扰时是否还能给出合理回答。这些指标在 Coze-Loop 里都是可插拔的评分模块。我们最开始只有规则判断后来发现指令遵循这种语义任务还靠关键词匹配太粗糙就注册了一个“LLM-as-a-judge”评分器用预设的评分标准让大模型给结果打分。这里要注意评分模型本身也有偏好和波动所以所有模型打分任务都固定温度、固定 prompt 版本并定期抽检评分质量。4.3 综合量化归一化与加权指数一个模型好不好不能只看单一指标最终要给决策者一个可比较的总分。我们把不同指标归一化到 0-100 分再按业务权重加权汇总。比如客服问答场景综合得分 准确率分数 × 0.4 指令遵循度 × 0.3 无害性 × 0.2 鲁棒性 × 0.1。这样设计是有意为之的准确率是底线权重最高但客服光答得对还不够必须用合适的语气和格式所以遵循度占三成安全性和鲁棒性是防御性指标不追求极致但必须有基本保障。归一化时最怕不同批次评测之间分数尺度变化。我们采取“锚点模型”策略每次评测固定跑一个基准模型用基准模型的分数来校准其他模型抵消评分模型状态波动带来的影响。实测下来同样的模型在不同批次之间分差能控制在 1 分以内这个策略帮了不少忙。4.4 人工评测与自动化结合保住“体验”底线完全靠自动化指标容易忽略真实用户的主观体验。我们把人工评测设计成补充闭环而不只是最后抽检。每次在自动评测结果里会按分数分布、模型答案差异度抽出一批“争议用例”推送给业务人员进行人工标分。争议用例通常是自动评分器给分不高、或者不同评分模型结论不一致的样本。人工看完后会把结果反馈到评测配置里优化 prompt 或调整评分权重。这样可以不断校准自动评分的偏差避免自动指标和业务体验“两张皮”。人工评测不宜贪多我们每个评测场景一次抽 50-100 条由至少两人独立打分再用简单一致性系数判断标注质量。这个量级占总体评测数据不到 5%但带来的校准价值很大。5. 实操中遇到的坑与排查经验5.1 数据污染模型可能“见过”你的考题数据污染是评测平台最容易出现、也最隐蔽的问题。公开 benchmark 用得越熟越要警惕模型是否在训练阶段见过原题。我们曾用一个公开数据集测模型模型 A 比模型 B 高出 6 个百分点后来查了很久才发现模型 A 的训练数据里包含该数据集的近似版本说白了是“背过答案”。现在我们的处理方式是优先构造场景专属数据集基于真实业务数据改写如果非要用公开数据集就把公开题目做语义扰动减少直接原题命中的概率另外数据入库前和模型已知训练集做相似性抽检相似度过高的打上高危标签。5.2 评测结果不稳定temp、随机采样、并发都要严格控制第一次发评测平台时大家反馈“评测分数忽高忽低”。排查下来发现有两个原因一是模型推理温度没有固定默认参数下生成结果随机性较大二是同一个模型接口并发过高时部分请求超时被重试重试后模型输出已经不同导致数据不一致。现在所有评测任务强制配置模型参数温度固定为 0除特殊测随机性场景外不做任何采样参数扰动。单条用例重复执行 3 次取均值。重试只针对请求链路错误不在模型已经返回结果后重试。这样执行结果才具备可比性。5.3 指标“骗人”长答案和模板套话会抬高分值模型评分时代有一个常见陷阱LLM-as-a-judge 对详细、完整的回答有偏好。同一个知识点模型用 200 字分点回答比用 30 字直白回答更容易拿高分但业务上用户可能只想要一句准确答复。我们给评分 prompt 里明确加了长度约束和简洁性加分规则同时对超长答案做截断或限制。另外在综合指标里加入了“响应质量符合长度要求”这一项超出业务限定长度的回答自动扣分。否则评测结果会引导模型越写越长体验反而下降。5.4 token 成本与评测资源规划自动化评测非常烧 token尤其是做重复采样和多模型对比。有次我们一次性测了 8 个模型每个模型跑 2000 条生成类用例每条重复 3 次光一次实验就消费了接近 200 万 token折算成成本让人心疼。现在的做法是“分层评测”日常开发用小规模快速集每个场景 200 条用例用来快速发现明显问题发布门禁用核心集每个场景 800-1000 条月度做全量深度评测再覆盖低频边界场景。同时把评测任务调度到模型服务低峰期跑能省一笔推理成本。Coze-Loop 支持任务排队调度到凌晨执行的话费用和时间压力都会小很多。6. 平台落地后的实际效果与后续方向6.1 业务侧的真实收益平台上线三个月后最明显的变化是模型选型不再靠“嗓门大”。算法团队可以拿着对比报告和相关方对齐哪些用例上模型表现好哪些维度拖了后腿一目了然。客服场景的模型迭代因为有了量化评估回退率从每次上线都提心吊胆变成了有数据支撑的确定流程。另一个收益是评测数据在复用。以前每个项目组都要自己人工构造验证集现在通过 AllData 平台共享核心评测集各团队既可以使用公共集也可以创建私有集在自己的空间里跑评测。重复造轮子的问题得到缓解整个组织对模型效果的口径也统一了。6.2 后续扩展多模态评测和动态对抗样例目前平台主要覆盖文本模型下一步我们在规划多模态评测能力包括图像问答、图文检索、以及视觉描述一致性。Coze-Loop 的任务模型对这类扩展相对友好只需要扩展数据集的字段类型和评分模块的输入输出不需要重构执行框架。动态对抗样例也是我们想做的方向。固定评测集跑久了模型可能会有“应试”倾向。我们计划从真实线上反馈中自动抽取低分案例再通过改写生成新的对抗评测用例持续补充到评测集里。让评测集跟着业务变化“活”起来而不是一套题用一年。这个方向没有终点但大方向已经跑通先让模型效果可评估再让评估流程自动化最后用自动化结果反哺模型和 prompt 迭代。只要这条路走对了AI 应用落地就不会再是“黑盒子式”的上线赌博。最后再分享一个小经验如果团队刚开始搭评测平台不用急着一次接几十个指标。先把三类用例跑通、把执行环境和评分逻辑稳定住再把门禁接进发布流程。我们一开始就是在指标上贪多结果很多指标算出来了但不看反而浪费了大量评测成本。先保证少数核心指标被所有人认可再慢慢扩展评测平台才能真正在团队里扎根。