Resumo Técnico: Convertido, Não Equivalente: Avaliação de Conversão de Base de Código via Equivalência Observacional

Declaração do Problema

Avanços recentes em agentes de codificação permitiram que atuassem como colaboradores em escala de base de código, capazes de navegar em projetos, editar arquivos e realizar manutenção de software em larga escala. No entanto, uma fraqueza crítica emergiu: agentes frequentemente superconfiam em suas próprias rotinas de validação local. No contexto de conversão de base de código (por exemplo, migração de PyTorch para JAX), agentes frequentemente declaram sucesso com base em verificações superficiais — como um ponto de entrada chamável, uma perda finita ou validade sintática — enquanto violam os contratos semânticos dos quais os usuários realmente dependem.

Métodos de avaliação anteriores para conversão de base de código são amplamente orientados a resultados, comparando o sucesso final da tarefa ou artefatos de estado final sob avaliadores ocultos. Essa abordagem é instável para conversão que preserva semântica, pois resultados observáveis podem ser esparsos em relação ao espaço de implementação. Duas bases de código com contratos internos drasticamente diferentes podem produzir perdas forward quase idênticas em um único lote, enquanto divergem agudamente em gradientes, estados de otimizadores ou dinâmicas de treinamento de curto horizonte. Consequentemente, comparações baseadas apenas em resultados correm o risco de recompensar acordos acidentais em sondas superficiais, enquanto falham em detectar falhas semânticas.

Metodologia: T2J-Bench

Para abordar essa lacuna de avaliação, os autores apresentam o T2J-Bench, um benchmark que reformula a conversão de base de código como transferência sob um contrato de equivalência fixo. Em vez de perguntar se uma base de código convertida meramente executa, o T2J-Bench verifica se a base de código convertida se comporta como a original sob um conjunto fixo de testes limitados derivados da fonte.

Estrutura Central

O benchmark opera através de um processo de verificação ordenado em três estágios. Uma base de código candidata deve passar em cada estágio sequencialmente para ser considerada bem-sucedida:

1. Especificação (Admissibilidade da Interface): Verifica se a base de código convertida expõe a mesma interface de treinamento que a fonte. Isso inclui verificar árvores de parâmetros, esquemas de lote, pontos de entrada públicos e a capacidade de construir um runtime sem erros.
2. Numérico (Saídas Forward e Tensores): Compara artefatos específicos computados durante testes limitados. Isso inclui saídas forward, perdas, gradientes e tensores específicos do objetivo (por exemplo, log-probabilidades de política para DPO, saídas de valor para PPO). As comparações utilizam tolerâncias estritas para erro absoluto/relativo, similaridade de cosseno e divergência KL.
3. Comportamental (Dinâmicas de Curto Horizonte): Sonda se o acordo numérico local é suficiente para preservar dinâmicas de treinamento de curto prazo sob sementes fixas. Isso envolve reproduzir algumas etapas de treinamento para garantir que atualizações de otimizador, computações de recompensa e interações com modelos de referência produzam trajetórias consistentes com a fonte.

Configuração Experimental

• Tarefa: Converter bases de código completas de treinamento em PyTorch para SFT (Ajuste Fino Supervisionado), DPO (Otimização Direta de Preferência) e PPO (Otimização de Política Proximal) em JAX.
• Conjunto de Dados: 45 pontos de dados cobrindo 15 famílias de modelos (por exemplo, variantes de LLaMA, Mistral, Qwen) com restrições de tamanho (<7B parâmetros) e configurações limitadas.
• Protocolo de Avaliação:
  • Linhas de Base Controladas: Modelos de fronteira (por exemplo, Claude Opus 4.7, Gemini 3.1 Pro, Qwen3 Coder) avaliados usando um scaffold multiagente independente de backbone implementado internamente.
  • Agentes Nativos: Sistemas completos de agentes de codificação (por exemplo, Claude Code, Codex) avaliados em suas interfaces nativas.
  • Restrições: Um "prompt de restrição mínima" ($p^\star$) é usado para fixar a interface de treinamento sem vazar detalhes internos do avaliador. O verificador permanece externo e fixo.

Principais Resultados

A avaliação de 355 tentativas cegas de conversão produz quatro achados centrais:

1. Conversão de Base de Código Está Longe de Ser Resolvida: Apesar de altas taxas de aprovação no estágio inicial de Especificação (até 91,1%), a taxa de aprovação ponta a ponta geral para os sistemas mais fortes é de apenas 26,7–28,9% em @1. O principal gargalo é preservar a equivalência numérica e as dinâmicas de treinamento, não meramente produzir código executável.
2. Orçamento de Computação é um Remédio Fraco: Aumentar o orçamento de inferência (contagem de tokens) produz retornos decrescentes. Uma dispersão de 4,7× no custo de tokens por tentativa resulta em apenas uma dispersão de 2,2× na taxa de aprovação geral. Sistemas que gastam mais tokens frequentemente se envolvem em investigação repetida ou autoverificação verbosa sem melhorar a qualidade final da conversão.
3. Superconfiança Sistemática: Cada sistema avaliado superestima significativamente seu próprio sucesso. A lacuna entre as taxas de aprovação relatadas pelos próprios agentes (frequentemente >90%) e as taxas de aprovação medidas pelo avaliador (0–29%) varia de 66,6 a 97,8 pontos percentuais. Os agentes tendem a verificar que artefatos existem e estão bem formados (por exemplo, "a perda é um escalar finito"), mas falham em verificar se esses artefatos correspondem aos semânticos da fonte.
4. Modos de Falha são Desalinhados ao Contrato: As falhas mais difíceis decorrem de autovalidação desalinhada ao contrato e não de força limitada do backbone. Padrões comuns de falha incluem:
   • Erros de Costura: Confusão de tipos na fronteira JAX/PyTorch (por exemplo, passar numpy.ndarray para uma camada de incorporação PyTorch).
   • Substituição Semântica: Retornar a perda do método DPO no slot forward_loss, satisfazendo testes de fumaça locais, mas violando o contrato específico exigido pelo avaliador.
   • Divergência de Gradiente/Estado: Correspondência de passes forward, mas falha em preservar normas de gradiente ou atualizações de estado do otimizador.

Significado e Afirmativas

O artigo afirma que o T2J-Bench proporciona uma mudança necessária de avaliação orientada a resultados para avaliação orientada a contratos. Ao decompor a verificação em estágios de Especificação, Numérico e Comportamental, o benchmark contorna a indecidibilidade da equivalência absoluta de base de código, mantendo-se discriminativo entre diferentes modelos e sistemas de agentes.

Os autores argumentam que, no regime atual de conversão de base de código:

• A escalabilidade do backbone sozinha é insuficiente: A lacuna entre os melhores e piores modelos é pequena em comparação com a lacuna entre autovalidação e verificação externa.
• A autovalidação é o principal gargalo: Os agentes falham não porque não conseguem calcular os valores corretos, mas porque seus loops internos de validação tratam "artefatos bem formados" como equivalentes a "artefatos semanticamente corretos".
• Melhorias futuras exigem alinhamento externo: Fechar a lacuna exige que os agentes internalizem um loop de comparação com a fonte, em vez de depender de testes de fumaça autoconsistentes. O benchmark serve como um scaffold diagnóstico para identificar esses desalinhamentos.

O artigo conclui que, embora o T2J-Bench seja instanciado na conversão de PyTorch para JAX, seu quadro de contratos de equivalência fixos e verificação em etapas oferece uma abordagem generalizável para avaliar transformações de base de código que preservam semântica.