CAPIRE L’IA · 11 di N
Abbiamo un manuale interno e vorremmo che l’assistente rispondesse alle domande dei colleghi. «Diamolo all’IA», diciamo. Ma questa frase può indicare operazioni molto diverse.
Possiamo inserire il testo nella richiesta. Possiamo costruire un sistema che recuperi i passaggi pertinenti quando servono. Oppure possiamo usare esempi per un nuovo addestramento. Sono tre modi di intervenire sul sistema, con effetti diversi su aggiornamento, comportamento e verificabilità.
La distinzione iniziale è decisiva: il RAG usa il contesto. Non è un’alternativa al contesto nello stesso senso in cui lo è una modifica dei parametri. È un modo organizzato di scegliere quali informazioni inserirvi.
Un esempio: la procedura che cambia versione
Immaginiamo un manuale aziendale, interamente fittizio. La versione 1 dice di inviare una richiesta di accesso al referente del servizio. La versione 2 introduce un portale e mantiene un’eccezione per gli utenti esterni.
Alla domanda «Come chiedo l’accesso?», non basta una risposta ben scritta. Occorre sapere quale versione vale e se chi domanda rientra nell’eccezione. Questo esempio ci accompagnerà nei tre casi.
Primo caso: mettere le informazioni nel contesto
Incolliamo il paragrafo aggiornato e chiediamo: «Rispondi usando questo testo; se manca un’informazione, segnalalo». Il modello elabora la domanda insieme al materiale fornito. I suoi parametri rimangono normalmente invariati.
Possiamo includere anche esempi del formato desiderato. Questo adattamento al materiale presente nella richiesta viene spesso descritto come apprendimento nel contesto, ma non implica un aggiornamento tramite gradiente.
Per un documento breve e una domanda occasionale, è una soluzione diretta. Tuttavia il contesto ha una capienza limitata e non garantisce che ogni dettaglio venga utilizzato correttamente. Aggiungere materiale irrilevante può rendere più difficile individuare l’eccezione importante.
Se domani apriamo un’altra conversazione, non possiamo presumere che il documento sia ancora disponibile. La persistenza dipende dal prodotto e dalle sue memorie o archivi esterni, non dal semplice fatto di aver mostrato il testo al modello.
Secondo caso: recuperare i documenti quando servono
RAG significa Retrieval-Augmented Generation: generazione arricchita dal recupero di informazioni. Un riferimento fondativo è il lavoro di Lewis e colleghi del 2020. Nelle applicazioni, il termine comprende oggi pipeline con molte varianti.
Una pipeline tipica prepara un archivio: legge i documenti, li divide in porzioni e conserva metadati come titolo, versione e sezione. Può indicizzarli con metodi lessicali, vettoriali o ibridi. Gli embedding sono una possibilità, non un requisito che esclude la ricerca per parole chiave.
Quando arriva una domanda, il sistema recupera i passaggi candidati, eventualmente li riordina e li inserisce nel contesto del generatore. La risposta può così riportare riferimenti ai documenti effettivamente consultati.
Nel nostro manuale, il recupero dovrebbe trovare sia la regola del portale sia l’eccezione per gli utenti esterni. Se la divisione in porzioni separa le due informazioni e ne viene recuperata una sola, il modello può ricevere una base incompleta.
La selezione della versione non dovrebbe dipendere soltanto dalla somiglianza semantica. La versione superata può contenere parole quasi identiche alla domanda. Date, stato di validità e permessi di accesso devono contribuire al recupero.
Tre punti in cui il RAG può fallire
Archivio: manca il documento corretto, oppure è stato estratto male. Recupero: il documento esiste ma il passaggio pertinente non arriva al modello. Generazione: il passaggio arriva, ma viene interpretato o citato in modo scorretto.
Questi errori richiedono interventi differenti. Cambiare il prompt non ripara un archivio privo della versione aggiornata. Migliorare la ricerca non basta se il generatore ignora sistematicamente le eccezioni.
Un test utile per diagnosticare il problema consiste nel fornire manualmente il passaggio corretto e osservare la risposta. Se il risultato migliora, il recupero merita attenzione; se resta sbagliato, occorre indagare anche istruzioni, interpretazione e modello. Non è una prova definitiva, ma separa due ipotesi.
Terzo caso: modificare il modello con il fine-tuning
Il fine-tuning è un ulteriore addestramento a partire da un modello esistente. Gli esempi contribuiscono a una funzione di perdita; i gradienti aggiornano parametri addestrabili. Cambia quindi una parte persistente del sistema.
Nel fine-tuning completo si possono aggiornare tutti i parametri. Tecniche efficienti come LoRA mantengono fissi i pesi di base e addestrano matrici aggiuntive più piccole. Il comportamento effettivo cambia comunque: non stiamo soltanto aggiungendo pagine alla richiesta.
Per esempio, possiamo addestrare su richieste di assistenza e classificazioni corrette per migliorare l’uso di una tassonomia interna, oppure su risposte nel formato strutturato atteso. Servono esempi coerenti e una valutazione su casi separati da quelli usati per l’addestramento.
Il fine-tuning può anche incorporare conoscenze, ma non è un database con operazioni affidabili di inserimento, correzione e cancellazione di singoli fatti. Se cambia il manuale, non basta assumere che una nuova sessione di addestramento cancelli ogni traccia della vecchia regola.
Confrontiamoli senza confonderli
| Intervento | Che cosa cambia | Esempio |
|---|---|---|
| Contesto fornito direttamente | Le informazioni della richiesta corrente | Incollare il paragrafo della versione 2 |
| RAG | I passaggi recuperati e inseriti nel contesto | Cercare regola ed eccezione nel manuale vigente |
| Fine-tuning | I parametri addestrabili del modello o degli adattatori | Imparare a classificare richieste con esempi corretti |
Un sistema può combinarli: un modello adattato al formato aziendale riceve istruzioni nella richiesta e consulta documenti con RAG. Non occorre scegliere una sola casella per sempre.
Come decidere da dove partire?
Nel nostro esempio, se la domanda riguarda una singola pagina già disponibile, inserirla nel contesto consente un primo esperimento semplice. Se le domande riguardano molti documenti che cambiano, il recupero organizzato diventa una possibilità da valutare. Se il problema persistente riguarda il comportamento su molti esempi simili, il fine-tuning può essere pertinente.
Prima di aumentare la complessità, conviene individuare il difetto concreto. Il sistema non trova la regola? La trova ma non la rispetta? Produce il formato sbagliato? La stessa etichetta «non funziona» nasconde problemi diversi.
Per informazioni puntuali e dinamiche, come lo stato attuale di una richiesta, può essere più appropriata una query a un sistema gestionale rispetto alla ricerca in documenti. Il dato operativo vive altrove e deve essere interrogato nel momento opportuno.
La verifica va progettata insieme alla soluzione
Costruiamo un insieme di domande con risposta attesa e fonti: casi ordinari, eccezioni, documenti superati, richieste ambigue e domande cui l’archivio non permette di rispondere. Misuriamo separatamente se il passaggio necessario viene recuperato e se la risposta lo usa correttamente.
Per il fine-tuning teniamo separati addestramento e valutazione, controllando anche duplicati e somiglianze eccessive tra i casi. Per il RAG rispettiamo i permessi già nella selezione dei documenti: il generatore non dovrebbe ricevere materiale cui l’utente non ha accesso.
I testi recuperati sono inoltre dati, non nuove istruzioni autorevoli. Una frase contenuta in un documento non deve poter cambiare liberamente obiettivo o autorizzazioni del sistema. La questione diventa ancora più concreta quando l’assistente può agire attraverso strumenti.
Tre cose da conservare
- Il contesto fornisce materiale da elaborare. Di norma non aggiorna i parametri.
- Il RAG seleziona materiale da portare nel contesto. Recupero corretto e risposta corretta vanno verificati separatamente.
- Il fine-tuning modifica parametri addestrabili. Può affiancare il RAG, ma non equivale a caricare un archivio consultabile.
Ora il sistema sa ricevere informazioni e cercarle. L’ultimo passaggio della serie riguarda un cambiamento ulteriore: che cosa accade quando, oltre a rispondere, può compiere azioni?
← Torna al percorso Capire l’IA
Lascia un commento