মাল্টি-এজেন্ট সিস্টেম: সম্ভাবনা যা স্কেলিং-এ গলে যায়
বৃহৎ ভাষা মডেলের উপর ভিত্তি করে মাল্টি-এজেন্ট সিস্টেমের প্রতিশ্রুতি আকর্ষণীয় দেখায়: বেশ কয়েকটি LLM-এজেন্ট একটি বড় কাজ নিজেদের মধ্যে ভাগ করে নিতে পারে, একে অপরের সাথে পরামর্শ করতে পারে এবং একসাথে সমাধান খুঁজে বের করতে পারে। তবে বাস্তবে বিপরীত প্রভাব দেখা যায়: যত বেশি এজেন্ট যৌথ কাজে যুক্ত হয়, সিস্টেম তত কম স্থিতিশীল হয়ে ওঠে। স্বজ্ঞাতভাবে মনে হয় সমস্যাটি সমন্বয়ে, কিন্তু arXiv-এ একটি অবস্থানমূলক নিবন্ধে গবেষকদের একটি দল পরিস্থিতিটিকে আরও গভীরভাবে দেখার প্রস্তাব দেয়।
অনেক ব্যর্থতার মূল কারণ এজেন্টরা সাধারণ অবস্থায় (shared state) কীভাবে প্রবেশ করে তার মধ্যে নিহিত। তাদের প্রত্যেকে সাধারণ ভান্ডারে (স্টোরেজ) ডেটা পড়ে এবং লেখে — নোট, ফলাফল, তথ্যের সংস্করণ। যখন অ্যাক্সেসের সংখ্যা বেড়ে যায়, তখন ক্লাসিক্যাল ডেটা রেস (data race) দেখা দেয়। যদি এটি একটি সাধারণ মাল্টি-থ্রেডেড প্রোগ্রাম হতো, প্রকৌশলীরা সাথে সাথে সিঙ্ক্রোনাইজেশন সমস্যা সন্দেহ করতেন। কিন্তু সিস্টেমের অংশগ্রহণকারীরা 'বুদ্ধিমান' দেখায় বলে, তাদের ভুলগুলো প্রায়ই ভুল বোঝাবুঝি হিসেবে চালিয়ে দেওয়া হয়, যদিও বাস্তবে এটি ভাগ করা সম্পদে সমান্তরাল অ্যাক্সেসের জন্য সাধারণ আচরণ।
দীর্ঘ 'চিন্তা' — দ্বিগুণ বিপজ্জনক
LLM-এজেন্টদের বিশেষত্ব অতিরিক্ত জটিলতা যোগ করে। মডেলের যৌক্তিক অনুমান প্রক্রিয়ায় উল্লেখযোগ্য সময় লাগে, এবং এই পুরো সময় জুড়ে এজেন্টটি সেই অবস্থার স্ন্যাপশট নিয়ে কাজ করে যা সে অনুরোধের মুহূর্তে দেখেছিল। মডেলটি 'চিন্তা' করার সময়, অন্যান্য এজেন্টরা স্থির থাকে না: তারা সাধারণ ডেটা আপডেট করে। প্রস্তুত সমাধান নিয়ে ফিরে এসে, এজেন্টটি বিশ্বের একটি পুরানো চিত্রের উপর নির্ভর করতে পারে।
এজেন্টের সংখ্যা বাড়ার সাথে সাথে এই ধরনের দীর্ঘ চিন্তার উইন্ডো বেশি হয়, এবং এর সাথে বিভিন্ন অসঙ্গতির সম্ভাবনাও বাড়ে। একজন এজেন্ট লক্ষ্য করে না যে সাব-টাস্কটি ইতিমধ্যে একজন সহকর্মী সম্পন্ন করেছে, এবং সে কাজটি নকল করা শুরু করে। দুজন চূড়ান্ত ফলাফল লেখার চেষ্টা করে, এবং শেষ লেখাটি কোনো সতর্কতা ছাড়াই আগেরটি মুছে দেয়। কেউ ডেটা পড়ে যখন অন্য একজন এখনও আপডেট শেষ করেনি, এবং একটি অসামঞ্জস্যপূর্ণ মধ্যবর্তী সংস্করণ পায়। এই সব বিশৃঙ্খলার মতো দেখায়, কিন্তু আসলে এটি ডেটাবেস তত্ত্ব থেকে পরিচিত নিয়ম মেনে চলে — পুরানো রিড (stale reads), হারানো আপডেট (lost updates) এবং অবস্থার অখণ্ডতা লঙ্ঘন।
যোগাযোগ ব্যর্থতাও কেবল একটি ফলাফল
নির্ণয়ে ভুল করা এত সহজ কেন? আসুন সমন্বয় লঙ্ঘন নেওয়া যাক। এজেন্টরা স্পষ্টভাবে ভূমিকা বণ্টন করেছে এবং মনে হয়, কর্মকাণ্ড সমন্বয় করেছে। কিন্তু যদি সাধারণ তথ্যের ভিত্তি (ফ্যাক্ট বেস) নিরন্তর পরিবর্তিত হয়, একজন এজেন্ট এমন একটি অবস্থার উপর ভিত্তি করে কাজ করতে পারে যা সহকর্মী ইতিমধ্যে পুনরায় লিখে ফেলেছে। বাইরে থেকে এটি পরিকল্পনার অসামঞ্জস্য বা নির্দেশাবলীর খারাপ বোঝার মতো দেখায়। তবে মূল কারণ — দুর্বল সমন্বয় নয়, বরং ডেটাতে একযোগে অ্যাক্সেসের উপর নিয়ন্ত্রণের অভাব।
যোগাযোগের ক্ষেত্রেও একই কথা প্রযোজ্য। বার্তাটি নিজেই নিখুঁতভাবে তৈরি এবং সময়মতো পৌঁছে দেওয়া হতে পারে। কিন্তু যদি প্রাপক এটি প্রক্রিয়া করা শুরু করার মুহুর্তে সাধারণ ডেটা ইতিমধ্যে পরিবর্তিত হয়ে থাকে, তাহলে বার্তার অর্থ বিকৃত হয়ে যাবে। এই ধরনের ব্যর্থতা পুনরুত্পাদন করা অত্যন্ত কঠিন: এগুলি সঠিক টাইমিংয়ের উপর নির্ভর করে। যতক্ষণ এজেন্ট কম থাকে, সমস্যাটি প্রায় প্রকাশ পায় না, কিন্তু স্কেলিংয়ের সময় ওভারল্যাপিং অপারেশনের সংখ্যা বাড়ে, এবং ভুলগুলো ভয়ঙ্কর নিয়মিততার সাথে উঠতে শুরু করে।
কনকারেন্সি কন্ট্রোল — প্যাচ নয়, ভিত্তি হিসেবে
গবেষকরা যে সমাধান প্রস্তাব করেন তা ডেটাবেস জগতের প্রমাণিত পদ্ধতিগুলোকে মাল্টি-এজেন্ট সিস্টেমের আর্কিটেকচারে স্থানান্তরের মধ্যে নিহিত। LLM কোনোভাবে 'আলোচনা করে নেবে' এই বিশ্বাসের উপর নির্ভর না করে, প্ল্যাটফর্মের উচিত স্পষ্টভাবে কনকারেন্ট অ্যাক্সেস পরিচালনা করা। বাস্তবে এর অর্থ কাজের তিনটি দিক:
- কনফ্লিক্ট সনাক্তকরণ। সিস্টেম এজেন্টদের একই ডেটা পরিবর্তন করার একযোগে প্রচেষ্টা ট্র্যাক করে এবং সংঘর্ষটি ফলাফল নষ্ট করার আগেই প্রতিরোধ করে।
- আইসোলেশনের নিশ্চয়তা। প্রতিটি এজেন্টকে অবশ্যই অবস্থার একটি সামগ্রিক স্ন্যাপশট নিয়ে কাজ করতে হবে অথবা এমন ব্যবস্থা থাকতে হবে যা অসম্পূর্ণ রেকর্ড পড়তে বাধা দেয়।
- সম্পদে কাঠামোবদ্ধ অ্যাক্সেস। সাধারণ কনটেক্সটে সরাসরি অ্যাক্সেসের পরিবর্তে স্পষ্ট ইন্টারফেস ব্যবহার করা হয়: লক, অপারেশনের সংস্করণ, লেখার জন্য কিউ বা পারমাণবিক (atomic) আপডেট।
লেখকরা জোর দিয়ে বলেন যে, সিস্টেমটি ব্যর্থ হতে শুরু করার পরে কনকারেন্সি কন্ট্রোল যোগ করা যাবে না। এটি অবশ্যই 'দ্বিতীয় তলার' স্তরের একটি আর্কিটেকচারাল সিদ্ধান্ত হতে হবে, যার উপর ভিত্তি করে বাকি সব ডিজাইন দাঁড়াবে। যদি প্রথমে সাধারণ অবস্থার সাথে কাজ করার নিয়মগুলো চিন্তা করা হয়, এবং তারপর তাদের উপর এজেন্টদের সমন্বয় তৈরি করা হয়, তাহলে নির্ভরযোগ্যতার অনেক সমস্যা উঠেই নাও পারে।
উপসংহার
LLM-এর উপর ভিত্তি করে মাল্টি-এজেন্ট সিস্টেমের বিশাল সম্ভাবনা রয়েছে, কিন্তু তাদের দুর্বলতা পৃথক মডেলের দুর্বলতার সাথে সম্পর্কিত নয়, বরং আমরা একাধিক সমান্তরাল নির্বাহককে প্রাথমিক প্রতিরক্ষামূলক ব্যবস্থা ছাড়াই একটি পরিবর্তনশীল অবস্থার সাথে কাজ করতে বাধ্য করার চেষ্টা করছি। ডেটা রেসকে ব্যর্থতার প্রধান উৎস হিসেবে স্বীকার করে, ডেভেলপাররা দীর্ঘদিনের পরিচিত সমাধান — আইসোলেশন, কনফ্লিক্ট সনাক্তকরণ এবং অ্যাক্সেসের ক্রম নির্ধারণ — প্রয়োগ করার সুযোগ পায়। সম্ভবত এটি প্রম্পট উন্নত করার চেয়ে কম চিত্তাকর্ষক, কিন্তু এই পদ্ধতিটিই মাল্টি-এজেন্ট সিস্টেমকে অংশগ্রহণকারীদের সংখ্যা বৃদ্ধির সাথে সাথে নির্ভরযোগ্য থাকতে দেয়।
