اے آئی ماڈل فیل اوور ڈرلز: جب فراہم کنندگان ناکام ہوں تو ایجنٹس کو کارآمد رکھیں
ماڈل فال بیک (fallback) جو صرف ایک ڈائیگرام میں کام کرتا ہے، وہ لچک (resilience) نہیں ہے۔ یہ محض بہتر برانڈنگ کے ساتھ ایک منصوبہ ہے۔
اگر آپ کی پروڈکٹ AI ایجنٹس استعمال کرتی ہے، تو ایک سست فراہم کنندہ (provider) یا ریٹ لیمٹ (rate-limit) میں اچانک اضافہ صارف کے تجربے کو خراب کر سکتا ہے۔ اصل خطرہ مکمل بندش (outage) نہیں ہے۔ اصل خطرہ ایک آدھا کام کرنے والا فال بیک ہے۔ ایسا تب ہوتا ہے جب ایک بیک اپ ماڈل خاموشی سے ڈیٹا فارمیٹس تبدیل کر دیتا ہے، ٹول اسٹیٹ (tool state) کو ختم کر دیتا ہے، یا صارف کو بتائے بغیر حوالوں (citations) کو چھوڑ دیتا ہے۔
آپ کو پروڈکشن ٹریفک کے ذریعے مشکل سبق سیکھنے پر مجبور ہونے سے پہلے عملی فیل اوور ڈرلز (failover drills) چلانی چاہئیں۔
مقصد ہر ماڈل کو ایک دوسرے کے متبادل بنانا نہیں ہے۔ مقصد یہ ہے کہ جب بنیادی ماڈل ناکام ہو جائے تو ورک فلو کو محفوظ اور درست رکھا جائے۔
زیادہ تر ٹیمیں ایک سادہ زنجیر استعمال کرتی ہیں: پہلے بنیادی ماڈل کو آزمائیں، پھر بیک اپ، اور پھر ایرر (error) دکھائیں۔ یہ طریقہ AI سسٹمز کے اصل مسائل کو نظر انداز کر دیتا ہے۔ AI باریک بینی سے ناکام ہوتا ہے:
• ایک بیک اپ ماڈل مختلف فیلڈ معانی کے ساتھ JSON واپس کرتا ہے۔ • ایک سستا ماڈل آپ کی ٹول پالیسیوں کو نظر انداز کر دیتا ہے۔ • ایک فراہم کنندہ ٹوکنز (tokens) بہت آہستہ اسٹریم کرتا ہے۔ • ایک فال بیک ماڈل میں وہی فنکشن کالنگ (function-calling) فارمیٹ نہیں ہوتا ہے۔ • ایجنٹ بار بار کوشش کرتا ہے اور صارف کا بجٹ ختم کر دیتا ہے۔
اے آئی ماڈل فیل اوور ڈرل ایک منصوبہ بند ٹیسٹ ہے۔ آپ جان بوجھ کر ایک ماڈل کے راستے کو توڑتے ہیں تاکہ یہ دیکھ سکیں کہ آیا پروڈکٹ محفوظ رہتی ہے یا نہیں۔
ایک اچھی ڈرل یہ چیک کرتی ہے:
- کیا ورک فلو چلتا رہتا ہے؟
- کیا یہ اسکیما (schema) اور ٹول اسٹیٹ کو برقرار رکھتا ہے؟
- کیا یہ لاگت اور لیٹنسی (latency) کے بجٹ کے اندر رہتا ہے؟
- کیا یہ اگلی بار کے لیے ریگریشن ٹیسٹ (regression test) تیار کرتا ہے؟
ہر پرامپٹ (prompt) کو متعدد فراہم کنندگان کے ساتھ کام کرنے کے قابل بنا کر آغاز نہ کریں۔ ان ورک فلو سے آغاز کریں جہاں ناکامی اعتماد کو ختم کر دیتی ہے۔
اعلیٰ ترجیحی ورک فلو:
- کسٹمر کے سامنے والی چیٹ
- رپورٹ کی تیاری
- ایجنٹ ورک فلو جو ٹولز کو کال کرتے ہیں
- حوالوں کے ساتھ RAG جوابات
- اسٹرکچرڈ فیلڈز میں ڈیٹا کا اخراج (extraction)
بہترین ڈیزائن ایک معاہدے (contract) سے شروع ہوتا ہے، نہ کہ ماڈل کے ناموں کی فہرست سے۔ ایک فال بیک معاہدہ یہ طے کرتا ہے کہ تمام فراہم کنندگان پر کیا چیزیں برقرار رہنی چاہئیں۔ ایک سپورٹ ایجنٹ کے لیے، اس میں یہ شامل ہو سکتا ہے:
- ان پٹ اور آؤٹ پٹ کی شکلیں (shapes)
- اعتماد کی سطح اور حوالے (citations)
- ٹول کی اجازتیں اور باقی بجٹ
- کوالٹی گیٹس اور تصدیقی قواعد (validation rules)
کبھی کبھی درست فال بیک کوئی دوسرا ماڈل نہیں ہوتا۔ یہ ہو سکتا ہے:
- صارف سے تصدیق مانگنا
- جزوی نتیجہ واپس کرنا
- کام کو بعد کے لیے قطار (queue) میں ڈالنا
- ورک فلو کو انسانی جائزے (human review) کے لیے بھیجنا
ہر ناکامی کو دوسرا ماڈل آزمانے کی وجہ سمجھنا بند کریں۔ غلطیوں اور فارمیٹس کو نارملائز کرنے کے لیے ماڈل اڈاپٹر کا استعمال کریں۔ اس سے آپ کی ڈرلز آسان ہو جاتی ہیں کیونکہ آپ اپنے مین لاجک کو تبدیل کیے بغیر ناکامیوں کی نقل (simulate) کر سکتے ہیں۔
آغاز کرنے کے لیے یہ تین ڈرلز چلائیں:
- دی ٹائم آؤٹ ڈرل: پرائمری ماڈل کو 'سلیپ' کرنے پر مجبور کریں۔ اس بات کی تصدیق کریں کہ فال بیک آپ کے لیٹنسی بجٹ کے اندر ہوتا ہے۔
- دی ریٹ لمٹ ڈرل: 429 ایرر پیدا کریں۔ اس بات کی تصدیق کریں کہ آپ کا سسٹم بیک آف استعمال کرتا ہے اور ٹیننٹ بجٹ کا تحفظ کرتا ہے۔
- دی اسکیمہ ڈرل: ماڈل کو غیر مستند JSON واپس کرنے پر مجبور کریں۔ اس بات کی تصدیق کریں کہ آپ کا سسٹم آؤٹ پٹ کی تصدیق کرتا ہے یا ورک فلو کو محفوظ طریقے سے روک دیتا ہے۔
صارفین کو آپ کے فراہم کنندہ کی تفصیلات جاننے کی ضرورت نہیں ہے۔ انہیں ایماندارانہ رویے کی ضرورت ہے۔
برا پیغام: کچھ غلط ہو گیا ہے۔ اچھا پیغام: میں اب بھی مدد کر سکتا ہوں، لیکن براہ راست اقدامات عارضی طور پر محدود ہیں۔ میں آپ کے جائزے کے لیے اگلا مرحلہ تیار کر سکتا ہوں۔
واضح حدود کے ذریعے اعتماد پیدا کریں، نہ کہ یہ ظاہر کر کے کہ سب کچھ ٹھیک ہے۔
اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi