ایجنٹ پر مبنی نظام کے ڈیزائن کے عملی اصول

• اپنے ایجنٹ پر مبنی نظام میں یہ بات احتیاط سے طے کرنا ضروری ہے کہ فیصلے کیسے اور کہاں کیے جائیں.

• زیادہ فیصلے LLM کے سپرد کرنے سے نظام مزید کاموں کے لیے کارآمد بن سکتا ہے، لیکن اس سے رفتار، قابلِ اعتماد ہونے اور مضبوطی پر منفی اثر پڑ سکتا ہے.

• جہاں ممکن ہو، فیصلہ سازی کے زیادہ سے زیادہ عمل کو LLM سے نکال کر واضح سافٹ ویئر کوڈ میں منتقل کریں. یہ بات بالخصوص زیادہ خطرے والے اور پیداواری عملی مراحل پر لاگو ہوتی ہے.

LLM پر مبنی ایجنٹ نظام بناتے وقت ایک اہم فیصلہ یہ ہوتا ہے کہ فیصلہ سازی کس حد تک LLM ماڈل میں رکھی جائے اور کس حد تک واضح سافٹ ویئر میں.

اس انتخاب کو سمجھنے کے لیے ہم اسے درج ذیل طریقوں کے درمیان ایک تسلسل سمجھ سکتے ہیں:

• راؤٹر پر مبنی ساختیں ترتیب اور منطق کو کوڈ میں واضح طور پر متعین کرتی ہیں، جس سے محدود دائرۂ کار والے کاموں میں جانچ، پیش گوئی اور مضبوطی یقینی بنتی ہے۔ انہیں ”عملی مراحل کے ایجنٹس“ بھی کہا جاتا ہے.

• آرکیسٹریٹر ایجنٹس فطری زبان کی ہدایات کے ذریعے کام کی روانی متحرک طور پر طے کرنے کے لیے بڑے لسانی ماڈلز (LLMs) پر انحصار کرتے ہیں۔ یہ ان کھلے تعاملات کے لیے موزوں ہیں جہاں پہلے سے طے شدہ منطق ناکافی یا ناممکن ہو.

زیادہ خطرے والے پیداواری عملی مراحل کے لیے ہم عموماً راؤٹر پر مبنی خصوصیات زیادہ استعمال کرنے اور آرکیسٹریٹرز کو ایسی اطلاقات تک محدود رکھنے کی تجویز دیتے ہیں جن میں لچک دار اور عمومی نوعیت کی گفتگو درکار ہو.

راؤٹر پر مبنی ساختیں

راؤٹر پر مبنی ایجنٹ نظام:

• فیصلہ سازی کی روانی کو کوڈ یا سافٹ ویئر میں واضح طور پر متعین کرتے ہیں اور یہ طے کرنے کے لیے LLM استعمال کرتے ہیں کہ سافٹ ویئر کون سا راستہ اختیار کرے.

• یہ روایتی سافٹ ویئر نظاموں سے زیادہ مشابہ ہوتے ہیں، کیونکہ ان کے راستے واضح اور قابلِ پیش گوئی ہوتے ہیں اور نتائج میں زیادہ یکسانیت آتی ہے.

• یہ ان کاموں کے لیے مثالی ہیں جنہیں سختی سے متعین کیا جا سکتا ہو.

ذیل میں ”راؤٹر طریقہ“ استعمال کرنے والے فضائی کمپنی کے بکنگ چیٹ بوٹ ایجنٹ کی ایک سادہ فرضی مثال ہے۔ LLM سوال کا مقصد تین ممکنہ انتخابات میں سے درجہ بند کرنے میں مدد دیتا ہے، لیکن بالآخر ہمارا سافٹ ویئر ہی اس مقصد کو سانچے میں موجود متنی جواب سے جوڑتا ہے. چونکہ LLM پر سخت پابندیاں ہیں، اس لیے صارف کو زیادہ یکساں طرزِ عمل نظر آئے گا.

آرکیسٹریٹر ساختیں

راؤٹر نظام کے برعکس، آرکیسٹریٹر پر مبنی ایجنٹ نظام:

• سافٹ ویئر کے بجائے فطری زبان کی ہدایات کے ذریعے منطقی روانی متعین کرتے ہیں. نوٹ: پروگرامنگ زبان کے مقابلے میں فطری زبان بنیادی طور پر مبہم اور لچک دار ہوتی ہے۔ یہ مثبت اور منفی، دونوں خصوصیات ہیں جن پر ہم آگے بات کریں گے. ہم اسے ”ہدایت کے بجائے مقصد“ کہتے ہیں.

