بناء وكلاء ذكاء اصطناعي ذاتيي الإصلاح: آليات Fallbacks في LangGraph وتوجيه LiteLLM

من المحتمل جداً أن يواجه مزود الذكاء الاصطناعي الرئيسي لديك انقطاعاً في الخدمة أو تدهوراً كبيراً في الأداء خلال هذا الربع. إذا كان نظام الـ multi-agent الخاص بك يعتمد على اتصال API واحد ومكتوب بشكل ثابت (hardcoded)، فإن هذا الانقطاع يترجم مباشرة إلى توقف تفاعلات العملاء، وتعطل تدفقات العمل الداخلية، وهدر موارد الحوسبة (compute). بالنسبة لمؤسسي شركات الـ B2B SaaS ومديري العمليات في الشركات الكبرى في الأسواق التنافسية مثل الولايات المتحدة ومنطقة الخليج، فإن حتى 15 دقيقة من التوقف يمكن أن تؤدي إلى غرامات بسبب الإخلال باتفاقيات مستوى الخدمة (SLA)، وتضر بالثقة في العلامة التجارية، وتدفع العملاء للمغادرة. تحل بنيات الذكاء الاصطناعي ذاتية الإصلاح (Self-healing AI architectures) هذا الخطر من خلال الكشف التلقائي عن الأخطاء، وتوجيه الطلبات بعيداً عن واجهات الـ API المتعطلة، وإعادة محاولة خطوات المنطق الفاشلة دون أي تدخل بشري.

على مستوى الصناعة، تتعطل معظم مشاريع الذكاء الاصطناعي للمؤسسات في مرحلة التجربة الأولى (pilot purgatory) لأنها تُبنى حصرياً لـ 'المسار المثالي' (happy path). يعمل العرض التوضيحي (demo) بشكل مثالي عندما يختبره مستخدم واحد ببطء. ولكن عندما تنشر هذا الوكيل نفسه في بيئة الإنتاج (production)، فإنه يواجه حدود معدل الطلبات (rate limits)، واستجابات JSON غير صالحة (malformed)، وأخطاء الشبكة المؤقتة. ينهار النظام، وتتراكم على الشركات الديون التقنية للذكاء الاصطناعي—وهي عبارة عن فوضى من سلاسل الموجهات (prompts) الهشة والمشاريع التجريبية المهجورة. تأخذ Verel Systems الذكاء الاصطناعي من مرحلة الأكواد العشوائية إلى بيئة الإنتاج الحقيقية. نحن نبني أنظمة تتوقع الفشل وتتعامل معه ديناميكياً، مما يضمن استمرارية الأعمال ويحمي أرباحك بغض النظر عن استقرار المزود الأساسي.

التكلفة الخفية لـ "المسار المثالي"

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

إن أحد أهم أنماط الفشل التي غالباً ما يتم تجاهلها في الذكاء الاصطناعي للمؤسسات ليس الهلوسة (hallucination)؛ بل هو فشل البنية التحتية الناتج عن حدود معدل الطلبات (rate limits). لنأخذ على سبيل المثال وكيلاً لخدمة العملاء يتعامل مع محادثات متزامنة. إذا تفاعل 50 مستخدماً مع النظام في وقت واحد، وتطلب كل تفاعل 4 استدعاءات للأدوات (tool calls) في الدقيقة بمتوسط 1,500 توكن سياق (context tokens)، فسيستهلك النظام 300,000 توكن في الدقيقة (TPM). إذا كان حد فئة الـ API الخاصة بمؤسستك يقف عند 250,000 TPM، فإن حوالي 17% من هذه الطلبات ستواجه خطأ 429 Too Many Requests.

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

للبقاء قيد العمل تحت أعباء الإنتاج، يجب على نظام الذكاء الاصطناعي فصل منطق العمل (business logic) عن مزود النموذج المحدد. يتطلب ذلك بنية تتعامل مع واجهات برمجة تطبيقات النماذج (model APIs) كموارد حوسبة قابلة للتبديل بدلاً من كونها تبعيات لا يمكن الاستغناء عنها. يتم تحقيق ذلك من خلال نهج ثنائي الطبقات: بوابة توجيه (routing gateway) للتعامل مع الأخطاء على مستوى الشبكة، وطبقة إدارة وتنسيق مستندة إلى الحالة (stateful orchestration layer) للتعامل مع الأخطاء على مستوى المنطق. هذا الفصل الهيكلي يحمي عملياتك من الارتفاع المفاجئ في أسعار الـ API وانقطاعات الخدمة الإقليمية المفاجئة.

