企业官网建设流程全解析

做AI应用最怕什么？我现在一定会回答：怕你根本说不清楚模型到底行不行。过去半年，我们团队一直在折腾一件事——把AllData这个数据集成平台，和开源项目Coze-Loop做集成，搭建一套大模型评测平台，用来做模型自动化测评和效果量化评估。这篇文章就是我从0到1跑通的完整记录，适合正在做模型选型评估、应用回归测试、Prompt工程质量管理的朋友，数据团队的同学也能从中看到评测数据如何跟业务数据打通。我会把平台搭建思路、评测流程设计、量化指标怎么计算，以及几个最容易让人误判结果的地方逐一讲透。

1. 为什么要把AllData和Coze-Loop集成在一起搭评测平台

1.1 大模型落地前的三座大山：选型、回归、量化

先说说我们最初遇到的三个问题，你可能也正在经历。

第一是模型选型。市场上公开可用的模型API越来越多，同一个业务场景，用模型A和用模型B，效果差异往往不是一眼能看出来的，但成本可能差出好几倍。团队内部讨论的时候，每个人都有自己的偏好，有人说A回答问题更完整，有人说B风格更自然，争论半天没有结论。没有量化数据，选型就是拍脑袋。

第二是上线后的回归。你以为模型版本固定了就稳了，实际不是。Prompt调整一个词，模型输出可能整体跳变；模型厂商服务端更新一个模型版本，应用质量可能悄悄波动。如果没有自动化回归机制，这些变化要等到用户投诉才会被暴露出来，那时候已经晚了。

第三是效果量化。业务方问“这个模型比旧模型好多少”，你拿不出一张得分表；老板问“AI客服的准确率到底有多少”，你只能说“体感还不错”。数字化说不清楚，AI应用就很难从试点走向规模化落地。

这三个问题指向同一个答案：需要一套大模型评测平台，把“模型行不行”从主观感受变成客观数据。这也是AllData要集成Coze-Loop的根本原因——只靠一个组件解决不了链路问题，数据侧和评测侧必须打通。

1.2 Coze-Loop在评测闭环里的位置

Coze-Loop这个名字，容易让人联想到一些做Bot编排的产品，但它实际上是专注评测闭环的开源项目。它把原本零散、靠人肉执行的评测工作，拆成了可编排、可重复运行的流程模块：评测任务定义、评测执行、自动打分、结果报告，这四个环节串起来，正好形成一个“评测循环”。

这个循环的意义在于，评测不再是“上线前临时跑一次”的动作，而是可以持续运转的机制。每次模型更新、每次Prompt改动、每次新增场景，都能触发一轮自动化测评，然后和上一次结果做对比。Coze-Loop解决的就是评测侧的调度、执行、打分、沉淀问题，让整个评测过程从手工劳动变成自动化流水线。

我最初看这个项目时，最看重的一点是它的任务编排抽象得很干净。评测集、模型服务、评分标准、输出报告这四样东西是解耦的，意味着你可以把任意模型接入同一套评测集做横向对比，也可以把同一模型在多个评测集上做纵向回归。这种“数据集与模型解耦”的设计，是后面所有自动化能力的基础。

1.3 AllData在评测链路里补上了哪块拼图

Coze-Loop解决了“评测怎么跑”，但解决不了“评测数据从哪来”。评测集的质量，直接决定评测结果有没有参考价值。如果评测集只是网上找来的几百道通用题，和你的业务场景关系不大，那分数再高也说明不了问题。

AllData在这里的角色，就是数据联邦。它是一个数据集成平台，负责把散落在各个业务系统里的数据汇聚、清洗、转换。在评测平台上，AllData承担了两件事：一是供给，从业务库、日志库、知识库里抽取真实的用户问句、对话记录、FAQ内容，加工成评测数据集；二是回流，把每次评测产出的分数、样本明细、模型输出写回数仓，形成历史数据，方便后续做趋势分析、异常发现、报表展示。

