Stable Diffusion 3.5 Large alla prova: come misurare il rispetto dei prompt

A quale domanda risponde questo benchmark

Una valutazione del rispetto dei prompt verifica se un’immagine generata contiene gli elementi richiesti dalle istruzioni e se questi presentano gli attributi e le relazioni indicate. Da sola, non stabilisce se il risultato sia bello, originale o adatto a qualsiasi utilizzo. Non consente neppure di dichiarare un modello «migliore» in senso universale: descrive il suo comportamento su un insieme di attività, con una configurazione e un metodo di valutazione specifici.

Per Stable Diffusion 3.5 Large, la domanda pratica potrebbe essere: con quale frequenza le immagini generate rispettano requisiti verificabili, come includere tre oggetti, collocarne uno alla sinistra di un altro o mostrare una determinata parola? Il confronto proposto con Stable Diffusion 3.5 Medium va inteso come una nuova prova. Nelle fonti qui disponibili non compaiono risultati quantitativi verificati né un protocollo completo che permettano di presentare una classifica già stabilita.

La pagina di un modello, una ricetta software o una dimostrazione visiva possono essere utili per identificare un’implementazione o avviare un’inferenza. Non sostituiscono però una valutazione controllata. Questo articolo descrive quindi come produrre e comunicare evidenze; non attribuisce a Large o a Medium un punteggio relativo al rispetto dei prompt.

Che cosa è stato verificato e che cosa non sappiamo ancora

La comunicazione di Stability AI annuncia la disponibilità di Stable Diffusion 3.5 Large e del codice per l’inferenza. La scheda del modello ospitata nell’area Stability AI su Hugging Face identifica Large come modello text-to-image e lo descrive come un Multimodal Diffusion Transformer. Questi elementi aiutano a riconoscere il modello e la sua provenienza, ma gli estratti disponibili non riportano misurazioni del rispetto delle istruzioni.

La documentazione di Amazon Bedrock descrive un’offerta di SD 3.5 Large con otto miliardi di parametri e output da un megapixel. Si tratta di un’informazione relativa a quella documentazione e alla configurazione di quella piattaforma: non va trasferita automaticamente a ogni implementazione né interpretata come prova di qualità. Una ricetta di vLLM menziona una variante Medium da 2,5 miliardi di parametri e Large da 8,1 miliardi nella famiglia; identificare queste dimensioni, però, non dimostra quale variante segua meglio un prompt.

Il repository di Stability AI si presenta come un’implementazione di riferimento incentrata sull’inferenza. La disponibilità del codice permette di esaminare un percorso di esecuzione, ma non determina di per sé i parametri adatti a un confronto. Anche le prove informali condivise su Reddit sono esperienze aneddotiche: possono suggerire casi da approfondire, ma non sostituiscono un insieme di test con criteri definiti in anticipo.

La conclusione metodologica è circoscritta, ma importante: con le evidenze fornite non si può affermare quale modello ottenga risultati migliori nel rispetto dei prompt, quale sia la differenza tra Large e Medium o quale configurazione abbia prodotto risultati comparabili. L’assenza di questi dati in questo insieme di fonti non dimostra neppure che non esistano valutazioni pubblicate altrove; significa che non si devono attribuire risultati che qui non sono stati verificati.

Progettare prompt che consentano di verificare i requisiti

L’insieme di valutazione dovrebbe scomporre il rispetto delle istruzioni in dimensioni osservabili, invece di basarsi su un’impressione complessiva. È opportuno includere presenza degli oggetti, quantità, relazioni spaziali, attributi visivi e testo richiesto. Per ogni prompt occorre specificare quale requisito si valuterà e che cosa conterà come conformità prima di generare le immagini. Se una frase ammette interpretazioni diverse, va riscritta o contrassegnata come ambigua, non interpretata a posteriori dopo aver visto il risultato.

La selezione dovrebbe comprendere casi semplici e combinazioni più impegnative. Per esempio, un prompt può richiedere due tazze; un altro, una tazza rossa alla sinistra di un libro blu; un altro ancora, una scena con un’etichetta su cui sia leggibile una parola. Sono esempi di progettazione del protocollo, non risultati attribuiti ai modelli. Le istruzioni dovrebbero evitare dettagli irrilevanti che rendano difficile stabilire quale requisito non sia stato rispettato.

