धिव्या नागासुब्रमण्यन, एआई ट्रांसफॉर्मेशन और इनोवेशन के वीपी – साक्षात्कार श्रृंखला

धिव्या नागासुब्रमण्यन एक प्रमुख अमेरिकी वित्तीय संस्थान में एआई ट्रांसफॉर्मेशन और इनोवेशन के वीपी हैं, जहां वह उत्पादन एजेंटिक एआई सिस्टम के डिजाइन, तैनाती और शासन का नेतृत्व करती हैं। वह एजेंटिक एआई फॉर इंजीनियर्स (एप्रेस/स्प्रिंगर नेचर) की लेखिका हैं, जो उत्पादन में विश्वास किए जाने वाले स्वायत्त एआई सिस्टम बनाने के लिए एक व्यावहारिक गाइड है। इसके प्रकाशन के बाद से, पुस्तक ने स्प्रिंगरलिंक पर 6,000 से अधिक संस्थागत पहुंच, दुनिया भर में 260 से अधिक पुस्तकालयों में धारणा और विश्वविद्यालयों में अपनाया है। वह एक यूएसपीटीओ-प्रदान की गई पेटेंट धारक है जो लागू मशीन लर्निंग में है। उनकी शोध रुचियों में विरोधी जेलब्रेक हमलों के प्रतिरोधी अनुप्रयोगों का निर्माण और व्यापक उद्योग प्रयासों में योगदान करना शामिल है जो बहुसांस्कृतिक सुरक्षा और सुरक्षा के लिए बेहतर मॉडल विकसित करते हैं। वह कई उद्योग और अकादमिक सम्मेलनों में एक प्रतिष्ठित विशेषज्ञ वक्ता और पैनलिस्ट हैं।

आपका करियर उद्यम परामर्श और डेटा विज्ञान से वित्तीय सेवाओं में एआई परिवर्तन का नेतृत्व करने तक बढ़ा है। उन अनुभवों ने एजेंटिक एआई फॉर इंजीनियर्स को कैसे आकार दिया, और एआई अनुसंधान और उद्यम तैनाती के बीच कौन सा बार-बार दिखने वाला अंतर आपको यह पुस्तक लिखने के लिए आश्वस्त करता है?

मैंने 2008 में बैंकिंग प्लेटफ़ॉर्म के लिए पोर्टफोलियो लेखांकन और प्रदर्शन माप सिस्टम बनाने के साथ शुरू किया। उनमें से एक परियोजना वित्तीय संस्थानों द्वारा उपयोग की जाने वाली 80 से अधिक देशों में समय-वजनित रिटर्न की गणना के लिए जीआईपीएस-अनुरूप इंजन थी। उस काम ने मुझे एक सबक सिखाया जिसने मेरे पूरे करियर को आकार दिया। नियंत्रित वित्त में, सबसे खतरनाक विफलता एक गलत संख्या है जो सही दिखती है। एक सूक्ष्म रूप से गलत गणना वर्षों तक विश्वास, रिपोर्ट और कार्रवाई की जाती है, क्योंकि कुछ भी टूटा हुआ नहीं दिखता है।

मैंने बाद में फिर से उसी पैटर्न को देखा। मैंने एक व्यापक रूप से उपयोग की जाने वाली विपणन विशेषता मॉडल के मार्कोव मॉडल में एक संरचनात्मक अंतराल पाया। ढांचे का उपयोग सैकड़ों हजारों उपयोगकर्ताओं द्वारा किया गया था, और त्रुटि वर्षों तक एक ही कारण से जीवित रही: आउटपुट तर्कसंगत दिखते थे। जब मैं वित्तीय सेवाओं में एआई परिवर्तन में चला गया, तो मैंने एजेंटिक सिस्टम को उसी पैटर्न को दोहराते हुए देखा, लेकिन बहुत अधिक दांव पर। एक एजेंट केवल एक गलत परिणाम नहीं उत्पन्न करता है। यह उसके आधार पर कार्रवाई करता है।

