كيف تُصدر Hugging Face عميل بايثون الخاص بها كل أسبوع باستخدام أدوات مفتوحة المصدر ومراجعة بشرية

قامت Hugging Face بهدم وإعادة بناء خط أنابيب إصدار huggingface_hub، عميل بايثون الذي يدعم الكثير من نظامها البيئي، من بينها transformers وdatasets وdiffusers وsentence-transformers. يدفع النظام الجديد نسخة جديدة كل أسبوع، معتمدًا على مجموعة أدوات مفتوحة المصدر بالكامل، وسير عمل واحد لـ GitHub Actions، ونموذج مفتوح الأوزان يكتب ملاحظات الإصدار تحت ضوابط حتمية.

"كل أسبوع لا نصدر فيه إصدارًا جديدًا هو أسبوع من الإصلاحات والميزات العالقة على main،" كتب الفريق في منشور مدونة يشرح التفاصيل. الإيقاع القديم، إصدار واحد كل 4 إلى 6 أسابيع، المتشابك مع الخطوات اليدوية، أفسح المجال لخط أنابيب أسبوعي آلي يعمل بحوالي 0.25 دولار أمريكي لكل عملية ولا يتطلب بنية تحتية خاصة.

المشكلة: نوعان من العمل

كانت عملية الإصدار السابقة مؤتمتة جزئيًا، حيث تنشر إلى PyPI عبر دفع الوسوم وتفتح فروع اختبار فرعية، لكنها كانت لا تزال تتطلب إنسانًا لعدة خطوات: إنشاء فرع الإصدار، رفع رقم الإصدار، مراقبة تشغيل CIs الفرعية، كتابة ملاحظات الإصدار يدويًا، قص الإصدار المستقر، صياغة الإعلانات، وفتح طلب السحب بعد الإصدار.

"كتابة ملاحظات جيدة لنسخة جديدة كانت الجزء الثقيل،" يلاحظ المنشور. "لا شيء صعب تقنيًا ولكن بضع ساعات من الاهتمام المركز." يمكن للإصدار البسيط أن يستهلك بسهولة نصف يوم عمل، موزعًا على عدة أيام.

أدرك الفريق أن العمل يقع في فئتين: المهام الميكانيكية البحتة مثل رفع رقم الإصدار والوسم (قابلة للأتمتة بالكامل) وتلك التي تتطلب حكمًا مثل كتابة ملاحظات الإصدار وصياغة الإعلانات لجمهور بشري.

الحل: أدوات مفتوحة المصدر، أوزان مفتوحة، إشراف بشري

من البداية، فرض الفريق قيدًا في التصميم: كل جزء متحرك يجب أن يكون شيئًا يمكن لأي مشرف تشغيله بنفسه. لا نموذج مغلق، لا منصة إصدار خاصة، لا وصفة سرية.

المكون	الدور
GitHub Actions	ينسق عملية الإصدار بأكملها
OpenCode	بيئة تشغيل الوكيل التي تقود النموذج
GLM-5.2 (من Z.ai)	نموذج مفتوح الأوزان يصوغ ملاحظات الإصدار وإعلانات Slack
HF Inference Providers	يخدم النموذج على أساس الدفع حسب الاستخدام
PyPI Trusted Publishing	ينشر الحزمة بأمان قائم على OIDC

المبدأ الثاني كان بسيطًا: النموذج يصوغ، الإنسان يقرر. "نماذج اللغة جيدة في تحويل ثلاثين عنوان طلب سحب موجز إلى ملاحظات إصدار قابلة للقراءة. إنها ليست جيدة في أن تُوثق بها بشكل أعمى."

خط الأنابيب: جولة

يعيش سير العمل الكامل في ملف YAML واحد، يتم تشغيله يدويًا من واجهة GitHub Actions مع إدخال واحد: نوع الإصدار، minor-prerelease، minor-release، أو patch-release.

تعمل المهام بالتسلسل: التحضير (حساب الإصدار، إنشاء الفرع، رفع الإصدار، الوسم، الدفع)، النشر على PyPI، توليد ملاحظات الإصدار من فرق طلب السحب بمساعدة النموذج، فتح فروع الاختبار الفرعية للإصدارات المرشحة (RCs)، صياغة إعلان Slack، أرشفة كل من الملاحظات الأولية والمحررة، رفع الإصدار إلى إصدار التطوير التالي بعد الإصدار المستقر، التعليق على طلبات السحب التي تم شحنها، مزامنة وثائق CLI، والإبلاغ عن الحالة إلى Slack.

