Knowledge distillation: come portare un LLM più piccolo in produzione

La knowledge distillation, o distillazione dei modelli, è utile quando un modello piccolo e specializzato può gestire un compito ricorrente, lasciando al modello di frontiera i casi che non riesce a risolvere. La disponibilità dell'addestramento conta ormai quanto la scelta del modello: i clienti esistenti di OpenAI ancora abilitati al fine-tuning perderanno la possibilità di avviare nuovi job il 6 gennaio 2027, salvo una dismissione anticipata del modello di base. Calendario della disponibilità di OpenAI

Il candidato ideale è una funzionalità basata su un modello linguistico di grandi dimensioni (LLM) con un contratto stabile: classificare una richiesta, estrarre determinati campi, scegliere un percorso o restituire un formato preciso. Il primo passo è provare un modello più piccolo senza addestrarlo. La distillazione ha senso quando il modello più grande risolve casi importanti che quello piccolo di riferimento sbaglia, e quella differenza si può trasformare in esempi di addestramento affidabili.

Documentazione dei fornitori e condizioni sull'uso degli output per l'addestramento verificate il 26 ottobre 2026. Le distinzioni che seguono riguardano le API di produzione e le licenze dei modelli citati; un abbonamento a un chatbot per consumatori o un diverso contratto di hosting può prevedere regole differenti.

Come funziona la knowledge distillation?

Un modello teacher, più grande, produce etichette o dimostrazioni, e un modello student, più piccolo, impara a svolgere il compito da quegli esempi. Una volta addestrato, lo student può rispondere alle richieste ordinarie senza interrogare il teacher a ogni chiamata. Nel fine-tuning supervisionato, un modello esistente viene addestrato su esempi di input e output desiderati. Un workflow di distillazione gestita può far generare quegli output al teacher. Workflow di distillazione documentato

È un po' come un istruttore di arrampicata che insegna una via breve. L'allievo si esercita sui movimenti necessari per quella via; non acquisisce per questo la capacità dell'istruttore di scalare qualsiasi montagna. Uno student in produzione ha lo stesso limite: imparare a classificare le richieste di rimborso non lo rende un sostituto universale del teacher.

Immaginiamo, per esempio, una funzionalità di assistenza che assegna ai messaggi le etichette billing, technical, cancellation o needs_review. Il teacher legge messaggi rappresentativi e propone le etichette. Un revisore risolve i casi ambigui. Lo student viene addestrato sulle coppie messaggio-etichetta approvate, poi affronta messaggi mai visti le cui risposte sono state verificate in modo indipendente.

Quest'ultimo passaggio è essenziale, perché concordare con il teacher non significa dare la risposta corretta. Se il teacher scambia sistematicamente una richiesta di cancellazione per una domanda sulla fatturazione, imitarlo fedelmente significa conservare l'errore.

Knowledge distillation LLM: imparare dagli esempi di output

Per chi sviluppa applicazioni, il punto di partenza più pratico è di solito la distillazione basata sugli output: si salvano gli input e le risposte accettabili del teacher, poi si addestra lo student su quelle coppie. Per seguire questo workflow documentato non serve accedere ai pesi del teacher, cioè ai parametri numerici appresi dal modello. Servono invece il diritto di riutilizzare gli output e un percorso di addestramento dello student che supporti il compito. Guida di OpenAI al fine-tuning supervisionato

La distillazione non si limita a copiare testo. La ricerca fondativa descrive anche il trasferimento di conoscenza da un ensemble, un gruppo di modelli, a un singolo modello più semplice da distribuire. Per una funzionalità circoscritta in produzione, però, la domanda utile è se lo student impara a prendere le decisioni necessarie, non se riproduce ogni aspetto del teacher. Distilling the Knowledge in a Neural Network

Questi approcci possono essere combinati. La quantizzazione degli LLM può seguire l'addestramento, con un'ulteriore valutazione al termine. Il confronto tra RAG e fine-tuning spiega perché apprendere uno schema di risposta non sostituisce il recupero di informazioni aziendali che cambiano nel tempo.

