跳到正文

#评测/基准

今日 11 条
今天10月2日周五
  1. arXiv cs.CR72

    论文提出黑盒 LLM 模型提取生命周期基准,检验纯文本 API 防御在不同攻击下是否有效。

    论文提出一个覆盖六类提取攻击、十种防御和两类自适应攻击的黑盒 LLM 模型提取生命周期基准,用于在纯文本 API 条件下比较防御是否有效。基准在每次比较中控制模型配置、查询数据、预算和 held-out 评测条件,同时保留各攻击的查询与训练流程,并测量代理模型能力、对受害模型的保真度、Rep-4 输出质量和查询预算敏感性。推断上,它把此前碎片化的攻击与防御评估放到同一预算和评测条件下,能减少因访问假设不同造成的误判,并帮助判断哪些防御在自适应攻击下仍有效。

  2. arXiv cs.AI75

    研究发现模型与 Agent 框架的配对会逆转性能排名且成本不决定表现

    该论文评估了 66 种配置,包括四种可配置框架(OpenHands、DeepSeek Harness、PI、openJiuwen)与五个模型的组合,在 TUA-Bench、ALE-CLI 和 Terminal-Bench 4 上测试发现,模型排名随框架变化而反转。例如在 Terminal-Bench 4 上,Claude 在 OpenHands 中领先 GPT 7.94 分,但在 PI 中落后 30.16 分。对于五分之四的模型,最佳框架在不同基准间并不一致,但部分配对具有稳定性,如 openJiuwen 使 Kimi 在所有三个基准上得分最高,提升幅度为 5.61 至 11.11 分。 证据细节显示,厂商原生框架并非总是最优解,且更高成本不能保证更高分数。GPT 在 PI 框架下的得分高于 DeepSeek Harness,但任务成本不足四分之一。轨迹匹配分析表明,模型自身处理修复的能力是关键变量,框架将失败反馈给模型的形式决定了最终效果:GPT 适应 PI 的轻量级脚手架,而经常发出格式错误工具调用的 Kimi 则在 openJiuwen 中表现最佳。 事实层面,研究已发布所有 6,204 条评分轨迹、代码及适配器;推断层面,这意味着单纯比较模型能力或框架能力的指标可能误导选型,必须结合具体任务场景进行联合评估;猜测层面,未来可能出现针对特定模型优化的专用框架,而非通用型框架通吃市场。

  3. arXiv cs.AI72

    ReLiveGym 通过数周重放真实世界信息流评测长时程智能体,发现行动时机机制影响性能

    论文提出 ReLiveGym,让大语言模型智能体在按时间重放的数周新闻、市场与社交媒体流中稀疏行动,以评测长时程任务。跨八个基础语言模型测试显示,智能体如何决定何时行动是重要的运行框架设计轴,最优设计会随任务和模型选择变化,持续从事后反馈中学习也影响性能并缓解失败模式。事实是这些结果来自预印本;推断是长时程智能体产品应把触发时机与反馈闭环纳入设计;材料未提供商业数据,故不猜测收益。

  4. arXiv cs.AI78

    智能体评测可靠性研究显示,更多任务并不总能修复智能体榜单排名。

    论文提出贝叶斯方差分解框架,发现智能体榜单中固定 model-scaffold 系统排名可靠,而底层模型排名可靠性明显更低。在 22 个 Holistic Agent Leaderboard 和 Harbor Index 基准上,固定 model-scaffold 系统可靠性为 0.935-0.994,底层模型可靠性为 0.148-0.841。当不确定性主要来自 scaffold 覆盖不足时,无限增加同类任务最多只能把模型排名可靠性提高 0.097;合并多样基准可在相同任务预算下把预测可靠性从 0.44 提到 0.75,并最多降低 83% 成本,推断上评估预算应优先投向 scaffold 与基准覆盖。

    推荐理由:它把智能体榜单可靠性拆到脚手架覆盖与任务数量,能校正加任务就能提升模型排名可信度的评估预算判断。

  5. arXiv cs.AI72

    Incident-Arena 发布:20个真实生产任务测试显示AI智能体故障修复成功率低于64.3%

    arXiv cs.AI 发布的 Incident-Arena 基准测试针对 AI 编码智能体在生产环境故障响应(agentic SRE)中的可靠性,包含20个基于真实开源软件构建的任务。该基准通过部署应用至临时 Kubernetes 集群、注入配置层及镜像层故障并施加持续负载,模拟真实生产场景,采用功能验证器而非静态检查来确保系统级指标稳定及修复安全性。 测试结果显示,跨3种应用底座的20个任务中,前沿模型得分均低于64.3%。失败原因涵盖诊断与定位错误、修复不完整以及引入不安全的回归。智能体平均消耗2.81M tokens并经历41轮交互,证明了长程推理需求远超现有基准设定。 事实层面,该研究证实当前模型在处理复杂生产故障时存在显著能力缺口;推断层面,这意味着将智能体直接应用于关键基础设施运维仍面临高风险,需解决长上下文下的稳定性问题;猜测层面,若无法突破此瓶颈,行业对“全自动运维”的商业化时间表可能需重新评估。

  6. arXiv cs.AI68

    Legal Research Bench 评估显示最强模型在长周期法律任务中全对率不足四成

    该论文发布 Legal Research Bench (LRB) 基准,包含 413 个由专家编写的开放式美国法律问题及金标准答案,旨在衡量端到端法律研究 Agent 的可靠性。评估结果显示,即使是表现最强的 Claude Opus 4.8 模型,在所有测试问题中的完全正确率仅为 42.9%。这意味着在需要识别管辖权、验证引用有效性并综合冲突法规的复杂场景中,当前前沿模型仍无法保证单一错误不会导致结果不可用。 研究团队采用全通过(all-pass)评分机制,要求响应必须满足所有标准且引用的权威来源经验证无误才算正确。实验发现,增加对话轮数、工具调用次数或推理成本并未带来准确率的提升。此外,性能在不同法律领域间差异显著,特别是在需要调和相互冲突的权威来源时,通过率进一步下降。LLM 裁判经过执业律师验证,其评分与人类判断高度一致。 事实层面,LRB 基准已公开,13 个前沿模型在特定设置下被评估。推断层面,单纯堆叠推理步骤或调用更多工具并非解决长周期任务可靠性的有效路径,核心瓶颈可能在于检索与验证机制而非生成能力。猜测层面,若要将此类 Agent 投入实际法律工作流,必须引入更严格的中间验证层,否则目前的技术水平尚不足以支撑自动化决策。

  7. arXiv cs.AI42

    Frozen Scenes, Shifting Winners: Configuration Fragility in Text-to-3D Evaluation

    针对文本生成 3D 场景的评估,研究发现渲染设置和提示词变化导致 17/19 个对齐评估器的配置方差超过生成器间方差。在 300 个固定场景中测试 19 个评估器时,18/19 个评估器在不同配置下改变了点估计获胜者。该审计建议报告生成器、分数与协议 ID,并强调选择相关的评估不确定性。

  8. arXiv cs.AI48

    JusticeAxis 如何评估法律判决在规则应用与自由裁量间的平衡

    JusticeAxis 将法律判决形式化为参考锚定任务,引入包含 256 起真实刑事案件的基准及 JusticeAgent 智能体框架。实验显示模型规模变化导致失败方向改变:开源骨干模型转向无依据理由,前沿模型则回归法定默认值。该框架验证了冻结开源骨干模型作为插件可达商业水平。

  9. arXiv cs.AI68

    R2T 用可执行检查提升科学计算 LLM Agent 的代码修复表现

    R2T(Rules to Tools)把公开科学计算要求预先做成可执行检查,供科学编码 Agent 在修复 SciCode 任务时使用。与只拿到文本规则、起始程序、模型和预算的对照组相比,拿到可调用检查的工具组在两个任务 ID 队列中完成修复数从 26/30 提升到 29/30。 细看任务层面,工具组在三个任务 ID 上占优,一个任务上文本占优,十一个任务打平;八 ID 队列中工具组 15/16、文本组 13/16,但任务聚类 bootstrap 95% 区间为 [-12.5, 43.75] 个百分点,说明差异并不稳健。更大的共享定义 SciCode 队列两组均 13/24;在更换起始程序的五个开发暴露任务上,工具组 7/10 对文本组 3/10。匹配 PDE 对比中,详细文本 23/24、检查 24/24,且检查组报告的模型输出低 31.2%,但公共 CPU 使用在两个任务 ID 队列中都上升。 事实是可执行检查能减少部分科学计算代码修复失败,并可能降低 Agent 侧输出成本;推断是其收益取决于任务是否已有可靠初始检查,且可能把成本转移到公共算力;猜测是这类方法更适合有明确方程、边界条件和输出要求的科学计算场景,而不是泛化到所有编码 Agent。

    推荐理由:论文用 SciCode 修复任务对比文本规则与可执行检查,显示检查可提升部分任务修复率但结果高度任务依赖,可用于判断 Agent 代码验证应优先做可执行校验而非纯提示约束。