Riassunto Tecnico: Socratic-SWE

Problematica

Gli agenti di ingegneria del software (SWE) guidati da Large Language Model (LLM) sono emersi come un benchmark critico per l'intelligenza nel mondo reale, richiedendo un'interazione a lungo termine con i repository di codice per la localizzazione, la riparazione e la verifica dei bug. Tuttavia, l'addestramento di questi agenti è frenato dalla scarsità di task SWE di alta qualità. I metodi esistenti di sintesi di dati si affidano tipicamente a mutazioni statiche, iniezione di bug o procedure di riscrittura fisse. Questi approcci generano distribuzioni di task indipendenti dal progresso di addestramento dell'agente e dalle sue specifiche debolezze, portando a un disallineamento tra il curriculum e le reali lacune di capacità del modello. Inoltre, sebbene l'addestramento tramite reinforcement learning (RL) produca preziosi "solving traces" (registrazioni del comportamento dell'agente, dell'uso di strumenti e dei fallimenti), gli attuali metodi scartano queste tracce dopo l'estrazione dei reward scalari, fallendo nell'utilizzarle per far evolvere il curriculum di addestramento.

Metodologia: Socratic-SWE

Gli autori propongono Socratic-SWE, un framework a ciclo chiuso e auto-evolutivo che trasforma le tracce storiche di risoluzione in segnali di addestramento strutturati. Il sistema opera attraverso un ciclo co-evolutivo che coinvolge una policy condivisa $\pi_\theta$ che alterna due ruoli: un Generatore e un Solver.

1. Registro delle Competenze dell'Agente (Distillazione delle Tracce)

Inve old di scartare le tracce, Socratic-SWE le destilla in un Agent Skill Registry ($S$). Questo processo prevede tre fasi:

• Raccolta delle Tracce: Il Solver interagisce con i repository seed, generando un corpus di tracce ($T$), incluse traiettorie di successo e di fallimento.
• Estrazione delle Competenze: Un modello di distillazione ($M_{distill}$) analizza queste tracce per identificare pattern comportamentali ricorrenti. Per le tracce di successo, estrae strategie generalizzabili; per le tracce di fallimento, riassume le modalità di errore e i principi correttivi.
• Costruzione del Registro: Le competenze candidate vengono de-duplicate e filtrate per formare un registro strutturato. Ogni competenza è un documento strutturato contenente un nome, una descrizione, le condizioni di applicabilità e un elenco ordinato di operazioni.

2. Generazione di Task Guidata dalle Competenze

Il ruolo del Generatore utilizza l'Agent Skill Registry per costruire task di riparazione mirati in repository di codice reali.

• Proposte Adattive: Il Generatore campiona una competenza $s \in S$ e un repository $r$ per proporre un task $\tau$ e un segnale di verifica $v$. Questo processo è condizionato dall'evidenza ($E_t$) raccolta dalle prestazioni precedenti del Solver, garantendo che i task prendano di mira le attuali lacune di capacità.
• Validazione a Stadi: I task candidati sono sottoposti a una pipeline di validazione basata sull'esecuzione in quattro fasi in un ambiente sandbox:
  1. Formato: Validità sintattica.
  2. Grounding: Verifica che gli artefatti del task esistano nel repository.
  3. Esecuzione: Stabilità e riproducibilità della suite di verifica.
  4. Semantica: Conferma che il task distingua tra stati di fallimento e stati riparati.
• Reward Consapevole del Gradiente: Per garantire che i task non siano solo validi ma anche utili, il Generatore è premiato in base all'allineamento del gradiente del solver. Il sistema calcola una direzione del gradiente target ($G_v$) da un set di validazione affidabile tenuto da parte. Il reward per un task candidato è la similarità del coseno tra il gradiente del solver indotto dal task ($g_\tau$) e $G_v$. Ciò privilegia i task che spingono il solver in una direzione coerente con i miglioramenti affidabili.

3. Repository Repair Solver

Il ruolo del Solver si addestra sul curriculum accettato di task. Interagisce con il sandbox del repository per generare patch. La funzione di reward ($r_S$) è multi-componente e premia:

• Il superamento dell'intera suite (tutti i test passano).
• I tassi di riparazione parziale.
• L'evitamento delle regressioni (preservazione dei test originariamente passati).
  Il Solver è ottimizzato utilizzando GDPO (Grouped Direct Policy Optimization) per gestire efficacemente i componenti eterogenei del reward.

Contributi Chiave