Quando conviene la distillazione dei modelli AI?

La distillazione è particolarmente interessante quando il compito rimane circoscritto, le richieste si ripetono e l'impiego dello student migliora un vincolo misurabile. Un volume elevato permette di distribuire il lavoro di addestramento e revisione su più richieste. Anche un requisito di latenza può giustificare l'investimento, pur quando la spesa non è il problema principale.

Un servizio di acquisizione documentale è un candidato plausibile se estrae ripetutamente gli stessi campi da famiglie di documenti note. Un assistente che deve rispondere a domande di qualsiasi tipo, utilizzare strumenti sconosciuti e ragionare in nuovi ambiti ha un compito molto più ampio. Ridimensionare l'intero assistente è un progetto più difficile che specializzarne il classificatore degli intenti.

Per chi sviluppa: fissare input, output e comportamento in caso di errore prima di raccogliere i dati. Se una fattura non contiene il numero dell'ordine d'acquisto, il valore corretto da estrarre può essere null, non una supposizione plausibile. Gli esempi di addestramento devono insegnare questa distinzione.

Per chi gestisce il servizio: confrontare l'intero percorso di erogazione. Includere tentativi ripetuti, errori di validazione, revisione umana, richieste inoltrate al teacher, valutazione continua e riaddestramento. Ridurre le risorse usate per l'inferenza è utile solo se questi oneri non annullano il beneficio. Non esiste una soglia universale di traffico oltre la quale la distillazione diventa conveniente.

Per chi acquista: verificare che teacher, student, metodo di addestramento e sede di distribuzione richiesti siano disponibili insieme. Il fatto che un fornitore offra entrambi i modelli per la normale inferenza non dimostra che consenta di distillare l'uno nell'altro.

La privacy può motivare la scelta di uno student più piccolo, ospitato nell'ambiente appropriato, ma piccolo non significa riservato. Occorre ricostruire dove transitano o risiedono input grezzi, chiamate al teacher, file di addestramento, log e modello distribuito. Eseguire lo student in locale non annulla l'invio di dati sensibili a un teacher remoto durante la creazione del dataset.

Meglio aspettare se la definizione del compito cambia spesso, gli esempi disponibili non sono rappresentativi, le etichette del teacher sono inaffidabili o i diritti di addestramento non sono chiari. Se un modello più piccolo senza fine-tuning supera già i criteri, l'addestramento non serve. Google segnala esplicitamente che la distillazione offre vantaggi minori quando lo student è già vicino al teacher nel compito di destinazione. Indicazioni di Google sui casi d'uso della distillazione

Quali servizi di distillazione gestita sono disponibili?

Scegliere un servizio gestito in base al supporto attuale per l'addestramento e al suo ciclo di vita, poi verificarne le condizioni. Il confronto seguente riflette la documentazione verificata il 26 ottobre 2026.

Model distillation con OpenAI: accesso riservato ai clienti esistenti, con una scadenza

Il workflow documentato da OpenAI prevede di migliorare il prompt del teacher, raccogliere le risposte che soddisfano i propri criteri, creare un dataset ed eseguire il fine-tuning di un modello più piccolo. Resta una descrizione utile del meccanismo. Non è più, però, un percorso da consigliare in generale a chi inizia: la guida attuale dichiara che la piattaforma di fine-tuning non è disponibile per i nuovi utenti. Fine-tuning supervisionato di OpenAI

I clienti attivi ancora abilitati possono creare job solo fino al 6 gennaio 2027, salvo dismissioni anticipate dei modelli. GPT-4.1 e GPT-4.1 mini, comprese le rispettive versioni sottoposte a fine-tuning, saranno dismessi il 14 gennaio 2027. La dismissione documentata di GPT-4.1 nano e o4-mini è avvenuta il 23 ottobre 2026. Queste scadenze rendono difficile giustificare una nuova dipendenza di lungo periodo, anche se l'account ha ancora accesso. Dismissioni di OpenAI

