संदर्भ, नियंत्रण नहीं

संदर्भ, नियंत्रण नहीं

आपके एजेंट के प्रॉम्प्ट में हर नियम एक बग के रूप में शुरू हुआ था।

किसी ने ख़राब व्यवहार देखा, एक नियम लिखा, आगे बढ़ गया। किसी और ने वही किया। एक तीसरे व्यक्ति ने एक "कभी X मत करो" जोड़ दिया क्योंकि मॉडल ने किसी मंगलवार को एक बार कुछ अजीब किया था। किसी ने कुछ भी नहीं हटाया।

छह महीने बाद एजेंट अपने संदर्भ-विंडो (context window) का ज़्यादा हिस्सा असली काम के बारे में सोचने के बजाय अपनी नियम-पुस्तिका में रास्ता ढूँढ़ने में ख़र्च कर रहा है।

यह नियंत्रण-शैली की सोच है। और मुझे लगता है कि AI एजेंट बनाते समय टीमें जो सबसे बड़ी डिज़ाइन ग़लतियाँ करती हैं, यह उनमें से एक है।

एक छोटा उदाहरण जो एक बड़ा पैटर्न उजागर करता है

हम एक समस्या से टकराए जहाँ किसी शेड्यूल किए गए काम से ट्रिगर हुआ एक एजेंट रन के भीतर से बार-बार नए शेड्यूल किए गए काम बनाता रहा। अनंत पुनरावृत्ति (infinite recursion), बस असली-दुनिया के दुष्प्रभावों के साथ।

जवाब देने के दो तरीक़े।

नियंत्रण शैली: इसे बैन कर दो। ऐसा कोड लिखो जो शेड्यूल को शेड्यूल बनाने से रोके। एक प्रॉम्प्ट नियम जोड़ो: "किसी शेड्यूल के भीतर कभी शेड्यूल मत बनाओ।" इसे भेज दो।

संदर्भ शैली: एजेंट को बताओ कि वास्तव में क्या हो रहा है।

आपको प्रशांत समय के अनुसार सुबह 3:00 बजे एक शेड्यूल किए गए काम ने ट्रिगर किया था। शेड्यूल ID: sched_29x8f। एक शेड्यूल किया गया रन एक पृथक निष्पादन है जिसका एक परिभाषित दायरा है जिसे उपयोगकर्ता ने मूल रूप से अधिकृत किया था। एक नया शेड्यूल किया गया काम बनाने से वह दायरा मूल अधिकृतीकरण से आगे बढ़ जाएगा।

पहला तरीक़ा एक व्यवहार को पैच करता है। दूसरा एजेंट को स्थिति का एक मॉडल देता है।

अब वह आस-पास के सवालों पर भी तर्क कर सकता है: क्या मुझे सुबह 3 बजे एक सूचना भेजनी चाहिए? क्या मुझे एक फ़ॉलो-अप प्रक्रिया बनानी चाहिए जो उपयोगकर्ता ने स्पष्ट रूप से नहीं माँगी? क्या मुझे कुछ ऐसा बदलना चाहिए जो मूल रन के दायरे से आगे बढ़ता है?

किसी नियम की ज़रूरत नहीं। एजेंट ने इसे ख़ुद समझ लिया।

बहुत-सी टीमें नियंत्रण की ओर हाथ बढ़ाती हैं जबकि उन्हें वास्तव में संदर्भ की ज़रूरत होती है।

वही अंतर प्रॉम्प्ट के भीतर भी दिखता है

यह सिर्फ़ सिस्टम-स्तर के प्रवर्तन के बारे में नहीं है। संदर्भ बनाम नियंत्रण का बँटवारा प्रॉम्प्ट के भीतर भी मौजूद है।

संदर्भ-शैली का प्रॉम्प्टिंग: ज़्यादातर तथ्य, न्यूनतम राय:

आप एक शेड्यूल किए गए काम की वजह से चल रहे हैं। बीजिंग समय के अनुसार सुबह 3:00 बजे ट्रिगर हुआ। काम ID: sched_29x8f। उपयोगकर्ता ने इस रन को एक विशिष्ट दायरे के लिए अधिकृत किया।

नियंत्रण-शैली का प्रॉम्प्टिंग: राय-भरा, निर्देशात्मक:

शेड्यूल बनाने से बचो। तुम्हें टूल X से उपयोगकर्ता को सूचित करना चाहिए। Z के बिना कभी Y मत करो।

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

प्रॉम्प्ट कैसे नौकरशाही बन जाते हैं

यह गहरा विफलता-तरीक़ा है।

एक टीम एक समस्या देखती है और एक नियम जोड़ती है। फिर एक और। फिर एक और। हर एक एक स्थानीय समस्या को पैच करता है, पर मिलकर वे प्रॉक्सी से भरा एक सिस्टम बना देते हैं।

Bezos ने अपने 2016 के शेयरधारक पत्र में इस पैटर्न का वर्णन किया: अच्छी प्रक्रिया आपकी सेवा करती है ताकि आप ग्राहकों की सेवा कर सकें। पर अगर आप सावधान न हों, तो प्रक्रिया ही असली चीज़ बन जाती है।

एजेंट सिस्टम में ठीक यही होता है।

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

मानव संगठनों में, यह नौकरशाही बन जाती है। एजेंट सिस्टम में, यह घाव के निशानों (scar tissue) से भरा एक विशाल प्रॉम्प्ट बन जाती है।

तथ्य पुराने पड़ते हैं। राय सड़ती हैं।

