آپ پرامپٹ میں دستاویزات کے سو صفحات پیسٹ کرتے ہیں اور ایک سادہ سا سوال پوچھتے ہیں۔ جواب غلط آتا ہے۔ یا یہ اس فارمیٹنگ کے اصول کو نظر انداز کر دیتا ہے جو آپ نے شروع میں دیا تھا۔ آپ نے اسے سب کچھ دے دیا تھا۔ اسے کام کرنا چاہیے تھا۔ لیکن یہ نہیں ہوا۔
یہ "کانٹیکسٹ ٹریپ" (context trap) ہے۔ زیادہ تر ڈویلپرز یہ سمجھتے ہیں کہ AI کو زیادہ معلومات فراہم کرنے سے خود بخود بہتر نتائج حاصل ہوں گے۔ اکثر اس کے برعکس ہوتا ہے۔ قابل اعتماد AI ایپلی کیشنز بنانے کے لیے تین بنیادی میکانزم کو سمجھنا ضروری ہے: ماڈلز متن (text) کو کیسے گنتے ہیں، وہ ایک وقت میں کتنا ڈیٹا رکھ سکتے ہیں، اور گفتگو ختم ہونے کے بعد معلومات کا کیا ہوتا ہے۔
ٹوکنز: اصل کرنسی
ٹوکن وہ سب سے چھوٹی اکائی ہے جسے ایک لینگویج ماڈل پروسیس کرتا ہے۔ یہ ایک حرف، لفظ کا ایک ٹکڑا، یا مکمل طور پر ایک عام لفظ ہو سکتا ہے۔ لفظ "purchase" اکثر دو ٹوکنز میں تقسیم ہو جاتا ہے، جبکہ "cat" جیسا چھوٹا لفظ مکمل رہتا ہے۔ رموزِ اوقاف (punctuation) اور خالی جگہیں (spaces) بھی ٹوکنز استعمال کرتی ہیں۔ کوڈ خاص طور پر زیادہ ٹوکنز لیتا ہے۔ Python کا ایک بلاک جس میں نیم نییسٹڈ انڈینٹیشن (nested indentation) اور خصوصی حروف ہوں، ٹوکن کی تعداد میں اس اندازے سے تین یا چار گنا بڑھ سکتا ہے جو آپ اسے دیکھ کر لگائیں گے۔
ڈویلپرز کو اس کی فکر کیوں ہونی چاہیے؟ API کی قیمت فی ٹوکن ہوتی ہے۔ پروسیسنگ کا وقت بھی اسی حساب سے ہوتا ہے۔ ایک پرامپٹ جو دو صفحات کے متن جیسا نظر آتا ہے، اس کی قیمت اس کے اندر موجود مواد کے لحاظ سے چند پیسے یا ڈالرز ہو سکتی ہے۔ اس سے بھی بدتر یہ ہے کہ ٹوکنز تبادلے کے دونوں اطراف جمع ہوتے ہیں۔ آپ اپنے پرامپٹ کے ہر ٹوکن کے لیے ادائیگی کرتے ہیں، اور ماڈل جو جواب تیار کرتا ہے اس کے ہر ٹوکن کے لیے بھی آپ کو ادائیگی کرنی پڑتی ہے۔ کانٹیکسٹ میں غیر ضروری اضافہ خاموشی سے منافع (margins) کو کم کر دیتا ہے۔
کانٹیکسٹ ونڈو ایک وائٹ بورڈ کی طرح ہے
کانٹیکسٹ ونڈو اس حد کا تعین کرتی ہے کہ ایک ماڈل ایک ہی بار میں کتنا دیکھ سکتا ہے۔ ایک چھوٹے سے کمرے میں لٹکے ہوئے وائٹ بورڈ کا تصور کریں۔ آپ اسے سسٹم کی ہدایات، صارف کے سوالات، حاصل کردہ دستاویزات، اور پچھلی گفتگو سے بھر سکتے ہیں۔ لیکن بورڈ کا سائز کبھی نہیں بڑھتا۔ جب نیا متن آتا ہے، تو پرانا متن بورڈ کے کنارے سے گر جاتا ہے۔
یہ اس لیے اہم ہے کیونکہ جب ماڈلز مواد کو نکالنا شروع کرتے ہیں تو وہ آپ کو خبردار نہیں کرتے۔ اگر آپ کی سسٹم ہدایت ایک طویل گفتگو کے شروع میں ہے، اور آپ پیغامات شامل کرتے رہتے ہیں، تو وہ ہدایت آخر کار نظروں سے اوجھل ہو جائے گی۔ ماڈل اپنی ڈیفالٹ حالت میں واپس جا سکتا ہے، آپ کے فارمیٹنگ کے اصولوں کو نظر انداز کر سکتا ہے، یا پہلے دی گئی رہنمائی کے برعکس عمل کر سکتا ہے۔ مختلف ماڈلز مختلف حدیں فراہم کرتے ہیں، کچھ چند ہزار ٹوکنز کو سنبھالتے ہیں اور کچھ لاکھوں کو، لیکن طریقہ کار ایک ہی رہتا ہے۔ ان پٹ اور آؤٹ پٹ ایک ہی بجٹ شیئر کرتے ہیں۔ ایک ماڈل جو دو ہزار ٹوکنز کا جواب تیار کرتا ہے، اس کے پاس آپ کی بتائی ہوئی باتیں یاد رکھنے کے لیے دو ہزار ٹوکنز کم دستیاب ہوتے ہیں۔
میموری ایک ہیک ہے، فیچر نہیں
انفرنس (inference) کے دوران ماڈل کے ویٹس (weights) کے اندر کوئی مستقل میموری نہیں ہوتی۔ بالکل نہیں۔ جب آپ ٹیب بند کرتے ہیں اور کل واپس آتے ہیں، تو ماڈل آپ کو نہیں پہچانتا۔ ہر API کال ایک "کولڈ اسٹارٹ" (cold start) ہوتی ہے۔
جو چیز میموری محسوس ہوتی ہے وہ دراصل ایپلی کیشن لیئر کی طرف سے کی جانے والی ایک ہوشیار بک کیپنگ (bookkeeping) ہے۔ فرنٹ اینڈ آپ کے پیغامات کو ڈیٹا بیس میں محفوظ کرتا ہے۔ جب آپ ایک نیا سوال بھیجتے ہیں، تو سافٹ ویئر متعلقہ ہسٹری حاصل کرتا ہے، اسے ایک نئے پرامپٹ میں جوڑتا ہے، اور پورا پیکج ماڈل کو بھیج دیتا ہے۔ ماڈل خود اس سے بے خبر رہتا ہے۔
پروڈکٹ ٹیموں کے لیے یہ فرق بہت اہم ہے۔ اگر آپ صارف کی پسند کو "یاد رکھنے" کے لیے ماڈل پر بھروسہ کرتے ہیں، تو آپ ریت پر عمارت بنا رہے ہیں۔ آپ کو خود اسٹیٹ مینجمنٹ (state management) بنانی ہوگی۔ فیصلہ کریں کہ کس چیز کو کیش (cache) کرنا ہے۔ فیصلہ کریں کہ اسے کیسے ریفریش کرنا ہے۔ اور یہ تسلیم کریں کہ ہسٹری کا ہر بائٹ جو آپ دوبارہ بھیجتے ہیں، وہ آپ کے وائٹ بورڈ کی جگہ گھٹاتا ہے۔
جب کانٹیکسٹ شور (noise) بن جائے
پرامپٹ کو ضرورت سے زیادہ بھرنا متوقع طریقوں سے الٹا اثر دکھاتا ہے۔
شور سگنل کو ختم کر دیتا ہے۔ اگر آپ ایک بگ کے بارے میں پوچھنے کے لیے پورا کوڈ بیس ڈال دیتے ہیں، تو ماڈل کو "سوئی کو گھاس کے ڈھیر میں ڈھونڈنے" (needle-in-a-haystack) جیسے مسئلے کا سامنا کرنا پڑتا ہے۔ یہ غلط فائل کا حوالہ دے سکتا ہے، غیر ضروری (dead) کوڈ میں تبدیلیوں کی تجویز دے سکتا ہے، یا ایک عام سا جواب دے سکتا ہے کیونکہ یہ نہیں
