ما بعد الـ Vibe Checks: بنية خط معالجة CI/CD لأنظمة الـ Multi-Agent

يقوم مهندس بتعديل موجّه النظام (system prompt) لإصلاح حالة حافة (edge case) بسيطة في طريقة معالجة وكيل الذكاء الاصطناعي للفواتير. يعمل الإصلاح بشكل مثالي في بيئة الاختبار المحلية لديه. ولكن نظرًا لأن نماذج اللغة الكبيرة بطبيعتها غير حتمية (non-deterministic)، فإن هذا التغيير البسيط في الـ prompt تسبب في تراجع (regression) في قدرة الوكيل على تصنيف عقود الموردين. في معظم الشركات، لا أحد يدرك حدوث هذا التراجع إلا بعد شكوى المورد بعد ثلاثة أسابيع، أو عندما تتأثر الإيرادات مباشرة بسبب توقف سير العمل.

هذا هو واقع نشر الذكاء الاصطناعي بدون بنية تحتية متخصصة. اختبارات الوحدة القياسية (unit tests) — التي تتوقع مخرجات دقيقة ومحددة من مدخلات دقيقة — تواجه صعوبة بالغة عند تقييم المخرجات غير الحتمية لأنظمة الـ multi-agent. عندما يتمكن النظام من حل نفس المشكلة بعشر طرق مختلفة، فإن كتابة اختبار يتوقع نصاً محدداً بعينه يصبح بلا فائدة. بالنسبة للشركات التي تعمل في أسواق ذات معايير صارمة مثل الولايات المتحدة ومنطقة الخليج، حيث تترجم التأخيرات التشغيلية مباشرة إلى الإخلال باتفاقيات مستوى الخدمة (SLAs) وفقدان ثقة الشركات الكبرى، فإن الاعتماد على التحقق اليدوي يعد مخاطرة غير مقبولة.

بدلاً من ذلك، تتراجع الفرق إلى التقييمات اليدوية القائمة على الانطباع أو ما يُعرف بـ vibe checks. يقوم المطورون بتشغيل بعض الاستعلامات التجريبية، وقراءة المخرجات، وتحديد أن الوكيل يبدو ذكياً بما يكفي، ثم دفع الكود إلى التشغيل الفعلي (production). هذا الأسلوب اليدوي ينجح فقط في مرحلة إثبات المفهوم (proof of concept)، ولكنه يتحول إلى عبء تشغيلي هائل وتهديد مباشر لأرباحك بمجرد بدء التوسع (scale).

بناء خط معالجة للتكامل والنشر المستمر (CI/CD pipeline) لوكلاء الذكاء الاصطناعي هو الحد الفاصل بين تجربة علمية مكلفة ونظام عمل موثوق. إليك كيفية تصميم بنية تحتية لخط تقييم مؤتمت يقيس منطق الوكيل (agent reasoning)، ويكتشف التراجعات قبل وصولها إلى بيئة التشغيل الفعلي، ويستبدل الـ vibe checks اليدوية بيقين رياضي مدروس.

التكلفة التجارية للاختبار اليدوي للوكلاء

عبر قطاع التكنولوجيا، تتعثر معظم مشاريع الذكاء الاصطناعي للشركات في مرحلة التجارب الأولية دون الانتقال للإنتاج الفعلي. تتراكم الديون التقنية للذكاء الاصطناعي بسرعة، حيث تبني الشركات سلاسل prompts متشابكة ووكلاء غير مراقبين يعملون بشكل جيد في العروض التوضيحية الخاضعة للرقابة، لكنهم يتعطلون بشكل غير متوقع تحت ضغط العمل الحقيقي. نحن نسمي هذا "سباغيتي الذكاء الاصطناعي" (AI spaghetti).

السبب الجذري لهذا الفشل غالباً ما يكون غياب البنية التحتية للاختبار المؤتمت. عندما تعتمد الشركة على الـ vibe checks اليدوية، تتضاعف التكاليف والمخاطر التشغيلية بثلاث طرق رئيسية.