طبقة البوابة (Gateway Layer): موازنة الأحمال عبر المزودين

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

يوفر LiteLLM بوابة موحدة لأكثر من 100 مزود للنماذج مع دعم مدمج لموازنة الأحمال وآليات الـ fallback. من خلال إدخال هذه البوابة بين تطبيقك وواجهات الـ API الخارجية، فإنك تعزل تطبيقك عن فترات تعطل المزودين.

عندما تقوم بتكوين سلسلة fallback في LiteLLM، فإنك تحدد نموذجاً رئيسياً وقائمة بالنماذج الثانوية. إذا أرجع المزود الرئيسي خطأ 500 Internal Server Error أو 429 Rate Limit Exceeded، تقوم البوابة باعتراض الخطأ. وفي غضون أجزاء من الثانية، تقوم بتحويل الطلب إلى التنسيق الذي يتطلبه المزود الثانوي وإعادة إرساله. يواجه المستخدم النهائي زيادة طفيفة في زمن الاستجابة (latency)—ربما 400 مللي ثانية إضافية—ولكن التفاعل يكتمل بنجاح.

تتيح إمكانية التوجيه هذه أيضاً موازنة الأحمال النشطة (active load balancing). إذا كان نظامك يتطلب معدل إنتاجية (throughput) عالٍ، يمكنك توزيع الطلبات عبر عمليات نشر متعددة ومتطابقة لنماذج مفتوحة الأوزان (مثل عائلة Llama 3.3) المستضافة عبر مناطق مختلفة أو مزودي سحابيين مختلفين. تراقب البوابة صحة وزمن استجابة كل نقطة نهاية (endpoint)، وتوجه حركة المرور بعيداً عن العقد المزدحمة.

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

model_list:
  - model_name: production-agent
    litellm_params:
      model: primary-provider/frontier-model
      api_key: os.environ/PRIMARY_KEY
  - model_name: production-agent
    litellm_params:
      model: secondary-provider/frontier-model-equivalent
      api_key: os.environ/SECONDARY_KEY
router_settings:
  routing_strategy: usage-based-routing
  fallbacks: [{"production-agent": ["secondary-provider/frontier-model-equivalent"]}]

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

طبقة المنطق (Logic Layer): الاسترداد المستند إلى الحالة في أنظمة Multi-Agent

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

يتطلب التعامل مع أخطاء المنطق إطار عمل للتنسيق (orchestration framework) يحافظ على الحالة ويمكنه تنفيذ تدفقات عمل دائرية (cyclical workflows). تتحرك سلاسل الموجهات (prompt chains) الخطية (مثل تلك المبنية في منصات الأتمتة الأساسية) في اتجاه واحد عادةً. إذا فشلت الخطوة الثالثة، تنقطع السلسلة بأكملها.

يتيح LangGraph بناء رسوم بيانية دائرية مستندة إلى الحالة (stateful, cyclic graphs) حيث يمكن للعقد إعادة المحاولة بسلاسة أو التوجيه إلى نماذج fallback عند حدوث فشل. ولأن LangGraph يمثل تدفقات العمل كآلات حالة (state machines)، فإن الوكيل يحتفظ بذاكرة أفعاله السابقة، والأخطاء التي واجهها، والحالة الحالية للبيانات.

إذا حاول وكيل استخدام أداة استعلام قاعدة البيانات وتلقى خطأ في صيغة SQL، فإن الرسم البياني الدائري المستند إلى الحالة يسمح للنظام بتوجيه الخطأ مرة أخرى إلى النموذج اللغوي. يقرأ النموذج رسالة الخطأ، ويتعرف على خطئه، ويعيد كتابة استعلام SQL، ويحاول تشغيل الأداة مرة أخرى. حلقة التصحيح الذاتي هذه هي ما يفرق بين السكربت الهش والوكيل المستقل (autonomous agent).

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

