Personalizzare un foundation model

Tre modi per personalizzare un foundation model

Un foundation model pre-addestrato raramente risponde “out of the box” esattamente come serve al tuo caso d’uso. Esistono tre approcci principali per adattarlo, in ordine crescente di costo e complessità.

Il prompt engineering è la tecnica più semplice ed economica: non modifica il modello, ma struttura l’input. Include istruzioni chiare, esempi (few-shot vs zero-shot) e ragionamento guidato (chain-of-thought). È sempre il primo tentativo, perché non richiede né dati di training né infrastruttura.

Il RAG (Retrieval Augmented Generation) collega il modello a una fonte di conoscenza esterna: al momento della query recupera i documenti pertinenti e li inietta nel contesto. Serve quando la risposta dipende da dati proprietari o aggiornati (manuali, policy, catalogo) che il modello non ha visto in addestramento. Riduce le hallucination grazie al grounding e non richiede di riaddestrare nulla. In Amazon Bedrock si realizza con le Knowledge Bases.

Il fine-tuning modifica effettivamente i pesi del modello addestrandolo su un dataset etichettato. Serve quando ti occorre uno stile, un tono o un comportamento coerente e specifico che il prompting da solo non garantisce. È l’opzione più costosa: richiede dati di qualità, un job di training e, in Amazon Bedrock, Provisioned Throughput per ospitare il modello personalizzato.

Come scegliere

La regola pratica d’esame è: parti sempre dall’approccio più leggero e sali solo se necessario.

• Se il modello non conosce i tuoi dati o servono informazioni fresche → RAG.
• Se il problema è la forma dell’output (formato, tono, gergo di dominio) e hai molti esempi etichettati → fine-tuning.
• Se basta chiarire il compito → prompt engineering.

Attenzione a non confondere gli assi: il RAG risolve la mancanza di conoscenza, il fine-tuning risolve il comportamento. Non usare il fine-tuning per aggiungere fatti aggiornati, che diventerebbero subito obsoleti.

Valutare il modello

Personalizzare senza misurare non ha senso. La valutazione può essere automatica, con metriche calcolate su un dataset di riferimento (ground truth), oppure umana, quando la qualità è soggettiva (utilità, tono, sicurezza). Amazon Bedrock offre model evaluation con entrambe le modalità, oltre a benchmark predefiniti. Le metriche vanno scelte in base al compito: la stessa metrica non misura bene un riassunto e una classificazione. In pratica definisci un set di test rappresentativo, confronti i modelli candidati e scegli il più piccolo che supera la soglia di qualità richiesta.

Trade-off: costo, latenza, accuratezza

Ogni scelta bilancia tre dimensioni. I modelli più grandi tendono a essere più accurati, ma costano di più per token e hanno latenza maggiore; i modelli più piccoli sono rapidi ed economici. Il criterio corretto è scegliere il modello più piccolo che soddisfa i requisiti, non il più potente disponibile.

Sul piano managed vs training: con un servizio gestito come Amazon Bedrock consumi foundation model via API e ottieni fine-tuning, RAG ed evaluation senza gestire infrastruttura; addestrare o fare deploy di un modello con pieno controllo (Amazon SageMaker) dà più flessibilità ma aumenta costo operativo e competenze richieste. Per il profilo AI Practitioner la scelta di default è il servizio gestito.

Sul piano dei costi: con l’on-demand paghi a consumo (token), ideale per traffico variabile; il Provisioned Throughput riserva capacità a costo fisso ed è richiesto per i modelli custom. Prompt engineering e RAG evitano il costo di training; il fine-tuning lo aggiunge e va giustificato dal valore prodotto.

Trappole tipiche d’esame

• Servono risposte basate su documenti interni e aggiornati → soluzione: RAG con una Knowledge Base, non fine-tuning; il fine-tuning non è il modo per iniettare fatti freschi.
• Serve un tono o formato coerente su molti esempi → soluzione: fine-tuning; il prompt engineering da solo non garantisce costanza a scala.
• Ridurre costo e latenza mantenendo qualità accettabile → soluzione: scegli il modello più piccolo che supera la soglia, non il più grande.
• “Costruire il proprio modello” o infrastruttura sotto pieno controllo → soluzione: Amazon SageMaker (training/controllo completo) vs Amazon Bedrock (managed, foundation model via API); per l’AI Practitioner il default è gestito.
• Traffico costante e prevedibile su un modello custom → soluzione: Provisioned Throughput; l’on-demand conviene per carichi variabili o sperimentazione.
• Dimostrare che la personalizzazione funziona → soluzione: definisci metriche e un dataset di valutazione (automatica o umana) prima di andare in produzione, poi decidi sulla soglia.