文本大模型评测，本质上是在给 LLM（Large Language Model，大语言模型）建立一套“考试体系”。

模型能不能理解问题，回答是否准确，遇到敏感问题会不会越界，在真实业务流程里能不能完成任务，都不能只靠几次人工试用来判断。评测的价值，就是把这些能力拆成可观察、可计算、可复盘的指标，再用稳定的数据集和评测流程持续衡量模型表现。

一套完整的大模型应用闭环通常长这样：

flowchart LR
    A[业务数据与知识沉淀] --> B[模型设计、训练或提示词优化]
    B --> C[能力评测]
    C -->|通过准入标准| D[上线]
    C -->|发现问题| E[数据补充 / 策略调整 / 模型迭代]
    E --> B
    D --> F[线上运营与反馈]
    F --> A

评测在这里不是上线前的一次性验收，而是贯穿模型迭代、版本回归、风险控制和业务优化的基础设施。没有评测，模型升级就只能依赖主观感觉；有了评测，才能回答三个关键问题：

1. 大模型评测要先分清三类能力

文本大模型评测最容易混乱的地方，是把“通用能力强”直接等同于“业务可用”。实际上，通用能力、领域能力、场景能力是三层不同的考察对象。

flowchart TB
    A[文本大模型能力评测] --> B[通用能力]
    A --> C[领域能力]
    A --> D[场景能力]

    B --> B1[语言理解]
    B --> B2[知识问答]
    B --> B3[逻辑推理]
    B --> B4[数学与代码]
    B --> B5[基础安全]

    C --> C1[医疗]
    C --> C2[金融]
    C --> C3[法律]
    C --> C4[教育]
    C --> C5[货运等垂直行业]

    D --> D1[客服]
    D --> D2[营销邀约]
    D --> D3[数据分析]
    D --> D4[办公助手]
    D --> D5[业务流程自动化]

1.1 通用能力：判断模型有没有基础能力

通用能力评测不依赖某个具体行业，主要考察模型的基础认知能力，例如语言理解、常识知识、推理、数学、代码生成、多轮对话和安全拒答。

MMLU Pro 这类 Benchmark（基准测试）就是典型代表。它通过标准化题目、统一评分规则和公开榜单，衡量模型在多学科任务上的表现。

通用能力评测的典型流程如下：

flowchart LR
    A[标准评测集] --> B[模型答题]
    B --> C[自动判分]
    B --> D[人工抽检或主观打分]
    C --> E[指标汇总]
    D --> E
    E --> F[模型排名 / 能力报告]

通用能力适合回答“这个模型底座是否足够强”，但它无法直接证明模型适合某个行业。一个模型在通用榜单上分数很高，仍然可能在医疗、金融、法律或货运场景中频繁犯错。

1.2 领域能力：判断模型懂不懂行业知识

领域能力评测关注模型对垂直行业的适配性。行业知识、专业术语、合规要求、业务规则都会进入评测范围。

比如医学领域的 CliMedBench，包含数万条中文医学评测样本，覆盖多个临床场景，用来评估模型在医学知识、临床推理和实际可用性方面的能力。

领域能力评测通常比通用评测多出三类要求：

领域能力评测解决的是“通用模型是否能进入专业行业”的问题。如果没有这一步，模型很容易出现“榜单高分、行业低能”的情况。

1.3 场景能力：判断模型能不能完成业务任务

场景能力评测最接近业务落地。它不只看模型答得对不对，还要看模型能不能在真实交互中推动任务完成。

例如客服场景要看一解率、用户问题识别、投诉风险控制；营销邀约场景要看身份确认、需求挖掘、异议处理、到店预约完成率；数据分析场景要看 SQL 生成准确率、指标解释能力和数据口径一致性。

场景能力有两个特点：

通用能力和领域能力更像“知识考试”，场景能力更像“岗位实操”。模型真正进入业务系统前，必须经过场景能力评测。

2. 评测方案的核心：维度、指标、评测集、评测方式

一套可落地的大模型评测方案，需要把三个问题讲清楚：

整体链路可以抽象成下面的流程：

flowchart LR
    A[明确业务目标] --> B[拆解评测维度]
    B --> C[定义指标和口径]
    C --> D[构建评测集]
    D --> E[选择评测方式]
    E --> F[执行评测]
    F --> G[生成报告]
    G --> H[定位问题并迭代]