نحن نضع ضوابط حماية (guardrails) محددة داخل هذه الرسوم البيانية لمنع الحلقات اللانهائية. أحد الأنماط الشائعة في بيئة الإنتاج هو فرض عداد max_retries داخل كائن الحالة (state object). إذا فشل الوكيل في تنسيق كائن JSON بشكل صحيح بعد ثلاث محاولات، يوجه الرسم البياني الطلب إلى عقدة fallback محددة مسبقاً (deterministic). قد تقوم هذه العقدة بتنبيه مهندس بشري، أو إرسال استجابة بديلة قياسية للمستخدم، أو تمرير النص الخام إلى نموذج أرخص وأسرع مخصص فقط لتنسيق النصوص إلى JSON.

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

قياس تأثير التوجيه الديناميكي

الجدوى الاقتصادية للاستثمار في البنية التحتية ذاتية الإصلاح تكمن في تقليل المخاطر والتحكم في التكاليف. الأنظمة ذات الأكواد الثابتة (hardcoded) إما تنهار تحت الضغط، مما يكلفك خسارة في الإيرادات، أو تتطلب تخصيص مفرط ومكلف لفئات الـ API للمؤسسات، مما يلتهم هوامش أرباحك.

يؤدي تنفيذ التوجيه الدلالي (semantic routing) وآليات الـ fallback الديناميكية إلى تقليل معدلات فشل الوكلاء بشكل هيكلي من خلال عزل نطاقات الفشل المختلفة. يضيف التوجيه الدلالي طبقة ذكية قبل استدعاء النموذج: حيث يقيم مدى تعقيد موجه المستخدم ويوجه المهام البسيطة (مثل استخراج تاريخ) إلى نماذج سريعة ومنخفضة التكلفة، بينما يحتفظ بنماذج الاستدلال القوية للمهام التحليلية المعقدة.

عندما تجمع بين التوجيه الدلالي لرفع كفاءة التكلفة وآليات الـ fallback الديناميكية لزيادة الموثوقية، تتغير المقاييس التشغيلية للنظام بالكامل.

أساس حساب التكلفة التوضيحي: 1,000 مهمة × 3,000 توكن لكل مهمة. المزود الفردي يستخدم تسعيرة ثابتة بقيمة 15 دولاراً لكل مليون توكن. البنية ذاتية الإصلاح توجه 80% من المهام إلى نموذج بتكلفة 1 دولار لكل مليون توكن و20% إلى نموذج بتكلفة 15 دولاراً لكل مليون توكن.

يرتبط الانخفاض في معدلات فشل المنطق ارتباطاً مباشراً بالساعات التي تم توفيرها. على سبيل المثال، إذا كان وكيل استخراج البيانات الداخلي يعالج 10,000 مستند شهرياً ويفشل في 8.5% منها (توضيحياً)، فيجب على فريقك معالجة 850 مستنداً يدوياً. من خلال تنفيذ محاولات الإعادة المستندة إلى الحالة، إذا انخفض حجم الفشل هذا إلى 3.2%، فلن تضطر إلا للتعامل مع 320 مستنداً فقط. البنية التحتية تغطي تكاليفها بالكامل بمجرد استعادة ساعات العمل التشغيلية وحماية عقود العملاء.

تنفيذ التدهور التدريجي السلس (Graceful Degradation) في بيئة الإنتاج

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

نحن نصمم مسارات التدهور هذه في ثلاثة مستويات:

المستوى 1: المحرك الرئيسي (The Primary Engine) هذه هي الحالة المثالية. يستخدم الوكيل نموذج استدلال من الفئة الأولى لمعالجة التعليمات المعقدة متعددة الخطوات وتنسيق أدوات متعددة. يتم تحسين زمن الاستجابة والتكلفة لبيئة التشغيل القياسية.

