ایک بنیادی لارج لینگویج ماڈل (LLM) کا انتخاب کرنے میں شاید ایک دوپہر لگ جائے۔ لیکن جب یہ ناکام ہو جائے تو اس صورتحال کو سنبھالنا اصل انجینئرنگ کا کام ہے۔

زیادہ تر ٹیمیں مثالی حالات (happy path) کے لیے چیزوں کو بہتر بناتی ہیں۔ وہ صاف ستھرے ڈیٹا سیٹس پر درستگی کا معیار طے کرتی ہیں، مثالی ان پٹس کے لیے پرامپٹس کو بہتر بناتی ہیں، اور اعتماد کے ساتھ اسے ڈیپلائے کر دیتی ہیں۔ پھر پروڈکشن ٹریفک کا آغاز ہوتا ہے۔ ماڈل مصروف اوقات کے دوران ٹائم آؤٹ ہونے لگتا ہے، جمعہ کی شاموں کو غلط JSON فارمیٹ واپس کرتا ہے، یا قیمتوں میں تبدیلی کے بعد اچانک تین گنا زیادہ خرچ ہونے لگتا ہے۔ آپ کا احتیاط سے ڈیزائن کیا گیا AI فیچر ایک بوجھ بن جاتا ہے کیونکہ کسی نے ماڈل کے خراب ہونے کا منصوبہ نہیں بنایا تھا۔

کسی بھی سنجیدہ ملٹی ماڈل ایپلی کیشن میں، فال بیک (fallback) کے اصول کوئی بعد میں سوچا جانے والا معاملہ نہیں ہوتے۔ یہ بنیادی انفراسٹرکچر کا حصہ ہیں۔ جب بنیادی ماڈل لڑکھڑاتا ہے تو آپ کا سسٹم کیسا برتاؤ کرتا ہے، یہی فیصلہ کرتا ہے کہ صارفین رکیں گے یا چلے جائیں گے۔

واضح ناکامی کے اشاروں سے آغاز کریں

آپ اس وقت تک فال بیک حکمت عملی نہیں بنا سکتے جب تک آپ کو یہ معلوم نہ ہو کہ آپ کس چیز پر ردعمل دے رہے ہیں۔ ہر آؤٹ باؤنڈ ماڈل کال کو مانیٹر کرنا شروع کریں اور ناکامیوں کو مخصوص، قابل عمل اشاروں میں تقسیم کریں۔

جب کسی فراہم کنندہ (provider) کا اینڈ پوائنٹ رک جائے تو API ٹائم آؤٹ پر نظر رکھیں۔ ریٹ لیمٹ کی غلطیوں پر نظر رکھیں — عام طور پر HTTP 429s — جو اس وقت آتی ہیں جب ٹریفک اچانک بڑھ جائے یا ماہانہ کوٹہ ختم ہو جائے۔ غلط JSON آؤٹ پٹ پر نظر رکھیں جو آپ کے پارسر پائپ لائن کو کریش کر دے۔ خالی یا نامکمل جوابات پر نظر رکھیں جو HTTP لیئر پر تو کامیاب لگتے ہیں لیکن ان میں کوئی قابل استعمال مواد نہیں ہوتا۔ زیادہ لیٹنسی (latency) پر نظر رکھیں جو کسی سخت ٹائم آؤٹ سے پہلے ہی چیٹ کے تجربے کو خراب کر دیتی ہے۔ جب صارف کا ان پٹ ماڈل کی حد سے بڑھ جائے تو کانٹیکسٹ لینتھ اوور فلو (context length overflow) پر نظر رکھیں۔ اور معیار میں کمی (quality regression) پر نظر رکھیں، جو سب سے باریک ناکامی ہے: ماڈل جواب تو دیتا ہے، لیکن فراہم کنندہ کی جانب سے اپ ڈیٹ کے بعد اس کے جوابات غیر متعلقہ ہو جاتے ہیں، مبہم ہو جاتے ہیں، یا فارمیٹنگ کی ہدایات کو نظر انداز کر دیتے ہیں۔

