mcpField
D
design-ai-benchmarking

design-ai-benchmarking

github.com/aperivue测试与质量353102 次安装1 天前更新
代码仓库

关于 design-ai-benchmarking

design-ai-benchmarking 是用于规划 AI 基准评估的 Skill,涵盖评分标准、评审流程、可靠性测量和数据结构,并要求评分结果有记录依据。

主要功能

  1. 01明确评估问题与比较组
  2. 02设计带锚点的多维评分标准
  3. 03规划校准探针与评审小组
  4. 04规定可靠性指标和评审分配
  5. 05创建结构化评分导出模式
  6. 06检查信息泄漏与构念独立性

适用场景

  1. 01设计专家评分的 AI 基准测试
  2. 02为大量评估项目规划评审分配
  3. 03准备基准数据收集与分析

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/aperivue/medsci-skills --skill design-ai-benchmarking

安装后在 Claude Code 中输入/design-ai-benchmarking确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

skill.yml
references/
anchor_rotate_reader_allocation.md
benchmark_export_schema.json
elicitation_rubric_template.md
tests/
test_reader_allocation.py

详细介绍

设计 AI 基准测试技能

标准输出

## AI-Benchmark Design Review
Evaluation question: ...
Arms / systems compared: ...
Reference (human-expert panel): ...
Unit of rating: (item / case / output)

### Rubric (decoupled dimensions)
- dimension -> construct -> anchors (1..k)

### Calibration probes (blinded, randomized)
- positive-control / known-bad / instability / mechanism-contradiction

### Reviewer panel
- n reviewers, metadata captured, per-reviewer randomized order

### Reliability plan
- IRR target on the anchor set of real items (ICC form + 95% CI) + control-item hit rate (a competence check, reported separately)

### Judge strategy
- human-as-judge / LLM-as-judge / both + adjudication rule

### Validity risks
1. ...

### Minimal fixes
- ...

### Decision
- Ready to collect / Needs rubric revision / Needs arm or judge redesign

评审者评分、参考标签、探针结果和一致性统计只能来自已收集的评分记录。绝不可编造:没有底层评分记录却报告 ICC、kappa 或分数,正是这项技能要防止的失败。只有经过 /search-lit 确认的 DOI 或 PMID 才能作为参考文献引用;其他引用均标记为 [UNVERIFIED - NEEDS MANUAL CHECK]。对于未经确认的临床定义、诊断标准或指南建议,标记 [VERIFY] 并询问用户。


工作流

阶段 1:明确评估问题和实验组

以书面形式明确:

  • 基准测试必须支持的具体主张(例如,“系统 A 的输出在感知上与专家输出无法区分”,而不是“系统 A 已准备好部署”)
  • 每个实验组/系统及其输入内容(相同条目、相同信息访问权限、相同输出格式),确保没有实验组暗中占优
  • 人类专家参考:专家是谁,以及他们是用于设定真实标签、作为比较组,还是兼具两者
  • 评分单位(条目、病例、输出),以及每位评审者将看到多少个单位

关卡: 将重构后的评估问题、实验组和参考对象呈现给用户,并在设计评分规则前确认。重构错误会误导整个基准测试。

阶段 2:设计相互独立的多维评分规则
  • 分离各个维度。 每个评分维度只衡量一种构念。将“输出是否有效/正确”与“是否新颖”“是否可行/可测量”“相较现有工具是否有增益”以及“是否会改变行动”分开。候选项可能有效性很高,但增益很低(“真实但冗余”);混合成单一分数会掩盖这一点。
  • 为每个量表等级设定锚点,并用简短的文字描述;在最终确定前,至少请一位评审者试用这些锚点。
  • 预先规定区分效度: 假设哪些维度应当相关、哪些应当彼此正交,然后报告完整的维度间相关矩阵。
  • 从 ${CLAUDE_SKILL_DIR}/references/elicitation_rubric_template.md 开始(包括维度、锚点和探针类型)。
阶段 3:加入并随机安排校准探针

加入少量有意设置的控制条目,在评审者之间进行盲法随机分配(通过 probe_arm 标记记录每位评审者收到的条目),以锚定量表、衡量评审者漂移/疲劳,并审计评分规则和流程。四种类型:

  • 阳性对照/“好得过头”的条目——近乎不言自明;用于测试评审者是否把“效应最大”等同于“最好”,以及构念独立性关卡(阶段 7)是否有效。
  • 已知不良的阴性对照——经过设计的缺陷(伪造的参考、缺失的关键统计量)。
  • 不稳定性条目——在留出数据上估计结果反转或未能复现。
  • 机制矛盾条目——实证方向与所提机制相反。

探针只能是预先植入或经过裁定的,绝不能为了符合假设而伪造。

