Chain-of-thought e ragionamento esplicito

Chiedere a un modello di “ragionare passo passo” può migliorare task complessi, ma non è una soluzione universale. A volte produce risposte più lente, più lunghe e più difficili da valutare. In alcuni casi è meglio chiedere una sintesi della motivazione, non tutto il ragionamento.

Perché questa lezione conta

Gli sviluppatori usano LLM per debugging, decisioni di design, analisi di trade-off e trasformazioni di codice. Sono task in cui il ragionamento conta. Ma il valore non sta nel vedere molti passaggi: sta nell’ottenere una decisione verificabile.

La domanda giusta è: quale parte del ragionamento deve essere visibile per permettere review e correzione?

Quando serve ragionamento esplicito

Serve quando:

• il task ha più passaggi dipendenti;
• ci sono trade-off reali;
• vuoi far emergere assunzioni;
• vuoi confrontare alternative;
• il rischio di saltare un caso limite è alto;
• la spiegazione serve a una persona che dovrà mantenere la decisione.

Esempio:

Valuta tre strategie per gestire cache e invalidazione.
Per ciascuna indica assunzioni, rischio principale, costo di implementazione e test necessari.
Chiudi con una raccomandazione motivata.

Qui non chiedi “pensa passo passo” in modo generico. Chiedi una struttura di ragionamento utile.

Quando evitarlo

Evitalo quando:

• il task è meccanico;
• vuoi output breve e parsabile;
• il formato è più importante della spiegazione;
• stai facendo classificazione semplice;
• il costo o la latenza sono critici;
• il ragionamento visibile rischia di confondere il revisore.

Esempio:

Estrai JSON conforme allo schema. Non includere spiegazioni.

In questo caso il ragionamento deve restare fuori dall’output: lo controllerai con validazione e test.

Ragionamento visibile vs motivazione

Non sempre devi chiedere tutti i passaggi. Spesso basta una motivazione breve:

Restituisci:
1. decisione;
2. motivazione in massimo 5 righe;
3. assunzioni;
4. verifiche da eseguire.

Questa forma è più utile in contesti professionali: lascia traccia della decisione senza trasformare la risposta in un saggio.

Esempio operativo

Prompt debole:

Pensa passo passo e trova il bug.

Prompt migliore:

Analizza il bug senza proporre subito una patch.

Restituisci:
1. sintomo osservato;
2. massimo 3 ipotesi;
3. prova minima per falsificare ogni ipotesi;
4. quale ipotesi controllare per prima e perché;
5. dati mancanti.

Non modificare codice in questa fase.

Il secondo prompt non chiede ragionamento generico. Chiede un ragionamento utile per il debug.

Laboratorio guidato

Scegli tre task:

1. uno semplice, come classificare una issue;
2. uno medio, come scegliere tra due refactor;
3. uno complesso, come diagnosticare una regressione intermittente.

Per ciascuno prova:

• prompt senza ragionamento;
• prompt con “ragiona passo passo”;
• prompt con struttura di motivazione controllata.

Misura:

• qualità della decisione;
• lunghezza;
• facilità di verifica;
• presenza di assunzioni;
• tempo necessario per usare la risposta.

Output atteso

Una guida quando-sì/quando-no per chiedere ragionamento esplicito nel tuo dominio.

Esempio:

Sì: decisioni architetturali, debug multi-causa, trade-off costo/qualità.
No: estrazione JSON, classificazioni semplici, output da parser, risposte in UI.
Forma preferita: decisione + motivazione breve + assunzioni + verifiche.

Checklist di verifica

• non uso “pensa passo passo” come abitudine automatica;
• scelgo quanto ragionamento mostrare in base al task;
• chiedo assunzioni e verifiche quando il ragionamento conta;
• tengo output parsabile quando serve;
• so distinguere spiegazione utile e verbosità.

Collegamenti

• Modulo: Tecniche di prompting — lezione 12 del corso.
• Lezione precedente: Zero-shot, one-shot, few-shot.
• Prossima lezione: Self-critique, self-consistency, rephrase.