测量冲突软件工件之间的 LLM 信任分配

基于 LLM 的软件工程助理经常对多个工件进行推理，包括代码、文档、签名和测试，即使这些工件不完整或相互不一致。现有的评估主要衡量最终输出，不清楚模型是否识别了不可靠的证据、识别了错误的来源或优先考虑了适当的工件。我们引入 TRACE，这是一种用于评估 LLM 如何评估冲突软件工件并确定其优先级的受控方法。 TRACE 通过将已知的错误注入到文档、实现或两者中，同时保持其余工件的固定，来构造现实世界 Java 方法包的配对干净版本和扰动版本。然后，模型评估工件质量，检测并定位不一致之处，并按可靠性对可用来源进行排名。使用 7 个 LLM 对 456 个方法包的 22,339 个有效响应，我们发现质量惩罚通常局限于受干扰的工件，并随着故障严重性而增加。然而，模型表现出一致的源头不对称性：它们检测文档错误的比例为 67-94%，明确的文档与实现矛盾的比例为 50-91%，但当仅实现更改而文档保持不变时，检测率会下降 21-43 个百分点。模型还很难排除错误实现的优先级，并且对于七个模型中的六个模型，置信度几乎无法区分正确和错误的判断。这些结果表明，当前的 LLM 不是软件证据的对称集成器：它们比微妙的实现行为更可靠地审核自然语言规范。 TRACE 提供了一种受控方法，用于在 LLM 用于正确性关键的软件工程工作流程之前暴露此故障模式。