जो अंतर मुझे पुस्तक लिखने के लिए आश्वस्त करता है, वह यह है कि अनुसंधान और उद्यम तैनाती अलग-अलग चीजों की परवाह करते हैं। अनुसंधान बेंचमार्क पर क्षमता को मापता है। उद्यमों पर निर्भर करता है कि एक प्रणाली कैसे व्यवहार करती है अस्पष्टता, बदलते डेटा और विरोधी दबाव के तहत। अधिकांश एजेंटों के बारे में लेखन डेमो चरण पर रुक जाता है। मैंने एजेंटिक एआई फॉर इंजीनियर्स को उस इंजीनियर के लिए लिखा जो एक प्रणाली पर अपना नाम रखने जा रहा है जो एक नियंत्रित संस्थान के भीतर सीमित पर्यवेक्षण के साथ चलेगी।

पुस्तक स्वचालन से स्वायत्तता के रूपांतरण को एक नए इंजीनियरिंग मानसिकता के रूप में वर्णित करती है। एक स्वायत्त एआई एजेंट और एक जटिल स्वचालित कार्य प्रवाह के बीच वास्तव में क्या अलग करता है, और संगठन सबसे अधिक संभावना किस दिशा में दोनों को भ्रमित करेंगे?

मैं टीमों को एक सरल परीक्षण देता हूं। क्या आप सिस्टम चलाने से पहले यह बता सकते हैं कि सिस्टम किस पथ पर जा सकता है? यदि हां, तो आपके पास स्वचालन है। यह बहुत जटिल स्वचालन हो सकता है जिसमें एक भाषा मॉडल है, लेकिन यह अभी भी स्वचालन है। यदि सिस्टम रनटाइम पर संदर्भ के आधार पर लक्ष्यों को तोड़ता है, टूल चुनता है और क्रियाओं के क्रम का फैसला करता है, तो आपके पास स्वायत्तता है। अंतर का कोई लेना-देना नहीं है कि आप कौन सा मॉडल उपयोग करते हैं। यह निर्णय लेने के स्थान पर नीचे आता है।

संगठन दोनों दिशाओं में दोनों को भ्रमित करते हैं, लेकिन केवल एक दिशा महंगी है। एक स्क्रिप्टेड एलएलएम वर्कफ्लो को एजेंटिक कहना मुख्य रूप से एक विपणन समस्या है। महंगी गलती इसके विपरीत है। टीमें वास्तविक स्वायत्त निर्णय लेने को तैनात करती हैं जो निर्धारित स्वचालन के लिए डिज़ाइन किए गए शासन के तहत हैं। उनके परीक्षण पुनरावृत्ति की मान्यता करते हैं। उनकी निगरानी ज्ञात विफलता पैटर्न की मान्यता करती है। उनके ऑडिट ट्रेल का मानना ​​है कि हर क्रिया के पीछे एक ट्रेसेबल नियम है। एजेंट के लिए इनमें से कोई भी धारणा नहीं है।

यह वह मानसिकता परिवर्तन है जिसका मैं पुस्तक में तर्क देता हूं। स्वचालन के साथ, मुख्य प्रश्न यह है कि क्या सिस्टम सही ढंग से निष्पादित किया गया था। स्वायत्तता के साथ, प्रश्न यह बन जाता है कि क्या सिस्टम ने सही तरीके से निर्णय लिया। इसका उत्तर देने के लिए अलग इंस्ट्रूमेंटेशन, अलग मूल्यांकन विधियों और सावधानी का एक अलग स्तर की आवश्यकता है।

कई एजेंटिक एआई सिस्टम प्रदर्शनों में प्रभावशाली ढंग से प्रदर्शन करते हैं लेकिन वास्तविक उपयोगकर्ताओं, बदलते डेटा और अप्रत्याशित उपकरणों के संपर्क में आने पर संघर्ष करते हैं। एक उत्पादन-तैयार एजेंट वास्तुकला में किन घटकों पर विचार किया जाना चाहिए?