• یہ عمل کاری کے متعدد اختیارات دے سکتے ہیں، جبکہ LLM عمل درآمد کی ترتیب اور طریقۂ کار طے کرتا ہے.

• یہ متحرک طور پر نئے منطقی راستے بنا سکتے ہیں جنہیں سافٹ ویئر میں واضح طور پر متعین کرنا مشکل ہوتا ہے.

• یہ ابہام غیر یکساں نتائج پیدا کر سکتا ہے، لیکن درست کام کرنے پر یہ ”جادوئی“ محسوس ہو سکتا ہے.

درج ذیل مثال میں فضائی کمپنی کے اسی سادہ فرضی مسئلے پر آرکیسٹریٹر طریقہ لاگو کیا گیا ہے. مناسب جواب کا فیصلہ سافٹ ویئر سے کرانے کے بجائے فیصلہ سازی LLM کی سطح کے سپرد کر دی جاتی ہے. یہاں ایک کثیر ایجنٹ نظام ہے جس میں ایک ”مرکزی“ آرکیسٹریٹر ایجنٹ صارف کے سوال کی ابتدائی جانچ کرکے اسے پرواز تبدیل کرنے کے لیے خاص طور پر بنائے گئے ایجنٹ کے سپرد کرتا ہے، جو آخرکار صارف کو جواب دیتا ہے.

اس مثال میں LLM کی سطح درجہ بندی کرنے والے، راؤٹر اور جواب لکھنے والے کا کردار ادا کر رہی ہے. راؤٹر کی مثال میں یہ صرف درجہ بندی کرنے والے کا کردار ادا کر رہی تھی، جبکہ باقی کام سافٹ ویئر سنبھال رہا تھا.

جہاں ممکن ہو، ہم راؤٹر پر مبنی طریقے استعمال کرنے کی تجویز دیتے ہیں، کیونکہ ان کے درج ذیل فوائد ہیں:

• رفتار اور کارکردگی: مقامی حسابی عمل، بیرونی API پر منحصر آرکیسٹریٹرز کے مقابلے میں زیادہ تیز ہوتے ہیں. اپنی ‘IF/ELSE’ منطق کو python میں چلانا بھی اس سے کہیں سستا ہے کہ اسے 400 ارب پیرامیٹر والے ماڈل سے گزارنے کے لیے کسی LLM فراہم کنندہ کو ادائیگی کی جائے.

• جانچ اور پیش گوئی: مروجہ سافٹ ویئر طریقوں سے خامیاں تلاش کرنا، جانچ کرنا اور دیکھ بھال کرنا خاصا آسان ہوتا ہے.

• شفافیت اور قابلِ اعتماد ہونا: طرزِ عمل میں کم تغیر سے مسائل کی تشخیص آسان ہو جاتی ہے. اطلاق کی روانی کا بڑا حصہ شفاف اور نسخہ جاتی کنٹرول والے سافٹ ویئر میں بھی ظاہر ہوتا ہے، نہ کہ LLM کے غیر شفاف اور ناقابلِ تشریح وزنوں میں.

راؤٹر طریقوں کے نقصانات یہ ہیں کہ وہ سخت اور غیر لچک دار ہو سکتے ہیں اور زیادہ کھلے مسائل سے نمٹنے میں مشکل محسوس کر سکتے ہیں. ہمیشہ بالکل ایک جیسے جواب دینے والا چیٹ بوٹ صارفین کو اکتا دینے والا یا جمود کا شکار لگ سکتا ہے.

آرکیسٹریٹر ڈیزائن میں طاقتور صلاحیتیں ہوتی ہیں:

1. منصوبہ بندی: یہ متحرک طور پر جوابات کی منصوبہ بندی کر سکتے ہیں.

2. آلے کا انتخاب یا ایجنٹ کو منتقلی: مناسب آلات منتخب کر سکتے یا کام ایجنٹس کے سپرد کر سکتے ہیں.

3. نتائج کا تکراری امتزاج: نتائج کو بار بار بہتر بنا کر تخلیقی انداز میں دوبارہ ملا سکتے ہیں.

4. تکمیل کا تعین: طے کر سکتے ہیں کہ جواب کو حتمی شکل دینے کے لیے کافی معلومات جمع ہو چکی ہیں یا نہیں.

Pydantic-AI یا OpenAI کے Agents SDK جیسے فریم ورک آرکیسٹریشن کو آسان اور فوری قابلِ نفاذ بناتے ہیں. اس لیے یہ عملی نمونوں یا تصور کے ثبوت کے لیے بہترین ہے.

اس طریقے کے نقصانات یہ ہیں:

• اس بات کی کوئی ضمانت نہیں کہ LLM کی منصوبہ بندی کے مراحل اور بعد کی کارروائیاں درست یا مناسب ہوں گی. راؤٹر نظام میں بھی یہی مسئلہ ہے، لیکن زیادہ پابند ہونے کی وجہ سے اس کا طرزِ عمل زیادہ قابلِ پیش گوئی ہے.

• سادہ اور واضح طور پر متعین کاموں کے لیے عموماً کثیر ایجنٹ نظام کی مکمل صلاحیت درکار نہیں ہوتی. مثلاً فضائی کمپنی کے ایجنٹ کی ہماری مثال میں غالباً سوالات کی صرف چند اقسام ہوں گی جن سے فضائی کمپنی کے معاونتی نظام کا صارف واقعی متعلقہ کارروائی کرنا چاہے گا.

• چونکہ زیادہ منطق LLM میں ہوتی ہے، اس لیے بدنیت افراد کے لیے اسے جیل بریک کرنا یا اس کا ناجائز فائدہ اٹھانا کہیں آسان ہوتا ہے.

• یہ فیصلہ سازی کو LLM میں پوشیدہ کر دیتا ہے، اس لیے نظام کو سمجھنا مشکل ہو جاتا ہے، اگرچہ Langfuse یا Braintrust جیسے نگرانی کے آلات جزوی مدد دے سکتے ہیں.

قاری کے لیے نوٹ: اگرچہ ماڈل کی صلاحیت تیزی سے بدل رہی ہے، لیکن درج ذیل باتوں کے مستقبل قریب میں بدلنے کا امکان کم ہے.

اپنے مسئلے کا دائرۂ کار طے کریں.

• کیا آپ اپنی مطلوبہ فیصلہ سازی کی منطق کو کسی خاکے میں آسانی سے واضح کر سکتے ہیں؟

• کیا آپ کے اطلاق میں ناکامی یا غیر متوقع طرزِ عمل ناقابلِ قبول ہے؟

مندرجہ بالا میں سے کسی ایک کا جواب ”ہاں“ ہو تو راؤٹر کی خصوصیات زیادہ موزوں ہوں گی.

جہاں تک ممکن ہو، ہم راؤٹر طریقے استعمال کرنے کی تجویز دیتے ہیں۔ عمومی اصول یہ ہے کہ اگر نظام کے کسی حصے کو کوڈ میں ظاہر کیا جا سکتا ہو تو اسے کوڈ ہی میں لکھیں، یعنی ضرورت نہ ہونے پر LLMs کا حد سے زیادہ استعمال نہ کریں.

جہاں ان طریقوں کی حدود آ جائیں، وہاں آرکیسٹریٹر کے بعض کھلے فوائد کو پابند انداز میں نقل کیا جا سکتا ہے. مثلاً:

1. آلے کا انتخاب یا ایجنٹ کو منتقلی: اسے مشروط شاخ بندی یا LLM درجہ بند کنندگان کے ذریعے آسانی سے نافذ کیا جا سکتا ہے.

2. تکمیل کا تعین: سادہ LLM درجہ بند کنندگان صارف کو جواب بھیجنے سے پہلے اس کی تکمیل جانچ سکتے ہیں.

البتہ سخت راؤٹر نظام میں ”منصوبہ بندی“ اور ”نتائج کا تکراری امتزاج“ حاصل کرنا بلاشبہ کہیں زیادہ مشکل ہے. اس لیے جب کسی کام کو ان کی ضرورت ہو، جس کا تعین LLM درجہ بند کنندہ یا کسی دوسری منطق سے کیا جائے، تو ہم نظام میں کم پابندی والی آرکیسٹریٹر شاخ بنانے کی تجویز دیتے ہیں.

راؤٹر اور آرکیسٹریٹر ساختوں میں آپ کا انتخاب اطلاق کی وضاحت، پیچیدگی اور تعامل کے انداز کے مطابق ہونا چاہیے. فی الحال راؤٹر پر مبنی طریقے واضح طور پر متعین کاموں کے لیے قابلِ اعتماد کارکردگی، مؤثریت اور آسان جانچ فراہم کرتے ہیں. وسیع اور مکالماتی تعاملات کے لیے آرکیسٹریٹرز زیادہ لچک فراہم کرتے ہیں.

LLMs کی مسلسل ترقی کے ساتھ ان طریقوں کے درمیان توازن بدل سکتا ہے. پیداواری کاموں کے لیے ہم راؤٹر پر مبنی یا مخلوط ساختوں کو ترجیح دیتے ہیں اور آرکیسٹریٹرز کو ایسے کھلے مسائل کے لیے محفوظ رکھتے ہیں جن میں متحرک اور انسان جیسا تعامل درکار ہو.