Gestisco un digital twin sul mio sito web. Risponde a domande sulla mia vita e sulle mie competenze. Gli ho dato una regola ferrea: non inventare mai nulla. Se qualcuno chiede di una competenza che non possiedo, deve ammettere di non saperlo. Per mesi, ho creduto che il sistema funzionasse. L'ho testato manualmente qua e là, e le risposte sembravano solide. Poi ho costruito un vero e proprio framework di valutazione. I numeri sono stati duri. Su 35 domande, nove contenevano menzogne palesi. Su otto domande progettate per essere impossibili da rispondere, il modello ne ha rifiutate solo quattro. Il mio prompt anti-allucinazione è fallito circa un quarto delle volte. Stavo distribuendo un prodotto che mentiva ai suoi utenti.
Un setup di retrieval semplicissimo
Non ho attivato Pinecone o alcun database vettoriale pesante. L'intero setup si basa su un semplice file JSON. Il mio codice suddivide il mio profilo in sezioni distinte. Quando arriva una domanda, il sistema calcola la similarità del coseno tra la query e ogni chunk di testo, seleziona i match più vicini e li inserisce nel prompt come contesto. Il modello genera quindi una risposta basandosi esclusivamente su ciò che vede in quella finestra.
Per un piccolo sito personale che serve un set limitato di fatti, questo approccio è veloce e non costa quasi nulla. Non c'è alcun round-trip di rete verso un vector store remoto, nessun overhead di indicizzazione e nessuna orchestrazione complessa. Leggi il file, assegni un punteggio ai chunk, costruisci il prompt e via. Ma la semplicità del backend non garantisce l'onestà dell'output. Una pipeline leggera può comunque produrre problemi seri quando il modello decide di improvvisare. Il divario tra "ecco il contesto" e "ecco cosa dirò a riguardo" è dove vivono le allucinazioni. Puoi fornire al modello un paragrafo sulla tua storia lavorativa e ricevere comunque una falsa affermazione sicura su un linguaggio di programmazione che non hai mai toccato.
I numeri che hanno distrutto la mia fiducia
Per mesi, ho considerato il controllo manuale sporadico come una copertura sufficiente. Aprivo la chat, facevo una domanda di cui conoscevo già la risposta e annuivo quando la risposta sembrava corretta. Quella era la mia strategia di test. Sembrava accurata perché stavo usando io stesso l'interfaccia. Non lo era.
Quando finalmente ho scritto un framework di valutazione che potesse girare sistematicamente, il quadro è cambiato. La suite di test ha sottoposto il twin a 35 domande. Nove risposte contenevano bugie. Ho incluso anche otto domande che non avevano risposta in nessuna parte del mio profilo. Il modello avrebbe dovuto rifiutarle tutte. Ne ha rifiutate solo quattro. Il mio prompt anti-allucinazione, creato con cura e che includeva un linguaggio assoluto sul non inventare mai nulla, è fallito circa il 25% delle volte. Una su quattro. Questo non è un errore di arrotondamento. È un prodotto rotto.
Smettete di testare con domande "amichevoli"
Non si trovano i bug semplicemente usando il proprio prodotto. Si trovano cercando di romperlo. I miei test manuali erano troppo amichevoli. Potevo porre solo domande di cui conoscevo la risposta esatta, il che significava che stavo inconsciamente guidando il modello verso un territorio sicuro. Non ho mai esplorato i margini. Non ho mai chiesto di competenze che avrei voluto avere o di esperienze mai accadute.
Il vero testing richiede un intento avversariale. Bisogna creare domande progettate per far fallire l'IA. Si vuole che sbagli in laboratorio, così non sbaglierà davanti a un visitatore. Una suite di test che conferma solo ciò che già credi è solo una demo travestita. Se non stai attivamente creando edge cases e domande trabocchetto, non stai testando. Stai sperando.
I due errori che contano
Il prompting non è una garanzia. Un'istruzione lunga e dettagliata che dice a un'IA di non allucinare è solo un suggerimento travestito da comando. Il modello potrebbe seguirla la maggior parte delle volte, ma ignorerà l'istruzione nel momento in cui la pressione statistica lo spingerà altrove. Temperatura, probabilità dei token e la forma dei dati di addestramento pesano molto più di una frase nel tuo system prompt. Devi misurare l'obbedienza con i dati, non con la speranza. Un'istruzione forte non è un fatto verificato. È una richiesta, e le richieste possono essere negate. Se l'intera tua strategia di sicurezza si basa sul formulare il prompt in modo fermo, hai costruito un parapetto di carta velina. Hai bisogno di un framework di valutazione che conti quante volte il modello obbedisce, in quali condizioni e perché fallisce quando fallisce. I numeri non si curano del tuo tono di voce.
Il ciclo di valutazione era difettoso. Ecco una sottile trappola che ha rischiato di farmi sbagliare. Il mio strumento di test originale eseguiva il processo di retrieval due volte. La prima esecuzione recuperava il contesto per confrontarlo con la ground truth. La seconda esecuzione recuperava il contesto per la generazione effettiva della risposta. In pratica, ciò significava che i chunk visti dal giudice potevano differire dai chunk visti dal modello. Il giudice stava valutando la risposta rispetto a dati che l'IA potrebbe non aver mai ricevuto. Una valutazione che giudica l'input sbagliato è peggiore di nessuna valutazione. Ti dà un falso senso di sicurezza. Guardi il punteggio, vedi un alto tasso di successo e ti rilassi. Nel frattempo i tuoi utenti stanno