用一句话概括集成后的效果：来自业务的数据，经过清洗后进入评测集，评测集中跑出分数，分数又回流到数据平台，最终形成“业务产生数据——数据驱动评测——评测反哺业务”的闭环。AllData不是评测平台的外围组件，而是评测数据生命周期的起点和终点。

2. 评测平台核心模块怎么设计：数据、任务、模型、打分

2.1 平台整体结构与数据流转

因为平台要承载自动化测评，结构上我把它拆成五个模块，每个模块职责单一，之间通过数据或消息解耦。这是整个评测平台能否稳定跑起来的关键。

评测集管理模块负责所有测试数据的组织。里面有评测集的创建、版本管理、分类标签、题目状态（待评测/已评测/有争议）、标注规范。评测集以数据集版本为粒度，每次评测都固定引用某个版本的评测集，避免数据变了导致结果不可比。

任务调度模块负责评测任务的编排与执行。它读取用户配置的评测任务，把评测集里的样本拆成批次，分发给执行引擎，同时处理后端超时、重试、并发控制。Coze-Loop的调度能力在这一层体现，执行引擎则是无状态的计算工作节点，可以水平扩展。

模型接入网关负责屏蔽各家模型的接口差异。同一个评测任务可能同时测三四个模型，网关把各自的API统一成内部协议，换来的是上层逻辑不用关心具体模型长什么样。打分模块负责对模型的输出进行评判，可以是规则打分、模型裁判打分、人工复核三种方式。结果存储模块负责把原始输出、评分明细、汇总指标一并入库，并生成评测报告。

数据流转大概是这样的：AllData把清洗后的业务语料写入评测集；评测任务启动时，Coze-Loop从评测集拉取样本，调用模型接入网关拿到模型输出；打分模块对输出评分；最终结果连同样本ID、模型版本、评测集版本一起写回AllData对应的结果表里。整个链路没有人工干预，跑完自动生成报告。

2.2 评测集管理：数据版本和样本标注是地基

评测集是整个平台里最容易糊弄、又最不能糊弄的部分。你喂给评测平台的每一道题，都要能答清楚三个问题：业务场景是什么、标准答案是什么、预期质量是什么。

我们实践中会把评测集按“场景-能力-难度”三层组织。场景是指业务上的分类，比如智能客服里的退款咨询、物流查询、发票问题；能力是指模型要展示的素质，比如理解准确、信息完整、语气专业；难度则是给样本打上的标签，简单、中等、困难、对抗样本四档。这样拆的好处是，评测完你不仅能看总分，还能看模型在哪个场景、哪个能力、哪个难度上掉点，定位问题非常快。

评测集的版本管理同样重要。上线前的评测、上线后的回归、模型升级后的对比，如果不锁定版本，你根本说不清分数差异是因为模型变了还是因为测试题变了。我们规定每个评测任务必须显式引用评测集版本号，并且每次更新数据都生成新版本，旧版本留档，保证任何时候都能复现一次历史评测。

样本标注是评测集建设里最耗时的一环。通用大模型的评测经常用模型生成参考答案，但到了具体业务场景，标准答案必须由熟悉业务的人来写。我们的经验是：每道题写清楚“标准答案要点”和“得分规则”，而不是只写一句参考答案。否则不同标注的人写出来的尺度完全不同，评测集的可靠性会大打折扣。

2.3 模型接入网关与执行引擎的关键设计

模型接入网关这块，有一个设计差点被我做复杂了。一开始我想把每个模型的最佳参数都暴露给上层，比如temperature、top_p、max_tokens都做成可配置字段。后来发现这样会让评测任务配置变得极重，而且不同模型之间的参数语义还不完全一致。

最后我采用的是“默认参数+覆盖字段”的方式。评测任务只配置业务层面的必要信息，模型网关给每次评测请求套上一套稳定的默认参数，比如temperature固定为0.2，max_tokens按场景预设。只有在特殊场景下，评测员才会显式覆盖某个参数。这么做保证了同一评测集在不同模型上的可比性——你测的是模型本身的差异，而不是参数的差异。

