Amazon MLA-C01: IA generativa e modelli fondazionali — Guida allo studio

By Laurynas Brazys · 3 August 2026 · #amazon #mla-c01 #certification #exam-prep #study-guide

Fa parte della AWS Machine Learning Engineer Associate MLA-C01 — Guida allo studio. Esercitati con risposte verificate nel centro esami Amazon, oppure fai test cronometrati su ExamRoll.io.

Concetto fondamentale

I modelli di base (foundation model) sono grandi reti pre-addestrate, tipicamente basate su architettura transformer, che forniscono rappresentazioni generiche per il linguaggio, la visione o multimodali. La messa in produzione pratica richiede di trasformare queste ampie capacità in comportamenti specifici per l’applicazione tramite tre leve ortogonali: il prompt engineering in fase di inferenza, la retrieval-augmented generation (RAG) per ancorare gli output a conoscenze aggiornate o specifiche del dominio, e la personalizzazione del modello tramite fine-tuning o tecniche parameter-efficient. Amazon Bedrock fornisce un percorso gestito per invocare modelli di base di terze parti e forniti da Amazon tramite un’API unificata, astraendo la selezione del modello ma preservando il controllo sugli input, sui parametri del modello (temperature, top_p, max_output_tokens) e sulla gestione della risposta. SageMaker JumpStart integra Bedrock fornendo pacchetti con artefatti di modelli pre-addestrati, script di addestramento e ricette di fine-tuning che vengono eseguiti su container di SageMaker Training o Hugging Face, abilitando flussi di lavoro di adattamento riproducibili e l’integrazione con il model registry.

Il fine-tuning si presenta in diverse varianti che bilanciano le esigenze di calcolo e di dataset con la fedeltà dell’adattamento. Il full fine-tuning aggiorna tutti i pesi del modello e spesso produce le migliori prestazioni per compiti specifici, ma richiede grandi flotte di GPU e spazio di archiviazione per i checkpoint. Le tecniche di parameter-efficient fine-tuning (PEFT) come LoRA (low-rank adapters), i moduli adapter o QLoRA (quantized low-rank adapters) riducono drasticamente la memoria GPU e il tempo necessario, iniettando e addestrando un piccolo numero di parametri aggiuntivi, compatibili con l’addestramento su SageMaker utilizzando Hugging Face e bitsandbytes per la quantizzazione a 8 o 4 bit. Il reinforcement learning from human feedback (RLHF) è una pipeline più complessa: si raccolgono etichette di preferenza umana a coppie, si addestra un modello di ricompensa (reward model) (un passo di apprendimento supervisionato che usa SageMaker Training e un ModelPackage), e si ottimizza il modello di policy con RL on-policy (PPO o simili), archiviando i rollout e i checkpoint in S3 e monitorando i segnali di ricompensa con SageMaker Debugger.

Le architetture RAG collegano i modelli di base con corpora aggiornati per ridurre le allucinazioni. La pipeline RAG tipica effettua l’embedding del testo della query con un modello di embedding (l’API Bedrock Embeddings o un embedder Hugging Face su SageMaker), esegue una ricerca vettoriale nearest-neighbor in un indice (Amazon OpenSearch Service con k-NN, Amazon Kendra o DB vettoriali di terze parti), recupera i primi k documenti e condiziona il LM con il contesto recuperato tramite template di prompt e parametri di decodifica controllati. La gestione dell’aggiornamento e della pertinenza dei dati richiede la re-ingestione e la re-indicizzazione periodica delle fonti utilizzando AWS Glue, AWS Lambda per aggiornamenti in streaming o AWS DMS per fonti transazionali, e l’archiviazione di metadati di provenienza (source_id, document_id, ingestion_time) insieme ai vettori per garantirne la tracciabilità (auditability).

Servizi chiave e configurazione

Amazon Bedrock espone l’API InvokeModel, le cui richieste includono l’identificativo del modello e i parametri di runtime: si passano gli header modelId, contentType e accept, un body contenente i prompt o l’inputText, e i modelParameters come temperature, topP e maxOutputTokens. Utilizzare messaggi strutturati di sistema (system) e utente (user) per separare le istruzioni basate sul ruolo e vincolare i formati di output; imporre sequenze di interruzione (stop sequences) e max_output_tokens per limitare la latenza e i costi. Per la generazione di embedding, utilizzare l’endpoint di embedding di Bedrock o un container di inferenza Hugging Face su SageMaker e persistere i vettori in OpenSearch, Kendra o un DB vettoriale esterno.