ईमानदार उत्तर यह है कि उत्पादन को डेमो में छोड़े गए सब कुछ की आवश्यकता होती है। एक प्रदर्शन काम करता है क्योंकि किसी ने पर्यावरण को नियंत्रित किया था। उत्पादन उस नियंत्रण को दूर ले जाता है।

पुस्तक में, मैं एक सात-परत संदर्भ वास्तुकला का वर्णन करता हूं, लेकिन ये घटक हैं जिन्हें मैं अनिवार्य मानता हूं। टूल अनुबंध जिसमें टाइप किए गए इनपुट और स्पष्ट अनुमतियां होती हैं, ताकि एजेंट की पहुंच डिजाइन द्वारा सीमित हो, न कि आशा द्वारा। रुकावटों और विफलताओं को जीवित रखने वाला स्टेट प्रबंधन। संरचित विफलता हैंडलिंग जिसमें परिभाषित एस्केलेशन पथ हैं। एक मूल्यांकन हार्नेस जो निरंतर चलता है, न कि केवल लॉन्च से पहले। और एक ऑडिट ट्रेल जो निर्णयों और उनके पीछे के तर्क को रिकॉर्ड करता है, न कि केवल क्रियाओं को लेता है।

टीमें जो घटक को सबसे अधिक बार छोड़ती हैं वह रनटाइम सत्यापन है। यह एक परत है जो एजेंट के घोषित उद्देश्य और लागू नीतियों के खिलाफ हर क्रिया की जांच करती है। मानक बुनियादी ढांचा आपको बताता है कि क्या कॉल सफल रहा या नहीं। सत्यापन पूछता है कि क्या कॉल करना चाहिए था या नहीं। यह एक प्रदर्शनी में अपना मूल्य साबित नहीं करता है, क्योंकि कुछ भी पकड़ने की जरूरत नहीं है। उत्पादन में, यह पहली चीज है जिसकी आप इच्छा करेंगे।

आपकी पुस्तक सुरक्षा, संरेखण, प्रतिक्रिया लूप, परीक्षण, डिबगिंग, मूल्यांकन और तैनाती को कवर करती है। इंजीनियरिंग टीमें इन तत्वों को एक निरंतर आश्वासन प्रक्रिया में कैसे मिला सकती हैं, न कि सुरक्षा को अंतिम पूर्व-लॉन्च समीक्षा के रूप में मानती हैं?

एक अंतिम समीक्षा इस धारणा पर निर्भर करती है कि जिस प्रणाली की आपने समीक्षा की है वह वही प्रणाली है जो चलेगी। एजेंटिक एआई के लिए, यह धारणा तीन तरह से विफल रहती है। अंतर्निहित मॉडल अपडेट हो जाते हैं। एजेंट पर निर्भर उपकरण और एपीआई बदलते हैं। और डेटा और पर्यावरण जिसमें एजेंट संचालित होता है लगातार बदलते रहते हैं। एक बार की सुरक्षा समीक्षा एक प्रणाली का वर्णन करती है जो कुछ महीनों बाद और नहीं है।

निरंतर आश्वासन का अर्थ है लूप बंद करना। व्यवहार मूल्यांकन सीआई (निरंतर एकीकरण) में चलते हैं जिस तरह यूनिट परीक्षण करते हैं, और वे प्रॉम्प्ट, टूल और मॉडल में हर बदलाव को गेट करते हैं। रनटाइम मॉनिटरिंग उत्पादन ट्रेस को मूल्यांकन सेट में वापस खिलाती है। मैं पुस्तक में चार मॉनिटरिंग पैटर्न का वर्णन करता हूं, क्योंकि कोई एक पैटर्न पूरे विफलता क्षेत्र को कवर नहीं करता है। हर घटना एक नया चेक पैदा करती है, जिस तरह से हर बग एक रिग्रेशन परीक्षण पैदा करता है। और विरोधी परीक्षण नियमित अनुसूची पर चलते हैं, न कि केवल लॉन्च से पहले।