ان میں سے ہر اشارہ ایک مختلف ردعمل کا باعث بننا چاہیے۔ ٹائم آؤٹ کے لیے دوبارہ کوشش (retry) مناسب ہے۔ غلط JSON کے لیے ماڈل تبدیل کرنا بہتر ہے۔ ریٹ لیمٹ کا مطلب یہ ہو سکتا ہے کہ آپ کو مکمل طور پر کسی دوسرے فراہم کنندہ کا استعمال کرنے کی ضرورت ہے۔

فال بیک کو ورک فلو کے مطابق بنائیں

ہر کام کے لیے ایک ہی فال بیک اصول استعمال کرنا تباہی کا باعث بن سکتا ہے۔ ایک چیٹ بوٹ اور بیک گراؤنڈ ڈیٹا ایکسٹریکشن کے کام کی ضروریات ایک دوسرے سے بالکل مختلف ہوتی ہیں۔ اپنے فال بیک کو مخصوص ورک فلو کے گرد ڈیزائن کریں۔

Chatbots کو رفتار اور گفتگو کے تسلسل کی ضرورت ہوتی ہے۔ صارفین تھوڑے عام سے جواب کو معاف کر دیں گے، لیکن وہ پانچ سیکنڈ کے وقفے کو معاف نہیں کریں گے۔ اگر آپ کا بنیادی ماڈل سست ہو جائے تو کسی تیز رفتار بیک اپ پر منتقل ہو جائیں — اکثر اسی ماڈل فیملی کا کوئی چھوٹا ورژن، یا کسی دوسرے فراہم کنندہ کی اسپیڈ ٹیر (speed-tier) پیشکش۔ گفتگو کو جاری رکھیں۔

RAG systems کو درستگی کی ضرورت ہوتی ہے۔ آپ پہلے ہی ڈیٹا نکالنے (retrieval) کی قیمت ادا کر چکے ہیں — ویکٹر سرچ، ری رینکنگ، شاید ویب کرالنگ۔ اگر جنریٹر فراہم کردہ سیاق و سباق (context) کا احترام کرنے میں ناکام رہتا ہے، تو وہ تمام محنت ضائع ہو جاتی ہے۔ کسی ایسے ماڈل پر منتقل ہو جائیں جو درست ہدایات پر عمل کرنے اور طویل سیاق و سباق کو سمجھنے کے لیے جانا جاتا ہو، چاہے وہ سست ہی کیوں نہ ہو۔

Coding tools کو منطق (logic) کی ضرورت ہوتی ہے۔ ڈویلپرز خوشگوار وضاحتوں کے بجائے درست سنٹیکس اور درست API کالز چاہتے ہیں۔ اگر بنیادی ماڈل فنکشنز کے بارے میں غلط معلومات (hallucinating) دینے لگے یا اہم کیسز کو چھوڑنے لگے، تو کوڈ پر مبنی ماڈل پر منتقل ہو جائیں۔ کمپائل کے قابل آؤٹ پٹ کے بدلے زیادہ لیٹنسی کو قبول کریں۔

JSON extraction کو ساخت (structure) کی ضرورت ہوتی ہے۔ ساخت کے مطابق ڈیٹا تیار کرنا ایک نازک عمل ہے۔ ایک غائب بریکٹ یا غلط طریقے سے استعمال شدہ کوٹیشن مارک ڈیٹا بیس میں ڈیٹا لکھنے کے عمل کو ناکام بنا سکتا ہے۔ اگر آپ کا بنیادی ماڈل اسکیما (schema) کی پابندی سے ہٹ جائے، تو ایک بار دوبارہ کوشش کریں، پھر ایسے ماڈل پر منتقل ہو جائیں جس کی فارمیٹنگ کی بھروسہ مندی زیادہ ہو۔ حیرت انگیز طور پر، فرمانبرداری کے لیے ٹیون کیے گئے چھوٹے ماڈلز اکثر اس مخصوص کام میں تخلیقی بڑے ماڈلز سے بہتر کارکردگی دکھاتے ہیں۔

