قد يستغرق اختيار نموذج لغوي كبير (LLM) أساسي فترة ما بعد الظهر. لكن التعامل مع ما يحدث عند فشله هو المهمة الهندسية الحقيقية.

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

في أي تطبيق جاد يعتمد على نماذج متعددة، لا تُعد قواعد التراجع (fallback rules) مجرد فكرة ثانوية، بل هي بنية تحتية أساسية. إن كيفية تصرف نظامك عندما يتعثر النموذج الأساسي هي ما يحدد ما إذا كان المستخدمون سيبقون أم سيرحلون.

ابدأ بإشارات فشل واضحة

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

راقب تجاوز مهلة استجابة واجهة برمجة التطبيقات (API timeouts) عندما يتوقف نقطة نهاية المزود (provider's endpoint) عن الاستجابة. راقب أخطاء حدود المعدل (rate limit errors) — وعادة ما تكون HTTP 429 — والتي تظهر عند حدوث طفرات في حركة المرور أو الوصول إلى الحصص الشهرية. راقب مخرجات JSON غير الصالحة التي تؤدي إلى تعطل خط معالجة البيانات (parser pipeline). راقب الاستجابات الفارغة أو غير المكتملة التي تبدو ناجحة على مستوى HTTP ولكنها لا تحتوي على محتوى قابل للاستخدام. راقب زمن الاستجابة العالي (high latency) الذي يقلل من جودة تجربة الدردشة قبل حدوث أي تجاوز فعلي للمهلة. راقب تجاوز طول السياق (context length overflow) عندما تتجاوز مدخلات المستخدم نافذة النموذج. وراقب تراجع الجودة، وهو أدق أنواع الفشل على الإطلاق: حيث يستجيب النموذج، لكن إجاباته تصبح منحرفة، أو غامضة، أو تتجاهل تعليمات التنسيق بعد تحديث من جانب المزود.

يجب أن تؤدي كل إشارة من هذه الإشارات إلى استجابة مختلفة. تجاوز المهلة يستدعي إعادة المحاولة. الـ JSON السيئ يستدعي تبديل النموذج. أما تجاوز حد المعدل فقد يعني أنك بحاجة إلى استخدام مزود مختلف تماماً.

طابق التراجع مع سير العمل

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

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

أنظمة RAG تحتاج إلى الدقة. لقد دفعت بالفعل تكلفة الاسترجاع — البحث الشعاعي (vector search)، وإعادة التصنيف (reranking)، وربما الزحف إلى الويب (web crawling). إذا فشل المولد في احترام السياق المقدم، فستضيع كل تلك الجهود سدى. انتقل إلى نموذج معروف بدقته في اتباع التعليمات واستيعاب السياق الطويل، حتى لو كان أبطأ.

أدوات البرمجة تحتاج إلى المنطق. يريد المطورون بناء جملة (syntax) صحيحاً واستدعاءات API صالحة بدلاً من التفسيرات البليغة. إذا بدأ النموذج الأساسي في "الهلوسة" بخصوص الدوال أو تجاهل الحالات الاستثنائية (edge cases)، فقم بالتبديل إلى نموذج تم ضبطه بدقة (fine-tuned) على الأكواد البرمجية. اقبل زمن استجابة أعلى مقابل الحصول على مخرجات جاهزة للتجميع (compile-ready).

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

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

اعرف قيودك قبل التبديل

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

قبل ترقية أي نموذج إلى حالة التراجع (fallback status)، قم بمراجعته بناءً على ستة عوامل.

  • قدرة النموذج: هل يمكنه حقاً التعامل مع نوع المطالبة (prompt)، أم سيفشل بطريقة مختلفة؟
  • دعم اللغات: قد يتقن نموذجك الاحتياطي اللغة الإنجليزية، لكنه قد يهلوس في الهندية أو الإسبانية أو اليابانية.
  • حجم نافذة السياق: إذا كانت مدخلاتك تبلغ 50,000 توكن (token)، فإن النموذج البديل الذي يمتلك حداً قدره 16,000 توكن سيقوم باقتطاع النص وتدمير المعنى بصمت.
  • زمن الاستجابة (Latency): بعض المزودين أسرع باستمرار من غيرهم في منطقتك.
  • التكلفة لكل طلب: ضع حداً أقصى صارماً. اعرف تكلفة النموذج البديل عند ذروة الاستخدام.
  • موثوقية المخرجات: هل سيلتزم بتنسيق المخرجات في كل مرة، أم في أيام معينة فقط؟

أربعة أنماط فعالة للتعامل مع حالات الفشل (Fallback)

ليست كل حالة فشل تستحق نفس العلاج. قم ببناء مجموعة أدوات من أنواع الـ fallback وطبقها بشكل مدروس.

نمط إعادة المحاولة (Retry fallback). بالنسبة لأخطاء الشبكة العابرة وانقطاعات المزود القصيرة، أعد محاولة استخدام نفس النموذج مع استخدام أسلوب التراجع الأسي (exponential backoff). لا تعد المحاولة في حالة المخرجات المشوهة أو تجاوز سياق النص — فإرسال نفس المطالبة السيئة مرتين نادراً ما يجدي نفعاً.

نمط البديل المكافئ (Equivalent fallback). عندما يتوقف مزودك الأساسي عن العمل أو يتم تقييد سرعته، انتقل إلى نموذج مشابه من مزود مختلف. الانتقال من نموذج رائد (frontier model) إلى آخر من نفس الفئة تقريباً يتطلب عادةً حداً أدنى من إعادة كتابة المطالبة ويحافظ على جودة المخرجات.

نمط البديل الأرخص (Cheaper fallback). خصص نموذجاً منخفض التكلفة للمهام غير الحرجة. إذا واجه الخيار الرخيص صعوبة، فقم بتقليل جودة الميزة تدريجياً بدلاً من استهلاك توكنات ممتازة (premium tokens) في أعمال منخفضة القيمة.

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

دمج المنطق في بنيتك البرمجية

لا تشتت منطق الـ fallback عبر عشرات من كتل try-catch في كود التطبيق. تعامل مع التوجيه (routing) كبنية تحتية. قم ببناء طبقة وسيطة (middleware layer) تربط أنواع المهام بقوائم مرتبة من النماذج، بحيث يكون لكل منها حد زمن الاستجابة (timeout threshold)، وسياسة إعادة المحاولة، وقاطع الدائرة (circuit breaker) الخاص بها.

تتبع أحداث الـ fallback كمقاييس أساسية (first-class metrics). تخبرك معدلات الخطأ متى يتوقف النموذج عن العمل؛ بينما تخبرك معدلات الـ fallback متى يكون النموذج غير مناسب للمهمة. إذا كان نظامك يلجأ للبديل بنسبة 30 أو 40 بالمائة من الوقت، فهذا يعني أن نموذجك الأساسي غير متوافق بشكل جيد مع حجم العمل. هذه إشارة لإعادة تقييم اختيارك للنماذج، وليس فقط معالجة الأخطاء.

ضع ميزانيات صريحة. لا ينبغي أبداً أن يكون الـ fallback بمثابة شيك على بياض. إذا قمت بالتصعيد إلى نموذج مميز (premium model) تحت ضغط العمل، فضع حداً أقصى لعدد الطلبات المصعدة في الدقيقة. احمِ محفظتك بنفس الصرامة التي تحمي بها وقت التشغيل (uptime) الخاص بك.

الاختبار الحقيقي

أنت لا تبني من أجل العرض التجريبي (demo). أنت تبني من أجل يوم الثلاثاء الساعة 3 مساءً، عندما تكون الـ API بطيئة، والمستخدم ينتظر، وفريق المالية يسأل للتو لماذا تضاعفت فاتورة الذكاء الاصطناعي. استراتيجية الـ fallback الناضجة تحافظ على استقرار المنتج، وتجعل تجربة المستخدم متسقة، وتجعل تكاليفك قابلة للتنبؤ.

اختر نموذجك الأساسي بعناية. ولكن اقضِ ضعف الوقت في تصميم ما سيحدث عندما يخذلك.

المصدر: How to Design AI Model Fallback Rules for Multi-Model Apps

المجتمع: GyaanSetu AI on Telegram