Un'azienda vuole adattare un modello al suo settore. Spesso vengono proposte tre soluzioni: migliorare il prompt, collegare una base documentale tramite RAG o addestrare il modello su esempi. Non risolvono lo stesso problema.
Il prompt dà istruzioni al momento della chiamata. Il RAG recupera informazioni esterne e le aggiunge al contesto. Il fine-tuning regola i parametri del modello per rafforzare un comportamento. Un'architettura matura può combinare i tre, ma solo dopo aver identificato la causa degli errori.
Iniziare con una baseline
Prima di aggiungere una tecnologia, costruire una versione minima con:
- un modello di riferimento ;
- un prompt chiaro;
- un'uscita strutturata se necessario;
- venti a cento casi di test rappresentativi;
- delle metriche;
- un'analisi degli errori.
Senza baseline, è impossibile sapere se il RAG o il fine-tuning portino un miglioramento. Il team rischia di misurare una sensazione su alcune dimostrazioni favorevoli.
L'ingegneria dei prompt: inquadrare il compito
Un buon prompt specifica:
- il ruolo atteso ;
- il compito;
- gli antipasti;
- i vincoli;
- il formato di output ;
- i criteri di rifiuto;
- esempi così utili;
- gli strumenti disponibili.
Il prompt è adatto quando la conoscenza necessaria è già nel modello o fornita nell'input. È adatto per trasformare un testo, estrarre campi, classificare, riassumere o applicare una procedura breve.
I suoi vantaggi sono la rapidità, il basso costo di messa in opera e la facilità di iterazione. I suoi limiti si manifestano quando le istruzioni diventano molto lunghe, contraddittorie o difficili da mantenere. Un prompt non aggiorna le conoscenze interne del modello e non garantisce informazioni aziendali accurate.
Le RAG: portare la conoscenza al momento della risposta
La Retrieval-Augmented Generation cerca passaggi pertinenti nelle fonti e li trasmette al modello. Si adatta quando le informazioni:
- cambiano regolarmente ;
- appartengono all’azienda;
- devono essere citate;
- sono troppo numerose per un prompt fisso;
- possiedono diritti di accesso;
- devono essere rimosse senza reinserire.
Un RAG non è una semplice base vettoriale. Bisogna gestire l'ingestione, il taglio, i metadati, la ricerca, il riorientamento, i diritti, le citazioni, la valutazione e l'aggiornamento.
I suoi difetti derivano spesso dalla ricerca, non dal modello: documento sbagliato, chunk incompleto, filtro di accesso, vocabolario diverso o informazioni assenti.
Il fine-tuning: imparare un comportamento
Il fine-tuning addestra il modello su coppie di esempi per aumentare la probabilità di un comportamento. Può essere pertinente per:
- rispettare un formato preciso;
- adottare uno stile costante;
- classificare secondo una tassonomia stabile;
- migliorare una lingua o un gergo ;
- ridurre la lunghezza del prompt;
- imparare decisioni ripetitive a partire da esempi di qualità.
Non è generalmente la soluzione migliore per memorizzare una documentazione in continuo cambiamento. I fatti diventano difficili da aggiornare e citare. Un modello fine-tuned può anche riprodurre errori, bias o dati sensibili del corpus.
Lo sforzo principale risiede nella selezione, nell'annotazione, nei diritti, nella separazione addestramento/test e nella valutazione, non nell'avvio del comando di addestramento.
La questione centrale: conoscenza o comportamento?
Quando il modello non conosce la procedura del giorno, manca di conoscenza: il RAG è spesso prioritario. Quando conosce gli elementi ma non segue un formato o confonde una tassonomia, il comportamento è in causa: prompt o fine-tuning possono aiutare.
Alcuni problemi sono misti. Un assistente di supporto deve trovare la procedura corretta e poi redigere una risposta conforme al tono dell’azienda. Il RAG fornisce il contenuto; il prompt o il fine-tuning inquadra la forma.
Albero decisionale tra prompt, RAG, fine-tuning e approccio ibrido in base alla conoscenza, al comportamento, alla freschezza e alle prove.
Confrontare gli approcci
| Criterio | Prompt | RAG | Messa a punto |
|---|---|---|---|
| Mise en place | veloce | media a elevata | importante |
| Aggiornamento dei fatti | ad ogni chiamata | per reindicizzazione | nuovo allenamento |
| Citazioni | limitate alle fonti fornite | naturali se concepite | non nativi |
| Dati richiesti | alcuni esempi | documenti utilizzabili | esempi supervisionati di qualità |
| Controllo degli accessi | nell'applicazione | fino nella ricerca | difficile a livello delle conoscenze apprese |
| Costi operativi | contesto talvolta lungo | ricerca + contesto | modello personalizzato + inferenza |
| Debugging | prompt e uscita | ricerca poi generazione | dati, addestramento e inferenza |
| Portabilità | relativamente forte | dipende dalla catena | dipende dal fornitore e dal formato |
Questa tabella fornisce delle tendenze. Il benchmark reale sul compito rimane decisivo.
Il contesto lungo non sostituisce sempre il RAG
I modelli accettano contesti sempre più lunghi. È allettante inviare tutti i documenti. Questo approccio può funzionare per un caso isolato, ma ha dei limiti: costo, latenza, rumore, controllo degli accessi, ripetizione dei dati e difficoltà a garantire che venga utilizzato il passaggio corretto.
Il RAG riduce il contesto agli elementi pertinenti e consente un indice condiviso. Per piccoli insiemi, una strategia ibrida può prima filtrare per metadati e poi inviare diversi documenti completi.
Le RAG non corregge tutti i comportamenti
Aggiungere ulteriori documenti non risolve un modello che rifiuta male, non rispetta il JSON o adotta un tono scorretto. Bisogna separare le metriche:
- richiamo e precisazione della ricerca;
- fedeltà alle fonti;
- esattezza della risposta;
- formato ;
- stile ;
- rifiuto;
- latenza ;
- costo.
Questa scomposizione mostra quale leva modificare.
Il fine-tuning richiede un corpus governato
Gli esempi devono essere:
- rappresentativi della produzione;
- corregge ;
- coerenti tra annotatori;
- autorizzati ;
- esenti da dati inutili;
- separati dal set di test;
- versionati.
Un corpus di risposte storiche può contenere le cattive abitudini che si desidera eliminare. Deve essere curato, non semplicemente esportato.
Prevedere un modello card interno: versione di base, dati, parametri, limiti, risultati, rischi e procedura di ritiro.
Una strategia ibrida frequente
Un'applicazione robusta può seguire questa catena:
- un prompt di sistema breve definisce le regole;
- un classificatore o router sceglie il compito;
- il RAG recupera le fonti autorizzate;
- un modello eventualmente fine-tuned produce il formato atteso;
- un validatore controlla schema e citazioni;
- un umano approva i casi sensibili.
Ogni blocco deve giustificare la sua complessità. Aggiungere un modello fine-tuned prima di aver stabilizzato gli errori rende l'architettura più difficile da mantenere.
Costruire un'esperienza comparativa
La decisione può essere presa in quattro iterazioni.
Iterazione 1: prompt di riferimento
Misurare la qualità senza retrieval né addestramento. Identificare gli errori di conoscenza, formato, ragionamento e sicurezza.
Iterazione 2: RAG minimale
Indicizzare un corpus limitato, definire domande di riferimento e misurare il recupero e poi la risposta. Non iniziare con tutta la documentazione.
Iterazione 3: perfezionamento mirato
Solo se un comportamento ripetitivo resiste ai prompt e se gli esempi sono disponibili. Confrontare con il baseline su un gioco mai visto.
Iterazione 4: combinazione e sfruttamento
Misurare latenza, costo, deriva, reversibilità e capacità di aggiornamento. Il punteggio migliore fuori produzione non è sempre la soluzione operativa migliore.
Quando non usare il fine-tuning
Evitare di effettuare il fine-tuning quando:
- i fatti cambiano ogni settimana;
- bisogna citare la fonte;
- il corpus è piccolo o contraddittorio;
- i diritti sono incerti;
- l'errore viene dalla ricerca;
- il bisogno può essere risolto con uno schema di uscita;
- Non esiste alcuna valutazione affidabile.
Quando non costruire un RAG
Un RAG è eccessivo per un compito di trasformazione senza conoscenza esterna, alcune regole stabili o un unico documento fornito a ogni chiamata. Aggiunge ingestione, indicizzazione, sicurezza e monitoraggio.
Guidare in base al costo per compito completato
Confrontare il costo completo: preparazione dei dati, infrastruttura, chiamate, annotazioni, reindicizzazione, addestramento, test, incidenti e manutenzione. Una soluzione meno costosa per token può costare di più se fallisce più spesso o richiede una revisione umana complessa.
La metrica utile è il costo per compito accettato, con il livello di qualità atteso.
Scegliere un metodo reversibile
Conservare prompt, corpus, valutazioni e schemi indipendentemente dal fornitore. Versionare le configurazioni e prevedere uno strato di adattamento. Un modello o un'API può evolversi, essere ritirato o cambiare prezzo.
Partitech può costruire la baseline, il pipeline RAG, il corpus di fine-tuning e la valutazione comparativa. La decisione non si basa quindi né su una moda né su una dimostrazione isolata, ma su errori misurati, dati controllati e un costo di gestione realistico.
Parliamo del tuo progetto
Costruire un benchmark confrontando prompt, RAG e fine-tuning sui vostri dati con Partitech. Contatta Partitech.