SpecBench：软件工程中大型语言模型智能体的规范级推理评估

论文编号 ：arXiv:2605.30314v1

主题：软件工程中规范（Specification）级推理的评估基准。

核心发现 ：现有的 SWE-Bench 等基准主要关注代码生成层面的推理，而现实中的软件工程要求智能体具备设计、审查规范（如 RFC）的能力。本文提出的 SpecBench 专门评估智能体生成完整、无歧义、一致且正确系统规范的能力。

📌 背景与动机 (Motivation)

问题现状 ：现有的基准（如 SWE-Bench）主要关注 实现级推理 (Implementation-level reasoning)，即从给定的、完整且正确的规范中生成代码。
现实需求 ：真实的软件工程涉及大量的 规范设计 (Specification design)。初始提案通常不完整、存在缺陷，需要专家审查。
核心任务 ：
- 给定初始设计提案、代码库和历史 RFC (Request for Comments) 讨论记录。
- 智能体必须识别 规范缺陷 (Specification deficiencies) ，包括：
  - 遗漏 (Omission)：缺失必要信息。
  - 歧义 (Ambiguous)：存在多种解释。
  - 不一致 (Inconsistent)：与其他部分或现有系统冲突。
  - 不正确 (Incorrect)：与前置信息矛盾。

🛠️ SpecBench 设计与方法 (Methodology)

1. 数据来源

任务源自真实世界 RFC 流程 中的五个多样化仓库：
- Kubernetes
- React
- Rust
- TVM
- vLLM

2. 缺陷分类依据

基于 IEEE Std. 1028-1997 及先前的软件规范研究：

Omission: 缺少必要的信息。
Ambiguous: 信息有多种解释。
Inconsistent: 与其他部分或现有系统存在冲突。
Incorrect: 与之前的文档或信息相矛盾。

3. 评估设置

预测结果与从历史 RFC 线程中提取的 专家验证金集 (Expert-validated golden sets) 进行匹配。

🔍 关键挑战与解决方案 (Challenges & Solutions)

挑战	解决方案
人类专家差异 (Human Expert Variance)	使用 LLM 专家面板对缺陷进行 5 点李克特量表评分。达成共识（均值 ≥3.0 且 ≥2/3 支持）的项目标记为 `核心 (Core)`；否则为 `扩展 (Extended)`。核心项在评分中获得 2× 权重。
开放世界验证 (Open-World Validation)	不在金集中的预测视为 `未评判 (unjudged)`。实施有界预测预算：智能体预测数量最多为金集大小的 `1.25×`。仅金集内的预测计入分数。
预测评判 (Prediction Judging)	使用 SPI 分解 (Subject-Predicate-Impact) 标准化预测与金集。使用集成评判 (Ensemble judging) ：两两 LLM 评判（共 4 次试验）。匹配需要多数票 (≥3/4 次试验)。

📊 评估结果 (Results)

最佳表现模型 ：Codex-5.4 取得了 44.4% 的准确率。
整体表现 ：所有评估模型的得分均低于 45%，表明在规范级推理方面仍有巨大的提升空间。
核心 vs 扩展 ：所有模型在 核心 项（高共识）上的得分均高于 扩展 项，符合分层评分设计。
仓库表现 ：Codex-5.4 在 React 和 vLLM 领域表现领先，分别超出第二好系统 9.5% 和 8.6%。
评判一致性：通过中位成对 Jaccard 相似度测量。未来版本将增加评判多样性和试验次数。

📈 下一步与未来工作 (Future Work)

规范修订任务 ：扩展 SpecBench 以评估 规范修订任务 (Specification revision tasks)，即纠正识别出的缺陷。
人类专家验证：替换仅 LLM 的评审，引入人类专家验证，报告人类间和人类与 LLM 间的一致性（如 Cohen's κ）。
鲁棒性研究 ：评估预测预算 N、核心/扩展加权、评判多样性以及 SPI 匹配稳定性。
数据集覆盖 ：包括被拒绝的提案或停滞的提案，并扩展生态系统：Python PEPs、Linux kernel、LLVM。
模型评估：评估更广泛的模型/工具配置和推理设置。

📋 附录：黄金标准示例 (Appendix Highlights)

Kubernetes Gang Scheduling RFC 黄金缺陷示例

ID	类型	关键发现
1	核心	Pod 引用不存在的 Workload 时行为未定义；缺乏防止永久挂起的机制。
3	核心	死锁避免和重试生命周期在竞争 Gangs 和部分失败情况下未明确说明。
5	核心	调度进行中的 WorkloadSpec 字段可变性规则未定义。
8	核心	Pod 到 PodGroup 的关联机制不明确（显式字段 vs 选择器）。
10	核心	WorkloadStatus 留为 "TBD"，阻碍了操作员的观测性。

SPI 分解与评分示例

ID	主题 (Subject)	缺陷类型	影响 (Impact)
1	引用不存在的 Workload 的 Pod	缺乏定义拒绝与推迟行为的区分	不可调试的无限阻塞和不安全操作
2	Gang 级抢占语义	关于优先级规则和部分 Gang 可调度性未明确说明	提前抢占的工作负载导致中断

📝 总结 (Summary)

SpecBench 填补了软件智能体评估中"规范设计"的空白。通过引入基于 RFC 流程的专家验证金集和 SPI 评判分解，该基准有效量化了智能体在识别和生成高质量软件规范方面的能力。实验结果表明，尽管前沿模型（如 Codex-5.4）表现出一定的推理能力，但在规范级推理上仍有显著差距，尤其是在处理复杂系统（如 Kubernetes）时。