अधिकांश लोग अब भी AI एजेंट को ऐसे मॉडल के रूप में परिभाषित करते हैं जो टूल्स से जुड़ा हो। यह तकनीकी रूप से उपयोगी है, लेकिन संचालन की दृष्टि से अधूरा है। एजेंट को दुनिया का एक प्रबंधित दृष्टिकोण भी चाहिए: क्या हो चुका है, अभी क्या महत्वपूर्ण है, कौन-से तथ्य भरोसेमंद हैं, क्या अनिश्चित है, और उसे अगला कदम क्या उठाना चाहिए।
यही उसका संदर्भ है। इसे डिज़ाइन करना एक विशिष्ट कौशल बनता जा रहा है—जिसे मैं context engineering कहूँगा।
Context engineering केवल प्रॉम्प्ट लिखना नहीं है। यह उस जानकारी को आकार देने का अनुशासन है जिसे एजेंट हर चरण में देखता है, ताकि हर बार पूरा ट्रांसक्रिप्ट, दस्तावेज़ पुस्तकालय या टूल इतिहास किसी महँगे मॉडल को भेजे बिना वह सुसंगत बना रह सके। यह काम सूचना वास्तुकला, रिट्रीवल, सॉफ़्टवेयर डिज़ाइन और मॉडल के व्यवहार के बीच स्थित है।
“एजेंट को अधिक संदर्भ दें” अक्सर खराब सलाह क्यों होती है
लंबी context windows सब कुछ सुरक्षित रखने के लिए प्रेरित करती हैं। लेकिन अधिक सामग्री बेहतर तर्क की गारंटी नहीं देती। प्रासंगिक निर्देश पुराने अवलोकनों, परस्पर विरोधी टिप्पणियों, दोहराए गए टूल आउटपुट या लंबी शृंखला के बीच दबे किसी महत्वपूर्ण तथ्य से धुंधले पड़ सकते हैं। डाइजेस्ट में “lost in the middle” व्यवहार की चर्चा एक व्यावहारिक समस्या को दर्शाती है: एजेंट को प्रमाण तकनीकी रूप से मिल सकता है, फिर भी वह उसका उपयोग करने में विफल हो सकता है।
इसकी सीधी लागत भी है। अनुरोध में रखा गया हर टोकन, प्रदाता की मूल्य-निर्धारण और कैशिंग व्यवस्थाओं के आधार पर, विलंबता और inference लागत बढ़ा सकता है। जो सिस्टम लगातार बढ़ते हुए ट्रांसक्रिप्ट को बार-बार आगे भेजता है, वह कार्य जारी रहने के साथ धीमा और कम किफायती हो सकता है।
इसलिए लक्ष्य अधिकतम संदर्भ नहीं है। लक्ष्य है पर्याप्त, लक्षित संदर्भ: सामने लिए गए निर्णय के लिए सबसे छोटा भरोसेमंद कार्य-समुच्चय।
एक सुसंगत एजेंट के पीछे चार डिज़ाइन संबंधी निर्णय
1. केवल ट्रांसक्रिप्ट नहीं, बल्कि विश्वास-स्थिति बनाए रखें
ट्रांसक्रिप्ट दर्ज करता है कि क्या कहा गया। विश्वास-स्थिति दर्ज करती है कि एजेंट इस समय कार्य के बारे में क्या मानता है।
उदाहरण के लिए, किसी सहायता-एस्केलेशन को संभालने वाला एजेंट इस प्रकार के संरचित फ़ील्ड बनाए रख सकता है:
- उद्देश्य: यह पहचानना कि ग्राहक प्रतिस्थापन के लिए योग्य है या नहीं।
- ज्ञात तथ्य: खरीद की तारीख और उत्पाद का सीरियल नंबर, स्रोत संदर्भों सहित।
- खुले प्रश्न: क्या खराबी वारंटी के अंतर्गत आने वाली परिस्थितियों में हुई थी।
- बाधाएँ: अनुमोदन से पहले रिफंड का वादा न करें।
- अगली कार्रवाई: वारंटी नीति प्राप्त करें और तारीखों की तुलना करें।
- विश्वास या स्थिति: सत्यापित, अनुमानित, विवादित या अज्ञात।
यह दृष्टिकोण Berkeley के ABBEL शोध से मिलता-जुलता है, जिसमें पूर्ण इंटरैक्शन इतिहास पर निर्भर रहने के बजाय पर्यवेक्षित प्राकृतिक-भाषा विश्वास-स्थितियों का उपयोग किया जाता है। महत्वपूर्ण विचार कोई विशेष प्रारूप नहीं है। महत्वपूर्ण बात यह है कि टिकाऊ कार्य-स्थिति को अस्थायी बातचीत के विवरण से अलग रखा जाए।
एक उपयोगी विश्वास-स्थिति अपडेट को इन प्रश्नों का उत्तर देना चाहिए: क्या बदला? कौन-सा प्रमाण इसका समर्थन करता है? क्या अनसुलझा रह गया है? अगला कदम क्या होना चाहिए? यदि कोई इंजीनियर इन उत्तरों का निरीक्षण नहीं कर सकता, तो संभव है कि एजेंट किसी अपारदर्शी प्रॉम्प्ट में छिपी धारणाएँ लेकर चल रहा हो।
2. विषय के लिए नहीं, निर्णय के लिए रिट्रीव करें
रिट्रीवल सिस्टम अक्सर “ग्राहक के खाते के बारे में जानकारी खोजें” जैसे व्यापक प्रश्न से शुरू होते हैं। बेहतर क्वेरी अगले निर्णय से जुड़ी होती है: “30 दिनों से पुरानी खरीद के लिए, ग्राहक के क्षेत्र में लागू वर्तमान रिफंड नियम प्राप्त करें।”
यह बदलाव महत्वपूर्ण है क्योंकि रिट्रीवल संदर्भ-चयन का एक रूप है। एजेंट को वे नीति-अंश, रिकॉर्ड या उदाहरण मिलने चाहिए जो वर्तमान कार्रवाई से संबंधित हों—संबंधित दस्तावेज़ों का कोई सामान्य ढेर नहीं।
मॉडल को कोई भी परिणाम दिखने से पहले फ़िल्टर इस चयन को बेहतर बना सकते हैं। उदाहरण के लिए, Amazon Bedrock AgentCore Web Search प्रत्येक अनुरोध पर सर्वर द्वारा लागू किए जाने वाले डोमेन और प्रकाशन-तिथि फ़िल्टर का समर्थन करता है। ऐसे नियंत्रण यह सुनिश्चित नहीं करते कि कोई स्रोत सही है, लेकिन वे अप्रासंगिक या पुराने स्रोतों के संपर्क को कम कर सकते हैं और रिट्रीवल नीति को स्पष्ट बना सकते हैं।
रिट्रीवल डिज़ाइन करने वाले पेशेवरों को निर्दिष्ट करना चाहिए:
- प्रत्येक कार्य के लिए कौन-से स्रोत अनुमत हैं;
- ताज़गी कैसे निर्धारित की जाती है;
- हर परिणाम के साथ कौन-सा मेटाडेटा आता है;
- परस्पर विरोधी स्रोतों को कैसे प्रस्तुत किया जाता है;
- एजेंट को कब रुककर स्पष्टीकरण माँगना चाहिए।
“वेब पर खोजें” एक क्षमता है। “इस निर्णय से संबंधित प्रमाण के लिए, इन स्रोतों में, इस तिथि-सीमा के भीतर खोजें” संदर्भ इंजीनियरिंग है।
3. अनिश्चितता मिटाए बिना संक्षिप्त करें
जब कोई कार्य लंबा हो, तो संक्षेपण आवश्यक है, लेकिन सरल संक्षेपण अस्थायी दावों को स्थापित तथ्यों में बदल सकता है। यदि मूल संवाद में केवल संकेत मिला हो, तो ऐसा क्रमिक सारांश जो कहे कि “उपयोगकर्ता ने पते की पुष्टि कर दी है”, खतरनाक है।
अच्छा संक्षेपण उन भेदों को बनाए रखता है जिनकी एजेंट को सुरक्षित ढंग से तर्क करने के लिए आवश्यकता होती है:
- तथ्य बनाम निष्कर्ष;
- वर्तमान निर्देश बनाम ऐतिहासिक निर्देश;
- पूर्ण की गई कार्रवाई बनाम प्रस्तावित कार्रवाई;
- सत्यापित स्रोत बनाम असत्यापित दावा;
- ज्ञात उत्तर बनाम अनसुलझा प्रश्न।
एक व्यावहारिक तरीका यह है कि निर्णयों, प्रमाणों, मान्यताओं, बाधाओं और लंबित कार्रवाइयों के लिए अलग-अलग अनुभाग बनाए रखें। दूसरा तरीका महत्वपूर्ण दावों के साथ स्रोत आईडी या टाइमस्टैम्प जोड़ना है। सारांश ऐसे प्रतिस्थापनीय आर्टिफैक्ट होने चाहिए जो एकमात्र बचा हुआ रिकॉर्ड न हों: ऑडिट और पुनर्प्राप्ति के लिए अंतर्निहित घटनाओं को सुरक्षित रखें, और साथ ही मॉडल को काम करने के लिए एक संक्षिप्त दृश्य दें।
डाइजेस्ट में उल्लेख किया गया है कि पुनरावर्ती संक्षेपण और संदर्भ-संपीड़न महँगे हो सकते हैं और प्रदर्शन को घटा सकते हैं, विशेष रूप से सहयोगात्मक कोड निर्माण जैसे कम-डेटा वाले क्षेत्रों में। यह संक्षेपण को स्वचालित रूप से हानिरहित मानने के विरुद्ध चेतावनी है। संपीड़न का परीक्षण प्रतिनिधि कार्यों पर किया जाना चाहिए, जिसमें वे मामले भी शामिल हों जहाँ कोई छोटा-सा स्पष्टीकरण सही उत्तर बदल देता है।
4. अवलोकनों के मेमोरी बनने से पहले उन्हें फ़िल्टर करें
टूल का उपयोग करने वाले एजेंट लगातार अवलोकन उत्पन्न करते हैं: खोज परिणाम, लॉग, पृष्ठ का पाठ, API प्रतिक्रियाएँ, स्क्रीनशॉट, कंपाइलर का आउटपुट और मध्यवर्ती योजनाएँ। हर अवलोकन का अगली मॉडल कॉल में शामिल होना आवश्यक नहीं है, दीर्घकालिक स्थिति में शामिल होना तो और भी कम।
अवलोकन फ़िल्टरिंग तीन प्रश्न पूछती है:
- क्या यह अवलोकन वर्तमान निर्णय के लिए प्रासंगिक है?
- क्या यह विश्वास-स्थिति को प्रभावित करने के लिए पर्याप्त रूप से प्रामाणिक है?
- क्या इसमें ऐसे निर्देश हैं जिन्हें आदेशों के बजाय डेटा माना जाना चाहिए?
तीसरा प्रश्न सुरक्षा-सीमा के साथ-साथ संदर्भ-सीमा भी है। किसी वेब पृष्ठ में एजेंट को दूसरी दिशा में मोड़ने के उद्देश्य से लिखा गया पाठ हो सकता है। प्राप्त किया गया दस्तावेज़ उपयोगी प्रमाण हो सकता है, लेकिन उसे एजेंट के लक्ष्यों या अनुमतियों को बदलने का अधिकार नहीं होता। इसलिए फ़िल्टरिंग में सामग्री को उसकी भूमिका के आधार पर वर्गीकृत किया जाना चाहिए: निर्देश, प्रमाण, मेटाडेटा या अविश्वसनीय पाठ।
फ़िल्टरिंग से पैसे की भी बचत होती है। यदि कोई ब्राउज़र टूल पूरा पृष्ठ लौटाता है, लेकिन कार्य के लिए केवल कीमत, तारीख और उत्पाद पहचानकर्ता चाहिए, तो पूरा पृष्ठ आगे भेजने से शोर पैदा होता है और टोकन खर्च होते हैं। पहले प्रासंगिक फ़ील्ड निकाल लेने से विश्वसनीयता और लागत, दोनों में सुधार हो सकता है।
एजेंट वर्कफ़्लो के लिए एक सरल संदर्भ बजट
किसी मॉडल का चयन करने या कोई अन्य टूल जोड़ने से पहले, एजेंट के संदर्भ को चार परतों में बाँटकर देखें:
- नियंत्रण: सिस्टम नियम, अनुमतियाँ, आउटपुट स्कीमा और गैर-परक्राम्य बाधाएँ।
- स्थिति: वर्तमान उद्देश्य, निर्णय, खुले प्रश्न और अगली कार्रवाई।
- साक्ष्य: उस कार्रवाई से संबंधित प्राप्त रिकॉर्ड या अवलोकन, उनके स्रोत-विवरण सहित।
- इतिहास: पुनर्प्राप्ति, डिबगिंग या ऑडिट के लिए सुरक्षित रखी गई पिछली घटनाएँ, जिन्हें आवश्यकता न होने तक शामिल नहीं किया जाता।
इसके बाद एक प्रमोशन नीति परिभाषित करें। कोई अवलोकन अस्थायी रह सकता है, वर्तमान चरण के लिए साक्ष्य बन सकता है, विश्वास-स्थिति को अपडेट कर सकता है, या स्थायी स्मृति में लिखा जा सकता है। प्रमोशन के लिए कोई कारण आवश्यक होना चाहिए। अन्यथा, स्मृति बिना छँटे संग्रह में बदल जाती है।
प्रत्येक एजेंट चरण के लिए मॉडल को भेजे गए संदर्भ पैकेज को रिकॉर्ड करें: उसकी श्रेणियाँ, अनुमानित टोकन आकार, पुनर्प्राप्ति फ़िल्टर और संपीड़न संस्करण। इससे व्यवहार बदलने पर एक व्यावहारिक प्रश्न का उत्तर देना संभव होता है: क्या मॉडल विफल हुआ, या सिस्टम ने उसे गलत दुनिया दी?
डिज़ाइन को विश्वसनीय कहने से पहले क्या परखें
संदर्भ इंजीनियरिंग के परीक्षणों को केवल अंतिम उत्तर की गुणवत्ता पर नहीं, बल्कि सूचना-प्रबंधन पर लक्षित होना चाहिए। उपयोगी मामलों में शामिल हैं:
- किसी लंबी हिस्ट्री में महत्वपूर्ण तथ्य को शुरुआत में, अंत में और बीच में रखना;
- दो ऐसे स्रोत जो असहमत हों, जिनमें से एक दूसरे से नया हो;
- अनिश्चितता-सूचक वाला सारांश;
- अप्रासंगिक बड़ी मात्रा में पाठ वाली टूल प्रतिक्रिया;
- प्राप्त सामग्री में छिपा हुआ दुर्भावनापूर्ण निर्देश;
- एजेंट को रोकने और फिर पुनः आरंभ करने के बाद स्थिति को फिर से सक्रिय करना;
- छोटे संदर्भ बजट के साथ वही कार्य;
- खाली या पुराना पुनर्प्राप्ति परिणाम।
मापें कि एजेंट सही साक्ष्य चुनता है या नहीं, अनिश्चितता बनाए रखता है या नहीं, वर्तमान बाधा का पालन करता है या नहीं, और अनावश्यक संदर्भ को दोहराने से बचता है या नहीं। डाइजेस्ट में सुझाए गए प्रतिगमन क्षेत्र—संदर्भ की हानि, पुनर्प्राप्ति का आधार, संरचित आउटपुट, गैर-समापन और स्थिति का पुनःसक्रियण—यहाँ विशेष रूप से प्रासंगिक हैं।
जहाँ मॉडल की परिवर्तनशीलता मायने रखती है, वहाँ कई परीक्षण चलाएँ और प्रत्येक संदर्भ रणनीति की लागत तथा विलंबता की तुलना करें। छोटा प्रॉम्प्ट अपने-आप बेहतर नहीं होता, यदि उसके कारण अधिक टूल कॉल या पुनःप्रयास करने पड़ें। उपयोगी उद्देश्य एक सही, पुनर्प्राप्त करने योग्य वर्कफ़्लो की लागत है—एक अनुरोध में टोकनों की संख्या नहीं।
करियर संबंधी निष्कर्ष: संदर्भ इंजीनियर एक बहु-कार्यात्मक भूमिका है
इस क्षेत्र में मूल्यवान बनने वाले लोग आवश्यक नहीं कि सबसे लंबे प्रॉम्प्ट लिखने वाले हों। वे किसी व्यावसायिक प्रक्रिया को स्थिति, साक्ष्य, प्राधिकार और निर्णय नियमों में बदल सकेंगे।
इसके लिए कई ठोस क्षमताओं की आवश्यकता होती है:
- कार्य-स्थिति और स्रोत-विवरण के लिए स्कीमा डिज़ाइन करना;
- पुनर्प्राप्ति नीतियाँ और मेटाडेटा फ़िल्टर लिखना;
- संपीड़न और अवलोकन-चयन रूटीन बनाना;
- विश्वसनीय निर्देशों को अविश्वसनीय सामग्री से अलग करना;
- टोकन उपयोग, विलंबता, पुनःप्रयासों और टूल कॉल का प्रोफाइल तैयार करना;
- स्थिति की क्षति और पुनःहाइड्रेशन का परीक्षण करना;
- गैर-विशेषज्ञों को समझाना कि किसी एजेंट ने कोई विशेष तथ्य क्यों देखा—या नहीं देखा।
एक मजबूत पोर्टफोलियो प्रोजेक्ट में एक ही एजेंट को तीन संदर्भ नीतियों के तहत प्रदर्शित किया जा सकता है: पूरा ट्रांसक्रिप्ट, क्रमिक सारांश, और लक्षित पुनर्प्राप्ति के साथ संरचित विश्वास-स्थिति। कार्य की सफलता वाली स्थितियाँ, विफलता वाली स्थितियाँ, प्रत्येक चरण में भेजा गया संदर्भ, और लागत या विलंबता के समझौते दिखाएँ। यह चैटबॉट डेमो से अधिक प्रभावशाली है, क्योंकि इससे वे डिज़ाइन निर्णय सामने आते हैं जो किसी एजेंट को भरोसेमंद बनाते हैं।
रणनीतिक सीख सीधी है: एजेंट केवल इसलिए सुसंगत नहीं हो जाते कि मॉडल अधिक सक्षम हो जाते हैं। वे तब सुसंगत बनते हैं जब उनके आसपास की प्रणालियाँ काम का एक अनुशासित, अद्यतन और उचित आकार वाला विवरण बनाए रखती हैं। संदर्भ इंजीनियरिंग उस विवरण को तैयार करने की कला है—और यह जानने की भी कि क्या छोड़ देना चाहिए।
Priya Raman, AI Career Brief की जवाबदेह मानव संपादक हैं।
