AI 评估与分析

假设你正在测试新的 AI 工具。也许你为一家广告代理公司实现并运行分析，希望自动化部署标准事件模式；或者你是一位播客制作人，正在自动化从最新节目生成社交文案。虽然现代新训练的 LLM 可能能够一次性完成很多这类任务——但这种特殊性可能意味着浪费 tokens 和时间，反复用相同的资源、描述和脚本提示它们。有鉴于此，你开始研究工具，无论是 MCP 服务器、Agent 技能还是 Agent 插件。

问题是，你如何知道一个技能（无论是自己开发的还是他人开源的）是否值得你花费时间，或者更重要的是，值得你花费 tokens 和配额？一个人如何设计这些（更加）客观的 AI 工具评估，并由此收集和分析相关指标？这正是使用开源评估框架（如 Inspect AI 和 Harbor）评估 Agent 技能的场景。但你如何「扩展评估」，使用可视化来发现趋势，并使用 Google Sheets 和 Data Studio 协作探索替代方案？

这些问题以及更多内容正是我希望通过这个系列为你演示的！

虽然你完全可以只是阅读我如何以及为何进行自己的调查研究，但你也可以跟随我的步骤运行基准测试脚本。

因此，如果你想跟着操作，请花点时间完成上述 codelab，完成后再回来。别担心，我们会在你回来的时候继续在这里！

注意：本博客系列包含 AI 生成的图表，以及实际截图和手工编辑的混合内容。AI 也协助进行了少量文案编辑。

在 codelab 中，我们学习了如何使用 Gemini CLI、Inspect 和 Inspect SWE 在隔离的 Docker Sandbox 中运行评估，以了解每个技能如何帮助 Agent 回答同一问题。

对于在家跟着操作的读者，请现在额外安装 inspect view，以免在运行以下评估时需要它；准备好根据你的机器和配额使用情况，等待几分钟让评估完成。

关于我们的新源文件，虽然它们有大量注释，并且 hopefully 以自描述的方式编写，但我随后会进一步解释。

出于我的研究演示目的，我使用了三个不同的模型：google/gemini-3.5-flash-lite 和 google/gemini-3.6-flash 作为「求解器」（被评估的模型），以及 google/gemini-3.1-flash-lite 作为「评分器」（对运行进行评分的模型）。这三者（以及更广泛的模型）在许多方面存在差异，但更具体地是在问题解决能力、速度和成本上。

我们故意将评分工作卸载到上一代模型，因为通过将评分标准改为严格的二元决策并以编程方式应用归约，它能够提供足够稳健的评估，而不会消耗大量求解器配额。对于生产评估系统，考虑研究使用更新、更有能力的模型作为评分器，因为它们可能有更窄的置信区间。

有关此解耦评分器架构的完整技术分解，以及如何用你选择的模型进行替换，请参阅 README 的《解耦评分器与多维评分标准》章节。

可复现性与本地设置注意：如果你在本地跟随操作，请在运行基准测试扫描前将领域技能定义克隆到 google-skills/：

git clone https://github.com/google/skills.git google-skills

本系列中的所有评估均在 Python 3.13 上使用 inspect-ai（v0.3.247）、inspect-swe（v0.2.66）、inspect-viz（v0.4.1）和 pandas（3.0.3）进行基准测试。如果上游 PyPI 版本引入破坏性变更，请查看 README 的《环境与依赖》规范以获取精确的版本锁定和复现配置说明。

对于这项研究，我使用了一个新的评估脚本；虽然脚本的具体细节对你希望制作自己的评估或运行我们接下来要用的代码很重要，但如果你主要对分析和可视化感兴趣，可以直接跳到下一节。

原始脚本在本地机器上运行了一小批测试。虽然这个版本可以在本地机器上运行，但它的优先级是运行作为更大规模开发流程一部分的自动化测试所需的三个架构维度：

外部配置（将评估和求解器系统提示作为外部文件提供，以实现关注点分离）。

配额管理（用于 GenAI API 和包管理）。

多维评估（扩展到评分器的任意事实数量）。

