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

Riepilogo Tecnico: TICoder

Definizione del Problema

La generazione di codice a livello di repository utilizzando i Large Language Models (LLM) affronta sfide significative dovute alle complesse dipendenze del codice e alle finestre di contesto limitate. Sebbene gli approcci esistenti utilizzino la Retrieval-Augmented Generation (RAG) e meccanismi di pianificazione per riutilizzare le funzioni da un repository, gli autori identificano due criticità fondamentali nei metodi allo stato dell'arte (SOTA) attuali:

1. Mancanza di Guida Comportamentale Basata su Test nella Pianificazione: I metodi di pianificazione esistenti derivano i passi di implementazione direttamente dai requisiti in linguaggio naturale (NL). Tuttavia, i requisiti in NL sono spesso vaghi o incompleti, portando a piani inaffidabili. Gli attuali metodi di generazione guidata dai test applicano principalmente i casi di test durante le fasi di generazione del codice o post-generazione, lasciando inesplorato il loro potenziale per guidare il processo di pianificazione.
2. Mancanza di Consapevolezza dell'Implementazione a Livello di Codice nel Riutilizzo: Le strategie di recupero esistenti si affidano pesantemente alla somiglianza semantica tra i passi di implementazione e le descrizioni delle funzioni. Esse spesso trascurano la reale logica di implementazione incorporata nel codice. Inoltre, le funzioni recuperate vengono frequentemente inserite nei prompt senza comprendere come esse vengano effettivamente utilizzate (pattern di utilizzo) all'interno del repository, portando a un riutilizzo inefficace.

Metodologia: Framework TICoder

Gli autori propongono TICoder, un framework progettato per migliorare sia le fasi di pianificazione che di riutilizzo della generazione di codice a livello di repository. Il framework si compone di tre fasi principali:

1. Pianificazione Iterativa Guidata dai Test

Inveve di generare piani basandosi esclusivamente sui requisiti in NL, TICoder sfrutta i casi di test come specifiche comportamentali per raffinare i passi di implementazione. Questa fase impiega un meccanismo di "giudizio e riflessione" che coinvolge due ruoli di LLM:

• LLM-as-a-Planner (LLM come Pianificatore): Genera una sequenza iniziale di passi di implementazione basata sul requisito e sui casi di test, guidata da principi quali chiarezza, consapevolezza delle condizioni limite ed esplicite dipendenze.
• LLM-as-a-Judge (LLM come Giudice): Valuta i passi generati rispetto a tre dimensioni: copertura/coerenza funzionale, indipendenza e granularità.
• Raffinamento Iterativo: Se i passi non soddisfano le soglie di qualità, il giudice fornisce un feedback e il pianificatore affina i passi. Questo ciclo continua finché il piano non è soddisfacente o viene raggiunto un limite massimo di iterazioni.

2. Riutilizzo del Codice Consapevole dell'Implementazione

Questa fase si concentra sul recupero delle funzioni chiamanti rilevanti e sull'identificazione di come utilizzarle efficacemente.

• Recupero delle Funzioni Chiamanti a Doppia Vista: Per recuperare le funzioni, TICoder calcola un punteggio di somiglianza congiunto combinando:
  • Somiglianza Funzionale ($Sim_F$): Somiglianza semantica tra il passo di implementazione e la descrizione della funzione.
  • Somiglianza di Implementazione ($Sim_I$): Somiglianza tra una rappresentazione del codice del passo di implementazione (generata da un LLM) e l'effettiva implementazione del codice della funzione.
  • Il punteggio finale è una somma pesata ($Sim = \alpha \cdot Sim_F + \beta \cdot Sim_I$).
