fallback strategy — تركيب نماذج كتير

أي production app بيستخدم نموذج واحد عنده single point of failure. النموذج ممكن يكون نازل. النموذج ممكن يرجّع قمامة على شكل input معيّن. النموذج ممكن يطلع بره الـprice لـuse case لو الـvendor عدّل التسعيرة. الـpattern الناضج هو إنك تركّب نماذج كتير بـfallback logic صريح.

الـ3 patterns اللي بتشتغل

Pattern 1 — primary + fallback. الأبسط. ابعت الـrequest للنموذج المفضّل عندك. لو الـresponse مش صالح (JSON parse فشل، body فاضي، error response، response قصير جداً)، حاول تاني على نموذج تاني. اختيارياً، بعد N فشل على الأساسي، حوّل كل الـtraffic للـfallback لفترة cooldown. ده الـsetup الإنتاجي الأشهر.

async function classifyWithFallback(input: string) {
  try {
    const r = await callClaude(input);
    if (isValid(r)) return r;
  } catch {}
  return await callGPT(input); // fallback
}

Pattern 2 — cheap-first, escalate. للمهام اللي أغلب inputs بتاعتها سهلة وكام منهم صعبين، وجّه كل حاجة لنموذج صغير الأول. لو النموذج الصغير مش متأكد (confidence قليل، مخرج مشوّه، رفض الإجابة)، اطلع لنموذج أكبر. ده بيقلّل التكلفة على الـ90% السهلة من الـrequests وبيدفع للنموذج الغالي بس على الـ10% الصعبة.

async function summariseEscalating(text: string) {
  const small = await callMistral7B(text);
  if (small.tokenCount < 50 || small.refusal) {
    return await callClaude(text); // escalate
  }
  return small;
}

Pattern 3 — verifier-on-top. نموذجين على نفس الـinput. الأول بيطلّع إجابة. التاني بيـverify الإجابة قبال الـinput. لو الـverifier رفض، اعمل regenerate. الـpattern ده overkill لإعادة كتابة نبرة بس أساسي لـcode generation، financial extraction، أو أي حاجة الغلط فيها غالي.

إزاي تعرف أنهي pattern مناسب

قاعدة قرار قصيرة:

• volume عالي، تباين صغير في صعوبة الـinput → Pattern 1 (primary + fallback) على frontier model صغير.
• volume عالي، تباين واسع في صعوبة الـinput → Pattern 2 (cheap-first, escalate) بـopen-weight model كالاختيار الرخيص.
• volume قليل، cost عالي للخطأ → Pattern 3 (verifier-on-top) بـfrontier model على الاتنين.

الـpatterns قابلة للـstacking. real production system ممكن يستخدم Pattern 2 بـLlama 4 70B كالنموذج الرخيص و Claude Sonnet 4.5 كالـescalation، بالإضافة لـverifier Pattern 3 فوق مسار Claude لأعلى 1% رهانات من الـrequests.

اللي تـlog-ه

أي multi-model setup محتاج 3 logging fields لكل request:

1. أنهي نموذج طلّع الإجابة النهائية. ولا تقدرش تـdebug "ليه المستخدم بيشتكي من مخرج غريب؟" — المستخدم ما بيعرفش أنهي نموذج ردّ.
2. ليه الـfallbacks اشتعلت (parse error، response فاضي، confidence قليل، manual override). ده الـdataset بتاعك لتحسين routing logic على الزمن.
3. Cost per request. تكاليف الـtokens بتختلف عبر النماذج؛ تكاليف الـrequests بتختلف أكتر أول ما تحسب الـfallbacks. الـlog-هم عشان تقدر تثبت التوفير للـCTO.

الـlogging ده هو الأساس بتاع تقرير المقارنة اللي هتشحنه في المشروع الختامي. تقرير هاجر مش هيقول بس "إحنا المفروض نستخدم النماذج دي للمهام دي". هيورّي التوزيع الفعلي للـcost-per-request قبل وبعد تغيير الـrouting، معدل اشتعال الـfallback، وdrجات الجودة اللي بتظهر للمستخدم. من غير logging، ولا حاجة في ده قابلة للإثبات.

الـmodule الجاي: المشروع الختامي — انقل prompt واحد عبر 8 نماذج واشحن تقرير مقارنة حقيقي. :::