ডেভেলপাররা যখন লোকাল লার্জ-ল্যাঙ্গুয়েজ মডেল (LLM) ব্যবহার করেন, তখন তারা দেখতে পান যে একটি মাত্র মাল্টি-চ্যানেল-প্রোটোকল (MCP) সার্ভার ব্যবহারকারীর প্রম্পট টাইপ করার আগেই পুরো কনটেক্সট উইন্ডো (context window) দখল করে নিতে পারে। তাদের হয় টুল ডেসক্রিপশন বা বর্ণনা ছোট করে দিতে হচ্ছে অথবা কথোপকথনের প্রবাহ নষ্ট করতে হচ্ছে।

লোকাল LLM-এর জন্য কেন টোকেন ব্লোট (token bloat) গুরুত্বপূর্ণ

MCP একটি LLM-কে এক্সটার্নাল টুল—যেমন API, স্ক্রিপ্ট বা ফাইল-সিস্টেম ইউটিলিটি—ব্যবহার করার সুযোগ দেয়, যেখানে প্রতিটি টুলের একটি বর্ণনা মডেলকে প্রদান করা হয়। ১২৮k-টোকেন উইন্ডো সম্পন্ন ক্লাউড-হোস্টেড মডেলগুলো অনেকগুলো টুলের সংজ্ঞা গ্রহণ করতে পারে এবং তবুও ব্যবহারকারীর সংলাপে পর্যাপ্ত জায়গা রাখে। কিন্তু একটি ৭-বিলিয়ন প্যারামিটার বিশিষ্ট লোকাল মডেল, যার উইন্ডো মাত্র ৮k-টোকেন, মাত্র কয়েকটি টুল লোড করার পরেই জায়গা হারিয়ে ফেলে। এখানে একটি কঠিন ভারসাম্য বজায় রাখতে হয়: ছোট এবং সস্তা বর্ণনাগুলো ভুল কল (call) করতে পারে; অন্যদিকে দীর্ঘ এবং বিস্তারিত বর্ণনা চ্যাটের জন্য প্রয়োজনীয় বাজেট শেষ করে দেয়।

এই পরিস্থিতির পেছনে যে ঘটনাপ্রবাহ কাজ করেছে

MCP তৈরি করা হয়েছিল কাস্টম ইন্টিগ্রেশন কোডের পরিবর্তে অনেকগুলো ডেটা সোর্সের জন্য একটি একক, মডেল-চালিত ইন্টারফেস হিসেবে। বেশিরভাগ MCP সার্ভার মূলত REST এন্ডপয়েন্টের ওপর তৈরি একটি পাতলা র‍্যাপার (thin wrapper), যা মানুষের ব্যবহারের জন্য তৈরি, মেশিনের জন্য নয়। যখন এই র‍্যাপারগুলো একটি লোকাল LLM সেশনে ব্যবহৃত হয়, তখন মডেলটিকে কোন টুলটি ব্যবহার করতে হবে তা সিদ্ধান্ত নেওয়ার আগে প্রতিটি টুলের নাম, প্যারামিটার এবং ব্যবহারের নোটগুলো পড়তে হয়। ছোট কনটেক্সট উইন্ডো এই "ডেসক্রিপশন ওভারহেড"-কে একটি কাঠামোগত বাধার (structural bottleneck) পরিণত করে।

কারা লাভবান হচ্ছে, কারা ক্ষতিগ্রস্ত হচ্ছে

  • অন-ডিভাইস অ্যাসিস্ট্যান্ট তৈরি করা ডেভেলপাররা নমনীয়তা হারান। তারা হয় টুল ক্যাটালগ ছোট করে ফেলেন, যা ঘন ঘন ব্যর্থতার ঝুঁকি তৈরি করে, অথবা একটি অতিরিক্ত বড় প্রম্পট গ্রহণ করেন যা ব্যবহারকারীর ইনপুটকে ছোট করে দেয়।
  • সাধারণ ব্যবহারকারীরা অ্যাসিস্ট্যান্ট যখন ভুল টুল নির্বাচন করে বা কনটেক্সট পূর্ণ থাকার কারণে কাজ করতে অস্বীকার করে, তখন অস্থিতিশীল আচরণ লক্ষ্য করেন।
  • টুল প্রোভাইডাররা একটি ইউনিফর্ম এন্ট্রি পয়েন্ট বা অভিন্ন প্রবেশপথ পায়।

এই খরচ কেবল একটি খারাপ অভিজ্ঞতা নয়; এটি নিরাপত্তার উদ্বেগও বাড়ায়। যখন একটি MCP এজেন্ট যেকোনো লোকাল ফাইল পড়তে পারে, তখন পারমিশন মডেলটি "সব অথবা কিছুই না" (all-or-nothing) মডেলে পর্যবসিত হয়। কোনো স্যান্ডবক্স (sandbox) না থাকলে, একটি ভুলভাবে কনফিগার করা টুল পুরো ফাইলসিস্টেম উন্মুক্ত করে দিতে পারে।

ডেভেলপাররা এটি মোকাবিলায় কী করছেন

