Processo di migrazione del modello

Questo articolo descrive un processo in sei fasi per la migrazione di un carico di lavoro basato su LLM da un modello di base a un altro: cosa considerare in ogni fase, che Microsoft funzionalità Foundry si applicano e come cambia il lavoro per diversi tipi di team.

Significato della migrazione del modello

Ogni modello eseguito nell'ambiente di produzione ha una data di ritiro. Quando un modello da cui dipende viene sostituito o quando un modello più recente serve meglio il carico di lavoro, si esegue la migrazione. Lo scambio di un modello non è una modifica a una riga: un modello diverso può spostare tranquillamente il tono, la formattazione, la forma JSON, latenza, il costo o il comportamento delle chiamate agli strumenti e suddividere il codice downstream che dipende dal comportamento precedente.

Una migrazione riuscita mantiene il comportamento dell'applicazione o lo migliora in modi misurabili. Il successo richiede un processo ripetibile per rilevare la deriva, adattarsi in modo sicuro e dimostrare la qualità prima dell'implementazione generale.

Quando eseguire la migrazione

Una migrazione viene in genere avviata per uno dei quattro motivi seguenti:

• Un modello viene ritirato. In Foundry, ogni modello disponibile a livello generale viene fornito con una data di ritiro e le famiglie meno recenti vengono sostituite nel tempo. Per informazioni sui criteri di ritiro e sulle relative date, consultare il ciclo di vita e i criteri di supporto dei modelli Foundry e il calendario di ritiro dei modelli.
• È disponibile un modello migliore. Un modello più recente offre una qualità più elevata, un costo inferiore, una latenza migliore o una funzionalità (ad esempio l'output strutturato o una chiamata agli strumenti migliorata) necessaria per il carico di lavoro.
• Un problema di costo o latenza forza una modifica. La latenza o costo unitario del modello corrente non soddisfa più le esigenze.
• Un gap di capacità blocca il prodotto. Il modello corrente non può eseguire un'operazione necessaria per il prodotto.

Cosa accade alla data di ritiro

Ciò che Azure fa quando un modello viene ritirato dipende dalla modalità di acquisto della capacità e Foundry usa una terminologia diversa per ogni percorso:

• Le distribuzioni Standard, Standard globale e Standard della zona dati (con pagamento in base al consumo) vengono aggiornate automaticamente secondo una pianificazione in sequenza in base all'area geografica. Puoi controllare la tempistica con versionUpgradeOption impostato su uno dei seguenti valori: OnceNewDefaultVersionAvailable, OnceCurrentVersionExpired o NoAutoUpgrade (il che significa che la distribuzione smette di funzionare al momento del ritiro). L'elaborazione della priorità segue lo stesso percorso.
• Le distribuzioni con provisioning (PTU)non vengono aggiornate automaticamente. È possibile eseguirne la migrazione in posizione (il traffico viene spostato nell'arco di 20-30 minuti senza tempi di inattività) o affiancata (si prepara la nuova distribuzione, la si testa, si reindirizza il traffico e si elimina quella precedente).
• Le distribuzioni batch seguono l'approccio affiancato: distribuire il nuovo modello, inviare nuovamente i processi, rimuovere la distribuzione precedente.

Indipendentemente dal percorso applicato, la sfida per gli sviluppatori è la stessa: in una data impostata, il traffico inizia a raggiungere un modello diverso. Un endpoint che risponde ancora non significa che l'app si comporti ancora correttamente, quindi sia i carichi di lavoro aggiornati automaticamente che i carichi di lavoro migrati manualmente traggono vantaggio dalla valutazione e dalla convalida descritti in questo articolo.

Eseguire la migrazione prima della data di ritiro

L'aggiornamento automatico è solo una rete di sicurezza per le distribuzioni con pagamento in base al consumo, non un piano di migrazione. Le distribuzioni di cui è stato effettuato il provisioning non dispongono di rete di sicurezza. In entrambi i casi, non è un sostituto di un piano di migrazione. Due impegni relativi alle policy ti consentono di eseguire la migrazione secondo le tue tempistiche invece di aspettare la scadenza:

• Il modello di sostituzione diventa disponibile circa 90 giorni prima del ritiro in Global Standard e circa 30 giorni prima del ritiro nelle aree con provisioning in cui il predecessore viene ritirato. Usare questa finestra per valutare il nuovo modello ed eseguire la migrazione manuale.
• Le date di ritiro non sono estendibili. Non esiste alcuna procedura di eccezione, quindi una data che non avevi previsto si applica comunque a te.

Non hai bisogno di un avviso di deprecazione per iniziare. Se un modello più recente è più economico, più veloce o più potente, fatelo passare subito attraverso il processo. La migrazione trasforma deliberatamente la data di ritiro in una formalità. Poiché le migrazioni si ripetono, vale la pena rendere ripetibile il processo.

Chi deve usare il processo di migrazione

Il processo di migrazione si adatta meglio quando il team compila una funzionalità basata su LLM all'interno di un prodotto o una piattaforma più grande, esegue la migrazione su una cadenza approssimativamente trimestrale e ha un proprietario chiaro (ad esempio un team della piattaforma centrale o il team dell'app) che esegue ogni migrazione deliberatamente.

Questo processo è adatto anche ai team nativi dell'intelligenza artificiale, in cui il modello è il prodotto. Le fasi sono le stesse, ma vengono eseguite più velocemente e spesso in parallelo anziché in sequenza rigorosa.

Il processo presume che si stia passando tra modelli di base, ossia modelli che si distribuiscono così come sono pubblicati nel catalogo dei modelli, senza personalizzazione a livello dei pesi. I carichi di lavoro ottimizzati in modo specifico sono esclusi dall'ambito di applicazione. Non possono essere aggiornati automaticamente, poiché seguono una propria tempistica per il training e la rimozione della distribuzione. L'adattamento dei carichi di lavoro sottoposti a fine-tuning richiede la sintesi o la ripetizione del training, anziché modifiche al prompt e allo schema. Se si eseguono distribuzioni di modelli sottoposti a fine-tuning, pianificare fin da subito un nuovo fine-tuning sul modello di base sostitutivo.

Fasi di migrazione

Una migrazione passa attraverso sei fasi. Ogni fase produce un output usato dalla fase successiva. Le fasi di migrazione sono:

Individuare → valutare → adattare → convalidare → implementare → ritiro

La tabella seguente descrive ogni fase e le funzionalità e gli strumenti di Foundry che supportano ciascuna fase. Le funzionalità sono disponibili sia in Microsoft Foundry che in Azure OpenAI, a meno che non sia contrassegnato solo Foundry, il che significa che Azure OpenAI non ha un equivalente.

Le sezioni per fase più avanti in questo articolo spiegano perché ogni fase esiste, come appare un risultato positivo, cosa considerare, quando usare ogni funzionalità e dove la fase si interrompe comunemente.

Prima di eseguire la migrazione: Preparare un set di dati di test

Questo passaggio di preparazione assembla un set di input rappresentativi, output previsti e criteri di esito positivo concordato prima dell'inizio di qualsiasi lavoro di migrazione. Questo insieme è un prerequisito vincolante per la parte centrale del processo: non è possibile rieseguire la fase di adattamento senza input e non è possibile attribuire un punteggio nella fase di convalida senza verità fondamentale e criteri.

Cosa prendere in considerazione

• Compilare il set di dati prima di selezionare una destinazione. Il set di dati descrive il carico di lavoro, non il modello candidato, quindi è possibile assemblarlo in parallelo con Discover.
• Raccogliere input da origini reali o sintetiche. Usare il traffico di produzione raccolto o esempi di dominio selezionati in formato CSV o JSONL. Quando non si dispone ancora di dati rappresentativi, generare input sintetici e antagonisti con il simulatore.
• Acquisire la strumentazione prima che serva. L'acquisizione dei contenuti in produzione è su adesione esplicita e non è mai retroattiva, quindi non puoi valutare il traffico che non hai registrato. Avviare la registrazione di richieste, risposte, latenza e conteggi dei token.
• Bloccare il set di dati. Mantenere gli input, le verità sul terreno e i criteri di esito positivo fissi per l'intera migrazione. Se uno di essi cambia, non è più possibile confrontare i risultati di origine e di destinazione.

È anche necessario un inventario delle distribuzioni del modello usate dal carico di lavoro, inclusi i relativi tipi di distribuzione (Standard, Provisioned o Batch). Per ogni modello di origine, annotare la data di ritiro e suggerire la sostituzione dalla pianificazione del ritiro del modello.

Fase 1: Individuazione

Lo scopo della fase di individuazione è riconoscere che una modifica del modello sta arrivando o vale la pena e decidere se agire. L'output è una decisione go/no-go e rimanere sul modello corrente è una scelta valida. Un esito positivo è un segnale tempestivo e strutturato che fornisce la data di deprecazione, il modello sostitutivo e la finestra di migrazione, oppure una decisione deliberata di rimanere con il modello corrente.

Cosa prendere in considerazione

• Qual è la data di ritiro e quanto pista hai effettivamente? Considera la data di deprecazione, al netto del tempo necessario per la convalida e la distribuzione, come la vera scadenza.
• Esiste una sostituzione consigliata specifica oppure devi stilare tu stesso una rosa ristretta di candidati?
• La modifica comporta vincoli di conformità o regionali (per carichi di lavoro regolamentati, disponibilità e certificazione spesso è importante prima della qualità)?

Dove si interrompe comunemente

I team vengono a conoscenza delle dismissioni in modo incoerente, tramite un'email, un banner nel portale o un messaggio interno, e colgono il segnale troppo tardi. Questo ritardo riduce ulteriormente un margine di tempo già ridotto. Gli sviluppatori solisti e i piccoli team spesso individuano un ritiro da un errore di produzione anziché da un annuncio.

Cosa porti

La pianificazione della rimozione e l'API Modelli espongono i dati in un contratto stabile. Le organizzazioni mature aggiungono un sottile livello di notifica interno sopra per instradarlo ai proprietari corretti.

Fase 2: Valutare

Lo scopo della fase di valutazione è scegliere il modello di destinazione candidato e verificare che sia possibile eseguirlo: l'area corretta, il tipo di distribuzione corretto, la quota sufficiente e la disponibilità insieme al modello corrente in modo che il rollback rimanga possibile. Un risultato positivo è una scelta chiara tra i modelli candidati, con area, SKU, quota e costi confermati prima dell'avvio dell'ottimizzazione.

Cosa prendere in considerazione

• Qualità e posizionamento tra candidati. Quando diversi modelli sono in uso, decidi quale si adatta al tuo carico di lavoro in base alla qualità, non solo quale ottiene il punteggio più alto in un benchmark pubblico.
• Costo del traffico personale. La struttura dei prezzi cambia tra generazioni di modelli. I token di ragionamento, l'input memorizzato nella cache e il sovraccarico dell'output strutturato possono incidere sull'economia unitaria fino al doppio o più, quindi stima il costo mensile in base al traffico storico anziché basarti solo sul prezzo di listino.
• Disponibilità operativa. Confermare l'area geografica, lo SKU e la quota e verificare che la destinazione possa essere eseguita in modalità affiancata con l'origine, in modo da mantenere una possibilità di rollback.
• Controllo della conformità. Per i carichi di lavoro regolamentati, la certificazione e la disponibilità a livello di area possono filtrare l'elenco dei candidati prima che la qualità entri nella conversazione.

Dove si interrompe comunemente

La paralisi della scelta subentra quando diversi candidati hanno un posizionamento poco chiaro. I team si accorgono solo a metà della pianificazione che il modello scelto non è disponibile nella loro area geografica o per il loro SKU. In alternativa, una proiezione di costi rivela che il nuovo modello è materialmente più costoso sul traffico reale.

Cosa porti

I benchmark sono calcolati su set di dati pubblici, quindi considerare la classifica come un filtro anziché il traguardo finale e verificare la lista dei finalisti in base al carico di lavoro. Per la proiezione dei costi vale lo stesso discorso: la vista mensile deriva dai tuoi log dei token, il che è semplice una volta che si dispone dei dati sul traffico.

Fase 3: Adattare

Lo scopo della fase di adattamento è quello di rendere il carico di lavoro ottimale sul nuovo modello. Riprodurre prima il carico di lavoro esistente invariato (per isolare le modifiche del comportamento basate su modello), diagnosticare gli spostamenti, quindi riprogezionare in modo iterativo. Un risultato positivo è un confronto di comportamenti side-by-side rispetto al traffico reale o rappresentativo, con ogni modifica rilevata.

Adapt è molto più della semplice modifica dei prompt

I prompt sono l’aspetto più visibile, ma una migrazione di solito ne coinvolge altri quattro:

• Parametri.temperature, top_p, max_tokens, e i controlli dello sforzo di ragionamento non corrispondono in modo univoco nelle diverse generazioni e le famiglie di modelli più recenti potrebbero non supportare alcuni parametri.
• Definizioni degli strumenti. Potrebbe essere necessario riformulare o restringere i nomi degli argomenti, le descrizioni e i campi obbligatori che hanno guidato in modo affidabile il modello precedente.
• Schemi di output. I modelli differiscono in base al modo in cui rispettano l'output strutturato. Potrebbe essere necessario aggiungere vincoli espliciti a uno schema soddisfatto in modo libero dal modello precedente oppure potrebbe essere infine possibile applicare uno schema.
• Prefisso telefonico. Differenze nella superficie dell'API e nell'SDK (Chat Completions rispetto a Responses, struttura dello streaming e campi di richiesta nuovi o rinominati). Potrebbe anche essere necessario aggiornare l'analisi downstream che presuppone la forma precedente della risposta.

Per i carichi di lavoro basati su agenti e sui flussi di lavoro, il lavoro relativo agli schemi e alle chiamate agli strumenti spesso supera quello sui prompt.

Cosa prendere in considerazione

• Riprodurre senza modifiche prima di ottimizzare. Eseguire la configurazione corrente nel modello di destinazione senza alcuna modifica. Questo approccio consente di separare il comportamento modificato dal modello rispetto alle modifiche introdotte e fornisce una baseline.
• Guarda cosa cambia effettivamente. Verbosità, profondità di ragionamento, aderenza all’output strutturato, formato delle chiamate agli strumenti, modalità di rifiuto e variabilità della latenza cambiano spesso.
• Riprodurre tracce reali per intercettare le regressioni delle chiamate agli strumenti. Campi aggiuntivi, argomenti rinominati e superficie di sequenza modificata solo in tracce reali, non in benchmark a turno singolo.
• Tenere traccia delle modifiche. La reingegnerizzazione dei prompt è facile da creare e facile da vanificare. Mantenere l'originale e registrare cosa è cambiato e perché.

Funzionalità di Foundry

Tre funzionalità foundry supportano questa fase:

• Prompt Optimizer è il pulsante Ottimizza direttamente sotto il campo delle istruzioni di sistema nel playground di Agent. Ristrutturare le istruzioni usando procedure consigliate per la progettazione dei prompt, mostra il ragionamento per paragrafo per ogni modifica e supporta un ciclo di iterazione: aggiungere un suggerimento come "mantenere esattamente lo schema JSON" e ottimizzare di nuovo. Disponibile solo in Foundry, non in Azure OpenAI.
• L'ottimizzazione dell'agente ottimizza le istruzioni, gli strumenti e la selezione del modello insieme per i carichi di lavoro degli agenti. Disponibile solo in Foundry, non in Azure OpenAI.
• Il simulatore genera input sintetici e antagonisti quando non sono presenti dati di produzione da riprodurre.

Dove si interrompe comunemente

Per i carichi di lavoro incorporati e destinati al prodotto, questa fase richiede in genere il tempo più lungo perché il ciclo di diagnosi è manuale: i team eseguono di nuovo le richieste, confrontano le differenze e raramente registrano le modifiche o il motivo.

Cosa porti

• Iniziare con gli ottimizzatori, quindi verificare. Applicano procedure consigliate generali in un singolo passaggio anziché adattarsi al set di dati e ottimizzano il testo delle istruzioni anziché le definizioni degli strumenti o gli schemi di output. Considerare l'output come una bozza solida: copiare prima il prompt originale (non c'è una cronologia delle versioni), quindi rivalutare il dataset congelato prima di fidarsi della modifica.
• Pianificare un lavoro pratico aggiuntivo per spostamenti tra famiglie. Non esiste un flusso del tipo "ottimizza per il modello di destinazione X", quindi passare da una famiglia di modelli all’altra richiede una traduzione esplicita del prompt e dello schema.
• Registra il traffico prima che ti serva. Replay è efficace solo quanto l'acquisizione che effettui, e l'acquisizione dei contenuti deve essere attivata esplicitamente e non è mai retroattiva.

