Il testo che
diventa dato

Arriva sempre così, in riunione, e sembra chiarissima. Poi ti siedi davanti ai ticket veri e cominci a trovare questi:

• «Buongiorno, la macchina è ferma da tre giorni, capisco che siate in ferie ma qui stiamo perdendo la produzione. Fatemi sapere. Grazie mille, buona giornata.» Educatissimo. Disastro totale.
• «ok ricevuto» in risposta a una comunicazione di aumento prezzi. Due parole, zero aggettivi, e il cliente sta già chiamando il tuo concorrente.
• «Siete stati velocissimi! Peccato per il pezzo sbagliato, ve lo rimando.» Metà e metà, e le due metà non pesano uguale.
• Una mail furibonda su un problema che il cliente stesso ha causato, e alla fine si scusa.

Adesso prova a chiedere a due colleghi bravi di etichettarli. Chi mette «negativo» sul primo perché il contenuto è grave, chi mette «neutro» perché il tono è cortese. Nessuno dei due ha torto: la domanda non dice se stai misurando il tono o il rischio. E sono due colonne diverse, con due usi diversi e due destinatari diversi.

Il momento in cui capisci se un progetto di analisi del testo funzionerà non è quando scegli il modello. È quando provi a scrivere, in una frase, cosa deve finire nella colonna. Se non ci riesci in una frase, il modello non ci riuscirà in un milione di parametri.

Quello che di solito serve davvero non è il sentiment. È una di queste tre, e vanno chieste per nome:

1. Il rischio di perdere il cliente. Colonna booleana o punteggio. La usa chi tiene i clienti. Con questa ci fai un modello di abbandono, e la trovi spiegata nella risorsa sul punteggio e la soglia.
2. L'urgenza operativa. Quanto in fretta va gestito. La usa chi smista. Serve a instradare, non a fare grafici.
3. Il motivo. Una categoria fra dieci o quindici. La usa chi decide cosa aggiustare nel prodotto. È la più preziosa delle tre ed è quasi sempre quella che nessuno chiede.

Il sentiment vero, «questo messaggio ha un tono positivo o negativo», serve a fare una slide con una torta colorata. L'ho consegnato qualche volta. Non l'ho mai visto cambiare una decisione.

Torniamo alla simulazione qui sopra, perché c'è un numero che merita di essere guardato meglio: il tetto. Con le istruzioni vaghe, un modello che indovinasse sempre la classe vera, misurato contro le etichette del collega A, prende circa il 75%. Non perché sia scarso. Perché in un quarto dei casi l'etichetta di A registra le abitudini di A, più che il contenuto del ticket.

Da questo discende una cosa che in riunione fa sempre lo stesso effetto:

Se il tuo modello di sentiment dichiara il 92% di accuratezza su dati etichettati così, non ha imparato il sentiment. Ha imparato a imitare la persona che ha etichettato. E quella persona, sui casi difficili, tirava a indovinare.

È il motivo per cui l'accuratezza sul testo va letta sempre con il kappa accanto. Sono due numeri che rispondono a domande diverse:

• Accuratezza: quante volte il modello scrive la stessa cosa che c'è nell'etichetta.
• Kappa: quanto di quell'accordo non sarebbe arrivato comunque per caso.

Le soglie che uso, e che sono la convenzione più diffusa: sotto 0,40 l'accordo è scarso e il progetto non sta in piedi; fra 0,40 e 0,60 è discreto e si può lavorare solo su categorie grosse; fra 0,60 e 0,80 è buono; sopra 0,80 è ottimo, e di solito vuol dire che il compito era ben definito, non che gli annotatori erano geni.

Il collaudo che faccio sempre, prima di scrivere una riga di codice, costa mezza giornata:

1. Prendo 200 documenti a caso, non scelti.
2. Li faccio etichettare a due persone diverse, separatamente, senza che si parlino.
3. Calcolo il kappa.
4. Se è sotto 0,50, non parto: torno alla definizione. Non serve a niente addestrare su etichette su cui gli umani non concordano.
5. Guardo i casi di disaccordo uno per uno. Quelli sono la linea guida: ogni disaccordo diventa una regola scritta.

Quel giro lì, ripetuto due volte, porta il kappa da 0,3 a 0,7 senza toccare niente di tecnico. È il miglior ritorno sull'investimento di tutto il progetto, e non lo vende nessuno perché non si può mettere in una demo.

