A6--俞凯--设计约束视角下的 Issue 修复智能体评估方法.pdf

1、设计约束视角下的设计约束视角下的 Issue Issue 修复智能体评估方法修复智能体评估方法 俞凯复旦大学 Codewisdom团队技术专家 0102030405 为什么需要设计约束视角下的评估方法从评审讨论中沉淀设计约束设计感知评测基准构建当前智能体的真实表现总结与展望为什么需要设计约束为什么需要设计约束视角下的评估视角下的评估方法方法为什么需要设计约束视角下的评估方法为什么需要设计约束视角下的评估方法SWE-Bench数据集里，Agent生成的Patch成功通过了所有功能但是，但是引入了系统可靠性隐患为什么需要设计约束视角下的评估方法为什么需要设计约束视角下的评估方法动机示例：在 Dja

2、ngo 的一个真实 Issue 中，使用 distinct()的补丁通过了所有测试。但因违背了系统级的数据类型处理约束，引发了更长期的系统隐患。最终被 Exists()方案取代。结论：只看测试通过率,会高估智能体的真实可用性。所以我们需要进行设计约束视角下的 Issue 修复智能体评估 为什么需要设计约束视角下的评估方法为什么需要设计约束视角下的评估方法ISO 将描述为一种需求类型：通过施加不可移动的边界与限制来约束设计者可选方案。设计约束本质上是对可接受设计/实现方案的边界限定，而非仅表达偏好或建议，因此天然具有更强的可判定性，便于在工程活动中用于检查一致性。设计约束的隐式、混杂和散布设计约

3、束的隐式、混杂和散布:即使设计知识出现在 PR等开发组件中，它也很少以清晰、结构化的形式存在。多个设计考虑可能缠绕在同一条评论中，同一个设计 concern 也可能分散在不同评论或 PR 中。设计约束不可执行，难以验证：设计约束不可执行，难以验证：不同于单元测试可以直接运行，设计约束即使被结构化表达，也仍然需要结合 patch 语义和上下文判断是否满足。评估方法的两大难点：评估方法的两大难点：总结总结:设计约束难获取、难验证，需要设计一个自动提取和评估设计约束的方法。设计约束是什么：设计约束是什么：整体框架整体框架设计约束的抽取解决难获取。核心思路就六个字先解构、再重构。设计感知的评测解决难验

4、证。约束与真实 Issue 关联配对，并自动评估补丁的设计一致性。评估代码库原子化设计建议提取层次化设计约束聚合.设计约束 已关联设计约束从评审讨论中沉淀设从评审讨论中沉淀设计约束计约束原子化建议单元提取原子化建议单元提取1.滑动窗口抽取：避免中间信息迷失（lost-in-the-middle），逐段抽取结构化的问题-建议单元。2.代码 Diff 采纳验证：对齐代码变更前后差异，验证建议是否真正采纳，并提取的适用边界条件。原子化建议单元提取原子化建议单元提取3.多维相似度预聚类：融合“语义相似度”与“结构依赖”，将散落的原子建议初步聚集成簇。4.大模型归并判定：根据预聚类结果，大模型判断集群间

5、是否应归并。设计感知评测基准设计感知评测基准构构建建设计感知评测基准构建设计感知评测基准构建可靠性可靠性：与人工判定一致性 Cohens =0.79、三分类准确率 80.8%实证研究实验设置实证研究实验设置双维度评估协议：功能正确性：测试通过率设计一致性：DSR(设计满足率):适用的设计约束均被完全遵循。DVR(设计冲突率):补丁违背了至少一条设计约束。DNR(设计中性率):补丁采用的实现路径未触发相关约束的适用条件。基于主流的 SWE-Bench/SWE-Bench-Pro扩展，涵盖 495 个真实 Issue 和 1,787 条人工验证的高质量约束核心研究问题：RQ1：智能体在真实修复任务

6、中的设计约束遵循程度如何？RQ2：功能正确性与设计满足度之间是否存在统计关联？RQ3：显式补充设计约束能否有效降低冲突率？当前智能体的真实表现当前智能体的真实表现设计感知修复的现状评估设计感知修复的现状评估顶尖智能体的测试通过率已经到 70%以上。但设计满足率最高的也才50.20%。结论：结论：冲突现象具有普遍性，设计一致性仍是一个尚未得到充分解决的问题。设计约束的违背,不是某一个模型的偶发失误,而是当前大模型共同的短板。设计一致性是独立的设计一致性是独立的评估维度评估维度C