Scegliere tra RAG e fine tuning significa stabilire cosa deve fare il tuo assistente. La RAG, abbreviazione di retrieval-augmented generation, fornisce materiale di riferimento pertinente quando il modello risponde; il fine tuning consiste nell’addestrare ulteriormente un modello su esempi. Inizia testando un’istruzione chiara per il compito, cioè un prompt. Poi usa il risultato per decidere se esaminare la mancanza di materiale di riferimento, l’incoerenza dell’output o entrambe prima di commissionare altro lavoro.
Un fornitore propone di addestrare un sistema di IA per la tua azienda, mentre un altro propone una base di conoscenze consultabile. Queste descrizioni non definiscono il compito che il sistema finito dovrà svolgere né cosa costituirebbe un risultato non riuscito. Noi partiamo dalla descrizione scritta del compito. Ti offre qualcosa di concreto da confrontare quando arrivano le proposte.
Cosa cambia tra RAG e fine tuning?
La RAG cambia il materiale fornito per una risposta; il fine tuning modifica il modello attraverso l’addestramento. La guida di OpenAI sull’accuratezza distingue la mancanza di contesto da un comportamento incoerente. È una distinzione iniziale utile per chi acquista, purché si lasci spazio a esigenze che si sovrappongono. Un assistente basato su documenti potrebbe avere bisogno anche di un modo coerente di formulare la risposta.
Secondo la spiegazione delle basi di conoscenze di Amazon Bedrock, il recupero seleziona il materiale pertinente e lo include nell’input di generazione. Per un assistente proposto che risponde a domande sulla politica dei resi, chiedi di vedere quale passaggio approvato giustifica la risposta. Anche un riferimento alla fonte deve essere verificato rispetto a ciò che afferma la risposta.
Il fine tuning utilizza esempi per addestrare ulteriormente un modello su come rispondere. La guida di OpenAI lo descrive come un’opzione per migliorare il comportamento in un compito. Pensa a una nota di passaggio desiderata con una struttura concordata: il fornitore ha bisogno di esempi di note accettabili e degli input usati per produrle. Si tratta di un risultato diverso da una cartella di documenti sulle politiche.
Nessuna delle due etichette indica se la dimostrazione soddisfa i tuoi requisiti. Chiedi al fornitore di identificare cosa cambia il componente proposto, mostrare il materiale che utilizza e spiegare come verificherai il risultato. Mantieni il confronto legato al lavoro effettivo che stai acquistando.
Parti da un compito e da una dimostrazione più semplice
Descrivi l’input e l’output accettabile prima di scegliere un approccio. La guida di Anthropic sui prompt parte da criteri di successo chiari, da un test con esempi e da una bozza di prompt. Usiamo quest’ordine per preparare una specifica d’acquisto: scrivere l’istruzione, fornire materiale approvato ed esaminare cosa può fare la configurazione proposta più semplice. Questo è il nostro metodo di valutazione suggerito, non un benchmark pubblicato.
Per un assistente ai resi a scopo illustrativo, l’input potrebbe essere la domanda di un cliente e la politica applicabile. Una bozza accettabile risponde solo a ciò che la politica giustifica e affida le eccezioni a una persona. Per un passaggio commerciale a scopo illustrativo, l’input potrebbe essere una richiesta e un formato di nota approvato. L’output dovrebbe preservare il significato della richiesta e lasciare vuoti i dettagli mancanti.
Chiedi al responsabile del processo di scrivere cosa rende accettabile ogni output. Includi una richiesta che l’assistente dovrebbe rifiutare o affidare a una persona. Usa materiale che sei autorizzato a condividere, dopo aver rimosso i dati personali non necessari. Una dimostrazione che dipende da informazioni che non puoi fornire non è ancora una proposta praticabile.
Se hai già un assistente che fornisce risposte inaffidabili, usa la guida separata su come verificare perché l’IA dà risposte sbagliate prima di decidere cosa commissionare.
Scegli il prossimo test in base alla lacuna rimasta
Usa il problema osservato per scegliere cosa testare in seguito. AWS consiglia di iniziare dal recupero per le domande che fanno riferimento a documenti personalizzati e segnala la difficoltà di mantenere l’addestramento allineato a materiale che cambia spesso. Ammette inoltre l’uso congiunto di recupero e fine tuning. La tabella seguente suggerisce il prossimo test per la lacuna riscontrata nella dimostrazione.
| Cosa manca ancora alla dimostrazione | Cosa testare in seguito |
|---|---|
| Informazioni provenienti da documenti approvati e soggetti a modifiche | Un recupero che fornisca il materiale pertinente corrente |
| Un output ripetibile che resta incoerente dopo istruzioni ed esempi più chiari | Addestramento su esempi accettati, se il modello scelto lo supporta |
| Materiale di riferimento e una risposta più coerente | Una configurazione combinata, con una verifica per ogni requisito |
Quando la dimostrazione più semplice soddisfa già i requisiti, mantieni quell’opzione nel confronto. Chiedi quale ulteriore problema risolverebbero l’addestramento o il sistema di recupero proposti. La scelta può anche restare aperta mentre prepari gli input mancanti.
AWS osserva che il fine tuning non è disponibile per tutti i modelli. Chiedi al fornitore di indicare il provider e il modello, spiegare dove e come funzionerà il sistema e confermare il supporto attuale per l’addestramento e l’implementazione proposti.
Chi mantiene il sistema dopo il lancio?
Confronta le responsabilità che ogni proposta lascia al tuo team. Per il recupero, indica la persona che approva i documenti di riferimento e verifica che gli aggiornamenti raggiungano l’assistente. Per l’addestramento, indica chi prepara gli esempi accettati e riesamina le modifiche successive. Registra chi concede l’accesso, chi gestisce i problemi e come il personale riporta il compito al processo manuale quando il sistema non è adatto.
Inseriamo queste domande nella pianificazione dell’implementazione dell’IA prima di scegliere i componenti. Una specifica utile registra:
- Il compito, gli input consentiti e l’output previsto.
- Le fonti autorevoli, il loro responsabile e il processo di aggiornamento.
- Esempi di lavoro accettabile e di omissioni o aggiunte inaccettabili.
- Le condizioni per rifiutare una richiesta o affidarla a una persona.
- Le verifiche di accettazione, il revisore e il materiale da consegnare.
Per il lavoro che coinvolge un ordine o un contatto attivo, chiedi come il sistema proposto otterrà il record corrente consentito. Includi questo requisito nella parte della specifica dedicata all’integrazione CRM. Una proposta di addestramento su record esportati deve comunque spiegare come verranno gestite le modifiche successive.
Chiedi dove verranno archiviati documenti, copie ricercabili, esempi e output, chi potrà accedervi e come viene gestita la rimozione. Registra le risposte per l’implementazione effettiva. Non considerare il nome dell’architettura una decisione sull’hosting o sulle autorizzazioni.
Verifica la proposta su richieste mai viste prima
Tieni le richieste di test separate dal materiale utilizzato per configurare o addestrare il sistema proposto. Chiedi a ogni fornitore di eseguire quelle richieste rispetto agli stessi criteri di accettazione. Fai esaminare al responsabile del processo gli output, gli input usati per produrli e le correzioni necessarie. Questo verifica la proposta sul tuo compito; non dimostra le prestazioni per ogni richiesta futura.
- Mantieni una baseline. Salva ciò che producono il processo manuale e il prompt più semplice, insieme ai relativi input e alle note di revisione.
- Verifica un aggiornamento della fonte. Modifica un documento di test approvato e ripeti la domanda interessata. Chiedi al fornitore di mostrare quale versione è stata utilizzata e come l’aggiornamento ha raggiunto l’assistente.
- Verifica le regole dell’output. Riformula una richiesta e lascia fuori alcune informazioni. Controlla se la nota mantiene la struttura richiesta senza inventare dettagli.
- Testa accesso e ambito. Prova una richiesta esterna all’ambito concordato e un utente che non dovrebbe ricevere un documento riservato. Esamina il rifiuto o il passaggio effettivo.
- Registra il lavoro che il tuo team deve continuare a svolgere. Annota correzioni, tempo di revisione e chi deve mantenere i materiali. Confrontali con la baseline prima di ampliare il lavoro.
Quando una verifica fallisce, registra il requisito non soddisfatto e chiedi una dimostrazione rivista. Non pagare per un approccio più elaborato solo perché il suo nome sembra più efficace. Accetta l’ambito che puoi verificare oppure lascia il compito alle persone finché le condizioni mancanti non sono risolte.
Come possiamo aiutarti
Iniziamo scrivendo insieme il compito, i dati consentiti e le verifiche di accettazione. Poi confrontiamo gli approcci proposti rispetto a questa specifica e documentiamo chi manterrà le fonti, gli esempi e la valutazione. Un primo passo utile è scrivere una richiesta reale e approvare un esempio del risultato di cui hai bisogno.
