Hallucination Inspector: A Fact-Checking Judge for API Migration

1. O Problema: Alucinação de Andaimagem (Scaffolding Hallucination)

O artigo aborda um problema crítico na engenharia de software automatizada: o uso de Grandes Modelos de Linguagem (LLMs) para migração de APIs. Embora os LLMs sejam eficazes em identificar qual API substituir a antiga (API de origem para a de destino), eles frequentemente falham na geração do "código de cola" (glue code) necessário para invocar corretamente a nova API.

Os autores definem esse fenômeno como Alucinação de Andaimagem (Scaffolding Hallucination). Ocorre quando o modelo gera um contexto de chamada incorreto, inventando Símbolos Fantasma (Phantom Symbols) que não existem na especificação real da API. Esses símbolos incluem:

• Importações imaginárias.
• Construtores inexistentes.
• Constantes ou métodos falsos.

O problema central é que as métricas padrão de avaliação (como CodeBLEU) e os "juízes" baseados em LLMs falham em detectar esses erros. O código gerado com alucinações frequentemente possui alta similaridade textual com a solução correta, mas falha na compilação ou execução devido a esses detalhes estruturais específicos.

2. Metodologia: O Hallucination Inspector

Para resolver isso, os autores propõem o Hallucination Inspector, uma ferramenta de análise estática e verificação de fatos baseada em conhecimento, projetada para ser determinística e livre de viés probabilístico.

Arquitetura e Funcionamento

A ferramenta opera em três módulos principais:

1. Parser (Analisador Sintático): Converte o código gerado pelo LLM em uma Árvore de Sintaxe Abstrata (AST) usando a biblioteca Tree-sitter.
2. Extrator de Símbolos: Isola unidades testáveis, como chamadas de métodos, constantes e cadeias de métodos (method chains).
3. Oráculo de API (Base de Conhecimento): Uma tabela de símbolos construída diretamente a partir da documentação oficial da API (no caso do estudo, o SDK do Android em XML). Diferente de usar outro LLM para checar, este oráculo é uma fonte de verdade estática e rigorosa.

Taxonomia de Alucinações

O sistema classifica e detecta dois tipos de alucinações:

• Nível 1: Alucinações Atômicas (Atomic Hallucinations): Invenção de símbolos atômicos que não existem no namespace da API (ex: uma constante CONTENT_TYPE_STREAM que não existe). O sistema verifica a existência direta no oráculo.
• Nível 2: Alucinações Limitadas por Escopo (Scope-bound Hallucinations): Invenção de membros (métodos) para um objeto específico. O sistema realiza a propagação de tipos para resolver o tipo do objeto na cadeia de chamadas e verifica se o método invocado é válido para aquele tipo específico (ex: chamar um método de AudioManager em um objeto do tipo AudioAttributes.Builder).

O algoritmo utiliza uma verificação em duas fases: busca direta para símbolos atômicos e resolução de cadeia de chamadas para membros dependentes.

3. Contribuições Principais

• Definição Formal: Introdução do conceito de "Scaffolding Hallucination" e sua taxonomia (Atômica e Limitada por Escopo).
• Ferramenta de Detecção: Desenvolvimento do Hallucination Inspector, uma ferramenta de análise estática que atua como um juiz de fatos baseado em documentação, eliminando o viés de otimismo ou supercorreção comum em LLMs.
• Validação Empírica: Demonstração de que métricas de similaridade (CodeBLEU) são inadequadas para migração de APIs e que o Hallucination Inspector supera os juízes baseados em LLMs em precisão.

4. Resultados da Avaliação

Os autores avaliaram a ferramenta em um conjunto de dados de 51 migrações de API do Android, utilizando dois modelos de ponta (Qwen-2.5 e Codestral-v1).

• Falha das Métricas Padrão (RQ1): O estudo mostrou que o CodeBLEU é cego a essas alucinações. Código com alucinações graves (que não compilam) obteve pontuações de similaridade médias e medianas quase idênticas às do código correto (ex: mediana de 0,844 para código com alucinação vs. 0,827 para código sem). Isso torna impossível filtrar erros apenas com base na similaridade textual.
• Desempenho do Juiz vs. Inspector (RQ2):
  • Hallucination Inspector: Alcançou Precisão de 1.00 (100%) para ambos os modelos geradores, eliminando completamente os falsos positivos. A taxa de Recall foi de 0,73 (Qwen) e 0,90 (Codestral).
  • LLM-as-a-Judge (GPT-5-mini): Apresentou desempenho inferior, com baixa precisão (0,67 e 0,50) e recall. O juiz baseado em LLM cometeu viés de supercorreção, rejeitando migrações válidas como se fossem alucinações, e também falhou em detectar alucinações reais, assumindo que estruturas superficialmente plausíveis eram corretas.

5. Significado e Impacto

O trabalho é significativo porque:

1. Muda o Paradigma de Avaliação: Demonstra que para tarefas de engenharia de software que exigem conformidade estrita com especificações (como migração de API), métricas estatísticas e juízos probabilísticos de LLMs são insuficientes.
2. Solução Determinística: Oferece uma abordagem baseada em oráculos de documentação que garante a veracidade factual do código gerado, algo crucial para pipelines de CI/CD automatizados.
3. Aplicabilidade Prática: A ferramenta pode atuar como um "porteiro" (gatekeeper) em loops de reparo iterativo, sinalizando erros específicos para o LLM corrigir antes da entrega final, ou servir como sinal de recompensa para treinar modelos via Aprendizado por Reforço (RL).

Em suma, o Hallucination Inspector preenche uma lacuna crítica na confiabilidade da IA generativa para engenharia de software, garantindo que o código gerado não apenas pareça correto, mas seja factualmente válido em relação às especificações da API.