跳到正文

#评测/基准

今日 14 条
今天10月2日周五
  1. Hacker News · AI78

    deepsense.ai 提出面向生产的 AI 系统评估模式，用 harness、重复运行和失败诊断替代公开 benchmark 做部署判断

    deepsense.ai 提出，生产 AI 系统评估不应以公开 benchmark 分数作为部署依据，而应评估模型、harness、工具、记忆、执行路径、可靠性、成本和业务结果。文章认为，2026 年公开评估已更接近端到端专业工作流，但 benchmark 分数只说明特定测试协议下的表现，不能证明系统会泛化到真实用户、数据、工具和约束；公开 benchmark 更适合建立候选短名单，而不是直接决定上线。 两个细节最能说明问题。事实是，OpenAI 在 ARC-AGI-3 中展示，启用 retained reasoning 和 compaction 后，GPT-5.6 Sol 的分数从 13.3% 提升到 38.3%，同时输出 token 约少 6 倍；模型没有变，变的是系统如何保存推理和管理上下文。作者自己的 EDA benchmark 也显示，Claude Fable 5 的平均分 0.50 高于 GPT-5.6 Sol 的 0.48，但按重复运行方差调整后，GPT-5.6 Sol 的可靠性调整分 0.46 高于 Claude Fable 5 的 0.42，说明平均分可能隐藏不稳定。文章还指出，工具响应可能事实正确但不可用，例如缺少单位、结构不适合下游 agent、没有回答用户目标。 从事实看，文章把部署前评估、生产监控和失败回归串成三个循环，并提到 Harbor 保存完整轨迹、轻量模型聚类问题、人工审查关键 trace。推断上，这会改变模型切换决策：团队更可能依据自有回归集、首跑成功率、单位成功成本和失败诊断，而不是公告分数；对交易、客服或合规类 agent，重复成功比单次高分更重要。猜测上，评估平台可能成为企业 AI 工程的核心资产，但原文没有给出市场、收入或采用率证据。

    推荐理由：它把部署判断从公开基准分数转向生产运行环境、重复运行方差、单位成功成本和失败诊断，能校正高分模型即可上线的误判。

  3. InfoQ 中文82

    谷歌发布 Gemini 4 Argon，输出上限升至百万 Token 且初期仅向受信任安全团队开放

    谷歌发布新一代模型 Gemini 4 Argon，主打长流程软件工程、企业知识工作与网络安全防御，输出 Token 上限从 64K 提升至 100 万，并采用分阶段开放：初期仅通过 Fairwind 计划向受信任的网络安全防御团队提供，后续才从付费 API 客户和 Google AI Ultra 订阅用户开始，具体时间未公布；定价为每百万输入 Token 2 美元、每百万输出 Token 10 美元，缓存输入价格较普通输入低 95%。 容易被标题带偏的是两个口径。其一，谷歌披露 Argon 智能体参与 C/C++ 向 Rust 的迁移，规模从 re2、libgav1 等核心库扩展至 Fuchsia 操作系统 Zircon 内核的 80 多万行代码，但原文明确这不代表迁移已完成或投入生产；libgav1 案例中替换约 3.2 万行 SIMD 代码后运行速度达到原 Rust 移植版本的 2.7 倍，比较对象是 Rust 移植版而非优化后的 C++ 实现。其二，DeepSWE v1.1 的 77.9%、AutomationBench 的 51.3%、LVBench 的 91.7%、CWE-bench v1 的 68% 并列第一均为谷歌公布或引用的结果，且配套表格中 GPT-6 Astra 在 FrontierSWE v2、Terminal-bench 4.0 等项目上仍高于 Argon，全面碾压的说法并不成立。 事实层面，谷歌把网络安全防御作为优先开放领域，向受信任防御者提供不带网络安全防护措施的版本，并计划用对齐偏差监测跟踪模型思维链与行动，必要时停止执行；推断层面，受信任测试者先行的节奏意味着公开跑分与开发者实际可用性之间的差距在拉大，正如评论中基准领先但普通开发者还拿不到 API 的质疑；猜测层面，后续开放时间未公布，付费 API 与订阅用户何时能用仍无依据。对准备把智能体接入工程流程的团队而言，眼下可依赖的是价格、输出上限这类硬参数，而非内部案例的性能倍数。

    推荐理由：材料拆出了Argon迁移案例与跑分的真实口径：2.7倍速度是对比Rust移植版而非C++，80万行内核迁移尚未投产，可校正把基准成绩当工程落地能力的判断。

  6. arXiv cs.CR72

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

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

  7. arXiv cs.AI72

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

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

  8. 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 与基准覆盖。

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

  10. arXiv cs.AI42

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

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

  11. arXiv cs.AI48

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

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

  13. 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 代码验证应优先做可执行校验而非纯提示约束。

  14. Hacker News · AI84

    Best-of-Agent-Harnesses 每周重排 167 个 AI agent harness，并提供 MCP 选型服务

    Best-of-Agent-Harnesses 是一个持续更新的开源清单，收录 167 个 AI agent harness、编排框架和相关技术，按与 harness 相关性和 GitHub stars/活跃度每周重排。它把 harness 定义为模型之外决定工具、审批、上下文、崩溃恢复和运行生命周期的运行时层，并提供可搜索站点、模板、playbook、harnesses.json、llms.txt 和一个可供 agent 调用的 MCP server。 材料给出的关键证据是同一模型换不同 harness 会显著改变成绩：在 SWE-bench Pro 相关分析中，GLM-5.2 的 pass@1 从 23% 到 52%，Gemma 4 26B 从 15% 到 36%；不同模型间的 harness 排名相关性约为 -0.05。材料还称一个裸前沿模型在 ARC-AGI-3 上约 30%，而 Prime Agent 的 harness 将 Opus 5 提升到 95.5%。这些数字被用来支持“harness 选择必须随模型和任务重新评估”的判断。 清单将项目分为编码代理产品、个人代理运行时、框架、多代理编排、MCP/插件、记忆层、评测和可观测性等类别，并标注 headless、durable、开源许可、复杂度等工程属性。事实是该项目提供了机器可读接口和推荐工具；推断是它试图把 agent 选型从静态榜单转向“模型—任务—harness”配对；猜测是若这些基准可复现，harness 工程可能比单纯升级模型更能影响长任务交付质量。

    推荐理由：它把 agent harness 从框架选型变成可按模型配对、可复测的工程决策，能改变选型和试用流程。