Riepilogo Tecnico: DeNovoSWE

Definizione del Problema

Sebbene gli agenti di codice basati su Large Language Model (LLM) abbiano dimostrato competenza nella risoluzione di bug localizzati all'interno di basi di codice esistenti (ad esempio, SWE-bench), le loro capacità in compiti di ingegneria del software a lungo orizzonte — specificamente l'architettura e l'implementazione di interi repository software partendo da specifiche di alto livello — rimangono poco sviluppate. I benchmark attuali spesso non riescono a testare rigorosamente queste capacità di ragionamento e implementazione a lungo orizzonte, e i dataset di addestramento esistenti sono prevalentemente centrati sulla risoluzione di singoli problemi piuttosto che sulla generazione di interi repository.

Il collo di bottiglia principale è la scarsità di dati verificabili su larga scala per la generazione di interi repository. La costruzione di tali dati presenta tre sfide fondamentali:

1. Costruzione della Documentazione: La documentazione dei repository esistenti è spesso incompleta o disallineata rispetto al comportamento eseguibile, rendendola insufficiente per definire compiti di generazione da documento a repository.
2. Progettazione della Valutazione: Manca la mancanza di protocolli obiettivi e scalabili per valutare diversi repository attraverso test eseguibili.
3. Esecuzione Senza Perdite (Leakage-Free): Gli agenti moderni che operano in ambienti interattivi possono sfruttare canali non intenzionali (ad esempio, recupero tramite rete, cronologia git) per accedere alle implementazioni di riferimento, rendendo necessaria una robusta tecnica di sandboxing.

Metodologia: Il Framework DeNovoSWE

Gli autori introducono DeNovoSWE, un dataset su larga scala composto da 4.818 istanze di alta qualità in cui gli agenti devono generare un intero repository da zero basandosi sulla documentazione generata. Il dataset è costruito tramite un workflow agentico automatizzato e sandboxed che impiega una strategia "divide et impera" accoppiata a un meccanismo iterativo di critica e riparazione.

1. Architettura della Pipeline Automatica

Il processo di costruzione è diviso in due fasi principali:

• Fase di Divisione (Decomposizione):

  • Profiling del Repository: Il sistema esegue unit test per catturare tracce di runtime, categorizzando le unità di implementazione in componenti diretti (esplicitamente testati), indiretti core (necessari per il comportamento) e indiretti non core (dettagli interni).
  • Partizione delle Capacità: Un autore di panoramiche genera un riepilogo di alto livello, seguito da un autore di capacità che decompone il repository in distinte capacità funzionali.
  • Mappatura: Un classificatore basato su LLM mappa funzioni e classi specifiche a queste capacità, garantendo che la documentazione sia fondata sulle effettive unità di implementazione.

• Fase di Conquista (Raffinamento Iterativo):

  • Agente Draft: Genera la documentazione iniziale per ogni capacità, ispezionando il codice sorgente in un ambiente sandboxed.
  • Agente Critic: Valuta la bozza per organizzazione strutturale, copertura dei componenti diretti/indiretti core e specificità delle API. Identifica omissioni o dettagli sotto-specificati senza far trapelare il comportamento specifico dei test.
  • Agente Repair: Raffina iterativamente la documentazione basandosi sul feedback del critic, ispezionando il repository sorgente per risolvere le incongruenze.
  • Merging: I documenti finali a livello di capacità vengono uniti alla panoramica del repository per formare la documentazione completa del compito.

2. Valutazione e Prevenzione delle Perdite (Leakage)

Per garantire la validità del compito "da documento a repository", il framework impone un rigoroso contenimento:

• Pre-pulizia: Il codice e le suite di test del repository target vengono rimossi, mantenendo solo le configurazioni di build.
• Purga delle Perdite (Leak Purging): Il processo elimina i pacchetti site-packages, le cache di pip e gli artefatti di compilazione transitori.
• Sanificazione Git: La directory .git viene distrutta e reinizializzata per impedire agli agenti di fare reverse-engineering della cronologia tramite git reflog.
• Restrizioni di Runtime: I container Docker impongono restrizioni ai comandi per bloccare il recupero tramite rete (ad esempio, pip install, curl) del pacchetto target, integrati da un auditing basato su LLM delle tracce di esecuzione.