Le linee guida che ho visto fallire hanno tutte la stessa forma: definiscono le classi. «Negativo: il cliente esprime insoddisfazione.» Grazie, lo sapevamo. Quella riga non risolve nessuno dei quattro ticket del capitolo 00.

Le linee guida che funzionano fanno l'opposto. Non definiscono le classi: arbitrano i conflitti. Si scrivono partendo dai disaccordi veri e hanno quattro pezzi.

1. Una regola di precedenza. «Il contenuto vince sul tono. Una mail cortese che segnala un fermo impianto è negativa.» Una riga, e il primo ticket del capitolo 00 smette di essere ambiguo per sempre.
2. I casi al limite, scritti. Cinque o sei esempi veri, copiati dai ticket, ciascuno con l'etichetta giusta e il motivo. Il motivo conta più dell'etichetta, perché è quello che si generalizza.
3. Una classe di scarico. «Non classificabile.» Senza, l'annotatore incerto è costretto a inventare, e il suo riflesso prudenziale finisce dentro i tuoi dati, esattamente come nella simulazione. Con la classe di scarico, il dubbio diventa un dato che puoi contare.
4. La destinazione. Una frase che dice a cosa serve la colonna e chi la guarderà. Sembra superfluo e invece è la cosa che fa prendere le decisioni giuste sui casi che la guida non copre.

Un dettaglio che sembra un cavillo e non lo è: la classe «non classificabile» va tenuta anche in produzione. Un modello che deve per forza scegliere fra tre etichette sceglierà sempre, anche sui testi che non c'entrano niente. Dargli il permesso di astenersi è il primo guardrail, e lo ritrovi in tutta la parte sull'estrazione.

Quando la linea guida è scritta, si riparte dal collaudo: stesse due persone, altri 200 documenti, nuovo kappa. Se non è salito, la guida non ha risolto i conflitti veri, e va riscritta guardando i nuovi disaccordi. Due giri bastano quasi sempre.

Un embedding è una funzione che prende un testo e restituisce una lista di numeri, di solito qualche centinaio o qualche migliaio. Sempre la stessa lunghezza, che il testo sia una parola o tre pagine. La proprietà utile è una sola, e vale la pena dirla con precisione perché tutto il resto ne discende: testi che parlano di cose simili producono liste di numeri vicine fra loro.

«Vicine» ha un significato tecnico esatto. Si prendono i due vettori, si calcola il coseno dell'angolo che formano, e si ottiene un numero fra -1 e 1. Vicino a 1 vuol dire «puntano nella stessa direzione». In pratica:

• «la pompa perde acqua» e «perdita dal circuito idraulico» → coseno alto, e non hanno una parola in comune.
• «la pompa perde acqua» e «la fattura è sbagliata» → coseno basso.

Questa è la cosa che la ricerca per parole chiave non sa fare, ed è un salto vero: il cliente che scrive «non parte più» e il manuale che dice «mancato avviamento» finalmente si trovano. Per questo negli ultimi due anni hanno venduto ricerca semantica a tutti.

Ora la parte che non viene raccontata mai, e che è il motivo per cui metà di quei progetti delude.

Il coseno misura di cosa parlano due testi. Non misura se il secondo risponde alla domanda del primo. Sono due cose diverse, e la distanza fra le due è dove si perdono i soldi.

Un esempio che ho visto dal vivo, su un archivio di assistenza. Ticket nuovo: «la centralina non si accende dopo l'aggiornamento firmware». La ricerca semantica restituisce, in cima, tre ticket vecchi che parlano di centraline che non si accendono. Bravissima: parlano esattamente di quello. Solo che riguardano un modello di centralina diverso, di sei anni prima, e la soluzione è cambiare un fusibile che sul modello nuovo non esiste. Il ticket che serviva davvero, quello che dice «dopo l'aggiornamento serve il reset dei parametri», stava al dodicesimo posto, perché era scritto con parole diverse e parlava anche d'altro.

Il modello ha fatto benissimo il suo lavoro. Ha trovato i testi più simili. Nessuno gli aveva chiesto i testi più utili, e non gliel'aveva chiesto nessuno perché quasi nessuno sa che sono due domande distinte.

