كيفية بناء خط أنابيب CI/CD لنماذج اللغة الكبيرة باستخدام Divinci AI

ملاحظات من دورة الإصدار — الجزء الأول

في المرة الأولى التي حاولنا فيها شحن نموذج لغة كبير عبر خط أنابيب CI/CD اعتيادي، تحوّل البناء إلى الأخضر، ونجح النشر، وبدأ دعم العملاء بتلقّي التذاكر خلال سبع دقائق.

لم يكن هناك أي شيء “معطّل”. اجتازت كل اختبارات التكامل الـ4,200. ظلّت الكمون دون تغيير. صمد معدّل 200 OK. لكن في صنف معيّن من أسئلة المجال القانوني، بدأ النموذج الجديد بهدوء في التحفّظ — رافضًا الالتزام بإجابة كان الإصدار السابق يجيب عنها بشكل صحيح. لم يلتقط أي اختبار ذلك لأننا لم نكن قد كتبناه بعد.

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

ذلك الانقطاع هو سبب وجود خط الأنابيب هذا. ما يلي هو خط الأنابيب الفعلي الذي نُصدِر من خلاله إصداراتنا، والذي نُتيحه عبر واجهة Divinci API للعملاء الذين يشحنون إصداراتهم. يتكوّن من أربع مراحل — التسجيل، البوّابة، الطرح، المراقبة — ولكل خطوة مسار تراجع لا يعتمد على وجود إنسان مستيقظ.

المراحل الأربع

المراحل صارمة عن قصد. يمرّ كل إصدار عبر كل مرحلة بهذا الترتيب. لا يوجد مسار “إصلاح عاجل” يتخطى التقييم — جرّبنا ذلك مرة واحدة.

المرحلة 1 — التسجيل

الإصدار ليس ملف أوزان نموذج. الإصدار هو بيان غير قابل للتغيير يجمع:

• قطعة النموذج (مستودع HF + SHA الالتزام، أو رقعة vindex)
• قالب الموجِّه (كل متغيّر، وكل رسالة نظام)
• قواعد التوجيه (أي صنف حركة يصل إلى أي إصدار)
• نسخة مجموعة البيانات المستخدمة لحساب عتبات البوّابة
• SHA الإصدار السابق، حتى يكون التراجع لا لبس فيه

curl -X POST https://api.divinci.ai/v1/releases \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -d '{
    "model_ref": "Divinci-AI/gemma-4-e2b@a7c91f",
    "prompt_template_ref": "templates/legal-qa@v14",
    "routing": { "domain": "legal" },
    "dataset_version": "scored-qa-medical-v3",
    "previous_release": "rel_8f72b1"
  }'
# → { "release_id": "rel_a01c66", "manifest_sha256": "9abaeaf6..." }

إن SHA البيان هو المُعرِّف الوحيد الذي يستخدمه أي شخص في خط الأنابيب. إذا نشر شخصان ما يعتقدان أنه الإصدار نفسه واختلفت قيم SHA، يرفض خط الأنابيب النشر. اصطدنا حتى الآن خطأين بهذه القاعدة.

المرحلة 2 — البوّابة

البوّابة هي الجزء الذي تخطئ فيه معظم خطوط أنابيب CI. ستسمح مقاييس على غرار Lighthouse — الحيرة (perplexity)، BLEU، ROUGE — بمرور تراجع في الأداء إذا كان التراجع متركّزًا في مجال واحد. تطمسه النتائج الإجمالية.

تشغّل بوّابة Divinci مجموعة الأسئلة والأجوبة المُسجَّلة التي سُجِّل بها بيان الإصدار، وتطبّق عتبة Spearman لكل فئة:

سيجتاز الإصدار في المخطط أعلاه بوّابة إجمالية (المتوسط 0.64 “قريب بما يكفي”). لكنه يفشل في بوّابة Divinci لأن ترخيص الملكية الفكرية يهوي من 0.68 سابقًا إلى 0.41 — وهو بالضبط نوع التراجع المحلّي الذي لا يلتقطه دفتر تجارب أبدًا.

