Retry اور fallback کو الگ رکھیں
Retry request کو اسی route پر دوبارہ بھیجتا ہے کیونکہ failure عارضی ہو سکتا ہے۔ Fallback provider یا model کو بدلتا ہے کیونکہ اصل route دستیاب نہیں یا مناسب نہیں ہوتا۔
ان دونوں actions کو ایک generic retry loop سمجھنا incidents کی تشخیص مشکل بنا دیتا ہے اور success rate بہتر کیے بغیر cost کو بڑھا سکتا ہے۔
- Retry: timeout، connection reset، 429 یا عارضی 5xx response۔
- Fallback: بار بار provider failure، model capacity issue یا policy restriction۔
- Stop: invalid request، unsupported parameter یا failed output validation۔
Capability-compatible route table بنائیں
Fallback models کو brand کے بجائے capability کی بنیاد پر گروپ کیا جانا چاہیے۔ ایک vision request text-only model پر fallback نہیں ہو سکتی، اور ایک strict JSON workflow کو ایسے model کی طرف route نہیں کرنا چاہیے جو باقاعدگی سے schema کی خلاف ورزی کرے۔
- Required input اور output modalities۔
- Minimum context اور output length۔
- Tool calling اور structured-output support۔
- زیادہ سے زیادہ قابلِ قبول price اور latency۔
ایک request-level budget نافذ کریں
Request budget کو ہر retry اور fallback attempt کا احاطہ کرنا چاہیے۔ ایک اور attempt شروع کرنے سے پہلے دیکھیں کہ remaining latency اور cost budget اسے support کر سکتے ہیں یا نہیں۔
const routePolicy = {
maxAttempts: 3,
maxLatencyMs: 18_000,
maxEstimatedCost: 0.12,
retryOn: [408, 429, 500, 502, 503, 504],
fallbackModels: ['primary-model', 'quality-fallback', 'fast-fallback'],
};Fallback quality کو بھی measure کریں، صرف availability کو نہیں
جو request success کے ساتھ واپس آئے وہ پھر بھی product failure ہو سکتا ہے۔ Fallback event کے بعد output validation، user correction rate اور task completion track کریں۔
Recommended dashboard: route success، fallback rate، p95 latency، estimated cost، validation pass rate اور model کے لحاظ سے quality score۔