Qui sotto ci sono cento ticket vecchi e una richiesta nuova. Guarda cosa cambia quando smetti di ordinare per somiglianza e cominci a ordinare per utilità, che vuol dire tenere conto di tre cose che il coseno ignora: se il ticket ha una soluzione, se riguarda lo stesso prodotto, e se non è vecchio di sei anni.

La cosa da portarsi via è che l'ordinamento per somiglianza è solo il primo passo, quello che riduce centomila documenti a cinquanta candidati. Il secondo passo, che decide chi va in cima ai cinquanta, è dove sta il valore, e si fa con informazioni che nel testo non ci sono:

1. Il documento ha una conclusione? Un ticket chiuso con una soluzione vale dieci volte un ticket chiuso con «il cliente non risponde».
2. È dello stesso mondo? Stesso prodotto, stessa versione, stesso tipo di cliente. Sono colonne che hai già nel database e che il coseno non guarda.
3. È recente? Un decadimento sull'età, morbido. Il vecchio non è inutile, vale solo meno.
4. Ha funzionato? Se registri quali risultati l'operatore ha effettivamente aperto e usato, dopo tre mesi hai il dato più prezioso di tutti, e a quel punto stai facendo un modello di punteggio come quelli della risorsa sui punteggi: ordinare i candidati per probabilità di essere utili.

Il riordino finale è quasi sempre una moltiplicazione fra il coseno e questi tre o quattro fattori. Niente di sofisticato, si scrive in venti righe, e sposta il numero di risultati utili molto più di quanto lo sposti cambiare il modello di embedding, che è invece la cosa su cui tutti passano le settimane.

RAG vuol dire una cosa semplice: prima cerchi nei tuoi documenti, poi passi al modello i pezzi che hai trovato e gli chiedi di rispondere usando quelli. È il modo giusto di far parlare un LLM dei tuoi dati, e funziona. Il pezzo che salta sempre fuori dopo, e che nella demo del fornitore non lo vedi, è questo:

Se la ricerca non trova niente di utile, il modello risponde lo stesso. Non ha modo di accorgersi che il materiale che gli hai passato non c'entra. Prende quei pezzi, ci ragiona sopra e produce una risposta ben scritta, sicura di sé e completamente inventata.

Il punto delicato è che quella risposta ha esattamente lo stesso aspetto di quella giusta. Stesso tono, stessa lunghezza, stessa sicurezza. Chi legge non ha nessun segnale per distinguerle. E l'unico posto dove il segnale esiste davvero è a monte: nel punteggio del recupero, cioè quanto assomigliavano i documenti trovati alla domanda. Se il migliore dei documenti trovati era lontano, la risposta è quasi certamente inventata. Ma quel numero, nella quasi totalità delle installazioni che ho visto, viene calcolato e buttato via.

Costruire il confine vuol dire tre cose, in ordine di quanto rendono:

1. Una soglia sul recupero. Se il documento migliore sta sotto una certa somiglianza, il sistema non chiama nemmeno il modello: risponde «non ho trovato niente su questo». Costa zero, taglia la maggior parte delle invenzioni ed è la cosa che quasi nessuno fa.
2. L'obbligo di citare. La risposta deve indicare da quale documento viene ogni affermazione. Non serve a far bello: serve perché un modello costretto a citare si astiene molto più spesso quando non ha da citare niente.
3. Il permesso di non sapere. Nel prompt, esplicito: «Se i documenti non contengono la risposta, scrivi che non lo sai». Sembra ovvio ed è saltato nella metà dei sistemi che apro.

Qui sotto ci sono centoventi domande vere fatte a un sistema RAG. Su una parte di queste, l'archivio semplicemente non contiene la risposta: nessuno ha mai scritto quel documento. Guarda cosa fa il sistema senza il confine, e cosa fa quando gli dai il permesso di dire «non lo so».

Il dato che conta è l'ultimo: di cui ti puoi fidare. È la percentuale di risposte date che sono davvero corrette. Senza confine il sistema risponde a tutte e centoventi, sembra generosissimo, e poco più della metà di quelle risposte regge: intorno al 55%, cioè poco meglio di una moneta. Con il confine risponde a una settantina di domande e ne azzecca oltre l'80%.

