Il catalogo modelli di Foundry

Azure AI Foundry mette a disposizione un model catalog: un punto unico da cui esplorare modelli di provider diversi (modelli Azure OpenAI, modelli open e di terze parti). Ogni modello è descritto da una model card che riassume le caratteristiche chiave: il tipo di task (generazione testo, chat, embedding, vision, ecc.), la modalità (testo, immagini, audio, multimodale), la dimensione del context window, le lingue supportate, la licenza e le opzioni di deployment disponibili.

Per l’esame conta memorizzare il flusso concettuale: prima si sceglie il modello dal catalogo, poi lo si deploya ottenendo un endpoint, infine lo si valuta sul proprio caso d’uso. Ricorda che il passing score dell’esame è 700 su 1000.

Criteri di model selection

La scelta non si fa “a intuito” ma bilanciando alcuni trade-off ricorrenti:

  • Task e modalità: un embedding model non serve a generare risposte in chat; un modello solo-testo non elabora immagini. Il primo filtro è sempre “cosa deve fare”.
  • Qualità vs costo vs latenza: i modelli più grandi tendono a rispondere meglio ma costano di più e sono più lenti. Per casi semplici un modello più piccolo è spesso la scelta corretta.
  • Context window: se l’input è lungo (documenti, cronologie di conversazione) serve una finestra di contesto adeguata.
  • Compliance, data residency e fine-tuning: alcuni scenari richiedono un modello che supporti il fine-tuning o un particolare tipo di hosting.

Foundry facilita il confronto mostrando benchmark e metriche comparative nelle model card, così da restringere la rosa prima ancora di deployare.

Deployment e endpoint

Deployare significa rendere il modello raggiungibile per l’inferenza. Concettualmente Foundry offre più modalità:

  • Serverless API (models as a service): si paga a consumo (tipicamente per token), senza gestire infrastruttura. Ideale per partire in fretta o per carichi variabili.
  • Managed compute: il modello gira su risorse di calcolo dedicate che si provisionano; si paga la capacità riservata. Utile per throughput costante e maggiore controllo.
  • Deployment dei modelli Azure OpenAI all’interno del relativo servizio.

In tutti i casi il risultato è lo stesso concetto: un endpoint, cioè un URL a cui l’applicazione invia le richieste, protetto da una chiave o da autenticazione Microsoft Entra. L’endpoint disaccoppia l’app dal modello: si può aggiornare o sostituire il modello dietro l’endpoint senza riscrivere l’applicazione. Nota che il deployment name è distinto dal nome del modello sottostante: l’app chiama il deployment, non il modello “per nome”. Per i dettagli operativi (parametri e comandi esatti) fai riferimento alla documentazione ufficiale, poiché Foundry è un prodotto in rapida evoluzione.

Model evaluation

Scegliere e deployare non basta: bisogna verificare che il modello risponda bene sul proprio caso d’uso. Foundry supporta la valutazione con approcci complementari:

  • Benchmark del catalogo: metriche pubbliche per un primo confronto rapido tra modelli.
  • Valutazione su dati propri: si esegue il modello su un dataset di test e si misurano metriche di qualità come groundedness (aderenza alle fonti), relevance, coherence, fluency e similarity, oltre a metriche di sicurezza e rischio sui contenuti.
  • Valutazione manuale: revisione umana delle risposte, utile quando le metriche automatiche non bastano.

La valutazione è iterativa: si confronta, si sceglie, si testa e — se serve — si torna al catalogo. È anche il modo corretto per giustificare un cambio di modello (ad esempio verso uno più economico) misurando che la qualità resti accettabile.

Trappole tipiche d’esame

  • Serve solo generare vettori per la ricerca semantica → soluzione: scegli un embedding model, non un modello di chat/generation: sono task diversi.
  • L’app deve elaborare sia testo sia immagini → soluzione: serve un modello multimodale (vision), non un modello solo-testo per quanto potente.
  • Voglio confrontare due modelli senza scrivere codice → soluzione: parti dai benchmark del catalogo; per una scelta affidabile sul tuo caso, valuta poi su dati tuoi.
  • Carico incerto e voglio partire subito senza gestire infrastruttura → soluzione: serverless API a consumo, non managed compute con capacità riservata.
  • L’app va in errore dopo aver cambiato modello → soluzione: verifica endpoint, deployment name e chiave: l’app chiama il deployment, non il modello “per nome”.
  • Devo ridurre i costi mantenendo la qualità → soluzione: passa a un modello più piccolo, ma conferma con una model evaluation su dati reali prima della produzione.