Google ने बायोटेकसाठी तीन स्तरांची एजंट रचना सुचवली

Google Cloud ने बायोटेक एजंटसाठी असा संदर्भ आराखडा प्रसिद्ध केला आहे, ज्यात नियोजन करणारा एजंट, GPU चा मोठ्या प्रमाणात वापर करणाऱ्या वैज्ञानिक गणना आणि दोन्हींवरील नियंत्रणे वेगळी ठेवली आहेत. १६ ऑक्टोबरच्या रचनाविषयक लेखात औषध संशोधन करणारा संघ Google Cloud वर प्रथिनांचे फोल्डिंग, रेणू निर्मिती आणि लीड संयुगांचे पुनरावलोकन कसे समन्वयित करू शकतो, हे सांगितले आहे. त्यात एक नमुना आणि उदाहरणार्थ तंत्ररचना दिली आहे; पण मोजमाप केलेली ग्राहकाकडील अंमलबजावणी, कार्यक्षमता-दराचे निष्कर्ष किंवा प्रमाणित औषध उमेदवार दिलेला नाही.

संशोधनात एजंट प्रणालींचे मूल्यमापन करणाऱ्या संघांसाठी हा फरक महत्त्वाचा आहे. भाषा मॉडेल काम योग्य ठिकाणी पाठवू शकते आणि निष्कर्षांचा सारांश देऊ शकते; पण प्रथिनाची रचना किंवा डॉकिंगचा गतिमार्ग हे साध्या चॅटच्या संदर्भात हाताळण्याइतके लहान नसतात. वैज्ञानिक गणनांना स्वतंत्र रनटाइम, रांग आणि प्रवेश नियंत्रणेही असतात. Google च्या प्रस्तावात या घटकांभोवती स्पष्ट सीमा ठेवल्या आहेत, जेणेकरून एकत्रित कार्यप्रवाहावर अवलंबून राहण्यापूर्वी संघ प्रत्येक भाग तपासू शकेल.

तीन स्तर, वेगवेगळ्या जबाबदाऱ्या

पहिला स्तर म्हणजे Agent Runtime वर चालणारा मुख्य समन्वयक. Google च्या उदाहरणात त्याला दोन विशेष उपएजंट दिले आहेत: एक लीड संयुगांच्या अनुकूलनासाठी आणि दुसरा सुरक्षिततेच्या प्राथमिक तपासणीसाठी. मुख्य एजंट विनंतीचे भाग करतो, काम वाटतो आणि उत्तर एकत्र करतो. या प्रस्तावित रचनेत अंतर्गत एजंटांमधील कामाचे हस्तांतरण एकाच प्रक्रियेत होते. Agent Runtime हे व्यवस्थापित तैनाती वातावरण आहे. एजंटला कॉल करण्यापूर्वी प्रकल्पाची मांडणी, Agent Platform SDK for Python, एजंटचा विकास आणि तैनाती या पायऱ्या Google च्या दस्तऐवजांत दिल्या आहेत. कंटेनरमध्ये असलेल्या एजंटने त्याचा रनटाइम करार पाळला पाहिजे.

दुसरा स्तर खर्चिक वैज्ञानिक कामे चालवतो. Google च्या उदाहरणात NVIDIA चे ESMFold आणि GenMol इन्फरन्स मायक्रोसर्व्हिसेस Google Kubernetes Engine वर चालतात. त्यासाठी RTX PRO 6000 Blackwell GPU असलेली G4 व्हर्च्युअल मशीन वापरली आहेत. प्रथिनांचे फोल्डिंग आणि रेणू निर्मिती ही समन्वयकाने मागणी करायची कामे आहेत; सर्वसाधारण भाषा मॉडेलने स्वतः करायच्या गणना नाहीत. कोल्ड-स्टार्टमधील विलंब कमी करण्यासाठी किमान एक GKE नोड सक्रिय ठेवावा आणि पॉड सुरू होताना मॉडेलची वेट्स लोड करावीत, अशी लेखात शिफारस आहे. तयार ठेवलेला नोड आणि लोड केलेली वेट्स संसाधने वापरतात; या निवडीसाठी विलंब, वापराचे प्रमाण किंवा खर्च यांची तुलना लेखात दिलेली नाही.