È lo stesso ragionamento della soglia nella risorsa sui punteggi: stai scegliendo dove tagliare, e il taglio è una decisione economica. Quanto costa una risposta inventata a un cliente? Quanto costa un «non lo so» che manda una persona a cercare a mano? Se la prima costa dieci volte la seconda, la soglia va spostata in alto e amen per le risposte perse.

Un ultimo avvertimento che mi è costato caro una volta. La soglia va tarata su domande vere, quelle che fanno gli utenti, non su quelle che ti inventi al collaudo. Le domande inventate dagli sviluppatori sono sempre ben poste, perché chi le scrive conosce l'archivio. Le domande vere sono storte, ambigue, scritte male, e girano intorno a cose che nell'archivio non ci sono mai state.

Questo è il pezzo che consiglio quasi sempre di fare per primo, e quasi sempre è quello che il cliente vuole fare per ultimo, perché non si vede. Prendi un documento, tiri fuori sei o otto campi, li metti in una tabella. Fine. Nessuno applaude in riunione. E poi quella tabella regge il resto: ci fai le query, i cruscotti, i modelli, e finalmente qualcuno può chiedere «quante consegne abbiamo sbagliato nel Nord Est nel primo trimestre» e avere una risposta in due secondi invece che in due settimane.

Gli LLM su questo sono bravi davvero. Sanno leggere una fattura scritta in un modo mai visto prima e capire qual è l'imponibile. È il caso d'uso in cui il salto rispetto a dieci anni fa è più netto: prima si facevano espressioni regolari e template, e bastava che il fornitore cambiasse il layout per far saltare tutto.

C'è un solo comportamento, però, che rovina tutto se non lo governi, e discende da come funziona la macchina:

Un modello a cui chiedi di riempire un campo lo riempie. Sempre. Anche quando quel campo, nel documento, non c'è. Non mente per malizia: sta facendo esattamente quello che gli hai chiesto, cioè produrre il testo più plausibile. E il testo più plausibile al posto di una data di consegna è una data.

Nei documenti veri la metà dei campi manca di continuo. Il contratto non dice la penale. La fattura non ha il riferimento all'ordine. La mail non contiene la data di consegna. Se su cento documenti trenta non hanno quel campo e il modello lo inventa trenta volte, hai una colonna piena, bellissima, e sbagliata nel 30% delle righe. Il guaio è che una colonna vuota si vede subito, mentre una colonna piena di date plausibili non se ne accorge nessuno finché qualcuno non ci pianifica sopra le spedizioni.

I quattro vincoli che uso, in ordine di quanto rendono per quanto costano:

1. Schema rigido in uscita. Non «rispondi in JSON» scritto nel prompt: lo schema imposto dall'API, con i tipi. Una data deve essere una data, un importo un numero. Da solo taglia gli errori di formato e rende il fallimento visibile invece che silenzioso.
2. Il valore nullo esplicito, e il permesso di usarlo. Ogni campo può essere null, e il prompt dice: «se il documento non contiene il dato, metti null, non dedurlo». È una riga di testo, ed è la singola modifica che sposta di più il risultato.
3. La citazione obbligatoria. Per ogni campo, il modello deve restituire anche il pezzo di testo da cui l'ha preso. Serve a due cose: rende il controllo umano dieci volte più veloce, e un modello costretto a citare inventa molto meno, perché non trova niente da citare.
4. La validazione che non passa dal modello. Codice normale: la data di consegna è dopo quella dell'ordine? L'imponibile più l'IVA fa il totale? La partita IVA esiste? Sono controlli deterministici che costano venti righe e catturano gli errori che tutto il resto ha lasciato passare.

Qui sotto ci sono centocinquanta documenti veri, con sei campi da estrarre. In una parte dei documenti alcuni campi non ci sono proprio. Guarda la differenza fra chiedere e basta, e chiedere con i vincoli.

La statistica che guardo per prima è la precisione di ciò che scrive: fra i campi che il sistema ha compilato, quanti sono giusti. È l'unico numero che conta per chi userà quella tabella, perché è la probabilità che una riga qualsiasi del suo report sia vera. La copertura, cioè quanti campi ha compilato, viene dopo: un sistema che compila il 70% dei campi e non sbaglia quasi mai è enormemente più utile di uno che li compila tutti e ne sbaglia un quinto, perché il primo lo puoi usare senza controllare e il secondo no.