Sul piano pratico, chi usa già il servizio dovrebbe pianificare la migrazione e conservare i dati di valutazione. Un nuovo progetto dovrebbe scegliere un percorso di addestramento disponibile, invece di basarsi sul lancio originario della distillazione.

Google Vertex AI: tuning di Gemini e distillazione dei modelli aperti sono percorsi distinti

La documentazione sui modelli generativi di Google Vertex AI rimanda ora a Gemini Enterprise Agent Platform. La guida al tuning di Gemini descrive il fine-tuning supervisionato, cioè l'addestramento su esempi etichettati, e include nell'elenco modelli come Gemini 3.5 Flash e Gemini 3.5 Flash-Lite. Lo raccomanda per classificazione, analisi del sentiment ed estrazione di entità. Panoramica attuale di Google sul tuning

Google documenta separatamente la distillazione gestita dei modelli aperti tramite il GenAI SDK. Tra gli esempi dell'elenco dei teacher figurano DeepSeek R1 0528 e DeepSeek V3.2; tra gli student, Qwen 3 8B e Gemma 3 4B IT. Il tuning supervisionato dei modelli aperti offre anche il fine-tuning completo e LoRA, che aggiorna meno parametri. Il relativo elenco di modelli è diverso da quello dei modelli ammessi alla distillazione. Documentazione sul tuning dei modelli aperti

Il vincolo da verificare è la combinazione di metodo, modello e località. Oltre alla quota per l'addestramento, serve quella per l'inferenza del teacher. L'endpoint globale sceglie una regione supportata: eventuali requisiti di residenza dei dati richiedono quindi una configurazione regionale esplicita. Per la semplice classificazione, conviene provare il modello più piccolo prima di impegnarsi nel percorso di distillazione di Google, orientato al ragionamento.

Amazon Bedrock Model Distillation: workflow gestito con coppie prestabilite

Amazon Bedrock Model Distillation riunisce in un unico workflow generazione delle risposte del teacher, sintesi dei dati e fine-tuning dello student. Si possono fornire prompt oppure usare log di invocazione dei modelli già disponibili, ossia registrazioni di richieste e risposte precedenti, archiviati in Amazon Simple Storage Service (Amazon S3). Bedrock offre anche fine-tuning supervisionato e per rinforzo come metodi di personalizzazione separati. Workflow di distillazione, metodi di personalizzazione

La tabella attuale delle coppie include Amazon Nova Pro → Nova Lite o Nova Micro in US East (N. Virginia) e Meta Llama 3.3 70B → Llama 3.1 8B tra le opzioni Llama in US West (Oregon). Specifica che la distillazione non è attualmente disponibile per i modelli Anthropic, senza una data confermata per il ripristino. Coppie e regioni supportate

La guida di Bedrock alla preparazione dei dati fissa un massimo di 15K prompt o coppie prompt-risposta in input. È un limite del job, non la prova che per il proprio compito servano così tanti esempi. I dati vanno selezionati per coprire decisioni reali e casi di errore. Limiti per la preparazione dei dataset

È un percorso praticabile se la coppia desiderata è supportata e i requisiti di distribuzione sono compatibili. Non è un servizio che consente di distillare un teacher qualsiasi in uno student qualsiasi.

Essere titolari degli output non autorizza ad addestrare altri modelli

Prima di usare gli output per addestrare un altro modello, occorre controllare il contratto dell'endpoint che ha prodotto i dati. La titolarità degli output, l'impegno del fornitore a non addestrare sui dati del cliente e il diritto del cliente di addestrare uno student sono disposizioni diverse.

Gli estratti che seguono sono volutamente brevi. Il loro ambito di applicazione conta quanto le parole citate: a disciplinare l'uso effettivo sono il contratto firmato, il modulo d'ordine e le condizioni di prodotto applicabili.

