Sintesi Tecnica: CodeRescue: Routing di Recupero Calibrato sul Budget per Agenti di Coding

1. Formulazione del Problema

Il paper affronta la sfida del deployment di agenti di coding che operano in ambienti eseguibili dove i tentativi falliti generano feedback azionabili (ad es., errori del compilatore, test falliti, tracce stderr) piuttosto che semplici output errati. I sistemi esistenti attenti ai costi trattano tipicamente i fallimenti del modello come una decisione binaria: escalation immediata a un modello più forte e costoso.

Gli autori sostengono che questo approccio sia subottimale per il coding perché il feedback di esecuzione può rendere vantaggiosi ulteriori tentativi da parte di un modello economico. Ciò crea una domanda di deployment con budget: quando un agente fallisce, dovrebbe spendere più computazione economica per riparare la soluzione (riflettere) o ripianificare, o dovrebbe scalare a un modello più forte?

Il problema è formulato come routing di recupero post-fallimento. Dato un tentativo iniziale fallito da un modello economico, il sistema deve scegliere tra tre azioni eterogenee:

1. Reflect (Riflettere): Revisionare la soluzione esistente utilizzando il feedback di esecuzione.
2. Replan (Ripianificare): Generare una nuova soluzione partendo da un piano diverso utilizzando il modello economico.
3. Escalate (Scalare): Delegare il problema (con il relativo feedback) a un modello più forte e costoso.

L'obiettivo è massimizzare il tasso di risoluzione (solve rate) soggetto a un budget medio di recupero ($B$) specificato dall'utente, senza dover riaddestrare la policy per ogni nuovo vincolo di budget.

2. Metodologia

2.1 Router di Recupero Supervisionato

Il componente centrale è un router supervisionato addestrato su rollout di esecuzione offline.

• Input: Un contesto di recupero $x = (q, v_0, e_0)$, composto dalla descrizione del problema, il verdetto di esecuzione e la traccia stderr.
• Etichettatura (Labeling): Per ogni istanza fallita, l'etichetta "oracle" è definita come l'azione di successo più economica ($a^\dagger$) tra l'insieme delle azioni che risolvono l'istanza ($S(x)$). Le istanze in cui nessuna azione ha successo vengono escluse.
• Addestramento: Un modello linguistico (ad es., Qwen3.5-4B) viene sottoposto a fine-tuning tramite cross-entropy per predire l'azione di successo più economica. Il router assegna punteggi alle azioni basandosi sulle log-probabilità e le normalizza tramite softmax.

2.2 Policy Regolarizzata sul Costo

Per consentire il deployment sotto budget variabili senza riaddestramento, gli autori introducono una penalità di costo $\lambda \ge 0$. La policy $\pi_\lambda(x)$ seleziona l'azione che massimizza:
$$s_\theta(a | x) - \lambda c(a, x)$$
dove $s_\theta$ è il punteggio del router e $c(a, x)$ è il costo stimato di deployment.

• All'aumentare di $\lambda$, la policy si sposta verso azioni più economiche (reflect/replan).
• Ciò crea un insieme discreto di punti operativi (una frontiera costo-qualità) derivati da un singolo router addestrato.

2.3 Calibrazione del Budget Conforme (CRC)

Per selezionare il $\lambda$ appropriato per un determinato budget utente $B$ con garanzie statistiche, gli autori applicano il Conformal Risk Control (CRC).

• Meccanismo: Utilizzando un set di calibrazione tenuto separato (held-out) di istanze fallite, il sistema calcola il costo medio empirico per vari valori di $\lambda$.
• Regola di Selezione: Seleziona la penalità meno restrittiva $\hat{\lambda}$ tale che il vincolo del budget su campioni finiti sia soddisfatto:
  $$\frac{n \hat{C}_n(\lambda) + c_{\max}}{n + 1} \le B$$
  dove $c_{\max}$ è un tetto di costo noto e il termine additivo fornisce una correzione conforme leave-one-out.
