R

A02 评测对象层级辨析·模型／系统／产品／Agent eval

创建 2026-06-06 更新 2026-06-11 2 条双链 评测 专题 AI 整理

A02 评测对象层级辨析·模型/系统/产品/Agent eval

一句话定义：当有人说”这个东西的 eval 怎么样”，他到底在评模型本身的原子能力、RAG/Agent 系统的端到端表现、产品交付给用户的体验，还是用户最终拿到的业务结果？这是四个不同的层、用四套不同的指标、由四类不同的人负责验收。本节点提供一张四层对照矩阵，并论证：层级错配——拿模型 benchmark 当产品验收线——是 AI 选型与上线事故里最高发、也最隐蔽的一类。

一、为什么是”四层评测对象”，而不是”一套通用 eval 指标”

业界默认的错误框架是：把 eval 当成一件事——“找几个 benchmark 跑分，分高就好”。这个框架在 2021 年模型即产品的时代勉强能用；到了 RAG / Agent / 复合系统时代，它会系统性骗人。

正确的框架是先分层，再选指标。判断一个 eval 数字有没有意义，第一步永远是问”它测的是哪一层”。四层自底向上：

┌──────────────────────────────────────────────┐
│ 4. 结果层 Outcome   用户/业务的真实改变          │ ← 钱、留存、人效
├──────────────────────────────────────────────┤
│ 3. 产品层 Product   用户在真实界面里的体验        │ ← 采纳率、接管率、满意度
├──────────────────────────────────────────────┤
│ 2. 系统层 System    RAG/Agent 端到端编排表现      │ ← 任务完成率、检索命中、步骤效率
├──────────────────────────────────────────────┤
│ 1. 模型层 Model     基础模型的原子能力            │ ← MMLU/GPQA/SWE-bench
└──────────────────────────────────────────────┘

四层的关键区别不在”难度递增”，而在测量对象、可控变量、归因边界、负责人全都不同。下层分数高是上层的必要非充分条件：模型层满分不保证系统层能用，系统层达标不保证产品层有人用，产品层好评不保证结果层赚钱。每跨一层，都引入新的、不属于模型的变量——检索质量、脚手架工程、UI、用户预期、市场。

[!note] 抽象层级的镜像（手法层） 这张表与本工厂 0411 A02 是同一手法的镜像：0411 A02 把 Harness/Framework/Agent/Skill 钉到六层抽象上，治”组件名混用”；本节点把评测对象钉到四层上，治”指标层混用”。背后是同一个操作——先确定你在哪一层说话，再判断这句话对不对。至于这个”分层”在认识论上凭什么成立、以及它怎样反过来改写”该测什么”的操作结论，见本节点第七节末的「跨域呼应」段落（链入 0114认识论）。

二、四层对照矩阵（贴墙版）

维度① 模型层 Model② 系统层 System③ 产品层 Product④ 结果层 Outcome
测的是模型孤立的原子能力RAG/Agent 端到端管线用户在真实界面的体验业务/用户的真实改变
典型指标MMLU、GPQA、SWE-bench、GSM8KRAGAS 四维、任务完成率、检索命中率、步骤效率、错误恢复率采纳率、人工接管率、编辑距离、重试率、CSAT收入、留存、人效、客诉率、单位经济
可控变量仅模型权重模型＋检索＋脚手架＋Prompt＋工具上述＋UI/UX＋默认值＋引导上述＋定价＋GTM＋市场
归因边界干净（单一对象）中等（已耦合多组件）模糊（混入产品设计）极模糊（混入商业全局）
谁出的分模型厂/学术榜系统团队/MLE产品团队/数据分析业务/财务/增长
变化频率换模型才变改任一组件就变每次产品迭代都变季度级滞后
可被主动作弊高（数据污染、刷榜）中（脚手架灌水）低（真实用户难批量造假）最低（钱不会撒谎）
PM 该怎么用圈定候选模型选型决赛＋回归门禁上线验收＋灰度续投/砍项目决策

