कॉन्टेक्स्ट इंजीनियरिंग: यह क्या है और बेहतर AI एजेंट बनाने के लिए मैं इसका उपयोग कैसे करता हूं

विषय-सूची

जुलाई 2026 में प्रकाशित।

TL;DR: प्रॉम्प्ट इंजीनियरिंग शब्द चुनाव के बारे में है; कॉन्टेक्स्ट इंजीनियरिंग सूचना वास्तुकला के बारे में है। आपके पास एक सीमित कॉन्टेक्स्ट विंडो है और हर टोकन एक ट्रेडऑफ है। मैं एजेंट कॉन्टेक्स्ट को चार परतों में संरचित करता हूं और विंडो को बजट की तरह मानता हूं। इससे मॉडल बदलने से ज्यादा विश्वसनीयता में सुधार हुआ।

[ऑपरेटर नोट] मैं प्रोडक्शन में 30 से अधिक एजेंट चलाता हूं। पिछले साल जिस सुधार ने सबसे अधिक फर्क किया, वह न तो बेहतर मॉडल है और न ही अधिक परिष्कृत फ्रेमवर्क — यह कॉन्टेक्स्ट विंडो में क्या जाता है और क्या बाहर रहता है, इसके बारे में अधिक जानबूझकर होना है। कॉन्टेक्स्ट इंजीनियरिंग अब वह मुख्य कौशल है जिसे मैं एजेंट कार्य का मूल्यांकन करते समय खोजता हूं।

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

“प्रॉम्प्ट इंजीनियरिंग” गलत फ्रेम क्यों बन गई

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

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

• बातचीत का इतिहास (पिछले मोड़ों में क्या हुआ)
• वे दस्तावेज़ या डेटा जो आपने प्राप्त करके इंजेक्ट किए हैं
• टूल कॉल परिणाम जो मॉडल ने अब तक देखे हैं
• प्रत्येक जानकारी की टोकन गिनती और स्थिति

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

कॉन्टेक्स्ट इंजीनियरिंग वास्तव में क्या है

कॉन्टेक्स्ट इंजीनियरिंग यह तय करने का अनुशासन है कि मॉडल की कॉन्टेक्स्ट विंडो में कौन सी जानकारी जाती है, किस क्रम में, बातचीत के किस बिंदु पर।

कॉन्टेक्स्ट विंडो मॉडल की वर्किंग मेमोरी है। यह सीमित है। आप जो भी टोकन इसमें डालते हैं, वह किसी और चीज़ को विस्थापित करता है — या लागत बढ़ाता है। और मानव वर्किंग मेमोरी के विपरीत, मॉडल के पास विंडो के बाहर कुछ “खोजने” का कोई तरीका नहीं है (जब तक आप इसे ऐसा करने के लिए टूल न दें)। जो यह देखता है वही सब कुछ है जो उसके पास है।

कॉन्टेक्स्ट इंजीनियरिंग उस विंडो को एक संसाधन के रूप में जानबूझकर प्रबंधित करने की प्रथा है:

• इस चरण को पूरा करने के लिए मॉडल को क्या जानना चाहिए?
• पिछले चरण में उसे क्या जानना था लेकिन अब नहीं चाहिए?
• रनों के दौरान क्या स्थिर है बनाम प्रति अनुरोध क्या गतिशील है?
• विंडो में प्रत्येक जानकारी कहां प्रकट होनी चाहिए?

ये प्रॉम्प्ट शब्दावली के बारे में प्रश्न नहीं हैं। ये सूचना वास्तुकला के प्रश्न हैं। और उत्तर एजेंट की विश्वसनीयता को मॉडल चयन जितना ही निर्धारित करते हैं।

मैं जो चार परतें डिज़ाइन करता हूं

मेरे द्वारा बनाए गए प्रत्येक एजेंट में चार अलग कॉन्टेक्स्ट परतें हैं। मैं प्रत्येक के बारे में अलग से सोचता हूं।

परत 1: सिस्टम प्रॉम्प्ट

यह स्थिर, टर्न-स्वतंत्र आधार है। यह परिभाषित करता है कि एजेंट कौन है, क्या कर सकता है, क्या नहीं कर सकता और एज केस को कैसे संभालना चाहिए।

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

1. यह एजेंट किसके लिए है? (मॉडल को एक अस्पष्ट मिशन नहीं, बल्कि एक सटीक दायरे की आवश्यकता है।)
2. जब इनपुट अस्पष्ट या अपूर्ण हो तो क्या करना चाहिए?
3. उसे कभी क्या नहीं करना चाहिए? (नकारात्मक बाधाएं महत्वपूर्ण हैं।)

सिस्टम प्रॉम्प्ट को न्यूनतम रखें। प्रत्येक अनावश्यक वाक्य ओवरहेड है जो गतिशील सामग्री के साथ प्रतिस्पर्धा करता है जहां वास्तविक तर्क होता है।

एक व्यावहारिक सुझाव: यदि आप API के साथ Claude का उपयोग कर रहे हैं, तो अपने सिस्टम प्रॉम्प्ट पर cache_control का उपयोग करें। एक बड़ा, स्थिर सिस्टम प्रॉम्प्ट जो कैश किया गया है, प्रति टर्न गैर-कैश किए गए की तुलना में लगभग 10% लागत आती है।

परत 2: बातचीत इतिहास

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

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

मैं क्या करता हूं:

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