تبقى خطوتان يدويتان فقط: مراجعة ونشر ملاحظات الإصدار الأولية، ومراجعة ونشر رسالة Slack الداخلية. هذه هي الأماكن التي يبقى فيها الحكم البشري ضروريًا.

ثق ولكن تحقق: جوهر الحلقة البشرية

الابتكار الحقيقي للفريق هو حلقة تحقق حتمية تمنع النموذج من إسقاط أو اختراع طلبات السحب بصمت. قبل تشغيل النموذج، يسترد سكربت بايثون جميع طلبات السحب في الإصدار عن طريق استخراج الأرقام من عمليات دمج السحق والالتزام:

PR_NUMBER_PATTERN = re.compile(r"\(#(\d+)\)$")
pr_numbers = [
    int(m.group(1))
    for commit in commits_since_last_tag
    if (m := PR_NUMBER_PATTERN.search(commit.title))
]
save_manifest(pr_numbers)

بعد أن يصوغ النموذج الملاحظات، يتحقق السكربت من أن كل رقم طلب سحب متوقع موجود ولا تظهر أرقام إضافية. إذا ظهرت تباينات، يُطلب من الوكيل إصلاح طلبات السحب تلك بالضبط في حلقة تصل إلى MAX_ITERATIONS تكرار.

"هذا هو النمط الذي يجعل الأمر بأكمله جديرًا بالثقة: نموذج غير حتمي ملفوف بضوابط حتمية،" يذكر المنشور.

تأريض النموذج ببيانات حقيقية

الاكتمال هو نصف المعادلة؛ الدقة هي النصف الآخر. النموذج الذي يلخص طلب سحب من عنوانه وحده قد يخترع أمثلة برمجية لا تطابق واجهة برمجة التطبيقات الحقيقية. لوقف ذلك، يجلب سير العمل فروقات الوثائق الفعلية من كل طلب سحب، وتحديدًا الفرق الموحد لأي ملف .md تحت docs/ الذي لمسه طلب السحب، ويضمن ذلك في سياق النموذج.

التعليمات نفسها مخزنة كمهارات: ملفات Markdown صغيرة مودعة في المستودع تحدد كيفية اختيار النقاط البارزة، هيكلة الأقسام، وتضمين روابط الوثائق. "يبدو الأمر وكأنه تعليمات تأهيل، وهو بالضبط النموذج العقلي الصحيح."

الأمان والشفافية

شددت عملية الإصدار المُجددة أيضًا الأمان ضد هجمات سلسلة التوريد. يستخدم نشر PyPI أسلوب النشر الموثوق (Trusted Publishing)، حيث يتحقق PyPI من رمز OIDC قصير العمر الذي يصدره GitHub لسير العمل الدقيق، مما ينتج شهادات PEP 740 وتوثيق Sigstore لكل قطعة أثرية. لا توجد أسرار طويلة الأمد يمكن تسريبها أو تدويرها.

يتم تثبيت بيئة تشغيل الوكيل والتحقق منها باستخدام SHA256 قبل التنفيذ. "الأدوات المفتوحة لا تعني أدوات مهملة."

يقوم الفريق أيضًا بأرشفة كل من المسودة الأولية للذكاء الاصطناعي والنسخة المحررة بواسطة البشر إلى Hugging Face Bucket كل أسبوع، مما ينشئ مجموعة بيانات متزايدة من "ما كتبه النموذج" مقابل "ما كنا نتمنى أن يكتبه" لتحسين مهارة الوكيل بمرور الوقت.

ما تغير عمليًا

تحول الإيقاع من مرة كل 4, 6 أسابيع إلى مرة واحدة في الأسبوع. كانت التأثيرات الثانوية ملحوظة: تحسنت جودة واتساق ملاحظات الإصدار، وظهرت الأعطال مبكرًا بفضل فروع الاختبار الفرعية في كل إصدار مرشح (RC)، وقصرت حلقات المساهمين بفضل التعليقات التلقائية "شُحن في vX.Y.Z" التي ألغت عمليات البحث اليدوية عن الوسوم.

"الأجزاء من الإصدار التي كانت تحتاج إلى نصف يوم من العمل البشري المركز هي الأجزاء التي يجيد النموذج صياغتها،" يختتم المنشور. "كل شيء آخر ميكانيكي ويناسب ملف YAML. الحيلة لم تكن أبدًا مجرد 'دع الذكاء الاصطناعي يفعلها.' إنها دع النموذج يصوغ، دع الكود الحتمي يتحقق، ودع الإنسان يقرر."