Huggingface_hub è la libreria Python che forma la base dell'ecosistema Hugging Face. Numerose librerie come transformers, datasets, diffusers, sentence-transformer e altre si affidano ad essa per interagire con il Hub. Una settimana di ritardo nel rilascio rappresenta una settimana di correzioni e nuove funzionalità bloccate su main.

In passato, i rilasci avvenivano ogni 4 a 6 settimane; oggi, invece, seguono un piano settimanale attraverso un unico workflow GitHub Actions. Questo è stato costruito utilizzando strumenti open-source, modelli aperti pesi, e mantenendo l'elemento umano dove la decisione è critica. Nulla di quanto descritto qui richiede un contratto con un vendor, un modello chiuso o infrastruttura esterna. È stato questo il principale obiettivo del design iniziale, poiché lo scopo era creare un processo che potesse essere facilmente adattato da altri manutenitori.

Ripensare al vecchio processo

Il vecchio processo era parzialmente automatizzato e prevalentemente manuale. Scrivere note significative per una nuova versione rappresentava una parte estremamente laboriosa, visto che era necessario aggregare decine di PR su diversi argomenti. Non trattavasi di qualcosa tecnicamente difficile, ma richiedeva ore di attenzione concentrata. Aggiungendo le notifiche e rilasciando una versione minore, si poteva contare sull'occuparsi di mezzo giorno di lavoro, distribuito su diversi giorni.

Per migliorare il tutto, abbiamo suddiviso il lavoro in due parti distinte:

Le operazioni completamente meccaniche, come aggiornare la versione, creare un tag, spingere, aprire teste di rilascio su branch downstream e il PR post-rilascio, sono automatizzabili e non richiedono pensiero da parte dell'utente. Questo tipo di lavoro richiede solo che venga eseguito in ordine corretto. Ci pensa il CI ad occuparsene.
Altro genere di lavoro richiede invece decisioni creative, come scrivere le note del rilascio, decidere cosa evidenziare e formulare annuncio per il pubblico. È il tipo di lavoro di giudizio che teneva il rilascio manuale per anni. Qui entra in gioco l'AI, in grado di generare un buon draft in pochi secondi.

Tuttavia, dobbiamo anche essere cauti: un draft che sembri confidente ma contenga errori sottili è peggio dell’assenza di un draft. Quindi, quando abbiamo deciso di affrontare il problema, abbiamo posto un vincolo iniziale: ogni parte del sistema doveva essere qualcosa che chiunque fosse manutenitore potesse eseguire autonomamente. Nessun modello chiuso accessibile tramite API, nessuna piattaforma di rilascio proprietaria, nessun segreto.

Due principi guida del workflow

Il secondo principio guida il workflow è il seguente: il modello genera, l’essere umano decide. I modelli linguistici sono bravi a prendere trenta titoli di PR concisi e riscriverli in note di rilascio leggibili. Tuttavia non sono bravi ad essere ciechi. Questo workflow ha bisogno di supervisione umana: il modello genera un primo passo, uno script deterministico controlla il lavoro e un essere umano lo rivede e lo modifica prima che venga effettivamente rilasciato (di più su questo dopo).

Il workflow completo è racchiuso in un unico file, .github/workflows/release.yml, che è lanciato manualmente dall'interfaccia di Actions. Richiede esattamente un unico input in ingresso:

I restanti passaggi manuali rimangono nella revisione e pubblicazione del progetto delle note di rilascio e nella revisione e invio di un messaggio interno su Slack. Sono questi due i punti in cui vogliamo un essere umano che tenga a mente la situazione.

Prevenzione di errori comuni con rilasci AI

Gli errori comuni con le note di rilascio generate dall’AI includono il modello che silenziosamente toglie un PR oppure ne inventa uno che non era presente. Una cronologia quasi corretta è peggiore dell’assenza di cronologia perché quasi nessuno la rivede.

Non ci fidiamo che le note di rilascio generate siano complete al primo tentativo. Le verifichiamo in modo deterministico. Prima che il modello vada in esecuzione, uno script Python recupera tutti i PR che rientrano nel rilascio e li immagazzina come dati di ground truth.

Poi, il modello traccia le note di rilascio. Fatto questo, confrontiamo l’output rispetto all’elenco iniziale di PR:

Se manca qualcosa o c'è qualcosa in più, non falliamo e non rilasceremo file errati. Passiamo la discrepanza all’agente e gli chiediamo di correggerli esattamente per quei PR:

Questa strategia rende tutto il sistema affidabile: un modello non deterministico è incorniciato da guardie deterministiche. Il modello eccelle nel produrre testi ma risulta instabile nell’essere esaustivo. Quindi lo lasciamo generare e lasciamo il codice supervisionare la coerenza.

Assicurazione di completezza e precisione

La completezza è solo il primo dei due elementi chiave. L'accuratezza ne è l'altro. Un modello che somma un PR solo dal titolo potrebbe tranquillamente inventare un esempio di codice che non corrisponde all'API reale.

Per prevenire questo scenario, quando recuperiamo i metadati del PR recuperiamo anche le modifiche effettive della documentazione, quelle che il PR ha toccato: la differenza unificata di un qualsiasi .md file nella directory docs.

Questo confronto va nel contesto del modello, in modo che, quando scrive “eccoti il nuovo comando CLI”, citi esattamente l’esempio che l'autore del PR ha effettivamente incluso nella doc. Lo stesso ragionamento si applica: si dà al modello un materiale da cui attingere e un lavoro ristretto.

Drafting delle note con AI

Gli stessi prompt del modello vengono conservati come Skills: piccoli file Markdown (SKILL.md e template di riferimento) caricati nel repository. La skill "note_rilascio" spiega esattamente come selezionare highlights, strutturare le sezioni, quando aggiungere un link alla documentazione, e così via. Si presenta come una guida per l'onboarding: questa è, infatti, la descrizione mentale corretta.

Dopo che il draft RC è pubblicato, le note di rilascio di GitHub restano lì con la prima stesura dell'AI. È qui che entra in gioco l’essere umano:

Il tempo del revisore si dedica al perfezionamento, trasformando una mezza giornata di scrittura in una sessione di editing di quindici minuti.

Creazione di un tracciato per il miglioramento

Conservare un tracciato per il miglioramento: archiviamo due file paralleli in un bucket di Hugging Face. Il primo è il draft RAW AI, caricato al momento della release candidate prima che venga riveduto da qualcuno; il