Resumo Técnico: Tricky2 – Rumo a um Benchmark para Avaliar Interações de Erros entre Humanos e LLMs

Declaração do Problema

Embora os Grandes Modelos de Linguagem (LLMs) estejam sendo cada vez mais integrados aos fluxos de trabalho de desenvolvimento de software (ex: GitHub Copilot), os benchmarks existentes para testes e depuração de software avaliam erros gerados por humanos e por IA de forma isolada. Conjuntos de dados atuais, como TrickyBugs (defeitos humanos) ou buggy-HumanEval (defeitos de LLM), falham em capturar a realidade do desenvolvimento moderno, onde códigos escritos por humanos e gerados por LLMs coexistem nos mesmos arquivos e funções.

O artigo identifica uma lacuna crítica: os benchmarks existentes não conseguem avaliar interações de erros. Em contextos híbridos, correções humanas podem mascarar falhas de LLM, reparos de LLM podem reintroduzir defeitos humanos, e métricas de avaliação padrão podem falhar quando múltiplas fontes de erro se combinam ou se obscurecem mutuamente. Consequentemente, a comunidade de engenharia de software carece da capacidade de avaliar rigorosamente ferramentas de reparo em ambientes mistos de origem realística ou de estudar a confiabilidade da depuração na colaboração híbrida humano–IA.

Metodologia

Para abordar isso, os autores introduzem o Tricky2, um conjunto de dados híbrido que estende o corpus existente TrickyBugs. O pipeline de construção envolve as seguintes etapas:

1. Dataset Base: A fundação é o TrickyBugs, contendo 3.043 programas com bugs escritos por humanos e 1.361 programas corrigidos em C++, Python e Java, derivados de submissões de programação competitiva.
2. Injeção Controlada de Bugs: Os autores empregam dois LLMs, GPT-5 e OpenAI-oss-20b, para injetar erros adicionais nos programas existentes.
   • Framework de Prompting: Um prompt estruturado e guiado por taxonomia instrui os modelos a injetar exatamente um novo bug de uma taxonomia predefinida (Entrada/Saída, Variável/Dados, Lógica/Condição, Loop/Iteração, Função/Procedimento) enquanto preservam estritamente todos os defeitos humanos originais e a estrutura do programa.
   • Restrições: Os modelos são instruídos a evitar mudanças em comentários ou formatação e a fornecer o arquivo modificado com o nível da taxonomia e as posições dos caracteres do código injetado.
3. Divisões do Dataset: O processo gera três divisões distintas:
   • Apenas Humano (Human-only): Os programas originais com bugs.
   • Apenas LLM (LLM-only): Programas corrigidos com erros injetados por LLM (sem bugs humanos).
   • Humano+LLM (Human+LLM): Programas com bugs contendo tanto os defeitos humanos originais quanto os novos erros injetados por LLM.
4. Validação: Um pipeline automatizado valida a sintaxe e a compilação usando ferramentas específicas de linguagem (g++, py_compile, javac). O corpus final contém 11.851 programas com bugs, sendo que todas as divisões compartilham os mesmos casos de teste e referências corrigidas.

Principais Contribuições

• Benchmark Tricky2: O primeiro benchmark controlado que modela explicitamente a coocorrência de erros humanos e de LLM dentro de contextos de programas compartilhados.
• Injeção Guiada por Taxonomia: Um pipeline reproduzível usando uma taxonomia de erro específica para gerar bugs de origem de máquina que interagem com defeitos humanos sem alterar a estrutura original do código.
• Três Tarefas de Avaliação: O artigo define três tarefas complementares para medir a confiabilidade em ambientes híbridos:
  1. Classificação de Origem: Distinguir entre defeitos humanos, de LLM e mistos.
  2. Identificação de Erro: Localizar os intervalos (spans) do bug e identificar o nível da taxonomia.
  3. Reparo de Programa: Avaliar o sucesso de patches mínimos contra os casos de teste fornecidos.
• Avaliações de Baseline: Avaliações de prova de conceito em pequena escala em um subconjunto estratificado de 135 problemas difíceis (45 por divisão) em C++, Java e Python.

Resultados

As avaliações de baseline, embora limitadas em escopo, revelam padrões distintos em relação aos erros de origem mista:

• Dificuldade de Reparo: Tanto as divisões "apenas humano" quanto as "apenas LLM" demonstraram taxas de sucesso de reparo mais altas em comparação com a divisão Human+LLM.
• Efeitos de Interação: Os resultados sugerem que defeitos de origem mista introduzem efeitos de interação que complicam o raciocínio e o reparo. Notavelmente, na divisão C++ de Human+LLM, o modelo falhou em produzir um único programa corrigido, apesar de ter corrigido com sucesso subconjuntos substanciais dos casos de origem única.
• Classificação e Localização: O artigo reporta matrizes de confusão e mapas de calor para classificação de origem e identificação de taxonomia, embora porcentagens de precisão específicas não sejam o foco principal do resumo; o foco está na divergência nos resultados de reparo.

Significância e Alegações

O artigo posiciona o Tricky2 como um passo inicial, mas necessário, para avaliar a confiabilidade do software em ambientes de desenvolvimento híbrido humano–IA. Os autores alegam que:

• Efeitos de Interação são Reais: Defeitos de origem mista não são meramente a soma de suas partes; eles criam efeitos de composição ou mascaramento que os benchmarks de fonte única atuais não conseguem detectar.
• Ferramentas Atuais Têm Dificuldades: LLMs existentes parecem ter dificuldades significativas com a complexidade de depurar código onde erros humanos e de IA interagem, destacando uma lacuna nas capacidades atuais de reparo.
• Fundação para Trabalhos Futuros: O Tricky2 serve como base para estudar robustez, colaboração consciente de erros e o design de fluxos de trabalho de codificação humano–IA mais seguros. Os autores vislumbram extensões futuras envolvendo protocolos de depuração agênticos, estudos longitudinais de confiabilidade de modelos e expansão para outros idiomas e famílias de modelos.

O artigo reconhece explicitamente as limitações, incluindo a dependência de versões específicas de LLMs (que podem sofrer deriva ao longo do tempo), a restrição do domínio subjacente do TrickyBugs (programação competitiva vs. sistemas industriais) e a falta de cobertura para erros semânticos complexos como concorrência ou gerenciamento de memória. No entanto, afirma que o conjunto de dados fornece uma base controlada para investigar interações de erros que eram anteriormente imensuráveis.