大模型升级评估实操：从指标选型到结果验证

一、教程目标

本教程帮助读者完成一次完整的大模型版本评估。完成后，你将得到四项产出：一份与业务对齐的评估指标清单，一套可复现的测试集，一份自动化评测报告，以及一条基于数据的替换或保留建议。

演示视频、品牌声誉、公开榜单排名都能提供参考，但它们无法代替你自己的业务场景测试。公开榜单使用的题目和你的真实请求分布通常不同，演示样例也经过挑选。评估的核心是回答一个问题：在我的业务数据上，新版本是否比当前版本更好，好在哪里，代价是什么。

二、适用读者与适用场景

适用读者

• 开发者：负责接入模型接口，需要确认提示词、参数和输出解析是否适配新版本。
• 算法或应用工程师：负责效果优化，需要量化不同版本在各类任务上的差异。
• 运维人员：关注延迟、错误率、并发和成本，需要验证新版本能否承受现有流量。
• 技术负责人与企业选型人员：需要基于证据做替换决策，并向团队解释理由。

适用场景

• 场景一：现有模型需要升级到同系列的新版本，希望确认效果提升是否覆盖业务核心需求。
• 场景二：在多个模型之间选型，需要统一口径比较效果、成本和延迟。
• 场景三：按任务路由到不同模型，需要为每类任务找到性价比最高的模型。

三、前置准备

1. 明确业务场景清单

先列出系统真正承担的任务，例如客服问答、代码辅助、文档摘要、结构化信息抽取、图片理解等。每个任务写明输入形式、输出要求和失败代价。失败代价高的任务，例如涉及金额或合规判断的输出，需要更严格的评测标准。

2. 获取模型服务访问权限

确认已具备目标模型的调用权限，并通过密钥管理服务或环境变量保存访问凭证。密钥不要写入代码仓库或日志。评测账号应只拥有完成评测所需的最小权限，并设置用量上限，防止脚本异常导致费用失控。

3. 准备测试数据

测试数据主要有三个来源：

• 线上真实请求经过脱敏后抽样，最贴近真实分布。
• 业务专家人工编写的典型样本与边界样本。
• 公开基准中与业务相关的子集，用于与行业通用水平做参考。

脱敏需要去除手机号、身份证号、地址、企业内部编号等个人或商业敏感信息。每类场景建议准备数百条样本，样本量太少时，分数差异很可能只是随机波动。

4. 搭建基础环境

准备一台可以访问模型服务的机器或容器，安装常用的 Python 运行环境，并准备用于存储结果的数据库或文件目录。建议把测试集、评测代码和结果文件放入版本管理，每次评测都记录代码版本、测试集版本和模型版本号，保证结果可以复现。

5. 确认预算与时间窗口

评测会产生调用费用，并可能占用接口配额。提前估算样本数量与平均输入输出长度，计算总消耗，并避开业务高峰期执行大批量测试。

四、实施步骤

步骤一：把”效果好不好”拆成可测维度

“效果好”是一个模糊的说法，无法直接测量。需要把它拆解为若干可以独立判断的维度。常见维度如下：

维度	含义	典型判断方式
指令遵循	是否严格按照格式、字数、步骤等要求输出	规则校验
事实准确性	回答是否与参考资料或标准答案一致	精确匹配或人工核对
代码能力	生成的代码能否通过单元测试	执行测试用例
推理能力	多步计算或逻辑题的结论是否正确	与标准答案比对
长文本理解	在长输入中定位和总结信息的准确程度	关键信息召回率
安全合规	对违规请求的拒答是否恰当，对正常请求是否误拒	分类标注后统计
多模态理解	对图片、表格等输入的理解准确程度	人工标注对照
延迟与成本	首字延迟、整体耗时、输入输出令牌数	日志统计

拆解完成后，为每个维度设定”合格线”。合格线应来自业务需求，例如”结构化抽取的字段准确率不低于当前版本”，而不是来自某个榜单的名次。

步骤二：构建测试集并划分开发集与保留集

测试集的质量决定评估结论的可信度。每条样本建议包含以下字段：

• id：样本唯一编号，便于追溯。
• category：所属任务类别。
• input：模型输入内容。
• reference：标准答案、参考要点或评分规则。
• difficulty：难度标签，用于分层分析。

测试集划分为两部分：开发集用于调整提示词和评测脚本，保留集只在最终评测时使用一次。如果反复根据某个测试集调整提示词，分数会虚高，因为提示词已经针对这些样本做了过拟合。保留集能够反映新版本在未见数据上的真实表现。

步骤三：固定评测口径

同一批样本在不同条件下的结果可能差别很大。评测前需要固定以下条件，并把它们写入配置文件：

• 系统提示词及其版本号。
• 采样温度。温度越高，输出随机性越大，结果越难复现。做效果对比时，建议使用较低温度。
• 最大输出长度。长度上限会截断部分回答，影响判分。
• 请求超时与重试次数。
• 样本顺序与批次大小。

每个版本至少运行两到三次，取平均值并记录标准差。若同一版本两次运行的分数差异已经接近两个版本之间的差异，说明当前的评测设置无法区分两者，需要扩大样本量或收紧口径。

步骤四：编写评测脚本

评测脚本的核心流程是：读取样本，构造请求，调用模型，记录输出，判分，汇总结果。下面是通用伪代码，实际实现可替换为所用语言和框架的对应写法。

