新一代大模型选型：中文能力与指令遵循的评估方法

为什么不能只凭第一印象判断模型

模型上线初期，开发者通常会先用几组对话体验新版本。这种体感有参考价值，能快速发现明显退化或明显改进，但它不适合作为切换决策的依据。原因主要有三点。

第一，个人提问的样本偏窄。一个人常用的任务类型、措辞习惯和领域固定，测出来的结论只能代表自己的使用场景。

第二，响应速度容易受外部因素干扰。新版本刚上线时，服务端负载、网络链路、客户端渲染都会影响观感，同一个模型在不同时段的表现可能差别很大。

第三，用量消耗需要统计，不能靠感觉。同样的任务，输入输出长度、上下文累积方式不同，实际消耗会相差很多。

因此，更可靠的做法是把体感转化为可量化、可重复的指标，再用固定测试集验证。

四个核心评估维度

一、中文表达质量

中文表达评估关注三个层面：语法自然度、术语准确性和语体一致性。自然度指句子是否符合中文习惯，有没有明显的翻译腔或堆砌式表达。术语准确性指专业概念能否被正确使用，例如在技术文档中是否混用同一概念的不同说法。语体一致性指同一篇输出中，语气、称谓和格式是否前后统一。

评估方法建议采用盲评。准备一批典型任务，例如改写、摘要、技术解释、邮件撰写，分别由不同模型输出。评审者不知道输出来自哪个模型，按统一量表（如 1 到 5 分）打分，最后比较均值与分布。盲评能有效减少对新版本的先入为主。

二、指令遵循能力

指令遵循决定模型能否稳定接入自动化流程。常见的约束类型包括：

• 格式约束：输出为 JSON、Markdown 表格或指定条数的列表。
• 数量约束：字数上限、段落数、条目数。
• 内容范围约束：只回答某类问题，不涉及某些话题。
• 否定约束：不要出现某些词，不要使用某种结构。
• 多步骤约束：先做 A，再把结果转换为 B，最后按 C 格式输出。

这类指标可以用程序自动判定，比人工打分更稳定。下面的示例检查模型是否按要求返回包含五个元素的 JSON 数组：

import json
def check_json_list(output: str, expected_len: int = 5) -> bool:
    try:
        data = json.loads(output)
    except json.JSONDecodeError:
        return False
    return isinstance(data, list) and len(data) == expected_len

自动检查的通过率应单独统计，并与人工抽检结果对照。如果两者差距较大，说明检查规则本身需要修正。

三、响应速度与稳定性

速度指标应从服务端或调用侧埋点获取，不宜依赖页面观感。常用指标包括：

• 首 token 延迟：从发送请求到收到第一个输出 token 的时间，决定用户等待的起点。
• 输出速率：每秒输出的 token 数，决定长文本的完整生成时间。
• 尾部延迟：P95 或 P99 延迟，反映最慢那部分请求的体验。
• 超时率与错误率：稳定性的直接体现。

测试应覆盖不同时段和不同并发水平。只在单一时段测试，得到的结果可能只反映当时的负载状况。

四、用量与成本

用量评估的基本单位通常是 token，需要分别统计输入 token、输出 token 和上下文长度。同一任务，新模型如果输出更详细，输出 token 会增加，成本随之上升。反过来，如果模型一次就给出正确结果，减少了多轮追问，总体成本反而可能下降。因此应以“完成单个任务的平均总消耗”作为比较口径，而不是只看单次请求的数字。

另外，用量限额的刷新周期、并发配额也会影响实际可用性。这些条件应写入评估记录，避免把限额导致的等待误判为模型性能问题。

搭建可复现的评测流程

一套可复现的评测流程通常包括以下步骤。

1. 构建测试集。按业务场景分类，每类准备 20 到 50 条样例，整体规模在 100 到 200 条为宜。样例应覆盖常见请求和边界情况。
2. 固定运行参数。温度、最大输出长度、系统提示词等参数在对比期间保持一致，并记录模型版本号与测试日期。
3. 自动执行并记录。每条样例重复运行若干次，记录输出、耗时和 token 数。重复运行可以观察输出的稳定性。
4. 自动判定与人工抽检结合。能用程序判定的指标直接计算通过率，其余部分按比例抽样人工复核。
5. 生成对比报告。按维度列出新旧模型的指标差异，并标注置信度较低的结果。

下面是一个汇总脚本的示例，用于计算通过率和延迟分位数：

import statistics
import time
from typing import Callable
def evaluate(call_model: Callable[[str], str], cases: list[dict], repeat: int = 3) -> dict:
    passed, total, latencies = 0, 0, []
    for case in cases:
        for _ in range(repeat):
            start = time.perf_counter()
            output = call_model(case["prompt"])
            latencies.append(time.perf_counter() - start)
            total += 1
            if case["check"](output):
                passed += 1
    latencies.sort()
    p95_index = min(len(latencies) - 1, int(len(latencies) * 0.95))
    return {
        "pass_rate": passed / total,
        "p50_latency": statistics.median(latencies),
        "p95_latency": latencies[p95_index],
    }

其中 call_model 是对接任意模型服务的适配函数，由调用方自行实现。样本量过少时，P95 数值波动较大，应增加重复次数或样例数量。

切换判定规则

切换决策应基于事先定义的阈值，而不是测试结束后再临时判断。一个可参考的规则如下：

• 指令遵循通过率不低于现有模型，且关键约束类型没有明显退化。
• 中文盲评均分不下降，低分样例中没有集中出现的新问题。
• P95 延迟与超时率处于业务可接受的范围内。
• 平均单任务成本的增幅有合理解释，例如输出质量提升带来了更少的追问。

只要其中一个关键指标明显退化，就应暂缓切换，先分析原因。确认无误后，可以先用灰度方式，把小比例真实流量切到新模型，持续观察一到两周，再决定是否全量切换。

常见误区

误区一：只测试寒暄类或简单问答。简单问题难以区分模型能力，应加入复杂推理、长文本处理和多约束任务。

误区二：用单次结果下结论。模型输出具有随机性，同一请求多次运行结果可能不同，单次结果只能作为线索。

误区三：忽略上下文长度的影响。多轮对话后，上下文累积会同时影响成本和响应速度，测试时应包含长对话场景。

误区四：把体感当作性能数据。页面渲染、网络抖动和客户端缓存都会改变观感，性能结论应以服务端埋点为准。

误区五：只关注单点指标。速度提升但指令遵循下降，或质量提升但成本翻倍，都需要放在整体业务目标下权衡。

落地建议

测试集和评测脚本应纳入版本管理，每次模型版本变更时重新运行，并保留历史报告。这样可以比较不同时期的模型表现，也便于追溯问题出现的版本。

团队可以把评测维度写成一份固定清单，让每次选型都按同一标准执行。清单应包括中文质量、指令遵循、延迟分位数、单任务成本和稳定性五项，并约定各项的阈值与权重。

大模型能力随版本迭代变化较快，单次评测的结论有时效性。建议每个季度或每次重大更新后复测，结合真实业务反馈调整测试集，让评估结果持续贴合实际需求。