أولاً، تتباطأ سرعة التطوير بشكل حاد. إذا لم يتمكن فريق الهندسة من التحقق تلقائياً من أن التغيير آمن، فسوف يخشون تعديل الـ prompts الأساسية أو تحديث النماذج الأساسية. تحديث بسيط للـ prompt يستغرق عادةً 10 دقائق يتحول إلى دورة اختبار تراجع يدوي تستمر لأسبوعين، مما يكلف آلاف الدولارات من ساعات العمل الهندسي ويؤخر إطلاق الميزات الحيوية.

ثانياً، تتزايد تكلفة ضمان الجودة (QA) طردياً مع تعقيد الوكيل. إذا كان نظام الـ multi-agent لديك يتعامل مع دعم العملاء، واستخراج بيانات العقود، وتوجيه المخزون، فإن اختبار كل الاحتمالات يتطلب محللين بشريين مخصصين لقراءة مئات النصوص والمحادثات. بالنسبة لعملية متوسطة الحجم تتعامل مع 10,000 عملية تشغيل شهرياً، يتطلب ضمان الجودة اليدوي فريقاً مخصصاً من المحللين، بتكلفة تزيد عن 15,000 دولار شهرياً كرواتب للقيام بمهمة يجب أن يتولاها البرنامج تلقائياً.

ثالثاً، وهو الأهم، يترك الاختبار اليدوي ثغرة هائلة أمام الإخفاقات الصامتة (silent failures). قد يبدأ الوكيل في الهلوسة (hallucinating) بشأن السياسات أو يفشل في تفعيل أدوات الامتثال الإلزامية، ولن تكتشف هذا الفشل إلا من خلال استياء العملاء، أو خسارة الحسابات، أو مواجهة غرامات تدقيق تنظيمية صارمة.

يقضي نظام الـ CI/CD المؤتمت لوكلاء الذكاء الاصطناعي على هذه المخاطر. من خلال تشغيل حزمة تقييم مؤتمتة وشاملة في كل مرة يقترح فيها المطور تغييراً في الكود، فإنك تضمن تتبع مقاييس الأداء رياضياً بمرور الوقت. أنت تحمي الإيرادات المرتبطة بسير العمل، وتسمح لفريقك الهندسي بنشر التحديثات في دقائق بدلاً من أسابيع.

تقييم مسار العمليات (Trajectory Evaluation): اختبار المنطق وليس الإجابة فقط

من منظور الميزانية العمومية، فإن الوصول إلى إجابة نهائية صحيحة عبر منطق معيب يمثل التزاماً مالياً خطيراً وموقوتاً. إذا تخطى وكيلك فحص امتثال إلزامي ولكنه خمن النتيجة الصحيحة بالصدفة أثناء تشغيل الاختبار، فستظل معرضاً لغرامات تنظيمية ضخمة وإخفاقات تشغيلية في بيئة الإنتاج الفعلي. تقييم مسار العمليات (trajectory evaluation) ليس تمرينًا أكاديميًا؛ بل هو خط دفاعك الأول ضد إخفاقات الامتثال الصامتة والمسؤوليات التشغيلية.

عندما تحاول الشركات لأول مرة أتمتة اختبارات الذكاء الاصطناعي، فإنها غالباً ما تقيم الاستجابة النهائية فقط باستخدام نموذج تقييم أساسي (LLM-as-a-judge). يقومون ببناء مجموعة بيانات من الأسئلة والإجابات المتوقعة، ويستخدمون نموذجاً للتحقق مما إذا كان المخرج النهائي للوكيل يتوافق مع النص المتوقع.

هذا الأسلوب غير مكتمل بشكل خطير بالنسبة لأنظمة الـ multi-agent. تقييم الاستجابة النهائية فقط يتجاهل أخطاء المنطق الحرجة حيث يصل الوكيل إلى الاستنتاج الصحيح باستخدام منطق معيب.