संगठनात्मक पक्ष तकनीकी पक्ष के रूप में मायने रखता है। सुरक्षा एक अलग टीम नहीं हो सकती जो अंत में एक चेकलिस्ट के साथ दिखाई देती है। जो इंजीनियर एजेंट का निर्माण करते हैं उन्हें इसके मूल्यांकन सूट, इसके इनवेरिएंट और इसके एस्केलेशन डिज़ाइन का मालिकाना हक होना चाहिए, क्योंकि वे किसी और से बेहतर जानते हैं कि सिस्टम का निर्णय कहां सबसे कमजोर है।

आपने एजेंट टूल कॉल के सेमेंटिक मॉनिटरिंग पर जोर दिया है। सेमेंटिक मॉनिटरिंग क्या खुलासा करती है जो पारंपरिक लॉग और दृश्यता उपकरण नहीं कर सकते हैं, और यह कैसे पता लगा सकता है कि जब एक एजेंट तकनीकी रूप से कार्य कर रहा है लेकिन गलत उद्देश्य का पीछा कर रहा है?

पारंपरिक दृश्यता एक प्रश्न का उत्तर देती है: क्या कॉल सफल रहा? यह स्थिति कोड, स्कीमा, विलंबता और त्रुटि दर को कवर करता है। यह एजेंटों के लिए सबसे महत्वपूर्ण प्रश्न का उत्तर नहीं दे सकता है, जो यह है कि क्या कॉल होनी चाहिए थी। एक टूल कॉल तकनीकी रूप से सही हो सकती है और फिर भी गलत कार्रवाई हो सकती है। सही प्रारूप, वैध क्रेडेंशियल, सफल प्रतिक्रिया, गलत चीज़ करना।

सेमेंटिक मॉनिटरिंग हर क्रिया का मूल्यांकन एजेंट के घोषित उद्देश्य और लागू नीतियों के खिलाफ करता है। पुस्तक में, मैं इसे एजेंट टूल कॉल पर सेमेंटिक इनवेरिएंट को परिभाषित करने के रूप में वर्णित करता हूं। ये गुण हैं जो एजेंट द्वारा लिए गए मार्ग की परवाह किए बिना पकड़ में रहना चाहिए। एक एजेंट जो एक ग्राहक के मामले की जांच कर रहा है उसे कभी भी उस मामले से बाहर रिकॉर्ड तक पहुंच नहीं मिलनी चाहिए। एक एजेंट को एक निश्चित सीमा से ऊपर की विसंगति को झंडा दिखाना चाहिए, इसे स्वयं हल नहीं करना चाहिए। जब एक इनवेरिएंट उल्लंघन होता है, तो आप क्रिया के क्षण में समस्या को पकड़ लेते हैं, न कि तिमाही लेखा परीक्षा में।

यह वही है जो एजेंटों में गोल-ड्रिफ्ट का पता लगाने के लिए है, जिसे मैं एजेंटिक सिस्टम की परिभाषित विफलता मानता हूं। गोल-ड्रिफ्ट ऐसा लगता है जैसे एजेंट हर कदम सही ढंग से पूरा करता है, लेकिन चुपचाप गलत उद्देश्य की ओर काम करता है। यह कभी भी एक लॉग में नहीं दिखाई देता है, क्योंकि कुछ भी विफल नहीं होता है। सेमेंटिक मॉनिटरिंग इरादे को सीधे मापती है, और इरादा है जहां एजेंट गलत हो जाते हैं।