तिसरा स्तर प्रवेशाचे नियमन करतो. Agent Identity एजंटला SPIFFE ओळख आणि व्यवस्थापित X.509 प्रमाणपत्र देते. ते IAM परवानग्या आणि ऑडिट लॉगसोबत वापरता येते. Agent Gateway समर्थित आत येणाऱ्या आणि बाहेर जाणाऱ्या मार्गांवर प्रवेश नियम लागू करू शकते. Agent Registry मध्ये एजंट, MCP सर्व्हर, साधने आणि एंडपॉइंट यांची सूची ठेवली जाते. महत्त्वाचे परिणाम होणाऱ्या टप्प्यांवर Model Armor तपासणी आणि मानवी मंजुरी वापरण्याचाही Google चा प्रस्ताव आहे. या नियंत्रणांसाठी तैनाती आणि धोरणांची मांडणी आवश्यक आहे. ती रचनेच्या आकृतीत दिसतात म्हणून एखादा डेटा मार्ग खाजगी आहे किंवा प्रत्येक निर्णयाची ऑडिट नोंद होते, हे सिद्ध होत नाही.

फायली प्रॉम्प्टमधून नव्हे, स्टोरेजमधून पाठवा

मोठ्या वैज्ञानिक डेटाचे व्यवस्थापन हा या रचनेतील इतर कामांत सर्वाधिक सहज वापरता येण्यासारखा भाग आहे. प्रस्तावित कार्यप्रवाहात PDB फायली, डॉकिंगमधील स्थिती आणि गतिमार्गाचे लॉग Cloud Storage मध्ये लिहिले जातात. एजंट ऑब्जेक्टचे संदर्भ आणि छोटे सारांश एकमेकांना देतात; साधनाला गरज असते तेव्हा मूळ डेटा आणतात. यामुळे स्थाननिर्देशांकांच्या अ‍ॅरे LLM च्या कॉन्टेक्स्ट विंडोमध्ये ढकलावे लागत नाहीत आणि फायलींवरील प्रवेश व त्या किती काळ ठेवायच्या हे नियंत्रित करण्यासाठी संघाला स्वतंत्र जागा मिळते.

या नमुन्यात Google स्वाक्षरीयुक्त ऑब्जेक्ट URI वापरण्याचे वर्णन करते. स्वाक्षरीयुक्त URL ही स्वतःच नमूद व्याप्ती आणि मुदतीसाठीची प्रवेश-परवानगीची खूण असते. त्यामुळे प्रत्यक्ष कार्यप्रवाहासाठी समाप्तीची वेळ, परवानग्या आणि लॉगिंग ठरवणे संघाला आवश्यकच असते. उत्पादनात चालणाऱ्या बायोटेक पाइपलाइनसाठी संपूर्ण स्टोरेज धोरण, डेटा कुठे राहतो याची संरचना किंवा धोक्यांचे मॉडेल या रचनाविषयक लेखात दिलेले नाही. खाजगी पद्धतीने होस्ट केलेला गणना-कंटेनर मालकीहक्काच्या संरचना संस्थेच्या सीमेत ठेवतो, हा दावा त्या संरचना स्वीकारणाऱ्या किंवा पुढे पाठवणाऱ्या प्रत्येक घटकावर अवलंबून आहे. यात स्टोरेज, मॉडेल कॉल, लॉग आणि बाहेर जाणारे एंडपॉइंट यांचाही समावेश होतो.

लेखात दीर्घ सिम्युलेशन साखळी स्पष्ट टूल इंटरफेसमागे ठेवण्याची आणि टप्पे पूर्ण झाल्यावर प्रगती दर्शवण्याचीही शिफारस आहे. या रचनात्मक निवडी प्रत्यक्ष बॅकएंड रांगेच्या संदर्भात तपासाव्या लागतात. वैज्ञानिक सेवा विनंत्या अंतर्गत क्रमाने चालवत असेल, तर अधिक विनंत्या समांतर पाठवून फायदा होणार नाही. प्रस्तावित संरचनेचा कार्यक्षमता-दर निर्धारक आहे, हे दाखवणारी कोणतीही बेंचमार्क चाचणी लेखात नाही.

मानवी निर्णय कुठे आवश्यक ठरवायचा

