一、评测为什么要从"战术"升到"战略"

作为天天拿豆包试用的评测人，我容易忽略一件事：手里那套评测集，是按"今天"的豆包长什么样设计的，但豆包不会停在今天。模型能力持续演进，你却在用去年的尺子量今年的模型，无声退化就从评测盲区溜走（05 篇讲过这个机制，07 篇也讲了灰度回滚怎么兜住它）。

试用时间长了你会发现一个规律：每次模型更新后，总有些能力变好了、有些能力悄悄退化了，但你的评测集不一定能捕获到。评测集设计时的盲区，恰恰是退化最容易溜进去的缝隙。这就引出一个更上层的问题：下一代模型会冒出什么新能力，你今天该提前布局什么评测基础设施？

某头部大厂的评测岗 JD 里明确要求"基于大模型技术演进趋势制定评测战略路线图"，这说明评测岗的核心价值正在从"会跑 benchmark"升级为"能设计评测战略"。本篇就做这件事：把评测从"来一个需求评一个"的战术响应，升级成"基于模型能力演进主动规划"的战略能力。它承上（承接 00 至 07 篇的认知框架与交付闭环：从评什么、用什么尺子，到交付闸门怎么把证据变成发布决策），启下（09 篇总览地图给你一张导航坐标，更远的第五幕平台化工程化再把这套顶层设计落进一键评测系统）。

二、三层架构：L3/L2/L1 各答什么问题

顶层设计的核心是一张三层架构图。它把"评什么、怎么评、为什么评"拆成三层，每层只答一个问题，互不越界。

• L3 业务价值层：业务场景到评测维度到交付标准的映射，回答"评测结果对业务意味着什么"。这是 07 篇"把证据变成发布闸门"的收口层，也是 09 总览地图里"用户价值"那一端的实例化。
• L2 能力评测层：多维度指标体系设计，回答"用什么尺子、量哪些维度"。09 的对照矩阵是能力到基准的导航清单，本篇 §四的维度矩阵才下钻到原子指标与聚合方式，两者一个管"导航"一个管"工程"。
• L1 技术演进层：模型能力 Roadmap 到评测需求预判，回答"下一代模型会新增什么能力、今天该预研什么评测集"。这一层是本篇飞轮专节的"原料预判器"：飞轮吃线上真实 case，但 L1 让你在能力还没上线前就备好尺子。

三层怎么咬合，是这节要讲清的。09 的矩阵是 L2 的导航层实例化（能力到代表基准），本篇维度矩阵是 L2 的工程层实例化（维度到原子指标到聚合方式），本篇飞轮专节是 L1 到 L2 的"新鲜度养分"回流（线上 case 反向补维度），07 的闸门是 L2 到 L3 的落地卡点（维度分达标才放行）。三层串起来，评测体系就从一个个点状任务，变成一条有输入有输出的战略管道，而不是每次发版前临时抓一批 case。

三、L1 技术演进驱动评测规划

L1 的逻辑很直白：模型能力往哪走，评测维度就得提前往哪铺。下面是六类正在发生的演进，以及它们对评测的前置要求（表中具体能力阈值截至 2026-07 为示例，须随模型 Roadmap 季度复核，非静态结论）。

技术趋势	评测影响	需提前布局的能力
长上下文窗口（128K 到 1M+）	传统短文本评测集失效，需"大海捞针"级评测	长序列评测集构建、位置敏感性测试
多模态融合（文 / 图 / 音 / 视频 / 3D）	单模态评测无法覆盖跨模态一致性	全模态评测基准
Agent / 工具调用能力爆发	评"对话质量"不够，需评"任务完成率 + 安全沙箱"	Agent 评测框架、端到端任务评测
推理能力跃迁（CoT / o1 系列）	答案对不等于推理过程对，需评推理链质量	过程奖励（PRM）式推理过程评估
实时 / 流式交互（语音 / 翻译）	离线评测无法反映延迟 / 流畅度	流式评测 Pipeline、首字延迟监控
AIGC 生成能力（图像 / 视频 / 3D / 音频）	文生图/视频质量、可控性、版权合规成新评测面	生成质量评测集、美学/语义一致性判分、版权过滤率
模型规模效率化（MoE / 蒸馏）	能力不变但成本 / 性能特征变化	性价比评测维度

