Nessun trucco vince da solo. La più economica: ritenta

Gli LLM sono dadi, non calcolatrici. Fai la stessa domanda allo stesso modello due volte e puoi ottenere due risposte diverse, perché sotto il cofano sta campionando un percorso in uno spazio di probabilità, non cercando un fatto. La maggior parte delle volte quel non determinismo è una seccatura che cerchi di eliminare a forza di ingegneria. Quando costruisci un agente che continua a farsi rifiutare da un filtro di sicurezza, si rivela lo strumento più economico che hai.

Il lavoro che fa SwarmAttacker è offensivo per natura, quindi il classificatore di sicurezza del modello a volte rifiuta una richiesta perfettamente autorizzata, e un rifiuto blocca l'agente a metà esecuzione. Abbiamo passato molto tempo su una sola domanda: quando il modello dice no, cosa lo porta davvero a dire sì?

Nessun singolo trucco vince

Abbiamo preso i casi difficili: 411 richieste già rifiutate una volta, e le abbiamo riprodotte una per una attraverso quattro interventi diversi su GPT-5.5. L'idea era trovare l'unica tecnica ingegnosa che rompe un rifiuto in modo affidabile. Non esiste.

Vestire la richiesta con del contesto l'ha fatta passare il 52% delle volte, che rientra nel rumore del non fare nulla. Dire al modello che si trattava di un engagement autorizzato ha aiutato di più, 68%, ma quel guadagno è fragile: si sposta molto a seconda del modello, e abbiamo scritto sul perché travestire il prompt non funziona in modo affidabile. L'unico intervento che ha sbloccato tutto è stato passare a un modello più permissivo, che per definizione funziona il 100% delle volte. Non esiste una frase magica. La mossa vincente è impilare qualche tentativo economico e tenere una rete di sicurezza garantita alla fine.

Perché riprovare e basta una richiesta LLM rifiutata funziona?

Guarda di nuovo la barra evidenziata. Rimandare esattamente la stessa richiesta rifiutata, invariata, senza alcun trucco, l'ha sbloccata circa il 54% delle volte. Poco più della metà delle richieste che si erano già sentite dire no è passata con un semplice retry, per la semplice ragione che il modello campiona un percorso diverso la seconda volta.

Un rifiuto non è un verdetto. È un lancio di dadi, e ti è permesso lanciare di nuovo.

Ecco perché riprovare non è il ripiego noioso a cui ricorri dopo che le idee ingegnose hanno fallito. Su un sistema non deterministico è la mossa con il rendimento più alto. Costa una chiamata in più e batte ogni tecnica di prompt che abbiamo provato, tranne il cambio di modello.

Riprova un paio di volte, poi fai escalation

Il problema è che il retry decade in fretta. Ogni tentativo aggiuntivo lavora sulle richieste che i tentativi precedenti non sono riusciti a salvare, quindi le probabilità peggiorano a ogni giro.

Il primo retry ha recuperato il 31% delle richieste che ha visto; il secondo solo il 16%. La lezione non è «riprova all'infinito», è «riprova due volte, poi fai escalation». In produzione lo abbiamo cablato in una piccola scala di escalation: retry sullo stesso modello, un altro retry, poi passa la richiesta a un modello più permissivo. Su 598 rifiuti in un'esecuzione completa, quella scala li ha risolti tutti. Nessuno ha lasciato l'agente bloccato.

Un avvertimento onesto su quel 54%

Dobbiamo essere chiari su una cosa. Quel «circa il 54% funziona semplicemente con un retry» è una misura fatta in replay, in un secondo momento. Durante le esecuzioni live originali, la stessa coda difficile di richieste rifiutate si sbloccava solo per circa il 16% con un semplice retry, stesso modello, stesse richieste. Da parte nostra non era cambiato nulla. Il classificatore di sicurezza è semplicemente diventato molto più permissivo tra l'esecuzione live e il replay.

Quindi non ancorarti al numero esatto. Il rendimento del retry oscilla molto a seconda dell'umore del classificatore in un dato giorno. Ciò che resta vero in entrambe le misurazioni è la forma: una fetta significativa dei rifiuti evapora con un reinvio gratuito, e il cambio di modello è la rete di sicurezza che chiude sempre il divario.

Cosa significa se stai costruendo un agente

La lezione pratica è più piccola di quanto sembri e facile da integrare:

• Tratta un rifiuto o un cattivo risultato di uno strumento come un lancio di dadi, non come un muro. Prima di ricorrere a una riscrittura del prompt, riprova e basta.
• Metti i retry nel loop per primi. Sono la cosa con il ROI più alto che puoi aggiungere e ti costano una chiamata in più.
• Limita i retry e fai escalation. Due tentativi sullo stesso modello, poi salta a uno più permissivo. Non ciclare all'infinito inseguendo un rendimento che decade.

Il prompt engineering riceve tutta l'attenzione, ma su un modello frontier attuale è spesso la leva che si muove appena. Se sei curioso di sapere quanto poco valesse davvero l'impalcatura ingegnosa, è una storia a sé: i prompt sono morti? La leva più grande e più stupida è semplicemente lasciare che il modello riprovi.