परत 3: पुनः प्राप्त सामग्री

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

मैं जो दो सिद्धांत लागू करता हूं:

केवल वही प्राप्त करें जो वर्तमान चरण के लिए प्रासंगिक है। जब वर्तमान चरण को केवल एक अनुभाग की आवश्यकता हो तो 50-पृष्ठ का दस्तावेज़ इंजेक्ट न करें।

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

परत 4: टूल आउटपुट

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

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

कॉन्टेक्स्ट बजट: क्या शामिल करें और क्या काटें

मैं एक सरल मानसिक मॉडल का उपयोग करता हूं: कॉन्टेक्स्ट विंडो एक बजट है और प्रत्येक टोकन एक खर्च है। प्रत्येक एजेंट टर्न से पहले, मैं पूछता हूं:

• इस चरण को करने के लिए मॉडल को अभी क्या जानना चाहिए?
• बिना कुछ महत्वपूर्ण खोए मैं क्या छोड़ या सारांशित कर सकता हूं?
• परतों में क्या डुप्लिकेट है?

लक्ष्य प्रत्येक चरण में संभव उच्चतम-सिग्नल जानकारी के साथ विंडो भरना है, व्यापक होना नहीं।

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

1. स्थिर उपसर्ग में तैरते टाइमस्टैम्प। मैं अपने सिस्टम प्रॉम्प्ट के शीर्ष पर वर्तमान तिथि: {{तिथि}} डालता था। वह स्ट्रिंग हर दिन बदलती थी, जो हर 24 घंटे में चुपचाप मेरे प्रॉम्प्ट कैश को अमान्य कर देती थी। अस्थिर जानकारी — टाइमस्टैम्प, उपयोगकर्ता आईडी — को स्थिर उपसर्ग के बाद कॉन्टेक्स्ट के अंत में ले जाएं।

2. टूल आउटपुट को केवल-जोड़ने के रूप में मानना। मैं एजेंटिक लूप चलाता था जहां प्रत्येक टूल कॉल परिणाम कॉन्टेक्स्ट में रहता था। टर्न 8 तक, मॉडल एक कॉन्टेक्स्ट से तर्क कर रहा था जो 80% पुराने टूल आउटपुट था।

3. कॉन्टेक्स्ट परिवर्तनों पर मूल्यांकन छोड़ना। कॉन्टेक्स्ट परिवर्तन मॉडल व्यवहार परिवर्तन हैं। मैं अब कॉन्टेक्स्ट परिवर्तनों पर वही मूल्यांकन हार्नेस चलाता हूं जो मैं प्रॉम्प्ट परिवर्तनों पर चलाता हूं।

व्यवहार में मेरा कॉन्टेक्स्ट इंजीनियरिंग वर्कफ़्लो

एजेंट कोड की एक भी पंक्ति लिखने से पहले, मैं कॉन्टेक्स्ट परतों को स्केच करता हूं:

सिस्टम प्रॉम्प्ट:       ~500 टोकन, स्थिर, कैश किया गया
इतिहास बजट:            ~2000 टोकन अधिकतम, प्रत्येक चरण के बाद सारांशित
पुनः प्राप्त कॉन्टेक्स्ट: प्रति चरण ~1000-3000 टोकन, केवल प्रासंगिक हिस्से
आउटपुट बजट:            केवल वर्तमान चरण, आगे सारांशित

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

अक्सर पूछे जाने वाले प्रश्न

प्रॉम्प्ट इंजीनियरिंग और कॉन्टेक्स्ट इंजीनियरिंग में क्या अंतर है?

प्रॉम्प्ट इंजीनियरिंग आपके सिस्टम प्रॉम्प्ट और उपयोगकर्ता संदेशों की शब्दावली पर केंद्रित है। कॉन्टेक्स्ट इंजीनियरिंग व्यापक अनुशासन है: यह तय करना कि पूर्ण कॉन्टेक्स्ट विंडो में कौन सी जानकारी जाती है — बातचीत इतिहास, पुनः प्राप्त डेटा और टूल आउटपुट सहित — किस क्रम में और किस टोकन लागत पर।

मेरा सिस्टम प्रॉम्प्ट कितना बड़ा होना चाहिए?

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

क्या कॉन्टेक्स्ट इंजीनियरिंग कुछ मॉडलों के लिए दूसरों की तुलना में अधिक महत्वपूर्ण है?

यह सभी के लिए महत्वपूर्ण है, लेकिन छोटे मॉडलों के साथ दांव अधिक है। एक बड़ा फ्रंटियर मॉडल कभी-कभी खराब संरचित कॉन्टेक्स्ट से उबर सकता है; सख्त बजट वाला छोटा मॉडल नहीं कर सकता।

मुझे कैसे पता चलेगा कि मेरी कॉन्टेक्स्ट इंजीनियरिंग काम कर रही है?

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

क्या मुझे हमेशा इतिहास को संपीड़ित या सारांशित करना चाहिए?

छोटे लेनदेन एजेंटों के लिए: नहीं। 5-6 से अधिक आदान-प्रदान वाले मल्टी-टर्न एजेंटों के लिए: हां, हमेशा। मैं जो अंगूठे का नियम उपयोग करता हूं — एक बार जब इतिहास बजट मेरे कुल कॉन्टेक्स्ट बजट के 30% से अधिक हो जाता है, मैं सारांश करना शुरू करता हूं।