有关这些架构支柱的完整技术分解——包括外部配置模式（questions.json、thrifty_system_prompt.txt）、求解器速率限制防御（version="0.51.0" 锁定）、评分器配额解耦以及分数曲线数学公式——请参阅 README 的《评估管道架构与技术参考》章节。

这些命令创建了受 model x skill condition x sample x epoch 条件制约的评估矩阵。快速可视化（我将在本文中反复引用）见下方。

图注：将被评分和比较的评估矩阵可视化。在 Inspect AI 中，表示为 Facts 的评分标准元素被评定为正确（C）或 Incorrect（I）。

话虽如此，终于到了关键时刻。我用以下命令运行了评估

inspect eval skills-eval.py \
  --model google/gemini-3.5-flash-lite,google/gemini-3.6-flash \
  --time-limit 300 \
  --epochs 2 \
  --max-tasks 4 \
  -T web_access=false

此命令在模型和技能条件上运行 4 路并行扫描，同时强制执行 300 秒任务超时并禁用 Web 搜索以最小化 token 消耗。详见 README 的《CLI 参数参考》以及《外部配置模板机制》章节。

如果你打算并且尚未这样做，请运行该命令行。如果你对如何阅读和与终端用户界面交互感兴趣，请参阅之前的 codelab。

观察运行的命令行足够长的时间以确定它没有崩溃或出现明显错误，然后也许可以花点时间做点吃的、喝点水或者在附近走走。享受生活中的小事，好吗？最坏的情况下，你会得到 20 分钟的散步时间，不是很糟糕吧！？

说完这些，阅读终端输出只是理解评估的最基本方式。现在你有了原始评估日志，你需要做什么才能开始分析和更重要的是，有说服力地使用这些数据？

首先，我简单运行了

inspect view

然后点击链接在浏览器中打开 GUI。

有关在浏览器 GUI 中进行分步诊断跟踪分析的内容，请参阅 README 的《本地诊断跟踪分析（inspect view）》章节。

我的结果是这样的（经过一些列拖放之后）：

虽然我们在《使用开源框架评估 Agent 技能》中介绍了 inspect view GUI 的基础知识，但可以用它做的事情要多得多。说到这个，TASK ARGS 列（未在图中显示）作为传入任务参数的快速参考。

宏观视图：比较运行

虽然 LLM 本质上是随机的（并且鉴于浮点硬件，是非确定性的），但在运行评估时，我们试图用采样来表征我们特定配置（model x skill）在相关问题上的平均可观察指标（例如正确性、延迟和 token 使用量）。因此，评估任务被设置为描述独立变量（模型或技能）的变化如何影响因变量（上述指标）。

在 inspect view 中按模型对评估运行进行分组，允许直接「目测」检查技能包含如何改变基线控制下的准确性——给定一个特定模型，添加技能的影响是什么？

我添加了一些标注，使基线到有技能状态的指标变化更加明显：

在所有情况下，添加技能后相较于同一模型的基线都取得了分数提升或持平。

所有这些情况也都增加了耗时

另一个可以进行的简单测量是查看 TOKENS 列——gemini-api 实际上相较于其基线 3.6-flash 出现了使用量下降。

虽然 tokens 与分数之间的一般关系很难从视觉上解析，但一个值得注意的结果是：在 4 组任务 x 模型配置中，有 3 组 gemini-3.6-flash 比同类 3.5-flash-lite 运行消耗了更多 tokens。

B. 比较技能条件（技能 vs 基线）

现在来分析反向情况；用更具体的术语来说：给定一个特定技能，更换底层模型的效果是什么？

从 3.5-flash-lite 切换到 3.6-flash 的效果如何？

在这 4 组中有 3 组，两种模型之间的变化相当于最高 45% 的准确率提升。然而，出于某种原因，将 gcloud 技能从使用一个模型切换到另一个却导致了轻微下降。

虽然这些都是很有价值的发现，但它们引出了更多问题：

这些是具有代表性的样本吗？

如果这些发现可复现，我们如何描述现有指标之间的关系？