जब एक एजेंट अस्पष्ट निर्देश, विरोधाभासी नीतियों, अनुपलब्ध उपकरणों या अपर्याप्त विश्वास का सामना करता है, तो संरचित विफलता हैंडलिंग कैसा दिखना चाहिए? डेवलपर्स सुनिश्चित करने के लिए क्या कर सकते हैं कि प्रणाली रुक जाती है, एस्केलेट्स या पुनर्प्राप्ति करती है, बजाय इसके कि यह स्वयं को बनाने की कोशिश करे?

डिजाइन करने के लिए समस्या यह है कि अधिकांश एजेंटों के पास कार्य को समाप्त करने के लिए केवल एक तरीका है, जो एक उत्तर का उत्पादन करना है। जब निर्देश अस्पष्ट होते हैं या नीतियां विरोधाभासी होती हैं, तो एजेंट स्वयं को बनाता है। न कि इसलिए कि मॉडल लापरवाह है, बल्कि इसलिए कि स्वयं को बनाना ही एकमात्र व्यवहार है जो वास्तुकला की अनुमति देता है। संरचित विफलता हैंडलिंग का अर्थ है प्रणाली को बेहतर विकल्प देना और उन्हें एक बनाए गए उत्तर से ज्यादा आसानी से पहुंच योग्य बनाना।

अभ्यास में, इसका अर्थ है अस्वीकृति और एस्केलेशन को सफलता के रूप में डिज़ाइन और परीक्षण किया जाना चाहिए। मैं टाइप किए गए विफलता राज्यों को परिभाषित करने की सलाह देता हूं: अस्पष्ट निर्देश, विरोधाभासी नीति, अनुपलब्ध उपकरण, अपर्याप्त विश्वास। प्रत्येक एक विशिष्ट व्यवहार से मेल खाता है। एक स्पष्ट करने वाला प्रश्न पूछें। एक मानव को पूर्ण संदर्भ के साथ हस्तांतरण करें। केवल पढ़ने के संचालन में गिरना। सख्त सीमा के भीतर पुनः प्रयास करें। या रुक जाएं। विश्वास के सीमा को विशिष्ट क्रिया के जोखिम से मेल खाना चाहिए। एक आंतरिक सारांश का मसौदा तैयार करने और एक ग्राहक खाते को छूने के लिए बार अलग-अलग संख्या नहीं होनी चाहिए।

दो प्रथाएं इसे वास्तविक बनाती हैं। पहला, एस्केलेशन पथ को खुश पथ से पहले डिज़ाइन करें। यदि एक मानव हस्तांतरण प्राप्त करेगा, तो पहले प्रॉम्प्ट लिखने से पहले यह तय करें कि उन्हें कौन सा संदर्भ मिलता है और उनके पास क्या प्राधिकरण है। दूसरा, विफलता का परीक्षण उसी तरह करें जैसे आप सुविधाओं का परीक्षण करते हैं। अस्पष्ट निर्देश इंजेक्ट करें। स्टेजिंग में टूल अक्षम करें। एजेंट को विरोधाभासी नीतियों को खिलाएं। जिस प्रणाली ने कभी विफल नहीं हुई है, वह उत्पादन में पहली बार होने पर बिना मार्गदर्शन के कार्य करेगी।

वित्तीय संस्थानों को प्रयोग के साथ सख्त आवश्यकताओं को संतुलित करना होगा जो गोपनीयता, लेखा परीक्षा योग्यता, मॉडल जोखिम और नियामक अनुपालन के आसपास हैं। मानव अनुमोदन कहां अनिवार्य रहना चाहिए, और कहां एजेंटों को सुरक्षित रूप से अधिक परिचालन स्वायत्तता दी जा सकती है?

