DevOps وMLOps وLLMOps: كيف وصل الذكاء الاصطناعي التوليدي إلى الإنتاج

يعرض الرسم الشائع ثلاثة خطوط أنابيب كأنها أجيال متعاقبة. يفيد ذلك في التوجيه، لكنه يخفي الفكرة الحاسمة: ليست DevOps وMLOps وLLMOps منتجات متنافسة ولا مراحل تلغي إحداها الأخرى. إنها استجابات تشغيلية لقطع تقنية صار تعريفها واختبارها أصعب مع الوقت. أضافت البرمجيات أتمتة التسليم؛ وأضاف تعلم الآلة البيانات والسلوك الإحصائي؛ ثم أضافت النماذج التأسيسية السياق اللغوي والمزوّدين الخارجيين والأدوات والمخاطر الدلالية.

هذه هي القصة الموثقة لذلك التطور، والأهم أنها دليل إلى ما ينبغي لفريق LLMOps تشغيله فعلاً. لا يوجد تاريخ ميلاد متفق عليه عالمياً لـMLOps أو LLMOps، ولذلك يعتمد التسلسل على محطات يمكن التحقق منها بدلاً من نسبة المصطلح إلى «مخترع» واحد.

ثلاثة أسماء وثلاثة أنواع من القطع التشغيلية

ليست هذه حدوداً تنظيمية جامدة. ما زال منتج LLM يحتاج إلى CI/CD والأسرار والشبكات والتراجع وSLO. وإذا امتلك أوزان النموذج احتاج أيضاً إلى نسب البيانات وسجل النماذج. توسّع LLMOps نطاق DevOps وMLOps ولا تمحوهما.

2009: DevOps ومشكلة التسليم بين الفرق

في مؤتمر Velocity عام 2009 قدّم John Allspaw وPaul Hammond محاضرة 10+ Deploys per Day: Dev and Ops Cooperation at Flickr.^[flickr] حمل العنوان الفكرة كاملة: لا يأتي النشر المتكرر من بطل يلقي حزمة فوق جدار بين فريقين، بل من التعاون والأتمتة. وفي العام نفسه أُقيم أول DevOpsDays في مدينة غنت.^[devopsdays]

حكاية موثقة: بدا «أكثر من عشرة عمليات نشر يومياً» استفزازياً حين كانت مؤسسات كثيرة تنشر كل ثلاثة أشهر. لم تكن القاعدة هي عبادة الرقم عشرة؛ بل إن التغييرات الصغيرة قصّرت زمن التغذية الراجعة ووزعت المسؤولية. حوّلت DORA هذه القدرة لاحقاً إلى مقاييس، وأظهرت أن السرعة والاستقرار ليسا بالضرورة متعارضين.^[dora]

2015–2017: عندما بدأت القطعة التقنية تتعلم

في تعلم الآلة لم يعد السلوك ناتجاً من الشيفرة وحدها؛ صار يعتمد على البيانات والتحويلات والمعاملات الفائقة والعالم الذي تُستخدم فيه التنبؤات. رسّخت ورقة Google عن الدين التقني الخفي فكرتين: شيفرة النموذج جزء صغير من النظام الحقيقي، وفي النظام المتشابك قد يؤثر تغيير واحد في كل شيء.^[debt]

من هنا جاءت الحاجة التي تسمى اليوم MLOps: إعادة إنتاج مجموعات البيانات والسمات، والتحقق من المخططات، وتسجيل التجارب والنماذج، ومنع اختلاف التدريب عن الخدمة، ومراقبة الانجراف وتقرير موعد إعادة التدريب. اقترحت ورقة ML Test Score عام 2017 ثمانية وعشرين اختباراً وحاجة للمراقبة من أجل الجاهزية الإنتاجية.^[mltest]

قصة لها أرقام: تشرح ورقة TFX كيف استبدلت Google نصوص الربط الهشة بمكوّنات موحدة. في تطبيق على Google Play كانت النماذج تتحدث مع وصول بيانات جديدة؛ وأبلغ المؤلفون عن دورات تجريب أسرع، وانخفاض زمن الوصول إلى الإنتاج من أشهر إلى أسابيع، وزيادة قدرها 2% في تثبيت التطبيقات ارتبطت بتحسين تحليل البيانات والنماذج.^[tfx] هذه نتيجة حالة بعينها وليست وعداً عاماً.

أضافت MLOps إلى CI/CD التسليم المستمر لخط تعلم الآلة والتدريب المستمر. يميّز دليل Google Cloud بين العمل اليدوي وأتمتة خط ML والأتمتة الكاملة لـCI/CD.^[mlops]

2020–2022: من نموذج منفرد إلى نظام تأسيسي