OpenAI: divieto di concorrenza con eccezioni definite

Il Services Agreement di OpenAI limita l'uso degli output per sviluppare modelli che “compete with OpenAI’s products and services”, salvo una Permitted Exception. Questa definizione include i modelli interni destinati principalmente a categorizzare, classificare o organizzare dati, purché non siano distribuiti né resi disponibili commercialmente a terzi. Include anche il fine-tuning o la personalizzazione dei modelli forniti tramite i servizi OpenAI specificati. Services Agreement: restrizioni e definizioni

Un classificatore interno è quindi un caso sostanzialmente diverso da un modello generativo generalista offerto ai clienti. Non bisogna presumere che qualsiasi funzionalità di estrazione, classificatore in hosting o modello generalista privato rientri nell'eccezione: chi è responsabile del contratto deve verificare l'uso concreto.

Va considerata anche la decorrenza delle regole. OpenAI ha pubblicato un aggiornamento delle policy in vigore dal 20 novembre 2026, successivo alla data di verifica di questo articolo. L'aggiornamento riguarda l'uso di modelli o output per fornire segnali di addestramento ad alternative o sostituti, comprese etichette, feedback e filtraggio, preservando gli usi espressamente consentiti dal contratto applicabile. Va considerato un cambiamento in arrivo, non una regola già in vigore alla data della verifica. Aggiornamento pubblicato delle Usage Policies

Anthropic: serve un'approvazione espressa per addestrare modelli concorrenti

I Commercial Terms di Anthropic vietano di accedere ai suoi servizi per realizzare un prodotto o servizio concorrente, anche per “train competing AI models”, salvo approvazione espressa. L'assegnazione separata dei diritti sugli output non elimina questo vincolo. Anthropic Commercial Terms, D.4

Prima di trasformare gli output di Claude nel dataset di addestramento di un altro modello, serve dunque un'analisi specifica del contratto. Un vecchio annuncio sulla distillazione in cloud non basta a dimostrarne la disponibilità attuale o l'autorizzazione all'uso.

Google: Cloud e API Gemini per sviluppatori hanno contratti diversi

Le restrizioni sui modelli di Google Cloud vietano di usare gli output del servizio per “substitute, replace, or circumvent the use of a Google Model” o “create or improve models similar to a Google Model”. È prevista un'eccezione esplicita quando il servizio offre fine-tuning o distillazione: i suoi output possono essere usati per modificare e utilizzare Modified Google Models al posto di Google Pre-Trained Models. Offerte distinte hanno condizioni distinte. Condizioni specifiche dei servizi Google Cloud

L'API Gemini per sviluppatori usa una formulazione diversa: non è consentito usare i suoi servizi per “develop models that compete with the Services”. Queste condizioni aggiuntive distinguono esplicitamente l'uso diretto di Google Cloud Platform. Un'autorizzazione valida in un workflow Cloud gestito non va estesa a un progetto indipendente di generazione di dati tramite l'API Gemini. Condizioni aggiuntive dell'API Gemini

Amazon: l'eccezione dipende dall'autorizzazione del servizio

La restrizione pertinente degli AWS Service Terms si apre con “Except where permitted by the AI Service” e, al di fuori di tale eccezione, vieta di generare contenuti per “the express purpose of training an AI model or service”, oppure per svilupparne uno sostanzialmente simile. Bedrock incorpora anche le condizioni applicabili dei modelli di terze parti. AWS Service Terms: AI Services e Bedrock

Il percorso concreto da esaminare è il workflow gestito documentato, con le coppie ammesse. La sua esistenza non equivale a un'autorizzazione generale a esportare le risposte di ogni modello Bedrock verso qualsiasi job di addestramento esterno.

Meta Llama: contano il nome del modello e le condizioni di ridistribuzione

La licenza di Meta Llama 3.3 disciplina esplicitamente l'addestramento di un altro modello con materiali o output di Llama. Quando il modello risultante viene distribuito o reso disponibile, richiede Llama “at the beginning of any such AI model name”. Contano anche la licenza, l'attribuzione e le altre condizioni applicabili. Llama 3.3 Community License