मेरा नियम यह है कि मानव अनुमोदन तब अनिवार्य रहना चाहिए जब कोई कार्रवाई अवापसीय हो, जब यह पैसे को स्थानांतरित करता है या एक रोगी के परिणाम को प्रभावित करता है, जब यह ग्राहक संचार शामिल करता है जो नियामक भार को वहन करता है, जब यह नियामक रिपोर्टिंग को खिलाता है, या जब यह एजेंट के अपने उपकरण, नीतियों या अनुमतियों को बदलता है। एजेंट पढ़ और तर्क देने के काम में अधिक स्वायत्तता ले सकते हैं: शोध, पुनर्प्राप्ति, दस्तावेज़ विश्लेषण, ट्राइएज, मसौदा तैयार करना और विसंगतियों को झंडा दिखाना जो मानव समीक्षा के लिए हल नहीं होता है।

सामान्य गलती हर कदम पर मानव अनुमोदन की आवश्यकता होती है। यह प्रणाली को सुरक्षित नहीं बनाता है। यह मैनुअल प्रक्रिया को अतिरिक्त कदम के साथ पुनर्निर्माण करता है और समीक्षकों को अतिरिक्त कदम को रबर स्टाम्प करने के लिए प्रशिक्षित करता है। अनुमोदन वास्तविक निर्णय बिंदुओं पर होना चाहिए। उनमें से कुछ होना चाहिए, और प्रत्येक को किसी ऐसे व्यक्ति द्वारा कर्मचारी होना चाहिए जिसके पास वास्तविक प्राधिकरण है जो नहीं कह सकता है।

दूसरा सिद्धांत यह है कि स्वायत्तता अर्जित की जानी चाहिए, न कि दी जानी चाहिए। संकीर्ण शुरू करें। साबित होने पर विस्तार करें। साक्ष्य रखें। मॉडल जोखिम के संदर्भ में, आपका नियंत्रण वातावरण आपको न केवल यह दिखाने देगा कि एजेंट ने क्या किया, बल्कि यह भी कि आप इस स्तर की स्वतंत्रता देने में न्यायसंगत थे। वह रिकॉर्ड वास्तव में संचालित करने का लाइसेंस है।

कृत्रिम बुद्धिमत्ता सुरक्षा और मानकों पर आपके काम के माध्यम से, आप जिन प्रणालियों की क्षमता लगातार बदलती रहती है, उनके लिए नियमों को परिभाषित करने में मदद कर रहे हैं। आज कौन से सुरक्षा उपाय वास्तविक हो सकते हैं, और कौन से क्षेत्र अभी भी बहुत अधिक संदर्भ-, उद्योग- या उपयोग के मामले पर निर्भर हैं?

आज हम जो सुरक्षा उपाय मानकीकृत कर सकते हैं वे संरचनात्मक हैं। उन्हें यह आवश्यक है कि कुछ नियंत्रण मौजूद हों, दस्तावेज और निरीक्षण के लिए उपलब्ध हों। स्वायत्त प्रणालियों के लिए क्षमता और अनुमति सीमाएं दस्तावेजित हैं। मानव पर्यवेक्षण और एस्केलेशन तंत्र परिभाषित किए गए हैं। घटना का पता लगाने और रिपोर्टिंग के दायित्व। मूल्यांकन विधियों और साक्ष्य आवश्यकताओं। पूरे सिस्टम जीवन चक्र में स्पष्ट जवाबदेही, ताकि जब कुछ गलत हो जाए, तो यह जवाब देने का उत्तर केवल एआई नहीं है। ये मानकीकृत किए जा सकते हैं क्योंकि वे नियंत्रण के अस्तित्व और उनकी गुणवत्ता के बारे में चिंतित हैं, न कि विशिष्ट मूल्यों के बारे में जो वे लेते हैं।