لنفترض أن نظام multi-agent تم نشره في شركة خدمات لوجستية. يسأل المستخدم: "ما هي حالة الشحنة 8842؟" فيجيب الوكيل: "الشحنة 8842 متأخرة لمدة يومين". الإجابة صحيحة من الناحية الواقعية، واختبار الإجابة النهائية ينجح.

ومع ذلك، إذا نظرت إلى الخطوات الوسيطة للوكيل — أي مسار عملياته (trajectory) — فقد تجد أن الوكيل فشل في الاستعلام عن واجهة برمجة تطبيقات التتبع المباشر (live tracking API). وبدلاً من ذلك، بحث في ويكي داخلي قديم، وهلوس بوجود صلة بين وثيقتين غير مرتبطتين، ووصل بالصدفة إلى الإجابة الصحيحة. كان الوكيل على حق ولكن لأسباب خاطئة. في بيئة التشغيل الفعلي (production)، يعد الوكيل الذي يتخطى استدعاءات الأدوات الإلزامية أو يستعلم من قاعدة البيانات الخاطئة فشلاً ذريعاً، حتى لو خمن الإجابة الصحيحة أحياناً.

يتطلب تقييم استخدام الوكيل للأدوات تتبع انتقالات الحالة (state transitions) والخطوات الوسيطة. هذا ما يسمى بتقييم مسار العمليات (trajectory evaluation).

يقيس تقييم مسار العمليات الرسم البياني الكامل للإجراءات (graph of actions) التي اتخذها الوكيل. هل استدعى أداة البحث في قاعدة البيانات؟ هل قام بصياغة استعلام SQL بشكل صحيح؟ هل قام بتقييم السياق المسترجع (retrieved context) قبل إنشاء الاستجابة؟ إذا كان من المفترض أن يقوم الوكيل بتوجيه عقد عالي القيمة إلى مراجع بشري، فإن تقييم مسار العمليات يضمن تفعيل أداة التوجيه بالفعل، بدلاً من مجرد التحقق مما إذا كان الوكيل قد أخبر المستخدم بأدب أنه سيقوم بتصعيد المشكلة.

من خلال تقييم مسار العمليات، يمكنك اكتشاف الإخفاقات الصامتة حيث ينهار منطق الوكيل، مما يمنع نشر كود هش سيفشل حتماً عند تعرضه لمدخلات مستخدم مختلفة قليلاً.

بنية CI/CD لأنظمة الـ Multi-Agent

بناء هذه البنية هو استثمار رأسمالي لمرة واحدة يحد بشكل دائم من مخاطرك التشغيلية. من خلال أتمتة خطوات التحقق أدناه، فإنك تنتقل من عمليات النشر اليدوية عالية المخاطر إلى نموذج تسليم برمجيات يمكن التنبؤ به وجاهز للتدقيق يحمي اتفاقيات مستوى الخدمة (SLAs) الخاصة بعملائك. يتطلب الانتقال من "سباغيتي الذكاء الاصطناعي" إلى خط معالجة جاهز للتشغيل الفعلي دمج أدوات مراقبة وتقييم متخصصة مباشرة في سير عمل التطوير القياسي لديك. تم تصميم الأدوات الحديثة مثل Langfuse و Weave خصيصاً لهذا الغرض، حيث تلتقط مخططات التنفيذ المعقدة ومتعددة الخطوات لأطر العمل مثل LangGraph.

إليك بنية خط معالجة CI/CD للذكاء الاصطناعي في بيئة التشغيل الفعلي.

الخطوة 1: مجموعة البيانات الذهبية (The Golden Dataset) لا يمكنك أتمتة الاختبار بدون نقطة مرجعية (baseline). أساس خط المعالجة هو "مجموعة البيانات الذهبية" — وهي مجموعة منسقة من 100 إلى 500 مدخل واقعي ومحدد للغاية، مقترنة بالأدوات الدقيقة التي يجب على الوكيل استدعاؤها، والسياق الذي يجب عليه استرجاعه، ومعايير الإجابة النهائية الناجحة. يجب أن تتضمن مجموعة البيانات هذه حالات الحافة المعروفة، والمدخلات الضارة، والطلبات المعقدة متعددة الخطوات.

