কেন আমরা ৯৬% টোকেন সাশ্রয় প্রত্যাখ্যান করেছি

আমরা এমন একটি MCP সার্ভার খুঁজে পেয়েছি যা টোকেন ব্যবহারে ৯৬% সাশ্রয় করে। এটি একটি মাত্র টুল ব্যবহার করে: execute_code। নির্দিষ্ট ফাংশন কল করার পরিবর্তে, এজেন্ট ডেটা সংগ্রহের জন্য JavaScript লিখে ফেলে।

কাগজে-কলমে এটি সেরা। জটিল কাজের ক্ষেত্রে, দক্ষতার দিক থেকে কোড এক্সিকিউশন টুল-কলিং-কে ছাড়িয়ে যায়।

কিন্তু আমরা এটি গ্রহণ করিনি। পরিবর্তে আমরা আমাদের আলাদা, নামযুক্ত টুলগুলোই রেখে দিয়েছি।

কেন আপাতদৃষ্টিতে সঠিক মনে হওয়া সিদ্ধান্তটি আমাদের এজেন্টের জন্য ভুল ছিল, তা নিচে দেওয়া হলো।

লক্ষ্য নির্ধারণই ডিজাইন ঠিক করে দেয়

বেশিরভাগ মানুষ চ্যাট উইন্ডোতে ফ্রন্টিয়ার মডেলগুলোর (frontier models) জন্য সিস্টেম তৈরি করেন। সেই মডেলগুলোর টোকেন বাজেট অনেক বেশি থাকে। তাদের জন্য কোড এক্সিকিউশনই হলো সেরা সমাধান।

আমরা একটি নৌকায় থাকা ছোট লোকাল মডেলের (Hermes 3 8B) জন্য একটি ভয়েস-ফার্স্ট (voice-first) এজেন্ট তৈরি করছি।

একটি ছোট মডেলের ক্ষেত্রে সীমাবদ্ধতা টোকেন নয়। সীমাবদ্ধতা হলো নির্ভরযোগ্যতা (reliability)।

একটি ছোট মডেল যদি একটি সাধারণ টুল কল করতে হিমশিম খায়, তবে তাকে সঠিক JavaScript লিখতে বলা আরও কঠিন কাজ। execute_code টোকেন সাশ্রয়ের জন্য নির্ভরযোগ্যতা বিসর্জন দেয়। আমরা সেই ঝুঁকি নিতে পারি না।

লাস্ট-মাইল সমস্যা (The Last-Mile Problem)

কোড এক্সিকিউশন কাজের "লাস্ট মাইল" বা শেষ ধাপের দায়িত্ব এজেন্টের ওপর চাপিয়ে দেয়। এজেন্টকে অবশ্যই:

• ডেটা ফিল্টার করতে হবে
• ফলাফলগুলো সাজাতে হবে
• আউটপুট ফরম্যাট করতে হবে

আমাদের টুলগুলো সার্ভারের ভেতরেই এই কাজগুলো করে ফেলে। উদাহরণস্বরূপ, ব্যাটারির অবস্থা সম্পর্কে জিজ্ঞাসা করলে, আমাদের টুলটি টেক্সট-টু-স্পিচ (text-to-speech)-এর জন্য প্রস্তুত একটি স্ট্রিং রিটার্ন করে। এটি কাঁচা সংখ্যার পরিবর্তে বলে, "৬৮ শতাংশ, ১২.৮ ভোল্ট"।

যদি আমরা execute_code ব্যবহার করি, তবে এজেন্টকে সেই কথাটি ফরম্যাট করার লজিক লিখতে হবে। ছোট মডেলগুলো এই কাজে ক্রমাগত ব্যর্থ হয়।

অনুপস্থিতির নিয়ম (The Absence Rule)

একটি নৌকায় সেন্সরগুলো অফলাইনে চলে যেতে পারে। আমাদের সিস্টেমে, কোনো সেন্সর না থাকলে সেটি একটি পরিষ্কার null রিটার্ন করে। এটি একটি সফল কল হিসেবে গণ্য হয়।

কোড এক্সিকিউশন মডেলে, কোনো সেন্সর না থাকলে প্রায়ই এরর (error) দেখায়। যদি একটি ছোট মডেল ভুল পথে কিছু অনুমান করে, তবে তা এরর লিমিট অতিক্রম করে এবং এজেন্টকে অচল করে দেয়। নামযুক্ত টুলগুলো আমাদের অনুপস্থিতিকে একটি ত্রুটি নয়, বরং একটি সাফল্য হিসেবে গণ্য করার সুযোগ দেয়।

গ্রহণ বনাম তৈরির চেকলিস্ট (Adopt-vs-Build Checklist)

আপনি কোনো MCP সার্ভার গ্রহণ বা তৈরির আগে এই প্রশ্নগুলো করুন:

• টার্গেট এজেন্ট কে? (ফ্রন্টিয়ার মডেল বনাম ছোট লোকাল মডেল) • প্রধান সীমাবদ্ধতা কী? (টোকেন বনাম নির্ভরযোগ্যতা) • লাস্ট মাইল বা শেষ ধাপের কাজ কে করে? (টুল কি ডেটা ফরম্যাট করে নাকি এজেন্ট?) • এটি অনুপস্থিতি কীভাবে হ্যান্ডেল করে? (একটি অনুপস্থিত মান কি এরর নাকি null?) • রক্ষণাবেক্ষণ খরচ কত? (আপনি কি একটি অচল কোডবেস উত্তরাধিকার হিসেবে পাচ্ছেন?)

আমরা অন্য প্রজেক্টটিকে অবহেলা করিনি। আমরা সেখান থেকে ধারণাগুলো গ্রহণ করেছি। আমরা তাদের অ্যালার্ম হ্যান্ডলিং এবং পাথ ডিসকভারি লজিক নিয়ে আমাদের রোডম্যাপে যুক্ত করেছি।

দক্ষতা চমৎকার, কিন্তু যখন আপনি পানির ওপর (নৌকায়) থাকেন, তখন নির্ভরযোগ্যতা অপরিহার্য।

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

Optional learning community: https://t.me/GyaanSetuAi