6.7 एआई एजेंट और एजेंटिक प्रणालियाँ

अवलोकन और प्रेरणा

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

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

बड़ी टीमों के लिए दाँव तकनीकी जितने ही संगठनात्मक हैं। उद्यम एजेंटों को असली आंतरिक प्रणालियों (टिकटिंग, वित्त, ग्राहक-रिकॉर्ड) में जोड़ना चाहते हैं, जिसका मतलब है एजेंट असली पहुँच-नियंत्रण और असली बदलाव-प्रबंधन बाध्यताएँ विरासत में लेते हैं। सरकार सार्वजनिक जवाबदेही जोड़ती है: किसी नागरिक को प्रभावित करने वाली स्वायत्त क्रिया को बाद में समझाने-योग्य, निगरानी-योग्य, और ऑडिट-योग्य होना चाहिए। यह पैटर्न शक्तिशाली है। बिना अनुशासन के तैनात, यह ग़लतियों को स्वचालित करने का तेज़ तरीक़ा है।

मुख्य सिद्धांत

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

सिफ़ारिशें

वर्कफ़्लो से शुरू करें, स्वायत्तता सिर्फ़ वहीं जोड़ें जहाँ ज़रूरी हो

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

टूल-इस्तेमाल को मुख्य क्षमता बनाएँ, और इसे सुरक्षित बनाएँ

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

स्पष्ट तर्क और योजना-पैटर्न इस्तेमाल करें

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

गंभीर क्रियाओं के लिए मनुष्यों को लूप में रखें

हर टूल और हर क्रिया के लिए तय करें कि क्या मॉडल अकेले काम कर सकता है या पहले पूछना चाहिए। उलट-सकने-योग्य, कम-दाँव वाली क्रियाएँ (खोजना, लिखना) बिना निगरानी के चल सकती हैं। गंभीर या न-उलट-सकने-योग्य क्रियाओं (बाहरी संचार भेजना, पैसा हिलाना, उत्पादन-डेटा बदलना, किसी नागरिक के मामले का फ़ैसला करना) को “ना” कहने के असली अधिकार वाले ह्यूमन-इन-द-लूप गेट की ज़रूरत है। जहाँ भी संभव हो पलटने-योग्यता के लिए डिज़ाइन करें: किसी बदलाव को कमिट करने के बजाय स्टेज करने को प्राथमिकता दें, और अनडू को प्रथम-श्रेणी फ़ीचर बनाएँ ताकि कोई ग़लत क्रिया किसी घटना के बजाय मिनट ख़र्च करे।

सुरक्षा-मॉडल को शत्रुतापूर्ण मानें

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

कार्य-सफलता पर मूल्यांकन करें और ग़ैर-निर्धारणवाद का रिग्रेशन-परीक्षण करें

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

ऑब्ज़र्वेबिलिटी, लागत, और विफलता-प्रबंधन के लिए रनों को इंस्ट्रूमेंट करें

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

ट्रेड-ऑफ़: फ़ायदे और नुक़सान

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

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

अपनी टीम के साथ चर्चा के लिए प्रश्न

1. क्या इस फ़ीचर को वाक़ई किसी एजेंट की ज़रूरत है, या कोई तय वर्कफ़्लो ज़्यादा सुरक्षित और सस्ता होगा? स्वायत्तता लुभावनी है, पर ज़्यादातर काम में जानने-योग्य क़दम होते हैं जिन्हें कोई व्यवस्थित पाइपलाइन कहीं कम जोख़िम के साथ संभालती है। बड़ी टीम के लिए, एजेंटों को डिफ़ॉल्ट बनाने का मतलब है हर समूह वह मूल्यांकन, ट्रेसिंग, और सुरक्षा-बोझ उठाता है जिसे कोई सरल डिज़ाइन टाल देता। विशिष्ट काम लाएँ और पूछें कि क्या उसके क़दम पहले से तय किए जा सकते हैं; अगर हाँ, तो कोई एजेंट संभवतः अति-इंजीनियरिंग है। खुले-अंत वाली स्वायत्तता उन लक्ष्यों के लिए बचाकर रखें जहाँ रास्ता वाक़ई हर मामले में बदलता है। उत्तर को ज़्यादातर फ़ीचरों को किसी वर्कफ़्लो की तरफ़ धकेलना चाहिए और सच्चे एजेंटों का एक छोटा, जान-बूझकर चुना गया सेट छोड़ना चाहिए।

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