مهّدت ثلاثة تغييرات لـLLMOps. جمع RAG عام 2020 بين الذاكرة البارامترية وفهرس خارجي، ما أتاح معرفة قابلة للتحديث ومصدراً يمكن تتبعه.^[rag] ثم رسّخ تقرير Stanford عام 2021 مصطلح foundation model: نموذج مدرّب على نطاق واسع وقابل للتكييف مع مهام كثيرة، يمنح قوة كبيرة لكنه يجعل منتجات عديدة ترث العيوب نفسها.^[foundation]

في 2022 أظهر InstructGPT أن التغذية الراجعة البشرية قد تغيّر المنفعة جذرياً: ضمن توزيع المطالبات الذي اختبره المؤلفون فضّل المقيمون نموذج 1.3 مليار معامل على GPT‑3 ذي 175 ملياراً، رغم استمرار الأخطاء البسيطة.^[instruct] وفي العام نفسه دعت HELM إلى تقييم شفاف متعدد الأبعاد بدلاً من رقم واحد في اختبار معياري.^[helm]

انتشر اسم LLMOps في هذا السياق. لا يعني «MLOps مع مطالبة»، ولا يشترط تدريب نموذج تأسيسي. تطبيقات كثيرة لا تدرّب الأوزان إطلاقاً؛ بل تشغّل واجهات API والمطالبات والاسترجاع والأدوات والقواعد. وحدة التغيير هي نظام LLM المركّب.

ما الذي تشغّله LLMOps فعلاً؟

1. حزمة ذات إصدار، لا مطالبة منفردة

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

يجب أن تكون الحزمة المرقاة غير قابلة للتغيير: app@sha + prompt@sha + index@snapshot + eval@version + policy@version + model@id. إن تعذر بناؤها من جديد تعذر تفسير الحادث أو تنفيذ تراجع موثوق.

2. التقييم قبل التحسين

يختبر البرنامج عادة قيمة متوقعة؛ أما اللغة فتقبل صيغاً صحيحة متعددة وإجابات بليغة لكنها خاطئة. لذلك تبدأ LLMOps بمجموعة تقييم من مهام حقيقية وحالات حدية وإساءات متوقعة. يحتاج كل مثال إلى معيار حكم، لا إلى نص «ذهبي» فقط.

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

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

3. RAG كخط بيانات يعمل على الإنترنت

ليس RAG مجرد «توصيل قاعدة متجهات». إنه سلسلة: ترخيص الوثيقة ← الاستخراج ← التنظيف ← التقسيم ← embeddings ← الفهرسة ← الاسترجاع ← إعادة الترتيب ← بناء السياق ← التوليد ← الاستشهادات. يمكن أن يتراجع كل رابط.

يجب إصدار المتن والفهرس وقياس حداثتهما، ومنع استرجاع وثائق لا يحق للمستخدم رؤيتها، وحفظ معرّفات المقاطع في التتبعات، والاختبار بأسئلة معروفة المصدر. قد يحسن الاسترجاع استناد الإجابة إلى الأدلة، لكنه لا يحولها تلقائياً إلى حقيقة ولا يزيل حقن المطالبات؛ وتذكر OWASP ذلك صراحة.^[owasp]

4. قابلية المراقبة الدلالية وFinOps

لا يعني HTTP 200 أن الإجابة مفيدة. يجب أن يربط التتبع الإدخال والسياسة والاسترجاع وإعادة الترتيب واستدعاءات النموذج والأدوات والمحاولات والخرج النهائي. تعرّف OpenTelemetry اتفاقيات للنماذج والرموز والرسائل واستدعاءات الأدوات؛ وينبغي أن يظل تسجيل المحتوى اختيارياً لأنه قد يحمل بيانات حساسة.^[otel]

تجمع اللوحات المفيدة الجودة والتشغيل: نجاح المهمة واستناد الإجابة حسب الإصدار، وزمن p50/p95/p99، ورموز الإدخال والإخراج، وتكلفة المهمة المكتملة لا الاستدعاء، ونسبة إصابة الذاكرة المخبأة، وعمق الوكيل، وفشل الأدوات، والتصعيد إلى إنسان. قد يكون الرمز رخيصاً، لكن الوكيل يصبح مكلفاً إذا دار في حلقة.

ينبغي تعريف SLO من منظور المستخدم: الإتاحة والزمن والصحة.^[sre] مثال: «تجيب 95% من أسئلة السياسات المصرح بها خلال ست ثوانٍ، باستشهاد صالح ومن دون تسريب بين المستأجرين».

5. الأمن والحوكمة وحدود الوكالة

يستقبل النموذج البيانات والتعليمات في قناة واحدة؛ لذلك يكون حقن المطالبات مشكلة معمارية لا مرشحاً يضاف في النهاية. تحتفظ OWASP بقائمة مخاطر خاصة بـLLM، وينظم ملف NIST للذكاء التوليدي إجراءات الحوكمة والقياس وإدارة المخاطر.^{[nist][owasp]}

