AI评测范式与理论框架 / Paradigms and Theoretical Foundations of AI Evaluation

AI 评测范式与理论框架

当一个团队"评测"一个 AI 系统时，它究竟在做什么？工业实践中，评测（Evaluation）经常被简化为一种仪式——运行基准、发布分数、撰写报告。然而，这种仪式掩盖了三种截然不同的认识论立场（epistemological stance）：行为主义（Behaviorism）、内在主义（Internalism）与功能主义（Functionalism）。每一种立场都独立地回答了三个根本性的问题：什么算作"证据"？什么算作"失败"？什么算作"成功"？如果不显式声明所采用的范式，那么所谓"评测战略"就只是一堆分数的累积，必然遭受 古德哈特定律（Goodhart's Law）的侵蚀、锚定效应（anchoring effect）的污染，以及指标博弈（metric gaming）的扭曲。

本章的核心主张是：在工业 AI 语境下，评测不是一项附属的"打分活动"，而是一门独立的工程学科。它拥有一套自成体系的理论框架，拥有可被工程化复用的方法论，并拥有内部可被推断、可被反驳、可被版本化的对象结构。我们将在本章完成三件事：第一，命名并区分三类历史范式，并论证为何 功能主义范式 在工业语境下取得主导地位；第二，构建一个被称为"评测立方体"（Evaluation Cube）的统一模型，把零散的离线基准、人类偏好、红队攻击（Red Team）与业务指标（KPI）映射到同一坐标体系内；第三，以一个真实的客服大模型评测项目为例，展示如何在该立方体中完成对每一次评测任务的定位。章末会留下一份"评测战略文档"（Evaluation Strategy One-Pager）的标准模板，为后续章节的统计学基础、心理测量学推断与闭环工程埋下锚点。

需要预先声明的是，本章只解决"框架"，不解决"证据强度"。立方体中的每一个点最终都必须穿过严格的统计推断与心理测量学（psychometrics）校准，才能从"印象"（Impression）晋升为"证据"（Evidence）。这正是第 2 章将要承接的工作。

---

1.1 评测的三类历史范式及其局限性

人工智能评测并非从大语言模型时代才开始。回望符号主义（symbolism）、连接主义（connectionism）以及当下的生成式 AI（generative AI），评测范式经历了三次重心迁移。理解这三次迁移，是理解为何今天的工业团队必须采用某种"混合范式"的前提。

1.1.1 行为主义范式：把模型当作黑箱

行为主义范式的核心主张极其简洁：模型的可观测输出即全部真相。一个分类器在测试集上的准确率、一个问答模型在 MMLU 上的得分、一个对话系统在 A/B 实验中的胜率——这些就是评测的全部。这一立场可以追溯到图灵的 模仿游戏（Imitation Game），并在过去二十年的机器学习实践中成为默认框架。它之所以长期主导工程界，原因有三：第一，可观测性（observability）——输出可以被稳定地采集、存储与复现；第二，可比较性（comparability）——不同模型之间的输出可以聚合为标量分数，从而产出排行榜；第三，可自动化（automation）——评测流水线可以脱离人工干预，连续运行于数千个样本之上。

然而，行为主义范式存在三个系统性局限。第一，分布外鲁棒性的失明。基准分数只能刻画模型在样本分布内的期望性能，对 分布偏移（distribution shift）、对抗扰动（adversarial perturbation）与 用户长尾意图（long-tail user intent）几乎完全失明。一个在 GSM8K 上达到 92% 准确率的模型，可能在真实客服场景的"带噪声对话 + 多轮依赖 + 工具调用失败回退"这一复合情境下出现 40% 以上的功能崩溃。第二，古德哈特定律的内生失稳。一旦某个基准被确立为"行业标准"，它立即成为优化目标本身；随之而来的，是基准污染（benchmark contamination）、过拟合于测试集（test-set overfitting）以及"刷榜式微调"（leaderboard-driven fine-tuning）。MMLU、HumanEval、GSM8K 都已出现不同程度的污染信号。第三，价值维度的不可见。行为主义不直接关心"是否安全"、"是否诚实"、"是否歧视"——这些属性只有在被外部翻译为可观测输出之后，才能进入行为主义框架。但这种翻译本身就是范式承诺：一旦翻译失败（例如把"安全"翻译为"是否触发关键词过滤器"），整个评测就退化为对代理指标的度量，而非对真实价值的度量。