执行引擎的处理逻辑也比较固定：从任务队列拉取一批样本，并发调用模型服务，收集输出后交给打分模块。这里有一个容易踩坑的点：并发设置得过高，API被限流，整批任务重试；设置得过低，几百条样本跑得很慢。我们的做法是把并发数做成任务级可调，并且加上指数退避重试，第一次超时等1秒，第二次等2秒，最多重试三次，超过三次的样本单独标记为失败，不影响整体统计。

2.4 打分层：规则、模型裁判、人工复核怎么搭配

打分是最容易出现玄学的地方，三种打分方式各有适用场景，不能一招鲜。

规则打分适合有明确正确答案或结构化结果的场景。比如“问模型的回复是否包含指定订单号”“是否在答案中提到了退款政策”，用正则或关键词就能判定。规则打分的优点是稳定、可解释、零成本，缺点是对开放性问题无能为力。

模型裁判打分，也就是LLM-as-Judge，适合语义相关、答案开放性强的场景。让一个更强的大模型按照既定的评分标准给被测模型的输出打分。这里要注意，裁判模型本身也可能有偏向性，不能完全信任，具体怎么把控我会在指标章节详细说。

人工复核适合小批量、高价值的样本。我们会在每周抽取5%到10%的评测结果，由业务同学重新打分，用来校准自动打分的准确率。三者形成一条分工链：规则打分做硬性判断，模型裁判做语义判断，人工抽查做整体校准。

3. 手把手实操：从评测集准备到自动化评测跑通

3.1 前置准备：需要哪些环境和配置

在跑通整套流程之前，先确认四样东西准备好：一个可访问的AllData环境，至少能连接你业务库并跑数据抽取任务；一套Coze-Loop环境或可执行源码，能启动评测服务；一份模型API访问凭证，至少一个被测模型的调用权限；一块存储空间，放评测集和结果数据。

如果你是从零开始尝试，建议先不要追求完整平台搭建，而是用最小可用方案跑通一版：用AllData手动导出一批业务问题存成JSONL文件，Coze-Loop本地跑一个评测任务，结果写到一个本地SQLite库里。这样能把链路概念串起来，之后再逐步替换成正式的库表和服务化部署。

3.2 从AllData构建评测集：抽数、清洗、标注、导出

第一步是明确从哪些表抽数据。以智能客服为例，我们一般从三张表取数：用户会话记录表、人工客服处理表、FAQ知识库表。用户会话记录提供真实问句，人工客服处理记录提供高质量的参考答案（客服的实际回复），FAQ知识库提供标准问答对。这三者合在一起，基本覆盖了评测集的题源。

第二步是清洗。真实业务语料非常脏，需要做几件事：去掉包含手机号、身份证号等敏感信息的样本，合并同一用户同一问题刷屏产生的重复问句，过滤掉长度异常的文本，把口语化的问句做轻度的规范化和脱敏处理。注意，清洗的目的是去噪，不是改写，尽量保持用户真实表达的样子，这样评测才有意义。

第三步是抽样和分桶。不能把所有数据都塞进评测集，要按场景和难度分层抽样。我们内部的经验是每个核心场景先抽100到200条作为基础评测集，其中困难样本占比20%到30%，关键场景再扩到500条左右。这样既能控制评测成本，又能保证结果有代表性。

第四步是标注和导出。每道评测题的结构可以定义为：输入、标准答案要点、场景标签、难度标签、可选的额外判断规则。导出格式用JSONL，每一行一个样本，字段清晰，方便后续评测任务直接引用。下面是一个简单的数据结构示例：

{ "id": "cs_refund_001", "scene": "售后退款", "difficulty": "normal", "input": "我昨天买的商品质量有问题，想申请退款，请问怎么操作？", "reference": "告知用户可在订单详情页提交退款申请，说明退款原因并上传凭证，审核通过后原路返回。", "check_rules": ["回复中应包含退款申请入口", "回复中不需要询问具体订单号"] }

3.3 配置评测任务：任务定义的参数设置