Fase 4: Convalidare

Lo scopo della fase di convalida è decidere se il carico di lavoro adattato è sicuro da spedire classificandolo in base a una rubrica di qualità in un set di dati curato. La griglia di valutazione può essere basata su regole, su riferimenti, su un LLM usato come giudice, sulla revisione umana o su un framework specifico per il dominio. Un esito positivo consiste nel fornire una suite di valutazione affidabile, eseguita su un set di dati congelato, di cui si fidano sia il team dell'app sia gli eventuali revisori.

Validate è una fase, ma ha due punti di tocco, quindi non considerarlo come un singolo evento end-of-line:

• Prepara in anticipo. Blocca il dataset e i criteri di successo in Prima della migrazione, prima dell'adattamento. Nel momento in cui questi elementi cambiano, sorgente e destinazione smettono di essere comparabili.
• Controllo posticipato, in due passaggi. Per prima cosa, eseguire il modello corrente sull'insieme congelato per stabilire una baseline di riferimento, il valore da superare. Assegna quindi un punteggio al target sullo stesso set e decidi.

Cosa prendere in considerazione

• Mantenere bloccato il set di dati e i criteri. Questa è la singola disciplina più importante nel processo per mantenere i risultati confrontabili.
• Misura le tre dimensioni che determinano l'approvazione finale: qualità (punteggi del valutatore o del revisore), latenza (tempo al primo token e throughput, considerati solo per la chiamata di cui stai eseguendo la migrazione) e costo (costo dei token di input e output per richiesta).
• Trovare la corrispondenza tra la rubrica e il carico di lavoro. Una griglia per la sintesi clinica, un’asserzione sulla sequenza di chiamata degli strumenti per gli agenti o segnali preesistenti di feedback degli utenti potrebbero essere più significativi di un punteggio generico.
• Considerare il controllo alla stregua di un segnale per i team nativi dell'intelligenza artificiale. Anziché una valutazione una tantum con esito positivo/negativo, la valutazione viene eseguita continuamente, a ogni commit, e si integra con l'implementazione.