3. Filtraggio delle Traiettorie Consapevole della Difficoltà

Riconoscendo che le traiettorie completamente andate a buon fine sono difficili da ottenere per repository complessi, gli autori propongono una strategia di filtraggio delle traiettorie consapevole della difficoltà invece di utilizzare una soglia globale fissa.

• Punteggio di Difficoltà: Un framework stima la difficoltà del compito utilizzando segnali strutturali (conteggio delle righe eseguibili) e giudizi qualitativi basati su LLM.
• Soglie Adattive: Le soglie di filtraggio sono regolate in base alla difficoltà stimata. I compiti più facili richiedono tassi di successo elevati (ad esempio, 0.90), mentre i compiti più difficili accettano tassi inferiori (ad esempio, 0.60) per trattenere successi parziali informativi. Ciò bilancia la qualità dei dati con la diversità delle istanze impegnative.

Contributi Chiave

1. Dataset DeNovoSWE: Un dataset su larga scala di 4.818 istanze di generazione da documento a repository, costruito automaticamente tramite una pipeline multi-agente sandboxed. È circa 46 volte più grande dei precedenti benchmark di generazione di repository come NL2Repo.
2. Pipeline di Costruzione Automatica: Un workflow innovativo che combina la decomposizione divide-and-conquer con meccanismi iterativi di critica e riparazione per sintetizzare una documentazione completa e allineata ai test senza annotazione umana.
3. Filtraggio Consapevole della Difficoltà: Una strategia per curare le traiettorie di addestramento che bilancia la fedeltà di esecuzione con la diversità dei compiti, evitando l'esclusione di preziosi casi difficili pur filtrando il rumore dai compiti facili.
4. DeNovoSWE-Agent: Un modello fine-tuned che dimostra miglioramenti sostanziali nelle capacità di SWE a lungo orizzonte.

Risultati Sperimentali

Gli autori hanno valutato l'impatto di DeNovoSWE effettuando il fine-tuning dei modelli Qwen3-30B-A3B e Qwen3.5-35B-A3B sul dataset.

• Guadagni di Performance: Il fine-tuning di Qwen3-30B-A3B su DeNovoSWE ha elevato il suo punteggio sul benchmark BeyondSWE-Doc2Repo dal 5.8% al 47.2%.
• Confronto con Modelli Proprietari: Il modello fine-tuned DeNovoSWE-Agent-35A3B ha ottenuto il 50.0% su BeyondSWE-Doc2Repo, riducendo il divario con i modelli proprietari di frontiera (ad esempio, entro 2.0 punti percentuali di Gemini3-Pro) nonostante l'uso di un backbone open-weight più piccolo.
• Studi di Ablazione: Gli esperimenti hanno confermato che il filtraggio consapevole della difficoltà supera le soglie globali fisse. Una soglia fissa di 0.95 ha prodotto prestazioni inferiori (48.1%) rispetto alla strategia adattiva (50.0%), evidenziando l'importanza di trattenere traiettorie diverse e impegnative.

Significato

Il paper sostiene che DeNovoSWE affronti una lacuna critica nei dati di addestramento verificabili per l'ingegneria del software a lungo orizzonte. Spostando il focus dalla risoluzione di bug localizzati alla generazione di interi repository, il dataset consente l'addestramento di agenti capaci di costruzione di repository a livello di architetto. I risultati suggeriscono che dati di addestramento di alta qualità e a lungo orizzonte siano un fattore decisivo per migliorare la capacità di un agente di generare interi sistemi software da zero, colmando potenzialmente il divario di performance tra i modelli open-weight e i modelli proprietari di frontiera in compiti complessi di ingegneria del software.