该模板支持按模型、技能组、完成状态和技能激活状态动态筛选评估数据，无需编写代码。
AI解读：这条新闻对需要向非技术同事展示AI模型评估结果的产品经理、业务负责人或技术Lead来说很实用。此前，Inspect AI的评估数据主要存在CSV或Google Sheets里，非技术成员很难直观地按不同维度（比如不同模型、是否成功调用工具）快速查看性能差异。Google AI开发者推出的Data Studio模板，把这些数据做成了带下拉筛选器的交互式图表，无需写代码即可按需查看准确率、延迟和成本。要注意的是，文章披露的示例数据量很小（每个组合仅 4 次运行），只能用来观察趋势，不能作为发布级的统计结论；如果要严谨验证，需要把运行次数扩大到至少 30 次以支持 95% 置信区间。所以，普通读者不必立即行动，但如果你正在跑Inspect AI评估且需要向老板或客户汇报，可以复制这个模板，接入自己的评估CSV就能快速生成可视化报告。
Google AI开发者Katie McLaughlin发布系列教程的最后一篇，介绍如何用Google Data Studio将AI评估数据（CSV导出）转化为无需代码的交互式仪表盘。文中提供了一个预先配置的“Master Dashboard Template”，支持通过下拉菜单动态筛选数据。
模板设置与数据绑定
教程指出，实施前提是拥有第 3 部分生成的CSV导出（data_mega_export.csv）以及一个Google Workspace账户以访问Data Studio。第 2 部分关于评估和轨迹分析的内容是可选阅读。
设置流程为：打开Inspect AI Dashboard Template，点击“Make a copy”克隆模板；然后在副本中选择Add data，连接Google Sheets并选择包含评估数据的工作表；接着选中所有组件并将数据源指向该工作表；最后将气泡图的样式设置为按“model”字段着色。作者称完成这些步骤后仪表盘即可运行。
- 模板位于报告右下角，包含一个Pivot Table Heatmap，以颜色强度表示数值大小（此处为二次曲线准确率分数）。
预置图表与筛选器功能
报告包含两个主要的可视化组件。Chart A（散点/气泡图）将三个核心评估维度映射到一个二维画布上：X轴代表平均任务延迟（秒），Y轴代表平均任务准确率（0.0 到 1.0），气泡大小反映平均任务成本。悬停提示会显示延迟、准确率、模型、技能组和成本，成本格式化为美元并保留四位小数（如 $0.0044），避免亚美分成本被四舍五入成 $0.00。
Chart B（准确率与误差条）显示平均准确率（条形高度）以及浮动点表示的 ±1 标准误（SEM）范围。设计说明提到，Data Studio不允许在同一图表中同时使用多个Y轴指标和细分维度，因此作者将模型放在X轴，并通过顶部下拉菜单按技能组筛选。统计严谨性说明指出，标准误衡量各次运行通过/失败分数的变化；演示中N=4 仅覆盖约 68% 置信范围（±1 SEM），而生产基准需要N≥30 才能获得标准的 95% 置信区间。
报告顶部有四个动态筛选器：model（按模型族过滤，如gemini-3.5-flash-lite vs gemini-3.6-flash）、skill_group（按技能设置过滤，如gemini-api、gcloud、baseline control）、is_baseline_or_has_activated_skill（区分基线与激活技能运行，TRUE表示通过activate_skill调用，FALSE表示技能可用但未被调用；作者强调这衡量的是工具采纳而非指令遵从）、completed（筛选干净运行TRUE与系统故障FALSE，如配额耗尽、超时、容器崩溃；选择TRUE可衡量模型能力即条件准确率，而FALSE或ALL则显示完整审计轨迹）。
筛选器分析示例
作者展示了两类分析。条件采纳分析：当筛选is_baseline_or_has_activated_skill为FALSE时，观察未被调用的技能运行（休眠运行）——结果显示这些运行得分相对较低；而TRUE运行（技能被激活）得分较高。作者指出，在gemini-3.5-flash-lite的样本中，技能被激活的情况具有更高的视觉上限，且只有 3.5-flash-lite存在未激活技能的情况（可能因样本数少）。
生存者偏差与联合运行时间分析：作者使用启用web search、时间限制 300 秒的配置重跑评估。结果显示，在completed=ALL时，3.5-flash-lite延迟低于 3.6-flash，但平均分数相当；当仅筛选completed=TRUE时，3.6-flash的分数略高（0.5-0.6 之间，而此前为 0.35-0.60）。作者建议参考Gemini API官方文档获取模型延迟和吞吐规格，并指出超时运行会被计为 0 分，可能影响了结果。作者强调，当前演示N=4 仅适合探索趋势，需将运行次数扩展到N≥30 并计算p值以实现统计显著性。
- 作者建议使用更大时间限制和内置自适应速率限制，以避免web search配额耗尽和超时。
- 后续方向包括：添加自定义计算指标（如ROI、每次成功任务成本）、扩展评估矩阵、直接连接数据库（BigQuery、PostgreSQL等）以及自动化告警设置。