Funzionalità di Foundry

Due funzionalità di Foundry supportano questa fase:

• Azure AI Evaluation SDK include più di 30 valutatori predefiniti, che coprono fondatezza, pertinenza, recupero, coerenza, fluenza, metriche basate su riferimenti (F1, BLEU e ROUGE), sicurezza, agenti e i valutatori di Azure OpenAI. Include anche una valutazione LLM-as-judge personalizzata per le valutazioni specifiche dell'attività.
• La valutazione del portale esegue gli stessi valutatori su destinazioni di modello, agente, set di dati e traccia.

Eseguire lo stesso insieme di valutatori su origine e destinazione nel set di dati congelato, in modo che i numeri siano confrontabili.

Dove si interrompe comunemente

La maggior parte dei team non dispone di una suite di valutazione, e quelli che ce l’hanno spesso se la sono costruita da soli. Per i carichi di lavoro soggetti a regolamentazione, una revisione obbligatoria da parte di un operatore umano o del controllo qualità si aggiunge a monte e diventa il collo di bottiglia. Queste migrazioni si arrestano nella fase Convalida, non adatto.

Cosa porti

I valutatori sono pronti per essere eseguiti, ma la creazione di un set di test rilevante per il dominio a partire dal traffico di produzione proprio richiede un intervento manuale per i carichi di lavoro di modelli (non agenti). È per questo che la fase di preparazione si ripaga da sola.

