一次关于敏捷评测集设计的完整思考，整理成 Q&A。
在视频评测过程中，一直被一个矛盾困扰：评测集想覆盖的能力越多，就越难构造；但为了支撑快速的版本迭代，评测集又不能做得太大。这篇文章是把这个矛盾拆开、一步步想透的过程，整理成问答形式。
一、定位：敏捷评测集是什么
Q：评测集越想覆盖全，越难构造。这个矛盾怎么破？
不要试图用一个评测集解决所有问题。
支撑快速迭代的”敏捷评测集”和对外跑分的”主版本评测集”，目的不同，设计逻辑就不同。敏捷评测集的目标只有两个——快速发现高优问题、观察版本间趋势。它不需要全面，只需要快、准、能复现。
承认”一个评测集服务所有目标”是幻想，是整个设计的起点。
Q：敏捷评测集和主版本评测集是什么关系？
不是简单的子集关系。
敏捷评测集是骨架——每个典型场景留代表 case；主版本评测集是骨架加血肉——在每个典型场景上再进行泛化以产生多样性。两者共享同一套”典型场景”定义，但敏捷集追求精简，主版本集追求覆盖。
二、结构：为什么是两层
Q：敏捷评测集会遇到一对矛盾的要求——case 要稳定才能比趋势，又要进化才能跟上新问题。怎么解？
不要让同一批 case 同时背两个互斥的要求。一批 case 做不到的事，就拆成两批。
最终结构是两层：
- 固定盘：典型场景 + 核心能力 case，缓慢进化，承担版本趋势观察
- 轮询盘：每轮抽换新 case，承担新问题发现
让每个盘只做一件事，是这个设计的核心原则。
Q：固定盘会进化，那版本趋势还怎么比？
关键认知：趋势只需要”相邻可比”，不需要”永恒不变”。
敏捷评测不负责长线趋势，那是主版本评测或回归评测的职责，它只看短线趋势，可能是几周或 1–2 个月。只要相邻两个版本用的是同一份固定盘就完全可比。下个周期固定盘吸收了新 case，那是 v6 vs v5 的事，不影响已经比完的结论。
我曾经把”固定盘既要稳定又要进化”当成死结，其实只是因为误以为趋势必须跨越所有历史版本。
三、roll 策略：不起眼但会污染趋势
Q：一条 case 多次 roll 结果不同，这个”不稳定”是噪声还是信号？
取决于你在测什么。
如果只关心模型能力的均值——它是要被消除的噪声。但模型的”抽卡率”（10 次里有几次出好结果）本身是一个值得单独评测的能力维度，对用户体验影响极大。
敏捷评测里，我的选择是消除抽卡率（它放到后期或专项评测里单独测），但这意味着 roll 策略必须明确。
Q：那对 badcase 重 roll 取最优，可以吗？
不可以——这是个隐蔽的陷阱。
如果好 case roll 一次、bad case 重 roll 三次取最优，你测的就不是模型的真实输出，而是它的能力上限。后果是：一个稳定性大幅退步的版本，会因为重 roll 而显示”没退步”。
铁律是：roll 策略必须对所有 case 一致。 要么都 roll 一次，要么都 roll 固定次数。不对称的 roll 会系统性地美化结果。
四、联动：两层之间的闭环
Q：轮询盘发现的问题，发现完就结束了吗？
不能结束，否则两个盘就是孤岛。
轮询盘发现的高频、高严重度问题，应该提炼成新的典型场景，回流补进固定盘。轮询盘是固定盘的”进化引擎”，固定盘是轮询盘成果的”沉淀池”。这条回流通路，就是两层之间的连接器。
Q：轮询盘每轮都换 case，算法侧会不会陷入”打地鼠”——永远在追新问题？
会，所以轮询不能盲目每轮换。
轮询的触发条件应该绑定”上一轮暴露的问题是否收敛”——问题没解决，就不放新的；解决了，才轮换下一批。这样算法侧的节奏完全可控，评测从”对抗算法”回归到”帮助算法”。
Q：“问题收敛”怎么衡量？
用归因标签的占比。
轮询盘发现的问题以结构化的归因标签形式进入持续统计。如果某个标签的占比相比上个版本下降、趋于 0 或降到可接受程度，就判定收敛。
这同时揭示了回流机制的另一重意义——它不只是让固定盘进化，还承担了”追踪问题生命周期”的职责。一个问题从发现、标签化、进入监控、被优化、到占比下降判定收敛，构成了一个完整的闭环。
Q：把”归因标签占比”当成优化目标，会不会被 Goodhart——模型不解决问题，只是让问题不触发标签？
会有这个风险，防线是：归因标签体系必须是动态演进的。
如果模型学会规避某种打标，人是能看出来的，并会补充新的标签。但这条防线依赖一个前提——标签体系有人持续维护。一旦标签体系僵化，防线就破了。所以”归因标签动态演进”本身，要被当作对抗 Goodhart 的关键机制来对待，而不是默认它静态可靠。
Q：如果某个顽固问题一直不收敛，轮询不就永远锁死了？
需要豁免机制。
顽固问题引入产品、算法的协同评估，可以豁免、不阻塞轮询。但豁免不等于遗忘——被豁免的问题要有显式状态（“已知顽固问题，暂缓，每 N 个版本复检”），并结合线上反应持续监控。豁免的本质是给问题降优先级，不是删除问题。
五、可置信：三个层面
Q：“可置信”到底指什么？它不只是结论准确吧？
是三个层面叠起来的：
- 结论层：GSB 配上置信区间、显著性检验、波动误差棒。差异是真差异还是噪声，要有量化判断。数据太少的子分类，只定性给出问题，不定量排优先级——知道什么时候不下结论，本身就是可置信的一部分。
- 工具层：评测集这个测量工具本身要被验证有效（见下两问）。
- 边界层：诚实声明用途和局限。过程评测集只用于内部迭代，不宣称分布代表性，结论不外推到真实用户分布。
承认局限，是可置信的一部分，不是缺陷。
Q：波动误差棒怎么用？
先在小范围内测出 roll 随机性、标注波动的幅度，得到一个波动值。
但要注意——波动值不是用来加减修正 GSB 点估计的，那是用一个噪声去修正另一个噪声。它的正确用法是当误差棒：v5 涨 3% 但实测波动 ±2.5%，信号偏弱要谨慎；涨 8% 远超波动，才可信。
Q：评测集自己怎么证明自己有区分度？
它证明不了——这是关键。
置信区间、显著性、MOS 分，这些指标全都依赖同一批 case。如果这批 case 本身失去了区分能力（太简单全员满分，或太难全员崩盘），那再精确的统计也只是精确地告诉你”没区别”。
区分度的杀手不是”简单”，是”同质”。两头都会失效。所以评测集的有效性，必须靠一个评测集之外的锚点来验证。
Q：可我设计了难度梯度，难道不能保证区分度吗？
不能。难度梯度是设计意图，不是已验证的事实。
“困难”是人主观标注的，但”能否拉开差距”是一个关于模型的客观事实，会随模型能力漂移。你标的困难 case，可能现在就已经全员崩盘，也可能半年后变成全员满分。你标注的难度，不等于实际的区分度——前者恰恰是需要被区分度验证去检查的对象。
Q：那怎么分辨”模型确实都不行”和”评测集失效了”？这两者在 GSB 上长得一模一样。
用 SOTA 模型做动态锚点。
核心认知是：难度不是 case 的固有属性，而是 case 相对于”当前模型能力水位”的相对属性。 持续摸底 SOTA 模型，用它的实时表现来定义难度——
- SOTA 做得好的，此刻是简单 case
- SOTA 做得勉强的，此刻是中等，区分度最高的区间
- SOTA 也崩的，此刻是困难，甚至滑入失效区
模型变强，标尺上移，case 难度自动重标。这把”会自己更新刻度的尺”，就是评测集之外的那个锚点。
落地上，SOTA 摸底要制度化：固定盘每次吸收新 case 后，先用 SOTA 跑一遍，确认难度分布还健康（中等档够厚）、区分度还在，再投入版本评测。摸底的节奏，绑定固定盘进化的节奏。
小结
把整个设计收成一张图：
持续积累的 case 池（带挑战点标签） │ ┌───────────┴───────────┐ ↓ ↓ 【固定盘】 【轮询盘】 核心场景，缓慢进化 定期抽换，频率衰减 │ │ ↓ ↓ 版本趋势 GSB 新问题清单 ↑ │ └──── 问题收敛后回流 ─────┘
可置信 = 结论层（CI/显著性/误差棒） + 工具层（SOTA 摸底校准区分度） + 边界层（声明用途与局限）整个思考让我确认了几件事：
- 有限数量逼出分层。 一个集子做不到全能，就拆成各司其职的多个盘。分层不是臃肿，是约束下的相对解法。
- 趋势只需相邻可比。 想清楚这点，“固定盘既要稳定又要进化”的死结自然解开。
- roll 策略必须对称。 不对称的 roll 会悄悄美化结果，污染趋势。
- 可置信不能自证。 评测集证明不了自己有效，必须靠 SOTA 摸底这种外部锚点来校准。
- 诚实声明边界，也是可置信。 知道什么时候不下结论，和下对结论同样重要。
评测集不是一个静态的题库，它是一个需要被持续校准、持续进化的测量系统。设计它的难点，从来不是凑够 case，而是让它在有限的规模下，依然说真话。