Composer 2 Technical Report

Titolo: Composer 2: Un Modello Specializzato per l'Ingegneria del Software Agente

1. Il Problema

L'attuale stato dell'arte nei modelli linguistici (LLM) per la generazione di codice presenta diverse limitazioni quando applicato all'ingegneria del software reale:

• Disallineamento Train-Test: I benchmark pubblici (come SWE-bench o Terminal-Bench) spesso misurano la capacità di risolvere puzzle astratti o bug isolati con prompt altamente specificati, non riflettendo la complessità, l'ambiguità e la mancanza di specifiche dei task reali degli sviluppatori.
• Contaminazione dei Dati: Molti benchmark sono costruiti su repository open-source storici, che possono essere stati inclusi nei set di addestramento, gonfiando artificialmente i punteggi.
• Mancanza di Pianificazione a Lungo Termine: I modelli esistenti faticano a mantenere la coerenza in task di ingegneria del software che richiedono pianificazione a lungo termine, debug complesso, refactoring su larga scala e interazione con ambienti di esecuzione reali.
• Costo ed Efficienza: I modelli generalisti di fascia alta sono spesso costosi da servire e meno efficienti rispetto a modelli specializzati.

2. Metodologia

Composer 2 è un modello specializzato nell'ingegneria del software agente, addestrato in due fasi principali per massimizzare le prestazioni su task reali:

A. Pre-addestramento Continuato (Continued Pretraining)

• Modello Base: È stato selezionato Kimi K2.5 (un modello MoE da 1,04 trilioni di parametri totali, con 32 miliardi di parametri attivi) come base.
• Strategia: Il modello è stato sottoposto a un pre-addestramento continuato su un vasto mix di dati dominati dal codice. Questa fase è stata divisa in tre sotto-fasi:
  1. Addestramento su sequenze di 32k token.
  2. Estensione al contesto lungo fino a 256k token.
  3. Una breve fase di SFT (Supervised Fine-Tuning) su task di codifica mirati.
• Obiettivo: Migliorare la conoscenza di base del codice e la capacità latente di programmazione prima dell'addestramento per agenti.
• Ottimizzazione: Implementazione di strati Multi-Token Prediction (MTP) per il decoding speculativo, accelerando l'inferenza in produzione.

B. Apprendimento per Rinforzo (Reinforcement Learning - RL)

• Ambiente: L'addestramento RL avviene in ambienti che replicano fedelmente le sessioni Cursor reali, utilizzando gli stessi strumenti e strutture (harness) del prodotto finale.
• Distribuzione dei Task: I task sono distribuiti per riflettere l'uso reale (debug, nuove feature, refactoring, comprensione del codicebase, ecc.), evitando la sovrapposizione con i benchmark pubblici.
• Algoritmo: Utilizzo di un algoritmo di gradiente della politica asincrono e su larga scala.
  • Stabilità: Implementazione di tecniche per minimizzare la divergenza off-policy (aggiornamenti dei pesi in volo, replay del routing MoE).
  • Ricompense: Oltre alla correttezza del codice, vengono applicate ricompense per lo stile di comunicazione, l'efficienza e penalità non lineari per la lunghezza (per incentivare risposte rapide su task semplici e pensiero approfondito su task complessi).
  • Auto-riassunzione (Self-Summarization): Tecnica per gestire orizzonti temporali lunghi, dove il modello riassume il proprio stato e le azioni precedenti per mantenere la coerenza senza superare i limiti del contesto.

C. Infrastruttura

• Scalabilità: Uso di Context Parallelism (CP) per gestire contesti lunghi, decoupling dell'Expert Parallelism (EP) dal Tensor Parallelism (TP) per supportare configurazioni MoE più grandi.
• Precisione: Addestramento su GPU NVIDIA Blackwell utilizzando formati a bassa precisione MXFP8 e NVFP4, con kernel ottimizzati (ThunderKittens) per garantire stabilità numerica e velocità.
• Ambienti di Esecuzione: Utilizzo di Anyrun, una piattaforma interna per eseguire codice non attendibile su larga scala, permettendo l'esecuzione di container isolati con browser e GUI per simulare l'uso reale.

3. Contributi Chiave

1. CursorBench: Introduzione di un nuovo benchmark interno derivato da sessioni di codifica reali del team di ingegneria di Cursor. A differenza dei benchmark pubblici, CursorBench presenta task con:
   • Prompt meno specifici (più ambigui).
   • Modifiche al codice molto più estese (mediana di 181 linee contro 7-10 di SWE-bench).
   • Assenza totale di contaminazione dai dati di addestramento.
2. Pipeline di Addestramento Agente: Dimostrazione che la combinazione di pre-addestramento continuato su dati di codice e RL su larga scala in ambienti realistici porta a modelli specializzati superiori.
3. Efficienza e Costo: Il modello raggiunge prestazioni di livello "frontier" mantenendo un costo di inferenza inferiore rispetto ai modelli generalisti di punta.
4. Infrastruttura RL Asincrona: Sviluppo di un sistema robusto per l'addestramento RL distribuito su più regioni, con gestione avanzata dei checkpoint a livello di rollout e sincronizzazione dei pesi in tempo reale.

4. Risultati

I risultati sono riportati nella Tabella 1 del documento:

• CursorBench: Composer 2 raggiunge un 61,3% di accuratezza, un miglioramento del 37% rispetto a Composer 1.5 e del 61% rispetto a Composer 1. Supera modelli come Opus 4.6 High (58,2%) e GPT-5.3 Codex (59,1%).
• SWE-bench Multilingual: Punteggio di 73,7%, competitivo con i migliori modelli (es. GPT-5.4 a 76,8% nel loro harness).
• Terminal-Bench: Punteggio di 61,7%, in linea con i sistemi all'avanguardia.
• Efficienza: Composer 2 si posiziona su una frontiera di Pareto ottimale: offre un'accuratezza paragonabile ai modelli più grandi e costosi, ma con un costo di inferenza simile a varianti più piccole o a basso sforzo.
• Miglioramento delle Statistiche: A differenza di altri studi dove l'RL migliora solo il "best-of-K" a scapito della media, Composer 2 mostra miglioramenti sia nella media che nel best-of-K, indicando una reale espansione della copertura delle soluzioni corrette.

5. Significato e Impatto

Il rapporto su Composer 2 segna un punto di svolta nell'approccio allo sviluppo di agenti per l'ingegneria del software:

• Validazione della Specializzazione: Dimostra che specializzare un modello generalista su un dominio specifico (codice) attraverso un addestramento mirato e ambienti realistici è più efficace che affidarsi a modelli generalisti generici.
• Superamento dei Benchmark Pubblici: Evidenzia i limiti dei benchmark attuali e propone un nuovo standard (CursorBench) basato su dati reali, che cattura meglio l'ambiguità e la complessità del lavoro degli sviluppatori.
• Fattibilità Economica: Smentisce l'idea che solo i modelli più grandi e costosi possano gestire task complessi di ingegneria del software; Composer 2 offre prestazioni di livello superiore a un costo inferiore.
• Futuro: Apre la strada a modelli capaci di gestire task che richiedono ore di lavoro umano, spostando il focus da semplici correzioni di bug a compiti di ingegneria sistemica complessi e a lungo termine.

In sintesi, Composer 2 rappresenta un modello "frontier" che unisce intelligenza di pianificazione a lungo termine, capacità di esecuzione precisa e efficienza economica, validato attraverso una metodologia di valutazione rigorosa e realistica.