সবাই AI এজেন্টদের একটি দল তৈরি করতে চায়। ডেমোগুলো দেখতে অত্যন্ত আকর্ষণীয় মনে হয়। একটি এজেন্ট গবেষণা করে, অন্যটি কোড লেখে এবং তৃতীয়টি পরীক্ষা (tests) চালায়। কিন্তু এই সিস্টেমগুলোর বেশিরভাগেরই একটি গোপন দুর্বলতা রয়েছে: সেগুলো অত্যন্ত ভঙ্গুর। পাঁচ মিনিটের ডেমোর সময় এগুলো চমৎকারভাবে কাজ করে কিন্তু বাস্তব অনুসন্ধানের সময় ভেঙে পড়ে। ব্যর্থতার কারণ সাধারণত ল্যাঙ্গুয়েজ মডেলের যুক্তিবোধ বা সোয়ার্মে (swarm) এজেন্টের সংখ্যা নয়। বরং এটি তাদের মধ্যকার ব্যবধান। মাল্টি-এজেন্ট সিস্টেমগুলো কোলাবরেশন প্লেনে (collaboration plane) ভেঙে পড়ে।

সুপারভাইজার ট্র্যাপ

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

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

সমন্বয় ব্যর্থ হলে কী হারিয়ে যায়

যখন একটি অনুসন্ধান গভীর হয়, তখন আপনার কেবল চূড়ান্ত উত্তরের চেয়েও অনেক বেশি কিছু জানার প্রয়োজন হয়। কার কী জানা ছিল এবং কখন জানা ছিল, তা আপনার জানা দরকার। কোন তথ্যটি কাজের দিক পরিবর্তন করেছে, তা ট্র্যাক করা প্রয়োজন। কেন একটি এজেন্ট দুই ঘণ্টা আগে তার পরিকল্পনা পরিবর্তন করেছিল, তা বুঝতে হবে। একটি কোলাবরেশন প্লেন ছাড়া এগুলোর কোনোটিই দৃশ্যমান নয়। আপনার কাছে লগ (logs) থাকে। লগ হলো কালানুক্রমিক শব্দ বা কোলাহল (chronological noise)। সেগুলো রেকর্ড করে যে এজেন্ট C হঠাৎ করে API কলের পরিবর্তে ডাটাবেস ট্রানজ্যাকশন বিশ্লেষণ করা শুরু করেছে, কিন্তু কেন করেছে তা ব্যাখ্যা করে না। আপনি শুধু এটি ঘটতে দেখতে পারেন এবং অনুমান করতে পারেন।

একটি সিকিউরিটি ইনসিডেন্ট রেসপন্সের কথা ভাবুন। এজেন্ট A সার্ভার লগগুলো পরীক্ষা করে সিদ্ধান্ত নেয় যে অনুপ্রবেশ (breach) সেখান থেকে শুরু হয়নি। এটি তার আউটপুট সুপারভাইজারের কাছে ফেরত পাঠায়। এজেন্ট B, যাকে নেটওয়ার্ক ট্রাফিক বিশ্লেষণের দায়িত্ব দেওয়া হয়েছে, সেই সিদ্ধান্তটিকে একটি প্রত্যাখ্যাত হাইপোথিসিস (rejected hypothesis) হিসেবে দেখতে পায় না। যেহেতু এর মূল কাজের বিবরণে সার্ভারকে এখনও প্রধান সন্দেহভাজন হিসেবে দেখা হচ্ছে, তাই এজেন্ট B একই লগে আঙুলের ছাপ খোঁজার জন্য আরও একটি সাইকেল নষ্ট করে। সিস্টেমটি একই কাজের জন্য দুবার মূল্য দেয় এবং প্রথমবার থেকে কিছুই শিখতে পারে না।

কোলাবরেশন প্লেন মানে মেমরি নয়

কোলাবরেশন প্লেন মানে কেবল তথ্যের জন্য একটি মেমরি বাধার (bucket) মতো নয়। মেমরি তথ্য জমা রাখে। কোলাবরেশন স্টেট (collaboration state) চলমান কাজ বা 'work in progress' জমা রাখে। ডকুমেন্ট সমৃদ্ধ একটি ভেক্টর ডাটাবেস এজেন্টকে রেফারেন্স মেটেরিয়াল দেয়। কিন্তু এটি এজেন্টকে জানায় না যে এজেন্ট X বর্তমানে এমন একটি হাইপোথিসিস পরীক্ষা করছে যা এজেন্ট Y-এর বর্তমান কাজটিকে অপ্রয়োজনীয় করে তুলবে। মেমরি হলো একটি স্থির প্রেক্ষাপট (static context)। কোলাবরেশন স্টেট হলো অপারেশনের একটি জীবন্ত মানচিত্র (live map)।

আপনি যদি এই দুটির মধ্যে গুলিয়ে ফেলেন, তবে আপনি এমন সিস্টেম তৈরি করবেন যা আপনার কোম্পানির হ্যান্ডবুকের প্রতিটি অনুচ্ছেদ খুঁজে বের করতে পারে কিন্তু অন্য কোনো এজেন্ট আপনার বর্তমান কাজটিকে অপ্রাসঙ্গিক প্রমাণ করেছে কি না তা বলতে পারে না।

শেয়ারড স্টেটের পাঁচটি বাকেট

একটি প্রকৃত কোলাবরেশন প্লেনের জন্য পাঁচটি নির্দিষ্ট বাকেট প্রয়োজন।

Claims (দাবি)। এগুলো হলো সেই সক্রিয় হাইপোথিসিস যা একটি এজেন্ট পরীক্ষা করছে। একটি জালিয়াতি অনুসন্ধানে, একটি দাবি হতে পারে "অসংগতিটি (anomaly) সপ্তাহান্তের ব্যাচ কাজের সাথে সম্পর্কিত।" প্রতিটি এজেন্টের দেখা উচিত কোন দাবিগুলো খোলা আছে, কোনগুলো পরীক্ষা করা হচ্ছে এবং কে সেগুলো পরিচালনা করছে। ছাড়া