Fase 5: Implementazione

Lo scopo di questa fase è promuovere in produzione la configurazione convalidata per fasi: prima negli ambienti non di produzione, poi con un rilascio canary o a una percentuale ponderata, quindi con una distribuzione più ampia. In globale, guardare la latenza in tempo reale, gli errori e, idealmente, la qualità rispetto alla baseline di pre-migrazione. Quindi eseguire il commit o il rollback. Un risultato positivo è un rilascio graduale tramite traffico canary, ponderato o shadow, un indicatore di qualità in tempo reale che vada oltre la latenza e gli errori e la possibilità di rollback preservata.

Cosa prendere in considerazione

• Conosci il tuo tipo di distribuzione. Il tipo di distribuzione determina le modalità: le distribuzioni della famiglia Standard possono essere aggiornate automaticamente secondo una pianificazione definita da te. Le distribuzioni con provisioning, batch e sottoposte a fine-tuning vengono migrate manualmente. Nella tabella seguente vengono illustrati i meccanismi in base al tipo.
• Mantenere un corridoio di rollback. Mantieni raggiungibile la distribuzione precedente finché non ne sei sicuro. Le decisioni di rollback imposte da una scadenza di deprecazione, anziché da dati concreti, sono un campanello d’allarme che indica che avete iniziato troppo tardi.
• Quando non è possibile eseguire il traffico canary, usare la modalità shadow o mirror. I flussi regolamentati (PHI, transazioni finanziarie) spesso non possono esporre un nuovo modello al traffico reale dei clienti. L'equivalente esegue il nuovo modello sugli input di produzione offline e confronta gli output con il modello precedente senza influire sugli utenti.
• Monitorare le regressioni non rilevate dalla valutazione offline. La latenza utente reale e il comportamento dei casi perimetrali possono essere visualizzati solo sotto il carico di produzione.