SageMaker JumpStart fornisce notebook preconfigurati e pipeline di fine-tuning che si collegano a CreateTrainingJob con parametri API concreti: TrainingJobName, AlgorithmSpecification (TrainingImage, TrainingInputMode), RoleArn, InputDataConfig (S3Uri, DataSource), OutputDataConfig (S3OutputPath), ResourceConfig (InstanceType, InstanceCount, VolumeSizeInGB) e StoppingCondition (MaxRuntimeInSeconds). Per la governance dei modelli, utilizzare SageMaker Model Registry e CreateModelPackage/CreateModelPackageGroup con ApprovalStatus impostato su “PendingManualApproval”; integrare la promozione dei modelli nel CI/CD utilizzando l’attributo ApprovalStatus insieme ad AWS CodePipeline o AWS Step Functions e un’azione di approvazione manuale (ManualApproval) per controllare i rilasci (deployment). Per il monitoraggio continuo e il rilevamento di bias, distribuire SageMaker Model Monitor tramite CreateMonitoringSchedule con MonitoringScheduleConfig e BaselineConfig; utilizzare SageMaker Clarify attraverso le API di ProcessingJob (ClarifyProcessor.run_pre_training_bias e run_post_training_bias) per calcolare le metriche di bias del dataset e produrre baseline archiviate in S3.

Per la ricerca vettoriale e RAG, scegliere la tecnologia di indicizzazione e ricerca in base alla scala e alla latenza delle query. Amazon OpenSearch Service supporta il plugin k-NN e fornisce API REST e controllo degli accessi granulare; Amazon Kendra offre una ricerca semantica di livello enterprise con connettori per S3, SharePoint e RDS. Utilizzare i crawler di AWS Glue per costruire un Data Catalog centrale e AWS Lake Formation per applicare un controllo degli accessi granulare e l’isolamento dei dati di addestramento in S3, assicurando che vengano applicati IAM, policy dei bucket e crittografia (SSE-S3 o SSE-KMS).

Pattern di progettazione e compromessi

Quando si personalizzano i foundation model, è necessario decidere tra il fine-tuning offline e il prompt engineering a runtime. Il fine-tuning completo massimizza le prestazioni per compiti specifici ma aumenta la complessità operativa: i processi di training richiedono grandi flotte di GPU, training distribuito su più nodi (utilizzando SageMaker DistributedDataParallel o Horovod in Script Mode), il checkpointing su S3 tramite

undefined

, e successivamente la quantizzazione e la conversione per un’inferenza efficiente. Gli approcci PEFT come LoRA mantengono congelata la maggior parte dei pesi del modello, riducendo drasticamente i tempi di training, consentendo scansioni degli iperparametri (hyperparameter sweeps) più economiche e semplificando il rollback poiché il modello di base rimane intatto. Per l’inferenza, gli endpoint gestiti da Bedrock alleviano l’onere operativo per gli FM di terze parti, mentre gli endpoint in tempo reale di SageMaker offrono un controllo più approfondito: si possono usare i MultiModelEndpoints per servire più modelli da una singola istanza, la Serverless Inference per traffico imprevedibile, o endpoint provisioned con auto-scaling e provisioned concurrency per ridurre i cold start.

La RAG introduce complessità nel mantenere aggiornato l’indice e nel bilanciare il recupero delle informazioni (retrieval) rispetto alle allucinazioni (hallucination). Un pattern semplice è il recupero ibrido (hybrid retrieval): prima si esegue una ricerca vettoriale (semantica), poi si applica un filtro per parole chiave per garantire la precisione. È opportuno memorizzare i metadati dei chunk di documenti in modo che la fase di generazione possa citare le fonti e facilitare i controlli di Model Monitor sulla frequenza delle allucinazioni. Per le applicazioni sensibili alla latenza, si consiglia di collocare nello stesso luogo (co-locate) il calcolo degli embedding e l’indice (inferenza SageMaker + OpenSearch nello stesso VPC) e di utilizzare l’indicizzazione approximate nearest neighbor (ANN) per scambiare la recall con la velocità.

L’RLHF presenta un’elevata complessità (high-friction) ma è necessario quando è richiesto l’allineamento ai valori umani o alla sicurezza. La pipeline richiede strumenti per l’annotazione, training della ricompensa (reward training) riproducibile con le API Estimator di SageMaker e ottimizzatori RL stabili (implementazioni di PPO nelle famiglie RLlib o Stable Baselines). Il costo e l’instabilità dell’RLHF devono essere soppesati rispetto alla capacità di correggere comportamenti che non possono essere codificati come una funzione di perdita (loss) statica.

Errori comuni e criteri decisionali

Un errore frequente è fare affidamento esclusivamente sui prompt per correggere errori sistematici che richiedono un adattamento a livello di modello; i prompt possono aiutare ma non sostituiscono il fine-tuning o la RAG per il radicamento nel dominio (domain grounding). Un’altra trappola è sottovalutare la governance: mettere in produzione sistemi generativi richiede la tracciabilità del modello (SageMaker Model Registry), il rilevamento automatico del drift (baseline di Model Monitor e Clarify) e un flusso di lavoro per l’approvazione (ApprovalStatus + approvazione manuale in CodePipeline). Per gli archivi di embedding, scegliere un indice vettoriale senza metadati o informazioni sulla provenienza rende costosi gli audit successivi e l’analisi degli errori.