E qui c'è il calcolo che convince i clienti più di ogni discorso tecnico. Se devi controllare a mano ogni campo perché non ti fidi, il progetto non ti ha fatto risparmiare niente: hai solo spostato il lavoro da «leggere il documento» a «verificare quello che ha scritto la macchina», che è più noioso e si fa peggio. L'estrazione rende soldi solo nel momento in cui smetti di controllarla, e per smettere di controllarla ti serve la precisione alta, non la copertura alta.

Classificare l'intenzione di un messaggio, per mandarlo alla coda giusta, è uno dei lavori più redditizi di questa famiglia. Arrivano ottocento mail al giorno, le smista una persona, quella persona è il collo di bottiglia di tutto il servizio. Un modello che le smista da solo con il 90% di accuratezza sembra la fine dei problemi.

Poi guardi quale 10% sbaglia, ed è sempre lo stesso: le classi rare. Le intenzioni non arrivano in parti uguali. Su ottocento messaggi al giorno tipicamente hai:

• Richiesta di informazioni: il 55%. Costo di sbagliarla: qualche ora di ritardo.
• Stato dell'ordine: il 28%. Costo di sbagliarla: una telefonata in più.
• Problema tecnico: il 12%. Costo di sbagliarla: un cliente che aspetta un giorno.
• Reclamo grave o disdetta: il 5%. Costo di sbagliarla: il cliente.

Il modello, addestrato a massimizzare l'accuratezza, impara benissimo le prime due, che sono l'83% dei casi, e sull'ultima fa quello che fanno tutti i modelli con le classi rare: tende a non usarla mai, perché sbagliare un reclamo grave costa quanto sbagliare una richiesta di listino, nel conteggio dell'accuratezza. È lo stesso identico meccanismo del 97% raccontato nella risorsa sui punteggi, applicato qui.

Su un reclamo grave sbagliato non perdi un punto percentuale di accuratezza. Perdi un cliente da centomila euro l'anno, che se ne va senza dirtelo, dopo aver aspettato tre giorni in una coda dove non doveva finire.

La correzione è concettualmente semplice e nessuno la fa: smetti di instradare verso la classe più probabile, e instrada verso quella con il costo atteso più basso. Per ogni messaggio calcoli, per ognuna delle quattro code, la probabilità che sia quella giusta moltiplicata per quanto costa sbagliare. Poi scegli il minimo.

In pratica, quello che succede: un messaggio che ha il 20% di probabilità di essere un reclamo grave e l'80% di essere una richiesta di informazioni finisce comunque nella coda dei reclami. Perché quel 20% moltiplicato per il costo di un cliente perso pesa più dell'80% moltiplicato per il costo di un'ora di ritardo. Il modello sembra sbagliare, l'accuratezza scende di due o tre punti, e i soldi migliorano.

Il resto lo fa un dettaglio operativo: la coda del dubbio. I messaggi su cui nessuna classe è chiaramente vincente non vanno instradati d'ufficio: vanno a una persona. Sono pochi, tipicamente il 5-8% del totale, e sono esattamente quelli su cui una persona serve davvero. Il collo di bottiglia si è ridotto di venti volte e non ha smesso di esistere: è stato messo dove conta.

Registri le chiamate dei venditori, le trascrivi, le analizzi. Su questo mercato girano promesse molto diverse fra loro per solidità, e vale la pena separarle, perché costano tutte uguali e non valgono uguale.

Quello che funziona bene, oggi, e lo consiglio senza riserve:

1. La trascrizione. Risolta. Su audio decente, in italiano, con due parlanti, l'errore è sotto il 5% e i nomi propri si sistemano con un dizionario aziendale. Dieci anni fa era un progetto, oggi è una riga di codice.
2. Chi ha parlato e quanto. Banale da calcolare e sorprendentemente utile: il rapporto fra il tempo in cui parla il venditore e quello in cui parla il cliente è uno dei segnali più solidi che conosca. Le chiamate che chiudono hanno il cliente che parla di più.
3. Gli argomenti toccati. Prezzo, concorrenza, tempi di consegna, garanzia. Estrarli come colonne booleane, e poi incrociarli con l'esito. È qui che salta fuori il dato che nessuno si aspetta, tipo «quando si parla di tempi di consegna nella prima call, chiudiamo il doppio».
4. Le domande aperte del cliente. Contarle. Un cliente che fa tre domande vere è un cliente che sta comprando.
5. Gli impegni presi. «Le mando il preventivo entro venerdì.» Estrarli e verificarli contro il CRM. Fa emergere una quantità di promesse non mantenute che di solito nessuno immaginava.