المستوى 2: الـ Fallback الموازي (The Parallel Fallback) إذا واجه المزود الرئيسي حد معدل الطلبات أو توقف عن العمل، تقوم البوابة على الفور بتوجيه الطلبات إلى نموذج رائد مماثل من مزود منافس. تظل القدرات متطابقة، وتستمر الأعمال في العمل دون انقطاع. يتطلب هذا التأكد من أن الموجهات (prompts) الخاصة بك ليست مفرطة في التحسين لخصائص نموذج واحد محدد، وهو مصدر شائع للديون التقنية في الذكاء الاصطناعي.

المستوى 3: الـ Fallback المحلي المتخصص (The Specialized Local Fallback) إذا تدهور الاتصال السحابي الخارجي تماماً، أو إذا واجه جميع المزودين الرئيسيين مشكلات متزامنة (وهو ما يحدث أثناء أحداث الشبكة الإقليمية الكبرى)، يتراجع النظام إلى نموذج مفتوح الأوزان مستضاف محلياً. قد لا يمتلك هذا النموذج المحلي قدرة الاستدلال لتنفيذ تدفقات عمل معقدة متعددة الأدوات، ولكنه يمكنه تنفيذ بروتوكول 'قاطع الدائرة' (circuit breaker) بأمان—إبلاغ المستخدم بالحالة المتدهورة، وتسجيل الطلب بشكل آمن، ووضع المهمة في قائمة الانتظار للمعالجة غير المتزامنة بمجرد استعادة الأنظمة الرئيسية عافيتها.

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

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

هل يؤدي تنفيذ بوابة التوجيه (routing gateway) إلى زيادة زمن الاستجابة (latency)؟ في التشغيل القياسي، تضيف بوابة مثل LiteLLM زمناً لا يُذكر—عادةً أقل من 15 مللي ثانية. عند حدوث فشل وتشغيل آلية الـ fallback، يواجه المستخدم زمن استجابة الطلب الأولي الفاشل بالإضافة إلى زمن استجابة طلب الـ fallback الناجح. ورغم أن هذا قد يضيف ثانية إلى وقت الاستجابة، إلا أنه يمنع الفشل التام للنظام، وهو مقايضة ضرورية لحماية تجربة المستخدم والتزامات اتفاقية مستوى الخدمة (SLA).

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

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

لماذا لا نكتفي بكتابة كتل try/catch في لغة Python القياسية بدلاً من استخدام LangGraph؟ تتعامل كتل try/catch القياسية مع أخطاء تنفيذ الكود، لكنها لا تستطيع معالجة إخفاقات الاستدلال متعدد الخطوات بسهولة. إذا كان الوكيل بحاجة إلى البحث في قاعدة بيانات، وقراءة النتيجة، وإدراك أن مصطلح البحث كان ضيقاً للغاية، ثم المحاولة مرة أخرى، فإن هذه مشكلة منطقية مستندة إلى الحالة (stateful logic)، وليست استثناءً برمجياً (code exception). يحتفظ LangGraph بالتاريخ الكامل لأفعال الوكيل وأفكاره ككائن حالة، مما يسمح للنموذج نفسه بالاستدلال على إخفاقاته السابقة وتجربة استراتيجيات جديدة. يمكن أن تتحول حلقات Python القياسية إلى أكواد عشوائية (spaghetti code) يصعب صيانتها عند محاولة تنسيق هذا المستوى من منطق إعادة المحاولة الذاتي.

ما هو العائد على الاستثمار (ROI) النموذجي لتنفيذ بنية ذاتية الإصلاح مقارنة بتكاملات الـ API القياسية؟ بينما يزيد بناء طبقات الإصلاح الذاتي من وقت التطوير الأولي بنسبة 20% إلى 30%، فإن العائد على الاستثمار يتحقق بشكل فوري تقريباً في بيئة الإنتاج. من خلال تجنب غرامات انتهاك اتفاقية مستوى الخدمة (SLA) (والتي يمكن أن تكلف آلاف الدولارات لكل ساعة توقف لشركات الـ B2B SaaS) وخفض تكاليف وحدة الـ API بنسبة تصل إلى 74% من خلال التوجيه الدلالي، تسترد معظم المؤسسات تكاليف التنفيذ الأولية في غضون أول 60 إلى 90 يوماً من توسيع النطاق.