Automation and batch jobs کو لاگت کے کنٹرول کی ضرورت ہوتی ہے۔ بیک گراؤنڈ کلاسیفائرز، لاگ سمریزرز، اور نوٹیفکیشن جنریٹرز مسلسل چلتے رہتے ہیں۔ آپ کے بنیادی ماڈل کی قیمت میں اچانک اضافہ ایک قابلِ انتظام روزانہ کے بل کو بجٹ کے بحران میں بدل سکتا ہے۔ ان غیر اہم کاموں کے لیے ایک سستا اور مستحکم ماڈل اسٹینڈ بائی پر رکھیں۔ اگر آؤٹ پٹ کا معیار تھوڑا گر بھی جائے، تو کاروباری اثر عام طور پر کم ہوتا ہے۔

تبدیلی سے پہلے اپنی حدود کو جان لیں

اندھا دھند ماڈلز کو تبدیل کرنا نئی مشکلات پیدا کرتا ہے۔ اگر آپ ایک طاقتور ماڈل سے کمزور ماڈل پر منتقل ہوتے ہیں، تو بیک اپ ماڈل باریک ہدایات کو غلط سمجھ سکتا ہے اور ایسا غلط ڈیٹا پیدا کر سکتا ہے جو آگے چل کر مزید غلطیوں کا باعث بنے۔ اگر آپ کسی بڑے ماڈل کی طرف جاتے ہیں، تو ہو سکتا ہے کہ آپ معیار کا مسئلہ حل کر لیں لیکن چند گھنٹوں میں اپنا بجٹ ختم کر دیں۔

کسی بھی ماڈل کو فال بیک کے طور پر استعمال کرنے سے پہلے، چھ عوامل کے مطابق اس کا آڈٹ کریں۔

  • ماڈل کی صلاحیت: کیا یہ واقعی پرامپٹ کی قسم کو سنبھال سکتا ہے، یا یہ کسی اور طریقے سے ناکام ہو جائے گا؟
  • زبان کی سپورٹ: آپ کا بیک اپ انگریزی میں تو ماہر ہو سکتا ہے لیکن ہندی، ہسپانوی یا جاپانی میں غلط معلومات (hallucinate) دے سکتا ہے۔
  • کانٹیکسٹ ونڈو کا سائز: اگر آپ کا ان پٹ 50,000 ٹوکنز ہے، تو 16,000 ٹوکنز کی حد رکھنے والا فال بیک ڈیٹا کو کاٹ دے گا اور خاموشی سے معنی کو تباہ کر دے گا۔
  • لیٹنسی (Latency): کچھ فراہم کنندہ آپ کے علاقے کے لیے دوسروں کے مقابلے میں مستقل طور پر تیز ہوتے ہیں۔
  • فی درخواست لاگت: ایک سخت حد مقرر کریں۔ جان لیں کہ زیادہ لوڈ کے وقت فال بیک کی لاگت کیا ہوگی۔
  • آؤٹ پٹ کی بھروسہ مندی: کیا یہ ہر بار آؤٹ پٹ فارمیٹ پر عمل کرے گا، یا صرف منگل کے روز؟

چار فال بیک پیٹرنز جو کام کرتے ہیں

ہر ناکامی کا علاج ایک جیسا نہیں ہوتا۔ فال بیک کی اقسام کا ایک ٹول کٹ بنائیں اور انہیں سوچ سمجھ کر استعمال کریں۔

ری ٹرائی فال بیک (Retry fallback)۔ عارضی نیٹ ورک کی غلطیوں اور فراہم کنندہ کے مختصر تعطل کے لیے، ایکسپونینشل بیک آف (exponential backoff) کے ساتھ اسی ماڈل کو دوبارہ کوشش کریں۔ غلط فارمیٹ والے آؤٹ پٹ یا کانٹیکسٹ اوور فلو پر دوبارہ کوشش نہ کریں — ایک ہی غلط پرامپٹ کو دو بار بھیجنے سے شاذ و نادر ہی کوئی فائدہ ہوتا ہے۔

مساوی فال بیک (Equivalent fallback)۔ جب آپ کا بنیادی فراہم کنندہ دستیاب نہ ہو یا اس کی رفتار محدود (throttled) ہو، تو کسی دوسرے فراہم کنندہ کے اسی طرح کے ماڈل پر منتقل ہو جائیں۔ ایک فرنٹیر ماڈل سے تقریباً اسی درجے کے دوسرے ماڈل پر منتقل ہونے کے لیے عام طور پر پرامپٹ کی بہت کم دوبارہ لکھائی کی ضرورت ہوتی ہے اور آؤٹ پٹ کا معیار برقرار رہتا ہے۔