Quello che vendono e che io non comprerei:

• L'emozione dalla voce. Il tono, l'entusiasmo, lo stress misurati dall'audio. Sulla carta si può fare, e in laboratorio funziona. Sulle chiamate vere, con microfoni diversi, linee che cadono, accenti regionali e persone che parlano con la cornetta fra spalla e orecchio, il segnale che resta è talmente rumoroso da non essere azionabile. E c'è una cosa che pesa più della tecnica: in Europa dedurre lo stato emotivo di una persona dalla sua voce sul lavoro è un terreno su cui non voglio portare nessun cliente, tanto più con l'AI Act in vigore.
• Il punteggio di qualità della chiamata. Un numero da 1 a 100 su ogni venditore. È il kappa del capitolo 01 travestito: chiedi a due responsabili di dare un voto alla stessa call e vedi quanto sono d'accordo. Se non lo sono, quel punteggio è arredamento.
• La «prossima mossa suggerita» generica. Un LLM che dice «ricontattare il cliente» è un LLM che non sa niente del tuo cliente e sta producendo il testo più plausibile.

La regola che uso sulle call: tutto quello che si può contare, contalo. Tutto quello che va interpretato, diffida. La trascrizione è un fatto, il tempo di parola è un fatto, l'argomento toccato è quasi un fatto. Lo stato d'animo del cliente è un'opinione, e le opinioni di una macchina non valgono più di quelle di una persona che c'era.

I numeri che seguono sono di luglio 2026 e sono quelli che uso per i preventivi. Prendiamo il caso concreto dell'assistenza: ottocento ticket al giorno, quindi circa 290.000 l'anno. Su ciascuno servono tre cose: classificare l'intenzione, estrarre quattro campi, e recuperare i ticket simili.

Un ticket medio è 400 parole, cioè circa 550 token, e la risposta strutturata ne occupa un centinaio.

• Con il modello grosso (Opus 4.8, 5 $ per milione in ingresso e 25 in uscita): 290.000 × (550 × 5 + 100 × 25) / 1.000.000 ≈ 1.520 $ l'anno.
• Con il modello medio (Sonnet 5, 3 $ e 15 $): circa 910 $ l'anno.
• Con il modello piccolo (Haiku 4.5, 1 $ e 5 $): circa 300 $ l'anno.

Adesso i due sconti che quasi nessuno applica e che cambiano l'ordine di grandezza:

1. La cache del prompt. Le istruzioni, lo schema e gli esempi sono identici su tutti e 290.000 i ticket, e sono la parte grossa del prompt. Messi in cache costano circa un decimo in lettura. Se le istruzioni sono 2.000 token e il ticket 550, stai pagando a prezzo pieno solo il ticket: il conto scende di più della metà.
2. Il lotto notturno. La classificazione dei ticket non ha bisogno di rispondere in mezzo secondo. Mandata in Batch API costa metà. Vale per tutto quello che può aspettare la notte: classificazione, estrazione, arricchimento dello storico.

Messi insieme, l'assistenza di un'azienda con ottocento ticket al giorno si analizza per qualche centinaio di euro l'anno con Haiku, e per meno di mille con Sonnet. La riga di costo vera del progetto non è quella.

La spesa che conta sta altrove, e sono le mezze giornate di due persone che etichettano duecento documenti, e le due settimane per scrivere la linea guida e rifarla. Quella parte non la sconta nessuno, non la fa nessun fornitore al posto tuo, ed è quella che decide se il progetto funziona.

Un'ultima nota sulla scelta del modello, perché è la domanda che ricevo sempre. Per classificare e instradare, il modello piccolo va benissimo: il compito è chiuso e la differenza fra i tre è dentro il rumore. Per estrarre da documenti storti, il medio si ripaga. Per ragionare su un contratto, dove un errore vale un contenzioso, si usa il grosso e non si discute. La regola: più il compito è chiuso, più il modello può essere piccolo.

