«Ma questa risposta l’ha capita, o l’ha solo azzeccata?»
Chi usa l’AI nel lavoro questo dubbio se lo porta dietro, prima o poi. La risposta arriva scorrevole, pulita, ben girata. Però l’ha tirata fuori capendo davvero, oppure sta solo restituendo qualcosa che «suona giusto»?
Più le si fa preparare la bozza di un piano o la sintesi di un’analisi, più il tarlo cresce. E, curiosamente, più il risultato è buono più sale il sospetto: e se fosse tutta apparenza?
Non è una pignoleria da addetti ai lavori. È esattamente la domanda da cui dipende quanto possiamo delegarle: cioè, in fondo, quale strumento adottare.
Nel pezzo precedente abbiamo visto come la serie «Physics of Language Models» smonti i benchmark rifacendo i test da zero. Stessa squadra, stesso spirito: ma stavolta, invece di guardare i voti, vanno a spiare il modello dentro.
Andiamo a vedere cosa salta fuori quando si seguono due cose: gli stati interni e l’attenzione.
Quando si seguono gli stati interni, spunta il «progetto» della frase
Prima però due parole sul banco di prova, perché conta. I ricercatori — Zeyuan Allen-Zhu e Yuanzhi Li, di Microsoft Research — non hanno usato frasi prese dal mondo reale, ma dati sintetici: problemi costruiti apposta, con una struttura nota in partenza. Così è chiaro cosa si sta misurando, e si può davvero seguire se il modello ha capito.
La cosa su cui mettono gli occhi sono gli stati interni. In pratica vuol dire la rappresentazione che il modello tiene in memoria mentre legge una frase: il suo blocco per gli appunti, il foglio di brutta su cui sta lavorando in quel momento.
E qui arriva la sorpresa. Davanti a frasi con incastri annidati — proposizioni dentro proposizioni — dentro al modello si ritrovava ricostruita una gerarchia di relazioni. Tradotto: non stava maneggiando una fila piatta di parole, ma il «progetto» della frase, la sua impalcatura.
L’attenzione si muoveva come chi spezza un problema in pezzi
C’è una seconda cosa, ancora più interessante: come faceva il modello a tirarla su, quell’impalcatura? I ricercatori hanno seguito anche il flusso dell’attenzione, cioè il modo in cui, leggendo, il modello decide a quali pezzi della frase dare peso.
E il flusso assomigliava alla programmazione dinamica. Detta senza gergo: si prende un problema grosso, lo si spezza in sotto-problemi più piccoli, si risolvono quelli e si riusano i risultati intermedi invece di rifare ogni volta i conti da capo. Un modo ordinato di lavorare, insomma.
Il che vuol dire una cosa precisa: il modello, qui, non tirava a indovinare. Si costruiva dentro un ordine delle operazioni — prima questo, poi quello — proprio come faremmo noi a smontare un problema complicato. Ed è esattamente il nodo della questione «capisce o no».
Lo stesso non vale per tutti i modelli: il progetto conta
Attenzione però a non generalizzare. Non tutte le AI si comportavano allo stesso modo: com’è progettato il modello cambiava la profondità con cui afferrava la struttura. E questo è il pezzo che ci interessa di più, perché tocca da vicino la scelta tra un fornitore e l’altro.
Un esempio concreto. Per dire al modello dove si trova ciascuna parola nella frase si usa la codifica della posizione: un’etichetta che segnala l’ordine. Tra i vari metodi, quello «relativo» — il RoPE, che ragiona sulla distanza tra le parole più che sulla loro posizione assoluta — se la cavava meglio degli altri.
C’è di più. Confrontando l’impostazione tipo GPT (che legge la frase da sinistra a destra, come quando scriviamo) con quella tipo BERT (che la guarda tutta insieme, avanti e indietro), in alcuni casi il progetto più vincolato, quello con meno libertà di movimento, mostrava una comprensione della struttura più profonda. Controintuitivo, no? Eppure è così: qualche paletto in più, a volte, aiuta a capire meglio.
Morale pratica di questo punto: due modelli «a pari voto» non sono affatto detto che siano a pari sostanza. Sotto, l’impalcatura può essere costruita molto diversamente.
Conclusione: guardate il «progetto» e i tipi di errore, non la patina
La cosa che da tutto questo passa più dritta al lavoro di tutti i giorni è una sola: una risposta che sembra impeccabile non garantisce un lavoro interno solido. Quando esce un testo ben scritto viene voglia di fidarsi, ma finché non si vede dove il modello inizia a sbandare — sui testi lunghi, sui confronti, sui ragionamenti a più condizioni — non sappiamo davvero quanto regge sul nostro lavoro.
Quindi, quando confrontate due modelli candidati, non annotate solo la percentuale di risposte giuste: tenete traccia anche dei tipi di domanda su cui falliscono. È un’informazione diversa, e spesso più utile del voto secco. E quando ascoltate un fornitore, chiedetegli le condizioni deboli e le condizioni del test, non solo i casi che vanno bene: i casi che vanno bene li raccontano tutti.
Infine, la regola che vale sempre: prima di adottare uno strumento, rifate la prova sul vostro compito. Una manciata di domande realistiche del vostro settore, misurate voi stessi, dicono più di qualsiasi classifica patinata. La patina convince in fretta; il progetto sotto, quello, va guardato con i propri occhi.
Fonti
- Zeyuan Allen-Zhu, Yuanzhi Li, “Physics of Language Models: Part 1, Learning Hierarchical Language Structures”, ICML 2023. arXiv:2305.13673
- Physics of Language Models, sito ufficiale della serie. physics.allen-zhu.com
