TICoder: A Repository-Level Code Generation Framework with Test-Driven Planning and Implementation-Aware Reuse

Resumo Técnico: TICoder

Declaração do Problema

A geração de código em nível de repositório utilizando Grandes Modelos de Linguagem (LLMs) enfrenta desafios significativos devido às complexas dependências de código e às janelas de contexto limitadas. Embora as abordagens existentes utilizem Geração Aumentada de Recuperação (RAG) e mecanismos de planejamento para reutilizar funções de um repositório, os autores identificam duas limitações críticas nos métodos atuais de estado da arte (SOTA):

1. Falta de Orientação Comportamental Baseada em Testes no Planejamento: Os métodos de planejamento existentes derivam etapas de implementação diretamente de requisitos de linguagem natural (NL). No entanto, os requisitos de NL são frequentemente vagos ou incompletos, levando a planos não confiáveis. Os métodos atuais de geração baseados em testes aplicam casos de teste primariamente durante as fases de geração de código ou pós-geração, deixando seu potencial para guiar o processo de planejamento inexplorado.
2. Falta de Consciência da Implementação ao Nível de Código na Reutilização: As estratégias de recuperação existentes dependem fortemente da similaridade semântica entre as etapas de implementação e as descrições das funções. Elas frequentemente negligenciam a lógica de implementação real contida no código. Além disso, as funções recuperadas são frequentemente inseridas em prompts sem a compreensão de como elas são realmente utilizadas (padrões de uso) dentro do repositório, levando a uma reutilização ineficaz.

Metodologia: Estrutura TICoder

Os autores propõem o TICoder, uma estrutura projetada para melhorar tanto as fases de planejamento quanto as de reutilização da geração de código em nível de repositório. A estrutura consiste em três estágios principais:

1. Planejamento Iterativo Baseado em Testes

Em vez de gerar planos apenas a partir de requisitos de NL, o TICoder utiliza casos de teste como especificações comportamentais para refinar as etapas de implementação. Este estágio emprega um mecanismo de "juiz-e-reflexão" envolvendo dois papéis de LLM:

• LLM-como-Planejador (LLM-as-a-Planner): Gera uma sequência inicial de etapas de implementação baseada no requisito e nos casos de teste, guiada por princípios como clareza, consciência de condições de contorno e dependências explícitas.
• LLM-como-Juiz (LLM-as-a-Judge): Avalia as etapas geradas em relação a três dimensões: cobertura/consistência funcional, independência e granularidade.
• Refinamento Iterativo: Se as etapas não atenderem aos limiares de qualidade, o juiz fornece feedback e o planejador refina as etapas. Este ciclo continua até que o plano seja satisfatório ou um limite máximo de iterações seja atingido.

2. Reutilização de Código Consciente da Implementação

Este estágio foca em recuperar funções chamadoras (callees) relevantes e identificar como usá-las efetivamente.

• Recuperação de Função Chamadora de Visão Dupla: Para recuperar funções, o TICoder calcula uma pontuação de similaridade conjunta combinando:
  • Similaridade Funcional ($Sim_F$): Similaridade semântica entre a etapa de implementação e a descrição da função.
  • Similaridade de Implementação ($Sim_I$): Similaridade entre uma representação de código da etapa de implementação (gerada por um LLM) e o código de implementação real da função.
  • A pontuação final é uma soma ponderada ($Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$).
• Seleção de Padrão de Uso de Dois Estágios: Para garantir que as funções sejam usadas corretamente, o TICoder seleciona padrões de uso representativos do repositório:
  • Identificação Baseada em Grafo: Constrói um Grafo de Chamadas de Repositório (RCG) para identificar todas as funções chamadoras para uma função chamada recuperada.
  • Agrupamento Baseado em Estrutura: Agrupa funções chamadoras com base no conjunto de funções que elas invocam (equivalência estrutural).
  • Filtragem Baseada em Perplexidade: Dentro de cada grupo, o chamador mais relevante (menor perplexidade) é selecionado como o centro. Um filtro global então classifica esses centros por perplexidade para selecionar os $n_p$ melhores padrões, equilibrando a riqueza do contexto com a eficiência de tokens.

3. Geração de Código Aprimorada

A fase final de geração de código integra as etapas de implementação refinadas, as funções chamadoras recuperadas, os padrões de uso selecionados, os casos de teste e o requisito original em um único prompt para o LLM gerar o código final.

Principais Contribuições

O artigo reivindica três contribuições primárias:

1. Estrutura TICoder: Uma nova estrutura de geração de código em nível de repositório que integra planejamento iterativo baseado em testes e reutilização de código consciente da implementação.
2. Estratégia de Reutilização Consciente da Implementação: Um mecanismo de recuperação de visão dupla (similaridade funcional + implementação) e uma estratégia de seleção de dois estágios (agrupamento + filtragem de perplexidade) para identificar e reutilizar funções do repositório com precisão.
3. Avaliação Empírica Abrangente: Experimentos abrangentes demonstrando que o TICoder supera os baselines de estado da arte em múltiplos LLMs e benchmarks.

Resultados Experimentais

Os autores avaliaram o TICoder em dois benchmarks amplamente utilizados, CoderEval (Python e Java) e DevEval (Python), usando três LLMs de base: GPT-4o-mini, DeepSeek-V3 e Qwen2.5-Coder-7B.

• Desempenho Geral: O TICoder superou consistentemente todos os baselines (incluindo SimpleRAG, RepoCoder, AllianceCoder e RepoScope). Ele alcançou uma melhoria média de 11,52% sobre o melhor baseline de desempenho.
• Significância Estatística: Um teste t de duas caudas confirmou que os ganhos de desempenho foram estatisticamente significativos ($p < 0,05$).
• Estudo de Ablação: Remover qualquer componente chave (planejamento, casos de teste, refinamento iterativo, recuperação de visão dupla ou padrões de uso) resultou em degradação do desempenho, validando a necessidade de cada módulo.
  • Notavelmente, remover o módulo de planejamento causou uma queda de 6,87% no Pass@1.
  • Remover os casos de teste da etapa de geração causou uma queda substancial de 10,42%.
• Sensibilidade de Hiperparâmetros:
  • Iterações: O desempenho geralmente melhorou com as iterações, mas foi não-monotônico; iterações excessivas poderiam introduzir ruído.
  • Pesos de Similaridade: A similaridade funcional foi geralmente mais importante, mas a similaridade de implementação proporcionou ganhos significativos, particularmente para Java.
  • Padrões de Uso: Um número moderado de padrões (ex: 2) produziu os melhores resultados; poucos limitavam o contexto, enquanto muitos introduziam ruído.

Significância e Alegações

O artigo afirma que o TICoder aborda as limitações específicas das abordagens de planejamento RACG anteriores ao incorporar explicitamente casos de teste na fase de planejamento e fundamentar a recuperação na lógica de implementação de código real. Os autores alegam que, ao preencher a lacuna entre os requisitos de linguagem natural e o código executável através de especificações comportamentais (testes) e contexto estrutural (padrões de uso), o TICoder permite que os LLMs gerem código mais preciso e contextualmente apropriado em configurações de repositórios complexos. O trabalho destaca que a geração bem-sucedida em nível de repositório requer não apenas encontrar código semelhante, mas entender como esse código é especificado comportamentalmente e integrado estruturalmente dentro da base de código existente.