前沿与中心：谁来评估评估？（12分钟阅读）

# 评估代理性能 来源：https://cloud.google.com/blog/products/data-analytics/evaluate-agent-performance **编者按：** 人工智能领域一些最有趣的问题正由信息理论学家提出，他们关注如何为新兴的一类AI代理提供上下文。几周前，我们通过一篇关于开放知识格式（https://cloud.google.com/blog/products/data-analytics/how-the-open-knowledge-format-can-improve-data-sharing?e=0）的博客涉足这一领域，该格式将LLM-wiki模式规范化为一种可移植、可互操作的格式，用于表示现代AI系统运行所需的元数据、上下文和精心整理的知识。那篇博客引起了广泛关注，因此我们决定作为新系列"前沿与核心"的一部分，继续带来更多相关内容。今天，我们邀请了Google Data Cloud前沿AI团队的两名成员，探讨一个反复出现的挑战：如何系统地评估代理能否基于其上下文有效回答问题。请继续阅读，并关注该团队后续的博客。 --- 及格分数是考试能给出的最无趣的信息。它只说明学生通过了门槛，却完全无法告诉我们失败有多接近、成功有多轻松，或者接下来该教什么。然而，这正是我们评估AI代理的方式。我们运行一个固定的基准测试，计算一个分数，然后宣布进步。这样做，我们实际上是在给代理进行一场及格/不及格的考试，而我们真正需要的是一张代理能力的地图：一张展示能力在何处、以多大程度下降的地形图。 对于数据代理来说，这张地图在搜索与检索的数据发现中至关重要——这是不起眼的第一步：代理拿到一个模糊的人类问题和包含数千张表与文件的数仓或数据湖，必须首先找到正确的数据集，然后才能进行推理。发现是一个"大海捞针"的问题。真实用户的问题表述并不完美，推断要检索哪些数据集对代理来说是一个真正的挑战。因此，评估中有趣的问题从来不是"代理能通过吗？"，而是"问题可以模糊到什么程度而代理仍然不失败？"考试很难回答这个问题，但地图可以。 今天，我们分享一种基于信息理论的方法，我们一直在利用它为基准测试增加细节和细微差别（即保真度），从而在评估代理时更好地理解其性能。在这个过程中，增加的保真度也暴露了新兴评估用例本身质量的一些更深层次的问题。 ### **难度，可量化** 在检索方面，评估用例通常按难度分层。这可能是自然发生的，例如，普遍且持续存在的失败场景被视为困难。也可能是通过人类或机器打上标签，将某些问题归类为"简单"或"困难"，例如基于查询中提供的上下文。虽然这种基于感性的标记并非标记测试用例的唯一方法，但它经常被使用，尽管有其不完美之处，例如难以复现。 尽管是行业标配，但手工评估每个评估用例的方法在规模化时是不现实的。我们需要一种严谨的方法，能够调节评估用例的难度。我们正在迭代一个我们称之为Discovery Bench的元基准：一个框架，通过为每个用例生成"简单"和"困难"的变体来调节评估用例的难度。这使我们能够审计代理在这些用例中离成功有多近或多远。 调节输入查询难度的杠杆来自一个经过验证的概念，它在信息理论和机器学习中都存在：惊异度，即在给定一组输入的情况下输出的可能性。在我们的案例中，一个查询的惊异度代表了在给定查询后，关于正确数据集的剩余不确定性。 我们方法背后的思路很简单：当评估查询中的一个词或短语能够将目标与语料库中的其他内容明显区分开时，它就具有高信息量。因此，我们可以通过添加或移除具有不同信息量的词来调节评估用例的难度。 让我们通过KramaBench（https://github.com/mitdbg/KramaBench）中的一个实际例子来说明，这是一个公开可用的基准。KramaBench的一个数据集包含关于在轨卫星的信息，来自该套件的示例查询包含以下文本："...使用TLE历史统计卫星48445在2024年期间卫星主要高度变化总数。" 标记"TLE"具有极强的区分性；它几乎唯一地指向数据集中的`TLE\_\_\_\_\_48445`表。去掉它，查询退化为"统计卫星48445的卫星高度变化次数"，其模糊的表述现在匹配了密度表、精确轨道文件和衰减日志。惊异度使之量化：罕见、指向性强的词比常见词携带更多比特。 查询的剩余惊异度是指其答案还有多少不确定性。当惊异度趋近于零时，查询已经足够具体，能精确指向一个数据集。 Discovery Bench的核心思想是这个优化循环，我们称之为基于迭代惊异度的查询优化（iSQR），它生成具有更高或更低信息量的用例，以测试代理从何处开始能够成功回答查询： https://storage.googleapis.com/gweb-cloudblog-publish/images/Who_Evaluates_the_Evaluations__-_FP_blog.max-1800x1800.jpg 图2：iSQR优化循环。 关键在于能够通过调整来控制评估用例中的挑战：不是每个问题只有一个固定的措辞，而是生成相同问题在三个校准模糊级别[高、中、低]下的变体，每个级别都以比特（而非主观意见）为基础。我们甚至可以逐词证明为什么添加或移除了某个词。难度不再是通过感性或分类来归因的属性，而是我们设计出来的。 ### **你看不见的悬崖** 以下是Discovery Bench难度调节旋钮揭示的内容——而单一措辞的基准在结构上根本无法做到。 我们有一个为召回率构建的F1代理（基于Gemini 3.1 Pro）。在整个模糊度范围下运行它对抗KramaBench，绘制出一条曲线：高模糊度下0.34，中性下0.76，中等模糊度下0.81，低模糊度下0.78。 https://storage.googleapis.com/gweb-cloudblog-publish/images/image1_viEBS6x.max-1300x1300.jpg 图3：F1在模糊度上的变化——点与曲线对比。 立即得出两个发现（而传统评估都无法看到这些）。 **第一，悬崖。** 这个查询在中性措辞下获得了完美的F1=1.00——而在高模糊度下为0.00。这就是上面提到的卫星48445用例：去掉区分性标记"TLE"，代理就完全找不到那张表。相同的查询、相同的代理、相同的真实答案；仅仅模糊一点，就跌下悬崖。静态基准测试了中性措辞，打上"已解决"的标签，然后报告平坦的地面，而实际上那里是悬崖。及格/不及格尤其具有误导性，因为它不仅错过了悬崖，还告诉我们地形是平坦的。 **第二，最佳点。** 对于Discovery Agent，中等模糊度优于中性，而低模糊度有时表现更差。更多的特异性并不单调地有利于被评估的系统；存在一个最优的引导量。这是一个分级的、可操作的信号。这就是我们之前从标量中缺失的"多接近、多困难"的质感。它告诉你应该在哪里爬山（改进）代理：在我们的案例中，直接针对具体的失败模式，比如时间分片表（精度骤降至约8%，因为代理为一个两表答案过度检索了21个几乎相同的分片）和上下文爆炸（一旦查询触发长搜索链，F1从0.75降至0.32）。地图不仅告诉你代理失败了，还告诉你失败在哪里以及为什么。请注意，我们的假设是，通过引导词减少模糊度并增加上下文通常会改善检索，但对于正在被测试的特定Discovery Agent，其独特的"最佳点"有意义地突出了其实现中的权衡。 ### **我们并不孤单** 该领域正在趋近于元基准测试，并对我们如何挑战和评估代理施加更多控制。越来越多的工作使用项目反应理论（https://en.wikipedia.org/wiki/Item_response_theory），即标准化测试背后的潜在能力模型，将难度视为一个可测量的量而非一个标签：tinyBenchmarks（https://arxiv.org/abs/2402.14992）和metabench（https://arxiv.org/abs/2407.12844）表明，少数信息丰富的项目可以复现模型的完整分数，而PSN-IRT（https://arxiv.org/abs/2505.15055）则将同样的视角转向基准质量本身。其他人则直接审计真实答案：MMLU-Redux（https://arxiv.org/abs/2406.04127）发现6.49%的MMLU问题标签错误，而Platinum Benchmarks（https://arxiv.org/abs/2502.03461）重新清理了十个数据集，以最小化标签错误和模糊性——这正是我们扫过的两个维度。模糊性越来越被视为固有特性而非噪声：AmbigQA（https://aclanthology.org/2020.emnlp-main.466/）表明，大量真实问题存在多种解读，后续工作发现明显的幻觉往往源于查询模糊性而非模型失败。我们尚未在其他地方看到的是这种组合：将基于信息论的模糊度扫描作为元基准应用于实时企业数据。 ### **我们信任的一个基准原来是坏的** 我们基于kramabench-astronomy（https://arxiv.org/abs/2506.06541）构建了第一个评估，这是一个在该领域确立的基准，其他团队已经依赖它进行自己的评估。团队从这个数据集衍生出基准，我们假设随着时间的推移可能引入了细微问题。当我们实际阅读了团队使用的基准时，在Gemini的帮助下，我们发现在有意义的方面它是错误的：真实答案表无法回答其查询；一个问题有124个分片表，超出了某些团队检索API的返回上限；指定了月份但实际需要确切日期。安静地坏掉的真值意味着安静地错误的结论——不仅对我们，对之前所有基于它的分析都是如此。 这是问题的广义核心：评估本身就是一个可能有缺陷的工件，而几乎没有人去评估它。我们给代理装上仪器，信任尺子，但我们在哪里验证测量工具本身是否合理？ ### **当两张地图不一致时** 现在是递归的转折：如果难度是我们生成的，那么我们需要评估生成器本身；我们也不应该盲目信任它。 因此，我们以两种方式构建了相同的模糊度扫描：基于纯LLM猜测的引导词，以及基于TF-IDF惊异度（https://en.wikipedia.org/wiki/Tf%E2%80%93idf）的引导词。两者产生了巨大分歧。在高模糊度下，LLM构建的扫描将代理评分约为F1≈0.34；基于惊异度的扫描约为0.85。其中一张地图严重失真。可以预见，基于惊异度的地图更稳健：惊异度为其提供了自由运行LLM所缺乏的立足点。 这就是"评估你的评估"的具体体现。信息理论的视角不仅在连续轴上对代理进行评分；它还对基准自身的构建进行评分，并在两者之间做出裁决。 ### **评估你的评估** 多年来，我们一直在针对从未测量过的尺子优化代理。苦涩的讽刺是，更好的模型使情况更糟：随着代理通过粗糙的基准测试，分数在顶部饱和，考试失去了发现代理可改进之处的能力。 因此，行动号召是令人不安且迫在眉睫的：评估你的评估。阅读你的真值。将难度视为一个可测量的量，而不是一个标签：对其进行扫描、绘图，找到你的系统在哪个比特宽度下崩溃。不仅要问"通过了吗？"，还要问"失败有多接近？通过有多困难？一个稍微模糊的问题会不会让它跌下悬崖？"构建能够产生信号而非仅仅判定的评估。 这里存在着需要正视的真实张力。基于熵的难度仅与估算熵的模型一样可靠。如果我们过于用力地追求一个可测量的代理，就有优化尺子而非代理的风险。这不是退回到及格/不及格的理由；而是要保持评估者与评估对象受到同样审视的理由。当我们停止问"谁来评估评估者"的那一刻，就是我们的地图再次变得无用的那一刻。 --- *1. Maia Polo, F. 等. tinyBenchmarks: 用更少的示例评估LLMs. ICML 2024. arxiv.org/abs/2402.14992 (https://arxiv.org/abs/2402.14992) 2. Kipnis, A. 等. metabench: 大型语言模型推理与知识的稀疏基准. ICLR 2025. arxiv.org/abs/2407.12844 (https://arxiv.org/abs/2407.12844) 3. 迷失在基准中？用项目反应理论重新思考大型语言模型基准测试（PSN-IRT）. AAAI 2026. arxiv.org/abs/2505.15055 (https://arxiv.org/abs/2505.15055) 4. Gema, A. P. 等. 我们完成MMLU了吗？（MMLU-Redux）. 2024. arxiv.org/abs/2406.04127 (https://arxiv.org/abs/2406.04127) 5. Vendrow, J. 等. 大型语言模型基准测试测试可靠性吗？（Platinum Benchmarks）. 2025. arxiv.org/abs/2502.03461 (https://arxiv.org/abs/2502.03461) 6. White, C., Dooley, S. 等. LiveBench: 一个具有挑战性、受限污染的LLM基准. 2024. arxiv.org/abs/2406.19314 (https://arxiv.org/abs/2406.19314) 7. Min, S. 等. AmbigQA: 回答模糊的开放域问题. EMNLP 2020. aclanthology.org/2020.emnlp-main.466 (https://aclanthology.org/2020.emnlp-main.466/) 8. Lai, E., Vitagliano, G. 等. KramaBench: 数据湖中数据到洞察管道的AI系统基准. 2025. arxiv.org/abs/2506.06541 (https://arxiv.org/abs/2506.06541)* 发布于 - 数据分析 (https://cloud.google.com/blog/products/data-analytics) - AI与机器学习 (https://cloud.google.com/blog/products/ai-machine-learning) - 应用开发 (https://cloud.google.com/blog/products/application-development)