2.1 评测维度：相当于考试大纲

评测维度决定“模型在哪些方面要被考察”。不同层级的评测，维度会有明显差异。

近几年评测体系有一个明显变化：传统自动指标的占比在下降，任务相关指标和人工指标的占比在上升。

原因很直接。BLEU、ROUGE 这类传统文本相似度指标，可以衡量生成文本和参考答案在字面上的接近程度，但无法完整判断业务回答是否真的有用。比如客服回答可能和标准答案用词不同，但解决了用户问题；也可能文字很相似，却遗漏了关键风险提示。

所以，业务场景更常使用“指标组合”：

2.2 评测指标：必须有明确计算口径

指标不能只写名称，还要定义清楚分母、分子和判定标准。否则不同评测人员会按不同理解打分，结果无法复现。

以对话类业务为例，指标可以这样定义：

安全类指标通常不能和普通效果指标简单加权。比如某个模型会话准确率从 93% 提升到 95%，但红线触及率从 0% 上升到 2%，这个版本就不能只看平均分。对高风险业务来说，红线指标应该作为上线门槛，而不是普通扣分项。

3. 评测集：模型考试里的“试卷”

评测集决定了模型会被什么问题考察。评测集质量不高，后面的打分再精细也没有意义。

3.1 三类评测集

通用评测集更适合横向比较模型底座；领域评测集更适合判断模型能不能进入某个行业；场景评测集更适合支撑版本迭代和业务上线。

3.2 评测集构建方式：人工主导，模型辅助

高质量评测集仍然离不开人，尤其是领域专家。专家负责定义任务边界、审核答案质量、设计难例和风险样本。模型可以参与数据扩写、问题改写、标签预标注、相似题生成，但不能完全替代人工审核。

常见构建流程如下：

flowchart LR
    A[收集真实问题或业务日志] --> B[脱敏与清洗]
    B --> C[任务分类与难度分层]
    C --> D[人工编写或模型辅助生成题目]
    D --> E[专家审核答案与标签]
    E --> F[去重与泄漏检查]
    F --> G[抽样试测]
    G --> H[形成稳定评测集]

评测集构建要特别注意三个问题：

3.3 动态评测集：用扰动和推理图生成新题

静态 Benchmark 用久了会被“刷榜”或过拟合，所以动态生成评测数据越来越重要。DARG（Dynamic Evaluation of LLMs via Adaptive Reasoning Graph Evolvement，基于自适应推理图的大模型动态评估框架）是一种典型思路。

它不是简单改写题干，而是从推理结构入手生成新问题：

flowchart LR
    A[已有评测题] --> B[抽取推理链路]
    B --> C[构建推理图]
    C --> D[调整复杂度或约束条件]
    D --> E[生成新问题]
    E --> F[校验答案正确性]
    F --> G[加入动态评测集]

这种方法的优势是可以保持题目能力点不变，同时改变表述、条件和推理复杂度，让评测更难被模型记忆。

4. 评测方式：人工、人机协同、机器自动化

评测方式决定“谁来阅卷”。文本大模型输出开放、多样、上下文相关，很难只靠一个统一公式打分，因此实际工程中通常混合使用三类方式。

4.1 人工评测：可靠但成本高

人工评测适合主观性强、语境复杂、风险高的任务。比如多轮客服对话是否真正解决问题，营销话术是否合规，长文本总结是否遗漏关键信息，都需要人工判断。

人工评测有两种常见形态。

一种是系统性评测：

flowchart LR
    A[确定评测规则] --> B[培训评测人员]
    B --> C[分发样本]
    C --> D[独立打分]
    D --> E[一致性检查]
    E --> F[仲裁分歧]
    F --> G[输出结果]

另一种是竞技场评测。多个模型回答同一个问题，用户或评审者投票选择更好的答案，再通过统计方法形成排名。

sequenceDiagram
    participant U as 评审者
    participant S as 评测系统
    participant M1 as 模型A
    participant M2 as 模型B

    U->>S: 提交同一个问题
    S->>M1: 请求回答
    S->>M2: 请求回答
    M1-->>S: 返回答案A
    M2-->>S: 返回答案B
    S-->>U: 隐去模型名展示两个答案
    U->>S: 投票选择更优答案
    S->>S: 更新统计排名

