Il team KwaiKAT di Kuaishou ha introdotto KAT-Coder-V2.5, un modello di programmazione progettato per operare all’interno di repository software reali ed eseguibili, anziché produrre frammenti di codice in una singola interazione. Il modello servito è disponibile tramite StreamLake. Una variante separata a pesi aperti, KAT-Coder-V2.5-Dev, è stata rilasciata su Hugging Face con licenza Apache-2.0.

Il rilascio è incentrato sui flussi di lavoro di programmazione agentica, in cui un modello deve ispezionare un repository, comprendere un’attività, modificare file, eseguire test e verificare se una patch è corretta. Questo orientamento riflette un cambiamento più ampio nella valutazione dei modelli di programmazione, che passa da prompt di programmazione isolati alla manutenzione software a livello di repository, dove ambienti riproducibili e feedback di test affidabili possono essere importanti quanto la qualità della generazione del codice. Il progetto pone l’accento su ambienti di repository, costruzione dei dati, affidabilità della sandbox, infrastruttura di reinforcement learning e valutazione tramite benchmark.

AutoBuilder costruisce ambienti che eseguono i test previsti

La ricerca definisce un’attività di programmazione verificabile come una tripletta: una descrizione precisa dell’attività, un ambiente di repository eseguibile e un insieme di test di validazione. Una patch è considerata corretta solo se supera l’intero insieme di validazione.

Le attività vengono estratte da pull request e commit reali, seguendo la linea di SWE-bench. La modifica al codice integrata fornisce una golden patch, mentre la modifica ai test associata fornisce una test patch. Il sistema non utilizza il testo grezzo delle issue come specifica. Le descrizioni delle attività vengono invece rigenerate in tre componenti: una formulazione del problema basata sulla golden patch, requisiti derivati dalla test patch e vincoli di interfaccia dedotti da entrambe le fonti. Un controllo di chiarezza rimuove le attività ambigue, incomplete, insufficientemente specificate o internamente incoerenti.

AutoBuilder è responsabile del processo di costruzione dell’ambiente. Un agente di build esamina il repository e scrive uno script di configurazione che installa le dipendenze ed esegue i test a partire da un checkout pulito. Un agente di verifica esegue poi lo script in una sandbox isolata.

Il processo di accettazione non si basa su codici di uscita o sulla corrispondenza di pattern nei log. La verifica analizza invece l’output strutturato dei framework di test. Un ambiente viene accettato solo quando viene raccolto più del 90% dei test attesi e gli esiti pass/fail sono riproducibili tra esecuzioni diverse. I fallimenti vengono restituiti come informazioni strutturate per una riparazione iterativa.

Combinando un ambiente di base preconfigurato, template per sistemi di build e una libreria recuperabile di ricette di build distillate, il team ha aumentato il tasso di successo nella costruzione degli ambienti dal 16.5% al 57.2%. Il dataset risultante include più di 100,000 ambienti verificabili in 12 linguaggi di programmazione. La cronologia Git, i metadati dei commit e altre tracce sfruttabili vengono rimossi, in modo che gli agenti non possano ottenere la soluzione di riferimento direttamente dal repository.

Data Scaling Flywheel filtra in base alla qualità del processo

Il progetto sostiene che filtrare le traiettorie solo in base al successo finale dei test può essere fuorviante. Alcune esecuzioni che passano possono dipendere da hard-coding, dall’aggiramento dei meccanismi previsti o da scorciatoie adattate ai test. Allo stesso tempo, alcune esecuzioni fallite possono comunque contenere comportamenti utili di ricerca, localizzazione e riparazione.

KwaiKAT affronta entrambi i casi. Per i tentativi quasi riusciti, suggerimenti mirati a livello di processo indicano cosa dovrebbe essere ispezionato o verificato senza rivelare la soluzione. Questo porta il tasso di superamento delle attività che in precedenza non venivano mai superate a circa il 20%. Poiché le traiettorie con suggerimenti contengono informazioni che non sarebbero disponibili al momento dell’inferenza, la patch verificata viene poi fissata e una traiettoria senza suggerimenti viene rigenerata dal contesto originale dell’attività. Vengono conservati solo i campioni che superano la verifica, non contengono fughe di informazioni dai suggerimenti e rimangono coerenti con la patch.

Per le traiettorie che già passano, filtri basati su regole rimuovono esempi non validi, instabili o sfruttativi. Una fase di scoring valuta quindi esplorazione, localizzazione, ragionamento prima della modifica, fedeltà alla specifica, aderenza alle convenzioni del repository, minimalità della patch, qualità della verifica, comportamento di recupero e onestà.