• Selezione dei Pattern di Utilizzo a Due Stadi: Per garantire che le funzioni siano utilizzate correttamente, TICoder seleziona pattern di utilizzo rappresentativi dal repository:
  • Identificazione Basata su Grafi: Costruisce un Repository Call Graph (RCG) per identificare tutte le funzioni chiamanti per una determinata funzione chiamata (callee).
  • Clustering Basato sulla Struttura: Raggruppa le funzioni chiamanti in base all'insieme di funzioni che invocano (equivalenza strutturale).
  • Filtraggio Basato sulla Perplessità: All'interno di ogni cluster, viene selezionato il chiamante più rilevante (perplessità più bassa) come centro. Un filtro globale classifica poi questi centri in base alla perplessità per selezionare i migliori $n_p$ pattern, bilanciando la ricchezza del contesto con l'efficienza dei token.

3. Generazione di Codice Potenziata

La fase finale di generazione del codice integra i passi di implementazione raffinati, le funzioni chiamanti recuperate, i pattern di utilizzo selezionati, i casi di test e il requisito originale in un singolo prompt per permettere all'LLM di generare il codice finale.

Contributi Chiave

Il documento rivendica tre contributi primari:

1. Framework TICoder: Un nuovo framework di generazione di codice a livello di repository che integra la pianificazione iterativa guidata dai test e il riutilizzo del codice consapevole dell'implementazione.
2. Strategia di Riutilizzo Consapevole dell'Implementazione: Un meccanismo di recupero a doppia vista (somiglianza funzionale + di implementazione) e una strategia di selezione a due stadi (clustering + filtraggio della perplessità) per identificare e riutilizzare con precisione le funzioni del repository.
3. Valutazione Empirica Estesa: Esperimenti completi che dimostrano come TICoder superi i baseline SOTA attraverso molteplici LLM e benchmark.

Risultati Sperimentali

Gli autori hanno valutato TICoder su due benchmark ampiamente utilizzati, CoderEval (Python e Java) e DevEval (Python), utilizzando tre modelli LLM di base: GPT-4o-mini, DeepSeek-V3 e Qwen2.5-Coder-7B.

• Prestazioni Complessive: TICoder ha costantemente superato tutti i baseline (inclusi SimpleRAG, RepoCoder, AllianceCoder e RepoScope). Ha ottenuto un miglioramento medio dell'11,52% rispetto al miglior baseline.
• Significatività Statistica: Un t-test a due code ha confermato che i guadagni di prestazione sono statisticamente significativi ($p < 0,05$).
• Studio di Ablazione: La rimozione di qualsiasi componente chiave (pianificazione, casi di test, raffinamento iterativo, recupero a doppia vista o pattern di utilizzo) ha causato un degrado delle prestazioni, validando la necessità di ogni modulo.
  • In particolare, la rimozione del modulo di pianificazione ha causato un calo del 6,87% nel Pass@1.
  • La rimozione dei casi di test dalla fase di generazione ha causato un calo sostanziale del 10,42%.
• Sensibilità degli Iperparametri:
  • Iterazioni: Le prestazioni sono generalmente migliorate con le iterazioni ma in modo non monotono; troppe iterazioni possono introdurre rumore.
  • Pesi di Somiglianza: La somiglianza funzionale è stata generalmente più importante, ma la somiglianza di implementazione ha fornito guadagni significativi, specialmente per Java.
  • Pattern di Utilizzo: Un numero moderato di pattern (ad esempio, 2) ha prodotto i risultati migliori; troppo pochi limitavano il contesto, mentre troppi introducevano rumore.

Significato e Rivendicazioni

Il documento afferma che TICoder affronta le specifiche limitazioni dei precedenti approcci di pianificazione RACG incorporando esplicitamente i casi di test nella fase di pianificazione e radicando il recupero nella reale logica di implementazione del codice. Gli autori sostengono che, colmando il divario tra i requisiti in linguaggio naturale e il codice eseguibile attraverso specifiche comportamentali (test) e contesto strutturale (pattern di utilizzo), TICoder consente agli LLM di generare codice più accurato e contestualmente appropriato in ambienti di repository complessi. Il lavoro evidenzia come una generazione di successo a livello di repository richieda non solo il reperimento di codice simile, ma la comprensione di come tale codice sia specificato comportamentalmente e integrato strutturalmente all'interno del codebase esistente.