Google च्या प्रस्तावात संरचना शोधणे किंवा रासायनिक नावाचा अर्थ निश्चित करणे यांसारखी उलटवता येणारी तयारी एजंट करू शकतात; मात्र खर्चिक किंवा महत्त्वाचे परिणाम घडवणाऱ्या कृतींसाठी व्यक्तीची मंजुरी आवश्यक आहे. अनेक GPU वर डॉकिंग चालवणे, लीड संयुगाला प्रत्यक्ष प्रयोगशाळेतील संश्लेषणाकडे नेणे आणि संशोधन कार्यक्रम संग्रहित करणे ही उदाहरणे आहेत. संशोधन संस्थेला हे मंजुरीचे टप्पे, मंजूर करणारी व्यक्ती आणि प्रत्येक टप्प्यावर दाखवायचे पुरावे निश्चित करावे लागतील. लेखात प्रमाणित सुरक्षितता तपासणीचा निकाल दिलेला नाही किंवा तज्ज्ञांच्या पुनरावलोकनाशिवाय मॉडेल औषधशास्त्रीय निर्णय घेऊ शकते, हे सिद्ध केलेले नाही.

प्रशासनाच्या दस्तऐवजांमुळे ब्लॉगमधील काही व्यापक विधानांची व्याप्ती स्पष्ट होते. Agent Runtime सोबत Gateway आत येणारे आणि बाहेर जाणारे दोन्ही मार्ग समर्थित करते; Gemini Enterprise साठी मात्र फक्त बाहेर जाणारे मार्ग समर्थित आहेत. एखाद्या स्पष्ट IAM धोरणाने गंतव्याचा URL लक्ष्य केला असेल, तर नोंदणी नसलेल्या गंतव्यांनाही विनंती पाठवता येते. त्यामुळे नोंदणी ही स्वतःहून सर्व अज्ञात साधने रोखणारी व्यवस्था नाही. Model Armor तपासण्या या संघ संरचित करू शकतो अशा सुरक्षा मर्यादांपैकी एक आहेत. Agent Identity च्या दस्तऐवजी मर्यादांमध्ये एजंट प्रिन्सिपलना जुन्या Cloud Storage बकेट भूमिका देता न येणे समाविष्ट आहे. एजंट हटवल्यावर IAM बाइंडिंग्जची साफसफाई स्वतः करावी लागते.

पडताळणीसाठी Google Cloud ने वेगळ्या संदर्भात मांडलेले एजंट प्लगइनच्या मूल्यमापनातून मिळालेले चार धडे उपयोगी पार्श्वभूमी देतात; पण तो प्लगइन वेगळी प्रणाली आहे. फक्त एजंटचे अंतिम उत्तर तपासल्यास टूल-कॉल लॉगमध्ये दिसणाऱ्या कृती सुटतात, असे संघाला आढळले. समांतर कॉलची रचना जतन करणे, प्रत्यक्ष चालवलेल्या आणि फक्त नियोजन करणाऱ्या रनची तुलना करणे आणि तज्ज्ञांनी निवडलेली आधारभूत कामे ठेवणे, अशी त्यांची शिफारस आहे. बायोटेक प्रस्तावाला हे लागू केल्यास प्रत्यक्ष स्टोरेज लेखन, मॉडेल एंडपॉइंट, परवानगीचे निर्णय, रांगेचे वर्तन आणि मानवी मंजुऱ्या तपासणे आवश्यक ठरते. BIG CHANGE ने ही रचना उभारलेली किंवा तपासलेली नाही.

यापूर्वीचा आमचा Google Antigravity द्वारे सूक्ष्मजीवरोधी पेप्टाइडची प्राथमिक छाननी हा लेख एका वेगळ्या वैज्ञानिक एजंट कामाविषयी आहे. येथे सुचवलेली पायाभूत रचना उभारली किंवा प्रमाणित केली आहे, हे त्यातून सिद्ध होत नाही.

प्रवेश, खर्च आणि उपलब्धतेची अवस्था

संघाला Google Cloud प्रकल्प, संबंधित API आणि IAM मांडणी, Agent Runtime तैनाती, GKE GPU क्षमता, स्टोरेज आणि संरचित प्रशासन घटक लागतील. उपलब्धता आणि मर्यादा निवडलेले प्रदेश, कोटा आणि उत्पादनाची संरचना यांवर अवलंबून असतात. Agent Runtime चे दस्तऐवज प्रदेश आणि कोटा याद्यांकडे निर्देश करतात आणि मोफत वापराचा स्तर उपलब्ध असल्याचे सांगतात. Agent Platform चे किंमत पान रनटाइम गणना आणि मेमरीचे शुल्क तसेच Gateway च्या बाहेर जाणाऱ्या वाहतुकीची आकारणी स्पष्ट करते. मॉडेलचा वापर, GPU पायाभूत सुविधा आणि Cloud Storage यांचा स्वतंत्र खर्च जोडला जातो. Google चा किंमत कॅल्क्युलेटर निवडलेल्या संरचनेचा अंदाज काढण्यास मदत करू शकतो. सतत तयार ठेवलेल्या GPU पूलचा खर्चही या अंदाजात धरला पाहिजे.

