Chain of thought e Tree of Thoughts: quando serve un albero

Nel confronto con il chain of thought, il prompting Tree of Thoughts giustifica le chiamate aggiuntive al modello quando è possibile valutare le soluzioni parziali prima di completarle. Anche una ricerca limitata può portare da una soluzione di riferimento con 1 chiamata a 21 chiamate, come mostra il budget esemplificativo più avanti. Conviene partire da un modello di ragionamento e aggiungere ramificazioni solo per gli errori che la ricerca può risolvere.

Fonti verificate il 24 ottobre 2026. I risultati dei benchmark riportati qui provengono esclusivamente dallo studio originale del 2023 di Shunyu Yao e colleghi. I rami dell'esempio e i budget delle chiamate al modello sono calcoli a scopo illustrativo, non risultati misurati in produzione.

Tree of Thoughts: come funziona l’albero dei pensieri

Tree of Thoughts (ToT) permette a un'applicazione di confrontare soluzioni ancora incomplete e scegliere su quali continuare a lavorare. Un modello linguistico di grandi dimensioni, o LLM, propone i passi successivi; un valutatore esamina gli stati risultanti; una procedura di ricerca decide quali conservare, espandere o abbandonare. Yao e colleghi hanno presentato questo framework nel maggio 2023. Il metodo nello studio originale.

Si può immaginare di dover trovare un percorso dentro un edificio. A un bivio, è possibile esaminare più corridoi prima di sceglierne uno. Un corridoio bloccato non dovrebbe più assorbire risorse. Un percorso plausibile resta disponibile mentre se ne esplora un altro. Il vantaggio sta nel poter cambiare direzione quando farlo costa ancora poco.

Un pensiero, o thought, è un'unità utile di lavoro intermedio: un'equazione, una parola proposta per un cruciverba o una scaletta di scrittura. Uno stato registra il problema iniziale e la soluzione parziale costruita fino a quel momento. L'unità deve essere abbastanza ampia da poter essere valutata, ma abbastanza piccola da rendere utile il confronto con altre possibilità.

Il ciclo comprende tre operazioni osservabili:

• Ramificare: proporre passi successivi distinti a partire dallo stato corrente.
• Valutare: verificare ogni stato risultante rispetto ai vincoli e alla possibilità di arrivare a una risposta valida.
• Potare: smettere di espandere gli stati scartati e dedicare il budget rimasto ai candidati più promettenti.

Lo studio combina queste operazioni con la ricerca in ampiezza, che mantiene i candidati promettenti di uno stesso livello, e con la ricerca in profondità, che segue un ramo e può tornare indietro se quel percorso fallisce. La procedura va scelta in base al compito. Nessuna delle due richiede di addestrare un nuovo modello. Framework e algoritmi di ricerca.

Per chi sviluppa, il cambiamento essenziale è poter controllare le alternative intermedie. Chiedere al modello di sembrare riflessivo non dà all'applicazione questo controllo.

Chain of thought e Tree of Thoughts: che cosa cambia?

La differenza sta nel momento in cui si confrontano le alternative: durante la costruzione di una soluzione oppure dopo aver prodotto risposte complete.

È la distinzione descritta nelle sezioni introduttive e metodologiche di Yao e colleghi. La self-consistency standard campiona catene complete e sceglie la risposta più frequente. Serve quindi un criterio sensato per riconoscere risposte equivalenti: votare su un testo libero è meno immediato che votare su un risultato numerico.

Il chain of thought prompting può aiutare a esplicitare il lavoro intermedio. La self-consistency introduce varietà fra i tentativi completati. ToT aggiunge un controllore capace di fermare un percorso debole prima di sostenere il costo necessario a finirlo. Quel controllore introduce anche un nuovo tipo di errore: scartare un percorso che avrebbe portato alla soluzione.

Due tecniche affini rispondono a esigenze diverse. Il few-shot prompting fornisce esempi del comportamento o del formato di output desiderato, e può quindi aiutare un generatore o un valutatore a rispettare le proprie specifiche. Il prompt chaining collega fasi successive, per esempio l'estrazione dei fatti e la stesura di una risposta. Una sequenza fissa di fasi diventa una ricerca solo quando mantiene più alternative e decide quali esplorare.