"यह रन सुबह 3 बजे एक शेड्यूल किए गए काम ने ट्रिगर किया था" जैसा तथ्य स्थिर है। यह सच रहता है चाहे इसे कोई भी मॉडल पढ़े: Claude, GPT, Gemini, अगली तिमाही में जो भी आए।

"तुम्हें उप-शेड्यूल बनाने से बचना चाहिए" जैसा कथन नाज़ुक है। यह व्याख्या पर निर्भर करता है। यह एक स्थिति में मदद कर सकता है और दूसरी में चुपचाप ग़लत निशाने पर जा सकता है।

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

लेकिन एनवायरनमेंट, अनुमतियों, दायरे और बाधाओं के बारे में आधारित तथ्य मॉडल और किनारे के मामलों के पार सामान्यीकृत होते हैं। इसीलिए तथ्य बेहतर निर्माण-सामग्री हैं।

मॉडल-विचित्रता का जाल

यह नियंत्रण समस्या का शायद सबसे कपटी संस्करण हो सकता है: टीमें लगातार अस्थायी मॉडल दोषों को स्थायी सिस्टम संरचना में बदल देती हैं।

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

वह पैच एक दाँव है कि वह विचित्रता बनी रहेगी। यह लगभग कभी नहीं रहती।

तीन महीने बाद, मॉडल बदल जाता है। मूल व्यवहार ग़ायब हो जाता है। पर पैच बना रहता है। कोई इसे हटाना नहीं चाहता, क्योंकि शायद यह किसी कारण से वहाँ था।

इसी तरह सिस्टम प्रॉम्प्ट लीगेसी कोड बन जाते हैं।

अमूर्त रूप से कहने पर हम ख़तरे को आसानी से पहचान सकते हैं। पर व्यवहार में, Sonnet की मौजूदा तर्क प्रवृत्तियों को प्रॉम्प्ट दर प्रॉम्प्ट पैच करना भेस बदलकर वही पैटर्न है।

स्थिर सिस्टम व्यवहार का दस्तावेज़ीकरण मूल्यवान है। किसी मॉडल की तर्क प्रवृत्तियों को पैच करना एक ट्रेडमिल है। मॉडल आपके नीचे उससे तेज़ी से बदलेगा जितनी तेज़ी से आप अपने पैच बनाए रख सकें।

एक अच्छा परीक्षण मामला: अनुमति अस्वीकृत

आप यह अंतर टूल डायग्नोस्टिक्स में साफ़ देख सकते हैं। जब एक एजेंट किसी अनुमति त्रुटि से टकराता है:

नियंत्रण शैली:

TOKEN ग़ायब है। इसे ठीक करने के लिए "zero permissions request gmail.send" चलाएँ।

सीधा, पर एजेंट कुछ नहीं सीखता। अगली बार जब यह किसी अलग अनुमति त्रुटि से टकराता है, तो यह फँस जाता है।

संदर्भ शैली:

process.env.GMAIL_TOKEN → मौजूद है zero connectors inspect gmail → कनेक्टेड zero permissions inspect gmail.send → अस्वीकृत

विकल्प:

1. gmail.send के लिए उपयोगकर्ता की मंज़ूरी माँगें
2. यदि कोई पहले से अधिकृत रास्ता मौजूद हो तो उसका इस्तेमाल करें

एजेंट अब जानता है कि टोकन मौजूद है, कनेक्टर काम करता है, और विशिष्ट अनुमति अस्वीकृत है। यह सिस्टम की स्थिति को समझता है और ऐसे नए हालात पर तर्क कर सकता है जिनका नियम-लेखक ने कभी अनुमान नहीं लगाया।

अंगूठे का नियम (heuristic)

यह वह है जिस पर मैं बार-बार लौटता हूँ:

जब भी आप किसी प्रॉम्प्ट में "मत करो," "बचो," या "कभी नहीं" लिखने वाले हों। रुकें। पूछें: यह नियम किस तथ्य की भरपाई कर रहा है?

आम तौर पर एक ग़ायब तथ्य होता है। एजेंट नहीं समझता कि वह किस एनवायरनमेंट में है, उपयोगकर्ता ने क्या अधिकृत किया, कौन-सी कार्रवाइयाँ अपरिवर्तनीय हैं, या यह रन एक सामान्य चैट इंटरैक्शन से क्यों अलग है।

वह तथ्य लिख डालें। नियम हटा दें।

कभी-कभी आप फिर भी बाधा चाहेंगे, ख़ास तौर पर विनाशकारी कार्रवाइयों, पैसे की आवाजाही, या सुरक्षा सीमाओं के इर्द-गिर्द। कठोर नियंत्रण अब भी मायने रखते हैं।

पर कई प्रॉम्प्ट नियम असली सीमाएँ नहीं हैं। वे ग़ायब समझ की भरपाई हैं। और ठीक वही हैं जो ढेर लगते हैं और सड़ते हैं।

लक्ष्य

लक्ष्य एक ऐसा एजेंट नहीं है जो किसी चेकलिस्ट को रटता है।

लक्ष्य एक ऐसा एजेंट है जो अपनी स्थिति को इतना अच्छी तरह समझता है कि स्पष्ट सीमाओं के भीतर अच्छे फ़ैसले ले सके।

एक दर्शन नियम जमाकर व्यवहार को नियंत्रित करता है। दूसरा दुनिया को सुपाठ्य बनाकर व्यवहार को बेहतर करता है।

पहला नौकरशाही की ओर झुकता है। दूसरा समझ की ओर झुकता है।

संदर्भ बनाएँ। घाव के निशान हटाएँ। ऐसे एजेंट भेजें जो सोच सकें।