评测任务配置是连接评测集、模型和打分的枢纽。我习惯把所有配置写在一个YAML文件里，版本化地放到代码库中，这样每次评测都有据可查。一个典型的评测任务配置长这样：

task: name: "cs_refund_model_compare_v1" dataset: "cs_refund_set_v3" model_endpoints: - name: "model_A" endpoint: "http://llm-gateway.internal/v1/chat" model_name: "model-A-20240201" params: temperature: 0.2 max_tokens: 512 - name: "model_B" endpoint: "http://llm-gateway.internal/v1/chat" model_name: "model-B-latest" params: temperature: 0.2 max_tokens: 512 judge: type: "llm_judge" judge_model: "judge-model-latest" temperature: 0.0 vote_times: 3 execution: concurrency: 16 timeout_seconds: 30 retry_times: 3 report: metrics: ["correctness", "reference_hit", "reject_rate", "latency"]

几个关键参数我展开说一下。temperature设为0.2，是为了在保持一定生成稳定性的同时，不至于让答案过于机械；裁判模型的temperature必须设为0.0，否则同一个输出打两次分可能得到不同的分数；vote_times设为3，是让裁判模型对同一条输出评分三次取平均，降低随机波动。concurrency和timeout要根据你调用的模型服务的限流策略反复调优，先用16和30秒起步，观察失败率再调整。

3.4 把评测跑起来：单次任务与自动化回归

任务配置好后，执行命令非常简洁，因为所有复杂度都在配置和模块里收着了。启动一个评测任务可以这样：

coze-loop run --config cs_refund_model_compare_v1.yaml

跑完会在结果目录下生成一份评测报告，同时在结果库里写入明细数据。如果评测集有500条，三个模型，通常十几分钟就能全部跑完。首次跑通后，下一步是让评测变成自动化回归机制，不再靠人手动触发。

我们在Coze-Loop的调度上做了三件落地的事：第一，挂在定时任务上，每天凌晨对线上核心模型跑一遍核心场景评测集，早上查看过不过；第二，接入持续集成流程，当代码变更涉及Prompt或模型切换时，Pull Request自动触发一轮评测；第三，保留一份稳定评测集作为“黄金回归集”，每次模型版本更新后强制跑一遍，跑完和上一次结果对比，分掉超过阈值就阻断发布。这套机制跑起来之后，模型质量的波动基本能在半天内被发现。

4. 效果量化评估：指标矩阵、分数解读与阈值设定

4.1 从正确率到多维指标矩阵

评测不能只看一个指标，这是我在初期踩过最大的坑。当时我们只看“回答正确率”，结果一个模型在简单问题上全对，在困难问题上全军覆没，总分看起来却还行。后来我们把指标拆成了多维度矩阵，按场景和任务类型选用更合适的指标组合。

下表是我们内部常用的指标矩阵，覆盖大多数业务场景：

每一个指标都要定义清楚“在什么数据范围下计算、分子分母分别是什么”。比如拒绝率，我们定义是“模型未给出实质性回答的样本数除以评测集总样本数”，其中未给出实质性回答包括“抱歉我不知道”“这个问题我无法回答”这类兜底话术。定义模糊的指标，算出来就是自欺欺人。

4.2 样本量怎么定：评测集规模背后的计算逻辑

很多人会问评测集到底要多少条才够，这个可以用一个简单的抽样公式来估算。假设你要测的模型在某个场景的基准通过率是p，希望检测到的效果差异是d，置信度取95%，对应的Z值取1.96，那么最少需要的样本量大约是：

n = 1.96的平方乘以p再乘以(1-p)后除以d的平方

举个例子，假设你预估模型通过率在0.7左右，想检测出5个百分点的差异，那么n约等于1.96乘1.96乘0.7乘0.3再除以0.05乘0.05，算下来大约323条。也就是说，这个场景下评测集至少要有300多条样本，结果才能比较可信地反映出不同模型之间的真实差异。