Conviene usare la struttura più semplice in grado di risolvere il problema. Un formato incoerente richiede esempi più chiari o controlli di validazione. La mancanza di elementi a sostegno della risposta richiede il recupero di informazioni. Nessuno dei due casi richiede automaticamente un albero.

Un esempio pratico: ramificare, valutare e potare

Un'equazione intermedia corretta può comunque portare a un vicolo cieco. È questa la distinzione che il valutatore deve saper riconoscere.

Prendiamo l'esempio del Gioco del 24 usato nello studio: utilizzare 4, 9, 10 e 13, ciascuno esattamente una volta, con le operazioni aritmetiche di base per ottenere 24. L'esempio seguente è costruito per illustrare il meccanismo; non è la trascrizione di un'interazione con un modello. Gli stati risolvibili e quelli impossibili sono stati verificati enumerando le combinazioni aritmetiche rimanenti. Dati dell'esempio nello studio.

1. 1

   Generare i rami dallo stato iniziale

   Il candidato A calcola 4 + 9 = 13, lasciando 10, 13, 13.

   Il candidato B calcola 13 - 9 = 4, lasciando 4, 4, 10.

   Entrambi i calcoli rispettano le regole. I numeri ripetuti rappresentano valori residui distinti: lo stato deve conservarne la molteplicità.

2. 2

   Valutare gli stati ottenuti

   Il candidato A non può arrivare a 24 usando una sola volta ciascun valore rimasto con addizione, sottrazione, moltiplicazione o divisione. Va scartato.

   Il candidato B ammette una continuazione valida: sottrarre uno dei 4 rimasti da 10, poi moltiplicare per l'altro 4. Va mantenuto.

   Questo esempio usa una verifica aritmetica esatta per rendere controllabile il giudizio. La ricerca dello studio usava invece stime di valore prodotte dal modello, che possono essere errate.

3. 3

   Espandere il ramo mantenuto

   Da 4, 4, 10, si possono considerare 4 + 4 = 8, che lascia 8, 10, oppure 10 - 4 = 6, che lascia 4, 6.

   Il primo stato non può raggiungere 24 con l'operazione rimasta. Il secondo sì: 4 × 6 = 24. Si mantiene questa continuazione e si verifica l'espressione completa.

4. 4

   Verificare la risposta finale

   (13 - 9) × (10 - 4) = 24 usa una sola volta ogni numero iniziale e dà il risultato richiesto. La ricerca termina perché il risultato supera la verifica prevista dal compito.

Per un rompicapo così piccolo, un risolutore esaustivo può svolgere l'intero lavoro: aggiungere un LLM sarebbe una complicazione inutile. L'esempio serve a spiegare il ciclo. In un'applicazione, spesso è utile affidare al modello la proposta di piani plausibili e al codice la verifica dei vincoli, senza affidarla alle congetture del modello.

Quali risultati riporta lo studio su Tree of Thoughts?

I risultati originali mostrano che una ricerca deliberata ha aiutato nei compiti scelti dagli autori. Non stabiliscono quale miglioramento ci si debba aspettare oggi in un carico di lavoro in produzione.

Per il Gioco del 24, gli autori hanno valutato GPT-4 su 100 problemi relativamente difficili. Gli esperimenti si sono svolti nel maggio 2023. La Tabella 2 riporta questi tassi di successo:

Fonte: Yao e colleghi, Tabella 2 e configurazione del Gioco del 24.

L'ampiezza è il numero di stati mantenuti, non il numero di chiamate al modello. Generare e valutare i candidati richiede lavoro aggiuntivo. Nella configurazione del Gioco del 24, gli autori hanno campionato tre volte il valore di ciascun candidato. Configurazione sperimentale.

Lo studio ha esaminato anche compiti di scrittura creativa e mini cruciverba. Sono attività diverse, valutate con metodi diversi. La conclusione pratica è più circoscritta di «ToT migliora i modelli»: la ricerca può essere utile quando la scelta di una direzione intermedia promettente conta ed è possibile valutarla. Prima di aggiungere il controllore, chi sviluppa deve comunque raccogliere riscontri sul proprio carico di lavoro.

Quante chiamate al modello aggiungono le ramificazioni?

Generazione, valutazione e finalizzazione vanno conteggiate separatamente. Il valutatore può richiedere più chiamate del generatore di candidati.