3. हमें कैसे पता चलेगा कि किसी एजेंट की सफलता-दर गिर गई है, जबकि हर रन प्रशंसनीय लगता है? एजेंट ग़ैर-निर्धारणवादी हैं, इसलिए कोई ट्रांसक्रिप्ट जो अच्छा पढ़ता है फिर भी ग़लत क्रिया ले सकता था, और एक हरा रन कुछ भी साबित नहीं करता। पूछें कि क्या आपके पास जाँचने-योग्य नतीजों वाला लक्ष्यों का मूल्यांकन-सेट है, हर मामले को कई बार चलाकर एक अकेले पास के बजाय सफलता-दर बनाई जाती है। ऊँचे-दाँव या सार्वजनिक तैनातियों के लिए, चर्चा करें कि रन-ट्रेस आपको कुछ ग़लत होने पर ठीक-ठीक यह फिर से बनाने देते हैं कि क्या हुआ (अध्याय 6.5 और 6.6)। अगर आपका इकलौता संकेत उपयोगकर्ता-शिकायतें हैं, तो आप पहले से बहुत देर कर चुके हैं। उत्तर को किसी घटना के बाद नहीं, पैमाने से पहले एक मूल्यांकन-हार्नेस वित्त-पोषित करना चाहिए।

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

5. क्या हम बहु-एजेंट डिज़ाइन तक इसलिए पहुँच रहे हैं क्योंकि काम वाक़ई विभाजित होता है, या क्योंकि यह सुरुचिपूर्ण दिखता है? विशेषज्ञ एजेंटों में काम बाँटना लुभावना है, फिर भी हर अतिरिक्त एजेंट समन्वय-ओवरहेड और किसी छोटी त्रुटि के ग़लत नतीजे में चक्रवृद्धि होने की एक और जगह जोड़ता है। बड़े संगठन के लिए लागत सिर्फ़ ख़र्च और विलंब नहीं है: बहु-एजेंट प्रणाली को विफल होने पर ट्रेस, मूल्यांकित, और समझना कहीं कठिन है, इसलिए शासन-बोझ हर भूमिका जोड़ने के साथ गुणा होता है। काम लाएँ और ठोस रूप से दिखाएँ कि कौन-से हिस्से स्वतंत्र रूप से और समानांतर में चलते हैं, फिर उसी मूल्यांकन-सेट पर बहु-एजेंट संस्करण की मापी गई सफलता-दर और लागत की एक अकेले एजेंट से तुलना करें। अगर अकेला एजेंट जीतता है या बराबर रहता है, तो सुरुचिपूर्ण डिज़ाइन अति-इंजीनियरिंग है। विनियमित या सार्वजनिक तैनातियों के लिए, याद रखें कि शृंखला में हर एजेंट एक और घटक है जिसका किसी निगरानी-निकाय को निरीक्षण करने में सक्षम होना चाहिए, इसलिए ऐसी जोड़ी गई संरचना जिसे आप उचित नहीं ठहरा सकते, जोड़ी गई देनदारी है।

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

क्षेत्र-लेंस

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

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

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

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

उदाहरण

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

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

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

व्यवसाय-मामला: प्रेरणाएँ, आरओआई, और टीसीओ

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

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

एंटी-पैटर्न और नुक़सान

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

परिपक्वता मॉडल