La decisione sull’hosting del modello deve bilanciare il controllo e l’overhead operativo. Utilizzare Bedrock quando si desidera un accesso gestito a diversi modelli di base (foundation models) performanti senza dover gestire la flotta di istanze per l’inferenza. Utilizzare gli endpoint di SageMaker quando si necessita di stack di inferenza personalizzati, isolamento tramite VPC o piena integrazione con Model Registry e Model Monitor. Per i metodi di fine-tuning, si sceglie PEFT quando la dimensione del dataset è modesta e l’iterazione rapida è importante; si opta per il full fine-tuning quando il dominio richiede un profondo cambiamento rappresentazionale e si dispone del budget per le GPU.

Problema Pratico: Scenario d’Uso

Azienda: AuroraPayments — sfida: implementare un assistente per il rilevamento delle frodi a bassa latenza e verificabile (auditable), che sintetizzi il contesto delle transazioni e i documenti normativi per spiegare i punteggi sospetti e supporti aggiornamenti controllati del modello.

Aggregazione e archiviazione dei dati: utilizzare AWS Glue per eseguire il crawling dei log delle transazioni su S3 e configurare AWS DMS per replicare le tabelle MySQL on-premise su Amazon RDS o S3. Registrare tutte le origini dati nell’AWS Glue Data Catalog e applicare le policy di Lake Formation. Motivazione: Glue fornisce un ETL serverless e un catalogo unificato per il recupero dati a valle, mentre Lake Formation garantisce l’isolamento dell’accesso a S3.
Ingegneria delle feature e rilevamento delle anomalie: inserire le feature in SageMaker Feature Store per garantire coerenza tra offline e online. Eseguire il rilevamento automatico delle anomalie utilizzando Amazon Lookout for Metrics sulle serie temporali delle transazioni e visualizzare le dashboard in Amazon QuickSight. Motivazione: Feature Store garantisce feature riproducibili per l’addestramento e l’inferenza; Lookout for Metrics automatizza il rilevamento delle anomalie e QuickSight fornisce la visualizzazione per gli analisti di business.
Addestramento del modello e gestione dello sbilanciamento: addestrare un classificatore XGBoost utilizzando l’algoritmo XGBoost integrato in SageMaker con iperparametri e impostare scale_pos_weight su (num_negative/num_positive) per correggere lo sbilanciamento delle classi. Utilizzare CreateTrainingJob di SageMaker Training con ResourceConfig ottimizzato per le dimensioni dell’addestramento e abilitare il checkpointing su S3 per la tolleranza ai guasti. Motivazione: XGBoost è efficace per compiti di rilevamento frodi su dati tabellari; scale_pos_weight richiede un overhead operativo minimo rispetto al sovracampionamento sintetico (synthetic oversampling).
Registro dei modelli, approvazione e deployment: registrare gli artefatti del modello in SageMaker Model Registry con CreateModelPackage/ModelPackageGroupName e impostare ApprovalStatus su “PendingManualApproval”. Implementare una CodePipeline che attivi un’azione di approvazione, per poi distribuire le versioni approvate su endpoint real-time di SageMaker con MultiModel endpoint o Istanze Provisionate dietro un gruppo di Auto Scaling. Motivazione: Model Registry mantiene un versioning centralizzato e la Governance; l’approvazione manuale tramite CodePipeline impone rilasci autorizzati.
Spiegabilità e RAG per il radicamento nelle policy: creare embedding dei documenti normativi con Bedrock o un modello di embedding Hugging Face su SageMaker, indicizzarli in Amazon OpenSearch k-NN con metadati, e implementare un flusso RAG in cui un prompt per una transazione sospetta includa i top-k frammenti di policy recuperati più un template che istruisce il modello di base a citare le fonti e a generare una spiegazione leggibile dall’uomo. Motivazione: la RAG fonda le spiegazioni su documenti autorevoli e OpenSearch fornisce una ricerca vettoriale scalabile all’interno del perimetro di sicurezza.
Monitoraggio e riaddestramento: abilitare SageMaker Model Monitor con una baseline derivata dalla validazione iniziale e pianificare l’esecuzione on-demand di ProcessingJobs di Clarify per controlli di bias post-deployment. Se Model Monitor segnala un drift (cambiamento distributivo nelle feature o nei label), attivare una SageMaker Pipeline che esegua l’ingestion dei dati, effettui un riaddestramento con fine-tuning LoRA (se si utilizza un encoder di un modello di base per le feature testuali), valuti il modello e lo inserisca nel registro con lo stato PendingManualApproval. Motivazione: il monitoraggio continuo con pipeline automatizzate mantiene sotto controllo le prestazioni e la conformità del modello, preservando al contempo il controllo manuale sulle modifiche in produzione.