Consideriamo una ricerca con limiti prefissati, a scopo illustrativo e indipendente dalla configurazione dello studio. Per chiamata si intende una richiesta al modello inviata dall'applicazione. Supponiamo che una sola chiamata generi tutti i figli di un nodo padre, mentre ciascun figlio riceva una propria chiamata di valutazione. La ricerca si ferma alla profondità scelta, senza nuovi tentativi né uscite anticipate; un'ultima chiamata produce poi la risposta.

Si generano tre figli per ogni nodo padre espanso, si mantengono due stati dopo ogni livello e si procede per tre livelli. I nodi padre espansi sono rispettivamente 1, 2 e 2. Quindi:

• Generazione: 1 + 2 + 2 = 5 chiamate.
• Valutazione: 3 × (1 + 2 + 2) = 15 chiamate.
• Risposta finale: 1 chiamata.
• Totale: 5 + 15 + 1 = 21 chiamate, cioè 21× rispetto al riferimento con 1 chiamata.

Ripetendo tre volte la valutazione di ciascun candidato, lo stesso albero richiede 5 + 45 + 1 = 51 chiamate. Raggruppando invece tutte le valutazioni dei candidati di ogni livello in un'unica richiesta, si arriva a 5 + 3 + 1 = 9 chiamate. Il raggruppamento modifica il contesto del valutatore e le condizioni in cui giudica: è una scelta implementativa, non una garanzia di qualità equivalente.

Per confronto, la self-consistency con cinque campioni richiesti separatamente usa cinque chiamate al modello quando il voto finale è gestito da codice deterministico. Un ulteriore modello con funzione di giudice aggiungerebbe chiamate e cambierebbe il confronto.

La regola generale di conteggio è C = Σ nₜ(g + kv) + f. Qui nₜ è il numero di nodi padre espansi al livello t, g il numero di richieste di generazione per nodo padre, k il numero di figli per nodo padre, v il numero di richieste di valutazione per figlio e f il numero di richieste di finalizzazione. La formula presuppone valutazioni separate per ciascun figlio; quando le si raggruppa, occorre conteggiare direttamente le richieste raggruppate.

Progettare Tree of Thoughts con un LLM: controllare la ricerca

Lo stato della ricerca e le regole di arresto devono restare nel codice dell'applicazione. Al modello spetta proporre e valutare elaborati circoscritti, che sia possibile esaminare.

Il limite decisivo di questa architettura è la qualità del valutatore. Se non sa distinguere una soluzione parziale praticabile da un vicolo cieco convincente, espandere più rami gli offre soltanto più occasioni di scegliere male.

1. 1

   Definire uno stato verificabile

   In una funzione di pianificazione soggetta a vincoli, lo stato potrebbe contenere le attività assegnate, quelle ancora da assegnare, le fasce orarie occupate e i vincoli non soddisfatti. Il pensiero successivo può essere definito come una proposta di assegnazione. Stato, identificativo del candidato, identificativo del nodo padre ed elementi a sostegno della proposta vanno memorizzati separatamente.

   Occorre scegliere un elaborato che si possa verificare nella fase corrente. È difficile potare in modo affidabile un paragrafo generico che si limita a descrivere una buona strategia.

2. 2

   Assegnare compiti diversi a generazione e valutazione

   Un'istruzione per il generatore può essere: «Proponi assegnazioni successive distinte a partire da questo stato. Per ogni candidato, restituisci l'assegnazione e lo stato aggiornato. Rispetta i vincoli elencati».

   Un'istruzione per il valutatore può essere: «Verifica ogni candidato rispetto ai vincoli. Restituisci il suo identificativo, gli eventuali vincoli violati e indica se la continuazione è fattibile, incerta o esclusa. Cita i campi dello stato su cui si basa il giudizio».

   Per regole come la sovrapposizione di fasce orarie o la presenza di campi obbligatori, vanno usati prima controlli deterministici. Se serve il giudizio di un modello, occorre validarlo su casi noti attraverso un processo di valutazione LLM-as-a-judge.