这六类是方法、架构、范式层面的演进判断，正确性不随单篇跑分衰减。但表内具体能力阈值（如 128K 到 1M）演进极快，本表是战略预判框架，具体数字须每季度随模型 Roadmap 复核，不能当成静态结论。

为什么我一般会选"提前布局"而不是"出来再评"？因为评测集的构建有领先周期。一份合格的长上下文"大海捞针"集，从设计 prompt 模板、标注答案位置、到验证位置敏感性，少说两三周；Agent 端到端任务集更要搭沙箱环境。等能力上线了你才动手，产品已经空窗一个月没评测覆盖了。L1 的价值，就是把这段领先周期"买"在前面。

四、L2 多维度可量化指标体系设计

L2 是把"尺子"做成可维护的系统，不是拍脑袋列指标。五条设计原则：

设计原则	含义	反例
维度正交	每个指标衡量独立能力，不重复计分	"准确性"和"正确率"是同一维度两个叫法，算两次
可量化	每个指标有明确计算公式或评分规则	"总体感觉不错"不是可量化指标
可迭代	指标体系支持新增 / 废弃 / 权重调整，不硬编码	指标写死在代码里而非 YAML 配置
分层聚合	原子指标到维度分到综合分，支持下钻	只报综合分不给维度分解
业务可解释	技术指标必须能翻译成业务语言	"BLEU=0.42"应译成"翻译质量中等，约 60% 句子可直接用"

前两条（正交 / 可量化）与 01 篇维度分治、本篇维度矩阵一脉相承；后三条（可迭代 / 分层聚合 / 业务可解释）是工程化落地的硬要求。

把原则落成维度矩阵（能力命名以 MEMORY §1.2 五大能力 + OS 集成为唯一真相源）：

核心维度	子维度	原子指标（可量化）	聚合方式	关联能力（§1.2）
语言理解	事实性 / 逻辑性 / 完整性	正确率 / 幻觉率 / 覆盖度	加权平均	文本对话
逻辑推理	数学 / 代码 / 常识 / 因果	GSM8K / HumanEval / ARC / COPA 分数	维度独立	文本对话（推理）
代码能力	生成 / 修复 / 理解 / 安全	pass@k / 修复率 / 安全扫描通过率	最低分卡线	文本对话（代码）或 Agent 编排
多模态理解	图文一致 / OCR / 视频理解	CLIPScore / OCR F1 / Video-MME	场景加权	多模态理解
AIGC 生成质量	语义一致性 / 美学质量 / 可控性 / 版权合规	CLIPScore / FID / 人工美学分 / 版权过滤率	场景加权	AIGC 生成
安全合规	越狱 / 偏见 / 对齐 / 隐私	漏过率 / 偏见检出率 / HHH 分	一票否决	横切（OS 集成 + 各能力）
价值观对齐	有用性 / 诚实性 / 无害性	HHH 三维评分 / Constitutional 评测	三维均达标	横切
性能效率	延迟 / 吞吐 / 成本	首字延迟 / QPS / 千 token 成本	SLA 达标	横切（OS 集成交付层）

上面基准名 GSM8K / HumanEval / ARC / COPA / CLIPScore / OCR F1 / Video-MME / FID 属学界通用基准，所引属方法、架构、原理层面结论，不绑定特定模型版本分数。

"聚合方式"这列是关键，我拿安全合规举个例子。假设豆包某一版整体正确率提升了 3%，但安全漏过率从 0.05% 涨到 0.15%，破了 0.1% 的红线。如果用加权平均，这 3% 的提升可能把安全退化淹掉了，综合分还是涨的。但用一票否决，安全维度直接 No-Go，别的好不好都先放一边。代码能力用最低分卡线也是同理：生成、修复、理解、安全四个子维度，任何一个掉到卡线以下，整个代码能力就不及格，木桶短板决定能不能用。不同能力放行逻辑不能一刀切，这正是 01、07 反复强调的"维度分治"。