• Garanzia: Sotto l'assunto di scambiabilità, questa procedura garantisce che il costo medio di recupero atteso della policy distribuita sui futuri dati di test non superi $B$. Fondamentalmente, questa garanzia si applica al costo, non al tasso di risoluzione, permettendo pattern di successo non monotoni tra le azioni.

3. Contributi Chiave

1. Routing di Recupero Post-Fallimento: Il paper formula il recupero di un agente di coding come un problema di routing su azioni eterogenee (reflect, replan, escalate) piuttosto che come un semplice cascata verso un modello più forte.
2. Deployment Controllabile tramite Budget: Introduce un controllo del budget calibrato tramite CRC che permette a un singolo router addestrato di operare a molteplici punti di budget con controllo del costo atteso marginale, eliminando la necessità di riaddestrare per diversi vincoli di budget.
3. Trade-off Empirici di Recupero: Lo studio fornisce prove empiriche che il recupero economico e l'escalation del modello esibiscono pattern di successo complementari (ovvero, alcuni fallimenti sono risolvibili solo da azioni economiche, altri solo dall'escalation, e altri da entrambi), formando una frontiera discreta costo-qualità.

4. Risultati Sperimentali

Il sistema è stato valutato su cinque benchmark di coding (APPS, TACO, BigCodeBench, LiveCodeBench, CodeContests) utilizzando GPT-5.4-NANO come modello economico e GPT-5.4 come modello forte.

• Efficacia del Router: Un router appreso supera significativamente le baseline a azione fissa. Il router appreso non vincolato ha raggiunto un tasso di risoluzione dell'81,7% con un costo medio di 5,51 m$, rispetto al 68,6% dell'approccio "always-escalate" con 7,22 m$.
• Complementarità: L'analisi delle azioni di successo più economiche ("oracle") ha rivelato che il 28% dei fallimenti era risolvibile solo da azioni economiche, il 45% solo dall'escalation e il 27% da entrambi. Questa eterogeneità giustifica l'uso di un router rispetto a una cascata fissa.
• Calibrazione del Budget: La frontiera calibrata tramite CRC ha dimostrato che con un budget di 2,56 m$, il sistema ha ottenuto un tasso di risoluzione del 71,7%. Questo ha superato la baseline "always-escalate" (68,6%) utilizzando solo il 35% del costo medio della strategia always-escalate.
• Baseline: Il router appreso ha superato i router basati solo su prompt (LLM zero-shot che agiscono come router) e le baseline di cascata binaria, confermando che il segnale di routing richiede l'apprendimento dai rollout piuttosto che il semplice prompt engineering.

5. Significato e Rivendicazioni

Il paper sostiene che trattare i fallimenti del coding come un problema di riparazione diagnosticabile piuttosto che come una semplice lacuna di capacità permette una allocazione più efficiente delle risorse. Decoupling (disaccoppiando) l'addestramento del router dal budget di deployment tramite CRC, il sistema offre un meccanismo pratico per il controllo del budget durante l'inferenza.

Gli autori sottolineano che il loro approccio non pretende di controllare il tasso di risoluzione in modo conforme; piuttosto, fornisce una garanzia sul costo, mentre i miglioramenti del tasso di risoluzione rimangono osservazioni empiriche. Il lavoro suggerisce che per gli agenti di coding, il "passaggio successivo utile più economico" non è spesso il modello più forte, ma un'azione di recupero specifica adattata alla modalità di fallimento, e che questa decisione può essere presa dinamicamente sotto rigorosi vincoli di budget.

Limitazioni notate dagli autori:

• Il recupero è modellato come una singola decisione post-fallimento, mentre i veri agenti possono iterare su più round.
• L'etichetta "più economico e di successo" è una proxy e non una stima di probabilità calibrata.
• Il CRC controlla il costo atteso, non il tasso di risoluzione, il che significa che i miglioramenti della qualità rimangono osservazioni empiriche.