Un terzo meccanismo mira a ridurre l’overfitting all’harness. I nomi degli strumenti, le convenzioni degli argomenti, i formati di output e i template dei prompt vengono randomizzati mantenendo invariata la funzionalità. Poiché la verifica è legata agli esiti dei test invece che alle tracce dell’harness, la stessa attività può essere presentata con più configurazioni dell’harness. Il sistema inserisce anche perturbazioni realistiche, tra cui dipendenze mancanti, fallimenti transitori dei comandi, output troncati e log rumorosi.

I fallimenti della sandbox hanno influenzato le ricompense prima dei limiti algoritmici

Durante l’addestramento di KAT-Coder-V2, le curve di ricompensa lente erano state inizialmente attribuite all’algoritmo di reinforcement learning. Un audit successivo ha rilevato che circa il 16% delle traiettorie falliva a causa di problemi dell’infrastruttura sandbox, anziché per la policy del modello. Disallineamenti ai confini a volte svuotavano le osservazioni per circa 40 step e corrompevano le ricompense.

Il team ha implementato tre correzioni infrastrutturali. In primo luogo, una policy di eliminazione anticipata delle immagini ha ridotto l’uso del disco dal 95% al 60%, abbassando i rollout non validi causati da timeout dal 6–7% a meno dell’1%. In secondo luogo, la correzione delle variabili d’ambiente durante l’inizializzazione remota della sandbox ha impedito override di sistema che avevano invertito le ricompense nel 6–7% dei campioni, riducendo tali errori sotto l’1%. In terzo luogo, il Gateway Server ha bypassato gli endpoint chat tradizionali, che avevano causato un drift dei token del 40% su una scala di circa 200 turni riapplicando apply_chat_template e ritokenizzando. Il sistema ha invece chiamato direttamente /generate per mantenere l’allineamento dei token nei rollout.

Nel complesso, queste modifiche hanno ridotto il tasso di errore del feedback della sandbox da circa il 16% a meno del 2% e hanno ridotto i collassi dell’addestramento di un ordine di grandezza. Il risultato evidenzia anche un vincolo pratico per l’addestramento di codice agentico: la qualità della ricompensa dipende dal sistema di esecuzione circostante, non solo dall’architettura del modello o dal metodo di ottimizzazione.

PPO asimmetrico e ricompense a tre livelli

I ricercatori hanno scelto PPO con GAE invece di metodi di traiettoria privi di critic perché gli harness di produzione suddividono le sessioni in campioni strutturalmente diversi, rendendo più difficili le baseline di gruppo.

La configurazione di addestramento utilizza un design actor–critic asimmetrico. Il Critic riceve un contesto di addestramento privilegiato, che include ricompense, test, copertura, patch, metadati e turni futuri. L’Actor vede solo lo stato del rollout. Il Critic e il contesto aggiuntivo vengono eliminati al momento dell’inferenza.

Le ricompense sono organizzate in tre livelli. I Core Task Scores richiedono il superamento di tutti i test fail_to_pass e pass_to_pass. Gli Standard Behavior Constraints penalizzano duplicazioni, chiamate a strumenti non valide e residui di debug. I Failed Trajectory Incentives assegnano punteggi al recupero dei file tramite F2 e attribuiscono credito parziale per i test.

Cinque esperti vengono combinati tramite Multi-Teacher On-Policy Distillation utilizzando reverse KL, un avvio off-policy e una troncatura sensibile al drift da Prune-OPD.

Risultati sui benchmark

Con un harness Claude Code unificato, KAT-Coder-V2.5 ha guidato il suo gruppo su PinchBench con un punteggio di 94.9, davanti a Opus 4.8 a 93.5. Si è classificato secondo su SWE-Bench Pro con 65.2 contro 69.2, e secondo sul benchmark interno KAT Code Bench con 53.1 contro 57.3.

Il modello ha ottenuto risultati meno forti su Terminal-Bench 2.1, dove si è classificato ultimo con 60.7, dietro GLM-5.1 a 61.8 e Opus 4.8 a 84.6. Su SciCode ha ottenuto 50.3, eguagliando GLM-5.2. I risultati misti rendono importanti l’harness e l’ambito del benchmark per l’interpretazione, poiché patching di repository, operazioni da terminale e test di programmazione scientifica misurano parti diverse di un sistema di programmazione agentica.

KAT-Coder-V2.5-Dev a pesi aperti è un modello MoE separato da 35B totali / 3B attivi, post-addestrato su Qwen3.6-35B-A3B utilizzando 127K esempi SFT, seguito da reinforcement learning. È stato valutato con un protocollo interno separato, quindi i suoi risultati non sono confrontabili con la tabella principale dei benchmark del modello di punta.

I materiali principali del progetto includono il paper, la pagina prodotto StreamLake e i pesi del modello KAT-Coder-V2.5-Dev su Hugging Face.