因此，纯行为主义不足以承担工业 AI 的评测责任——这是我们必须引入第二种范式的根本理由。

1.1.2 内在主义范式：打开模型内部

针对行为主义对价值维度的忽视，研究界在 2010 年代之后逐渐发展出 内在主义范式（Internalism）。它主张：模型的内部表征与计算过程本身是评测对象。代表性方法包括：表征探测（probing classifier）、注意力归因（attention attribution）、因果中介分析（causal mediation analysis）、机械可解释性（mechanistic interpretability）等。一句话概括：内在主义把模型视作一个 可被解剖的有机体（dissectable organism），而不是一个只输出对错的函数。

内在主义的优势在于，它能够回答行为主义永远无法回答的问题——"模型为什么这么做"。例如，通过激活补丁（activation patching）实验，研究者可以定位一个拒绝回答有害请求的行为对应到哪些电路（circuit）；通过线性探针（linear probe），可以判断模型是否在某一层隐空间中编码了某种属性。这些信息对工业部署极具价值：它们支撑了模型可解释性报告、模型卡（model card）的撰写、对监管的回应与对客户的审计。然而，内在主义同样面临三个深刻挑战。

第一，因果鸿沟。内部表征与外部行为之间并不存在严格的因果等价。一个探针在第 18 层检测到"虚假信息"的高激活，并不意味着模型在第 18 层之后的解码阶段仍会输出虚假信息。干预实验（interventional study）与 观察实验（observational study）之间存在系统性差距，这是可解释性研究最棘手的部分。第二，资源不对称。完整的内在主义评测往往需要访问模型全部权重与激活，这在闭源模型、托管 API 或边缘部署场景下几乎不可得。第三，过度承诺。在大量实际工程场景中，我们真正关心的是"模型在用户的某个长尾输入下会输出什么"，而不是"模型第 27 层第 4,392 个神经元是否被激活"。内在主义如果不能连接到行为后果，就只能停留在科学好奇心层面。

由此可以得出：纯内在主义也不能独立承担工业评测——这是引入第三种范式的理由。

1.1.3 功能主义范式：把评测锚定到任务效用与安全效用

工业语境下真正可用的范式，是 功能主义（Functionalism）。它的核心承诺是：评测的对象不是模型本身，而是模型在特定任务上产出的效用（utility）；并且这种效用必须至少在一个 双维度空间 中被同时测量——任务效用（task utility，即能否正确完成任务）与 安全效用（safety utility，即能否在不违反约束的前提下完成任务）。这一范式可以追溯到 Newell（1982）提出的"知识层级"（knowledge level）与"符号层级"（symbol level）的区分，也可以追溯到更晚近的 AI 对齐（AI alignment）研究中对"helpful / harmless / honest"的三角约束。

功能主义之所以在工业上取得主导，原因不在哲学倾向，而在工程可操作性。第一，它有清晰的失败定义。任务效用给出"做对没有"，安全效用给出"做坏了没有"。两者缺失其一，部署都会被否决。第二，它在交付物层面闭合。一个对话机器人、一份报告生成工具、一个代码补全助手——它们的"成功"都可以被还原为这两个维度的加权得分，并最终还原为客户能感知到的指标。第三，它兼容多模态证据。功能主义不要求所有评测都是行为主义的——它允许引入人类偏好（preference）的群体判断，允许引入红队对抗生成的极端案例，允许引入业务侧的真实运行数据。于是，离线基准、人类评估、红队、业务 KPI——这些看似散乱的评测手段，被功能主义统摄在同一框架之下。