لم نخترع البوّابة الواعية بالشرائح من باب التسلية. إنها وضع الفشل المُسمّى مباشرةً في الموجة الحالية من تقارير ما بعد حوادث LLM. يصف مقال Tianpan “كذبة Semver”^[6] تغييرًا في الموجِّه “اجتاز مراجعة الكود، ونُشِر بدون بوّابات تقييم، ووصل إلى الإنتاج بدون A/B لكل مستخدم، ولم يُطلِق أي تراجع تلقائي.” الشيء الذي جعل تلك الحادثة كارثية بدل أن تكون مجرد مزعجة هو أن التراجع كان متركّزًا في شريحة واحدة — صنف واحد من رحلات المستخدم — بينما صمدت الأرقام الإجمالية. كل أدوات إصدار LLM التي استقصيناها في 2026 إما تُبوِّب على نتيجة عالمية واحدة، أو لا تُبوِّب إطلاقًا. لا أحد منها يُشرِّح البوّابة.

فشل البوّابة ليس تحذيرًا ناعمًا. يُعلَّم release_id بـ gate_fail، ويُؤرشَف البيان، ولن يقبله أي أمر نشر. الإصدارات من نقطة الصفر — نموذج جديد كليًا بلا تاريخ Spearman للمقارنة معه — تمرّ عبر مسار --force-gate-override لمرة واحدة يتطلّب مبرّرًا مكتوبًا؛ يدخل المبرّر، ومعرّف المستخدم، وgate_override_sha256 مباشرةً في مسار التدقيق. التجاوز موجود لأن هناك مواقف مشروعة له؛ مسار التدقيق موجود لأن “أنت في المستقبل” بحاجة لقراءة المبرّر.

المرحلة 3 — الطرح

كناري في Divinci يعني ثلاث نقاط تفتيش: 5٪، 25٪، 100٪. عند كل نقطة تفتيش، يحتفظ خط الأنابيب بالحالة إما لزمن المكوث المُعدَّل أو لعدد الطلبات المُعدَّل، أيهما أحدث. الافتراضي هو 4 دقائق / 1,000 طلب عند 5٪، و15 دقيقة / 10,000 طلب عند 25٪.

عند كل نقطة تفتيش، يجب أن يصمد ثلاثة مراقبين:

1. كمون p95 ضمن 1.2× من p95 الإصدار السابق
2. معدّل 5xx ضمن 1.5× من معدّل الإصدار السابق
3. مراقب جودة المخرجات: إعادة تشغيل مستمرة لآثار الإنتاج الحديثة عبر الإصدار المرشّح، مُقيَّمة بنفس الحَكَم المُعاير الذي شغّل المرحلة 2

الثالث هو الذي لا يشحنه أي خط أنابيب إصدار آخر. SageMaker، KServe، BentoML، Vertex AI — كلها تراقب الكمون ومعدّل الأخطاء. لا أحد منها يُقيِّم مخرجات المرشّح مقابل الأسئلة الفعلية التي يسألها الإنتاج الآن. يحصل المرشّح على نفس الموجِّهات التي حصل عليها الإصدار النشط للتوّ، يُشغّلها على مرآة 5٪، ونقيس ρ Spearman لإجابات المرشّح مقابل المُقيِّم المُعاير. يمكن أن يبقى معدّل 5xx نظيفًا بينما يتحفّظ النموذج بهدوء أو يرفض أو يهلوس. شاهدنا هذا يحدث. مراقب إعادة تشغيل الآثار هو ما يلتقط ذلك.

مجموعة إعادة التشغيل محدودة — نضع حدًا عند 50 أثرًا حديثًا لكل شريحة لكل نقطة تفتيش بحيث تكون التكلفة متوقّعة. التقييم يستغرق نحو 90 ثانية عند حركة 5٪. أبطأ من كناري بنسبة مئوية ثابتة، وأسرع من انتظار عميل ليرفع تذكرة.

