SemVerBench: Benchmarking LLM Comprehension of Version-Constraint Resolution Semantics
作者: Qibai Chen, Zeming Liu
分类: cs.AI, cs.SE
发布日期: 2026-09-10
备注: Accepted at the 38th IEEE International Conference on Tools with Artificial Intelligence (ICTAI 2026). 8 pages, 6 tables
💡 一句话要点
提出SemVerBench以评估LLM对版本约束解析语义的理解
🎯 匹配领域: 支柱九：具身大模型 (Embodied Foundation Models)
关键词: 大型语言模型 版本约束解析 基准测试 软件开发 机器学习
📋 核心要点
- 现有的LLM在版本约束解析方面存在系统性的盲点，未能有效理解复杂的版本语义。
- 论文提出SemVerBench基准测试，通过240个项目评估LLM对版本约束解析的理解，涵盖多个生态系统。
- 实验结果显示，Opus模型表现优异，Sonnet超越OpenAI模型，且通过注入提示可显著提高模型的解析能力。
📝 摘要（中文）
大型语言模型（LLM）编码代理在判断版本是否满足约束（如^1.2.3或>=2.0,<3）时，其对版本约束语义的理解从未被直接测量。我们提出了SemVerBench，这是第一个针对LLM版本约束解析语义的基准测试，涵盖三个生态系统（npm、PEP 440、Cargo），包含240个可机器检查的项目，具有唯一答案，基于四个平衡来源构建（每个生态系统的官方测试套件加上三个前沿LLM提议者），并由一个非循环的双实现预言机标记。对六个前沿模型的评估发现，存在系统性的、可预测的机制盲点：部分比较器的携带规则（>1.2意味着>=1.3.0）使每个模型在Cargo上陷入困境（接近60%），尽管标准的PEP 440前缀匹配是普遍适用的，但在零填充/发布后边界情况下，GPT-5.1崩溃（0/26），而Claude保持在97-100%（在67个项目的预言机验证集上验证）。Opus显著优于所有其他模型，Sonnet优于OpenAI模型（McNemar）。这些失败更像是激活/应用差距而非知识差距：注入规则或轻微的正确提示可以恢复大部分错误，而区间分解则无效，模型在相同规则的基本形式上已达到上限。作者分层分析发现没有统计显著的自我偏好。
🔬 方法详解
问题定义：本论文旨在解决大型语言模型（LLM）在版本约束解析中的理解不足，现有方法未能有效评估其对版本语义的掌握，导致在实际应用中出现错误。
核心思路：通过构建SemVerBench基准测试，系统地评估LLM在不同生态系统中的版本约束解析能力，提供可验证的测试项目以量化模型性能。
技术框架：整体架构包括三个主要生态系统（npm、PEP 440、Cargo），每个生态系统基于官方测试套件和前沿LLM提议者构建240个可机器检查的项目，并由双实现预言机进行标记。
关键创新：SemVerBench是首个专注于版本约束解析的基准测试，填补了LLM理解版本语义的研究空白，提供了系统性评估的框架。
关键设计：在实验中，采用了非循环的双实现预言机进行标记，确保测试项目的唯一性和准确性，同时通过注入规则和提示来评估模型的激活和应用能力。
🖼️ 关键图片
📊 实验亮点
实验结果显示，Opus模型在所有测试中表现最佳，而Sonnet模型在与OpenAI模型的比较中显著优越。特别是在Cargo生态系统中，模型在处理部分比较器携带规则时表现出近60%的错误率，而通过注入提示可以有效恢复大部分错误。
🎯 应用场景
该研究的潜在应用领域包括软件开发工具、版本管理系统和自动化编码助手。通过提高LLM对版本约束的理解，可以显著提升编码代理在版本解析中的准确性，减少开发过程中的错误，进而提高软件开发的效率和质量。
📄 摘要（原文）
Large language model (LLM) coding agents constantly decide whether a version satisfies a constraint such as ^1.2.3 or >=2.0,<3, yet their grasp of version-constraint semantics has never been measured directly. We introduce SemVerBench, the first benchmark of LLM version-constraint resolution semantics across three ecosystems (npm, PEP 440, Cargo): 240 machine-checkable items with unique answers, built author-neutrally from four balanced sources (each ecosystem's official test suite plus three frontier LLM proposers) and labeled by a non-circular two-implementation oracle. Evaluating six frontier models, we find systematic, predictable per-mechanism blind spots: a partial-comparator carry rule (>1.2 means >=1.3.0) traps every model on Cargo (near 60%), and although standard PEP 440 prefix matching is universal, on zero-pad/post-release corner cases GPT-5.1 collapses (0/26) while Claude stays at 97-100% (verified on a 67-item oracle-validated set). Opus significantly outperforms all other models, and Sonnet outperforms the OpenAI models (McNemar). The failures look more like an activation/application gap than a knowledge gap: injecting the rule or a light correct hint recovers most errors, whereas interval decomposition does not, and models are at ceiling on the basic forms of the same rules. An author-stratified analysis finds no statistically significant self-favoritism. Because the task is verifiable and a free, 100%-correct resolver exists, tool delegation reaches ~100%: coding agents should delegate version resolution to a resolver rather than reason about versions in-head.