• स्तर 1, आरंभ: एजेंट चौड़ी टूल-पहुँच और बिना सीमा के तदर्थ प्रोटोटाइप किए जाते हैं। सफलता डेमो से आँकी जाती है, प्रतिक्रियात्मक रूप से, कुछ टूटने के बाद। कोई मूल्यांकन-सेट नहीं, कोई ट्रेसिंग नहीं, और गंभीर क्रियाओं पर कोई मानव-गेट नहीं।
• स्तर 2, विकास: कुछ एजेंटों में सीमित लूप और न्यूनतम-विशेषाधिकार टूल हैं, और बुनियादी ट्रेसिंग मौजूद है, पर अभ्यास टीम-दर-टीम बदलता है। एक मैनुअल मूल्यांकन-सेट कुछ परियोजनाओं में बड़े रिग्रेशन पकड़ता है जबकि दूसरों में कोई नहीं है। मानव-मंज़ूरी सबसे स्पष्ट न-उलट-सकने-योग्य क्रियाओं की रक्षा करती है, फिर भी कवरेज असमान और अदस्तावेज़ित है।
• स्तर 3, मानकीकरण: साझा पैटर्न स्वायत्तता, टूल-अनुमतियों, सैंडबॉक्सिंग, और ह्यूमन-इन-द-लूप गेट को शासित करते हैं, हर टीम में दस्तावेज़ित और लागू। हर गंभीर क्रिया गेटेड या सत्यापित है, एजेंट छोर-से-छोर ट्रेस होते हैं, और सफलता-दर स्कोरिंग वाला एक स्वचालित मूल्यांकन-सेट हर बदलाव पर चलता है। प्रॉम्प्ट-इंजेक्शन को एक स्थायी ख़तरे के रूप में एक परिभाषित प्रतिक्रिया के साथ माना जाता है।
• स्तर 4, प्रबंधन: एजेंट-पोर्टफ़ोलियो को आधार-रेखाओं के मुक़ाबले मापा और नियंत्रित किया जाता है। प्रति-कार्य सफलता-दर, प्रॉम्प्ट-इंजेक्शन रक्षा पास-दर, प्रति-रन लागत और क़दम-गिनती, मानव-मंज़ूरी-विलंब, और लूप या विफलता-घटनाएँ मेट्रिक्स के रूप में ट्रैक की जाती हैं; रोलबैक और किल-सीमाएँ शिकायतों के बजाय उस प्रमाण पर लागू होती हैं। क़दमों, समय, और ख़र्च पर प्रति-रन बजट निगरानी में रहते हैं, और किसी भी मेट्रिक में रिग्रेशन पैमाने से पहले कार्रवाई ट्रिगर करता है, किसी घटना के बाद नहीं।
• स्तर 5, संयोजन: स्वायत्तता को नीति से कार्य-जोख़िम से मिलाया जाता है और नतीजे आने के साथ लगातार समायोजित किया जाता है। चालू ऑफ़लाइन और ऑनलाइन मूल्यांकन एजेंट-व्यवहार को व्यावसायिक नतीजों से जोड़ता है, और जोख़िम-तस्वीर बदलने के साथ संगठन नियमित रूप से एजेंटों को सेवानिवृत्त, फिर से दायरा, या फिर से अनुमति देता है। ट्रेसिंग, लागत-बजट, और ऑडिट-ट्रेल पोर्टफ़ोलियो में समान हैं; इंजेक्शन और कन्फ़्यूज़्ड-डिप्यूटी रक्षाओं का शत्रुतापूर्ण परीक्षण होता है; स्वायत्त क्रियाओं की जवाबदेही स्पष्ट और ऑडिट-योग्य है।

चर्चा के लिए विचार