实际操作中我们不会卡着这个公式来，而是把它作为一种判断依据：如果评测集只有50条，那你只能发现非常大的差距，细微的质量波动根本看不出来；如果核心场景能做到300到500条，常规的回归分析就基本够用了。样本量再往上增加，边际效果递减，但标注成本和评测成本会直线上升。

4.3 LLM-as-Judge结果怎么才可信

模型裁判打分是当前评测平台的主要推进方向，但很多人直接用却不知道它有多脆弱。裁判模型可能在评测过程中表现出系统性偏向：有的更喜欢条理清晰的长答案，有的对特定风格的回帖打分偏高，有的会在连续打分中产生位置偏差。

我们的应对措施有四个。第一，裁判温度固定为0.0，让单次打分尽量可复现。第二，对同一条样本打分多次取均值，至少3次，把波动摊平。第三，在评分标准里写死打分细则，用数字标尺而不是“优秀/良好”这种模糊词，比如“答案包含两个以上关键信息点得2分，缺少政策依据扣1分”。第四，定期做人工抽检，拿模型打分和人类打分做一致性对比，如果一致性跌到合理范围之外，就停下来检查评分标准或裁判模型是否出了问题。

4.4 报告解读与发布阈值

评测报告不能只是一堆数字堆在那里，得能支撑决策。我们的报告分三层：总分层给出加权综合评分或各场景得分；对比层给出当前模型和基准模型在每个维度的差值，标注出显著掉点的场景；样本层给出所有评测样本的明细，包括模型输出和分数，方便回溯。

发布阈值也要定得可操作。我们目前的规定是：新模型相比旧模型，核心场景综合得分不低于旧模型，关键子场景得分下降不超过一个设定幅度；鲁棒性指标不低于一个基准分数；成本如果增加，需要业务侧确认预算是否可接受。任何一条不满足，就进入人工评审，而不是直接放行。阈值不需要一开始就定得很严谨，但一定要定下来，并且随着评测集质量的提升持续收紧。

5. 完整案例：智能客服退款场景的模型自动化测评实录

5.1 场景定义与评测目标

拿我们最近做的一次评测来完整走一遍。场景是智能客服的售后退款咨询，核心诉求有两个：答案正确，能引导用户完成退款申请；政策引用准确，不出现说错退款时限、说错退款方式这类问题。

评测目标是三选一：从候选模型A、B、C中选出最适合该场景上线的模型，同时量化出各模型与当前线上版本的差距。评测集用AllData从业务库抽取了最近30天的真实会话记录，经过清洗、抽样、标注后，形成500条样本，其中简单题200条、中等题160条、困难题100条、对抗题40条。每道题都以人工客服的回复为参考基准。

5.2 评测执行与关键环节

三个候选模型走同一份评测集，相同的输入顺序、相同的参数设置。执行前我们还做了一件事：把三个模型的输出做了匿名化处理，在打分阶段，裁判模型看不到答案来自哪个模型。这一步虽然简单，但能有效避免位置偏差和品牌偏好。

500条样本加上3次投票打分，三轮评测跑了约40分钟。过程中遇到过一次限流，是某个模型的API在并发16的情况下触发了服务端限频。我们把该模型的并发降到8、重试间隔拉长后，任务跑完，失败样本数为0。这也是我在执行引擎章节反复强调并发配置的原因，限流在真实评测里太常见了。

5.3 结果分析与模型选型结论

评测结果汇总时，我们发现几个很有信息量的现象：

模型B综合胜出，尤其在困难题和对抗题上领先明显，政策引用准确率也比模型A高出8个百分点，说明它在复杂上下文理解上更强。模型C虽然正确率不差，但平均延迟3.5秒，对客服场景来说体验不可接受，直接出局。模型A的成本最高、效果最差，淘汰。

选型结论是模型B上线，同时针对模型B在对抗题上0.64的得分专门开了一个优化项，目标是下一次迭代把它提升到0.7以上。评测平台在这一轮的作用不是简单排名，而是把“谁更好”背后的原因也暴露出来了。

5.4 评测结果如何真正反哺AI应用落地

