Riepilogo Tecnico: Convertito, Non Equivalente: Valutazione della Conversione di Codebase tramite Equivalenza Osservazionale

Enunciato del Problema

I recenti progressi negli agenti di codifica li hanno resi capaci di agire come collaboratori su scala di codebase, in grado di navigare progetti, modificare file ed eseguire manutenzione software su larga scala. Tuttavia, è emersa una debolezza critica: gli agenti tendono a sovrastimare eccessivamente le proprie routine di validazione locale. Nel contesto della conversione di codebase (ad esempio, la migrazione da PyTorch a JAX), gli agenti spesso dichiarano successo basandosi su controlli superficiali — come un punto di ingresso chiamabile, una perdita finita o la validità sintattica — violando al contempo i contratti semantici da cui gli utenti dipendono effettivamente.

I metodi di valutazione precedenti per la conversione di codebase sono in gran parte guidati dal risultato, confrontando il successo finale del compito o gli artefatti nello stato finale sotto valutatori nascosti. Questo approccio è instabile per la conversione che preserva la semantica, poiché gli esiti osservabili possono essere scarsi rispetto allo spazio delle implementazioni. Due codebase con contratti interni profondamente diversi possono produrre perdite forward quasi identiche su un singolo batch, divergendo nettamente nei gradienti, negli stati dell'ottimizzatore o nella dinamica di allenamento a breve termine. Di conseguenza, i confronti basati solo sul risultato rischiano di premiare accordi accidentali su sonde superficiali, fallendo nel rilevare fallimenti semantici.

Metodologia: T2J-Bench

Per colmare questa lacuna nella valutazione, gli autori introducono T2J-Bench, un benchmark che riformula la conversione di codebase come trasferimento sotto un contratto di equivalenza fisso. Invece di chiedere se un codebase convertito esegua semplicemente, T2J-Bench verifica se il codebase convertito si comporta come l'originale sotto un insieme fisso di test limitati derivati dalla sorgente.

Framework Principale

Il benchmark opera attraverso un processo di verifica ordinato in tre fasi. Un codebase candidato deve superare ciascuna fase in sequenza per essere considerato riuscito:

1. Spec (Ammissibilità dell'Interfaccia): Verifica che il codebase convertito esponga la stessa interfaccia di allenamento della sorgente. Ciò include il controllo degli alberi dei parametri, degli schemi dei batch, dei punti di ingresso pubblici e della capacità di costruire un runtime senza errori.
2. Numeric (Output Forward e Tensori): Confronta artefatti specifici calcolati durante test limitati. Ciò include output forward, perdite, gradienti e tensori specifici per l'obiettivo (ad esempio, log-probabilità della politica per DPO, output di valore per PPO). I confronti utilizzano tolleranze rigorose per errore assoluto/relativo, similarità coseno e divergenza KL.
3. Behavioral (Dinamiche a Breve Termine): Indaga se il accordo numerico locale sia sufficiente a preservare le dinamiche di allenamento a breve termine sotto semi fissi. Ciò comporta la riproduzione di alcuni passaggi di allenamento per garantire che gli aggiornamenti dell'ottimizzatore, i calcoli delle ricompense e le interazioni con il modello di riferimento producano traiettorie coerenti con la sorgente.

Impostazione Sperimentale

• Compito: Convertire codebase completi di allenamento in PyTorch per SFT (Supervised Fine-Tuning), DPO (Direct Preference Optimization) e PPO (Proximal Policy Optimization) in JAX.
• Dataset: 45 punti dati che coprono 15 famiglie di modelli (ad esempio, varianti di LLaMA, Mistral, Qwen) con vincoli di dimensione (<7B parametri) e configurazioni limitate.
• Protocollo di Valutazione:
  • Baseline Controllate: Modelli all'avanguardia (ad esempio, Claude Opus 4.7, Gemini 3.1 Pro, Qwen3 Coder) valutati utilizzando un'architettura multi-agente auto-implementata e agnostica rispetto al backbone.
  • Agenti Nativi: Sistemi completi di agenti di codifica (ad esempio, Claude Code, Codex) valutati nelle loro interfacce native.
  • Vincoli: Viene utilizzato un "prompt di vincolo minimo" ($p^\star$) per fissare l'interfaccia di allenamento senza rivelare i dettagli interni del valutatore. Il verificatore rimane esterno e fisso.

Risultati Chiave

La valutazione di 355 tentativi di conversione cieca produce quattro scoperte centrali:

1. La Conversione di Codebase è Lontana dall'Essere Risolta: Nonostante alti tassi di superamento nella fase iniziale Spec (fino al 91,1%), il tasso di superamento end-to-end complessivo per i sistemi più forti è solo del 26,7–28,9% a @1. L'ostacolo principale è preservare l'equivalenza numerica e le dinamiche di allenamento, non semplicemente produrre codice eseguibile.
2. Il Budget Computazionale è un Rimedio Debole: Aumentare il budget di inferenza (numero di token) produce rendimenti decrescenti. Una dispersione di 4,7 volte nel costo in token per tentativo si traduce in una dispersione di soli 2,2 volte nel tasso di superamento complessivo. I sistemi che spendono più token spesso si impegnano in indagini ripetute o auto-verifiche verbose senza migliorare la qualità finale della conversione.
3. Sovrastima Sistematica: Ogni sistema valutato sovrastima significativamente il proprio successo. Il divario tra i tassi di superamento auto-dichiarati (spesso >90%) e i tassi di superamento misurati dal valutatore (0–29%) varia da 66,6 a 97,8 punti percentuali. Gli agenti tendono a verificare che gli artefatti esistano e siano ben formati (ad esempio, "la perdita è uno scalare finito") ma falliscono nel verificare che questi artefatti corrispondano alla semantica della sorgente.
4. I Modi di Fallimento sono Disallineati al Contratto: I fallimenti più difficili derivano da auto-validazione disallineata al contratto piuttosto che da una forza limitata del backbone. I modelli di fallimento comuni includono:
   • Errori di Giuntura: Confusione di tipi al confine JAX/PyTorch (ad esempio, passare numpy.ndarray a un layer di embedding PyTorch).
   • Sostituzione Semantica: Restituire la perdita del metodo DPO nello slot forward_loss, soddisfacendo i test di fumo locali ma violando il contratto specifico richiesto dal valutatore.
   • Divergenza di Gradiente/Stato: Corrispondenza dei passaggi forward ma fallimento nel preservare le norme dei gradienti o gli aggiornamenti dello stato dell'ottimizzatore.

Significato e Affermazioni

Il documento afferma che T2J-Bench fornisce una necessaria transizione da una valutazione guidata dal risultato a una valutazione guidata dal contratto. Decomponendo la verifica nelle fasi Spec, Numeric e Behavioral, il benchmark aggira l'indecidibilità dell'equivalenza assoluta delle codebase rimanendo discriminativo tra diversi modelli e sistemi di agenti.

Gli autori sostengono che nel regime attuale di conversione di codebase:

• Il solo scaling del backbone è insufficiente: Il divario tra i modelli migliori e quelli peggiori è piccolo rispetto al divario tra auto-validazione e verifica esterna.
• L'auto-validazione è il principale collo di bottiglia: Gli agenti falliscono non perché non possono calcolare i valori corretti, ma perché i loro loop di validazione interni trattano "artefatti ben formati" come equivalenti a "artefatti semanticamente corretti".
• I futuri miglioramenti richiedono un allineamento esterno: Chiudere il divario richiede che gli agenti interiorizzino un ciclo di confronto con la sorgente piuttosto che affidarsi a test di fumo auto-coerenti. Il benchmark funge da architettura diagnostica per identificare questi disallineamenti.

Il documento conclude che, sebbene T2J-Bench sia istanziato sulla conversione da PyTorch a JAX, il suo framework di contratti di equivalenza fissi e verifica a stadi offre un approccio generalizzabile per valutare le trasformazioni di codebase che preservano la semantica.