[!warning] 别把两件事说成一件——“可被作弊”≠“归因脏” 上表”可被主动作弊”这一行讲的是作弊难度（有没有人能主动把分数刷上去），它从模型层到结果层递减：钱最难假，所以结果层最难作弊。但第四节会反复强调”结果层归因最脏”，讲的是另一个维度——因果归因难度（这个数字到底是谁的功劳）。两者方向相反且互不蕴含：结果层既最难主动造假、又最难干净归因。R0 把这两个维度混用一句话带过，是个错误；这里拆清楚——下面”对角线规律”只就作弊/可比/语境干净度这一组说，不涉及因果归因。

矩阵的实战读法：越往下越脏（语境耦合越多）、越不可比、但也越难主动作弊；越往上越干净（单一对象）、越可比、却越容易被刷。 这解释了为什么模型 benchmark 满天飞而结果层数据稀缺——前者便宜可比但离钱远、且易被污染，后者贵且滞后但离钱近、难造假。PM 的核心手艺是别让前者冒充后者，也别因为结果层”最真”就以为它能告诉你因果。

三、每一层各自的”信号失真”陷阱

分完层不等于能用——每一层都有自己的失真源，PM 要知道每个数字在它那一层是怎么被污染的：

  • 模型层：数据污染与刷榜。MMLU 在 GPT-4 于 2023 年 3 月达到 86.4% 后，到 2024 年所有前沿模型停滞在 86–87% 区间，判别力丧失（Hendrycks et al., MMLU, ICLR 2021；饱和数据见证据简报）。SWE-bench Verified 经 OpenAI 内审发现每个前沿模型都有逐字复现 gold patch 的案例，人工筛查显示 32.67% 的成功 patch 存在解答泄漏，OpenAI 已于 2025 年停止汇报该分数（OpenAI 博客 ‘Why SWE-bench Verified no longer measures frontier coding capabilities’, 2025）。模型层的高分越来越多是”测过了”而非”会做”。
  • 系统层：脚手架污染与归因丢失。同一个模型，换个 agent scaffold 分数能差几十分——Claude Mythos Preview 在 SWE-bench Verified 上 93.9%，在更难的 SWE-bench Pro 上仅 45.9%，差距约 48 点（SWE-bench Pro, Scale AI + OpenAI, arXiv 2509.16941, 2025）。这意味着系统层分数里”模型贡献”和”工程贡献”已经无法干净拆分。
  • 产品层：偏好≠质量。产品层常用人类偏好/满意度，但人类投票与专家事实核查的一致率只有 72–83%（Chatbot Arena, Chiang et al., arXiv 2403.04132, ICML 2024）。冗长、谄媚、格式漂亮都会抬高满意度而不抬高真实质量——产品层好评里混着风格红利。
  • 结果层：滞后与混杂。结果层最真，但归因最难——这个季度留存涨了，是模型变好、还是营销发力、还是竞品自爆？结果层的”干净”是统计意义上的（钱不撒谎），不是因果意义上的（说不清谁的功劳）。

四、判断主轴 · 层级错配的三类高发事故 ⭐

这是本节点的命门。层级错配不是抽象的方法论问题，它是 AI 项目翻车的具体病因。三类最高发：

事故一：拿模型 benchmark 当产品验收线

症状：选型会上拍板”这模型 SWE-bench 70 分，比那个 60 分的强，就它了”，上线后客户投诉解决率不到三成。

为什么会错：把模型层指标（孤立能力）直接当成了系统层/产品层结论。SWE-bench Verified 的分数里裹着脚手架工程的巨大贡献，且 32.67% 涉及解答泄漏（OpenAI, 2025）——它压根不是”放进你的产品里能解决多少真实工单”的预测器。同一模型从 Verified 到 Pro 掉 48 点（SWE-bench Pro, 2025）就是铁证：换个更接近生产的测法，分数立刻塌方。

