لم يعد تشغيل نموذج لغوي كبير في بيئة الإنتاج يقتصر على تدريب النموذج واختباره ونشره ومراقبة لوحات البيانات. فالنظام الحديث قد يربط بين المطالبات وقواعد البيانات المتجهية ومصادر المعرفة، ثم ينتج نصوصاً مفتوحة النهاية يجري تقييمها وفق النبرة والسلامة والثقة، إلى جانب الدقة. من هنا يطرح دانيال براينت، في مادة منشورة على مدونة CNCF، سؤالاً عملياً: من ينبغي أن يملك خط أنابيب الذكاء الاصطناعي؟
يرى الكاتب أن الإجابة لا تكمن في منح LLMOps مملكة منفصلة، بل في إدماجها ضمن منصة هندسية جيدة التنظيم، تتيح القدرات المطلوبة عبر الواجهات نفسها التي تستخدمها فرق التطوير في بقية أعباء العمل.
ما المقصود بـLLMOps؟
تشير LLMOps إلى مجموعة الممارسات والأدوات وسير العمل اللازمة لتطوير النماذج اللغوية الكبيرة ونشرها وإدارتها طوال دورة حياتها الإنتاجية. وتشمل هذه الدورة إدارة البيانات، وهندسة المطالبات، والضبط الدقيق، والنشر وخدمة الاستدلال، والمراقبة والتقييم، إلى جانب الأمن والحوكمة.
وبحسب التحليل، لا تمثل LLMOps مجرد إعادة تسمية لـMLOps. فالنماذج اللغوية الكبيرة أكثر كلفة في الضبط الدقيق والخدمة، كما أن تقييم مخرجاتها أصعب من اختزال الأداء في رقم دقة واضح. ولا يكفي أن يكون النموذج دقيقاً؛ إذ ينبغي أيضاً أن يكون آمناً وجديراً بالثقة، وهي خصائص أكثر تعقيداً في القياس.
كما أن تشغيل النموذج لا ينتهي عند النشر الأول. فقد تنحرف النماذج عن سلوكها السابق، وترتفع التكاليف، وتتوقف المطالبات عن العمل بالطريقة المعتادة، وتحتاج التكاملات مع أنظمة إدارة علاقات العملاء أو قواعد المعرفة الداخلية إلى متابعة مستمرة.
دورة حياة تتقاطع مع هندسة المنصات
تمتد دورة LLMOps من إعداد البيانات وهندسة المطالبات، مع التعامل مع المطالبات بوصفها عناصر قابلة للإصدار بدلاً من نصوص مؤقتة، إلى الضبط الدقيق للنماذج الأساسية المفتوحة باستخدام مكتبات مثل Hugging Face Transformers. وتشمل أيضاً إصدار النماذج والمطالبات وتتبع نسبها، وتوفير الاستدلال عبر نقاط نهاية مدعومة بوحدات معالجة الرسوميات، والمراقبة اعتماداً على ملاحظات بشرية لرصد الانحراف والتكلفة.
يحتاج كل جزء من هذه الدورة إلى بنية تحتية وضوابط وصول وبيئة تشغيل، وهي مجالات تقع أصلاً ضمن نطاق هندسة المنصات. لكن الكاتب يميز بين طبيعة المجالين: هندسة المنصات تتمحور حول البنية التحتية، بينما تتمحور MLOps حول النماذج. لذلك لا يرى أن السؤال المفيد هو «من يملك خط الأنابيب؟»، بل «من يملك كل طبقة، وهل توجد جهة تنسق بينها فعلياً؟».
خطر إنشاء مكدس موازٍ
يقسم التحليل مشهد تسليم البرمجيات إلى فرق DevOps التي قد تغرق في طلبات النشر، وفرق هندسة المنصات التي تبني مسارات قياسية للخدمة الذاتية، وفرق MLOps التي أنشأت مكدسات موازية لأن أدوات DevOps لم تكن مصممة لإدارة إصدارات البيانات أو مراقبة الانحراف. ومع إضافة LLMOps، قد يظهر مكدس ثالث مستقل للمطالبات وقواعد البيانات المتجهية وخطوط RAG، بعيداً عن الجهة المسؤولة عن الحوكمة.
ويربط الكاتب هذا الاحتمال بمشكلة «عمليات الذكاء الاصطناعي الخفية». فقد تنشئ إحدى الفرق خط أنابيب RAG خاصاً بها، متصلاً بقاعدة بيانات متجهية لم تخضع للمراجعة، من دون أن يكون واضحاً للجهة المسؤولة ما الذي يعمل فعلياً. ولا يكمن الخطر التشغيلي الأكبر، وفق التحليل، في روبوت محادثة ينتج هلوسات فقط، بل في انتشار هذه القدرات خارج المنصة ثم بقائها خارج نطاق الرؤية والضبط.
ولا يقترح الكاتب إبطاء الفرق لمنع ذلك، بل جعل المنصة قادرة على تلبية الطلبات بسرعة مع تضمين الحوكمة في مسار الاستخدام نفسه. فغياب المسار الجاهز قد يدفع الفرق إلى بناء قدراتها خارج المنصة، بينما يساعد توفير مسار قياسي على إعادة هذه القدرات إلى بيئة يمكن إدارتها.
LLMOps داخل طبقات المنصة
يستند براينت إلى تصور الورقة البيضاء للمنصات الصادرة عن مجموعة TAG App Delivery التابعة لـCNCF، والتي تقسم البيئة إلى ثلاث طبقات: المنتجات في الأعلى، والمنصات في الوسط بوصفها طبقة التكامل الأقل سمكاً المعقولة، ومقدمو القدرات في الأسفل.
وفق هذا التصور، يمكن التعامل مع وظائف مثل مهام الضبط الدقيق، وقواعد البيانات المتجهية، وسجلات المطالبات، ونقاط نهاية الاستدلال باعتبارها قدرات منصة أخرى. وهي تحتاج، مثل غيرها، إلى واجهات برمجية وإصدارات وملكية واضحة. ويشير الكاتب إلى أدوات ضمن منظومة CNCF يمكن أن تدعم هذا النموذج؛ إذ يعرض Backstage المسارات القياسية في طبقة المنتج، بينما يركب Crossplane البنية التحتية في الطبقة السفلى، وتعمل أطر مثل Kratix وKusionStack وKubeVela في الوسط لإتاحة خط أنابيب LLM عبر واجهة خدمة ذاتية مشابهة لبقية الخدمات.
ضوابط عملية لحوكمة خط الأنابيب
يقترح التحليل أن تتبنى فرق المنصات مجموعة من الضوابط العملية:
- واجهات برمجية محكومة بدلاً من النصوص البرمجية غير الرسمية: ينبغي طلب مهام الضبط الدقيق ونشر المطالبات ونقاط نهاية الاستدلال عبر واجهة الخدمة الذاتية نفسها المستخدمة لبقية احتياجات المطورين.
- تطبيق السياسات عند الطلب: يجب فحص حدود التكلفة وقواعد إقامة البيانات وضوابط الوصول إلى النماذج قبل بدء المهمة، لا بعد ظهور فاتورة الخدمات السحابية.
- موافقة بشرية متناسبة مع حجم الأثر: لا تحتاج كل مطالبة إلى اعتماد مسبق، لكن النموذج الذي يتعامل مع بيانات شخصية للعملاء أو يتخذ قرارات مستقلة قد يتطلبه.
- سجل تدقيق واضح: ينبغي أن يجيب السجل عن أسئلة مثل ما الذي تغير ولماذا، سواء تعلق التغيير بالنموذج أو المطالبة أو البيانات، ومن وافق عليه أو ما الذي وافق عليه.
ويخلص الكاتب إلى أن خط أنابيب LLM هو مستهلك آلي آخر لقدرات المنصة، ويحتاج إلى الضمانات نفسها التي يحصل عليها المطور البشري أو الوكيل المستقل. أما الفرق التي تنجح في هذا النموذج فلا تختار طرفاً في الخلاف بين DevOps والمنصة وMLOps، بل تتعامل مع خط الأنابيب بأكمله كمنتج قابل للإصدار والمراقبة ومراعاة التكلفة، مع حلقات تغذية راجعة مستمرة.
وبهذا المعنى، لا يرى براينت أن LLMOps تلغي سؤال الملكية أو تعيد اختراعه، بل تضع المنصات القائمة تحت ضغط أكبر بسبب حجم النماذج وارتفاع تكلفتها وصعوبة تقييمها. والحل، في رأيه، هو بناء المسار القياسي مرة واحدة، ثم إتاحته كقدرة محكومة لكل من المطور وعالم البيانات والوكيل الذكي عبر واجهة برمجية أو واجهة مستخدم مشتركة. ويشير إلى أن هذا النقاش مستمر داخل CNCF، ولا سيما في مجموعة Platforms Working Group التابعة لـTAG App Delivery، وهي مفتوحة لمن يريد المساهمة فيه.