这次评测最直接的收益，是给业务方交出了一份可量化的选型说明。后面每次调Prompt、换模型版本，都能在同一套评测集上快速看到分数变化，不再需要反复拉人工评审。

更重要的是数据回流。评测明细写回AllData之后，我们开始把评测分数和线上真实反馈做关联分析，比如用户对某些会话点了“没有帮助”，这批会话对应的模型输出在评测集里是不是分数也偏低。一旦建立起这种关联，评测平台就成了业务质量和模型质量之间的桥梁，AI应用的迭代就有了明确方向。

6. 常见问题与排查技巧实录

6.1 评测结果不稳定，同一模型两次跑分数差异很大

这是评测平台最让人头疼的问题，通常不是模型本身的问题，而是打分链路的随机性。先查裁判模型的temperature，很多评测任务的默认参数是从对话场景复制来的，temperature偏高，导致打分忽高忽低。再查是否只打了一次分就结算，单次打分受随机波动影响极大，至少要多轮投票取平均。最后查评测集版本是不是被改动过，没有锁定版本导致前后两次评测数据不一致。

我们的处理方案很简单：裁判模型温度固定0.0；所有评测任务必须引用锁定的评测集版本ID；分数取三次投票均值。做完这三件事，相同配置的两次评测结果基本能稳定在正负1个百分点以内。

6.2 评测集出现数据泄漏，分数虚高

数据泄漏的表现是模型在评测集上得分极高，但上线后真实效果明显不及预期。原因是评测集可能和模型训练数据或线上历史数据混在了一起。我们当初就犯过一次：评测样本直接来自线上对话记录，而这些对话可能出现在公开语料里，被模型训练时看到过。

解决办法是建评测集时做三层隔离：优先用内部业务数据，且在入库前和已知的公开评测集、历史版本评测集做去重；从真实对话中抽样的样本要做改写处理，避免原文直接出现在题面中；定期用一份全新的高分标注意见样本做盲测，防止评测集被模型记忆污染。

6.3 评测任务执行中大量超时或被限流

线上评测遇到最多的执行问题是API限流和超时。原因通常是并发设置过高，超过了模型服务的配额，或者单条样本的输入过长，导致模型响应时间超过了任务的超时阈值。

排查时先看失败样本的模式：如果失败样本集中在固定时间段，大概率是限流，把并发调低，重试策略改为指数退避；如果失败样本集中在超时字段，检查输入文本长度，按场景给max_tokens和timeout做动态调整。另外，评测任务不要安排在同一时刻全部启动，给不同任务的启动时间做一点错峰，能显著降低被限流的概率。

6.4 评测指标区分度太低，所有模型都得满分

如果你发现不同模型在评测集上的得分都很高，拉不出差距，最可能的原因是评测集偏简单。我们的教训是第一版评测集里简单题占了七成，三个模型在简单题上全是满分，综合得分差异全靠那两成困难题撑着，样本量根本不够。

解决思路有三种：增加困难样本和对抗样本的比例，把评测集难度分布调成40%简单、40%中等、20%困难及对抗；增加更细粒度的人工复核，对关键场景做逐条打分而不是只看总体指标；补充一些边界条件样本，比如超长文本、多轮追问、语义模糊的输入，专门测试模型的鲁棒性。

6.5 常见问题速查表

7. 写在最后：一点个人体会

评测平台这套东西，技术上并没有想象中那么复杂，真正难的是让评测结果可信。模型评测本质上是建立一套“质量的度量衡”，度量衡不准，后面所有基于分数做的决策都会跟着跑偏。我自己的建议是不要一上来就铺很大的盘子，而是先锁定一个核心业务场景，把评测集建扎实，把自动化流程跑通，把指标口径统一，再慢慢往更多场景扩展。

另外，评测平台不是一次性的工程，它的维护成本和业务同样重要。评测集要持续更新，评分标准要跟着业务变化迭代，人工抽查要定期做。当你发现评测平台开始帮助团队提前发现问题、阻止一次模型变更带来的质量衰退时，前面投入的这些功夫就都值回票价了。