3. 3

   Rendere espliciti potatura e budget

   Si scartano gli stati che violano un vincolo inderogabile. Si ordinano i candidati rimanenti, si mantiene un insieme limitato di stati da esplorare e si eliminano i duplicati. Quando il budget lo consente, conviene tenere disponibili i candidati incerti: una bassa confidenza del valutatore non dimostra che un ramo sia impossibile.

   Il controllore deve imporre limiti alle richieste, alla profondità, ai token e al tempo trascorso, includendo nel conteggio anche valutazioni e nuovi tentativi. Registrare che cosa è stato scartato e perché permette di esaminare i casi in cui la potatura ha eliminato il percorso risolutivo.

4. 4

   Verificare prima di accettare un risultato o agire

   Serve un controllo conclusivo: per esempio, che tutti i vincoli di pianificazione siano soddisfatti o che i test software pertinenti siano superati. Se nessun candidato soddisfa i criteri prima dell'esaurimento del budget, l'esito va segnalato come irrisolto o inviato a revisione.

   L'esplorazione dei rami deve rimanere in una sandbox o limitarsi a proposte di azione. Un ramo di pianificazione ancora ipotetico non deve inviare inviti. Un ramo dedicato al codice non deve distribuire modifiche mentre il controllore sta ancora confrontando i candidati.

Va misurata la qualità del valutatore, oltre a quella della risposta finale. Uno scarto errato può eliminare definitivamente il ramo utile. Un'accettazione errata può consumare tutto il budget rimasto nell'espansione di un vicolo cieco. Sono errori che richiedono interventi diversi.

Quando un modello di ragionamento rende ToT superfluo?

Una ricerca ToT esterna è superflua quando un modello di ragionamento soddisfa già i requisiti di qualità e latenza e l'applicazione non ha bisogno di controllare le alternative intermedie.

Un modello di ragionamento svolge lavoro interno prima di rispondere. Le indicazioni attuali di Anthropic sul prompting raccomandano di dare ai suoi modelli di ragionamento obiettivi generali, senza prescrivere ogni singolo passaggio. Questo sostiene la scelta di partire da un compito chiaro, con vincoli e criteri di accettazione. Non dimostra che uno specifico modello implementi internamente l'algoritmo ToT di Yao e colleghi. Indicazioni di Anthropic sul prompting.

Chi sviluppa una piccola trasformazione del codice dovrebbe prima provare un modello di ragionamento adatto e sottoporre il risultato ai test pertinenti. Se questa soluzione di riferimento soddisfa il criterio di rilascio, un albero esterno aggiunge gestione dello stato, valutazione e gestione degli errori senza un beneficio dimostrato.

La ricerca esterna resta un'opzione quando l'applicazione può contribuire con qualcosa in più: un simulatore, un verificatore di vincoli, ambienti di test isolati o la necessità di conservare piani candidati distinti. Un modello più potente può comunque fungere da generatore all'interno di quella ricerca. Il ragionamento del modello e la ricerca controllata dall'applicazione sono scelte progettuali separate.

La decisione dipende dai risultati osservati: l'albero va mantenuto solo se migliora gli esiti verificati abbastanza da giustificare le risorse misurate. Una risposta più lunga o una traccia più elaborata non sono il criterio di successo.

Tree of Thoughts: quali promesse sono eccessive?

Un prompt che chiede a esperti immaginari di discutere non realizza, da solo, una ricerca ad albero controllata. Può produrre alternative, ma un'implementazione ToT in produzione richiede uno stato esplicito, una valutazione, una selezione dei rami e regole di arresto. Se tutto questo esiste soltanto all'interno di un unico completamento, non si può presumere che la ricerca descritta sia stata eseguita come previsto.

L'altra esagerazione è che più rami garantiscano una risposta migliore. I rami possono ripetere la stessa idea. Il giudice può condividere un presupposto errato del generatore. Una potatura precoce può eliminare l'unica continuazione utile. Esprimere sicurezza non sostituisce la verifica del compito.

Infine, il miglior risultato dello studio sul Gioco del 24 non dimostra che ogni workflow aziendale abbia bisogno di ToT. Un estrattore di documenti con un output non conforme allo schema può aver bisogno di esempi e controlli migliori. A un assistente di supporto che non dispone di una determinata policy può servire la fonte giusta. Esplorare più percorsi partendo dalla stessa carenza di informazioni non fa comparire il dato mancante.