È utile bilanciare le categorie e registrarne la composizione. Se ci sono molti prompt sulla presenza degli oggetti e pochi sul testo, un punteggio complessivo può nascondere prestazioni disomogenee. Vanno inoltre definite in anticipo le esclusioni: per esempio, se il testo sarà valutato solo quando è chiaramente visibile o se si ammetteranno variazioni tipografiche. Non si dovrebbero eliminare prompt solo perché producono immagini scomode per una conclusione attesa.

Definire le condizioni di esecuzione

Prima di generare le immagini, occorre registrare l’identificazione esatta del modello e dei pesi, insieme alla versione del software, all’implementazione e a qualsiasi modifica della pipeline. Vanno inoltre pubblicati risoluzione, numero di passaggi, parametri di guida, precisione numerica, hardware e opzioni di accelerazione. Se una piattaforma nasconde parte di queste informazioni, è necessario dichiararlo e limitare di conseguenza le conclusioni.

Devono essere documentati anche il seed e il numero di generazioni per prompt. Una sola immagine per istruzione può far sì che una variazione casuale domini il risultato; più generazioni consentono di osservare tale variabilità, anche se aumentano i costi. Il protocollo deve stabilire quante immagini saranno prodotte prima di esaminare i risultati e applicare lo stesso criterio a entrambi i modelli. Per rendere il confronto interpretabile, è utile indicare anche se i seed sono stati abbinati tra i modelli e che cosa significhi tale abbinamento nelle implementazioni usate.

Dichiarare la stessa risoluzione o lo stesso numero di passaggi non basta se Large e Medium vengono eseguiti con pipeline diverse. Il confronto più pulito mantiene invariati i parametri condivisibili e pubblica ogni differenza inevitabile. Se i limiti di memoria obbligano a modificare precisione, dimensione del batch o altre opzioni, tali differenze fanno parte della descrizione e possono impedire di attribuire il risultato esclusivamente al modello.

Valutare i requisiti e ricorrere a valutatori all’oscuro del modello

L’unità principale di valutazione dovrebbe essere il requisito verificabile. Per ogni immagine, i valutatori possono indicare se l’oggetto è presente, se la quantità è corretta, se l’attributo richiesto compare, se la relazione spaziale è rispettata e se il testo è leggibile e corrisponde a quello richiesto. Una scala binaria facilita il conteggio, ma può essere utile anche una categoria «non valutabile» per immagini corrotte o istruzioni realmente ambigue. Le regole per utilizzarla vanno stabilite prima di esaminare i risultati.

La valutazione umana dovrebbe celare quale modello ha generato ciascuna immagine e presentarle in ordine misto. I valutatori hanno bisogno di istruzioni condivise, esempi che mostrino come applicare la rubrica e un modo per registrare i dubbi. È opportuno coinvolgere più di una persona e pubblicare sia l’accordo sia i disaccordi; se questi ultimi sono frequenti, la definizione del requisito potrebbe essere insufficiente. Un disaccordo non andrebbe risolto in modo silenzioso né presentando il consenso come certezza assoluta.

Le metriche automatiche possono fornire un supporto, non sostituire universalmente il giudizio su tutti i requisiti. Prima di usarle, occorre spiegare che cosa misurano, in quali casi si applicano e come sono state verificate rispetto a un campione esaminato da persone. Una misura complessiva di somiglianza non dimostra da sola che ci siano esattamente tre oggetti, che uno sia alla sinistra di un altro o che una parola sia leggibile correttamente. Se una metrica non è stata convalidata per una dimensione, il rapporto deve dichiararlo, invece di trattarla come arbitro.

Confrontare Large e Medium senza attribuzioni indebite

Il confronto dovrebbe partire dallo stesso insieme di prompt e dalla stessa rubrica. Per quanto consentito dalle implementazioni, occorre uniformare risoluzione, numero di generazioni, parametri d’inferenza e condizioni di valutazione. Per ciascun requisito, è opportuno presentare i risultati per modello e categoria, indicando il numero di campioni e descrivendo la variabilità, non soltanto una media generale.