الخطوة 2: التشغيل المؤتمت عبر GitHub Actions عندما يقوم المطور بتعديل موجّه (prompt)، أو إضافة أداة جديدة، أو تحديث منطق التنسيق (orchestration logic)، فإنه يفتح طلب سحب (Pull Request). هذا الإجراء يشغل تلقائياً سير عمل في GitHub Actions (أو مشغل CI المفضل لديك). يقوم خادم CI بتشغيل نسخة معزولة (containerized) من نظام الـ multi-agent.

الخطوة 3: محاكاة الحالة والإجراءات غير القابلة للتراجع (Mocking) غالباً ما يتفاعل الوكلاء مع العالم الحقيقي — مثل إرسال رسائل البريد الإلكتروني، أو تحديث سجلات Salesforce، أو إصدار المبالغ المستردة. في خط معالجة CI/CD، يتم اعتراض هذه الأدوات ومحاكاتها (mocked). ينفذ الوكيل منطقه، ويقرر إرسال بريد إلكتروني ويقوم بصياغة البيانات، ولكن الأداة المحاكية تعيد ببساطة رمز نجاح إلى الوكيل دون إرسال البريد الإلكتروني فعلياً. يتيح لك هذا اختبار اتخاذ القرار لدى الوكيل بأمان.

الخطوة 4: التنفيذ والتقاط بيانات القياس عن بُعد (Telemetry) يقوم خط معالجة CI بتشغيل الوكيل مقابل كل مدخل في مجموعة البيانات الذهبية. أثناء تشغيل الوكيل، تقوم منصة المراقبة (مثل Langfuse) بالتقاط كل رمز (token) تم إنشاؤه، وكل أداة تم استدعاؤها، وزمن استجابة واجهة برمجة التطبيقات (API latency)، والتسلسل الدقيق لانتقالات الحالة.

الخطوة 5: التقييم باستخدام نموذج كحكم (LLM-as-a-Judge) نظراً لأن المخرجات غير حتمية، لا يمكنك استخدام مطابقة النصوص البسيطة لتقييم النتائج. بدلاً من ذلك، يستخدم خط المعالجة أسلوب "LLM-as-a-Judge". يتم تزويد نموذج رائد منفصل وعالي القدرة (الحكم) بمسار عمليات الوكيل ومعايير التقييم (rubric). يقيم نموذج الحكم عملية التشغيل بناءً على معايير محددة: هل استخدم الوكيل الأداة الصحيحة؟ هل كانت الإجابة النهائية مطابقة للسياق المسترجع؟ هل تجنب الوكيل ذكر المنافسين؟

الخطوة 6: بوابة النشر (The Deployment Gate) تخرج نماذج الحكم درجات منظمة (مثل تقييم من 0 إلى 1 للدقة الواقعية). يقوم خط المعالجة بتجميع هذه الدرجات. إذا انخفضت الدقة الإجمالية عن الحد المحدد — على سبيل المثال، 95% — أو إذا فشل الوكيل في أي فحوصات امتثال حرجة، يفشل خط معالجة CI. يتم منع المطور من دمج الكود (merging)، ويتلقى تقريراً مفصلاً يوضح بالضبط أي حالات الاختبار التي تراجعت.

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

اقتصاديات الاختبار المؤتمت للوكلاء

من الاعتراضات الشائعة لدى قادة الأعمال هي تكلفة تشغيل تقييمات LLM-as-a-Judge عند كل تغيير في الكود. قد يبدو استخدام نموذج رائد لتقييم مئات الحالات مكلفاً حتى تحسب تكلفة الحوسبة الفعلية مقابل تكلفة العمالة البشرية.