• عامل النصوص المسترجعة وصفحات الويب ونتائج الأدوات كمدخلات غير موثوقة.
• طبّق أقل صلاحية لكل أداة، وافصل القراءة عن الاقتراح عن التنفيذ.
• تحقق من الخرج قبل SQL أو shell أو البريد أو الدفع أو تغيير البنية التحتية.
• اطلب موافقة بشرية للأفعال غير القابلة للعكس أو عالية الأثر.
• حدد الاحتفاظ وحجب PII ومكان البيانات ومن يقرأ المطالبات والتتبعات.
• وفّر مفتاح إيقاف وحدود الخطوات والميزانية والمهل والتراجع.

خط LLMOps إنتاجي في تسع خطوات

1. عرّف المهمة والمخاطر: القرار والصلاحيات والمسؤول وما لا يجوز حدوثه.
2. أنشئ مجموعة التقييم: الحالات العادية والحدية واللغات والفئات ذات الصلة والهجمات.
3. اختر وفق القيود: جودة المهمة والزمن والخصوصية والمنطقة والسياق والأدوات والتكلفة، لا لوحة عامة.
4. ابنِ السياق: استخدم RAG للمعرفة أو التتبع، مع ACL والمصدر والحداثة.
5. أضف القياس قبل الإطلاق: الإصدارات ومعرّفات الربط وspans والرموز والتكاليف والتقييمات.
6. نفّذ بوابات offline: التراجع والأمان والحمل والميزانية.
7. انشر بوضع shadow أو canary: قارن حركة حقيقية من دون منح المرشح وكالة كاملة.
8. خذ عينات من الإنتاج: إشارات آلية وتغذية بسياق ومراجعة بشرية تحمي الخصوصية.
9. رقِّ الحزمة كلها أو تراجع عنها: النموذج والمطالبة والفهرس والأدوات والسياسات معاً.

ثلاث حكايات تحولت إلى قواعد تشغيلية

Flickr، 2009: يتذكر الناس «عشرة عمليات نشر يومياً»، لكن «تعاون Dev وOps» كان النصف الأبقى من العنوان. كان التكرار نتيجة ظاهرة لتغذية راجعة أقصر ومسؤولية مشتركة.^[flickr]

TFX، 2017: لم تُحل مشكلة الإنتاج بخوارزمية أفضل، بل باستبدال الربط المؤقت بمنصة قابلة للتكرار. هذا هو الانتقال من «لدينا نموذج» إلى «نستطيع تشغيل النماذج».^[tfx]

Tay، 2016: سبقت Tay النماذج اللغوية الحديثة، ولذلك لم تكن حادثة LLM. لكنها كانت إنذاراً تشغيلياً. كتبت Microsoft أن هجوماً منسقاً استغل خلال أول 24 ساعة ثغرة لم تكن متوقعة، ثم أُوقف الروبوت.^[tay] اختبارات المختبر وred teaming والمراقبة الحية وطريق السحب أجزاء من المنتج.

أخطاء LLMOps الشائعة

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

التطور الحقيقي: توسيع نطاق المسؤولية

جعلت DevOps تغيير البرمجيات قابلاً للتشغيل. أضافت MLOps تغير البيانات والسلوك التنبؤي. وتضيف LLMOps السياق والنية والفعل. لا يظهر النضج في زيادة الصناديق، بل في الإجابة عن خمسة أسئلة لكل خرج: أي إصدار أنتجه، وبأي سياق، وكيف قُيّم، وما الذي سُمح له بفعله، وكم كلّف.

إذا وُجدت هذه الإجابات أمكن تحسين النظام من دون إيمان أعمى. وإن غابت بقي «خط LLMOps» عرضاً تجريبياً له مسار شبكة إلى الإنتاج.

المصادر وقراءات إضافية

الأبحاث الأصلية والوثائق الرسمية وروايات الحوادث المنشورة من الجهات المعنية التي استند إليها المقال.

1. John Allspaw & Paul Hammond — 10+ Deploys per Day: Dev and Ops Cooperation at Flickr
2. DevOpsDays — Ghent 2009, official event archive
3. DORA / Google Cloud — 2019 Accelerate State of DevOps Report
4. Sculley et al. — Hidden Technical Debt in Machine Learning Systems
5. Breck et al. — The ML Test Score
6. Baylor et al. — TFX: A TensorFlow-Based Production-Scale ML Platform
7. Google Cloud Architecture Center — MLOps: Continuous delivery and automation pipelines
8. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
9. Bommasani et al. — On the Opportunities and Risks of Foundation Models
10. Ouyang et al. — Training language models to follow instructions with human feedback
11. Liang et al. — Holistic Evaluation of Language Models (HELM)
12. Microsoft — Learning from Tay’s introduction
13. NIST AI 600-1 — Generative AI Profile
14. OWASP GenAI Security Project — Top 10 for LLM Applications
15. OpenTelemetry — Inside the LLM Call: GenAI Observability
16. Google SRE Book — Service Level Objectives