তিনটি বিকল্প সমাধান কমিউনিটিতে প্রাধান্য পাচ্ছে:

  • ডেসক্রিপশন ছোট করা (Trim descriptions) – টুলের মেটাডেটা একদম ন্যূনতম পর্যায়ে নামিয়ে আনা। এটি টোকেন সাশ্রয় করে কিন্তু মডেলটি ভুল এন্ডপয়েন্ট বেছে নেওয়ার সম্ভাবনা বাড়িয়ে দেয়, যার ফলে ডেভেলপারদের ভুল শনাক্ত করতে হয় এবং পুনরায় চেষ্টা করতে হয়।
  • ডায়নামিক লোডিং (Dynamic loading) – বর্তমান কথোপকথনের জন্য প্রাসঙ্গিক টুলের একটি নির্দিষ্ট অংশ মাত্র লোড করা। একটি হালকাওয়েট ডিসপ্যাচার ব্যবহারকারীর উদ্দেশ্য অনুযায়ী কোন টুল সেটটি ইনজেক্ট করা হবে তা নির্ধারণ করে। এটি অব্যবহৃত টোকেন ব্যবহার কমায় কিন্তু ল্যাটেন্সি (latency) এবং কোডের জটিলতা বাড়ায়।
  • সক্রিয় সার্ভারের সংখ্যা সীমিত করা (Limit active servers) – প্রতিটি সেশনে MCP সার্ভারের সংখ্যা নির্দিষ্ট করে দেওয়া, যা ডেভেলপারদের সবচেয়ে প্রয়োজনীয় ইন্টিগ্রেশনগুলোকে অগ্রাধিকার দিতে বাধ্য করে। এটি প্রম্পটের আকার নিয়ন্ত্রণযোগ্য রাখে কিন্তু সক্ষমতার পরিধি কমিয়ে দেয়।

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

টোকেন সমস্যার সাথে যুক্ত নিরাপত্তা ঝুঁকিগুলো

লোকাল এজেন্টগুলো প্রায়শই অবাধ ফাইল-সিস্টেম অ্যাক্সেস নিয়ে চলে। MCP প্রোটোকল "এই ফোল্ডারটি পড়ুন" এবং "সবকিছু পড়ুন" এর মধ্যে কোনো সূক্ষ্ম পার্থক্য বা গ্র্যানুলারিটি (granularity) প্রদান করে না। কিছু টিম এই ফুল-অ্যাক্সেস সমস্যা সমাধানের জন্য গেটওয়ে লেয়ার তৈরি করেছে, যা আরও জটিলতা যোগ করে। এই গেটওয়েগুলো "ফুল-কন্ট্রোল" সমস্যা কিছুটা প্রশমিত করলেও কোডবেস বাড়িয়ে দেয়।

ছোট মডেলের জন্য টুল ডিজাইন করা

বড় ক্লাউড মডেলগুলো ভুল ডেসক্রিপশন থেকেও ঠিক হয়ে যেতে পারে, তাই ডেভেলপাররা অনেক সময় সুনির্দিষ্ট টুল সংজ্ঞার প্রয়োজনীয়তা উপেক্ষা করেন। লোকাল মডেলের ক্ষেত্রে নিচের নীতিগুলো অনুসরণ করুন:

  • সংকীর্ণ কার্যকারিতা (Narrow functionality) – প্রতিটি টুলের একটি মাত্র কাজ থাকা উচিত। একটি "সার্চ" টুল যা ফাইলও লিখতে পারে, তা এমন একটি মডেলকে বিভ্রান্ত করবে যা ওভারল্যাপিং দায়িত্ব ট্র্যাক করতে পারে না।
  • অস্পষ্টতাহীন নামকরণ (Unambiguous naming) – "process" বা "handle"-এর মতো সাধারণ নাম এড়িয়ে চলুন। নামগুলো যেন সঠিক অপারেশন বা কাজ প্রকাশ করে, যা মডেলের মানসিক চাপ (mental load) কমায়।
  • স্পষ্ট ও সংক্ষিপ্ত বর্ণনা (Clear, concise descriptions) – মডেলটি সিদ্ধান্ত নেওয়ার জন্য সত্যিই যে প্যারামিটারগুলোর প্রয়োজন, কেবল সেগুলোই অন্তর্ভুক্ত করুন। একটি সুসংগত ফরম্যাট ব্যবহার করুন যাতে মডেলটি দ্রুত প্যাটার্ন চিনতে পারে।

পাল্টা যুক্তি: প্রোটোকলটির তবুও গুরুত্ব রয়েছে

বাধা থাকা সত্ত্বেও, MCP আকর্ষণীয় কারণ এটি বয়েলারপ্লেট কোড (boilerplate code) থেকে মুক্তি দেয়। একটি একক, মডেল-চালিত ইন্টারফেস প্রতিটি সার্ভিসের জন্য আলাদা কাস্টম অ্যাডাপ্টার না লিখেই ডজন ডজন সার্ভিসের সাথে যুক্ত হতে পারে। যেসব টিম ক্লাউড-স্কেল মডেল ব্যবহারের সামর্থ্য রাখে, তাদের কাছে টোকেন ব্লোট কোনো সমস্যা নয় এবং এর সুবিধাগুলো ওভারহেডের চেয়ে বেশি। চ্যালেঞ্জ হলো সেই সুবিধাকে অন-ডিভাইস LLM-এর সীমাবদ্ধ জগতে নিয়ে আসা।

সারসংক্ষেপ

আপনি যদি একটি on-device assistant তৈরি করেন, তবে MCP tool descriptions-কে একটি সীমিত সম্পদ হিসেবে বিবেচনা করুন। মূল কথোপকথনের জন্য context window সচল রাখতে এগুলোকে ছোট করুন, ডায়নামিকভাবে লোড করুন এবং narrowly scoped tools ডিজাইন করুন। একই সাথে, কিছু অতিরিক্ত tokens খরচ হলেও একটি permission layer যুক্ত করার মাধ্যমে অন্তর্নিহিত “full-access” security model থেকে সুরক্ষা নিশ্চিত করুন। আপনি যে ভারসাম্য বজায় রাখবেন, তা-ই নির্ধারণ করবে আপনার local LLM একটি সহায়ক সঙ্গী হিসেবে কাজ করবে নাকি একটি ত্রুটিপূর্ণ chatbot হিসেবে।