def run_eval(model_client, dataset, config):
    results = []
    for sample in dataset:
        prompt = build_prompt(sample["input"], config["system_prompt"])
        try:
            response = model_client.generate(
                prompt=prompt,
                temperature=config["temperature"],
                max_tokens=config["max_tokens"],
                timeout=config["timeout"],
            )
        except TimeoutError:
            results.append({"id": sample["id"], "status": "timeout"})
            continue
        score = grade(sample, response.text)
        results.append({
            "id": sample["id"],
            "category": sample["category"],
            "score": score,
            "latency_ms": response.latency_ms,
            "output_tokens": response.output_tokens,
            "status": "ok",
        })
    return results
def summarize(results):
    summary = {}
    for r in results:
        if r["status"] != "ok":
            continue
        bucket = summary.setdefault(r["category"], {"n": 0, "score_sum": 0.0})
        bucket["n"] += 1
        bucket["score_sum"] += r["score"]
    return {
        cat: round(v["score_sum"] / v["n"], 4)
        for cat, v in summary.items()
    }

脚本需要注意两点。第一，超时和报错的样本必须单独记录，不能直接丢弃。直接丢弃会让新版本在超时率高的情况下仍然显示较高的平均分。第二，汇总时应按类别统计，不能只输出一个总分。总分会掩盖某类任务的明显退化。

步骤五：选择判分方式

判分方式大致分为三类：

1. 规则判分：通过精确匹配、正则表达式、JSON 结构校验或单元测试执行来判断。结果稳定、可复现，适合格式、字段抽取、代码等有明确标准的任务。
2. 模型辅助判分：让另一个模型按照评分细则给回答打分。它适合开放性问答，但存在偏好问题，例如倾向于给更长、更完整的回答打高分。使用时需要做三件事：随机打乱候选回答的顺序，隐藏模型身份，并用一小部分人工标注样本校准判分结果的一致性。
3. 人工判分：由业务专家对抽样样本进行盲评。人工判分成本高，但用于校准自动判分和处理争议样本时不可替代。

建议组合使用三种方式：能用规则判分的任务优先用规则，开放任务用模型辅助判分，并定期抽样人工复核。

步骤六：对比结果并判断差异是否可信

拿到两个版本的结果后，逐类别比较分数差值。判断差值是否可信，可以参考以下做法：

• 计算每个类别的置信区间。样本量越小，区间越宽。
• 对同一批样本做配对比较，观察新版本在哪些样本上更好，在哪些样本上更差，并统计两者的数量。
• 检查差异是否集中在少数样本上。如果提升只来自几条异常样本，结论就不稳定。

例如，某类任务新版本平均分高出 2 个百分点，但置信区间跨越零点，这一结果应视为”无法确认提升”，而不是”已经提升”。

步骤七：小比例灰度上线

离线评测无法覆盖所有线上情况。确认离线结果符合预期后，可以用小比例流量进行灰度验证：

• 初始流量设置为总流量的很小比例，例如 1% 到 5%，并保留快速切回原版本的开关。
• 监控指标包括接口错误率、超时率、首字延迟、整体耗时、单次请求成本，以及业务侧的采纳率或人工转接率。
• 按时间段观察，避免只看某一时段的数据。
• 达到预设观察时长且指标稳定后，再逐步扩大比例。

灰度期间如果出现错误率上升、延迟超过阈值或关键业务指标下降，应立即回切，并分析原因后再重新评测。

五、配置说明

评测与接入过程中的关键配置项及其风险如下：

配置项	常见取值思路	风险
温度	对比评测用较低值，创意类任务可适当提高	温度过高导致结果不可复现；过低可能使输出单一
最大输出长度	按任务的正常回答长度加适当余量设置	设置过小会截断回答；设置过大增加成本和延迟
超时时间	参考历史 P95 或 P99 延迟设置	超时过短会误判为失败；过长会阻塞队列
重试次数	通常设为 1 到 2 次，配合指数退避	重试次数过多会放大限流压力，并重复计费
并发数	从较低值开始，逐步提高并观察错误率	并发过高触发限流，导致大量超时
系统提示词版本	每次修改都记录版本号	不记录版本会使结果无法追溯

这些取值没有统一标准，应根据业务延迟要求、预算和接口限制逐项确定，并在评测报告中写明。

六、结果验证

评测或上线是否成功，可以从以下几个方面判断：

1. 达到合格线：每个核心维度的分数都达到步骤一中设定的阈值。
2. 相对基线无明显退化：关键类别的分数不低于当前版本，且差异超出随机波动范围。
3. 可复现：同一配置多次运行的结果在可接受范围内一致。
4. 格式与解析稳定：输出结构化内容的解析成功率达到要求，解析失败样本有明确的分类记录。
5. 线上指标符合预期：灰度期间错误率、延迟和业务指标与离线预估一致，没有出现意外波动。

只要有一项核心指标不达标，就应暂缓全量替换，先分析原因。

七、常见问题与排查

问题一：多次运行分数波动大

• 可能原因：温度较高导致输出随机；超时重试使部分样本被计为失败；样本量太小。
• 排查思路：先检查日志中的超时与重试记录，再把温度调低，最后增加样本量或多次取平均。

问题二：离线分数高，线上体验却没有提升

• 可能原因：测试集分布与真实请求不一致；测试样本被纳入提示词调优，产生过拟合；评分标准与用户真实需求有偏差。
• 排查思路：对比测试集与线上请求的类别分布，检查保留集是否真正未被使用，并抽查线上失败案例，补充到测试集中。

问题三：延迟明显升高

• 可能原因：新版本输出更长，导致生成