给一个最小可落地的指标 schema，把"可迭代"原则直接工程化：

dimension: 安全合规
sub: 越狱
metric: jailbreak_pass_rate      # 漏过率
agg: veto                        # 一票否决
threshold: 0.001                 # 红线：大于 0.1% 即 No-Go
weight: 1.0
owner: 安全评测组
updated: 2026-07

把指标写进 YAML 而非硬编码，权重调整走配置审批、不碰代码，这是"可迭代"的工程落地，也是第八节落地策略要制度化的事。

五、L3 业务价值映射

技术指标本身不值钱，能翻译成业务语言才值钱。每个维度我会配一张"业务解读卡片"，固定三问：

1. 该指标退化 5%，用户会感知到什么？比如安全漏过率升 5%，约等于每 20 次对话多 1 次明显越狱风险。
2. 该指标提升 5%，产品口径怎么说？比如翻译正确率升 5%，可以表述为"翻译质量进入行业第一梯队"。
3. 该指标触及红线，业务后果是什么？比如安全漏过率破红线，可能引发监管投诉与舆论风险。

这三问直接对接 07 篇"把证据变成发布闸门"：闸门放行的不是"分数"，是"业务后果可控"。也呼应 01 篇红线一票否决，红线不是评测人的个人偏好，是业务不可承受后果的硬边界。

六、评测数据飞轮：让评测集自己长大

飞轮解决"评测集自己长大"，和 07 闸门、本篇维度矩阵咬合：本篇维度矩阵告诉你"今天该评什么维度"，飞轮告诉你"明天新增哪些维度、旧维度是否还准"，07 闸门用飞轮产出的新集子做放行判决。这套养分回流机制让顶层设计能跟着模型能力自己加速。

6.1 飞轮长什么样：五环闭环

飞轮不是单条流水线，是一个会自我加速的闭环。拆成五环：

• 采集：从线上捞原料，来源分三类，下一节展开。
• 聚类：把同类 bad case 归并，提炼出"这一类问题"而非"这一个 case"。
• 入库：经过质量闸门（6.3 节）后，写进评测集，打版本标记。
• 回归：新版本发布前，用更新后的评测集跑回归，看哪类能力掉分。
• 反馈：回归结果反推采集重点，哪类信号稀疏就加强哪类采集。

这五环和 07 篇的发布闸门是咬合的：07 的灰度监控数据是"采集"环的原料，飞轮产出的新评测集又是 07 准入闸的"弹药"。区别在于，07 的环是"一次发布"尺度，飞轮是"长期演进"尺度。一个管当下放不放行，一个管评测集会不会越来越钝。

6.2 原料从哪来：三道采集来源

飞轮转不转得起来，先看原料够不够。三道来源，信号量和信号强度完全不同。

第一道，显式 Badcase 反馈。 用户点"不好""举报""转人工"，或者给出差评。信号最强、最干净，但量最小。一个显式举报背后，往往已经有一批用户默默流失。

第二道，行为信号。 这是被严重低估的金矿。用户在对话里的某些行为，比显式反馈多一到两个数量级（属通用工程观察，非特定模型版本分数）：

• 复制查证：用户把模型给的答案整段复制到搜索框，大概率是"我不信，要自己核对"，背后是模型不确定性或事实性存疑。
• 中途打断与反复追问：说明首轮回答没解决问题，模型在绕或者没接住意图。
• 低停留加秒关：回答可能看着对、实际没用。

这些行为信号不需要用户主动举报，天然就在日志里。难点在解读：行为信号是"弱标注"，不能直接当标准答案，要结合业务场景判断它指向哪类缺陷。比如"复制查证"集中在某类事实问答，就提示该领域幻觉或时效性风险偏高。