但功能主义绝非银弹。它至少有四个常见误用必须被指出。误用一：把任务效用窄化为单一基准分数。一个产品可能并不在意 HellaSwag 跑多少分；它在意的可能是该指标的某个特定子能力。误用二：把安全效用窄化为关键词命中。这是一个极其常见的工程错误——使用简单的黑名单匹配来检测"有害输出"，但这既漏报又误报。误用三：忽略效用之间的张力。任务效用与安全效用不是单调相关的。一个模型完全可以通过"无脑拒绝"获得满分的安全效用，但任务效用归零。误用四：混淆"评估效用"与"展示效用"。很多团队既有的所谓"评测分数"实际上是给领导看的宣传物，而不是给工程团队用的决策证据。这两种用途在指标设计上应该被严格分开。

至此，三类范式的边界已经明晰：行为主义回答"做了什么"，内在主义回答"为何这样做"，功能主义回答"做得够不够好且够不够安全"。在工业语境下，功能主义是主导范式（governing paradigm），其余两者则是支撑范式（supporting paradigm），各自服务于不同的诊断目的。

---

1.2 评测立方体模型：能力 × 对齐 × 情境

把功能主义范式工程化，我们需要一张足够干净的"地图"，让任何一次具体的评测活动都能被定位到这张地图的某一坐标。这就是 评测立方体（Evaluation Cube）的由来：它由三条互相正交的轴构成——能力维度（Capability）、对齐维度（Alignment）与 情境维度（Context）。立方体中的每一个点 $(C, A, X)$ 都对应一次具体的、可被工程化复用的评测任务。

1.2.1 三轴的定义与可测性

能力维度 $C$：衡量模型"会做什么"。这不是单一指标，而是一个能力向量（capability vector）。根据当代大语言模型评测的成熟分类，它至少包括以下子维度：知识（Knowledge，覆盖事实与世界常识）、推理（Reasoning，覆盖数学、逻辑与多步规划）、代码（Code，覆盖生成、调试与重构）、工具使用（Tool Use，覆盖 API 调用、函数选择与失败回退）、多语言（Multilingual）、长上下文（Long-Context）。每一个子维度都有可被独立测量的基准或子基准，例如代码可对应 HumanEval、MBPP、LiveCodeBench；推理可对应 GSM8K、MATH、ARC-AGI；工具使用可对应 BFCL、τ-bench 等。

对齐维度 $A$：衡量模型"应不应该这样做"。这是评测立方体中最容易被低估的一轴。它至少包含：安全性（Safety，覆盖有害指令、越狱攻击 jailbreak、双用途滥用）、诚实性（Honesty，覆盖幻觉、置信度校准、对不确定性的承认）、公平性（Fairness，覆盖偏见、社会刻板印象与差异化待遇）、稳健性（Robustness，覆盖对抗提示、噪声注入、分布外场景）。对齐维度的核心特点是：它衡量的是模型在"压力下"的边界行为，而非"惯常下"的平均行为。因此，它极度依赖红队、对抗生成（adversarial generation）与压力测试（stress test）。

情境维度 $X$：衡量模型"在何种条件下这样做"。这是工业评测独有、学术评测经常缺位的一轴。它至少包含：领域（Domain，覆盖金融、医疗、法律、客服等垂直语境的迁移能力）、用户状态（User State，覆盖新手、专家、愤怒、焦虑等不同心理状态下的输入）、渠道（Channel，覆盖 Web、APP、语音、API、嵌入式等交互通道）、延迟预算（Latency Budget，覆盖 P50/P99 响应时间下的可接受度）、多轮依赖（Multi-turn Dependency，覆盖跨轮指代、上下文漂移与状态维护）。情境维度的本质，是承认 "同一道题，在不同情境里是不同的题"。

三轴的相互正交性不是数学意义上的严格独立，而是评测目的上的解耦：能力对齐于"做对与否"，对齐对齐于"做坏与否"，情境对齐于"在哪做、做给谁"。三者共同决定了一次评测任务的"全息坐标"。

1.2.2 四类评测方法在立方体中的映射

工业团队在实践中常用的四类评测方法——离线基准（Offline Benchmark）、线上 A/B 实验（Online A/B Test）、红队（Red Team）、业务 KPI（Business KPI）——并非互相替代关系，而是分别定位在立方体的不同位置。下表与图示给出了标准化映射。