阶段 4:组建评审小组
  • 招募涵盖预期专业水平梯度的评审者;预先规定任何分层方式。
  • 收集评审者元数据(从业年限、既往 AI 评估经验、亚专科)。
  • 按评审者分别随机排列条目(而不是使用一个全局随机种子),记录排列顺序,并计划分析顺序和疲劳效应。
  • 要求每个条目都独立评判;自由文本中若引用其他条目,则表明评分不独立。

关卡: 在最终确定招募方案前,将评审小组构成、分层和随机化计划提交用户审阅。

阶段 5:设定评分者间信度目标
  • 预先指定信度统计量及其形式——对于多位评分者,使用注明模型的 ICC(例如 ICC(2,1):双向随机、绝对一致性、单个评分者)或 Krippendorff's α(顺序尺度);加权(Cohen's)kappa 是双评分者统计量——并设定有依据的目标。根据所需的 CI 宽度确定项目数量:ICC 的精度主要由项目数量决定(Koo & Li,J Chiropr Med 2016)。
  • 预先植入的控制项目用于检验评分者能力,而不是作为信度证据。 报告已知良好与已知不良控制项目的命中率。不要把基于控制项目计算出的 ICC 作为评分准则或量表效度的证据:ICC 会随项目间差异增大而提高,而控制项目按设计就具有极端差异,因此无论评分者对真实项目的信度如何,其 ICC 都会很高(同样的 5 位评分者、同样的噪声:4 个预植控制项目上的 ICC(2,1) 为 0.89,40 个真实项目上则为 0.16),而且这项结果仅基于少数项目。
  • 报告真实项目代表性锚定集上的信度——附上 95% CI 并注明形式的 ICC,同时提供一项一致性指标(精确一致率、SEM),因为信度取决于所评分项目的异质性(de Vet 等,J Clin Epidemiol 2006)。如果真实项目上的 ICC 较低,但控制项目命中率较高,这说明项目间的真实差异较小,或评分准则无法区分这些项目,而非评分者不认真。
  • 规划每个项目所需的最低评分次数,以获得稳定的一致性估计(相关计算见 /analyze-stats)。
阶段 5b:在负担限制下分配读者(锚定集加轮换)

当项目池超出单个读者一次评分所能承担的数量时,不要让每位读者都评所有项目(这会将项目池限制在每位读者的上限内)。采用锚定集加轮换(一个锚定集加轮换的不完整分块——这不是平衡不完全区组设计,因为不同读者组合共同评分的次数并不相同):所有读者都评一组共享的真实项目锚定集(用于计算评分者间信度;预植控制项目仅用于能力检查),另加各自的轮换专属分块。通常起决定作用的限制是可用专家读者的数量,因此应反向求解(R 位读者可覆盖的最大项目池),以确定必须评分的项目集。评分前,预先指定锚定集成员、每个项目的评分者人数和轮换随机种子。公式、权衡因素和标准库实现见 ${CLAUDE_SKILL_DIR}/references/anchor_rotate_reader_allocation.md。

阶段 6:选择评审策略并进行裁决
  • 决定采用人工评审、LLM 评审,或两者兼用。LLM 评审是另一个实验组,其评分必须在真实项目锚定集上与人工评审小组进行验证,而不能只在极端控制项目上验证。
  • 预先指定出现分歧时的裁决规则(多数表决、由第三位资深审阅者裁决、协商达成共识)以及裁决人。
  • 尽可能对评审者隐藏实验组身份;记录任何不可避免的揭盲情况。
阶段 7:构念独立性与信息泄漏防范
  • 排除作为结果定义组成部分的任何预测变量或输入,并标记由结果定义组成部分构成的近乎同义反复的复合指标——这会造成夸大且近乎循环的结果,应作为带标签的探测项,而非发现。
  • 确认没有任何实验组能看到其他组看不到的决策后信息或源自结果的信息。
  • 确认参考标签并非根据正在评估的同一模型输出得出。
阶段 8:锁定结构化导出架构

从 ${CLAUDE_SKILL_DIR}/references/benchmark_export_schema.json 开始,将机器可读的评分记录编写为 JSON 架构:包括每个条目在所有评分标准维度上的评分、自由文本说明、后续跟进标记、probe_arm 标记、评审者 ID 和元数据、条目顺序及计时信息。

关卡: 将最终评分标准、探测集、评审小组计划、评判策略和导出架构一并提交;在开始任何评分前,先征得用户明确批准,因为开始收集后再做更改会影响比较结果。


交接规则

  • 对于 ICC(指定形式)/ Krippendorff's α / kappa(两名评审者)/ DeLong、一致性样本量,以及基准测试结果中效应量的实际意义解读,转至 /analyze-stats
  • 设计锁定后,如需按条目报告 STARD-AI、CLAIM 或 TRIPOD+AI,转至 /check-reporting
  • 如果还需要审查围绕基准测试的整体研究(队列逻辑、分析单位、比较对象),转至 /design-study
  • 仅在已有评分且正在评估稿件时,才转至 /peer-review 或 /self-review

评论

支持 Markdown