# أمر الطرح هو "أطلِق وانسَ". خط الأنابيب يُمسك بنفسه.
curl -X POST https://api.divinci.ai/v1/releases/rel_a01c66/roll \
  -H "Authorization: Bearer $DIVINCI_API_KEY" \
  -d '{ "strategy": "canary", "dwell_5pct_seconds": 240, "dwell_25pct_seconds": 900 }'
# → { "rollout_id": "rol_b3e2", "next_checkpoint_at": "2026-05-26T09:04:00Z" }

المرحلة 4 — المراقبة، التراجع، والإيصال

هذه هي المرحلة التي تُبرِّر وجود خط الأنابيب.

يعمل المراقب باستمرار بعد اكتمال الطرح. يحسب نتيجة جودة مخرجات لكل دقيقة على عيّنة إعادة تشغيل آثار متجدّدة بنسبة 5٪. إذا انخفضت النتيجة تحت عتبة التراجع (الافتراضي: 0.85 من عتبة البوّابة، أي 0.55 إذا كانت البوّابة 0.65) لثلاث دقائق متتالية، يُطلَق التراجع تلقائيًا. لا تنبيه، ولا إنسان، ولا جدال.

التراجع نفسه تعليمة واحدة: أعِد توجيه التوجيه إلى previous_release من البيان. ولأن الإصدار السابق كان بيانًا مُجمَّعًا بالكامل، فإن كل مكوّن — الأوزان، الموجِّه، التوجيه، مجموعة البيانات — يُقلَب ذرّيًا.

ثم يُطلَق الإيصال.

كل قرار إصدار — تسجيل، اجتياز بوّابة، فشل بوّابة، تجاوز بوّابة، ترقية نقطة تفتيش، تعليق نقطة تفتيش، تراجع تلقائي، تراجع يدوي — يُصدِر إيصال إصدار: قطعة JSON مع SHA-256، مرتبطة بسلسلة تجزئة بالإيصال السابق لهذا العميل والإيصال السابق لهذا الإصدار، مرسّخة خارجيًا وفق جدول يُهيِّئه العميل.

عندما يكون الإصدار مدعومًا بنموذج مفتوح الأوزان — Gemma، Qwen، Llama، Mistral، GPT-OSS، أي نموذج أوزانه قابلة للعنونة والتعديل — يضمّن الإيصال شهادة vindex: برهانًا تشفيريًا على أن الأوزان النشطة وقت القرار هي الأوزان التي سجّلها البيان. هذا هو المسار الذي يستوفي طلبات الامتثال الأشد (المادة 17 من GDPR حق المحو، وأصول قانون الذكاء الاصطناعي الأوروبي) لأنه يمكنك إثبات ليس فقط ما الذي نُشِر بل أن الأوزان الكامنة هي ما تدّعيه.

عندما يكون الإصدار مدعومًا بنموذج مغلق الأوزان — OpenAI، Anthropic، Google، أي نموذج يُقدَّم فقط عبر API غامض — يغطّي الإيصال مع ذلك سلسلة القرار (أي بيان، أي نتيجة بوّابة، أي قراءة مراقب، أي مستخدم أطلق أي إجراء) لكنه لا يستطيع المصادقة على الأوزان الكامنة، لأننا لا نستطيع رؤيتها. هذا ليس قيدًا في خط الأنابيب؛ بل قيد على ما يمكن التحقق منه حين لا يكشف المزوّد عن الأوزان. المراجعون الذين يهتمّون بهذا التمييز يحصلون على إجابة صادقة في الإيصال نفسه.

في كلتا الحالتين، يحصل المراجعون اليوم على سجلات. مع هذا خط الأنابيب، يحصلون على براهين لكل ما يمكن إثباته فعلًا. لم نرَ أحدًا آخر في السوق يشحن هذا. نتوقّع أنهم سيفعلون — جداول قانون الذكاء الاصطناعي الأوروبي تجعل الأمر حتميًا في النهاية. اخترنا أن نشحنه الآن.

