Introduzione a ThinkingBox e al suo scopo
ThinkingBox è stato concepito per valutare il lavoro di un agente confrontando lo stato finale di un database con l’esito atteso. Il sistema, inizialmente pensato come grader, è stato successivamente trasformato in una funzione di ricompensa per il reinforcement learning (RL) su compiti al di fuori del benchmark ThinkingBox‑Bench. Il codice è ora disponibile su GitHub, consentendo a ricercatori e sviluppatori di riprodurre e ampliare gli esperimenti.
Nel primo post del blog, intitolato “The Agent Said It Was Done. The Database Disagreed”, abbiamo mostrato come un modello potesse dichiarare completato un ticket cliente, mentre in realtà una eccezione del corriere rimaneva aperta. Nove chiamate a strumenti sembravano corrette, ma una riga di database era sbagliata.
Da grader a ricompensa: la logica di ThinkingBox
Ogni task di ThinkingBox‑Bench (507 in totale) fornisce all’agente un backend reale e un set di strumenti (MCP). Dopo che l’agente ha operato, il sistema verifica le modifiche effettive nel database. Per la maggior parte dei compiti, un semplice controllo eseguibile restituisce 1 (successo) o 0 (fallimento) dallo stato terminale del database. Questo output binario può essere usato direttamente come ricompensa RL.
Il passaggio chiave è stato selezionare quali task fossero adatti all’addestramento. Molti compiti erano già risolti dal modello di base o, al contrario, troppo difficili per fornire un segnale di apprendimento utile. Abbiamo introdotto il concetto di “difficoltà relativa alla politica offline”: una misura della probabilità di successo di un task stimata con la politica di partenza, mantenuta fissa per tutta la fase di training.
Costruzione del pool di allenamento
- Stima della probabilità di successo di ciascun task con la politica di base.
- Selezione dei task con probabilità intermedia, né troppo alta né troppo bassa.
- Creazione di un pool statico di compiti da utilizzare per 50 passi di GRPO.
Questa strategia ha permesso di focalizzare l’addestramento su esempi che potevano effettivamente migliorare la policy, evitando sia il “over‑fitting” a casi già risolti sia il “rumore” di compiti irrisolvibili.
Metodologia di valutazione
Per valutare le prestazioni, ogni task del benchmark è stato eseguito 20 volte. Sono state calcolate tre metriche principali:
- pass@1: percentuale media di successi su tutti i 10.140 tentativi (507 task × 20 esecuzioni).
- pass@20: percentuale di task risolti almeno una volta su 20 esecuzioni.
- observed 20/20: percentuale di task che hanno superato tutti i 20 tentativi.
Queste metriche consentono di distinguere tra capacità di “colpire” occasionalmente un risultato corretto (pass@20) e affidabilità costante (observed 20/20), quest’ultima cruciale per applicazioni in produzione.
Risultati prima e dopo il fine‑tuning
| Modello | pass@1 (%) | pass@20 | observed 20/20 |
|---|---|---|---|
| Qwen‑3.8‑27B (base) | 51,70 | 38 | 7,5 |
| Qwen‑3.8‑27B (GRPO 50 steps) | 60,78 | 107 | 21,1 |
Il training ha aumentato notevolmente il numero di task completati in modo ripetibile (da 38 a 107), con un leggero calo nella copertura “almeno una volta”. Questo fenomeno, noto come “sharpening”, è coerente con studi precedenti: la distribuzione di probabilità si concentra su traiettorie affidabili, sacrificando alcuni percorsi a bassa probabilità.
Esempio pratico: prenotazione alberghiera
Un task tipico richiedeva di gestire una richiesta di downgrade di camera, la cui approvazione doveva passare da un manager. Prima del fine‑tuning, l’agente modificava la prenotazione e rimborsava senza l’autorizzazione in 15 su 20 tentativi. Dopo il RL‑fine‑tuning, tutti i 20 tentativi hanno preservato lo stato corretto di prenotazione e pagamento, con 19 su 20 che corrispondevano esattamente ai record attesi.
Questo risultato dimostra come la trasformazione del grader in ricompensa possa incoraggiare il modello a rispettare regole di business più stringenti, riducendo errori critici.
Confronti con altri modelli
Nel post iniziale avevamo testato 18 modelli su ThinkingBox‑Bench. Alcuni esempi:
- Kimi‑K3: pass@20 = 93,89 % ma solo 68 task (13,41 %) hanno raggiunto 20/20.
- Claude Opus 5: alta consistenza ma copertura più ristretta.
- Claude Opus 5.5: miglioramento di 0,66 punti percentuali su pass@1, ma nessun aumento di task 20/20 (241).
Questi dati sottolineano che l’accuratezza headline (pass@1) non è sufficiente per valutare modelli destinati a operare su database di produzione; la metrica osservata 20/20 è più indicativa di affidabilità.
Analisi per dominio
Abbiamo segmentato i risultati per dominio (neobank, consulting, retail, travel, auto‑insurance). Le tendenze più rilevanti:
- Tutti i domini hanno mostrato incrementi sia in pass@1 sia in observed 20/20.
- Pass@20 è aumentato in neobank e consulting, ma è diminuito in retail, travel e auto‑insurance.
- Il più grande calo di copertura è stato nell’auto‑insurance (‑7,0 punti), mentre il retail ha registrato il maggior guadagno in observed 20/20 (+24,5 punti).
Queste variazioni riflettono come il “sharpening” possa avvantaggiare alcuni domini più strutturati rispetto a quelli con flussi più variabili.
Impatto economico della dipendenza affidabile
Nel primo post abbiamo introdotto una metrica di costo per task affidabile, calcolata come:
costo per task affidabile = (costo stimato della campagna 507 × 20) ÷ (numero di task con 20/20)
Applicando lo stesso ragionamento al checkpoint fine‑tuned, i risultati sono:
| Modello | Costo per task affidabile (USD) |
|---|---|
| Qwen‑3.8‑27B (base) | 0,177 |
| Qwen‑3.8‑27B (RLFT) | 0,139 |
| GPT‑5.4 | 0,134 |
| GPT‑6 Astra | 0,148 |
| Claude Opus 5.5 | 0,152 |
Il modello fine‑tuned raggiunge un costo per task affidabile di 0,139 $, avvicinandosi a GPT‑5.4 (0,134 $) e superando GPT‑6 Astra e Claude Opus 5.5. Questo dimostra che la strategia di reward basata sul database non solo migliora la ripetibilità, ma lo fa in modo economicamente competitivo.
Implementazione pratica
Per chi volesse replicare l’esperimento, il repository GitHub fornisce:
- Il codice per generare il pool di training usando la difficoltà relativa offline.
- Lo script di training con GRPO per 50 passi.
- Il benchmark ThinkingBox‑Bench per valutare pass@1, pass@20 e observed 20/20.
Il flusso di lavoro è riassunto nella figura 1 del post originale: i controlli eseguibili sullo stato terminale del database vengono trasformati in ricompense per l’agente, chiudendo così il ciclo di valutazione‑addestramento.
Conclusioni e prospettive future
Il passaggio da un semplice grader a una funzione di ricompensa ha dimostrato di aumentare la consistenza dei modelli LLM su compiti che modificano database reali. La crescita di observed 20/20 da 7,5 % a 21,1 % per Qwen‑3.8‑27B evidenzia un miglioramento significativo nella affidabilità operativa.
Le prossime fasi di ricerca includono:
- Espandere il pool di training con task più diversificati per mitigare la perdita di copertura in alcuni domini.
- Integrare metriche di costo‑efficacia più precise, tenendo conto di token usage e latenza.
- Esplorare metodi di curriculum learning basati sulla difficoltà relativa dinamica, aggiornando il pool di training man mano che il modello migliora.
In sintesi, ThinkingBox offre una nuova strada per addestrare agenti LLM più affidabili in contesti di produzione, trasformando la valutazione del database in una ricompensa efficace per il reinforcement learning.