Optimierung des Veröffentlichungsprozesses bei Hugging Face durch KI und menschliche Aufsicht

Die kontinuierliche Weiterentwicklung und Bereitstellung von Softwarebibliotheken ist eine zentrale Herausforderung im modernen Software-Engineering. Insbesondere im Bereich der Künstlichen Intelligenz, wo Innovationen schnell aufeinanderfolgen, ist ein effizienter Veröffentlichungszyklus von großer Bedeutung. Hugging Face, bekannt für seine Beiträge zur Open-Source-KI-Gemeinschaft, hat seinen Veröffentlichungsprozess für die kritische Python-Client-Bibliothek `huggingface_hub` signifikant optimiert. Dieser Artikel beleuchtet die technische Umsetzung und die zugrundeliegenden Prinzipien dieser Umstellung, die auf einer Kombination aus Künstlicher Intelligenz, Open-Source-Tools und menschlicher Aufsicht basiert.

Hintergrund: Die Evolution des Veröffentlichungsprozesses

Die Bibliothek `huggingface_hub` bildet das Fundament des Hugging Face Ökosystems. Bibliotheken wie `transformers`, `datasets` und `diffusers` sind auf sie angewiesen, um mit dem Hugging Face Hub zu interagieren. Eine langsame Veröffentlichungsfrequenz bedeutete, dass Fehlerbehebungen und neue Funktionen über Wochen im `main`-Branch verbleiben konnten, bevor sie für die Benutzer verfügbar waren.

Ursprünglich erfolgte die Veröffentlichung von `huggingface_hub` in Zyklen von vier bis sechs Wochen. Dieser Prozess war teilweise automatisiert, enthielt jedoch zahlreiche manuelle Schritte, die viel Zeit und Aufmerksamkeit erforderten. Zu den manuellen Aufgaben gehörten:

• Das Erstellen von Release-Branches und das Aktualisieren von Versionsnummern.
• Das Überwachen von CI-Läufen in nachgelagerten Bibliotheken.
• Das manuelle Verfassen von Release Notes, die eine Zusammenfassung der seit der letzten Veröffentlichung zusammengeführten Pull Requests darstellten.
• Das Erstellen von internen und externen Ankündigungen.
• Das Aktualisieren des `main`-Branches auf die nächste Entwicklungsversion.

Insbesondere das Erstellen aussagekräftiger Release Notes, die zahlreiche Pull Requests aus verschiedenen Themenbereichen zusammenfassen mussten, erwies sich als zeitaufwendig und erforderte ein hohes Maß an Konzentration. Dies konnte leicht einen halben Arbeitstag in Anspruch nehmen, verteilt über mehrere Tage.

Die Designprinzipien der Transformation

Angesichts dieser Herausforderungen wurde eine Neugestaltung des Veröffentlichungsprozesses initiiert. Zwei zentrale Prinzipien leiteten die Entwicklung:

1. Automatisierung mechanischer Schritte: Aufgaben wie Versionsaktualisierungen, das Erstellen von Branches, Tags und das Auslösen von Tests in nachgelagerten Bibliotheken wurden vollständig automatisiert.
2. KI-Unterstützung für kreative Aufgaben mit menschlicher Kontrolle: Das Verfassen von Release Notes und Ankündigungen, das Urteilsvermögen und ein Verständnis für Nuancen erfordert, wurde durch KI-Modelle unterstützt. Dabei wurde jedoch stets ein Mensch in den Prozess integriert, um die Qualität und Richtigkeit der Inhalte zu gewährleisten.

Ein weiteres entscheidendes Designziel war die Offenheit und Wiederverwendbarkeit des gesamten Workflows. Es wurde bewusst auf proprietäre Lösungen, geschlossene Modelle oder spezifische Infrastrukturen verzichtet, um anderen Maintainern die Adaption des Prozesses zu ermöglichen.

Technologischer Stack

Der umgesetzte Stack basiert auf folgenden Komponenten:

• GitHub Actions: Orchestriert den gesamten Veröffentlichungsprozess.
• OpenCode: Eine Agenten-Laufzeitumgebung, die das KI-Modell steuert.
• Open-Weights-Modell (derzeit GLM-5.2 von Z.ai): Generiert Entwürfe für Release Notes und Slack-Ankündigungen.
• HF Inference Providers: Stellt die Dienste für das KI-Modell bereit.
• PyPI Trusted Publishing: Ermöglicht die sichere Veröffentlichung von Paketen auf PyPI.

