کانٹیکسٹ ونڈوز (Context Windows) بہت بڑی ہو رہی ہیں
لوگ ہر چیز کے لیے 'ایجنٹ' کا لفظ استعمال کرتے ہیں۔
ایک فنکشن جو کسی ٹول کو کال کرتا ہے وہ ایجنٹ ہے۔ میموری والا چیٹ بوٹ ایجنٹ ہے۔ لوپ والا اسکرپٹ ایجنٹ ہے۔
یہ غلطی ناقص انجینئرنگ کا باعث بنتی ہے۔ ٹیمیں سادہ کاموں کو ضرورت سے زیادہ پیچیدہ بنا دیتی ہیں اور پیچیدہ کاموں کو ضرورت کے مطابق ڈیزائن نہیں کر پاتیں۔ میں دیکھتا ہوں کہ ٹیمیں ایسے ورک فلو کے لیے ایجنٹ آرکیسٹریشن (agent orchestration) پر ہفتوں ضائع کر دیتی ہیں جن کے لیے صرف ایک اچھے پرامپٹ کی ضرورت ہوتی ہے۔
ایک حقیقی ایجنٹ کی میری تعریف یہ ہے:
ایک ایجنٹ کا ایک مقصد ہوتا ہے۔ وہ صرف ہدایات پر عمل نہیں کرتا۔ وہ فیصلہ کرتا ہے کہ آگے کیا کرنا ہے۔ وہ ناکامی کو سنبھالتا ہے۔ اسے معلوم ہوتا ہے کہ کب رکنا ہے۔
ان معیاروں (benchmarks) کا استعمال کریں:
- اگر انسان کو ہر قدم پر رہنمائی کرنی پڑے، تو یہ ایک چیٹ انٹرفیس ہے۔
- اگر سسٹم کسی ناکام ٹول کال سے خود کو سنبھال لیتا ہے، تو یہ ایجنٹ بننے کی طرف بڑھ رہا ہے۔
- اگر سسٹم ایک مقصد کو مختلف کاموں میں تقسیم کرتا ہے اور انہیں سونپ دیتا ہے، تو یہ ایک حقیقی ایجنٹ ہے۔
زیادہ تر کامیاب ایجنٹس مخصوص کاموں کے لیے ہوتے ہیں۔ وہ ایک کام اچھے طریقے سے کرتے ہیں۔ وہ کسٹمر سپورٹ ٹریاج (triage) یا دستاویزات کے اخراج (document extraction) کو سنبھالتے ہیں۔ وہ عمومی استدلال کرنے والے انجن (general reasoning engines) نہیں ہوتے۔
کامیاب ٹیمیں ان تین چیزوں پر توجہ دیتی ہیں:
- ٹول ڈیزائن: انٹرفیس کتنا صاف ستھرا ہے؟
- ناکامی کو سنبھالنا: جب کوئی ٹول کچھ واپس نہ کرے تو کیا ہوتا ہے؟
- مشاہدہ (Observability): کیا آپ یہ معلوم کر سکتے ہیں کہ ایجنٹ نے کوئی فیصلہ کیوں کیا؟
ناکام ٹیمیں صرف ایک ماڈل کو نئے ماڈل سے بدل دیتی ہیں اور بہتر نتائج کی توقع کرتی ہیں۔ وہ سسٹم ڈیزائن کو نظر انداز کر دیتی ہیں۔
LangChain یا CrewAI جیسے فریم ورکس ہر ماہ بدل جاتے ہیں۔ فریم ورک سے زیادہ اہمیت پیٹرن (pattern) کی ہوتی ہے۔
ان پیٹرنز کا استعمال کریں:
- پہلے منصوبہ بنائیں پھر عمل کریں: استدلال (reasoning) کے مرحلے کو عمل درآمد (execution) کے مرحلے سے الگ کریں۔
- معلومات نکالنے (retrieval) کو استدلال سے الگ رکھیں: سیاق و سباق (context) حاصل کرنا اسے استعمال کرنے سے مختلف کام ہے۔
- واضح ہینڈ آف (handoffs): جب ایک ایجنٹ دوسرے کو کام سونپے تو اسٹرکچرڈ لاگز (structured logs) کا استعمال کریں۔
فریم ورک صرف ڈھانچہ (scaffolding) ہے۔ آرکیٹیکچر اصل عمارت ہے۔
RAG ایک معیار ہے، لیکن چنکنگ (chunking) اکثر غلط ہوتی ہے۔ اگر آپ دستاویزات کو غلط طریقے سے تقسیم کرتے ہیں، تو ماڈل سیاق و سباق کھو دیتا ہے۔ اس سے ہالوسینیشن (hallucinations) کا سامنا کرنا پڑتا ہے۔
اگر آپ کے RAG کے نتائج بیکار ہیں، تو اپنی چنکنگ اور میٹا ڈیٹا (metadata) کو چیک کریں۔ مسئلہ شاذ و نادر ہی ماڈل کا ہوتا ہے۔
ماڈلز بہتر ہوں گے۔ کانٹیکسٹ ونڈوز بڑھیں گی۔ ٹوکن کی قیمتیں کم ہوں گی۔
ان میں سے کوئی بھی چیز اصل انجینئرنگ کے چیلنج کو حل نہیں کرتی۔ آپ کو ایسے سسٹم بنانے ہوں گے جو آپ کی غیر موجودگی میں بھی درست طریقے سے کام کریں۔
گورننس (governance)، مشاہدہ (observability) اور قابل اعتماد ٹول کے استعمال پر توجہ دیں۔ بہترین انجینئرز ماڈل کے محققین نہیں ہوں گے۔ وہ سسٹم ڈیزائنرز ہوں گے جو قابل اعتماد AI بنائیں گے۔
Context Windows بہت بڑی ہو رہی ہیں: یہاں بتایا گیا ہے کہ یہ سب کچھ کیوں بدل دیتا ہے
ایک Large Language Model (LLM) کی context window بنیادی طور پر اس کی short-term memory ہے۔ یہ اس معلومات کی مقدار ہے جسے ماڈل جواب تیار کرتے وقت 'ذہن میں رکھ' سکتا ہے۔
تاریخی طور سے، context windows کافی چھوٹی تھیں۔ آپ شاید 4k، 8k، یا شاید 32k token limits والے ماڈلز کے عادی رہے ہوں گے۔ اگر آپ کسی پوری کتاب یا ایک بہت بڑے codebase کے بارے میں بات کرنا چاہتے تھے، تو آپ کو ماڈل کو صرف سب سے زیادہ متعلقہ ٹکڑے فراہم کرنے کے لیے RAG (Retrieval-Augmented Generation) کا استعمال کرنا پڑتا تھا۔
لیکن چیزیں تیزی سے بدل رہی ہیں۔ Gemini 1.5 Pro جیسے ماڈلز کے ساتھ، جو 2 ملین ٹوکنز تک کی context windows پیش کرتے ہیں، کھیل بنیادی طور پر بدل رہا ہے۔
یہ کیوں اہم ہے
- RAG اب واحد راستہ نہیں ہے: پیچیدہ vector databases اور retrieval pipelines بنانے کے بجائے، آپ بعض اوقات پوری documentation یا codebase کو براہ راست prompt میں ڈال سکتے ہیں۔
- بہتر Reasoning: جب ایک ماڈل مکمل context دیکھ سکتا ہے، تو وہ input کے دور دراز حصوں کے درمیان ایسے تعلقات بنا سکتا ہے جو RAG شاید مس کر دے۔
- سادہ Workflows: ڈویلپرز ڈیٹا انجینئرنگ پر کم وقت اور prompt engineering پر زیادہ وقت صرف کر سکتے ہیں۔
"Needle in a Haystack" ٹیسٹ
بڑی context windows کی صلاحیت کو جانچنے کے لیے "Needle in a Haystack" ٹیسٹ کا استعمال کیا جاتا ہے۔ اس میں ماڈل کو ایک بہت بڑے ڈیٹا سیٹ (haystack