正确做法：模型 benchmark 只用于圈定候选（把明显不行的刷掉），决赛必须用自建的、贴你业务的系统层黄金集重测。参照 m205 的做法：200–500 条真实 query 人工标注，进 CI/CD。

真实反例：OpenAI 自己 2025 年宣布停止汇报 SWE-bench Verified 分数、改用 SWE-bench Pro——连出题方都承认 Verified 分数已不能代表前沿编码能力。一个连厂商都弃用的模型层数字，更不该被 PM 当产品验收线。

事故二：拿系统层指标当结果层承诺，向上汇报”任务完成率 90%”

症状：向老板汇报”Agent 任务完成率 90%“，老板据此承诺给客户，三个月后业务数据没动，项目被砍。

为什么会错：系统层的”任务完成率”和结果层的”业务改变”之间隔着产品采纳、用户信任、流程嵌入三道墙。90% 完成率在离线测试集上成立，不代表用户会真的把任务交给它（产品层采纳率可能只有 20%），更不代表完成的任务带来了增量价值（结果层）。把系统层数字当结果层承诺，是 demo 阶段最常见的过度承诺来源。

正确做法：系统层与结果层之间显式补上产品层桥梁指标——采纳率、人工接管率、编辑距离（参照 c14 的三层因果链：模型指标 → 产品体验指标 → 业务结果指标）。汇报时永远标清楚数字是哪一层、在什么集上测的。

真实反例：Arena 数据过拟合实验显示，把训练数据里 Arena 数据比例从 0% 提到 70%，ArenaHard 胜率从 23.5% 升到 49.9%（相对 +112%），但 MMLU 等分布外指标反而略降（‘The Leaderboard Illusion’, Singh et al., arXiv 2504.20879, NeurIPS 2025）。系统能在一个层（榜单分布）上猛涨而在另一层（通用能力）上不动甚至倒退——层间不传递是常态，不是例外。

事故三：层内”测对象”混淆——把 LLM-as-Judge 的裁判分当被测系统的真实质量

症状：用 GPT-4 当裁判给自家 RAG 输出打分，分数漂亮，但裁判本身的可靠性从未被验收。

为什么会错：这是更隐蔽的同层错配——评测工具（judge）和评测对象（被测系统）被混为一谈，工具的偏差被算进了对象的成绩。LLM-as-Judge 存在系统性偏差：交换回答顺序后 GPT-4 改变裁决的比例约 35%（位置偏差）；GPT-4 给自身输出的胜率高出 10%、Claude-v1 高出 25%（自我增强偏差）；对故意冗长回答，GPT-3.5/Claude-v1 的”上当”失败率达 91.3%（冗余偏差）（均见 Zheng et al., ‘Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena’, NeurIPS 2023, arXiv 2306.05685）。更狠的是 JudgeBench（Ye/Tan et al., arXiv 2410.12784, 2024）发现：在高难度知识/推理/数学/编程对上，GPT-4o 当裁判的表现仅略好于随机猜测。

正确做法：先验收裁判，再用裁判验收系统。标准动作是双向评测（同一对以两种顺序各评一次，只计双向一致的裁决，Zheng et al. 2023 推荐），并用 Cohen’s Kappa 量化裁判与人工金标的一致性——注意原始一致率会高估，GPT-4 的 Kappa 只有 0.84 而人类互评是 0.97（Eugene Yan 综述, 2024）。把 judge 的偏差当被测系统的能力，等于用一把没校准的尺子量身高还四舍五入往高了报。

真实反例：‘The Leaderboard Illusion’（Singh et al., 2025）揭露 Meta 在 Llama-4 发布前私测 27 个变体、只公布最高分——这正是”评测工具/平台本身被博弈”的产业级版本：当裁判（榜单）可被操纵，被测对象的排名就失真。LMArena 回应称实际私测增益约 +11 Elo、政策自 2024 年 3 月已公开，争议未平息——但无论增益多大，“裁判可被博弈”这一点双方都不否认。