دعنا ننظر إلى الأرقام لعملية نشر نموذجية لشركة متوسطة الحجم. افترض أن مجموعة البيانات الذهبية الخاصة بك تحتوي على 200 حالة اختبار معقدة. يتطلب تقييم حالة اختبار واحدة إرسال مسار عمليات الوكيل، والسياق، ومعايير التقييم إلى نموذج الحكم — بمتوسط 3,000 رمز مدخل (input tokens) تقريباً لكل اختبار.

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

200 cases × 5 runs × 3,000 tokens = 3,000,000 input tokens per day.

باستخدام نموذج حكم رائد حديث بسعر يتراوح بين 3.00 و 5.00 دولارات لكل مليون رمز مدخل، فإن تكلفة الحوسبة المباشرة تتراوح بين 9.00 و 15.00 دولاراً يومياً. وبافتراض 22 يوم عمل تقريباً، فإن ذلك يعادل حوالي 200 إلى 350 دولاراً شهرياً.

من خلال تطبيق هذا الإطار المؤتمت، يمكن لشركة متوسطة الحجم توقع ثلاثة أنواع من التحسينات (أرقام توضيحية لتوضيح الحجم — يمكنك تطبيقها على حجم عملياتك الخاص):

1. ▸خفض تكاليف ضمان الجودة بنسبة 95%: استبدال المراجعات اليدوية للنصوص بتقييمات LLM-as-a-judge المؤتمتة يخفض تكاليف الاختبار من 6,000 دولار شهرياً إلى أقل من 350 دولاراً شهرياً.
2. ▸تسريع دورات النشر بنسبة 98%: تغييرات الكود التي كانت تتطلب سابقاً أسبوعين من اختبار التراجع اليدوي يتم دمجها ونشرها بأمان في أقل من 15 دقيقة.
3. ▸ترقية النماذج دون أي مخاطر: استبدال النموذج الأساسي بنموذج أرخص أو أسرع (مثل نموذج أصغر مفتوح الوزن، أو نموذج أخف من نفس العائلة) يمكن التحقق منه فوراً مقابل مجموعة البيانات الذهبية، مما يتيح لك الاستفادة من توفير تكاليف الاستنتاج (inference) دون القلق من حدوث تراجع صامت.

قارن هذا بالبدائل المتاحة:

دفع 350 دولاراً شهرياً كأرصدة لواجهات برمجة التطبيقات (API credits) لأتمتة ضمان الجودة بالكامل، والقضاء على تراجعات الإنتاج، وتحرير فريقك الهندسي هو أحد أفضل الاستثمارات ذات العائد المرتفع التي يمكنك القيام بها في بنيتك التحتية للذكاء الاصطناعي. البديل هو دفع 80 دولاراً في الساعة للمطور لقراءة النصوص يدوياً، أو الأسوأ من ذلك، خسارة آلاف الدولارات عندما يتسبب prompt معطل في قيام الوكيل بتقديم أسعار خاطئة للعميل.

الانتقال من مرحلة التجارب إلى التشغيل الفعلي

تقوم Verel Systems بنقل الذكاء الاصطناعي من مرحلة العشوائية (spaghetti) إلى التشغيل الفعلي. نحن نرى نفس النمط يتكرر باستمرار: تبني الشركة عرضاً توضيحياً رائعاً للوكيل، ويتحمس أصحاب المصلحة الداخليون، ثم يتعثر المشروع لمدة ستة أشهر لأن النظام هش للغاية ولا يمكنه الصمود عند تفاعله مع مستخدمين حقيقيين. يستمر الفريق في تعديل الـ prompts، وإصلاح خطأ واحد ليظهر خطأين آخرين، ليجدوا أنفسهم محاصرين في دورة لا تنتهي من الاختبار اليدوي. يمثل هذا تكلفة غارقة هائلة وفرصاً ضائعة في السوق.