第三道，A/B 长尾。 线上 A/B 实验里，实验组相对对照组的尾部表现，藏着标准评测集碰不到的真实分布。长尾 case 单独看偶发，聚起来就是一类能力短板。

三道来源的关系是：显式反馈定方向，行为信号铺量级，A/B 长尾补分布。只靠第一道，飞轮转不动；三道一起，原料才够密。

6.3 入库质量控制：四道闸门

原料多不等于评测集好。脏数据进集，等于在考卷里混进错题，毁的是整份集子的公信力。四道闸门：

• 去重闸：语义相似度超过 0.9 的 case 合并，只留代表性一条（语义去重阈值，通用工程实践）。否则同类 case 堆上百条，评测集虚胖，正确率被同类题拉偏，区分度下降。
• 格式标准化闸：统一成 YAML 结构，字段含"输入、预期能力维度、判分规则、难度标签"。非结构化的一句话反馈不能直接入库，判分规则必须写清，否则下游 LLM-as-judge 或人工评测会各判各的。
• 版本标记闸：每条 case 标引入版本号和日期。作用是可回溯，某版本突然掉分，能立刻定位是"能力真退了"还是"新入库的难 case 拉低了"，避免误判。
• 回归验证闸：入库前先跑一遍，确认这条 case 真能区分好坏（好回答得高分、坏回答得低分）。区分不开的 case 是噪声，进集只会加熵。这一闸最容易被省，但省掉后飞轮转得越快、污染越快。

四闸的逻辑就一句：飞轮转速再快，也得保证进集的每一条都干净，否则是"快速污染"。

6.4 飞轮健康度：三个指标

飞轮不能只转，得看转得健不健康。三个指标，给具体阈值和判法（属工程实践范式，非特定模型版本分数）：

• 新鲜度：最近 30 天内新增 case 占评测集比例，应大于 15%。低于这条，说明集子在"吃老本"，采集链路可能断了。判法：按月统计新增 case 数除以集子总量，红黄灯按 15% 划界，低于 10% 红灯。
• 难度：豆包在评测集上的正确率，应落在 60% 到 85% 区间。高于 85% 说明题太简单、没区分度；低于 60% 说明题太难或集子已脱离当前能力，跑出来全是红也失去指导意义。判法：每两周看一次正确率分布，偏离区间就调题。
• 周期：从线上发现 bad case 到正式入库，应控制在 2 周内。周期越长，时差越大，评测集越滞后。判法：抽 10 个近期 bad case，看平均入库耗时。

把 A/B 长尾喂进飞轮时，另有统计纪律要守，否则长尾噪声会污染集子。三条（Cohen J.A. Kappa 系数，1960，经典统计方法论）：

• 预注册：入库前先写清"我要验证哪类能力退化、假设方向"，不能事后 cherry-pick。
• 方向一致：同一退化信号在至少 3 个连续时间窗口都出现，才认。
• 效应量：Cohen's d 大于等于 0.2，确认差异不是随机波动。

6.5 两周节奏与角色边界

飞轮要和产品迭代同频。豆包版本迭代很密（据火山引擎开发者社区豆包版本动态｜截至 2026-07），评测集如果按月才更新一次，时差会越拉越大。两周一更新，和大多数产品双周迭代对齐，是性价比最高的节奏。

角色边界要划清，否则"转速"没人负责：

• 评测人：拥有飞轮本身，定采集策略、守四道入库闸、盯三个健康度指标。
• 算法人：提供行为信号和 A/B 长尾的埋点能力，认领回归掉分的根因。
• 标注同学：做聚类后的语义归并和判分规则撰写。

关键一句：飞轮的健康度指标，责任人是评测人，不是算法人也不是产品。谁拥有指标，谁对转速负责。

6.6 三个典型误用

实操中我见过三种典型坑，列出来供参考：

• 手工 case 凑数：为了把正确率从 90% 压到区间里，人工编难题硬塞。飞轮的意义是"从线上长出来"，手工凑的是盆景，不是生态，转两版就失真。
• 只收显式举报：忽视行为信号，结果飞轮原料只有举报那一点量，转不起来，集子永远滞后。
• 入库不跑回归验证：省了第四道闸，脏 case 进集，正确率分布被噪声拉乱，健康度指标全线失真，还误以为飞轮很健康。

