प्रत्येकाला AI एजंट्सची एक टीम तयार करायची आहे. त्यांचे डेमो अतिशय आकर्षक वाटतात. एक एजंट संशोधन करतो, दुसरा कोड लिहितो आणि तिसरा चाचण्या (tests) चालवतो. परंतु यातील बहुतेक सिस्टीम्सचे एक गुपित आहे: त्या अत्यंत नाजूक (fragile) आहेत. पाच मिनिटांच्या डेमोमध्ये त्या उत्तम काम करतात, परंतु प्रत्यक्ष तपासणी दरम्यान त्या कोलमडून पडतात. अपयशाचे कारण क्वचितच लँग्वेज मॉडेलची तर्कक्षमता किंवा समूहातील एजंट्सची संख्या असते. ते त्यांच्यामधील अंतर असते. मल्टी-एजंट सिस्टीम्स 'कोलॅबोरेशन प्लेन' (collaboration plane) वर खंडित होतात.
सुपरव्हायझरचा सापळा (The Supervisor Trap)
डिफॉल्ट आर्किटेक्चर अतिशय सोपे आणि मोहक आहे. एक सुपरव्हायझर एजंट ध्येय प्राप्त करतो, त्याचे उपकार्यांमध्ये (subtasks) विभाजन करतो आणि ते वर्कर एजंट्सना सोपवतो. वर्कर एजंट्स ती कामे पूर्ण करतात, निकाल देतात आणि सुपरव्हायझर सर्व गोष्टी एकत्र करून अंतिम उत्तर तयार करतो. जर तुम्ही दहा लेखांचा सारांश काढत असाल, ऑडिओ फाइल्स ट्रान्सक्राइब करत असाल किंवा शंभर सारख्याच वेब पेजेस मधून डेटा काढत असाल, तर ही पद्धत योग्य आहे. ही कामे स्वतंत्र असतात. ती एकमेकांशी संवाद साधत नाहीत.
गुंतागुंतीची तपासणी वेगळी असते. जेव्हा एखादा एजंट एखादा आश्चर्यकारक शोध लावतो, तेव्हा कामाची संपूर्ण दिशा बदलण्याची गरज पडू शकते. जर सिस्टीममध्ये ही दिशा बदलण्याची माहिती प्रसारित करण्यासाठी कोणतीही संरचित पद्धत नसेल, तर इतर एजंट्स चुकीच्या दिशेने काम करत राहतात. यामुळे संवादाऐवजी केवळ समांतर स्वगत्यांचा (monologues) समूह तयार होतो. सुपरव्हायझर समन्वयाऐवजी अडथळा (bottleneck) बनतो.
समन्वय बिघडल्यास काय हरवते?
जेव्हा तपासणी सखोल होते, तेव्हा तुम्हाला केवळ अंतिम उत्तरापेक्षा कितीतरी जास्त गोष्टी जाणून घेणे आवश्यक असते. कोणाला काय आणि कधी माहित होते, हे तुम्हाला माहित असणे आवश्यक आहे. कोणत्या शोधामुळे कामाची दिशा बदलली, याचा मागोवा घेणे आवश्यक आहे. दोन तासांपूर्वी एखाद्या एजंटने आपली योजना का बदलली, हे समजून घेणे आवश्यक आहे. कोलॅबोरेशन प्लेन शिवाय यापैकी काहीही दृश्यमान नसते. तुमच्याकडे लॉग्स (logs) असतात. लॉग्स हे केवळ कालानुक्रमे येणारा गोंधळ (chronological noise) असतात. ते फक्त एवढेच नोंदवतात की एजंट C ने अचानक API कॉल्सऐवजी डेटाबेस ट्रान्झॅक्शन्सचे विश्लेषण करण्यास सुरुवात केली, परंतु ते का केले याचे स्पष्टीकरण देत नाहीत. तुम्ही ते घडताना पाहू शकता आणि फक्त अंदाज लावू शकता.
एका सुरक्षा घटनेच्या प्रतिसादाची (security incident response) कल्पना करा. एजंट A सर्व्हर लॉग्सची बारकाईने तपासणी करतो आणि निष्कर्ष काढतो की घुसखोरी तिथून सुरू झाली नाही. तो आपला निकाल सुपरव्हायझरला देतो. नेटवर्क ट्रॅफिकचे विश्लेषण करण्यासाठी नियुक्त केलेला एजंट B, तो निष्कर्ष 'नाकारलेला गृहीतक' (rejected hypothesis) म्हणून कधीच पाहत नाही. कारण त्याच्या मूळ कामाच्या वर्णनामध्ये सर्व्हर अजूनही मुख्य संशयित मानला जातो, त्यामुळे एजंट B त्याच लॉग्समध्ये पुरावे शोधण्यात आणखी एक सायकल वाया घालवतो. सिस्टीमला एकाच कामासाठी दोनदा खर्च करावा लागतो आणि पहिल्या प्रयत्नातून काहीही शिकता येत नाही.
कोलॅबोरेशन प्लेन म्हणजे मेमरी नाही
कोलॅबोरेशन प्लेन म्हणजे केवळ तथ्यांसाठीची मेमरीची बादली नाही. मेमरी माहिती साठवते. कोलॅबोरेशन स्टेट (collaboration state) प्रगतीपथावर असलेले काम साठवते. दस्तऐवजांनी भरलेला वेक्टर डेटाबेस एजंटला संदर्भ साहित्य देतो. परंतु, एजंट X सध्या अशा एका गृहीतकाची चाचणी घेत आहे ज्यामुळे एजंट Y चे सध्याचे काम निरर्थक होईल, हे तो एजंटला सांगत नाही. मेमरी हा एक स्थिर संदर्भ (static context) आहे. कोलॅबोरेशन स्टेट हा ऑपरेशनचा थेट नकाशा (live map) आहे.
जर तुम्ही या दोन्ही गोष्टींमध्ये गोंधळ घातला, तर तुम्ही अशा सिस्टीम्स तयार कराल ज्या तुमच्या कंपनीच्या हँडबुकमधील प्रत्येक परिच्छेद शोधून काढू शकतात, परंतु दुसऱ्या एजंटने तुमचे सध्याचे काम निरर्थक ठरवले आहे की नाही, हे तुम्हाला सांगू शकत नाहीत.
शेअरड स्टेटचे पाच विभाग (The Five Buckets of Shared State)
एका खऱ्या कोलॅबोरेशन प्लेनला पाच विशिष्ट विभागांची (buckets) आवश्यकता असते.
Claims (दावे). हे असे सक्रिय गृहीतक आहेत ज्यांची एखादा एजंट चाचणी घेत आहे. फसवणुकीच्या तपासात, एक दावा असा असू शकतो की "विसंगती (anomaly) वीकेंड बॅच जॉब्सशी संबंधित आहे." कोणते दावे प्रलंबित आहेत, कोणत्यांची चाचणी सुरू आहे आणि त्यांचे मालक कोण आहेत, हे प्रत्येक एजंटला पाहता आले पाहिजे. शिवाय
