एआई एजेंटों की छोटी दुनिया में, इस समय का शब्द संदर्भ इंजीनियरिंग है।

ऐसा लगता है जैसे किसी चीज़ को बेचने के लिए एक और लेबल का आविष्कार किया गया है जिसे हम पहले ही बेच चुके हैं। आंशिक रूप से यह है. हालाँकि, जैसा कि अक्सर होता है, लेबल पकड़ में आ जाता है क्योंकि यह वास्तविक दर्द को एक नाम देता है।

दर्द यह है: मॉडल केवल इसलिए विफल नहीं होते क्योंकि वे "सोचते नहीं" हैं। वे अक्सर असफल हो जाते हैं क्योंकि हम उन्हें गलत कमरे में काम करने के लिए भेज देते हैं।

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

संकेत वह वाक्यांश है जिसे आप कहते हैं। संदर्भ वह दुनिया है जिसे आप इसके चारों ओर तैयार करते हैं।

शीघ्र इंजीनियरिंग से संदर्भ इंजीनियरिंग तक

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

कॉन्टेक्स्ट इंजीनियरिंग आर्किटेक्चर के करीब है।

आप बस यह न पूछें कि "मैं अनुरोध कैसे तैयार करूं?"। यह पूछता है:

• वास्तव में किस जानकारी की आवश्यकता है? -शोर क्या हैं?
• तुरंत क्या पुनर्प्राप्त करने की आवश्यकता है?
• क्या याद रखना चाहिए?
• कौन से उपकरण उजागर होने चाहिए?
• कौन से निर्देश स्थिर हैं और कौन से कार्य पर निर्भर हैं?
• मैं एजेंट को कैसे समझाऊं कि आधिकारिक क्या है?

यह एक सूक्ष्म लेकिन बहुत बड़ा बदलाव है. क्योंकि जब आप एजेंटों के साथ काम करते हैं, तो संदर्भ एक स्थिर ब्लॉक नहीं होता है। यह हर कदम पर बदलता है.

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

यह इंजीनियरिंग है.

संदर्भ कोई लैंडफिल नहीं है

बड़ी संदर्भ विंडो वाले टेम्प्लेट ने हमें एक प्रलोभन दिया: आइए सब कुछ डाल दें।

यह समझ में आता है. यदि मेरे पास दस लाख टोकन हैं, तो मुझे क्यों चुनना चाहिए?

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

अच्छे संदर्भ में एक पदानुक्रम होता है:

1. सिस्टम निर्देश और नीतियां;
2. विशिष्ट उद्देश्य;
3. वर्तमान स्थिति;
4. प्रासंगिक डेटा;
5. बाधाएं;
6. उपलब्ध उपकरण;
7. पहले से लिए गए निर्णयों पर नज़र रखें।

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

कॉन्टेक्स्ट इंजीनियरिंग का मतलब सिर्फ डेटा ही नहीं बल्कि वेटेज देना भी है।

##याददाश्त: कम याद रखें, बेहतर याद रखें

एजेंटों में स्मृति सबसे फिसलन भरे विषयों में से एक है।

एक उपयोगकर्ता के रूप में, आप चाहते हैं कि एजेंट आपको जाने। आप चाहते हैं कि वह लहज़े, योजना, परंपराएँ, पहले से तय की गई चीज़ें याद रखें। एक इंजीनियर के रूप में, आप जानते हैं कि हर स्थायी स्मृति भी एक जोखिम है: यह गलत, पुरानी, ​​​​बहुत व्यक्तिगत, बहुत सामान्य, अप्राप्य हो सकती है।

एक उपयोगी मेमोरी में कम से कम तीन गुण होने चाहिए:

• उत्पत्ति: यह जानकारी कहां से आती है?
• दिनांक: यह कब सच था?
• उद्देश्य: इसका उपयोग किस प्रकार के कार्य के लिए किया जाना चाहिए?

इन तीन चीजों के बिना याददाश्त अंधविश्वास बन जाती है।

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

एक अच्छी प्रणाली को इस रखरखाव को सामान्य बनाना होगा। वीर नहीं.

पुनर्प्राप्ति और उपकरण एक ही चीज़ नहीं हैं

जब हम संदर्भ के बारे में बात करते हैं, तो हम अक्सर तुरंत RAG पर पहुँच जाते हैं। एंबेडिंग, वेक्टर डेटाबेस, चंकिंग, रीरैंकिंग।

सभी उपयोगी. लेकिन पुनर्प्राप्ति मॉडल में जानकारी लाने का केवल एक तरीका है। वह अकेला नहीं है.

एक एजेंट फाइलों को पढ़कर, एपीआई से पूछताछ करके, एमसीपी सर्वर को कॉल करके, ब्राउज़र खोलकर, परीक्षण चलाकर, स्लैक में खोजकर, डैशबोर्ड को देखकर, मानव से पूछकर संदर्भ प्राप्त कर सकता है।

दिलचस्प हिस्सा यह तय करना है कि किस मार्ग का उपयोग करना है और कब।