La ricerca serve a confrontare decisioni alternative che si possono valutare. Le lacune di contesto e il mancato rispetto delle specifiche vanno risolti direttamente.

Che cosa cambiare questa settimana nella propria applicazione

Conviene intervenire subito se i casi falliti contengono scelte iniziali correggibili e si dispone di un modo credibile per valutare gli stati intermedi. Ne sono esempi le modifiche candidate al codice verificate in ambienti isolati o i piani controllati rispetto a vincoli espliciti di pianificazione. Si può iniziare con un percorso limitato a questi casi e un budget di ricerca fisso.

È meglio aspettare se non si sa ancora spiegare perché una soluzione parziale sia migliore di un'altra. Occorre costruire un insieme di stati accettabili e inaccettabili, verificare le decisioni del valutatore e migliorare quel giudizio prima di allargare l'albero.

Se il workflow consiste in una semplice estrazione, una classificazione o una sequenza fissa che soddisfa già i criteri di accettazione, cambia poco. Conviene mantenerne la struttura più semplice.

Il primo intervento del lunedì è concreto: prendere i casi falliti nell'attuale workflow chain-of-thought e confrontare un modello di ragionamento di riferimento con una variante ToT a ricerca limitata, sugli stessi compiti tenuti da parte per la valutazione. Il verificatore finale deve restare invariato. Vanno registrati gli esiti accettati, le chiamate al modello, i token, la latenza e i casi in cui la potatura ha eliminato un percorso risolutivo. La ricerca va adottata solo per il sottoinsieme di compiti in cui questi risultati ne giustificano l'uso.

Domande frequenti su Tree of Thoughts

Ragionamento e chain-of-thought sono la stessa cosa?

Il ragionamento è la capacità più ampia di affrontare un problema. Il chain-of-thought è un approccio al prompting che usa passaggi intermedi. Un modello può ragionare internamente senza mostrare quei passaggi nella risposta.

Che cos'è un albero nell'intelligenza artificiale?

Un albero rappresenta stati e possibili azioni successive. Un nodo è uno stato e i suoi figli sono le alternative raggiunte compiendo un altro passo. In ToT, questi stati rappresentano soluzioni parziali.

Che cosa si intende per albero di ragionamento?

In questo contesto significa organizzare soluzioni parziali alternative in rami, valutarle e scegliere quali proseguire. Il framework specifico di Yao e colleghi si chiama Tree of Thoughts.

Che cos'è il prompting Tree of Thoughts?

Usa un modello linguistico per proporre e valutare alternative intermedie, insieme a una procedura di ricerca che seleziona gli stati da espandere. Il vantaggio pratico è poter riconsiderare una decisione prima di completare l'intera risposta.

Quali sono le tre C del prompting?

L'algoritmo ToT di Yao e colleghi non definisce una regola delle tre C. Quel promemoria non ne costituisce la specifica: lo studio descrive la scomposizione in pensieri, la generazione, la valutazione degli stati e la ricerca.

Quali sono le differenze principali tra chain of thought e tree of thought?

Il CoT standard produce un unico percorso continuo di ragionamento. ToT considera esplicitamente percorsi parziali alternativi e li valuta durante la ricerca. La self-consistency segue ancora un'altra logica: campiona percorsi completi e aggrega le risposte finali.

Qual è un esempio di chain of thought prompting?

Una dimostrazione aritmetica svolta può mostrare 13 - 9 = 4, poi 10 - 4 = 6, infine 4 × 6 = 24. Fornire questi passaggi intermedi come esempio illustra il CoT. Confrontare passaggi alternativi e decidere quale ramo mantenere aggiunge il meccanismo di ricerca ToT.

Che cos'è il chain-of-thought in parole semplici?

Collega una domanda alla sua risposta attraverso passaggi intermedi, come calcoli o deduzioni. Questi passaggi possono rendere il compito più facile da seguire, ma possono comunque contenere errori.

Come funziona concretamente il chain-of-thought?

Nella configurazione standard di prompting, un modello genera una sequenza di passaggi intermedi condizionata dal problema e dal testo già generato, poi produce una risposta. Da sola, quella sequenza non fornisce né un controllo indipendente della correttezza né un insieme di stati da esplorare gestito dall'applicazione.

Iscriviti alla newsletter per guide pratiche su come costruire workflow AI affidabili.