| 评测方法 | 主要轴 | 次要轴 | 适用阶段 | 证据强度 | |---|---|---|---|---| | 离线基准 | Capability 高 | Context 低、Alignment 低 | 训练后 / 发布前 | 中（受污染） | | 线上 A/B 实验 | Capability 中、Context 高 | Alignment 中 | 发布后 / 灰度 | 高（真实流量） | | 红队 | Alignment 高 | Capability 中、Context 中 | 发布前 / 持续 | 高（极端样本） | | 业务 KPI | Context 极高、Capability 中 | Alignment 低 | 长期 / 闭环 | 高（业务相关） |

```mermaid flowchart TD CUBE[Evaluation Cube / 评测立方体]

CUBE --> CAP[Capability Axis / 能力维度] CUBE --> ALN[Alignment Axis / 对齐维度] CUBE --> CTX[Context Axis / 情境维度]

CAP --> CAP1[Knowledge] CAP --> CAP2[Reasoning] CAP --> CAP3[Code] CAP --> CAP4[Tool Use]

ALN --> ALN1[Safety] ALN --> ALN2[Honesty] ALN --> ALN3[Fairness] ALN --> ALN4[Robustness]

CTX --> CTX1[Domain] CTX --> CTX2[User State] CTX --> CTX3[Channel] CTX --> CTX4[Latency Budget]

M1[Offline Benchmark / 离线基准] M2[Online A/B / 线上实验] M3[Red Team / 红队] M4[Business KPI / 业务闭环]

M1 --> P1[Position: high CAP, low CTX, low ALN] M2 --> P2[Position: high all three] M3 --> P3[Position: high ALN, mid CAP, mid CTX] M4 --> P4[Position: high CTX, mid CAP]

P1 --> CUBE P2 --> CUBE P3 --> CUBE P4 --> CUBE ```

离线基准通常位于立方体的 Capability 一侧，而 Context 与 Alignment 两个维度几乎被抽空。这是因为绝大多数基准的样本来自与生产完全不同的分布，且不主动触发对抗场景。一个具备 92% GSM8K 准确率的模型，在客服对话的真实 Context 下可能跌至 70%。红队则在立方体的 Alignment 一侧 重锤，它通过对抗性生成扩展样本空间，使模型在边界条件下的行为被显式测出。线上 A/B 实验 试图同时覆盖三轴：它使用真实用户流量，因此具备高 Context；它通过随机分流，因此可推断因果，因此具备高 Capability 信号；它附带安全过滤与护栏监控，因此也覆盖了 Alignment。业务 KPI 则是一种"Context 极重"的评测：它是产品在客户心目中的最终得分，但对能力与对齐的分解能力有限，必须与其他评测正交使用。

理解这个映射关系之后，一个常被工程团队忽视的推论是：单一评测方法永远只能给出立方体的一个投影。没有任何一个孤立的方法能够同时完整地描述一个系统。这就是为什么"评测工程"必然是"多方法联合"（multi-method ensemble）的工程。

1.2.3 立方体内部的"对角线"问题

把方法映射到立方体之后，还需要警惕一个隐性问题：立方体内部的"对角线"（diagonal across the cube）。某些最危险的失败模式，并不是发生在某个单一坐标的低分，而是发生在坐标间的耦合失配。例如：一个高 Capability 但低 Alignment 的模型，可能是一个"高度自信地胡说八道"的灾难；一个高 Capability 但低 Context 的模型，可能是一个"在测试集封神、在生产环境崩溃"的英雄；一个高 Alignment 但低 Capability 的模型，可能是一个"什么都不敢做"的安全摆件。

工业评测的成熟度，恰恰体现在团队是否能够识别并测量这些 跨轴耦合（cross-axis coupling）。这意味着：一个评测项目不能只报告"能力得分 85"、"安全得分 95"两个独立数字，它还必须报告二者的耦合指标——例如"在高能力任务中触发的安全事件数"、"在长尾领域上下文下的能力衰减率"。我们将在第 5 章"红队评测工程"与第 8 章"业务闭环设计"中回到这个耦合测量的问题。

---

1.3 评测作为证据而非印象

把评测与"打分活动"区分开来的，是