Meccanismi di migrazione per tipo di distribuzione

Dopo lo spostamento del traffico, configurare la valutazione continua per valutare una percentuale campionata del traffico di produzione nella dashboard Osservabilità di Foundry, collegata alle tracce per l'analisi delle cause radice, oltre agli avvisi di Monitoraggio di Azure quando la qualità cala.

Dove si interrompe comunemente

Le regressioni della qualità che la valutazione offline non ha rilevato emergono sotto carico di produzione. Le decisioni di rollback sono spesso forzate da una scadenza di deprecazione anziché da prove, che è un segno che la migrazione è iniziata troppo tardi.

Cosa porti

Il routing ponderato tra due distribuzioni viene implementato nel gateway o nel livello dell'applicazione e il corridoio di rollback è una scelta intenzionale per mantenere attiva la distribuzione precedente per un certo intervallo di tempo (i team di sistemi incorporati in genere richiedono circa 30 giorni). Vale la pena progettare entrambi una sola volta e riutilizzarli in ogni migrazione.

Fase 6: Ritiro

Lo scopo della fase di ritiro è mettere fuori servizio la distribuzione precedente, liberare capacità, archiviare gli artefatti di valutazione e comunicare a valle la modifica alla documentazione destinata ai clienti, alle pagine di marketing, ai runbook di supporto e ai log di audit nei casi in cui è richiesta la conservazione. Alla fine, la distribuzione precedente viene rimossa, il numero di distribuzioni diminuisce e gli insegnamenti confluiscono nel ciclo successivo.

