今天小编分享的科技经验：田渊栋团队新作祭出Agent-as-a-Judge！AI智能体自我审判，成本暴跌97%，欢迎阅读。
【新智元导读】AI 评估 AI 可靠吗？来自 Meta、KAUST 团队的最新研究中，提出了 Agent-as-a-Judge 框架，证实了智能体系统能够以类人的方式评估。它不仅减少 97% 成本和时间，还提供丰富的中间反馈。
AI 智能体，能否像人类一样有效地评估其他 AI 智能体？
对于 AI 智能体来说，评估决策路径一直是棘手的问题。
已有的评估方法，要么只关注结果，要么要要过多的人工完成。
为了解决这一问题，田渊栋、Jürgen Schmidhuber 带领的团队提出了「Agent-as-a-Judge」框架。
简言之，让智能体来评估智能体系统，让 AI 审 AI。
它不仅可以减少 97% 的成本和时间，还能提供丰富的中间反馈。
这是「LLM-as-a-Judge」框架的有机延伸，通过融入智能体特性，能够为整个任务解决过程提供中间反馈。
论文地址：https://arxiv.org/abs/2410.10934v1
研究人员提出了 DevAI 基准，为全新框架提供概念验证测试平台。包含 55 个真实的 AI 开发任务，带有详细的手动注释。
通过对三个领先的智能体系统进行基准测试，发现它大大优于「LLM-as-a-Judge」框架。
总之，这项研究真正的变革之处在于：它提供了可靠的奖励信号，为可扩展的、自我改进的智能体系统铺平了道路。
「法官」智能体，击败大模型
现有评估方法，无法为智能体系统的中间任务解决阶段，提供足够的反馈。
另一方面，通过人工进行更好的评估，代价太大。
而智能体系统的思考方式，更像人类，通常是逐步完成，并且在内部经常使用类人的符号通信来解决问题。
因此，智能体也能够提供丰富的反馈，并关注完整的思考和行动轨迹。
「Agent-as-a-Judge」不仅保留了「LLM-as-a-Judge」成本效益，还具备智能体特性，使其在整个过程中提供中间反馈。
下图展示了，大模型、智能体、人类作为评判者的示意图。
DevAI：自动化 AI 开发数据集
另外，在代码生成领網域，基准测试的发展也落后于智能体系统的快速进步。
比如，HumanEval 仅关注算法问题，而 MBPP 则处理简单的编程任务，但这两者都没有反映出开发者面临的最实际的挑战。
作为一个改进，SWE-Bench 基准确实引入了 GitHub 现实问题，提供一种全新评估的方法。
不过，它仍需要关注自动修复任务的开发过程。
为了解决当前代码生成基准测试中的上述问题，研究人员引入了 DevAI：AI 开发者数据集，其中包含 55 个由专家注释者创建的真实世界综合 AI 应用开发任务。
DevAI 结构是这样的：智能体系统首先接收用户查询以开始开发，然后根据 AI 系统满足需求的程度来评估它，其中偏好作为可选的、较为柔性的标准。
图 3 展示了 DevAI 任务的一个例子。
DevAI 中的任务规模相对较小，但涵盖了常用的关键开发技术。
如图 2 所示，任务被标记并覆盖了 AI 的多个关键领網域：监督学习、强化学习、计算机视觉、自然语言处理、生成模型等。
每个任务都是，可能交给研究工程师的真实世界问题，并降低了在这个基准上评估方法的计算成本。
接下来，研究人员将领先的开源代码生成智能体框架，应用于 DevAI 中的任务：MetaGPT、GPT-Pilot、OpenHands。
他们让人类评判者、大模型评判者、以及智能体评判者框架，来评估其性能。
结果如表 1 所示，MetaGPT 最具成本效益（1.19 美元），而 OpenHands 是最昂贵的（6.38 美元）。
从开发时间来看，OpenHands 完成任务平均耗时 362.41 秒，而 GPT-Pilot 耗时最长，为 1622.38 秒。
平均而言，使用这三者之一对 DevAI 进行完整评估，大约需要 210.65 美元和 14 小时才能完成。
Human-as-a-Juge：DevAI 手动评估
为了确定 DevAI 的实用有效性，并准确估计当前最先进的智能体系统实际代码生成能力，研究人员手动评估三个 AI 开发者基线在 DevAI 中的应用。
如表 2 所示，（I）和（D）代表独立性能与考虑任务依赖性的性能。
表示多个专家的进化，并且意味着评估使用白盒测试（允许访问生成的 workspace、人类收集的轨迹和开源代码库）。
两种性能最好的方法（GPT-Pilot 和 OpenHands）可以满足大约 29% 的要求，但只有一项任务可以满足所有要求。
另外，在三位人类评估者之间，他们的个人评估存在大量分歧，说明了单一人类评估的不可靠性。
下图 5 总结了人类评估和共识评估的不匹配度。
---：智能体评估智能体
根据以往智能体设计的经验，并通过模仿人类评估过程，研究人员涉及了 8 个模块化互動组件，具体包括：
1 影像模块：构建一个影像，获取项目整个结构，包括檔案、模块、依赖项，还可以将代码块分解为代码片段
2 定位模块：识别需求所引用的特定檔案夹 / 檔案
3 读取模块：超越了简单的檔案解析，支持跨 33 种不同格式的多模态数据的读取和理解
4 搜索模块：提供了对代码的上下文理解，并且可以快速检索高度相关的代码片段，以及其背后细微差别
5 检索模块：从上下文中提取信息，识别轨迹中相关片段
6 查询模块：确定是否满足给定要求
7 记忆模块：存储历史判断信息，允许智能体基于过去记忆评估
8 规划模块：允许智能体根据当前状态和项目目标制定策略，并排序任务。
具体操作流程，如下图 9 所示。
下表 3 展示了，Agent-as-a-Judge 在各项任务中始终优于 LLM-as-a-Judge，特别是在那些训在任务依赖关系的情况下。
评判开发者智能体，是一项类别不平衡的任务，满足要求的情况要比失败的情况少的多。
而判断转移和对齐率等指标可能会产生误导。比如，由于 MetaGPT 很少满足要求， LLM-as-a-Judge 很容易将大多数情况识别为负面（在黑盒設定中达到 84.15%）。
PR 曲线通过平衡精确度和召回率，提供更清晰的性能衡量标准。
这表明，在某些情况 下，Agent-as-a-Judge 几乎可以取代人类评估员。
最后，在消融研究中，研究人员分析了各种组件的添加，对 Agent-as-a-Judge 判断 OpenHands 性能的影响。
参考资料：
https://x.com/tydsh/status/1846538154129375412