È la licenza di un modello specifico, non una regola universale per tutti i modelli Meta o tutti gli endpoint in hosting. Insieme al dataset vanno registrate la versione esatta e le condizioni di hosting.

Mistral AI: distinguere gli output testuali dai vincoli sulle immagini

L'attuale restrizione commerciale di Mistral AI sugli output cita gli “image Outputs” usati per “develop or train any image generation product that competes”. La clausola riguarda le immagini: presentarla come un divieto generale di addestrare con il testo ne estenderebbe indebitamente la portata. Le stesse condizioni vietano separatamente di usare gli output per effettuare il reverse engineering dei prodotti Mistral AI, e possono applicarsi ulteriori condizioni di prodotto o distribuzione. Condizioni commerciali di Mistral AI

Per un dataset destinato a un LLM, occorre esaminare l'uso del testo alla luce del contratto applicabile, senza estendere i vincoli sulle immagini né presumere un'autorizzazione illimitata.

Grok: l'addestramento con output enterprise richiede un'eccezione nel modulo d'ordine

Le condizioni enterprise di Grok su x.ai vietano di usare “any Output to train any foundation models, large language models, or other artificial intelligence systems”, salvo autorizzazione espressa in un Order Form. La pagina identifica il fornitore contraente come SpaceXAI LLC, che usa il nome SpaceXSI. Condizioni enterprise di Grok: diritti su input e output

Questa formulazione va oltre un vincolo limitato ai modelli concorrenti. Non si può presumere che uno student interno sia esente solo perché rimane all'interno dell'azienda.

DeepSeek-R1: autorizzazione esplicita alla distillazione per una versione specifica

Il repository ufficiale di DeepSeek-R1 dichiara che codice e pesi usano la MIT License e consente espressamente la “distillation for training other LLMs”. Identifica inoltre le licenze Qwen e Llama di origine per le versioni già distillate. Sezione sulla licenza di DeepSeek-R1

È un'autorizzazione utile, legata a una versione precisa. Non stabilisce le condizioni di ogni futuro modello DeepSeek, servizio di hosting o modello di base dello student. La documentazione del rilascio deve conservare sia l'autorizzazione relativa al teacher sia la licenza dello student.

Come valutare lo student prima di affidargli il traffico di produzione

Uno student è pronto quando soddisfa i criteri di accettazione della funzionalità su input mai visti, simili a quelli di produzione, e supera un rilascio controllato. Una loss di addestramento in calo, cioè una riduzione dell'errore misurato durante l'addestramento, non dimostra nessuna delle due condizioni.

Quella che segue è una proposta di procedura di rilascio, non un resoconto di risultati di benchmark.

1. 1

   Fissare il compito e il riferimento iniziale

   Definire il contratto degli input, i valori di output consentiti, i campi obbligatori e il comportamento di astensione. Salvare i risultati del teacher attuale e quelli di un modello piccolo guidato da un prompt su un campione rappresentativo. Stabilire qualità e latenza accettabili prima di esaminare il punteggio dello student addestrato.

2. 2

   Separare addestramento, validazione e test finale

   Usare i dati di addestramento per aggiornare i pesi e quelli di validazione per scegliere prompt o checkpoint. Tenere intatto un insieme di test finale finché queste scelte non sono concluse. Raggruppare conversazioni correlate dei clienti, modelli di documento e quasi duplicati, in modo che copie dello stesso contenuto non finiscano in insiemi diversi. Includere traffico reale recente, classi rare ed esempi difficili.

3. 3

   Curare le dimostrazioni del teacher

   Far etichettare gli input di addestramento al teacher di cui si è autorizzati a usare gli output. Validare il formato, esaminare le ambiguità e correggere gli errori importanti. Conservare gli esempi in cui la risposta corretta è un'astensione o un valore mancante. Registrare modello teacher, prompt, autorizzazioni relative alle fonti e versione del dataset. La guida alla generazione di dati sintetici approfondisce questo lavoro sui dati.

