Cosa significa istruire un'AI: dare conoscenza a un Large Language Model

Quando si dice di usare un Large Language Model con le proprie informazioni, in modo che ragioni sui propri dati, si descrive un'idea corretta nella sostanza ma imprecisa nel dettaglio tecnico. Far sì che un'AI conosca davvero il proprio mondo, un catalogo prodotti, una base documentale, un dominio specifico, è una sfida che non ha una sola soluzione. È un terreno in cui l'esperienza concreta fa emergere problemi, vincoli e compromessi, e in cui la risposta giusta dipende quasi sempre dal contesto.

Il punto di partenza: RAG e vicinanza semantica

La metodologia più comune per costruire un assistente AI, ad esempio uno shopping assistant su un catalogo e-commerce, si basa su un modello come GPT-4o o Claude 3.5 usato tramite API, con uno stack intermedio che lo orchestra. Il primo passo è quasi sempre la RAG, Retrieval Augmented Generation. A una domanda, ad esempio dei pantaloni jeans slim fit, il sistema cerca nella knowledge base tutto ciò che ha a che fare con quei termini, recupera da un database vettoriale i blocchi di informazione più vicini, li mette nel contesto del modello insieme al Mental Model e all'obiettivo, e chiede una risposta. La knowledge base è la parte di conoscenza specifica che il modello non possiede: non conosce il nostro catalogo prodotti, glielo dobbiamo fornire noi.

Quando la vicinanza semantica non basta

Questo approccio funziona molto bene, ma non sempre. Il limite emerge quando la selezione delle informazioni giuste non dipende dalla vicinanza semantica, bensì da un ragionamento, da un'inferenza. Se chiediamo un outfit completo per andare a un battesimo, nel catalogo non c'è scritto da nessuna parte che pantalone, giacca e camicia sono adatti a una cerimonia: è una conoscenza implicita che il modello possiede, ma che entra in gioco solo se gli forniamo i pezzi giusti. Con la RAG, però, in fase di recupero si prelevano i prodotti per vicinanza semantica rispetto alla parola battesimo, che nel catalogo non ha quasi corrispondenze: il risultato diventa aleatorio e spesso non funziona, perché il criterio di selezione corretto sarebbe di ragionamento, non di prossimità.

Prima soluzione: tutto il catalogo nel Mental Model

Una prima via è inserire l'intero catalogo prodotti nel Mental Model, passandolo al modello a ogni interazione. Così funziona perfettamente, perché il modello dispone sempre di tutta la conoscenza e può fare l'inferenza corretta. Il problema è la scala: con cinque o diecimila SKU, oltretutto da aggiornare di continuo, il contesto da passare a ogni richiesta diventa enorme. Va ricordato che un LLM è stateless, non ha memoria, quindi il contesto va ripassato ogni volta. Questo genera due conseguenze pesanti: i costi, perché ogni milione di token in input e output si paga (con GPT-4o si parla di alcuni dollari per milione di token in input e di più in output), e i limiti tecnici della finestra di contesto, che per GPT-4o è di 128k token. Funziona quindi solo in contesti piccoli, con poche informazioni, non come metodo standard.

Seconda soluzione: il fine tuning

La seconda via è il fine tuning: si prende un modello, gli si fornisce una collezione di informazioni proprie e si genera un nuovo modello che è la somma dei due. Qui serve però una distinzione importante. Il fine tuning offerto oggi da OpenAI sui modelli GPT non aggiunge conoscenza, bensì agisce sulla forma: fornendo un subset di esempi di input e output validi, si insegna al modello come strutturare le risposte, non quali dati conoscere. Per integrare davvero la conoscenza si può ricorrere a un modello open source, come Llama 3 o alternative più piccole, scaricabile e addestrabile con i propri dati tramite piattaforme come Hugging Face. In quel caso la base di conoscenza diventa parte integrante del modello e il risultato è perfetto.

Anche questa strada ha un costo. È una fotografia statica: ogni volta che il catalogo si aggiorna bisogna riaddestrare il modello, con tempi e costi. Inoltre si perde flessibilità: mentre nella logica RAG l'LLM è una componente intercambiabile, e si può passare da un modello all'altro scegliendo il migliore o il più economico, con il fine tuning si fa una scelta di campo, una scatola nera. Quando esce un modello più potente, bisogna rifare tutto su quello. È una soluzione obbligata in alcuni casi, ma poco adatta a molte situazioni reali.

La terza via: arricchire la knowledge base con l'AI

La strada che dà i risultati più interessanti utilizza ancora la logica della RAG e della vicinanza semantica, ma lavora preventivamente sulla knowledge base per arricchirla, usando l'AI stessa. L'idea è generare a monte le informazioni che serviranno a valle. Si mostra ogni prodotto al modello e gli si chiede di classificarlo: per quali occasioni d'uso è adatto e per quali no, con cosa si abbina, con quali colori funziona e con quali no. A quel punto, nel catalogo comparirà scritto cerimonia, adatto per le cerimonie, e la connessione torna a essere di vicinanza semantica. È un'operazione one shot, fatta una volta sola, che arricchisce il catalogo con un meta contenuto al di sopra della descrizione del prodotto.

Un'applicazione concreta ha riguardato un grande database di immagini. Tramite le API di vision è stata generata, per ogni foto, una descrizione puntuale secondo un preciso Mental Model, ad esempio lo sguardo di un interior designer: materiali, contesto, situazione d'uso. Queste informazioni, abbinate alle immagini, hanno permesso di creare un assistente capace di mostrare foto che contengono certi materiali o certi contesti, ricerche che su un database classificato per altro, come la collezione di appartenenza o una descrizione marketing generica, avrebbero sempre restituito zero risultati. Fino a poco tempo fa lavori simili si facevano a mano, contenuto per contenuto, con limiti evidenti, tempi enormi e una resistenza comprensibile da parte di chi avrebbe dovuto taggare migliaia di elementi.

Nessuna soluzione universale, ma un approccio

La terza via funziona benissimo nei contesti in cui il comportamento atteso dell'AI è ben definito e le tipologie di domanda sono prevedibili, perché solo allora si sa con quali informazioni arricchire la knowledge base. Funziona meno in contesti molto aperti, dove qualunque domanda è possibile e diventa difficile sapere in anticipo cosa serve. La conclusione è che non esiste una soluzione valida per tutte le occasioni: in contesti piccoli può bastare il Mental Model con il catalogo, in contesti chiusi e ben definiti conviene arricchire la knowledge base, in contesti che non rientrano in nessuno dei due il fine tuning resta spesso l'unica strada. Ciò che conta è avere a disposizione tutti questi metodi, conoscerli e saper scegliere caso per caso quello giusto: non è la tecnologia, ma l'approccio alla soluzione, a fare la differenza.