Der optimierte Veröffentlichungs-Workflow im Detail

Der gesamte Workflow ist in einer einzigen GitHub Actions-Datei (`.github/workflows/release.yml`) definiert und kann manuell über die Actions-Benutzeroberfläche ausgelöst werden. Dabei kann zwischen verschiedenen Veröffentlichungstypen gewählt werden:

• `minor-prerelease`: Erstellung eines Release Candidates (RC) aus dem `main`-Branch.
• `minor-release`: Promotion eines RC zur finalen Version.
• `patch-release`: Bugfixes auf einem bestehenden Release-Branch.

Die Jobs laufen in einer vordefinierten Reihenfolge ab:

1. Vorbereitung: Berechnung der nächsten Version, Erstellung oder Wiederverwendung des Release-Branches, Aktualisierung der Versionsnummer, Commit, Tagging und Push.
2. Veröffentlichung auf PyPI: Build und Upload von `huggingface_hub` und der `hf`-CLI als separates PyPI-Paket.
3. Release Notes: Ermittlung der Änderungen seit dem letzten Tag, Abruf von Pull Request-Metadaten von der GitHub-API und Erstellung eines strukturierten Changelog-Entwurfs durch das KI-Modell. Dieser wird als Entwurf einer GitHub-Veröffentlichung gespeichert.
4. Downstream-Test-Branches: Für RCs werden Test-Branches in abhängigen Bibliotheken wie `transformers`, `datasets` und `diffusers` erstellt, die den RC verwenden, um frühzeitig Integrationsprobleme zu erkennen.
5. Slack-Ankündigung: Erstellung einer internen Ankündigung basierend auf den Release Notes.
6. Archivierung der Release Notes: Speicherung des ursprünglichen KI-Entwurfs und der finalen, von Menschen bearbeiteten Version in einem Hugging Face Bucket.
7. Post-Release-Versionierung: Nach einer stabilen Veröffentlichung wird ein Pull Request im `main`-Branch erstellt, um die Version auf die nächste Entwicklungsversion zu erhöhen.
8. Kommentierung von Pull Requests: Automatische Kommentierung aller im Release enthaltenen Pull Requests mit einem Hinweis auf die Versionsnummer.
9. Synchronisierung der CLI-Dokumentation: Erstellung eines Pull Requests im `skills`-Repository mit der neu generierten `hf`-CLI-Skill-Dokumentation.
10. Statusmeldung an Slack: Jeder Schritt des Workflows sendet Statusaktualisierungen an Slack, wobei eine abschließende Nachricht den Gesamterfolg oder -misserfolg meldet.

Die verbleibenden manuellen Schritte umfassen die Überprüfung und Veröffentlichung der Entwürfe der Release Notes sowie die Überprüfung und Veröffentlichung der internen Slack-Nachricht. Diese Schritte sind die entscheidenden menschlichen Kontrollpunkte.

Vertrauen, aber überprüfen: Der Mensch im Kreislauf

Ein zentrales Anliegen bei KI-generierten Inhalten ist die Genauigkeit und Vollständigkeit. Es besteht die Gefahr, dass das Modell Pull Requests übergeht oder nicht existierende Änderungen erfindet. Ein fast korrektes Changelog kann problematischer sein als gar keines, da es möglicherweise nicht erneut überprüft wird.

Um dies zu adressieren, wurde ein Mechanismus implementiert, der die deterministische Überprüfung der KI-generierten Inhalte sicherstellt. Vor der Ausführung des Modells extrahiert ein Python-Skript alle relevanten Pull Request-Nummern und speichert sie als Referenz. Nachdem das Modell die Release Notes generiert hat, wird seine Ausgabe mit dieser Referenzliste verglichen.

Falls Abweichungen festgestellt werden (fehlende oder zusätzliche Pull Requests), wird das Modell aufgefordert, diese spezifischen Inkonsistenzen zu beheben. Dieser Ansatz kombiniert die Stärken des Modells bei der Texterstellung mit der Zuverlässigkeit deterministischer Code-Überprüfungen. Das Modell ist effizient im Verfassen von Prosa, aber unzuverlässig in Bezug auf Vollständigkeit; der Code stellt die Konsistenz sicher.