1. आपके कौन-से मौजूदा एलएलएम-फ़ीचर चुपचाप एजेंट बन गए हैं, और क्या हर एक की स्वायत्तता जान-बूझकर सीमित की गई है?
2. हर एजेंट-टूल के लिए, कोई हमलावर इंजेक्टेड सामग्री के ज़रिए इसका दुरुपयोग करने का सबसे सस्ता तरीक़ा क्या है, और उसे क्या रोकता है?
3. आपने कहाँ बहु-एजेंट डिज़ाइन चुने हैं, और क्या आप दिखा सकते हैं कि समन्वय-लागत किसी अकेले एजेंट के मुक़ाबले फल देती है?
4. कौन-सी एजेंट-क्रियाएँ वाक़ई न-उलट-सकने-योग्य हैं, और क्या उन सभी को उलट-सकने-योग्य या स्टेज्ड बनाने के लिए फिर से डिज़ाइन किया जा सकता है?
5. अगर कल कोई एजेंट कोई हानिकारक क्रिया कर दे, क्या आप ठीक-ठीक फिर से बना सकते हैं कि उसने क्या किया और कौन जवाबदेह था?

मुख्य निष्कर्ष

• एजेंट टूल, स्मृति, और एक लक्ष्य वाले लूप में एक एलएलएम है। जोख़िम लूप और टूलों में रहता है, पाठ में नहीं।
• जब क़दम ज्ञात हों तो तय वर्कफ़्लो को प्राथमिकता दें; स्वायत्तता वाक़ई खुले-अंत वाले लक्ष्यों के लिए बचाकर रखें और इसे कसकर सीमित करें।
• टूल-इस्तेमाल मुख्य क्षमता है। हर टूल को न्यूनतम विशेषाधिकार, सत्यापित स्कीमा, और सैंडबॉक्स दें।
• गंभीर और न-उलट-सकने-योग्य क्रियाओं को असली अधिकार वाले किसी मनुष्य के पीछे गेट करें, और सस्ते पलटाव के लिए डिज़ाइन करें।
• एजेंटों को शत्रुतापूर्ण मानें: प्रॉम्प्ट-इंजेक्शन और कन्फ़्यूज़्ड-डिप्यूटी दुरुपयोग से बचाव करें (अध्याय 4.2)।
• कई रनों में कार्य-सफलता-दर पर मूल्यांकन करें, और डिबगिंग, लागत-नियंत्रण, और ऑडिट के लिए हर रन को ट्रेस करें (अध्याय 6.5 और 6.6)।
• अक्सर सही उत्तर बिल्कुल कोई एजेंट न बनाना है।

संदर्भ और आगे पढ़ने के लिए

• शुन्यु याओ एट अल., ReAct: सिनर्जाइज़िंग रीज़निंग एंड एक्टिंग इन लैंग्वेज मॉडल्स।
• टिमो शिक एट अल., टूलफ़ॉर्मर: लैंग्वेज मॉडल्स कैन टीच देमसेल्व्स टू यूज़ टूल्स।
• एंथ्रोपिक, बिल्डिंग इफ़ेक्टिव एजेंट्स (वर्कफ़्लो बनाम एजेंट पर इंजीनियरिंग मार्गदर्शन)।
• OWASP फ़ाउंडेशन, OWASP टॉप 10 फ़ॉर लार्ज लैंग्वेज मॉडल एप्लिकेशन्स (प्रॉम्प्ट-इंजेक्शन और अत्यधिक एजेंसी सहित)।
• साइमन विलिसन, प्रॉम्प्ट-इंजेक्शन और एआई एजेंटों के लिए “लीथल ट्राइफ़ेक्टा” पर लेखन।
• नॉर्मन हार्डी, द कन्फ़्यूज़्ड डिप्यूटी (कन्फ़्यूज़्ड-डिप्यूटी समस्या का क्लासिक कथन)।
• चिप ह्युएन, एआई इंजीनियरिंग: बिल्डिंग एप्लिकेशन्स विद फ़ाउंडेशन मॉडल्स।
• स्टुअर्ट रसल और पीटर नॉरविग, आर्टिफ़िशियल इंटेलिजेंस: अ मॉडर्न अप्रोच (बुद्धिमान एजेंट और तर्कसंगत क्रिया)।