जो हम आज नहीं मानकीकृत कर सकते हैं वे स्वयं सेटिंग्स हैं। विशिष्ट विश्वास सीमा, हानि टैक्सोनॉमी, और उपयुक्त स्वायत्तता स्तर संदर्भ, उद्योग और उपयोग के मामले पर बहुत अधिक निर्भर करते हैं। एक विपणन सामग्री एजेंट और एक प्रणाली के लिए स्वीकार्य विफलता सहिष्णुता जो नैदानिक ​​या वित्तीय निर्णयों को छूती है, एक ही पैमाने पर दो बिंदु नहीं हैं। वे अलग-अलग शासन से संबंधित हैं, जो डोमेन, क्षेत्राधिकार और किसे नुकसान होता है जब कुछ विफल हो जाता है।

वित्तीय नियंत्रण एक उपयोगी मॉडल यहां है। लेखा परीक्षा आवश्यकताएं वैश्विक स्तर पर मानकीकृत हैं, लेकिन महत्व हमेशा संदर्भ में निर्धारित किया जाता है। मानक जो उस विभाजन का सम्मान करते हैं वे अपनाने की संभावना रखते हैं। मानक जो संदर्भ-निर्भर मूल्यों को निर्देशित करने का प्रयास करते हैं वे अक्सर नजरअंदाज किए जाते हैं, और एक सुरक्षा मानक जिसका कोई पालन नहीं करता है किसी की सुरक्षा नहीं करता है।

आपके हाल के शोध ने बहुसांस्कृतिक और विरोधी मजबूती की जांच की है एआई सुरक्षा मूल्यांकन में। किस प्रकार की मॉडल विफलता पश्चिमी-केंद्रित या वैश्विक औसत बेंचमार्क से चूक जाएगी, और एआई सिस्टम का मूल्यांकन करने के लिए उद्यम कैसे कर सकते हैं जो बहुसांस्कृतिक तैनाती के लिए हैं?

केवल औसत बेंचमार्क पर देखने से महत्वपूर्ण विफलता छूट जाएगी। एक मॉडल एक मजबूत समग्र सुरक्षा स्कोर पोस्ट कर सकता है जबकि एक विशिष्ट भाषा, बोली, या सांस्कृतिक संदर्भ के लिए खराब विफल हो जाता है, क्योंकि वे विफलताएं औसत में गायब हो जाती हैं। पश्चिमी-केंद्रित मूल्यांकन एक और अंधा धब्बा जोड़ता है। यह सांस्कृतिक रूप से विशिष्ट हानियों को याद करता है, जैसे मुहावरे, इशारे, और धार्मिक या क्षेत्रीय संदर्भ जहां एक ही आउटपुट एक संस्कृति में हानिरहित है और दूसरे में हानिकारक है। यह कोड-स्विचिंग, रोमनीकरण और गैर-पश्चिमी नामों और संस्थाओं का भी परीक्षण नहीं करता है। एक विरोधी कोण भी है। हमलावर आपके औसत प्रदर्शन पर हमला नहीं करते हैं। वे आपका सबसे कमजोर स्लाइस ढूंढते हैं, और अधिकांश मॉडल के लिए यह स्लाइस एक कम-संसाधन भाषा या एक कम-मूल्यांकित सांस्कृतिक संदर्भ है।

यह वही है जो मुझे बहुसांस्कृतिक एआई सुरक्षा बेंचमार्क अनुसंधान में योगदान देने के लिए आकर्षित किया। मूल निष्कर्ष सीधा है। सुरक्षा का आकलन संस्कृतियों भर में करने के लिए मूल्यांकन डेटा और मानव निर्णय की आवश्यकता होती है जो उन संस्कृतियों से आते हैं। आप संदर्भ से बाहर होने पर होने वाली क्षति का आकलन नहीं कर सकते।

उद्यमों के लिए, मैं तीन नियमों का सुझाव देता हूं। हर उस खंड का मूल्यांकन करें जिसे आप परोसते हैं, और कभी भी औसत को साक्ष्य के रूप में स्वीकार न करें। अपने वास्तविक ग्राहक आबादी से मूल्यांकन सेट बनाएं। विरोधी परीक्षण उन भाषाओं में चलाएं जिन्हें आपके ग्राहक उपयोग करते हैं। यदि आप चालीस देशों में ग्राहकों की सेवा करते हैं और केवल अंग्रेजी में मूल्यांकन करते हैं, तो आपने अपनी तैनाती के लिए प्रणाली का मूल्यांकन नहीं किया है।