यदि एजेंट को किसी ऐतिहासिक प्रश्न का उत्तर देने की आवश्यकता है, तो शायद केवल पुनर्प्राप्ति ही पर्याप्त है। यदि उसे कोई बग ठीक करना है, तो उसे वास्तविक कोड पढ़ना होगा। यदि उसे यह समझने की आवश्यकता है कि परिनियोजन विफल क्यों होता है, तो उसे ताज़ा लॉग देखने की आवश्यकता है। यदि आपको किसी ग्राहक को लिखना है, तो आपको टिकट का स्वर, इतिहास और स्थिति पुनः प्राप्त करनी होगी। यदि उसे उत्पादन पर कार्य करना है, तो उसे अनुमति मांगनी होगी।

प्रसंग कोई डेटाबेस नहीं है. यह एक वर्कफ़्लो है.

अच्छा एजेंट नजरअंदाज करना भी जानता है

एजेंटों में परिपक्वता का संकेत यह कहने की क्षमता होगी: मुझे इस जानकारी की आवश्यकता नहीं है।

यह मामूली लगता है, लेकिन है बहुत कठिन. कई एजेंटिक सिस्टम जमा होते हैं। प्रत्येक टूल कॉल टेक्स्ट जोड़ता है। प्रत्येक त्रुटि बफ़र में रहती है. पढ़ी गई प्रत्येक फ़ाइल स्टैक में जुड़ जाती है। अंत में मॉडल का इतिहास बहुत लंबा है और कोई नक्शा नहीं है।

संपीड़न की आवश्यकता है. मध्यवर्ती संश्लेषण की आवश्यकता है. इसे संरचित करने की आवश्यकता है।

यह नहीं कि "बस इतना ही हुआ", बल्कि:

• उद्देश्य अभी भी मान्य है;
• वर्तमान परिकल्पना;
• फ़ाइलें पहले ही जाँच ली गई हैं;
• किए गए निर्णय;
• खुले जोखिम;
• अगला कदम।

यह एजेंट को कम नाटकीय और अधिक मददगार बनाता है। इसलिए नहीं कि वह अधिक होशियार लगता है, बल्कि इसलिए कि वह साफ-सुथरी डेस्क के साथ काम करता है।

टीमों के लिए संदर्भ इंजीनियरिंग, त्वरित कलाकारों के लिए नहीं

इस विषय में मेरी दिलचस्पी इसलिए है क्योंकि यह जिम्मेदारी को व्यक्ति से सिस्टम पर स्थानांतरित कर देता है।

त्वरित इंजीनियरिंग में, जो मॉडल से सबसे अच्छी तरह बात कर सकता है वह अक्सर जीतता है। संदर्भ इंजीनियरिंग में, वह टीम जीतती है जो अपने काम को बेहतर ढंग से व्यवस्थित करती है: दस्तावेज़ीकरण, सम्मेलन, मुद्दे, लॉग, परीक्षण, स्वामित्व, नामकरण, स्रोत।

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

यह अच्छी और कुछ हद तक असुविधाजनक खबर है. सुंदर इसलिए क्योंकि यह अच्छी प्रथाओं को पुरस्कृत करता है। असुविधाजनक है क्योंकि आप हर चीज़ को एक चतुर संकेत से हल नहीं कर सकते।

एजेंट अपने द्वारा खोजे गए सिस्टम की स्वच्छता को बढ़ाते हैं।

मैं इसे कल कैसे लागू करूंगा

यदि मुझे किसी वास्तविक परियोजना में संदर्भ इंजीनियरिंग का परिचय देना हो, तो मैं छोटी चीज़ों से शुरुआत करूँगा:

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

फिर मैं एक साधारण सी बात मापूंगा: एजेंट को कितनी बार स्पष्टीकरण मांगना पड़ता है या गलत दिशा में चला जाता है?

यदि ऐसा अक्सर होता है, तो मैं तुरंत कोई बड़ा मॉडल नहीं जोड़ूंगा। मैं संदर्भ को देखूंगा.

मेरा पढ़ना

हां, कॉन्टेक्स्ट इंजीनियरिंग थोड़ा फूला हुआ शब्द है। लेकिन अवधारणा सही है.

यह हमें याद दिलाता है कि एक एजेंट की बुद्धिमत्ता सिर्फ मॉडल में नहीं होती है। यह उस वातावरण में निहित है जिसे हम उसके लिए तैयार करते हैं: वह क्या देखता है, वह क्या याद रखता है, वह क्या कर सकता है, उसे क्या करने से मना किया जाता है, वह किन स्रोतों को सत्य मानता है।

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

कम जादू. साफ़-सफ़ाई वाला कमरा. एजेंटों को भी इसकी उतनी ही आवश्यकता है जितनी हमें।

स्रोत

• लैंगचेन ब्लॉग: संदर्भ इंजीनियरिंग का उदय
• साइमन विलिसन: कॉन्टेक्स्ट इंजीनियरिंग
• मॉडल संदर्भ प्रोटोकॉल: परिचय
• एंथ्रोपिक: प्रभावी एजेंटों का निर्माण
• ओपनएआई: बिल्डिंग एजेंटों के लिए नए उपकरण