七、路线图迭代节奏

设计再好，不进节奏表就是摆设。四档节奏：

周期	动作	产出
每季度	模型能力 Roadmap Review 到评测维度增减	评测维度变更清单
每月	指标权重校准到离线 / 线上 gap 分析	权重配置更新（YAML）
每两周	评测集新鲜度 Review 到对抗 case 补充	评测集版本升级
每次发布	全量评测到交付意见书	Go / No-Go 决策

"每两周"这一行，和本篇飞轮专节的双周新鲜度 Review 是同一件事的两个名字：飞轮负责"养分回流"，路线图负责"版本升级"，本质一个节拍。别让两套节奏各跑各的，否则飞轮喂的养分没人打包成版本。

八、落地策略与角色边界

四策略把顶层设计钉进组织：

1. 技术 - 评测联动会议：每季度与模型团队对齐 Roadmap，提前识别新能力到新评测维度的需求（把 L1 预判机制化）。
2. 指标体系 YAML 化：所有指标定义、权重、阈值写入 YAML，版本控制加审批流程（呼应第四节 schema）。
3. 业务解读卡片制度化：每个评测指标附带"业务翻译"，确保产品、运营、管理层读得懂（呼应第五节）。
4. 路线图可视化：用甘特图展示评测能力建设计划，对齐模型发布节奏。

角色边界（谁对什么负责，避免"路线图没人拥有"的坑）：

• 评测负责人：拥有路线图与指标体系定义，对"评测覆盖业务价值"总责。
• 算法团队：提供模型 Roadmap 输入，参与 L1 预判。
• 产品 / 运营：认领业务解读卡片的业务语言，对"红线后果"拍板。
• 标注 / 数据：执行评测集新鲜度 Review（即本篇飞轮专节"入库"动作的执行者）。

九、下篇预告

下篇（09）收个尾：做豆包评测系列总览，给你一张能力维度对照矩阵导航地图，把已发篇和待展开坑位摆在一张桌上。本篇的三层架构、指标体系与数据飞轮，是这套评测体系的战略骨架；总览地图帮你把它们落到一张可随时定位的坐标上。

作者注：本系列是一边工作、一边实操、一边琢磨着写出来的，规划约 100 篇，内容和篇幅会随实际调整；为保证质量，不追求固定的更新频率。以上内容基于脱敏内部信息、公开权威资料和自己踩坑后的理解，不一定对，欢迎拍砖。

参考与延伸

• 00 篇（开篇定位贴：系列定位、双角色锚定、北极星 thesis）｜2026-07
• 01 篇（豆包产品能力全景图：五大能力骨架，维度分治与红线）｜2026-07
• 04 篇（基准表现怎么看：准入证不是通行证）｜2026-07
• 05 篇（非确定性系统的测试思维：无声退化、Bootstrap 置信区间）｜2026-07
• 06 篇（能力账本：算法评测 vs 传统测试）｜2026-07
• 07 篇（评测驱动交付决策：维度分治、红线一票否决、灰度回滚）｜2026-07
• 09 篇（豆包评测系列总览：能力维度对照矩阵、导航地图）｜2026-07
• 通用评测基准（GSM8K / HumanEval / ARC / COPA / CLIPScore / OCR F1 / Video-MME / MMLU / MT-Bench / TruthfulQA / LibriSpeech / MOS / MMBench / MMMU / AgentBench / VBench 等）为学界通用方法，所引属方法、架构、原理层面结论，不绑定特定模型版本分数
• Cohen J.A. Kappa 系数（评分者一致性，一般大于等于 0.6 可接受），1960，经典统计方法论
• Efron B. Bootstrap Methods，1979，置信区间重采样估计，经典统计方法论
• 语义去重（sentence embedding 相似度聚类）、行为信号挖掘（session 级日志分析）为通用工程实践