Measuring LLM Trust Allocation Across Conflicting Software Artifacts

这篇论文提出了一种名为 TRACE (Trust Reasoning over Artifacts for Calibrated Evaluation) 的框架，旨在评估大型语言模型（LLM）在软件工程（SE）任务中，面对相互冲突的软件工件（如代码、文档、测试等）时，如何分配信任（Trust Allocation）。

以下是该论文的详细技术总结：

1. 研究背景与问题 (Problem)

• 核心痛点：现有的 LLM 辅助软件工程工具（如测试生成、代码审查）不仅会生成错误输出，更严重的问题在于错误地分配信任。当源代码、文档（Javadoc）和测试用例之间存在不一致时，LLM 可能会盲目信任错误的来源，同时生成看似合理的输出，导致这种“静默失败”难以被检测。
• 现有局限：以往的研究主要关注下游任务的结果（例如生成的断言是否正确），而忽略了模型在推理过程中是否识别了证据的退化、是否识别了不可靠的来源，以及是否在不同工件间进行了合理的信任校准。
• 研究目标：揭示 LLM 在输入质量评估、不一致性检测、故障归因和来源优先级排序方面的能力，特别是当文档与代码发生冲突时。

2. 方法论 (Methodology)

作者提出了 TRACE 框架，通过盲测（Blind Perturbation）机制，强制模型输出结构化的“信任推理轨迹”（Trust Traces）。

2.1 数据构建 (Benchmark Construction)

• 基础数据集：基于 25 个真实世界的 Java 系统，筛选出 456 个 高质量的 Java 方法包（Method Bundles）。每个样本包含四个核心工件：
  1. 被测方法（MUT, Method Under Test）
  2. 方法签名（Signature）
  3. Javadoc 文档
  4. 测试前缀（Test Prefix）
• 扰动变体：对每个基础样本构建了 6 种 扰动变体，加上原始干净样本共 7 种版本。扰动类型包括：
  • 移除类：删除 Javadoc 描述、@return 标签或两者。
  • 注入类：在 Javadoc 或 MUT 中注入语义错误（Bug），分为三个严重程度（严重 Heavy、正常 Normal、微妙 Subtle）。
  • 冲突类：人为制造 Javadoc 与 MUT 之间的逻辑矛盾。
• 规模：共涉及 7 个不同的 LLM 模型，总计生成 22,339 条 有效推理轨迹。

2.2 评估模型 (Models Evaluated)

评估了来自不同提供商的 7 个模型：

• Anthropic: Claude Opus 4.6, Sonnet 4.6, Haiku 4.5
• OpenAI: GPT-5.2 Chat, GPT-4o
• DeepSeek: DeepSeek-V3.2-Speciale
• xAI: Grok 4 Fast Reasoning

2.3 TRACE 流程

1. 提示设计：使用统一的系统提示，强制模型不预设任何工件为真理（Artifact Symmetry），要求模型对每个工件进行独立的质量评分、冲突分析，并输出优先级排序。
2. 盲测协议：模型仅看到四个工件，不知道样本是否被扰动、哪个被扰动或严重程度。
3. 输出结构：模型输出包含：
   • 各工件的质量评分（0-1）。
   • 成对冲突分析（Pairwise Conflict Analysis）。
   • 识别出的冲突及归因（Attribution）。
   • 来源优先级排序（Source Prioritization）。
   • 置信度分数。

3. 主要研究问题与发现 (Key Findings)

RQ1: 输入质量敏感性 (Input-quality Sensitivity)

• 发现：所有模型都能根据扰动严重程度调整评分（严重 > 正常 > 微妙），表现出分级敏感性而非简单的二元故障检测。
• 不对称性：模型对文档（Javadoc）的退化极其敏感，评分下降幅度大；而对代码（MUT）的退化敏感度较低。
  • 文档 Bug 的“严重 - 微妙”评分差距为 0.152–0.253。
  • 代码 Bug 的“严重 - 微妙”评分差距仅为 0.049–0.123。
• 结论：LLM 更擅长审计自然语言规范，而非检测细微的代码级故障。

RQ2: Javadoc-MUT 不一致性检测 (Inconsistency Detection)

• 文档错误检测：模型能很好地检测显式的文档错误（检测率 67–94%）和文档与代码的明显矛盾（50–91%）。
• 代码漂移盲点 (The Blind Spot)：当仅代码（MUT）发生漂移而文档保持合理时，所有模型的检测率均大幅下降（下降 7–42 个百分点）。
  • 这表明模型倾向于依赖文档作为主要信号，当文档“看起来没问题”时，即使代码错了，模型也往往不会报警。
• 置信度校准：除 DeepSeek-V3.2 外，其余 6 个模型的置信度校准极差，不能直接用作自动决策的门槛。

RQ3: 语义代码理解与轨迹保真度 (Semantic Code Understanding)

• 模型差异：不同模型在应对“微妙”扰动时的表现差异巨大，这主要归因于语义代码理解能力的深浅。
  • 表现稳健：Claude Sonnet, DeepSeek-V3.2, Haiku。它们在表面线索消失时仍能保持较高的检测率和描述准确性。
  • 表现崩溃：GPT-4o。随着扰动变得微妙（表面线索减少），其检测率从 76% 暴跌至 32%，表明其依赖表面模式匹配而非深层语义推理。
  • 定位错误：Opus 虽然能理解语义矛盾，但经常错误地将故障归因于文档而非代码。

4. 主要贡献 (Contributions)

1. 形式化定义：首次将“基于工件的信任推理”形式化为软件工程中的首要预测目标，并提出了 TRACE 框架。
2. 基准构建：构建了一个包含 456 个精心策划的 Java 方法包及其 6 种扰动变体的基准数据集，提供了关于 Bug 类型、严重程度和扰动来源的 Ground Truth 元数据。
3. 大规模实证研究：揭示了 LLM 在跨工件信任分配上的系统性偏差（重文档、轻代码），并证明了模型间的差异主要由语义代码理解能力决定。

5. 意义与启示 (Significance & Implications)

• 重新定义 LLM 在 SE 中的角色：目前的 LLM 更适合作为文档审计员（检测文档过时或错误），而不是代码漂移检测器。在代码更新快于文档更新的现实场景中，LLM 容易漏报代码错误。
• 部署建议：
  • 在 CI/CD 或代码审查中，不应盲目信任 LLM 生成的代码断言，特别是在文档看起来完美但代码可能已变更的情况下。
  • 模型选择：对于需要检测微妙代码冲突的任务，应优先选择 Sonnet, DeepSeek-V3.2, 或 Haiku；对于需要解释矛盾的任务，Opus 表现较好但需配合检测器使用。
  • 置信度不可靠：不能依赖模型的置信度分数来过滤错误，必须进行模型特定的重新校准。
• 未来方向：TRACE 为构建“感知工件质量”的 SE 助手奠定了基础，提示在做出关键决策前，应先显式地评估输入工件的可信度。

总结

该论文通过 TRACE 框架揭示了当前 LLM 在软件工程任务中的一个关键弱点：对文档的过度信任和对代码细微错误的“视而不见”。研究强调，在利用 LLM 进行代码生成或测试时，必须引入显式的工件级信任推理机制，并谨慎选择模型，以避免因错误信任来源而导致的系统性失败。