4. 4

   Misurare il risultato del compito, non la somiglianza

   Per la classificazione, misurare gli errori per ogni classe, soprattutto il richiamo nei casi in cui una mancata rilevazione costa cara: quante vere richieste di cancellazione sono state riconosciute? Per l'estrazione, controllare i valori esatti dei campi richiesti e la gestione di quelli mancanti. Per la generazione in formato fisso, verificare la validità rispetto allo schema, cioè il rispetto della struttura richiesta, separatamente dalla correttezza fattuale. Per il routing, misurare se il percorso scelto a valle risolve la richiesta. Esaminare i disaccordi tra teacher e student confrontandoli con risposte verificate in modo indipendente.

5. 5

   Provare il traffico in modalità shadow, poi un rilascio canary

   In modalità shadow, inviare allo student una copia degli input reali mentre il sistema esistente continua a fornire il risultato all'utente. Misurare qualità delle risposte, richieste lente, timeout e necessità di escalation sotto carico effettivo. Se la prova riesce, un rilascio canary affida allo student solo una quota controllata del traffico, con condizioni di arresto esplicite e un rollback funzionante.

6. 6

   Mantenere un'alternativa e monitorare i cambiamenti

   Rimandare al teacher o alla revisione umana gli input non supportati, gli errori di validazione e i casi definiti ad alto rischio. Monitorare i cambiamenti nella composizione degli input, gli errori per classe e la quota di richieste che richiede il fallback. Ripetere la valutazione dopo modifiche a prompt, schemi, checkpoint dello student, quantizzazione o dati a monte. Un ricorso frequente al fallback è un segnale che il progetto va rivisto.

Per una funzionalità di estrazione, un criterio pratico di rilascio potrebbe richiedere che lo student mantenga l'accuratezza dei campi obbligatori su ogni famiglia documentale importante, rispetti l'obiettivo di latenza del servizio esistente e si astenga correttamente quando l'informazione manca. Il responsabile della funzionalità stabilisce le soglie in base alle conseguenze degli errori: un benchmark generale del fornitore non può farlo al suo posto.

La guida al routing dei modelli aiuta a definire il confine tra il traffico gestito dallo student e il fallback al modello di frontiera. Non basta affidarsi alla sicurezza dichiarata dallo student. Regole di ammissibilità degli input, validazione degli output e schemi di errore misurati forniscono al router criteri concreti su cui agire.

Le promesse eccessive sulla distillazione

«Il modello piccolo diventa il modello grande.» Impara dalla supervisione e dalla copertura degli esempi forniti. Riuscire su schemi di estrazione familiari dice poco su una lingua sconosciuta, una nuova famiglia di documenti o un compito di ragionamento più ampio.

«I dati generati eliminano il problema dell'etichettatura.» Spostano parte del lavoro dalla scrittura delle etichette alla loro verifica. Un teacher può produrre una vasta raccolta di esempi sistematicamente sbagliati. La valutazione umana e le risposte di test verificate in modo indipendente restano preziose.

«Un modello più piccolo garantisce un risparmio.» La funzionalità in produzione comprende fallback, revisione, hosting, monitoraggio e riaddestramento. Va giudicato il risultato complessivo; i miglioramenti di latenza devono essere misurati, non dati per scontati in base alle dimensioni del modello.

«La distillazione gestita risolve la questione dei diritti.» Fornisce un workflow documentato con confini precisi. Non trasforma tutti gli output dei modelli in materiale di addestramento utilizzabile senza restrizioni.

«Un JSON valido significa che la funzionalità funziona.» Un identificativo di account errato rimane errato anche se il formato è perfetto. I controlli sul formato sono un criterio di rilascio, non l'intera valutazione.

Domande frequenti sulla distillazione degli LLM

La distillazione dei modelli funziona davvero?