对于第一个问题，如果你想获得更具代表性的样本，要知道你应该用更多的问题、样本和轮次来进行进一步的研究，并将这些指标与这些进行比较。不过，鉴于这个博客系列的目的，我会把这个留给你来做。

不过对于第二个问题，我们可以而且将会努力去做。话虽如此，在设计后续分析时，考虑一下评估过程中遇到的常见模式可能会有所帮助。这对于那些正在自己运行评估的人尤其如此（可能在不同的技能或评分标准上）；你可能会遇到与我的非常不同的指标，因此我将列出一些常见模式以及进一步调查它们的后续操作。

评估比较的心理模型（技能 vs 基线）

在分析评估运行时，将技能化执行与基线对照进行比较通常映射到五种不同的诊断结果——从高效率能力提升（最佳）到上下文过载与技能退化（最差）。

关于这个诊断分类学的完整分解以及每种结果的可操作审计步骤，请参阅诊断心理模型进行评估比较的 README 分解。

微观视角：样本级诊断

虽然高级指标摘要会提醒你注意成本膨胀或技能退化等结果，但打开单个样本会显示样本详情面板，用于细粒度的追踪分析：

此标签页显示了解题智能体、沙箱 shell 和外部工具之间的确切多轮对话。用它来诊断模型推理与环境噪音：

系统提示验证：确认 web 搜索规则（-T web_access=false）和自动时间限制（300 秒）已正确注入到容器环境中。

技能摄取检查：验证智能体是否激活了该技能。如果激活未发生，你的评估主要是在测试基线模型知识而非技能实用性。

这是一个技能被激活的案例示例。

这意味着：智能体实际摄取了 gemini-api，而不是依赖基线预训练记忆。

不过值得注意的是，一些提供了技能的任務并没有激活该技能。如果你是一名技能作者，你可能想要重写"激活条件"（即什么情况下需要使用该技能），使其更适用于相关任务的具体情况。

审核追踪详情可以让你区分模型推理循环（例如，重复冗余的工具调用）和沙箱环境噪音（例如，容器超时或缺失的二进制依赖）。有关分步诊断追踪审核程序，请参阅 README 参考资料沙箱噪音与模型推理。

点击评分标签页会显示我们的自定义 multi_scorer 对某个样本的经验细分：

multi_scorer 使用 model_graded_qa 将样本答案与单个二元是/否事实进行核对，从而聚合结果。生成的分数列表在 [0.0, 1.0] 范围内，被提供给我们的 custom_reducer，由它计算算术平均值。然后它应用二次分数曲线（mean²）来确保提供的答案均值越偏离正确答案，分数就被拉得越低。这使得最正确答案能够立即突出。在评分标签页中，这个向下曲线将原始的 5/6 事实分数（≈0.8333）映射到归一化的 0.65 样本分数。有关完整公式和数学推导，请参阅 README 关于原子事实验证与二次曲线的章节。

视觉里程碑：向队列分析过渡

虽然 inspect 视图为单个样本追踪提供了出色的深度诊断，但评估数十个跨多个技能领域的模型很快就会变得混乱（正如你在上面可能已经看到的）。将技能包含与排除之间的相关性以及模型变化相互权衡，如果找不到更好的推理方式，可能会令人困惑，与其说是科学不如说是艺术；它需要一个结构化的矩阵概览。

还记得我之前向你展示的那些代表所有配置的 3D 空间截面吗？好吧，除非我们找到数字方法来压缩它或进行更深入的量化比较，否则你无法获得在两个能力相似的替代方案之间进行选择所需的细粒度信息。更糟糕的是，你无法将这些信息传达给那些掌握钱袋的人（当然，除非你就是那个人）。

为了使这件事更容易，下一次我们将开始走上理解和可视化显示这些内容的道路：如上面链接的队列矩阵中所可视化，理解智能体能力因素逐个因素需要跨多维指标进行队列切片。

在第二部分中，我们将把分析从单个日志 UI 检查扩展到带有 inspect viz 的聚合记分板！

如需进一步操作，你可以考虑屏蔽此人或举报滥用行为