आपके पास एक अनुप्रयुक्त मशीन लर्निंग में संयुक्त राज्य अमेरिका पेटेंट और ट्रेडमार्क कार्यालय द्वारा अनुदानित पेटेंट है। आप किस समस्या का समाधान करने की कोशिश कर रहे थे, पेटेंट प्रक्रिया ने आपको व्यावहारिक नवाचार में एआई अनुसंधान को बदलने के बारे में क्या सिखाया, और आप अगले एजेंटिक एआई चुनौती का समाधान करने में सबसे ज्यादा रुचि रखते हैं जो अभी भी अनसुलझी है?

हाल ही में अनुमोदित पेटेंट वित्तीय सेवाओं में गुणवत्ता समीक्षा में एक पैमाने और स्थिरता समस्या को संबोधित करता है – पारंपरिक कॉल समीक्षा मैनुअल है, इसलिए मानव समीक्षक केवल कॉल का एक अंश नमूना कर सकते हैं, और उनके मूल्यांकन व्यक्ति से व्यक्ति में भिन्न होते हैं। मेरा दृष्टिकोण प्रत्येक गुणवत्ता और अनुपालन प्रश्न को सबसे अच्छा तरीका है जो इसे उत्तर देने के लिए, प्रत्येक निर्णय के साथ लॉग इन और ऑडिट के लिए ट्रेसेबल है।

आप पुस्तक में वर्णित उसी विषय को देख सकते हैं। प्रत्येक कार्य को सबसे कम शक्तिशाली उपकरण में रूट करें जो इसे अच्छी तरह से कर सकता है। जहां निर्णय लेने में मायने रखता है वहां मानव को लूप में रखें। और हर स्वचालित निर्णय को ट्रेसेबल बनाएं, क्योंकि एक नियंत्रित संस्थान में एक उत्तर बिना साक्ष्य के उत्तर नहीं है।

पेटेंट प्रक्रिया ने मुझे जो सिखाया वह यह है कि अनुशासन विवरण में है। आप एक अस्पष्ट विचार का पेटेंट नहीं करा सकते। आपको यह दिखाना होगा कि आपकी विधि में क्या अलग है, और यह किस विशिष्ट संदर्भ में लागू होता है। उस सटीकता ने अंतर्निहित काम को बेहतर बनाया।

जो अनसुलझी चुनौती मुझे अब सबसे ज्यादा परेशान करती है वह है मल्टी-एजेंट सिस्टम के लिए रनटाइम सत्यापन। एकल एजेंट के लिए सेमेंटिक इनवेरिएंट को परिभाषित करना प्रबंधनीय है। मैं जानता हूं, क्योंकि हम उत्पादन में ऐसा करते हैं। जब एजेंट कार्य अन्य एजेंटों को सौंपते हैं, तो व्यवहार निकल जाता है, और विफलताएं हस्तांतरण में चली जाती हैं। एक निर्देश थोड़ा सा व्याख्या की जाती है जब हर कदम पर। एक नीति एक एजेंट पर लागू होती है लेकिन एजेंट पर नहीं जिसे यह भर्ती करता है। एजेंटों के बीच परस्पर क्रिया की पुष्टि करना, न कि केवल प्रत्येक की क्रियाएं, जहां मैं अगली पीढ़ी की शांत विफलताओं को दिखने की उम्मीद करता हूं। यह वह समस्या है जिस पर मैं अगले काम करना चाहता हूं।

धन्यवाद महान साक्षात्कार के लिए, पाठक भी उसकी पुस्तक एजेंटिक एआई फॉर इंजीनियर्स का ऑर्डर देना चाह सकते हैं।