Può trasferire dal teacher allo student comportamenti utili per un compito. Per la propria funzionalità, la prova che conta è la prestazione su input mai visti e verificati in modo indipendente, seguita da un rilascio controllato in produzione. Non garantisce capacità generali pari a quelle del teacher.

Che differenza c'è tra distillazione dei modelli e fine-tuning?

La distillazione descrive l'apprendimento dalla supervisione di un altro modello. Il fine-tuning descrive l'aggiornamento di un modello già addestrato usando dati del compito. Quando le risposte del teacher diventano esempi supervisionati per lo student, lo stesso job è sia distillazione sia fine-tuning.

Come si distilla un LLM?

Si definisce un compito circoscritto, si verificano i diritti sugli output del teacher e sul modello student, si selezionano e revisionano dimostrazioni rappresentative del teacher, si addestra tramite un percorso supportato e si confronta lo student con il teacher e con un modello piccolo di riferimento senza fine-tuning. Prima di estendere il passaggio, si usano una valutazione su dati tenuti da parte, traffico in modalità shadow e un rilascio canary.

Che cos'è un modello distillato?

È un modello addestrato con la supervisione di un altro modello, spesso per rendere un modello più piccolo efficace in un compito specifico. Le sue capacità dipendono comunque dallo student, dai dati di addestramento e da ciò che si valuta.

Che cos'è la distillazione dei modelli?

La distillazione dei modelli trasferisce comportamenti appresi da un modello teacher a uno student attraverso l'addestramento. In un workflow LLM comune, il teacher produce etichette o risposte e lo student impara da coppie input-output approvate.

Quali sono i quattro tipi di distillazione?

Non esiste una tassonomia universale in quattro tipi per la distillazione degli LLM. Gli elenchi con questa formulazione riguardano spesso la separazione dei liquidi, un altro significato di distillazione. Per una funzionalità LLM, occorre identificare la supervisione e il metodo di addestramento effettivi, invece di scegliere da una classificazione della chimica.

Quali sono 5 esempi di distillazione?

Nelle applicazioni LLM, alcuni compiti candidati sono lo smistamento dei ticket di assistenza, l'etichettatura degli intenti, l'estrazione dei campi delle fatture, la normalizzazione dei record e la generazione di risposte in formato fisso. Sono possibili impieghi da valutare, non affermazioni che un modello distillato riesca automaticamente in tutti e cinque.

Quali sono gli svantaggi della distillazione?

Si possono ereditare gli errori del teacher, non gestire correttamente input rari, spendere molto nella revisione dei dati e dover riaddestrare il modello quando il compito cambia. Anche il ciclo di vita del fornitore, le restrizioni sugli output del teacher e la licenza dello student possono vincolare la distribuzione.

Qual è una tecnica semplice per distillare un LLM?

Si usa un teacher di cui si è autorizzati a usare gli output per produrre risposte a input rappresentativi, si revisionano le risposte e si esegue il fine-tuning supervisionato dello student sulle coppie approvate. Poi lo si prova su casi reali separati. È un significato diverso dalla distillazione semplice di laboratorio.

Il prossimo passo da mettere in pratica

La prossima settimana, individuare il responsabile di una funzionalità usata ripetutamente. Affidargli la definizione del contratto degli output, la preparazione di un campione di test separato ricavato da richieste reali e il confronto tra il teacher attuale e un modello piccolo guidato da un prompt. Se rimane un divario di qualità significativo, verificare che esista un percorso teacher-student disponibile e autorizzato, quindi costruire il dataset di addestramento a partire dagli errori.

Se il modello piccolo di riferimento supera già i criteri, conviene scegliere questa soluzione più semplice. Se né il teacher né i revisori riescono a etichettare i casi difficili in modo coerente, occorre chiarire la definizione del compito prima di addestrare.

Iscriviti alla newsletter per orientarti nelle decisioni pratiche sullo sviluppo e sulla gestione di funzionalità AI.