هذه ليست أرقامنا — إنها أرقام مصادر أوّلية منشورة من تقارير ما بعد الحوادث الحقيقية، ووثائق المنصّات، وإطار DORA. التباين هو ما يُحرِّك تصميم Divinci. استغرق انقطاع Atlassian في أبريل 2022^[1] اثنتي عشرة ساعة لكل موقع لأن الحالة كانت موزّعة عبر أنظمة متعدّدة تحتاج إلى التنسيق للعودة إلى التوافق. واستغرق انقطاع Cloudflare في يونيو 2022^[2] أربعًا وأربعين دقيقة للإلغاء لأن المهندسين، بكلماتهم الخاصة، كانوا يتداخلون مع إلغاءات بعضهم البعض. وتوثّق ضمانات نشر AWS SageMaker الكناري^[4] انتظار إنهاء افتراضي من عشر دقائق قبل اكتمال التراجع. وعتبة DORA^[3] للنخبة في التعافي من نشر فاشل هي “أقل من ساعة” — هذا هو الحد الذي يُتوقّع من منظّمة عالية الأداء تجاوزه، وليس السقف.

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

ما هذا، الذي لا تشحنه أدوات إصدار LLM الأخرى

استقصينا اثنتي عشرة أداة أخرى في 2026 قبل أن نبني هذه — LangSmith Deployment، W&B Models، MLflow، SageMaker Deployment Guardrails، Vertex AI Endpoints، Seldon Core، BentoCloud، KServe، Humanloop، Braintrust، Patronus AI، Arize Phoenix. تتجمّع في معسكرين لا يلتقيان تمامًا.

معسكر eval-CI — Braintrust، Humanloop، Patronus — يُبوِّب دمج طلبات السحب على نتائج التقييم خارج الخط. لا يلمس أبدًا الخدمة قيد التشغيل. عندما يكون النموذج في الإنتاج وتنخفض الجودة، يُنبِّه؛ شخص آخر عليه التراجع.

معسكر serving-canary — SageMaker Deployment Guardrails، KServe، Vertex AI، BentoCloud، Seldon Core — يُقسِّم الحركة ويتراجع تلقائيًا. لكن كل واحد منها يُطلَق على مقاييس البنية التحتية: كمون p99، ومعدّل الخطأ، وتنبيهات CloudWatch. لا أحد منها يتراجع تلقائيًا على تراجع في الجودة. لا يستطيعون، لأنهم لا يملكون حَكَمًا يعمل على مخرجات الإنتاج.

الفجوة بين “اجتاز التقييم عند دمج طلب السحب” و“كناري حي مُقيَّم على رحلات المستخدم التي نهتم بها فعلًا“ هي تسليم يدوي على كل فريق حاليًا أن يجسّره بنفسه. تُحدِّد التدوينة ذلك كوضع الفشل المهيمن في 2026^[6]. أغلقناه. بالتحديد:

1. البوّابة مُشرَّحة. ρ Spearman لكل مجال مقابل مُقيِّم مُعاير بشريًا، وليس نتيجة عالمية واحدة. عمى الشرائح هو ما تمتلكه كل بوّابة أخرى.
2. الكناري يراقب جودة المخرجات، وليس فقط p95. إعادة تشغيل آثار مستمرة عبر المرشّح، مُقيَّمة بنفس الحَكَم الذي شغّل البوّابة. هذه هي الفجوة المفقودة.
3. كل قرار يُصدِر إيصال إصدار. مرتبط بسلسلة تجزئة، قابل للترسيخ خارجيًا، بصيغة JSON-مع-SHA-256 التي تدعم صفحات الامتثال لدينا. للنماذج مفتوحة الأوزان — Gemma، Qwen، Llama، Mistral، GPT-OSS — يضمّن الإيصال شهادة أوزان vindex حتى يستطيع المراجعون إثبات ما هي الأوزان الحية فعلًا. للدعامات المغلقة عبر API، يغطّي الإيصال سلسلة القرار لكنه لا يدّعي مصدر الأوزان، لأن المزوّد لا يكشف عنها. في كلتا الحالتين، يحصل المراجعون على براهين لما يمكن إثباته فعلًا، وليس مجرد سجلات.

