माइक्रोसॉफ्ट और नोवो नॉर्डिस्क की एक संयुक्त विकास टीम ने एक एआई एजेंट को दोबारा लागू किया है, जिसका उपयोग चिकित्सा विशेषज्ञ नोवो नॉर्डिस्क के क्लिनिकल ट्रायल डेटा को खंगालने के लिए करते हैं, और उसे होस्टेड एजेंट के रूप में Microsoft Foundry पर ले जाया गया है। Command Line पर प्रकाशित एक पोस्ट में लेखकों का कहना है कि इस बदलाव से संचालन सरल हुआ, उपयोगकर्ता सत्रों के बीच अलगाव मजबूत हुआ और एजेंट सीधे Foundry के ट्रेसिंग, मूल्यांकन और ऑप्टिमाइज़ेशन टूल्स से जुड़ गया।
एजेंट क्या करता है
यह एजेंट द्वितीयक विश्लेषण में सहायता करता है, यानी ऐसा काम जो ट्रायल प्रोटोकॉल से आगे जाता है, जैसे किसी परिकल्पना का परीक्षण करना या रोगी समूहों की तुलना करना। टीम के अनुसार, इसका मुख्य टूल वह कोड है जिसे वह नियंत्रित वातावरण में लिखता और चलाता है, और उसके बाद एक सारांश और एक चार्ट लौटाता है। यह परियोजना एक फॉरवर्ड-डिप्लॉयड इंजीनियरिंग सहयोग से विकसित हुई। इसका पहला प्रोडक्शन संस्करण Azure Container Apps पर चलता था, जिसमें PostgreSQL बातचीत को सहेजता था और Azure Container Apps के डायनामिक सेशन कोड के लिए सैंडबॉक्स उपलब्ध कराते थे। इससे स्केलिंग, सत्र के जीवनचक्र, आइसोलेशन, नेटवर्किंग और टेलीमेट्री की ज़िम्मेदारी टीम पर रहती थी।
नई व्यवस्था में, लेखकों के अनुसार, मॉडल और टूल चुनना तथा यह तय करना कि एजेंट अपना काम कैसे संचालित करे, अब भी उन्हीं के हाथ में है। अब Foundry एंडपॉइंट और एजेंट की पहचान चलाता है, हर सत्र के लिए कंप्यूट उपलब्ध कराता है, स्टेट को सुरक्षित रखता है और स्केलिंग संभालता है।
सत्रों को अलग रखना
लेखकों द्वारा रेखांकित किया गया एक बदलाव यह है कि सत्रों को कैसे अलग किया जाता है। अब हर सत्र एक समर्पित सैंडबॉक्स में चलता है, जो VM स्तर पर आइसोलेटेड है; Foundry इसे ज़रूरत पड़ने पर शुरू करता है और निर्धारित निष्क्रियता अवधि बीतने पर हटा देता है। टीम का कहना है कि यह इसलिए अहम है क्योंकि एजेंट का अपना बनाया कोड संवेदनशील क्लिनिकल डेटा पर काम करता है। Foundry Agent Service प्राइवेट नेटवर्किंग भी प्रदान करती है, जिसके बारे में लेखकों का कहना है कि इससे वे उस डेटा के लिए आने वाले और बाहर जाने वाले ट्रैफ़िक को नियंत्रित कर पाते हैं जिसे किसी अनुमोदित सीमा के भीतर ही रहना है।
टीम ज़ोर देकर कहती है कि प्लेटफ़ॉर्म सुरक्षा या गुणवत्ता की ज़िम्मेदारी अपने ऊपर नहीं ले लेता। उन्हें फिर भी एक्सेस कंट्रोल तय करने, टेलीमेट्री को सुरक्षित रखने और घटाने, एजेंट का अपने उपयोग-मामले पर परीक्षण करने और एजेंट जिन भी सिस्टम को कॉल कर सकता है उन सभी की जाँच करने का काम करना पड़ा।
नेटवर्क की योजना पहले से बनाएँ
लेखकों का तर्क है कि प्राइवेट नेटवर्किंग पर निर्णय डिज़ाइन चरण में ही हो जाना चाहिए। सत्र IP पते इस्तेमाल करते हैं, और Foundry अकाउंट से जुड़े सबनेट को बाद में बदला नहीं जा सकता, इसलिए बहुत छोटी रेंज क्षमता बढ़ाने जैसे सामान्य काम को व्यापक इन्फ्रास्ट्रक्चर माइग्रेशन में बदल सकती है। वे Foundry के मौजूदा मार्गदर्शन का हवाला देते हैं: प्रोडक्शन के लिए /24 सबनेट, जबकि छोटी तैनाती के लिए /27 सबसे छोटा समर्थित आकार है।
ट्रेस और गुणवत्ता जाँच
Foundry की ट्रेसिंग OpenTelemetry पर आधारित है और डेटा Azure Monitor Application Insights में रखती है; बदलाव के दौरान टीम ने ट्रेस Langfuse को भी भेजे। चूँकि किसी ट्रेस में प्रॉम्प्ट, आउटपुट तथा टूल के इनपुट और नतीजे दर्ज हो सकते हैं, इसलिए लेखकों का कहना है कि क्लिनिकल टेलीमेट्री को अन्य संवेदनशील प्रोडक्शन डेटा जैसा ही बरताव मिलना चाहिए, जिसमें रिडैक्शन, न्यूनतमीकरण, प्रतिधारण सीमाएँ और प्रतिबंधित एक्सेस शामिल हैं।
टीम ने अपने बैकएंड कॉन्ट्रैक्ट अछूते रखे, इसलिए उसका मौजूदा मूल्यांकन फ्रेमवर्क दोबारा बनाए गए एजेंट तक बिना बदलाव पहुँच सका और उसी टेस्ट सेट और ग्रेडर्स से उसे आँक सका, जिनमें विषय-विशेषज्ञों के संदर्भ उत्तरों से तुलना भी शामिल है। लेखकों के अनुसार, ये स्कोर माइग्रेशन के लिए आधार-रेखा और रिग्रेशन के विरुद्ध जाँच के रूप में काम आए।
यह पोस्ट परियोजना टीम का अपना विवरण है, कोई स्वतंत्र आकलन नहीं।
