Distribuire huggingface_hub ogni settimana con l'intelligenza artificiale, strumenti aperti e un team umano

Introduzione ad huggingface_hub

huggingface_hub è il client Python alla base dell'ecosistema Hugging Face. Librerie come transformers, datasets, diffusers, sentence-transformers e decine di altre dipendono da essa per comunicare con il Hub. Ogni settimana in cui non rilaschiamo una nuova versione, sono settimane in cui aggiuste e nuove funzionalità restano bloccate sul ramo main.

Dal vecchio al nuovo processo

Fino a poco tempo fa, facevamo rilasci ogni 4 a 6 settimane. Ora rilaschiamo ogni settimana attraverso un singolo workflow di GitHub Actions. Abbiamo costruito questo sistema utilizzando strumenti open source e modelli con pesi aperti mantenendo comunque un essere umano coinvolto là dove è necessaria una valutazione. Nulla in questo post richiede un contratto con un venditore, un modello chiuso o infrastruttura non eseguibile da voi stessi.

Entro la fine di questo articolo, avrete tutto ciò che serve per costruire il vostro stesso sistema.

Il vecchio processo

Il vecchio processo era in parte automatizzato e per lo più manuale. Scrivere buone note per una nuova versione era la parte più impegnativa, richiedendo di aggregare decine di pull request su diversi argomenti. Non era tecnicamente difficile ma richiedeva ore di attenzione concentrata. Aggiungerevi le annuncio ufficiale rendeva un minore rilascio facilmente una mezza giornata di lavoro sparsa in diversi giorni.

Ridurre il processo

Abbiamo deciso di semplificare tutto. Vedendo quell'elenco, il lavoro si divide in due categorie:

• Alcuni passaggi sono puramente meccanici e possono essere automatizzati: aggiornare la versione, commit, tag, spingere, aprire i test branch downstream, aprire il pull request post rilascio. Non è necessario pensare a questi passaggi. Devono simplemente avvenire nel giusto ordine, ogni volta.
• L’altra parte è diversa. Scrivere le note di rilascio, decidere cosa evidenziare, formulare annunci per una comunità umana: è lavoro manuale che ha tenuto il rilascio manuale per anni. Questo è dove entra in gioco l'intelligenza artificiale, trasformando una pagina vuota in una buona bozza in pochi secondi. Ma è anche qui che dobbiamo stare attenti, perché una bozza che sembra corretta ma è sottilemente sbagliata è peggio di nessuna bozza.

Quando abbiamo deciso di risolvere questo problema, abbiamo posto un vincolo chiaro fin dall'inizio: ogni componente del sistema doveva essere qualcosa che tutti gli sviluppatori potessero eseguire da soli. Nessun modello chiuso dietro un API, nessuna piattaforma di rilascio proprietaria, nessun segreto nascosto.

AI in azione

Il secondo principio è: il modello suggerisce, l’umano decide. I modelli linguistici sono buoni nel trasformare decine di titoli di PR concisi in note leggibili. Ma non sono buoni da fidarsi ciecamente. Pertanto, il workflow è supervisionato da un essere umano: il modello produce la prima bozza, uno script deterministico controlla il lavoro, e un umano revisiona e modifica prima di qualcosa venga rilasciato.

Il completo workflow in un solo file

Il workflow completo si trova in un unico file, .github/workflows/release.yml, attivato manualmente tramite l'interfaccia di azioni GitHub. Richiede esattamente un input.

Controlli umani nel workflow

I restanti passaggi manuali sono la revisione e la pubblicazione delle note di rilascio, e la revisione e l'invio di un messaggio interno su Slack. Questi due passaggi sono i punti in cui vogliamo un essere umano coinvolto.

Sicurezza nella generazione automatica

Uno scenario frequente di fallimento legato alle note generate dall'intelligenza artificiale è la mancata citazione delle PR reali o l'invenzione di una non esistente. Una cronologia quasi corretta è peggiore di nessuna cronologia perché nessuno la verifica. Non ci fidiamo completamente delle note generate e le verifichiamo in modo deterministico prima dell’invio.

La precisione e la completatezza

Prima che il modello corra, uno script Python recupera tutte le PR che fanno parte del rilascio e le utilizza come verità assoluta. Il modello elabora le note in base alla lista. Una volta completata la stesura, confrontiamo il contenuto con la lista iniziale:

• Se manca qualcosa o ne aggiunge di extra, non rifiutiamo, né distribuiamo un file errato. Chiediamo al sistema di correggere puntualmente quei PR mancanti.

Questo schema rende l'intero sistema affidabile: un modello non deterministico circondato da guardie deterministe. Il modello è bravo a generare testi ma non a essere esaustivo, quindi gli permettiamo di scrivere e chiamiamo il codice per verificare la coerenza.

I dati per le note

La completezza è un aspetto. L’accuratezza è l’altro. Un modello che sintetizza una PR da un titolo potrebbe inventarsi un esempio che non corrisponde all’API effettiva. Per evitare ciò, quando recuperiamo i PR, prendiamo anche le modifiche effettive dei file di documentazione: diff unificati di ogni file .md modificato.

Prompts come skill

I promt stessi sono archiviati come skill: file Markdown piccoli (SKILL.md più template di riferimento) inclusi nel repository. Il "releasenotes skill" spiega come selezionare i punti salienti, come strutturare le sezioni, quando aggiungere collegamenti alla documentazione, ecc. Legge come una guida d'introduttiva, che è la modello mentale corretto.

Revisione e miglioramento

Dopo che il PR candidato è stato pubblicato, la bozza di release su GitHub rimane lì con la prima passata dell’IA. Questo è dove entra in gioco il team umano:

Il tempo del revisore serve a migliorare, trasformando un lavoro manuale di mezza giornata in una sessione di editing di quindici minuti.

Archiviare per imparare

Archiviamo due file paralleli su un Hugging Face Bucket: la bozza grezza dell’IA, caricata al momento del rilascio candidate prima di essere toccata, e la versione modificata dal team umano, caricata quando il rilascio definitivo viene completato.

Prevenzione degli attacchi a catena

Non c'è alcun token PyPI. La pubblicazione utilizza la pubblicazione fidata: PyPI verifica un token OIDC a breve durata emesso da GitHub per questo esatto workflow, e genera attestazioni PEP 740/Sigstore per ogni artefatto. Non c'è nessun segreto lungo a perdere o ruotare.

Costi e risparmio

Quasi niente. Un rilascio completo (note più l’annuncio