سستا فال بیک (Cheaper fallback)۔ غیر اہم کاموں کے لیے کم لاگت والا ماڈل مخصوص رکھیں۔ اگر سستا آپشن جدوجہد کرے، تو کم اہمیت والے کاموں پر قیمتی ٹوکنز ضائع کرنے کے بجائے فیچر کی کارکردگی کو نرمی سے کم (degrade gracefully) کر دیں۔

مضبوط فال بیک (Stronger fallback)۔ یہ سننے میں الٹا لگتا ہے، لیکن یہ ضروری ہے۔ جب ایک درمیانے درجے کا ماڈل پیچیدہ استدلال (reasoning)، کثیر مرحلہ وار ریاضی، یا باریک قانونی تجزیہ کرنے میں مسلسل ناکام ہو رہا ہو، تو زیادہ قابل ماڈل کی طرف بڑھیں۔ اسے صرف ان اعلیٰ قدر والے صارف راستوں (user paths) کے لیے وقفے وقفے سے استعمال کریں جہاں درستگی آمدنی یا حفاظت کا تحفظ کرتی ہے۔

اپنی آرکیٹیکچر میں لاجک شامل کریں

ایپلی کیشن کوڈ میں درجنوں try-catch بلاکس میں فال بیک لاجک کو بکھیریں نہیں۔ روٹنگ کو انفراسٹرکچر کے طور پر سمجھیں۔ ایک مڈل ویئر لیئر بنائیں جو ٹاسک کی اقسام کو ماڈلز کی ترتیب وار فہرستوں سے جوڑے، جس میں سے ہر ایک کی اپنی ٹائم آؤٹ حد، ری ٹرائی پالیسی اور سرکٹ بریکر ہو۔

فال بیک واقعات کو فرسٹ کلاس میٹرکس کے طور پر ٹریک کریں۔ ایرر ریٹس آپ کو بتاتے ہیں کہ کب کوئی ماڈل ڈاؤن ہے؛ فال بیک ریٹس آپ کو بتاتے ہیں کہ کب کوئی ماڈل کام کے لیے غلط ہے۔ اگر آپ کا سسٹم 30 یا 40 فیصد وقت فال بیک کرتا ہے، تو اس کا مطلب ہے کہ آپ کا بنیادی ماڈل ورک لوڈ کے ساتھ صحیح طرح سے مطابقت نہیں رکھتا۔ یہ صرف آپ کے ایرر ہینڈلنگ کو نہیں بلکہ آپ کے ماڈل کے انتخاب پر نظر ثانی کرنے کا اشارہ ہے۔

واضح بجٹ مقرر کریں۔ فال بیک کبھی بھی بلا روک ٹوک چیک (blank check) نہیں ہونا چاہیے۔ اگر لوڈ کے دوران آپ کسی پریمیم ماڈل کی طرف منتقل ہوتے ہیں، تو فی منٹ منتقل ہونے والی درخواستوں کی تعداد مقرر کریں۔ اپنے اپ ٹائم کی طرح ہی سختی سے اپنے بجٹ کا تحفظ کریں۔

اصل امتحان

آپ ڈیمو کے لیے نہیں بنا رہے ہیں۔ آپ منگل کے دن دوپہر 3 بجے کے لیے بنا رہے ہیں، جب API سست ہو، صارف انتظار کر رہا ہو، اور فنانس ٹیم نے ابھی پوچھا ہو کہ AI کا بل دوگنا کیوں ہو گیا۔ ایک پختہ فال بیک حکمت عملی پروڈکٹ کو مستحکم رکھتی ہے، صارف کے تجربے کو مستقل رکھتی ہے، اور آپ کے اخراجات کو قابل پیش گوئی رکھتی ہے۔

اپنے بنیادی ماڈل کا انتخاب احتیاط سے کریں۔ لیکن جب وہ آپ کو مایوس کرے تو کیا ہوگا، اس کے ڈیزائن پر اس سے دوگنا وقت صرف کریں۔

ماخذ: How to Design AI Model Fallback Rules for Multi-Model Apps

کمیونٹی: GyaanSetu AI on Telegram