विषय-सूची
AI के साथ काम करने में ध्यान का केंद्र "prompt engineering" से "context engineering" की ओर खिसक रहा है। अपने prompt (निर्देश) को निखारने से आगे बढ़कर, आप मॉडल को सौंपी जाने वाली पूरी जानकारी (context) को डिज़ाइन और प्रबंधित करते हैं — और 2026 में यह AI के इस्तेमाल के लिए, खासकर AI agents बनाने के लिए, एक अनिवार्य कौशल बन चुका है।
यह लेख शुरुआती लोगों के लिए सरल शब्दों में बताता है कि context engineering क्या है, यह क्यों मायने रखता है (कुंजी है "context rot"), और इससे जुड़ी ठोस तकनीकें कौन-सी हैं।
context एक "सीमित बजट" है
— केवल सबसे छोटी, सबसे उपयोगी जानकारी रखने की कला
चुनिंदा रहें
सब कुछ ठूँसें नहीं — केवल वही शामिल करें जो सचमुच मदद करे।
बार-बार सफाई करें
हल्का बने रहने के लिए पुरानी history और tool नतीजों का सारांश बनाएँ या हटाएँ।
ज़रूरत पर ही लाएँ
शुरू में ही सब कुछ लोड न करें; जिस क्षण ज़रूरत हो उसी समय लाएँ।
1. Context Engineering क्या है?
Anthropic की परिभाषा उधार लें तो, context engineering है "उन रणनीतियों का समूह जिनसे आप inference के दौरान मॉडल को सौंपे जाने वाले tokens (जानकारी) के सबसे उपयुक्त समूह को चुनते और बनाए रखते हैं" (इसके "Effective context engineering for AI agents," मार्च 2026 से)। यह केवल prompt को नहीं, बल्कि context window में आने वाली हर चीज़ को कवर करता है — system prompt, tools, बातचीत की history, और बाहरी डेटा।
इसे "अपनी मेज़ को साफ-सुथरा रखने की कला" समझें। आप केवल वही सामग्री हाथ की पहुँच में रखते हैं जिसकी ज़रूरत है और जो काम हो चुका उसे हटा देते हैं। अपनी मेज़ (context window) पर दस्तावेज़ों का ढेर लगा दें तो आपकी कार्यक्षमता असल में घट जाती है — AI के साथ भी ठीक यही होता है। इसीलिए "क्या रखें और क्या छोड़ें" एक हल करने लायक डिज़ाइन समस्या है।
💡 एक पंक्ति में: prompt engineering = "निर्देश को निखारना।" Context engineering = "मॉडल जो पूरी जानकारी देखता है उसे डिज़ाइन करना।" बाद वाला एक व्यापक अनुशासन है जिसमें पहला भी शामिल है।
2. यह क्यों मायने रखता है: "context rot" की दीवार
"अगर context window में दस लाख tokens समा सकते हैं, तो सब कुछ डाल क्यों न दें?" यहीं जाल है: आप जितने ज़्यादा tokens जोड़ते हैं, मॉडल की सटीकता असल में उतनी ही घटती जाती है। इस परिघटना को "context rot" कहते हैं।
जब Chroma ने 2025 में 18 अग्रणी मॉडलों (GPT, Claude, Gemini, और अन्य) का परीक्षण किया, तो हर एक input के लंबा होते जाने के साथ कम भरोसेमंद होता गया। इसकी वजह यह है कि मॉडल का "attention" एक सीमित बजट है। हर अतिरिक्त token इस बजट को पतला करता है, जिससे प्रासंगिक जानकारी छूट जाना आसान हो जाता है — और लंबे context के बीच में रखी जानकारी को नज़रअंदाज़ करना खासकर आसान होता है ("lost in the middle")।
input जितना लंबा, सटीकता उतनी ही कम (केवल उदाहरण हेतु)
* एक अवधारणात्मक चित्रण। मापे गए अध्ययनों में, Stanford research (2023) ने बताया कि, उदाहरण के लिए, जब करीब 4,000 tokens की संदर्भ सामग्री दी गई तो सटीकता 70–75% से गिरकर 55–60% रह गई। कठिन कार्यों पर यह गिरावट और बड़ी होती है।
संक्षेप में, "लंबा context हमेशा बेहतर होता है" यह गलत है। इसीलिए context engineering — केवल सबसे छोटे, सबसे उपयोगी tokens रखना — ज़रूरी है। खासकर लंबे समय तक चलने वाले AI agents और coding agents के लिए, context rot प्रायः विफलता का मुख्य कारण बनता है।
3. context में असल में क्या होता है
लोग अक्सर सोचते हैं कि "context = prompt," पर हकीकत में उसी window में कहीं ज़्यादा तत्व साझा होते हैं — और वे सब बजट खर्च करते हैं।
काम जितना लंबा होता है, उतनी ही ज़्यादा history और tool नतीजे जमा होते जाते हैं। इसे अनदेखा छोड़ दें तो window जल्दी ही "बीच में दबी अहम जानकारी" से भर जाती है। इसीलिए नीचे दी गई सफाई की तकनीकें ज़रूरी हैं।
4. छह मुख्य तकनीकें
Anthropic के मार्गदर्शन और व्यावहारिक अनुभव के आधार पर, यहाँ छह ज़्यादा असरदार तकनीकें हैं। इनका साझा सिद्धांत है "उच्च-signal वाले tokens का सबसे छोटा समूह खोजें।"
① सही ऊँचाई पर निर्देश
बहुत बारीक if-else तर्क भंगुर होता है; बहुत अस्पष्ट हो तो असर नहीं करता। बीच का रास्ता अपनाएँ: "ठोस मगर लचीला।"
② अपने tools चुनें
ऐसे tools हटाएँ जो आपस में ओवरलैप करते हों या जहाँ साफ न हो कि कौन-सा लागू होता है। कुछ ही स्पष्ट tools तक सीमित करें।
③ Just-in-time retrieval
शुरू में ही सब कुछ लोड करने के बजाय केवल file paths और links रखें और जिस क्षण ज़रूरत हो उसी समय लाएँ। यह Claude Skills के progressive disclosure जैसा ही विचार है।
④ Compaction (सारांश संपीडन)
जब window भर जाए, तो history का सारांश बनाकर उसे एक नई window में आगे ले जाएँ। निर्णय और खुले मुद्दे रखें; दोहराव वाले tool आउटपुट हटा दें।
⑤ Notes (बाहरी memory)
प्रगति और मुख्य बिंदुओं को window के बाहर एक file में लिखें और ज़रूरत पड़ने पर ही उन्हें वापस पढ़ें। इससे लंबे कार्य सुसंगत बने रहते हैं।
⑥ sub-agents से अलग करें
शोध जैसे भारी काम को किसी sub-agent को सौंपें और मुख्य agent को केवल सारांश लौटाएँ। इससे विस्तृत context मुख्य thread से बाहर रहता है।
⚠️ हद से ज़्यादा इंजीनियरिंग न करें: किसी भी पेचीदा तंत्र की ओर बढ़ने से पहले वह सबसे सरल चीज़ करें जो काम कर जाए। केवल अनावश्यक जानकारी न जोड़ना, और बार-बार एक नया session शुरू करना ही अक्सर काफी दूर तक काम आ जाता है।
5. prompt, RAG और Skills से इसका संबंध
ये पड़ोसी अवधारणाएँ आसानी से एक-दूसरे में घुलमिल जाती हैं, इसलिए आइए इन्हें यथास्थान रखें। Context engineering वह "छाते जैसी सोच" है जो इन सबको आपस में जोड़ती है।
- Prompt engineering: निर्देशों को निखारने का कौशल। यह context engineering का एक हिस्सा है।
- RAG: बाहरी ज्ञान को खोजकर context में जोड़ने की एक विधि। "क्या लाएँ और शामिल करें" को संभालने का एक तरीका।
- Skills: एक तंत्र जो किसी प्रक्रिया को केवल ज़रूरत पड़ने पर ही विस्तृत करता है। just-in-time retrieval का एक ठोस उदाहरण।
तो "निर्देश निखारना" (prompts), "ज्ञान जोड़ना" (RAG), और "प्रक्रियाओं को अंदर-बाहर लाना" (Skills) — context engineering इन सबको एक ही डिज़ाइन समस्या मानता है: window में क्या डालें, और क्या साफ करें।
6. आज से आप क्या कर सकते हैं
किसी भी कठिन कार्यान्वयन से पहले, कुछ ऐसी आदतें हैं जिन्हें कोई भी तुरंत अपना सकता है।
- विषय बदलने पर नई chat शुरू करें: पुराने context को साथ न घसीटना ही सटीकता वापस लौटा देता है। सबसे सरल और सबसे असरदार कदम।
- लंबे दस्तावेज़ पूरे-के-पूरे पेस्ट न करें: केवल प्रासंगिक हिस्सा निकालकर सौंपें। पूरा पाठ संलग्न करना अक्सर उल्टा पड़ता है।
- लंबे काम के बीच में सारांश बनवाएँ: कहें "अब तक के निर्णय और बचे हुए कार्य गिनाओ," फिर उसी से आगे बढ़ें (मैन्युअल compaction)।
- tools और extensions का ढेर न लगाएँ: जिन MCP servers और skills का इस्तेमाल नहीं करते उन्हें हटा दें। जितने ज़्यादा विकल्प, उतना ही मॉडल हिचकिचाता है।
💡 यह सस्ता भी है: अतिरिक्त tokens न लोड करना सीधे-सीधे token लागत की बचत में बदल जाता है। सटीकता और लागत दोनों एक साथ सुधरते हैं।
सारांश
Context engineering पर तीन मुख्य बातें।
- यह क्या है: prompts समेत "मॉडल जो पूरी जानकारी देखता है" उसे डिज़ाइन और प्रबंधित करने का अनुशासन। prompt engineering के बाद का अगला चरण।
- क्यों: "context rot" के कारण — tokens जोड़ते जाने के साथ सटीकता घटती है। context एक सीमित बजट है।
- तरकीब: केवल सबसे छोटे, सबसे उपयोगी tokens रखें। आपके हथियार हैं — चुनाव (curation), सफाई (सारांश बनाना), ज़रूरत पर retrieval, और sub-agent से अलगाव।
"विषय बदलने पर नया session" और "केवल मुख्य बिंदु पेस्ट करें" से शुरुआत करें। अगर और गहराई में जाना चाहें, तो Claude Skills और harness engineering भी देखें।
FAQ
Q. क्या अब prompt engineering पुरानी पड़ गई है?
A. नहीं। prompt engineering context engineering के एक हिस्से के रूप में अब भी अहम है। संबंध यह है कि निर्देश निखारने के कौशल के ऊपर आप पूरी जानकारी को डिज़ाइन करने का नज़रिया जोड़ते हैं।
Q. क्या बड़े context window वाला मॉडल इस्तेमाल करने से समस्या हल हो जाती है?
A. बड़ी window के साथ भी context rot होता है। शोध दिखाता है कि जगह है इसलिए सब कुछ ठूँस देना असल में सटीकता घटा देता है। बड़ी window "गुंजाइश" है, "सब कुछ शामिल करने की छूट" नहीं।
Q. क्या यह आम chat इस्तेमाल के लिए भी मायने रखता है?
A. हाँ। केवल "हर विषय के लिए नई chat शुरू करना" और "सिर्फ़ मुख्य बिंदु पेस्ट करना" ही जवाब की गुणवत्ता बढ़ा देता है। ये ऐसे सुझाव हैं जिन्हें आप आज ही अपना सकते हैं, भले ही आप इंजीनियर न हों।
Q. RAG और context engineering में क्या फ़र्क है?
A. RAG एक ठोस विधि है — "बाहरी ज्ञान खोजें और उसे context में जोड़ें।" Context engineering वह व्यापक अवधारणा है जो "window में क्या डालें और क्या साफ करें" को समग्र रूप से संभालती है, और RAG उसका एक घटक भर है।