Cosa prendere in considerazione

• Considera la dismissione come un aspetto della governance, non solo come pulizia finale. Per i carichi di lavoro regolamentati, gli obblighi di conservazione possono richiedere la conservazione degli artefatti per anni.
• Conferma che la fonte sia effettivamente scomparsa. Verificare che la versione precedente sia ritirata, quindi eliminare la distribuzione in modo da arrestare l'utilizzo della capacità.
• Trasmetti gli apprendimenti in avanti. Reintegrare le nuove tracce di produzione nel set di dati di riferimento, così la prossima migrazione costerà meno.

Dove si interrompe comunemente

I team saltano la rimozione, che comporta un accumulo di distribuzioni zombie. I team che non rimuovono attivamente mantengono molte più distribuzioni attive rispetto ai pari simili, e la maggior parte di quel totale è costituita da residui strutturali derivanti da migrazioni precedenti. Un passaggio secondario comune mancante è la comunicazione: la documentazione di marketing e prodotto fa ancora riferimento al vecchio modello dopo lo scambio.

Cosa porti

Il dashboard di osservabilità mostra che il numero di deployment è in calo, ma decidere quali deployment gestiscono ancora il carico è una valutazione che spetta al tuo team. Rendere il ritiro un'attività tracciata esplicita anziché una speranza.

La migrazione è raramente binaria

Le migrazioni reali sono spesso suddivise: parte di un carico di lavoro viene eseguita nel nuovo modello, mentre un percorso di rischio sensibile alla latenza o superiore rimane su quello precedente, a volte per settimane. Pianificare l'implementazione parziale e il rollback parziale anziché un unico passaggio dal modello precedente a quello nuovo. La rimozione in genere avviene con settimane o mesi di ritardo rispetto all'implementazione, e sono proprio quelle vecchie distribuzioni che restano ancora attive a manifestarsi come proliferazione.

Contenuti correlati

• Comprendere le tempistiche di deprecazione e supporto nel ciclo di vita e nei criteri di supporto dei modelli di Foundry
• Controllare le date di ritiro e le sostituzioni nella pianificazione del ritiro del modello
• Scopri quali modelli sono già stati ritirati in Modelli Microsoft Foundry ritirati
• Confronta i modelli candidati con benchmark dei modelli e classifiche
• Adattare le richieste a un nuovo modello con Ottimizza richieste con Prompt Optimizer
• Convalidare la qualità prima di passare eseguendo valutazioni dal portale foundry
• Monitorare il carico di lavoro migrato con Observability in generative AI