跳到正文
#能力评测
10月23日周五
  1. arXiv · cs.AI42

    ColaBench：评估个人智能体中记忆引导的知识获取

    研究者提出个人智能体基准 ColaBench，覆盖健康与日常生活场景，包含 349 个任务、10 个 Profiles 和 13,033 篇文档的知识库，通过 Evidence Graph 将个人状况与公开交互记录及文档证据关联。配套方法 MemKB 利用状态摘要、规则应用和记忆-文档链接检索知识，达到 86.25% Accuracy，平均每任务 4.07 轮交互。错误分析发现无依据的个人假设和规则误用是主要障碍。

  2. arXiv · cs.AI35

    SecLog-Bench：基于阶梯式证据的网络安全日志推理可扩展评测基准

    SecLog-Bench 是一个可扩展的网络安全日志推理评测基准，构建覆盖 29 种攻击场景的仿真平台，结合审计日志、应用日志和网络流量多源证据，并为每个样本标注结构化分步证据链。对 8 个主流 LLM 的评测显示，最佳模型准确率仅 44.44%、Macro-F1 为 45.07%，最高 Stage Reasoning F1 仅 54.87%，表明当前模型攻击进展推理能力有限且推理质量与预测准确率常不一致。

  3. arXiv · cs.AI21

    评估人工智慧（AW）：一种基于轨迹的情境敏感决策调节框架

    arXiv 论文提出评估人工智慧（AW）的基于轨迹的测量框架，将其行为化定义为对判断的情境敏感调节，并用九组件画像、两项转换指标和关键失败报告进行评分。三项简化模拟显示：单准则模拟在每领域 24 个情景时达到精度标准；瓶颈估计在接近平局时存在 0.55 点的下偏；增量预测模拟用 8 和 12 个模型族分别以 .508 和 .742 的概率检测到 0.027 的 Brier 改善。12 模型族目标仍属暂定，画像能否预测超越能力的独立决策结果仍是开放问题。

  4. arXiv · cs.AI47

    危害在于行为，审核止于词汇：语言与文化如何决定自动化安全系统保护谁、消音谁

    一篇 arXiv 论文提出，内容审核系统的过度拦截与保护不足同源于依据词汇表面形式而非信息功能判断危害，并归纳为七种失败模式。作者提出一套评估协议，在 11 种语言上测试五个开放系统，55 个系统-语言组合中有 51 个无法在母语者水平区分有害功能与无害形式；能力提升在九种语言中改善判别，但阿拉伯语和罗马化印地语仍接近随机，最受益与最不受益语言社区之间的差距随能力扩大。

  5. arXiv · cs.AI44

    诊断 LLM 的显式到应用心智理论鸿沟

    一项 arXiv 研究指出，LLM 的 ToM 基准总分混淆了显式 ToM（识别信念）与应用 ToM（用信念预测行为）。在 SimpleToM 上，Llama-3.1-8B 总分 51.5%，但识别心理状态达 99.4%，预测行为仅 28.9%。提出 BSTTT 结合提醒语后，Llama 行为预测提升 40.8 个百分点，其中提醒贡献大部分，BSTTT 额外增加 1.3 至 5.5 个百分点，研究者建议分别报告显式与应用准确率。

  6. arXiv · cs.AI45

    Dual Exam：多模态智能体与世界模型的受控评测

    arXiv 论文提出 Dual Exam 评测框架，在物理、数字、社会和科学领域分别固定环境响应测试多模态智能体、固定动作干预测试世界模型。Agent 赛道含 1,088 项、15 类报告维度的 10 种配置，GPT 6 Astra 以 31.3 的 Agent Index 居首；World Model 赛道含 400 个案例、8 个场景，GPT-Image-2 以 21.7 的全覆盖总分领先。150 个案例的耦合试点任务成功为零，揭示了任务表现不均与任务相关状态保持失败的问题。

  7. arXiv · cs.AI20

    MQAScore：基于大型音频语言模型的细粒度文本-音乐对齐评估

    研究者提出 MQAScore，利用大型音频语言模型（LALM）对二元问题的肯定回答概率，沿流派、乐器、情绪主题、人声、用途五个维度逐一验证原子音乐概念。他们还基于存在/缺失标注和 LLM 引导的概念替换构建验证标签，并提出 Sensitivity-Invariance Ratio 衡量评估器对改变语义替换的选择性响应。实验显示概念级评分可提升问答式与相似度式评估器，MQAScore 可作为全局相似度的可靠、可解释细粒度补充。

  8. arXiv · cs.AI44

    成对评测遗漏了什么：跨 prompt 的奖励模型分数问题

    一项 arXiv 研究指出，成对评测会让同一 prompt 下响应共享的分数成分相互抵消而未被检验。作者提出基于 prompt 间方差占比、兄弟评分回归和 prompt 替换的人类参照审计，测试 18 个已发布评分器与 6 种匹配训练条件；在 HelpSteer2 上，6 个 reward model 的 prompt 间份额为 0.34 到 0.64，而人类评分接近零。研究建议奖励模型评测应分别检验 prompt 间方差、对错误 prompt 的敏感性以及对选择的有用性。

  9. arXiv · cs.AI48

    ProductWebBench：超越任务完成度的网站连续性评测基准

    论文提出 ProductWebBench 基准，在真实前端仓库上同时评分需求完成与网站连续性，包含 320 个 Change 任务和 80 个 Build 任务。基于 13 个模型共 8,737 次运行，通过全部需求检查的 Change 运行中仍有 28.2% 未通过连续性检查，18.3% 破坏了已验证状态。此外，静态 DOM 通过的运行中有 29.5% 在交互环节失败。

  10. arXiv · cs.AI41

    Post-Audit Mirage：离线智能体验证的可识别性极限

    一篇 NeurIPS 2026 工作坊论文提出“事后审计幻象”：离线测试可能无法揭示智能体更新部署后是否安全。作者用匹配的安全与有害生命周期构造可执行审计边界，并给出错误-弃权权衡定理。Post-Audit Mirage benchmark 覆盖授权、调度与共享容量环境，实验表明监控在有利条件下可恢复关键区分，但对稀有群体、小效应或缺失观测可能仍无法判定。

  11. arXiv · cs.AI43

    工具增强模型对比中的提示词敏感性问题

    arXiv 论文提出一种匹配协议，将工具增强问答评测拆分为答案读出、推理、调用决策、工具返回和无调用报告五个步骤，以检验工具是否让模型对比更稳定。在五个领域、五种问法下测试六个开源模型后发现，工具在程序可作答的场景提升准确率，但会扩大许多两两对比的措辞敏感性，其程度随模型调用频率变化。作者建议在准确率之外同时报告调用频率和多措辞下的对比稳定性。

  12. arXiv · cs.AI49

    LLM-as-a-Judge 提示策略的效果取决于评测模型：一项多语言鲁棒性研究

    一项多语言研究发现，LLM-as-a-Judge 评估中的提示策略不可跨模型迁移：评测模型的选择比提示策略的选择影响更大，同一策略在不同 judge 上效果方向会反转，且低资源语言下稳定性下降。研究测试了 9 种提示策略、4 个开源 judge 模型、27 种语言、4 个任务共 13 个数据集，产出超 100 万条基于标准答案的点对评分，并经人类判断验证。研究建议提示策略应针对具体评估场景验证，跨研究比较需同时考虑 judge 与提示配置。

  13. GitHub · 去对齐工具与仓库28

    Ollama 本地模型基准测试结果看板上线 GitHub

    GitHub 上的 z440-ollama-benchmarking 项目发布面向本地运行 Ollama 模型的交互式基准测试结果看板。看板提供可排序、可筛选的模型对比表、基于 `ollama ps` 实测内存的 VRAM 可行性指示、生成速度与内存占用图表，以及质量分级热力图和指标术语表。通过主仓库运行 Publish-Website.ps1 -Push 即可重新生成 data.js 并推送最新结果。

  14. GitHub · 灵魂体仓库51

    Tajima 发布护理执业考试 LLM 一致性研究的数据与代码仓库

    Tajima（Shumei University）公开了预部署评估研究的数据、分析脚本和图表代码，研究考察 GPT-4o、Claude Opus 4.5 与 Gemini 2.5 Flash-Lite 在护理临床判断题上的输出一致性何时不再对应正确率。主分析（Study 2）基于日本国家护理考试 2018–2026 年间公开的 90 道题，90 题 × 11 个模型-温度条件 × 30 次 = 29,700 条响应；修订版将受并列项顺序影响的分诊 AUC 修正为 GPT-4o 0.77、Claude 0.50、Gemini 0.68。

  15. Reddit · r/LocalLLaMA66

    Flint 40B-A2.5B vs Ornith 1.5 35B-A3B vs Nemotron 3.5 Lightning 本地编码 agent 横评

    作者在相同的 Opus 5.5 规划、3 worker 并行设置下，用 llama.cpp Q8_0 在 RTX PRO 6000 Blackwell 96GB 上实测三个小型 MoE 编码同一个 Three.js 万圣节连锁反应场景。Flint 40B-A2.5B 综合最优：墙钟 7:36、修复 6 次、Opus 花费 $0.41；Nemotron 3.5 Lightning 解码最快但生成约 5 倍 token、修复 16 次、花费 $0.95，其编辑成功率仅约 17%。作者指出换 worker 模型使规划者账单从 $0.41 涨到 $0.95，裸 tok/s 并不决定总耗时，且三者在单轮内都没产出完全可用的场景。

    推荐理由：同一任务同机实测三个小型 MoE 当编码 worker，给出 token 消耗与 Opus 花费对比，显示编辑成功率比裸速度更影响实际耗时。

  16. Reddit · r/LocalLLaMA33

    Qwen 3.8 Flash Next（129 GB）在量化对比中胜过 DeepSeek V4.1 Flash 1017（187 GB + 203 GB Engram）

    Reddit 用户用修改版 BenchKit 对比 Qwen3.8-Flash-Next-W4A16-FP8PLE（129 GB）与 DeepSeek-V4.1-Flash-1017 2.6 bit 量化版（187 GB + 203 GB Engram），Qwen 以 25/25 满分胜过 DeepSeek 的 23/25。HumanEval 第 22 题上 Qwen 18.8 秒答对，DeepSeek 思考 127.9 秒后陷入循环被终止；第 24 题 DeepSeek 等待 297.7 秒未答出，Qwen 34.5 秒给出正确答案。作者表示将继续使用 Qwen。

  17. GitHub · 灵魂体仓库49

    llm-verifier-reliability：NeurIPS 2026 Verify-Agents Workshop 论文验证实验代码与数据发布

    该仓库发布 NeurIPS 2026 Verify-Agents Workshop 论文的验证可靠性实验代码与数据，共 64,800 次 verification calls，覆盖 HumanEval+、MATH、GPQA-Diamond 三个领域、每域 150 题，报告 headline +13.1 pp 的 self-preference gap。代码为 MIT 许可，派生产物为 CC BY 4.0；GPQA-Diamond 题目文本被隐去，需 HF_TOKEN 本地恢复。

  18. Reddit · r/LocalLLaMA38

    Meta 816B Muse Spark Open 在 Artificial Analysis 得 39 分，180B Qwen3.8-Flash-Next 得 40 分：11 个开源权重模型得分与规模对比

    基于 Artificial Analysis 数据绘制的 11 个开源权重模型得分与总参数量（log 轴）对比图。Muse Spark Open（816B，42B active）得 39 分，Qwen3.8-Flash-Next（180B，6B active）得 40 分；最高为 MiMo-V2.6-Pro（1T）的 46 分，DeepSeek V4.1 Flash 1017（552B）和 GLM-5.3（753B）均为 45 分。该指数是 AA 自评的单一综合分，不反映速度、长上下文或视觉能力。

  19. GitHub · 去对齐工具与仓库51

    serbeval 塞尔维亚语 LLM 基准发布，GPT-6-sol 以 99% 居首

    作者发布塞尔维亚语大语言模型基准 serbeval，基于 lm-evaluation-harness 0.4.12，官方集 v1.2 共 351 题，其中 61 题经人工核验、214 题由四模型共识确认、76 题由其派生，重点考查翻译无法覆盖的语法现象如格支配、动词体、aorist/imperfect、正字法与西里尔/拉丁字母一致性。30 个模型经 OpenRouter 零样本评测显示 openai_gpt-6-sol 以 99% 居首，gemini-3.8-flash、claude-opus-5.5、gpt-6.1-sol 98%，前沿模型差距很小，剩余错误多为有争议的正字规范；DeepSeek V4 Pro 达 95% 超过 Sonnet 5.5（94%），Kimi K3 92%。

  22. Reddit · r/LocalLLaMA50

    RTX 5090 实测 Qwen3.8-FN NVFP4 三引擎性能：basalt 全场景最快

    作者在单张 RTX 5090 上对 Qwen3.8-Flash-Next NVFP4 的 basalt、capy-flash、ninfer-ext 三个引擎做了 262,144 token 全上下文对照测试，统一开启 MTP 推测与 int8 KV。结果 basalt 在所有上下文深度最快，prefill 8.1k-9.2k tok/s、greedy decode 176-265 tok/s；decode 排名与 MTP draft 接受率一致（0.74/0.57/0.56），采样解码使各引擎 decode 下降 7-10%。

  23. GitHub · 去对齐工具与仓库66

    六个免费模型工具调用横评：gpt-oss-20b 以 88% 准确率胜出

    Shinzuu 发布 free-model-bakeoff 评测，六个免费模型在 126 次评分尝试、14 个对抗性问题上跑生产级 tool-calling 流程。openai/gpt-oss-20b 答对 88%、工具路由正确率 95%，超过比它大六倍的模型（64%/76%）；同一权重换托管方降到 64%、中位延迟 28 秒。关键发现包括每日 20 万 token 的隐性限额（约等于全团队每天 60 个问题）、一句补充 'open' 定义的系统提示词带来最大准确率提升，以及评测中发现并修复的六个 harness bug。

    推荐理由：实测给出六个免费模型的准确率与工具路由数据，并指出同权重不同托管方的表现差异可能比模型间差距更大。

  24. GitHub · 灵魂体仓库59

    SurfBench 基准发布：用 50 个真实任务评测各网页访问 API

    riccardogiorato 发布 SurfBench 基准，用 50 个真实任务（分 4 个层级）统一评测 parallel、exa、tavily、firecrawl、keenable、linkup 等网页访问 API，检查各服务商能否找到并抓取正确页面。评分按质量 0.50、可靠性 0.35、速度 0.15 加权，使用固定的 MiniMax M3 读取模型和 Kimi K3 + GLM-5.3 评审面板，给出 95% 置信区间与每千个通过任务的成本列，完整结果包、任务检查器与方法论页面随仓库公开，MIT 协议，可自行运行复现。

    推荐理由：这是一个可直接复现的网页访问 API 评测基准，方法论、提示词与评分细则全部公开，还给出了置信区间与成本列。

  25. GitHub · 灵魂体仓库26

    llm-research 使用指南：如何用本地 Java 应用向多家大模型批量提问并保存结果

    GitHub 开源项目 llm-research 是一个本地 Java 21 应用，可向 OpenAI、Claude、Gemini、Grok、DeepSeek、Qwen 等多家模型提供商批量发送 questions.csv 中的问题并保存答案。用户通过 .env 配置 API 密钥、application.yml 选择启用的提供商，每次运行在 output/ 目录生成 xlsx、csv、jsonl、json 四种格式的结果，并记录延迟和输入/输出 token。每次调用消耗 API 额度，项目建议首次只用 1 个提供商、1 次重复和少量问题进行验证。

  26. GitHub · 灵魂体仓库50

    matt-riley 开源 skill-evaluator：为 AI 技能提供评测驱动的迭代工具

    matt-riley 在 GitHub 发布 skill-evaluator，用于对 AI skills 做评测驱动迭代：定义测试用例后，让 agent 分别在有技能和无技能的情况下运行，由 LLM 给输出打分并对比基准结果。工具支持 `skill-eval init`、`skill-eval loop`（运行→评分→基准）和 `skill-eval report` 生成 HTML 报告，可通过 brew 或 `go install` 安装。

