Immagina di chiedere al commercialista quanto hai speso davvero in spedizioni nell’ultimo trimestre. Non esiste un foglio con quel numero già pronto: la risposta va costruita. Una parte è in un file di fatture, un’altra in una cartella di ricevute, una regola sulle commissioni sepolta in una mail. Qualcuno deve aprire i documenti, incrociarli, fare i conti — e, soprattutto, decidere quando ha fatto abbastanza. Perché a differenza di un problema di matematica, qui non c’è la soluzione in fondo al libro con cui confrontarsi. Proprio quest’ultima parte, sapere quando l’analisi è finita, è il nodo che un gruppo di ricercatori di Google Cloud e KAIST prova a sciogliere in DS-STAR, un agente descritto in un paper di ottobre 2025.
Il codice che gira non è il codice che risponde
Da un paio d’anni si costruiscono agenti per la data science: modelli linguistici che, data una domanda e una cartella di dati, scrivono ed eseguono codice Python fino a produrre una risposta. Funzionano, ma con due debolezze che gli autori chiamano per nome. La prima riguarda i dati. La maggior parte di questi agenti è tarata su tabelle ben ordinate, i file CSV, eredità della tradizione text-to-SQL. Il mondo reale è più sporco: JSON, markdown, testo libero, fogli Excel. Su formati eterogenei questi sistemi arrancano.
La seconda debolezza è più sottile, e più interessante. Molti agenti si fermano appena il codice viene eseguito senza errori. Ma codice che gira non è codice che risponde giusto: un programma può calcolare diligentemente la cosa sbagliata. Senza una soluzione corretta da confrontare — e nelle domande aperte quella soluzione non esiste — l’agente non ha modo di sapere se il suo piano bastava. Così si accontenta del primo che funziona, e adotta un piano subottimale. DS-STAR nasce per rimettere al centro la domanda che questi agenti saltano: ho davvero risposto?
Due tempi: catalogare, poi costruire un passo alla volta
DS-STAR è un sistema di più agenti specializzati, ciascuno un modello linguistico con un compito preciso. Lavora in due tempi.
Nel primo, un agente analyzer apre ogni file della cartella e ci scrive sopra una scheda: che colonne contiene, che tipi di dato, un riassunto se è testo libero. È il gesto di chi, prima di iniziare, cataloga cosa c’è in ogni cassetto invece di tuffarsi alla cieca. Il passaggio è parallelizzabile — un file, una scheda — e serve a dare al resto del sistema un contesto anche su dati che non sono affatto tabellari, dove il concetto stesso di «riga da mostrare» non ha senso.
Nel secondo tempo comincia il ciclo vero e proprio, ed è qui l’idea centrale. Formalmente il compito è una ricerca: tra tutti gli script possibili $\mathcal{S}$, trovare quello che massimizza la correttezza dell’output,
$$s^* = \arg\max_{s \in \mathcal{S}} h\big(s(D)\big),$$
dove $D$ sono i dati e $h$ misura quanto la risposta è giusta. Il problema è che $h$, nella pratica, non si può calcolare: manca l’etichetta corretta. DS-STAR la sostituisce con un giudizio.
Il ciclo procede come un analista che lavora in un notebook Jupyter, una cella alla volta, guardando ogni risultato prima di scrivere il prossimo. Un agente planner propone un primo passo semplice ed eseguibile — spesso solo «carica il file». Un agente coder lo traduce in Python, il codice viene eseguito, si ottiene un risultato. A questo punto entra il pezzo nuovo: un agente verifier, un modello usato come giudice, guarda il piano, la domanda, il codice e il risultato, e risponde a una sola domanda binaria — questo piano basta a rispondere? — con l’operazione $v = A_{\text{verifier}}(p, q, s_k, r_k)$. Non confronta soltanto il piano con la domanda: guardando anche il codice e ciò che ha prodotto, il giudizio è più ancorato ai fatti.
Se il verdetto è «sufficiente», il codice accumulato diventa la soluzione finale e ci si ferma. Se è «insufficiente», interviene un agente router che decide come procedere, con $w = A_{\text{router}}(p, q, r_k, \{d_i\})$: aggiungere un passo nuovo, oppure — se un passo precedente era sbagliato — tornare indietro. E qui c’è una scelta di design controintuitiva. Invece di correggere chirurgicamente il passo difettoso, DS-STAR lo cancella insieme a tutti quelli successivi e li rigenera da capo. Gli autori lo spiegano con un’osservazione empirica: aggiustare un singolo passo tende a produrre una toppa sempre più contorta, che il router al giro dopo ribolla come difettosa. Meglio potare il ramo e ricrescerlo. Il tutto si ripete fino al via libera del verifier o fino a un tetto di 20 iterazioni.
Il primo passo è catalogare i file. Poi planner, coder e verifier girano in cerchio: si esce solo quando il verifier dà il via libera; altrimenti il router aggiunge un passo o taglia quello sbagliato e il planner ricomincia da lì.
I numeri, senza arrotondare a proprio favore
Gli autori misurano DS-STAR, con Gemini 2.5 Pro come modello di base, su tre benchmark pensati apposta per essere difficili. Su DABStep, che costringe a incrociare sette file in formati diversi, il salto è vistoso sui compiti «hard», quelli che richiedono più file: dal 12,70% del solo modello Gemini al 45,24% di DS-STAR, oltre trenta punti percentuali. Va detto con onestà, però, che rispetto al miglior agente concorrente sullo stesso benchmark — un sistema commerciale fermo al 41,01% — il margine si assottiglia a circa quattro punti. Sugli altri due benchmark i guadagni sono più contenuti: su KramaBench il totale passa dal 39,79% al 44,69%, su DA-Code dal 37,0% al 38,5% complessivo. Anche qui, però, sui compiti più duri di DA-Code lo stacco resta netto: dal 32,0% al 37,1%. Il quadro è coerente: DS-STAR guadagna poco quando la domanda è semplice e molto quando bisogna orchestrare più file eterogenei.
Le prove di smontaggio dicono quali pezzi contano davvero. Togliere l’analyzer fa crollare l’accuratezza sui compiti hard di DABStep dal 45,24% al 26,98%: capire i file prima di toccarli è metà del lavoro. Togliere il router — cioè rinunciare a tornare sui propri passi e limitarsi ad accumulare — porta al 39,95%: correggere gli errori conta più che impilare passi buoni sopra passi cattivi. E i numeri sul ciclo confermano l’intuizione dell’incipit: un compito facile si risolve in media in 3 iterazioni, e più della metà con il primo piano soltanto; un compito difficile ne chiede in media 5,6, e il 98% richiede almeno una correzione.
Il pezzo nuovo non è un modello più bravo, ma una domanda resa esplicita: «ho finito?», ripetuta a ogni passo e affidata a un giudice separato.
Quel che il paper non nasconde
La qualità si paga. Ogni task costa in media 0,23 dollari contro gli 0,09 dei metodi più semplici — circa due volte e mezzo — e consuma più del triplo dei token in ingresso, perché ogni giro rilegge piano, codice e risultati. Su volumi di analisi ripetute non è un dettaglio.
C’è poi un collo di bottiglia dichiarato: trovare i file giusti quando la cartella è enorme. Su KramaBench, dove un dominio contiene oltre 1.500 file e solo pochi sono rilevanti per una domanda, dare a DS-STAR direttamente i file corretti (la condizione che gli autori chiamano «oracolo») ne alza l’accuratezza di otto punti. Segno che una fetta degli errori non sta nell’analisi, ma nel decidere cosa analizzare. Un limite più generale, che gli autori non nascondono ma che vale la pena ricordare: il verifier è a sua volta un modello linguistico senza verità di riferimento. Giudica la plausibilità di un piano, non la sua correttezza dimostrata. È un giudice fallibile che ne sorveglia un altro, e i test sono condotti in casa Google con i modelli di casa Google. La strada indicata per il futuro è rimettere l’umano nel ciclo, affiancando l’automazione all’intuizione di un esperto.
Perché conta
Ciò che rende DS-STAR interessante non è un modello più intelligente: sotto c’è lo stesso Gemini che, da solo, sui compiti difficili si ferma al 12,70%. È il processo che gli sta intorno. La differenza la fa una domanda che di solito diamo per scontata — «ho finito?» — resa esplicita, ripetuta a ogni passo e affidata a un giudice separato invece che all’entusiasmo di chi ha appena visto girare il proprio codice. Man mano che deleghiamo agli agenti analisi destinate a orientare decisioni reali, quel «ho finito?» smette di essere un dettaglio ingegneristico e diventa la domanda che conta. DS-STAR non la risolve del tutto. Ha però il merito di trattarla come il problema, invece di far finta che il codice che gira sia già la risposta.
Il paper
Jaehyun Nam, Jinsung Yoon, Jiefeng Chen, Tomas Pfister, DS-STAR: Data Science Agent via Iterative Planning and Verification, Google Cloud e KAIST, ottobre 2025. Disponibile su arXiv: arxiv.org/abs/2509.21825.
I commenti sono riservati agli iscritti.
Accedi per commentare