人工评测的主要问题是成本高、周期长，而且不同评测人员的尺度可能不一致。工程上通常需要双人标注、抽样复核和一致性统计来控制质量。

4.2 人机协同评测：当前更适合业务落地

人机协同评测的核心是“人工定义标准，模型负责批量初评，人工复核关键样本”。这类模式适合样本量大、评测规则相对稳定、但仍需要质量控制的业务场景。

LLM-as-a-Judge（用大模型充当裁判）是常见实现方式。裁判模型会根据评分标准，对候选模型的回答进行打分、分类或给出原因。

flowchart LR
    A[评测样本] --> B[待测模型生成回答]
    B --> C[裁判模型按规则打分]
    C --> D[异常样本筛选]
    D --> E[人工复核]
    E --> F[修正评分规则]
    F --> C
    C --> G[指标统计与报告]

一个裁判模型评分规则可以写成结构化配置，便于版本管理和复现：

metric: fact_accuracy
score_range: [0, 1]
definition: 判断回答中的事实信息是否与标准答案和业务知识一致
judge_instruction:
  - 如果回答完全正确，记为 1
  - 如果回答包含错误事实、虚构政策或错误地址，记为 0
  - 如果回答避开问题但未提供有效信息，记为 0
evidence_required: true
human_review:
  trigger:
    - judge_confidence < 0.8
    - contains_risk_keyword == true

裁判模型不能无条件信任。它可能偏好更长的回答，也可能被候选答案中的自信表达误导。比较稳妥的做法是：

4.3 机器自动化评测：快，但适用范围有限

机器自动化评测不依赖人工打分，适合答案客观、判定规则清晰的任务。

典型场景包括：

流程通常很简单：

flowchart LR
    A[固定评测集] --> B[模型生成答案]
    B --> C[规则或程序判分]
    C --> D[计算准确率、通过率等指标]

新的自动化方向开始引入 Agent（智能体）评测。Agent 不只是回答一句话，而是会调用工具、执行计划、访问外部系统并完成任务。评测系统要检查的不再只是最终文本，还包括中间动作是否合理、工具调用是否正确、任务是否完成。

flowchart LR
    A[任务输入] --> B[Agent规划]
    B --> C[工具调用]
    C --> D[中间结果校验]
    D --> E[最终输出]
    E --> F[自动评测引擎]
    F --> G[人工抽检异常案例]
    F --> H[生成指标报告]

不同评测方式的适用范围可以这样选：

5. 货运邀约场景中的半自动评测实践

业务场景评测和通用 Benchmark 最大的区别，是要把模型放进具体任务里看表现。以货运司机邀约为例，AI 邀约员需要和司机进行多轮沟通，确认意向、解释规则、处理异议，并推动司机完成到店激活或预约。

这类场景不是简单问答，至少包含四类能力：

5.1 评测集构建：真实数据和模拟数据混合

真实业务数据能反映用户表达习惯，但覆盖不一定完整；模拟数据可以主动覆盖边界场景和难例，但需要控制真实性。比较稳的做法是混合构建。

flowchart LR
    A[真实对话日志] --> B[脱敏清洗]
    B --> C[提取用户诉求和话术特征]
    C --> D[构造模拟用户人设]
    D --> E[生成模拟多轮对话]
    E --> F[人工审核与修正]
    B --> G[真实样本抽样]
    F --> H[最终评测集]
    G --> H

模拟用户人设不能只写一句“用户很着急”。它应该包含背景、诉求、表达风格和对话轮数等信息。

一条评测样本可以结构化保存，方便自动执行：

{
  "case_id": "invite_001",
  "scenario": "driver_invitation",
  "persona": {
    "status": "registered_not_activated",
    "intent": "ask_vehicle_eligibility",
    "style": "oral_repetition",
    "rounds": 5
  },
  "golden_facts": {
    "must_mention": ["到店激活", "携带身份证、驾驶证、行驶证"],
    "must_not_mention": ["保证收入", "虚假优惠"]
  },
  "success_criteria": {
    "task_completed": "用户确认预约或接受后续联系",
    "compliance_required": true
  }
}

5.2 指标体系：效果指标和风险指标分开看

邀约场景的指标不能只看“模型有没有回答”。更关键的是，它是否遵循业务流程、是否完成邀约目标、是否触碰安全红线。