هذا كل شيء. كناري عام، وسجل إصدارات، وتراجع على مقاييس البنية التحتية — هذه سلع. لم نكتب كناري عامًا.

ما لا يحلّه هذا

ثلاث قيود صادقة:

البوّابة لا تتجاوز جودة مجموعة البيانات. مجموعة أسئلة وأجوبة مُسجَّلة لا تغطّي المجال الذي يستخدمه العميل فعلًا لن تلتقط التراجعات في ذلك المجال. رأينا هذا مرّتين. في كلتا المرّتين، كانت الخطوة الأولى للعميل هي شحن مجموعة أسئلة وأجوبة مُسجَّلة جديدة، وليس تغيير النموذج. هذه هي الخطوة الصحيحة.

التراجع يفترض أن الإصدار السابق كان جيدًا. إذا كان التراجع حيًّا منذ ثلاثة إصدارات ولم يلاحظه أحد، فإن التراجع عن إصدار واحد يشتري لك فقط نموذجًا أقل سوءًا بقليل. مسار التدقيق يساعد هنا — يمكنك التراجع إلى أي بيان سابق بـ SHA، وليس فقط N-1.

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

أصغر نسخة من هذا يمكنك تشغيلها

إذا أردت إقامة شيء كهذا دون استخدام Divinci، فإن الحد الأدنى القابل للتطبيق هو تقريبًا:

1. سجل يُخزِّن النموذج + الموجِّه + التوجيه + مجموعة البيانات كقطعة غير قابلة للتغيير واحدة، مُعنوَنة بتجزئة المحتوى
2. حَكَم مُعاير مقابل لوحة بشرية عبر ρ Spearman — وقرار بوّابة يستشير نتائج لكل شريحة، وليس فقط الإجمالي
3. مُقسِّم حركة يحتفظ عند نقاط التفتيش ويستشير مراقب جودة محدود الحداثة — حيث يُعيد المراقب تشغيل آثار إنتاج حديثة عبر المرشّح، وليس مجرد عيّنات اصطناعية
4. طبقة توجيه يمكن تبديل حالتها ذرّيًا — بما في ذلك قالب الموجِّه، وليس فقط الأوزان
5. سجل تدقيق يُصدِر إيصالًا مرتبطًا بسلسلة تجزئة، قابلًا للترسيخ خارجيًا لكل قرار إصدار — بالإضافة إلى تضمين شهادة أوزان عندما يكون النموذج مفتوح الأوزان، لأن إصدارات API المغلقة لا يمكن المصادقة عليها فعليًا على مستوى الأوزان

معظم الفرق لديها بالفعل (1) و(3). الأجزاء المؤلمة هي (2) و(4) و(5). سبب وجود Divinci هو أننا بنينا الخمسة جميعًا لأنفسنا أولًا، ثم أدركنا أن الجميع سيحتاجها أيضًا.

إذا أردت تخطّي البناء، مرجع API هنا، ونقاط نهاية الإصدار في قسم “Release Management” هي السطح الكامل لخط الأنابيب هذا. الجانب المتعلق بالامتثال — كيف تبدو إيصالات vindex وكيف تتطابق مع قانون الذكاء الاصطناعي الأوروبي، والمادة 17 من GDPR، وHIPAA، وNIST AI RMF — موجود في صفحة الامتثال. كل أمر في هذا المنشور هو نقطة نهاية حقيقية.

المراجع