Modell-Grounding zur Vermeidung von Halluzinationen

Neben der Vollständigkeit ist auch die Genauigkeit der Inhalte von entscheidender Bedeutung. Ein Modell, das eine PR nur anhand ihres Titels zusammenfasst, könnte leicht falsche Codebeispiele oder API-Details erfinden. Um dies zu verhindern, werden beim Abrufen der Pull Request-Metadaten auch die tatsächlichen Dokumentations-Diffs (Änderungen in `.md`-Dateien unter `docs/`) der jeweiligen Pull Requests erfasst.

Diese Diff-Informationen werden dem Modell als Kontext zur Verfügung gestellt. Dadurch kann das Modell beim Beschreiben neuer CLI-Befehle oder anderer Änderungen auf die tatsächlichen Beispiele und Beschreibungen zurückgreifen, die der Autor des Pull Requests in der Dokumentation hinterlegt hat. Dies stellt sicher, dass das Modell mit realen Quelldaten arbeitet und seine Aufgabe präziser erfüllen kann.

Die Prompts selbst sind als "Skills" in Markdown-Dateien im Repository hinterlegt. Diese Skills definieren, wie Highlights ausgewählt, Abschnitte strukturiert und Dokumentationslinks hinzugefügt werden sollen, ähnlich einer Onboarding-Anleitung.

Der menschliche Kontrollpunkt: Qualitätssicherung

Nach der Veröffentlichung eines Release Candidates verbleibt der Entwurf der GitHub-Veröffentlichung mit dem ersten Entwurf der KI. An diesem Punkt tritt der Mensch in Aktion:

1. Ein Reviewer liest den Entwurf, überarbeitet den Ton und die Schwerpunkte und korrigiert etwaige Ungenauigkeiten des Modells.
2. Erst nach dieser Überprüfung wird der `minor-release`-Lauf ausgelöst, der den RC zur finalen Version befördert.

Die Zeit des Reviewers wird somit auf das Polieren konzentriert, wodurch ein einst halbtägiger Schreibprozess zu einer fünfzehnminütigen Bearbeitungssitzung wird.

Zusätzlich wird ein Audit-Trail geführt: Sowohl der unbearbeitete KI-Entwurf als auch die von Menschen bearbeitete Version werden wöchentlich in einem Hugging Face Bucket archiviert. Diese Sammlung dient als Datensatz, um zukünftige Verbesserungen der Agenten-Skills zu ermöglichen, indem die Diskrepanz zwischen dem, was das Modell generiert hat, und dem, was gewünscht wurde, analysiert wird.

Offene und sichere Implementierung

Die Überarbeitung des Veröffentlichungsprozesses bot auch die Gelegenheit, die Sicherheit zu erhöhen, insbesondere im Hinblick auf Supply-Chain-Angriffe.

• Kein PyPI-Token: Für die Veröffentlichung wird "Trusted Publishing" verwendet. PyPI verifiziert ein kurzlebiges OIDC-Token, das von GitHub speziell für diesen Workflow generiert wird. Dadurch entfällt die Notwendigkeit eines langlebigen Secrets, das geleakt oder rotiert werden könnte.
• Verifizierte Agenten-Laufzeitumgebung: Die OpenCode-Laufzeitumgebung wird nicht einfach per `curl | bash` installiert. Stattdessen wird eine spezifische Version angeheftet und ihre SHA256-Prüfsumme vor der Ausführung überprüft.

Diese Maßnahmen unterstreichen, dass offene Tools nicht gleichbedeutend mit nachlässiger Handhabung sind.

Kosten und Auswirkungen

Die Kosten für diesen optimierten Prozess sind minimal. Eine vollständige Veröffentlichung, inklusive Release Notes und Slack-Ankündigung für 20-40 Pull Requests und mehrere Prompting-Runden, beläuft sich auf etwa 0,25 US-Dollar über Inference Providers. Da Open-Weights-Modelle nach Verbrauch abgerechnet werden, stellt sich die einzige relevante Frage jede Woche, ob es sich lohnt, eine neue Version zu veröffentlichen – und das ist fast immer der Fall.

Die praktischen Auswirkungen der Umstellung sind bemerkenswert:

• Wöchentlicher Release-Zyklus: Die Frequenz konnte von alle 4-6 Wochen auf wöchentlich erhöht werden.
• Verbesserte Release Notes: Die Qualität der Release Notes hat sich verbessert, da die Überarbeitungszeit für das Polieren genutzt werden kann.
• Frühere Erkennung von Fehlern: Downstream-Test-Branches in den RCs fangen Integrationsprobleme frühzeitig ab.
• Kürzere Feedbackschleifen für Mitwirkende: Die automatische Kommentierung von Pull Requests mit der Versionsnummer, in der die Änderung enthalten ist, hat sich als unerwartet wertvoll erwiesen.

Anpassbarkeit und Zukunftsaussichten

Der entwickelte Workflow ist um `huggingface_hub` herum konzipiert, seine Struktur ist jedoch generisch und kann von anderen Projekten wiederverwendet werden. Insbesondere folgende Elemente sind nahezu unverändert übertragbar:

• Die Trigger- und Versionslogik.
• Der "Vertrauen, aber überprüfen"-Kreislauf: deterministisches Manifest, Modellentwurf, Validierung, erneutes Prompting.
• OIDC Trusted Publishing, verifizierte Laufzeitumgebung, Slack-Threading.
• Die Skill-basierten Prompts, bei denen die Templates ausgetauscht, die Struktur jedoch beibehalten werden kann.

Spezifische Anpassungen sind lediglich für die Liste der nachgelagerten Repositories, die genaue Gliederung und den Ton der Skills sowie die Zielorte für Slack-Nachrichten und Buckets erforderlich.

Für die Zukunft sind weitere Optimierungen geplant, wie die automatische Kategorisierung von Downstream-Fehlern und die Ausweitung des Musters auf andere Python-Bibliotheken im Hugging Face Ökosystem.

Fazit

Die Neugestaltung des Veröffentlichungsprozesses bei Hugging Face demonstriert eindrucksvoll, wie die Kombination von Künstlicher Intelligenz, Open-Source-Tools und menschlicher Expertise die Effizienz und Qualität von Software-Releases nachhaltig verbessern kann. Die Aufgaben, die früher einen erheblichen manuellen Aufwand erforderten, wie das Verfassen von Release Notes und Ankündigungen, werden nun durch KI-Modelle unterstützt. Gleichzeitig stellen deterministische Code-Überprüfungen und menschliche Kontrollpunkte sicher, dass die generierten Inhalte präzise und zuverlässig sind. Die Offenheit des Ansatzes ermöglicht es anderen Maintainern, diesen Workflow zu adaptieren und von den gewonnenen Erkenntnissen zu profitieren.

Bibliographie

• Wauplin & Hanouti, C. (2026, 23. Juni). Shipping huggingface_hub every week with AI, open tools, and a human in the loop. Hugging Face Blog. Verfügbar unter: https://huggingface.co/blog/huggingface-hub-release-ci
• Wauplin. (2026, 2. März). Automated release notes · Issue #3869 · huggingface/huggingface_hub. GitHub. Verfügbar unter: https://github.com/huggingface/huggingface_hub/issues/3869
• Wauplin. (2026, 30. April). [Release] Move social drafts to minor-release and archive release notes to bucket · Pull Request #4173 · huggingface/huggingface_hub. GitHub. Verfügbar unter: https://github.com/huggingface/huggingface_hub/pull/4173
• Wauplin. (2026, 23. April). [Release] Add social media draft generation to release workflow (#4132) · 50444e5 · huggingface/huggingface_hub. GitHub. Verfügbar unter: https://github.com/huggingface/huggingface_hub/commit/50444e55029608bdb12c70be76c82359b8c70250
• Hanouti, C. (2026, 11. Juni). [CI] Fix versioned docs not publishing on release · Pull Request #4344 · huggingface/huggingface_hub. GitHub. Verfügbar unter: https://github.com/huggingface/huggingface_hub/pull/4344
• Hugging Face. (o. D.). Trusted Publishers. Hugging Face Docs. Verfügbar unter: https://huggingface.co/docs/hub/trusted-publishers
• Narr, F. (2026, 3. Mai). ml-intern: Hugging Face's Autonomous ML Engineer. Codeline. Verfügbar unter: https://www.codeline.co/thoughts/repo-review/2026/ml-intern-huggingfaces-autonomous-ml-engineer