Introduzione: Perché il Feedback è Diverso nell’AI

Quando si parla di raccolta di feedback, la mente va subito a sondaggi, stelline o pollici in su/giù. Ma nell’AI conversazionale il concetto si amplia: il feedback diventa una risorsa strategica, tanto importante quanto il modello stesso.

Come ricorda Chip Huyen in AI Engineering, i dati proprietari derivanti dal feedback non sono semplicemente “qualche statistica in più”: sono un asset che può determinare il successo o il fallimento di un prodotto AI, soprattutto in un contesto dove le fonti pubbliche di dati stanno diventando più scarse.

In altre parole, chi progetta un buon sistema di raccolta feedback costruisce, senza saperlo, un motore a ciclo continuo — il data flywheel — che alimenta l’evoluzione del modello e crea un vantaggio competitivo difficile da colmare.

Anatomia del Feedback Conversazionale

Feedback Esplicito vs Implicito

Feedback Esplicito

Qui parliamo di segnali chiari e diretti, che l’utente fornisce intenzionalmente:

• Valutazioni a pollice o stelle: il classico thumbs up/down o da 1 a 5 stelle, spesso usato come metrica di gradimento.
• Domande di verifica: “Abbiamo risolto il tuo problema?” o “Sei soddisfatto della risposta?” permettono di misurare la percezione di utilità.
• Comparazioni dirette: mostrare due risposte fianco a fianco e chiedere quale sia migliore, come fa ChatGPT con le risposte rigenerate.

Feedback Implicito

Qui il segnale va interpretato: l’utente non dice esplicitamente cosa pensa, ma le sue azioni lo rivelano.

• Terminazione anticipata: interrompere la generazione di testo o chiudere la conversazione può indicare insoddisfazione.
• Rigenerazioni o richieste di varianti: segnale che la risposta fornita non è sufficiente o non centrata.
• Azioni di organizzazione: cancellare una chat (spesso negativo), rinominarla (positivo ma con titolo inadeguato), salvarla o condividerla.

I Segnali del Linguaggio Naturale

L’interfaccia conversazionale apre alla possibilità di catturare feedback direttamente dal testo dell’utente, senza domande dedicate:

• Correzioni esplicite: frasi che iniziano con “No…” o “Intendevo…” sono un chiaro indicatore di fraintendimento.
• Tentativi di riformulazione: se l’utente ripete la richiesta in un altro modo, il modello non ha colto l’intento iniziale.
• Richieste di verifica: “Sei sicuro?”, “Controlla le fonti” spesso indicano mancanza di fiducia o incompletezza della risposta.
• Lamentele dirette: “Troppo generico”, “Informazione sbagliata”, “Risposta troppo lunga”.
• Espressioni emotive: segnali di frustrazione (“Uggh”) o sorpresa positiva che possono arricchire l’analisi di sentiment.

💡 Esempio: se chiedi un hotel a Sydney e rispondi “Sì, prenota quello vicino alle gallerie”, il modello può dedurre una preferenza per l’arte. Se invece chiedi “Non c’è niente sotto i 200$?”, stai trasmettendo una sensibilità al prezzo.

Quando e Come Raccogliere Feedback

Momenti Chiave

1. All’inizio del journey Serve a calibrare l’esperienza. Un’app di riconoscimento facciale ti fa scansionare il volto, un assistente vocale ti chiede di leggere una frase per allenare il wake word. Per applicazioni non critiche, questa fase dovrebbe essere opzionale, così da ridurre la frizione iniziale.
2. In caso di errore Allucinazioni, blocchi immotivati, immagini compromettenti o risposte lente: l’utente deve poter segnalare il problema subito, senza uscire dal flusso. Se il modello fallisce, l’ideale è permettere la correzione diretta o passare la conversazione a un operatore umano.
3. Con bassa confidenza del modello Quando il modello non è sicuro, può proporre più opzioni e chiedere quale sia preferita. Esempio: Google Photos, quando non è certo se due volti siano la stessa persona, chiede conferma all’utente. Questo tipo di feedback comparativo è prezioso per la preference fine-tuning.

Design Principles per la Raccolta

• Integrazione fluida nel workflow GitHub Copilot propone il completamento in grigio chiaro: Tab per accettare, scrittura per rifiutare. Midjourney usa pulsanti U/V per scegliere immagini o generarne varianti. Il feedback non interrompe, ma accompagna l’esperienza.
• Incentivi e motivazione dell’utente Spiegare come verrà usato il feedback: per personalizzare l’esperienza, per migliorare il modello globalmente o per monitorare le performance. Più l’utente percepisce utilità, più sarà disposto a contribuire.
• Evitare richieste impossibili Mai chiedere di scegliere tra due opzioni tecniche incomprensibili o troppo simili: si rischia di ottenere dati rumorosi e poco affidabili.

Bias, Limitazioni e Rischi

• Leniency bias Le persone tendono a dare voti più alti per evitare conflitti. Esempio: nel 2015, su Uber la media dei conducenti era 4.8/5, e sotto 4.6 si rischiava la disattivazione. In pratica, 4 stelle erano percepite come un giudizio negativo.
• Position bias La prima opzione mostrata riceve più click a prescindere dalla qualità. Si mitiga variando l’ordine di presentazione.
• Preference bias L’utente può preferire risposte più lunghe (percepite come più complete) o semplicemente quella vista per ultima, anche se meno accurata.
• Degenerate feedback loops Il modello rinforza i propri bias iniziali basandosi solo su ciò che viene mostrato e valutato. Esempio: iniziano a piacere le foto di gatti → il sistema ne propone di più → arrivano utenti amanti dei gatti → il sistema diventa un “paradiso per gatti” e ignora il resto.

Feedback Privato vs Pubblico

• Privato
  Favorisce onestà e precisione: l’utente non teme il giudizio sociale. Dopo che X/Twitter ha reso privati i “like”, il numero di interazioni è aumentato sensibilmente. Tuttavia, la visibilità ridotta ha anche eliminato un segnale pubblico utile per la discoverability e per spiegare perché certi post vengono suggeriti, rendendo il funzionamento dell’algoritmo meno trasparente agli occhi degli utenti.
• Pubblico
  Aumenta la discoverability dei contenuti ma introduce dinamiche di conformismo e distorsioni nelle valutazioni.

Feedback come Fonte di Training Data

Ogni modifica dell’utente a una risposta AI può essere strutturata come:

• Winning response: la versione modificata dall’utente (quella preferita)
• Losing response: l’output originale del modello

Questi dati possono:

• Personalizzare il modello sul singolo utente
• Alimentare il training di nuove versioni
• Fornire insight sull’uso reale dell’applicazione

Conclusioni: Dati, Sistema e Prodotto

Se c’è una cosa che questo capitolo mi ha lasciato, è che il feedback nell’AI engineering non è un “extra” delegato al product team: è parte integrante dell’architettura.

Progettarlo significa decidere quali segnali catturare, come interpretarli e come trasformarli in miglioramenti concreti.

Dopo questa lettura, mi porto a casa l’idea che raccogliere segnali utili è progettare il sistema tanto quanto scrivere un’API o costruire una pipeline di training.

E mentre mi preparo a una piccola vacanza — fatta di tuffi e di Il Giorno dei Trifidi — so già che al mio rientro mi aspetta Designing Machine Learning Systems, sempre di Chip Huyen, per scoprire come queste strategie di raccolta e interpretazione del feedback si intrecciano con il mondo MLOps e il ciclo di vita completo dei modelli.