घटकांच्या दस्तऐवजांत वापरता येणाऱ्या सेवांचे वर्णन आहे; पण त्यामुळे एकत्रित बायोटेक नमुना सर्वसाधारण उपलब्ध आणि मोजमाप झालेला उत्पादन बनत नाही. Registry मधील स्वतंत्र कौशल्यांना स्पष्टपणे Preview म्हटले आहे. येथे तपासलेल्या पानांवर प्रस्तावित तंत्ररचनेतील प्रत्येक घटकासाठी एकच सार्वत्रिक प्रकाशन-अवस्था दिलेली नाही. नेमके मॉडेल कंटेनर, नेटवर्क नियंत्रणे आणि संशोधन अनुप्रयोग यांची परस्पर सुसंगती अपेक्षित प्रदेश व तैनातीसाठी तपासावी लागेल. हा लेख १६ ऑक्टोबरच्या प्रस्तावाचा दस्तऐवजांवर आधारित आढावा आहे; सेटअप मार्गदर्शक किंवा कार्यरत स्थापनेचा अहवाल नाही.

मोठा बदल

Google ने बायोटेक एजंट कार्यप्रवाहाचे नियोजन, स्वतंत्र वैज्ञानिक गणना आणि नियंत्रित प्रवेश असे विभाजन करण्याचा मार्ग मांडला आहे. मोठ्या संरचना संदर्भाद्वारे पुढे दिल्या जातात आणि खर्चिक किंवा महत्त्वाचे परिणाम असलेल्या कृतींसाठी मानवी मंजुरी राखली जाते. संशोधन पायाभूत सुविधा सांभाळणाऱ्या संघांना मूल्यमापनासाठी ठोस सीमा या आराखड्यात मिळतात. वेग, विलगीकरण, वैज्ञानिक विश्वासार्हता आणि संचालनाचा खर्च हे प्रश्न प्रत्यक्ष संरचित तैनाती व मोजमाप केलेल्या चाचण्यांतून सोडवायचे बाकी आहेत.

स्रोत आणि अधिक वाचन

• Google Cloud, “स्वायत्ततेची रचना”: १६ ऑक्टोबरची संदर्भ रचना, तिचे प्रस्तावित घटक, कामाच्या भाराचे नमुने आणि मंजुरीचे टप्पे.
• Agent Runtime चे दस्तऐवज: व्यवस्थापित एजंट तैनाती, पूर्वअटी, फ्रेमवर्क समर्थन, प्रदेश व कोट्याच्या लिंक्स आणि किंमत माहितीचे प्रवेशस्थान.
• Agent Identity चा आढावा: ओळख व प्रवेश-प्रमाणकांची कार्यपद्धती, IAM चे जीवनचक्र आणि Cloud Storage भूमिकेची एक मर्यादा.
• Agent Gateway चा आढावा: अंमलबजावणीची पद्धत, रनटाइम मोड, संरचनेवर अवलंबून सुरक्षा मर्यादा आणि नमूद केलेल्या मर्यादा.
• Agent Registry चे दस्तऐवज: नोंदणीकृत संसाधनांचे प्रकार आणि स्वतंत्र कौशल्यांची Preview अवस्था.
• Agent Platform च्या किंमती: Runtime आणि Gateway च्या शुल्काचा आधार; संपूर्ण तंत्ररचनेचा अंदाज स्वतंत्रपणे काढावा.
• Google Cloud चे मूल्यमापनातील चार धडे: कार्यवाहीच्या नोंदी तपासणे आणि मूल्यमापनाची रचना याबद्दल दुसऱ्या एजंट प्लगइनमधून मिळणारी पार्श्वभूमी.

स्रोत १८ ऑक्टोबर २०२६ रोजी तपासले. BIG CHANGE ने प्रस्तावित बायोटेक प्रणाली तैनात केलेली किंवा तिची बेंचमार्क चाचणी केलेली नाही.