Measuring LLM Trust Allocation Across Conflicting Software Artifacts

1. O Problema

Os assistentes de engenharia de software baseados em Grandes Modelos de Linguagem (LLMs) falham não apenas ao gerar saídas incorretas, mas principalmente ao alocar confiança errada quando diferentes artefatos de software (código-fonte, documentação, assinaturas de métodos e testes) estão em desacordo.

• Limitação das Avaliações Atuais: A maioria das avaliações foca apenas nos resultados finais (downstream outcomes), como a correção de um teste gerado. Isso oculta o processo de raciocínio: o modelo reconheceu que a evidência estava degradada? Identificou a fonte não confiável? Calibrou sua confiança corretamente entre os artefatos?
• O Risco: Um LLM pode produzir uma saída que parece razoável, mas que se baseia silenciosamente na fonte errada (ex: confiar em uma documentação desatualizada em vez do código real), tornando essas falhas difíceis de detectar apenas olhando para o resultado final.

2. Metodologia: Framework TRACE

Os autores propõem o TRACE (Trust Reasoning over Artifacts for Calibrated Evaluation), um framework que trata o raciocínio sobre a confiança em artefatos como uma saída de primeira classe, em vez de inferi-lo indiretamente.

A. Construção do Benchmark

• Dados: Baseado em 456 bundles de métodos Java curados, extraídos de 25 sistemas reais (OE25).
• Artefatos Analisados: Cada amostra contém quatro artefatos:
  1. MUT (Method Under Test - implementação).
  2. Assinatura do método.
  3. Javadoc (documentação).
  4. Prefixo do teste (contexto de execução).
• Perturbações Cegas (Blind Perturbations): Foram criadas 6 variantes de perturbação para cada amostra base (totalizando 7 versões, incluindo a limpa):
  • Remoção de partes do Javadoc.
  • Injeção de bugs na documentação (comportamento errado, parâmetros faltando).
  • Injeção de bugs na implementação (lógica, null-checks, limites).
  • Conflitos diretos entre Javadoc e MUT.
  • Níveis de Severidade: Pesado (H), Normal (N) e Sutil (S).
• Protocolo Cego: O modelo não sabe qual artefato foi alterado ou a severidade da alteração; deve inferir tudo apenas analisando os artefatos.

B. Coleta de Rastros (Traces)

O framework solicita aos LLMs que gerem um rastro estruturado contendo:

1. Avaliação de Qualidade por Artefato: Uma pontuação de 0 a 1 para cada artefato individualmente.
2. Análise de Inconsistência: Detecção de conflitos entre pares de artefatos e identificação de qual artefato é o "culpado".
3. Priorização de Fontes: Uma ordenação total dos artefatos baseada na confiabilidade percebida.
4. Confiança: Uma pontuação de confiança geral.

C. Modelos Avaliados

Foram testados 7 modelos de ponta (via Microsoft Foundry/Azure) com temperatura 0.0:

• Claude (Opus 4.6, Sonnet 4.6, Haiku 4.5)
• OpenAI (GPT-5.2 Chat, GPT-4o)
• DeepSeek (V3.2-Speciale)
• xAI (Grok 4 Fast Reasoning)
• Total de Dados: 22.339 rastros válidos gerados.

3. Principais Contribuições

1. Formalização do Raciocínio de Confiança: Define o "raciocínio de confiança em nível de artefato" como um objetivo de avaliação explícito, focando na alocação de confiabilidade entre entradas heterogêneas.
2. Benchmark de Perturbação com Proveniência: Um conjunto de dados anotado com metadados de ground-truth sobre o tipo de bug, severidade e origem da mutação, permitindo avaliar não apenas se o modelo detectou o erro, mas onde ele atribuiu a culpa.
3. Estudo em Grande Escala: Uma análise cruzada de 7 modelos revelando assimetrias sistemáticas na capacidade de detectar falhas em código vs. documentação.

4. Resultados Chave

RQ1: Sensibilidade à Qualidade de Entrada

• Localização de Penalidades: As penalidades de pontuação são altamente localizadas no artefato perturbado, com pouco "vazamento" para outros artefatos.
• Assimetria Documentação vs. Código: Os modelos são muito mais sensíveis a falhas na documentação do que no código.
  • A diferença de pontuação entre erros "pesados" e "sutis" na documentação é de 0.152 a 0.253.
  • Para erros na implementação (MUT), essa diferença é muito menor (0.049 a 0.123).
• Conclusão: Os modelos são melhores auditores de especificações em linguagem natural do que detectores de falhas sutis de código.

RQ2: Detecção de Inconsistência Javadoc-MUT

• Detecção de Erros Explícitos: Os modelos detectam bem erros explícitos na documentação (67–94%) e contradições diretas (50–91%).
• O "Ponto Cego" da Implementação (MUT_Only Blind Spot): Quando apenas o código (MUT) muda e a documentação permanece plausível/correta, a taxa de detecção cai drasticamente (21 a 42 pontos percentuais abaixo do cenário onde ambos mudam).
• Calibração de Confiança: A confiança declarada pelos modelos é mal calibrada em 6 dos 7 modelos. Um modelo pode ter alta confiança em uma detecção incorreta.
• Priorização: Modelos como Sonnet e Opus conseguem priorizar melhor artefatos com falhas de documentação, mas nenhum modelo consegue discriminar consistentemente implementações defeituosas.

RQ3: Compreensão Semântica de Código

• Fator Explicativo: A variação na fidelidade dos rastros entre modelos é explicada principalmente pela compreensão semântica do código.
• Modelos Robustos: Sonnet, DeepSeek-V3.2 e Haiku mantêm a detecção estável mesmo quando as pistas superficiais desaparecem (erros sutis).
• Modelos Frágeis: GPT-4o sofre um colapso acentuado (queda de 44 pp) em cenários sutis, indicando dependência de pistas lexicais superficiais.
• Caso Especial (Opus): O Opus entende a contradição semanticamente, mas frequentemente falha em localizar qual artefato é o culpado (atribuição errada).

5. Significado e Implicações Práticas

• Auditoria de Documentação vs. Detecção de Drift de Código: Os LLMs atuais são ferramentas confiáveis para auditar se a documentação está desatualizada em relação a um código confiável. No entanto, não são confiáveis para detectar quando o código mudou e a documentação permaneceu correta (o cenário mais comum em repositórios reais).
• Não Confiar na Confiança do Modelo: A pontuação de "confiança" interna do LLM não deve ser usada como gatilho automático para decisões críticas, pois a maioria dos modelos não está bem calibrada.
• Seleção de Modelos para Engenharia de Software:
  • Para detecção bruta de contradições: Sonnet é a escolha mais forte.
  • Para cenários sutis de código: Sonnet, DeepSeek-V3.2 e Haiku.
  • Para explicação de falhas (após a detecção): Opus (embora tenha dificuldade em localizar a falha).
• Fluxo de Trabalho Recomendado: O TRACE sugere que os LLMs devem ser usados como uma etapa de triagem (preflight) para avaliar a qualidade dos artefatos antes de tarefas críticas. A documentação de alta qualidade deve ser enfatizada, mas nunca considerada a única fonte da verdade sem verificações cruzadas de consistência com o código.

Em resumo, o trabalho demonstra que os LLMs atuais possuem uma "visão" assimétrica: enxergam claramente falhas na documentação, mas têm um "ponto cego" significativo para falhas sutis na implementação, e seu raciocínio de confiança precisa ser explicitamente gerenciado e não apenas inferido.