1. Paradigma di Auto-Evoluzione Guidato dalle Tracce: Il paper dimostra che le tracce di risoluzione, tipicamente scartate dopo il calcolo del reward, possono servire come substrato riutilizzabile per agenti auto-evolutivi. Socratic-SWE converte il comportamento storico in competenze strutturate che guidano un ciclo chiuso di traccia-competenza-task.
2. Ottimizzazione del Curriculum Consapevole del Gradiente: Gli autori introducono un meccanismo di curriculum che combina la generazione condizionata dalle competenze con la validazione basata sull'esecuzione e un reward di allineamento del gradiente del generatore. Ciò assicura che i task generati siano sia verificabili che allineati con le direzioni di miglioramento affidabili.
3. Prestazioni Empiriche Superiori: Il framework raggiunge risultati allo stato dell'arte tra i baseline auto-evolutivi sotto budget computazionale identico, dimostrando forti capacità di auto-evoluzione e di trasferimento.

Risultati Sperimentali

Il framework è stato valutato su quattro benchmark: SWE-bench Verified, SWE-bench Lite, SWE-bench Pro e Terminal-Bench 2.0. Gli esperimenti hanno utilizzato un budget computazionale fisso di 36.000 istanze di addestramento (12k per iterazione su 3 iterazioni) e ha confrontato il sistema contro cinque baseline auto-evolutive (SPIRAL, R-Zero, Absolute-Zero, Socratic-Zero, SSR) e un agente base.

• Performance: Dopo tre iterazioni, Socratic-SWE ha raggiunto il 50,40% su SWE-bench Verified, un miglioramento di +7,80 punti rispetto all'agente base e di +3,40 rispetto al baseline più forte (SSR). Ha inoltre raggiunto il 36,67% su Lite, il 22,85% su Pro e il 14,61% su Terminal-Bench 2.0.
• Scalabilità: A differenza dei baseline che si stabilizzano o regrediscono dopo 2 iterazioni, Socratic-SWE ha mostrato guadagni costanti attraverso la terza iterazione. L'estensione della scalabilità a 5 iterazioni ha mostrato il raggiungimento di un tetto più alto (52,00%) rispetto a SSR (48,00%).
• Studi di Ablazione: La rimozione del Skill Registry ha causato il calo di performance più grande (-4,20 punti), confermando che il design del curriculum guidato dalle competenze è il driver principale. Sostituire la distillazione delle tracce con competenze manuali o utilizzare lo standard GRPO invece di GDPO ha portato anch'esso a una significativa degradazione.

Significato e Rivendicazioni

Il paper sostiene che Socratic-SWE fornisca un substrato scalabile per agenti SWE auto-evolutivi sfruttando le proprie tracce di risoluzione per adattare continuamente il proprio curriculum di addestramento. Gli autori argomentano che questo approccio supera i limiti della sintesi di dati statica e agnostica rispetto al modello, creando un loop dinamico e consapevole del modello dove:

• Le tracce vengono trasformate in competenze.
• Le competenze guidano la generazione di task mirati.
• I task generati producono nuove tracce per un'ulteriore evoluzione.

I risultati suggeriscono che le tracce di risoluzione contengono segnali sufficienti per guidare un miglioramento continuo senza annotazione esterna, ritardando efficacemente la saturazione delle curve di apprendimento osservata in altri metodi di self-play. Il framework è particolarmente efficace perché utilizza i ricchi e diagnosticabili pattern di fallimento inerenti alle tracce SWE, combinati con una verifica deterministica basata sull'esecuzione.

Limitazioni

Gli autori riconoscono diverse limitazioni:

• Ambiente a Mondo Chiuso: La valutazione si basa su un pool fisso di repository seed. Man mano che il Skill Registry diventa più completo, il sistema affronta rendimenti decrescenti a causa di segnali di addestramento ridondanti.
• Dipendenza dalla Validazione: Il metodo dipende da un set di validazione tenuto da parte per definire il reward di allineamento del gradiente del generatore, il che può limitare la robustezza se la distribuzione di validazione non rappresenta l'ambiente di deployment target.
• Requisiti di Esecuzione: L'approccio assume una verifica eseguibile e un'interazione in sandbox, il che significa che i guadagni potrebbero non trasferirsi direttamente a contesti privi di test affidabili o esecuzione deterministica.
• Ambito: La valutazione è attualmente limitata a specifici benchmark SWE e terminal-agent; il trasferimento più ampio ad altri linguaggi o workflow deve ancora essere stabilito.