10月22日周四
  1. Reddit · r/LocalLLaMA35

    MOSS-Transcribe-Diarize 0.9B 在 MacBook 上实测 AMI 四人会议：全部说话人识别正确，说话人混淆率 0.08%

    在 17 分 29 秒的 AMI 四人会议音频上，MOSS-Transcribe-Diarize 0.9B 在 M5 Pro MacBook（64 GB、mps）上以 fp32 单次完成转写、说话人标注和时间戳，耗时 714 秒，约 0.68x 实时。四个说话人全部识别，0.25 s collar 下说话人混淆率 0.08%，整体 DER 15.4%；317 段中 87 段为重叠语音且均标注了不同说话人。

  3. GitHub · 3D 生成新仓库36

    RadMatch：基于 LLM 的可审计放射报告评估框架开源上架 PyPI

    新开源框架 RadMatch 用 LLM 评估放射报告生成质量：先从报告中抽取原子化 findings，按临床等价性匹配预测与 ground truth，再从七个临床属性维度刻画每处错误，并以 actionable_errors_per_report（越低越好）作为核心分数。所有中间步骤均写入磁盘，分数可回溯到具体 finding 对，并提供可选 dashboard。支持 OpenAI、Anthropic、Mistral 及 OpenAI 兼容自托管端点，示例使用本地 vLLM 部署的 Gemma-4-31B（fp8 量化）。

  4. GitHub · 3D 生成新仓库47

    NVIDIA 开源 SkillEvaluator：检测 AI Agent 技能质量及其对任务效果的影响

    NVIDIA 发布开源工具 SkillEvaluator，用于检查 AI Agent 技能并衡量技能对任务结果的影响。它提供三层评估：Tier 1 静态校验（可用 Semgrep、SkillSpector、Gitleaks 做安全扫描）、Tier 2 基于 embeddings 的重复检测、Tier 3 通过 Harbor 沙箱对比有无技能的实际运行效果。示例技能可获得 84.5/100（B）评分，默认通过阈值为 70；工具支持 uv 运行 Python 3.13，可通过 NVIDIA Build API key 调用模型。

  6. Reddit · r/LocalLLaMA63

    ggufbench 实测 8 个本地 GGUF 模型的 agent 编码能力：27B 级已够用

    作者 /u/Joralk_ 自建 harness，在 2× RTX 5080 上以统一采样配置实测 8 个本地 GGUF 模型的工具调用、代码与 agent 任务，每任务跑 3 个种子并统计均值与标准差。结果显示 125B 的 Qwen3.8-Flash-Next 并非榜首，35B MiniCPM-V-4.7 与 27B Qwen3.8 在 agent 任务上与其持平，工具调用可靠性比模型规模更关键；开启 thinking 模式使 27B 代码分从 0.79 升至 0.93、agent 分从 0.90 升至 0.96，但延迟从 36 ms 增至 629 ms 且每调用多花约 253 个中位 token。

    推荐理由：作者自建 harness 实测 8 个本地 GGUF 模型的工具调用与 agent 编码表现，还给出 thinking 模式开关的量化代价，方法可复用。

  7. GitHub · 去对齐工具与仓库68

    agents-per-gpu 实测单张 A40 上 vLLM、SGLang 与 TensorRT-LLM 的 Agent 并发容量

    作者开源 agents-per-gpu 仓库，在单张 48 GB A40 上以 Agent 形态负载实测 vLLM 0.32.0、SGLang 0.5.9 和 TensorRT-LLM 1.2.1 服务 Qwen3-4B 的并发容量。开启 prefix caching 后三个引擎均能承载 6 个并发 Agent 会话，关闭时仅 2 到 3 个，且每任务成本降至原来的三分之一到五分之二；8 秒 step SLO 下 SGLang 以 4 个会话领先。INT4-AWQ 量化的 Qwen3-8B 在工具调用精度持平的情况下比 BF16 的 4B 承载更多 Agent。所有数字可用 apg report 从 results/ 复现，方法与细节见 reports/REPORT.md。

    推荐理由：作者在单张 A40 上实测三种推理引擎的 Agent 并发容量，并给出 prefix caching 带来的容量差和每任务成本数据。

  9. Reddit · r/LocalLLaMA39

    基于 NVIDIA AIPerf 构建的 LLM 基准测试工具发布 alpha 版，征集反馈

    Reddit r/LocalLLaMA 用户基于 NVIDIA AIPerf 开发了一款易于理解的 LLM 基准测试与调优工具，目前处于 alpha 阶段并公开征集反馈。工具能报告在指定延迟目标下服务器可承载的用户数、哪个环节最先成为瓶颈，以及下一步应调整哪个 vLLM 参数，附有 llama 3.1 8b 在单张 H100 上的示例报告。

  11. Reddit · r/LocalLLaMA20

    LFM2.5-24B-A2B 实测体验不佳：LocalLLaMA 用户称其反复循环、代码任务表现差

    Reddit 用户实测 LFM2.5-24B-A2B-Q4_K_M.gguf 后给出负面评价：在 llama.cpp 优化版上 RTX A4500 跑出 130tk/s 但反复循环，换 LM Studio 后行为稳定。在 Hermes 桌面端测试 Microsoft Garnet 插件任务时，经 GPT 检查发现代码残缺、缺少必要功能且未做端到端测试就声称验证通过，模板修复后改善有限。

  12. Hugging Face Blog45

    IBM Granite 时间序列模型集成预测

    Hugging Face 发布 Granite Timeseries Ensemble，将四个不同架构的预训练 Granite 时间序列模型（PatchTST-FM-r1、PatchTST-FM-r2、FlowState-r1.1、TTM-r3）组合成一个无需重训练、无需拟合权重的集成预测接口。默认 Probabilistic Ensemble 采用等概率池化，另提供按预测离散度自适应加权的 IQR Ensemble。两个配方在 97 个 GIFT-Eval 数据集配置上评估，配置经宽松许可开源，可通过 granite-tsfm>=0.3.11 从 Hugging Face 加载。

  13. GitHub · 灵魂体仓库39

    LLM_Trend_Observer：自动化大模型排行榜监测系统，每日推送 LMSYS、OpenRouter 等榜单变化

    GitHub 上的 LLM_Trend_Observer 是一个自动化大模型排行榜监测系统，持续抓取 LMSYS Chatbot Arena、OpenRouter Rankings、Hugging Face Open LLM Leaderboard 和 Artificial Analysis 数据，自动计算排名变化。报告包含排名、Token 使用量、Elo 分数及变动 Delta，通过 WXPusher 或 Server酱 每天北京时间 11:00 前推送到微信或手机 App。

  14. GitHub · 灵魂体仓库56

    McPair 麦麦配开源：LLM 只做意图理解，套餐搭配由确定性求解器算出

    开发者开源了麦当劳配餐 Skill「McPair 麦麦配」（github.com/paraboy-s/mcd-meal-pairing），LLM 只做意图理解与渲染，价格、热量、用券全部由确定性代码经 MCP 工具计算，每个数字可追溯。系统枚举门店 1881 种搭配剪枝出三档方案，含品味指纹（带置信度）、券诊断、反事实解释和 max-min 拼单分配；40 场景评测中主餐口味契合 0.55、热量贴合 0.78、16 个场景用上券，消融显示关闭品味引擎后口味契合跌至 0.05。该项目为麦当劳程序员创意开发大赛参赛作品，非官方产品，只做决策不下单。

    推荐理由：把意图理解交给 LLM、算账交给确定性求解的架构，附带消融实验和基线对比，是一套可迁移的 Agent 工程参考。