其中，红线触及率应被设计成强约束。原因是业务模型的错误并不等价：少问一句材料要求，可能只是体验问题；承诺不确定收益或输出不合规内容，则可能带来真实风险。

5.3 评测执行：批量跑样本、裁判初评、人工复核

半自动评测的执行流程可以拆成五步：

flowchart LR
    A[准备评测集] --> B[批量调用待测模型]
    B --> C[保存多轮对话结果]
    C --> D[裁判模型按指标打分]
    D --> E[规则校验与风险扫描]
    E --> F[人工复核抽样和异常样本]
    F --> G[生成版本评测报告]
    G --> H[问题归因与下一轮迭代]

评测报告不应该只给一个总分，而要能定位问题：

5.4 版本对比：效果提升不代表可以上线

某个版本迭代中，模型表现可能出现下面的变化：

从普通效果指标看，会话准确率提升了 2 个百分点，主流程遵循准确率提升了 4 个百分点，说明模型在语义理解、流程执行或数据质量上有改善。

但红线触及率从 0% 上升到 2%，这是更值得关注的退化。对业务模型来说，不能把安全风险用平均分掩盖。更合理的决策方式是：

flowchart TD
    A[新版本评测完成] --> B{红线触及率是否为0或低于准入线}
    B -->|否| C[禁止上线，优先修复安全问题]
    B -->|是| D{核心业务指标是否提升}
    D -->|否| E[继续优化，不替换旧版本]
    D -->|是| F[进入灰度验证]
    F --> G[线上监控与回滚预案]

模型评测不是为了证明新版本更好，而是为了判断新版本在哪些方面变好、在哪些方面变差，以及这种变化是否满足上线条件。

6. 评测落地时最容易踩的坑

6.1 只看总分，不看指标结构

总分会掩盖关键问题。一个模型可能因为语言更自然拿到更高总分，但在事实准确率或安全指标上退化。业务评测应该把指标分层：安全指标作为门槛，核心业务指标作为主判断，体验指标作为辅助参考。

6.2 用通用榜单替代业务评测

通用榜单适合筛选模型底座，但不能替代业务评测。客服、邀约、风控、数据分析这些任务都有自己的流程和风险边界，必须使用场景数据单独验证。

6.3 评测集长期不更新

业务话术、政策规则、用户问题都会变化。评测集如果长期不更新，模型可能在旧题上表现稳定，却无法处理新问题。比较好的做法是维护三类集合：

6.4 裁判模型没有校准

LLM-as-a-Judge 可以提高效率，但必须定期和人工结果对齐。可以维护一批黄金样本，比较裁判模型和人工标注的一致率。一旦一致率下降，就需要调整评分规则或更换裁判模型版本。

6.5 没有把评测结果回流到迭代链路

评测报告如果只停留在分数层面，就很难真正推动模型优化。更有价值的是把失败样本按原因分类，然后分别进入知识库修正、提示词调整、训练数据补充、策略规则更新等环节。

flowchart LR
    A[失败样本] --> B{失败原因}
    B -->|知识错误| C[补充知识库或标准答案]
    B -->|流程错误| D[调整提示词或状态机]
    B -->|合规风险| E[增强安全规则和拒答策略]
    B -->|表达不佳| F[优化话术模板]
    C --> G[重新评测]
    D --> G
    E --> G
    F --> G

7. 一套可复用的大模型评测框架

从通用模型选型到业务上线，可以用一套分层框架组织评测工作：

评测体系成熟之后，模型迭代会从“凭感觉调参”变成“用数据定位问题”。每次版本升级都能回答清楚：

• 哪些能力提升了；
• 哪些指标退化了；
• 是否触碰上线红线；
• 问题样本应该回流到哪里；
• 新版本适合全量上线、灰度验证，还是继续修复。

参考标准与基准

• GB/T 45288.2-2025《人工智能 大模型 第2部分：评测指标与方法》
• ITU-T F.748.44：基础模型评估标准与基准测试
• NIST：AI TEVV（测试、评估、验证与确认）相关标准草案
• 中国信通院“可信 AI”评测体系与“方升”基准测试体系
• SuperCLUE 中文大模型基准测评框架
• FinDABench、FinEval-KR 等金融领域大模型评测基准
• MMLU Pro、CliMedBench、M3-SafetyBench、DARG 等公开评测研究与实践方向