لا يمكنك بناء برمجيات موثوقة فوق نماذج غير حتمية (non-deterministic) دون وجود بنية تحتية حتمية للاختبار.

إذا كانت مبادرات الذكاء الاصطناعي لديك متوقفة حالياً، فإن الحل ليس الانتقال إلى عائلة نماذج أحدث قليلاً أو إعادة كتابة الـ prompts مرة أخرى. الحل هو التراجع خطوة إلى الوراء وبناء خط المعالجة الهندسي. من خلال تطبيق تقييم مسار العمليات (trajectory evaluation)، ومحاكاة استدعاءات الأدوات (mocking)، وربط عمليات النشر بتقييم مؤتمت عبر LLM-as-a-Judge، فإنك تحول ذكاءك الاصطناعي من تجربة هشة إلى أصل تجاري قابل للقياس والإدارة.

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

الأسئلة الشائعة

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

ما هو الحجم المناسب لمجموعة البيانات الذهبية لضمان الأمان؟ ابدأ بـ 50 نموذجاً تمثيلياً للغاية لتأسيس آليات عمل خط المعالجة. بمجرد تشغيل تدفق الـ CI/CD، قم بتوسيع مجموعة البيانات لتتراوح بين 200 و 500 حالة. الجودة والتنوع أهم بكثير من الحجم الإجمالي. يجب عليك تضمين حالات الحافة عمداً، والمدخلات العدائية، وأمثلة لمستخدمين يغيرون آرائهم في منتصف المحادثة لضمان صمود إدارة حالة الوكيل (state management).

ألا يمكن لـ LLM-as-a-Judge أن يضيف هلوسات خاصة به في نتائج الاختبار؟ يمكن أن يحدث ذلك، ولهذا السبب لا يجب أبداً طرح أسئلة مفتوحة على نموذج الحكم مثل "هل قام الوكيل بعمل جيد؟". يجب عليك إجبار نموذج الحكم على إخراج بيانات منظمة (JSON) بناءً على معايير ثنائية صارمة. على سبيل المثال: "هل استدعى الوكيل أداة search_database قبل الإجابة؟ أخرج True أو False". من خلال تقييد الحكم بفحوصات واقعية محددة مقابل مسار العمليات المقدم، فإنك تقلل بشكل كبير من هلوسات التقييم.

كيف نختبر الوكلاء الذين يتخذون إجراءات غير قابلة للتراجع، مثل معالجة المدفوعات؟ يجب عليك فصل منطق وكيلك عن بيئة تنفيذه. في خط معالجة CI/CD، يتم تزويد الوكيل بنسخ محاكاة (mocked) من أدوات التشغيل الفعلي. عندما يقرر الوكيل تنفيذ عملية دفع، فإنه يستدعي الأداة المحاكاة. يسجل خط المعالجة أن الوكيل اتخذ القرار الصحيح وقام بصياغة بيانات واجهة برمجة التطبيقات (API payload) بشكل مثالي، ولكن لا يتم معالجة أي دفعة مالية حقيقية. يتيح لك هذا اختبار سلسلة منطق الوكيل بالكامل بأمان.

ما هو العائد على الاستثمار (ROI) وفترة الاسترداد النموذجية لبناء خط تقييم مؤتمت للذكاء الاصطناعي؟ بالنسبة لمعظم عمليات نشر الشركات، تكون فترة الاسترداد أقل من 60 يوماً. من خلال استبدال ضمان الجودة اليدوي بتقييم مسار العمليات المؤتمت، فإنك تلغي فوراً ما بين 4,000 إلى 8,000 دولار من التكاليف البشرية الشهرية للاختبار. والأهم من ذلك، أنه يقلل من مخاطر النشر إلى ما يقارب الصفر، مما يحمي عملك من الإخفاقات الصامتة التي قد تؤدي إلى خسارة العملاء، أو فقدان العقود، أو غرامات الامتثال التي تتجاوز 50,000 دولار.