L’uguaglianza dei valori in una tabella dei parametri non garantisce che le esecuzioni siano equivalenti se cambiano pipeline, precisione, opzioni di campionamento o software. Ogni disallineamento deve quindi essere reso esplicito. Se non è possibile controllare una differenza importante, il rapporto dovrebbe descrivere il risultato come confronto tra due configurazioni complete, non come prova isolata del fatto che sia stata la dimensione o la variante del modello a causarlo.

Non si dovrebbero inserire valori ipotetici nei campi che non sono ancora stati verificati con un’esecuzione. Il rapporto può pubblicare il protocollo previsto e indicare che i risultati sono in attesa. Quando saranno disponibili i dati, ogni conclusione dovrà rimandare all’insieme di test, alla configurazione e alla rubrica che la sostengono. La valutazione proposta non permette di anticipare se Large supererà Medium nel seguire le istruzioni.

Contaminazione, selezione dei campioni e limiti

Un benchmark può essere distorto se i prompt sono pubblici, sono stati riutilizzati spesso nelle dimostrazioni o somigliano a esempi visti durante lo sviluppo del sistema. Senza informazioni sui dati di addestramento, non sempre è possibile confermare o escludere un’esposizione precedente. Il team di valutazione può ridurre i rischi scrivendo prompt appositamente per la prova, limitandone l’accesso fino all’esecuzione e pubblicando poi l’insieme; tuttavia, queste misure vanno descritte come controlli parziali, non come prova dell’assenza di contaminazione.

Si introduce inoltre una distorsione quando si scelgono e si mostrano solo le immagini più convincenti. Per evitarlo, vanno conservate tutte le generazioni previste e definite in anticipo le regole di esclusione. Le gallerie di esempi possono illustrare successi o errori, ma non sostituiscono i conteggi completi. Un solo seed, una selezione manuale a posteriori o una categoria con pochissimi casi possono produrre un’impressione fuorviante.

La rubrica comporta decisioni umane: che cosa si considera una relazione spaziale sufficientemente rispettata, quando un testo è leggibile o quanto dettaglio basta perché un attributo sia soddisfatto. Per questo servono definizioni operative, valutazioni indipendenti e la comunicazione dei disaccordi. I risultati non andrebbero combinati senza distinzione con punteggi ottenuti su altri insiemi, configurazioni o metodi: se i compiti e le regole di misurazione sono diversi, il numero potrebbe non rappresentare lo stesso fenomeno.

Checklist per riprodurre il benchmark

Una valutazione utile dovrebbe permettere ad altre persone di ripetere la procedura e comprenderne i limiti, anche se non ottengono immagini identiche. Il materiale pubblicato dovrebbe includere prompt, criteri d’inclusione e d’esclusione, seed, numero di generazioni, versioni e configurazioni, oltre alle immagini o a una spiegazione chiara del motivo per cui non vengono distribuite. Dovrebbe comprendere anche la rubrica, i moduli di valutazione, il metodo di anonimizzazione e i risultati disaggregati per dimensione.

Il rapporto dovrebbe separare fatti osservati, scelte metodologiche e interpretazioni. Per esempio, il conteggio delle risposte dei valutatori è un risultato dell’esecuzione; la definizione di «relazione spaziale rispettata» è una scelta della rubrica; affermare che una differenza dipende dal modello è un’interpretazione che richiede condizioni comparabili ed evidenze sufficienti. Questa distinzione aiuta chi consulta la valutazione a non confondere una raccomandazione di protocollo con un risultato già misurato.

Finché una prova di questo tipo non sarà pubblicata e riprodotta, la scelta responsabile è presentare Stable Diffusion 3.5 Large e Medium come varianti da valutare in condizioni esplicite, non come vincitori o sconfitti di un benchmark sul rispetto dei prompt. L’indice dei benchmark può fornire un contesto editoriale e la scheda di valutazione di SD 3.5 Large può fungere da riferimento per la prova, purché risultati ancora da ottenere non vengano descritti come misurazioni. La conclusione pratica è semplice: pubblicare il metodo prima di interpretare le immagini e pubblicare i dati insieme a ogni eventuale punteggio.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.