1. Atlassian — Post-Incident Review: April 2022 Outage. من التقرير: "استغرق نهج الاستعادة المُسرَّع 2 نحو 12 ساعة لاستعادة موقع." الاستعادة الكاملة لـ 883 موقع عميل استغرقت 14 يومًا. الحالة الموزّعة عبر البنية التحتية والنسخ الاحتياطية والتحقق لكل موقع تدفع الرقم لكل موقع إلى ساعات بدلًا من دقائق.
2. Cloudflare — Cloudflare outage on June 21, 2022. الجدول الزمني مذكور حرفيًا في المنشور: "06:58: عُثِر على السبب الجذري وفُهِم. بدأ العمل لإلغاء التغيير الإشكالي… 07:42: اكتمل آخر الإلغاءات." أربع وأربعون دقيقة من "نعرف ما الذي نُلغيه" إلى "اكتمل الإلغاء"، جزئيًا لأن المهندسين كانوا يتداخلون مع إلغاءات بعضهم البعض.
3. DORA — Software delivery performance metrics. عتبة مؤدّي النخبة لـ "زمن التعافي من النشر الفاشل" موثّقة بأنها أقل من ساعة واحدة. يُقاس المؤدّون المنخفضون بالأسابيع إلى الأشهر في تقارير DORA التاريخية.
4. AWS SageMaker — Use canary traffic shifting والصفحة المرافقة Auto-Rollback Configuration and Monitoring. مثال TerminationWaitInSeconds هو 600 (عشر دقائق)؛ MaximumExecutionTimeoutInSeconds محدّد بـ 1800 (ثلاثون دقيقة). يُطلَق التراجع ضمن نافذة الانتظار بمجرد إطلاق تنبيه: "إذا أُطلِق أي من التنبيهات خلال فترة الانتظار، يبدأ SageMaker AI تراجعًا وتعود كل الحركة إلى الأسطول الأزرق."
5. Divinci AI — قلب توجيه ذرّي عبر بيان إصدار. اثنتا عشرة ثانية هي زمن تصريف الطلبات الجارية على خدمة بنحو 100 نسخة متماثلة؛ تبديل البيان نفسه دون ثانية. الرقم من خدمتنا، وليس من اختبار قياسي؛ البنية التي تجعله ممكنًا هي البيان المُجمَّع الموصوف أعلاه (المرحلة 1 — التسجيل).
6. Tianpan — The Semver Lie: how an LLM minor update breaks production (April 2026). يُسمّي التقرير نمط الفشل مباشرةً: "اجتاز مراجعة الكود، ونُشِر بدون بوّابات تقييم، ووصل إلى الإنتاج بدون A/B لكل مستخدم، ولم يُطلِق أي تراجع تلقائي." منشور مرافق — LLM postmortem template — fields SRE missed — يُعدِّد حقول الشريحة / الرحلة / لكل مستخدم التي تحذفها تقارير ما بعد الحوادث الحالية بشكل ممنهج.

ملاحظة حول ما ليس على هذا المخطط. زمن kubectl rollout undo في Kubernetes تحكمه إعدادات maxSurge / maxUnavailable وإحماء الجراب، وليس الأمر نفسه، ولم نتمكّن من إيجاد مصدر أوّلي يُنشر فيه رقم مُقاس بالطريقة التي تنشر بها المصادر الأربعة أعلاه — لذا تركناه خارجًا بدلًا من ملئه بتقدير.

التالي في هذه السلسلة: 10 إخفاقات إصدار CI/CD اصطدناها في نماذج لغة مخصّصة، وأي مرحلة من خط الأنابيب تلتقط كلًّا منها. ثلاث من العشرة هي تراجعات واعية بالشرائح كانت بوّابة إجمالية ستشحنها. اثنتان أخريان هي انخفاضات جودة صامتة كان كناري بمقاييس البنية التحتية سيُرقّيها. والبقية من نوع الفشل الذي يُفترض أن يلتقطه كل خط أنابيب إصدار — نُدرجها لأن من المفيد أن يُقال بصوت عالٍ أيها يلتقطه خط أنابيب مُبوَّب إجماليًا فعليًا من تلقاء نفسه.