Se avete letto la serie Capire l’AI (Parte 1, Parte 2 e Parte 3), nella quale tra le altre cose sono stati utilizzati degli LLM di tipo “Open-Weight” vi sarete resi conto di una cosa, che abbiamo più volte specificato: Open-Weight non vuol dire Open-Source.

Tutt’altro.

Secondo l’Open Source Initative, sebbene la definizione non sia universalmente accettata nelle community, un modello, per essere open-source deve avere precise caratteristiche: devono essere disponibili e accessibili i dati utilizzati per addestrarlo, il codice sorgente completo e necessario per usare, modificare e studiare il sistema e i parametri del modello, cioè i suoi pesi.

Inoltre, questi elementi devono essere distribuiti con licenze che consentano di usare, studiare, modificare e condividere il sistema e le sue componenti.

I modelli Open-Weight quelle caratteristiche non le hanno: i pesi (decisionali) del modello sono sì disponibili, ma tutto il resto, vedi il codice completo, i dati di training e l’intera pipeline che ha prodotto il modello non lo sono necessariamente.

In questo contesto si collocano i cinque principi di SS1/23, il quadro della Prudential Regulation Authority britannica sulla gestione del rischio dei modelli, entrato in vigore nel maggio 2024 e descritti in questo articolo di OpenUK.

La definizione di “modello” citata nel documento è stata estesa anche ai sistemi AI/ML che producono output qualitativi: quindi un LLM utilizzato, per esempio, per supportare una decisione sul credito o individuare frodi può rientrare nel perimetro della disciplina.

Per una banca questo significa, tra le altre cose ad esempio, che il modello deve essere:

• identificato e classificato;
• sottoposto a una struttura di governance;
• documentato e testato;
• sottoposto a validazione indipendente;
• accompagnato da misure di mitigazione del rischio e da meccanismi di fallback.

Ed è qui che entra in gioco la distinzione fra closed, open-weight e open source che l’articolo cerca di chiarire.

Un modello closed è quello in cui il modello vero e proprio rimane nelle mani del fornitore: normalmente noi interagiamo con lui attraverso un’API o un servizio, senza avere accesso ai suoi pesi, al codice o ai dati utilizzati per il training. Possiamo quindi testarne il comportamento, ma dobbiamo necessariamente fidarci del fornitore per una parte significativa di ciò che avviene “dentro” la scatola.

Un modello open-weight fa un passo in più: i pesi del modello vengono resi disponibili e possono quindi essere scaricati ed eseguiti, almeno in linea di principio, in un ambiente sotto il nostro controllo. Questo permette di effettuare test più approfonditi, verificare la riproducibilità dei risultati e, in alcuni casi, intervenire sul modello attraverso fine-tuning o altre tecniche. Ma non significa necessariamente sapere come quei pesi siano stati prodotti: i dati di training, il codice completo e l’intera pipeline di addestramento possono rimanere proprietari.

Un modello open-source, nella definizione dell’OSI, va invece oltre la semplice disponibilità dei pesi: devono essere disponibili le componenti necessarie per poter studiare, utilizzare, modificare e condividere il sistema, secondo i termini della relativa licenza. È quindi una differenza che non riguarda soltanto “quanto possiamo scaricare”, ma soprattutto quanto possiamo effettivamente verificare e riprodurre.

Ed è proprio quest’ultimo punto a diventare interessante quando parliamo di modelli utilizzati in contesti regolamentati: avere i pesi a disposizione può rendere la validazione molto più concreta, ma non significa automaticamente avere tutte le informazioni necessarie per validare l’intero processo che ha prodotto il modello.

Quindi, servisse chiarirlo ulteriormente, “open-weight” non significa “completamente trasparente”, e l’articolo di OpenUK lo chiarisce in maniera netta. Puoi avere accesso ai pesi, ma non sapere:

• con quali dati il modello è stato addestrato;
• quale sia la provenienza dei dati;
• quali siano stati i criteri di selezione;
• come siano state effettuate determinate valutazioni;
• quali problemi di fairness – ossia le situazioni in cui un modello di AI produce risultati sistematicamente più favorevoli o sfavorevoli per determinati gruppi di persone, per esempio in base a genere, etnia o età – possano essere presenti nel training.

L’articolo cita in questo senso un lavoro dell’AI Security Institute, secondo cui l’opacità dei dati di training rimane anche nei modelli open-weight.

Quindi, chiarendo ulteriormente: i modelli open-weight sono una scorciatoia parziale verso la validazione, non la soluzione definitiva alla trasparenza.