1. «Il modello di sentiment ha il 91% di accuratezza.» Cosa chiedi?
   Quanto vale il kappa fra due annotatori umani sugli stessi dati. Se nessuno l'ha misurato, quel 91% non si sa cosa misuri. Se il kappa è 0,3, il modello sta imitando le abitudini di chi ha etichettato.
2. Due annotatori concordano sull'88% dei ticket. È un buon dato?
   Dipende da come sono distribuite le classi. Se l'85% dei ticket è neutro, l'88% di accordo è quasi tutto caso: il kappa sarà intorno a 0,2. Il numero grezzo, da solo, non dice niente.
3. La ricerca semantica trova i documenti più simili. Perché non basta?
   Perché somigliare e rispondere sono due cose diverse. Il coseno non sa se il documento riguarda il tuo prodotto, se ha una conclusione o se è di sei anni fa. Quelle informazioni le hai già nel database e vanno moltiplicate al coseno.
4. Il RAG risponde a tutte le domande. È un bene?
   No, è il sintomo principale che manca il confine. Un archivio non contiene la risposta a tutto: un sistema che non dice mai «non lo so» sta inventando ogni volta che l'archivio tace, e lo fa con lo stesso tono con cui ha ragione.
5. Dove sta l'unico segnale che distingue una risposta vera da una inventata?
   Nel punteggio di recupero, calcolato prima di chiamare il modello. Se il documento migliore era lontano, la risposta è probabilmente inventata. Quel numero c'è già in tutti i sistemi, e quasi tutti lo buttano.
6. L'estrazione ha compilato tutti i campi di tutti i documenti. Cosa sospetti?
   Che non abbia il permesso di dire «non c'è». Nei documenti veri i campi mancano in continuazione. Una tabella senza un solo buco è una tabella con dentro delle deduzioni.
7. Precisione o copertura, su un'estrazione?
   Precisione, quasi sempre. Una tabella di cui ti fidi al 95% si usa senza controllarla. Una piena all'100% e giusta al 70% va controllata riga per riga, e a quel punto non hai risparmiato niente.
8. Perché la citazione obbligatoria riduce le invenzioni?
   Perché costringe il modello a puntare a un pezzo di testo esistente. Quando non trova niente da citare, si astiene molto più spesso. E in più rende il controllo umano dieci volte più veloce.
9. L'instradamento ha il 90% di accuratezza. Cosa guardi?
   La riga della classe rara e costosa nella matrice di confusione. L'accuratezza complessiva è dominata dalle classi frequenti: il modello può avere il 90% e non usare quasi mai la classe «reclamo grave», che è quella che vale un cliente.
10. Come si instrada allora?
    Verso il costo atteso minimo, non verso la classe più probabile. Probabilità per costo dell'errore, per ogni coda, e si sceglie il minimo. L'accuratezza cala di due punti e i soldi migliorano.
11. Ti offrono l'analisi dell'emozione dalla voce dei venditori. Cosa rispondi?
    Che sulle chiamate vere il segnale è troppo rumoroso per decidere qualcosa, e che dedurre lo stato emotivo di un lavoratore dalla sua voce, in Europa, è un terreno su cui non porto nessun cliente. La trascrizione e gli argomenti toccati danno più valore e non hanno né il problema tecnico né quello legale.
12. Qual è la voce di costo vera di un progetto sul testo?
    Le ore delle persone che definiscono l'etichetta e scrivono la linea guida. I token sono qualche centinaio di euro l'anno, e con cache e lotto notturno diventano spiccioli. Chi ti fa il preventivo parlando solo di token non ha ancora capito dove sta il lavoro.

Se sei arrivato fin qui, probabilmente hai in mente un archivio preciso: le mail dell'assistenza, i ticket, i contratti, le note dei venditori. E probabilmente hai anche il sospetto che lì dentro ci sia qualcosa che nessuno ha mai contato.

Il modo più veloce per scoprirlo non è un progetto da sei mesi. È mezza giornata fatta così: si prendono duecento documenti veri, si prova a scrivere in una frase cosa deve finire nella colonna, e si misura il kappa fra due tue persone. Alla fine di quella mezza giornata sai già se il progetto sta in piedi, e sai quanto vale. Costa quasi niente e ti evita di scoprirlo dopo aver speso.

Se vuoi farlo insieme, scrivimi su WhatsApp e ne parliamo sul tuo caso.