五、产品 PM 视角补盲

跳出工程视角，层级错配在三处非技术维度上还会咬人：

  • 用户心理模型：用户不在任何一层”做题”，他们形成的是信任曲线。第一次接管/纠错的体验，权重远高于第 100 次成功——这是产品层指标（首次接管率）必须独立于系统层平均完成率单独看的原因。一个平均 90% 但首单翻车的 Agent，留存可能比平均 80% 但首单稳的更差。
  • 商业模式：结果层指标决定计价方式能不能成立。按结果付费（per resolved ticket）只有在你能干净度量结果层时才敢签；度量不了就只能按 token / 按席位收费——eval 能力直接约束商业模式选择。
  • 合规边界：在 Rick 的安全/国际化场景里，结果层还有一条隐藏轴——误伤的不对称代价。一个把”任务完成率”最大化的 Agent，可能在跨境合规审查里把该拦的放过（漏报代价远高于误报）。这类场景的验收线不能用对称的完成率，必须按 m207 的”可接受失败率 + HITL 断点”逐场景定义。

六、对手框架回应（接受 + 边界）

反方立场（强形式）：模型 benchmark 派会说——“分层太学究了。前沿模型 benchmark 和真实能力其实强相关，GPQA 都到 94%+ 超过 PhD 专家了，与其搞一堆自建评估集，不如信榜单、跟前沿模型走，省时省力。“（这是大量 PM 的真实默认操作。）

接受：这个立场有对的部分——在圈定候选这一步，模型 benchmark 确实是最便宜、最可比的过滤器；而且对于能力差距极大的两个模型，所有层的结论大概率一致（Arena 数据也显示候选差距极大时位置偏差近乎消失，一致性 98.8%，Zheng et al. 2023），这时分层确实是过度工程。强相关在”粗筛”尺度上成立。

边界与赌注：但我赌的是——决赛和验收尺度上，层间相关性会塌。GPQA 的 94% vs 65% 不能直接读成”AI 超过博士”：人类是无工具、限时、冷启动作答，模型经过海量相关语料训练，四选一格式本身也与真实科研推理不等价（GPQA 争议点，证据简报）。把粗筛尺度的强相关外推到验收尺度，正是事故一的成因。我的边界：当两个候选模型 benchmark 差距在 5 分以内、或应用场景与 benchmark 分布差异大时，榜单失去决赛资格，必须落到系统层自建集——这条边界之外，反方是对的。

failure scenario：如果你的产品恰好就是”做题型”应用（如纯知识问答、与 benchmark 同分布的任务），那么模型层 ≈ 系统层 ≈ 产品层，四层会坍缩成一层，本节点的分层开销纯属浪费。分层的价值与”应用分布偏离 benchmark 分布的程度”成正比。

七、PM 决策启示

  • 面试怎么用：被问”你怎么评估一个 AI 功能”，先反问”评哪一层”，再画四层矩阵——这一下就把你和”背了几个 benchmark 名字”的候选人区分开。点出”拿模型 benchmark 当产品验收是最高发事故”是高判断密度的信号。
  • 选型怎么用：建立”benchmark 圈定候选 → 自建系统层黄金集决赛 → 灰度看产品层 → 季度看结果层”的四道闸；任何环节想跳级（拿模型分直接上线）就是事故一在敲门。
  • 复现怎么用：搭 eval 管线时，先在文档里写明”本指标属于哪一层、测量对象是什么、归因边界在哪”——这一行注释能挡掉后续 80% 的”这个数字到底说明什么”的扯皮。

八、与已有节点的关系（升级对照）

