ہم نے 96% ٹوکن کی بچت کو کیوں مسترد کر دیا

ہمیں ایک ایسا MCP سرور ملا جو ٹوکنز میں 96% کی بچت کرتا ہے۔ یہ صرف ایک ٹول استعمال کرتا ہے: execute_code۔ مخصوص فنکشنز کو کال کرنے کے بجائے، ایجنٹ ڈیٹا حاصل کرنے کے لیے JavaScript لکھتا ہے۔

کاغذ پر تو یہ بہتر نظر آتا ہے۔ پیچیدہ کاموں کے لیے، کوڈ ایگزیکیوشن (code execution) کارکردگی کے لحاظ سے ٹول کالنگ (tool-calling) سے بہتر ہے۔

لیکن ہم نے اسے اپنایا نہیں۔ اس کے بجائے ہم نے اپنے الگ الگ، نامزد ٹولز (named tools) کو برقرار رکھا۔

یہاں وجہ بتائی گئی ہے کہ کیوں یہ بظاہر درست انتخاب ہمارے ایجنٹ کے لیے غلط ثابت ہوا۔

ہدف ڈیزائن کا تعین کرتا ہے

زیادہ تر لوگ چیٹ ونڈو میں موجود فرنٹیر ماڈلز (frontier models) کے لیے چیزیں بناتے ہیں۔ ان ماڈلز کے پاس ٹوکنز کا بہت بڑا بجٹ ہوتا ہے۔ ان کے لیے، کوڈ ایگزیکیوشن ہی سب کچھ ہے۔

ہم ایک کشتی پر موجود چھوٹے لوکل ماڈل (Hermes 3 8B) پر مبنی وائس فرسٹ (voice-first) ایجنٹ کے لیے بنا رہے ہیں۔

ایک چھوٹے ماڈل کے لیے، رکاوٹ ٹوکنز نہیں ہیں۔ رکاوٹ بھروسہ مندی (reliability) ہے۔

اگر ایک چھوٹا ماڈل ایک سادہ ٹول کو کال کرنے میں مشکل محسوس کرتا ہے، تو اسے درست JavaScript لکھنے کے لیے کہنا ایک بہت زیادہ مشکل کام ہے۔ execute_code ٹوکنز کے بدلے بھروسہ مندی کا سودا کرتا ہے۔ ہم ایسا سودا نہیں کر سکتے۔

آخری مرحلے کا مسئلہ (The Last-Mile Problem)

کوڈ ایگزیکیوشن کام کے "آخری مرحلے" کا بوجھ ایجنٹ پر ڈال دیتا ہے۔ ایجنٹ کو یہ کرنا پڑتا ہے:

  • ڈیٹا کو فلٹر کرنا
  • نتائج کو ترتیب دینا
  • آؤٹ پٹ کو فارمیٹ کرنا

ہمارے ٹولز یہ کام سرور کے اندر ہی کر لیتے ہیں۔ مثال کے طور پر، بیٹری کی حالت کے بارے میں پوچھنے پر، ہمارا ٹول ٹیکسٹ ٹو اسپیچ (text-to-speech) کے لیے تیار شدہ اسٹرنگ (string) واپس کرتا ہے۔ یہ خام نمبروں کے بجائے "68 فیصد، 12.8 وولٹ" کہتا ہے۔

اگر ہم execute_code استعمال کرتے ہیں، تو ایجنٹ کو اس گفتگو کو فارمیٹ کرنے کے لیے لاجک لکھنی ہوگی۔ چھوٹے ماڈلز اس کام میں مسلسل ناکام رہتے ہیں۔

عدم موجودگی کا اصول (The Absence Rule)

ایک کشتی پر، سینسرز آف لائن ہو جاتے ہیں۔ ہمارے سسٹم میں، ایک غائب شدہ سینسر ایک صاف ستھرا null واپس کرتا ہے۔ یہ ایک کامیاب کال ہے۔

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

اپنانے بمقابلہ بنانے کی چیک لسٹ (Adopt-vs-Build Checklist)

کسی MCP سرور کو اپنانے یا بنانے سے پہلے، یہ سوالات پوچھیں:

• ہدف ایجنٹ کون ہے؟ (فرنٹیر ماڈل بمقابلہ چھوٹا لوکل ماڈل) • بنیادی رکاوٹ کیا ہے؟ (ٹوکنز بمقابلہ بھروسہ مندی) • آخری مرحلہ کون کرتا ہے؟ (کیا ٹول ڈیٹا فارمیٹ کرتا ہے یا ایجنٹ؟) • یہ عدم موجودگی کو کیسے سنبھالتا ہے؟ (کیا غائب شدہ ویلیو ایک ایرر ہے یا null؟) • دیکھ بھال کی لاگت کیا ہے؟ (کیا آپ ایک غیر فعال کوڈ بیس ورثے میں لے رہے ہیں؟)

ہم نے دوسرے پروجیکٹ کو نظر انداز نہیں کیا۔ ہم نے اس کے آئیڈیاز سے فائدہ اٹھایا۔ ہم نے ان کے الارم ہینڈلنگ اور پاتھ ڈسکوری لاجک کو لیا اور انہیں اپنے روڈ میپ میں شامل کر لیا۔

کارکردگی (Efficiency) اچھی ہے، لیکن جب آپ پانی پر ہوں تو بھروسہ مندی (reliability) ضروری ہے۔

ماخذ: https://dev.to/clarkbw--/why-we-kept-named-mcp-tools-despite-a-96-token-saving-40ae

اختیاری لرننگ کمیونٹی: https://t.me/GyaanSetuAi