大语言模型可以解决真正的Java合并冲突吗？使用经过校准的 LLM 作为法官进行评估

合并冲突是协作软件开发的经常性成本，而解决这些问题的传统结构化和半结构化合并工具经常放弃：当它们的启发式方法不适用时，它们就会让冲突得不到解决。 大语言模型 (LLM) 可以为几乎所有冲突生成候选解决方案，但衡量这些解决方案是否实际上在规模上良好是很困难的，因为获得每个模型输出的人类合意性判断并不能扩展。我们通过 ConflictBench 的真实 Java 合并冲突来一起研究这两个问题。我们首先构建一个 LLM 求解器作为生成验证重试代理，它仅使用推理时间信号（冲突标记、Java 解析器和重复声明检查），并且永远不会看到开发人员的答案。然后，我们使用两个度量套件评估其分辨率：(1) 作为 G-Eval 度量实现的开发人员匹配 LLM-as-judge，最重要的是，在使用前根据 ConflictBench 的人类标签进行校准，以及 (2) 不使用 LLM 的确定性结构有效性检查。在对 292 个人工标记案例的元评估中，法官在 64.6% 的召回率下达到 100% 的精确度（零错误接受），因此每次接受都是值得信赖的，并且每个下游速率都是保守的下限。根据这一经过验证的判断，LLM 求解器在大约 55% 的真实冲突（保守下限）上与开发人员自己的解决方案相匹配，并且在覆盖公平比较下，LLM (55-59%) 击败了最强的传统工具（AutoMerge，36.7%）大约 18-22 个百分点；优势几乎完全来自覆盖范围，而不是原始准确性，因为这些工具放弃了 20-90% 的冲突，而强制解决方案下的 LLM 则没有放弃任何冲突。最后，LLM 法官接受了未通过确定性结构检查的 5 项决议中的 4 项，这证明结构正确性不得委托给 LLM。