本节点对三个旧节点做的是升高抽象层，不复述它们的事实基础：

  • 对照 c14：深化 + 前置。c14 给了”模型指标 → 产品体验指标 → 业务结果指标”三层因果链，但它从”模型层”起步、聚焦防 Goodhart。本节点在 c14 下方补了更细的”模型/系统”二分（c14 把 RAG/Agent 系统笼统归入”模型”），在上方把”产品/结果”拆成两层，并把 c14 的”防 Goodhart”重新定位为”层内信号失真的一个特例”。读 c14 之前先读本节点定层，c14 的因果链会更稳。
  • 对照 m205：层位归档。m205 的 RAGAS 四维、检索命中率、分层诊断逻辑，在本矩阵里被明确归为”系统层”指标。本节点不重复 m205 怎么测，而是回答 m205 没处理的”系统层数字向上（产品/结果）能不能直接外推”——答案是不能（事故二）。
  • 对照 m207：归因升级。m207 的 Agent 七维评估（任务完成率、步骤效率等）全部是系统层指标；本节点指出这些指标的共同盲区是”系统层→结果层不传递”，并把 m207 的”可接受失败率/HITL”接到了产品层与结果层（事故二、补盲三）。

九、关联节点

核心（必读）

延伸（可选）

  • 幻觉 — 校准失准是评测工具的前提性挑战（裁判自身也会幻觉）
  • Agent 产品评估的五个具体问题 — 系统层评估的 PM 实操清单
  • m209 - 推理成本控制手册 — 结果层”单位经济”的成本侧
  • Rick 写作 SABCD 评级体系 — “按体裁分轨”= 按任务类型分层评测的人文版
  • AI PM 知识图谱·总索引 — 全库总入口

十、修订日志

  • R0（2026-06-06）初稿：建立四层评测对象矩阵（模型/系统/产品/结果）；判断主轴写”层级错配三类高发事故”四件套；接 benchmark-contamination / LLM-as-Judge / arena-elo 三域证据接地；与 c14/m205/m207 写显式升级对照；与 0411 A02 做抽象层级跨域呼应；对手框架回应”信榜单走前沿”派（接受粗筛强相关 + 边界=决赛尺度塌相关）。待 grounding pass 复核 SWE-bench Pro 具体分数与 OpenAI 弃用声明措辞。
  • R1（2026-06-07）文件名修复：原文件名含 ”/“（A02 评测对象层级辨析·模型/系统/产品/Agent eval.md）被文件系统拆成「目录 A02 评测对象层级辨析·模型/ → 系统/ → 产品/ ＋ 文件 Agent eval.md」四段（三层嵌套目录，比 E03 的单层更严重），导致 Obsidian 链接 basename 退化为 Agent eval、丢失 A02 前缀编号与几乎整个标题，违反宪章 §3 命名规范 <前缀><序号> <标题>。修复：合并为单一文件 A02 评测对象层级辨析·模型／系统／产品／Agent eval.md——因标题已用 · 作”前缀↔标题”分隔符，四层斜杠改用全角斜杠 ／(U+FF0F) 而非 ·（避免与既有分隔符歧义；／ 文件系统安全且阅读自然），放回 01 概念辨析/，删除残留空目录 产品、系统、A02 评测对象层级辨析·模型（删前确认无 .DS_Store 等残留文件）；同步把 final_path 改为新名。全库 6 处入链（4 文件） 全部改指新 basename：A01「§九 关联节点」、S01「关联节点」、_总览「§收录什么 / §决策链 / §全索引」三处；其中 S02「导言 callout」那条 A02 评测对象层级辨析·模型 原本指向首层目录段、是一条死链，一并修正为新 basename。旧 basename A02 评测对象层级辨析·模型/系统/产品/Agent eval 与退化名 Agent eval 已加入 aliases 作兜底，确保历史/外部链接不产生死链。（注：本专题尚在 99Archive/_ai_review/ 待审区、未进 00Meta/索引.md，已 grep 确认零引用，按宪章原则二无需改索引。）