मुख्य कंटेंट तक स्किप करें
मध्यम

कॉन्टेक्स्ट इंजीनियरिंग

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

यह अंतर इसलिए मायने रखता है क्योंकि कॉन्टेक्स्ट विंडो कोई नोटपैड नहीं है। यह एक सीमित, महँगा, ध्यान-संबंधी संसाधन है। आप इसे कैसे भरते हैं, यह बदल देता है कि मॉडल किस पर ध्यान केंद्रित करता है, इसकी आपको कितनी लागत पड़ती है, और सेशन बढ़ने पर यह उपयोगी बना रहता है या नहीं।

What you'll learn
  • कॉन्टेक्स्ट इंजीनियरिंग को प्रॉम्प्ट इंजीनियरिंग से अलग पहचानें — और जानें कि यह क्षेत्र क्यों आगे बढ़ा
  • कॉन्टेक्स्ट विंडो को एक भंडारण डिब्बे के रूप में नहीं, बल्कि एक अटेंशन बजट के रूप में मानें
  • किसी लंबे सेशन को बर्बाद करने से पहले कॉन्टेक्स्ट रॉट और 'lost in the middle' को पहचानें
  • निर्देशों को वहाँ रखें जहाँ ध्यान वास्तव में पड़ता है — शुरुआत में, अंत में, कभी भी बीच में दबाकर नहीं
  • तीन मुख्य रणनीतियाँ लागू करें: कॉम्पैक्शन, नोट-लेना, और जस्ट-इन-टाइम रिट्रीवल

कॉन्टेक्स्ट बजट​

हर मॉडल का एक अधिकतम कॉन्टेक्स्ट आकार होता है — टोकनों में मापी गई एक कठोर सीमा। इसे एक बजट की तरह सोचें। आप इसे इन पर खर्च करते हैं:

  • आपका सिस्टम प्रॉम्प्ट और स्थायी निर्देश
  • रिट्रीव किए गए दस्तावेज़, कोडबेस के अंश, टूल परिभाषाएँ
  • बातचीत का इतिहास
  • मॉडल का आउटपुट (जो बहु-टर्न सेशनों में भी विंडो के विरुद्ध गिना जाता है)

जब यह खत्म हो जाता है, तो कुछ न कुछ छोड़ना पड़ता है। या तो पुरानी सामग्री हटा दी जाती है, या सेशन एक दीवार से टकरा जाता है।

अधिकांश शुरुआती गाइड कॉन्टेक्स्ट विंडो को "जितना अधिक, उतना अच्छा" मानते हैं। कॉन्टेक्स्ट इंजीनियरिंग इसे एक ऐसे संसाधन के रूप में मानती है जिसे सावधानी से आवंटित करना है: इसे उसी पर खर्च करें जो मॉडल को इस टर्न के लिए वास्तव में चाहिए, न कि हर उस चीज़ पर जो प्रासंगिक हो सकती है। Anthropic पूरे अनुशासन को "उच्च-संकेत वाले टोकनों के सबसे छोटे संभव समूह" की खोज के रूप में ढालता है — आपके द्वारा जोड़ा गया हर टोकन एक सीमित अटेंशन बजट के लिए प्रतिस्पर्धा करता है, जो इस बात का सीधा परिणाम है कि एक ट्रांसफ़ॉर्मर हर टोकन को हर दूसरे टोकन से कैसे जोड़ता है।

कॉन्टेक्स्ट रॉट और "lost in the middle"​

लंबे-कॉन्टेक्स्ट वाले LLM में एक भली-भाँति प्रलेखित परिघटना है: मॉडल अपने कॉन्टेक्स्ट की शुरुआत और अंत के पास की सामग्री पर असमान रूप से अधिक ध्यान देते हैं, और बीच में दबी सामग्री को याद रखने की उनकी क्षमता घट जाती है। इस प्रभाव का अध्ययन करने वाले शोधकर्ताओं ने इसे "lost in the middle" कहा।

व्यावहारिक परिणाम: यदि आप 100,000-टोकन वाले कॉन्टेक्स्ट को दस्तावेज़ों से भर देते हैं और सबसे महत्वपूर्ण निर्देश को स्थिति 60,000 पर दबा देते हैं, तो मॉडल वस्तुतः उसे अनदेखा कर सकता है — इसलिए नहीं कि वह इतनी दूर तक पढ़ने में असमर्थ है, बल्कि इसलिए कि ध्यान विंडो भर में समान रूप से वितरित नहीं होता।

"कॉन्टेक्स्ट रॉट" एक व्यापक पैटर्न है: जैसे-जैसे सेशन बढ़ता है, प्रतिक्रियाओं की गुणवत्ता भटकती जाती है। शुरुआती निर्देश पतले पड़ जाते हैं। बार-बार की गई आवाजाही मूल कार्य को किनारे कर देती है। मॉडल टालमटोल करने लगता है, खुद को दोहराने लगता है, या आपने जो वास्तव में पूछा था उसकी कड़ी खो देता है।

ये ऐसे बग नहीं हैं जिन्हें आप किसी बेहतर प्रॉम्प्ट से पूरी तरह ठीक कर सकें। ये इस बात के संरचनात्मक गुण हैं कि बड़े पैमाने पर ध्यान कैसे काम करता है। इंजीनियरिंग प्रतिक्रिया यह है कि कॉन्टेक्स्ट को छोटा और तीक्ष्ण रखें, न कि उसे भरकर उम्मीद करें।

क्रम मायने रखता है​

आप सामग्री कहाँ रखते हैं, यह उतना ही महत्वपूर्ण है जितना आप क्या शामिल करते हैं। स्थापित अच्छा अभ्यास:

स्थितिवहाँ क्या रखें
बिल्कुल शीर्ष पर (सिस्टम प्रॉम्प्ट)स्थिर, टिकाऊ निर्देश। पर्सोना, नियम, फ़ॉर्मेट संबंधी आवश्यकताएँ।
सिस्टम प्रॉम्प्ट के बादवर्तमान कार्य, सरल शब्दों में।
अंतिम यूज़र टर्न से ठीक पहलेइस विशिष्ट अनुरोध के लिए सबसे महत्वपूर्ण, विशिष्ट कॉन्टेक्स्ट।
बीच मेंसहायक दस्तावेज़, रिट्रीव किए गए अंश — प्रासंगिकता के अनुसार क्रमबद्ध, न कि कालक्रम के अनुसार।
बातचीत का इतिहासकेवल वही जो निरंतरता के लिए ज़रूरी है। आक्रामक रूप से छाँटें।

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

निर्देशों के लिए "सही ऊँचाई"​

एक सिस्टम प्रॉम्प्ट दो विपरीत तरीकों से विफल हो सकता है। बहुत नीचे और आप भंगुर, अगर-यह-तो-वह वाला तर्क हार्डकोड कर देते हैं जो वास्तविकता के अलग होते ही टूट जाता है। बहुत ऊँचे और आप अस्पष्ट मार्गदर्शन लिख देते हैं जो ऐसे कॉन्टेक्स्ट को मान लेता है जो मॉडल के पास नहीं है। Anthropic इस लक्ष्य को "सही ऊँचाई" कहता है — वह गोल्डीलॉक्स क्षेत्र जो "व्यवहार को प्रभावी ढंग से निर्देशित करने के लिए पर्याप्त विशिष्ट हो, फिर भी मजबूत अनुमान-नियम प्रदान करने के लिए पर्याप्त लचीला हो।" वहीं निशाना लगाएँ: ठोस नियम और उदाहरण, न कि कोई निर्णय-वृक्ष, और न ही कोई महज़ अनुभूति।

ठूँसने के बजाय रिट्रीवल​

प्रलोभन यह होता है कि सब कुछ डाल दिया जाए: सभी दस्तावेज़, पूरा कोडबेस, पूरी बातचीत। इसका विरोध करें।

बेहतर तरीका है चयनात्मक रिट्रीवल: पहचानें कि इस विशिष्ट अनुरोध के लिए मॉडल को वास्तव में क्या चाहिए, और केवल उसी को इंजेक्ट करें। सही दस्तावेज़ का एक भली-भाँति रिट्रीव किया गया 2,000-टोकन वाला अंश उस 40,000-टोकन वाले ढेर से बेहतर प्रदर्शन करता है जहाँ उत्तर कहीं बीच में होता है।

यही कारण है कि रिट्रीवल-ऑगमेंटेड जेनरेशन (RAG) मौजूद है — केवल कॉन्टेक्स्ट सीमाओं को पार करने के लिए नहीं, बल्कि कॉन्टेक्स्ट को सुव्यवस्थित रखकर गुणवत्ता सुधारने के लिए। इसका एजेंटिक संस्करण है जस्ट-इन-टाइम रिट्रीवल: हर दस्तावेज़ को पहले से लोड करने के बजाय, एजेंट हल्के पहचानकर्ता (फ़ाइल पथ, ID, क्वेरीज़) रखता है और वास्तविक सामग्री को कॉन्टेक्स्ट में केवल तभी खींचता है जब उसकी ज़रूरत होती है।

इंटरैक्टिव सेशनों के लिए भी यही तर्क लागू होता है: सब कुछ संचित करने के बजाय, समय-समय पर इतिहास को कॉम्पैक्ट या क्लियर करें ताकि वह सामग्री हटा दी जाए जो अब वर्तमान कार्य के लिए प्रासंगिक नहीं है। Claude Code के /compact और /clear कमांड कॉन्टेक्स्ट इंजीनियरिंग के टूल हैं, न कि केवल सेशन प्रबंधन के। API पर, यही पैटर्न memory और context editing द्वारा स्वचालित होता है — पुराने टूल परिणाम विंडो से छाँट दिए जाते हैं जबकि जो मायने रखता है उसे एक स्थायी मेमोरी स्टोर में लिख दिया जाता है।

तीन मुख्य रणनीतियाँ​

लंबी-अवधि वाले काम के लिए, तीन तकनीकें अधिकांश भारी बोझ उठाती हैं। ये आपस में मिलकर काम करती हैं — अधिकांश वास्तविक एजेंट तीनों का उपयोग करते हैं।

Guided walkthrough1 of 3
  1. जब कोई सेशन विंडो की सीमा के करीब पहुँचे, तो उसका सारांश बनाएँ और निचोड़े गए संस्करण के साथ फिर से शुरू करें। भार-वहन करने वाले विवरण सुरक्षित रखें — स्थापत्य संबंधी निर्णय, अनसुलझे बग, मुख्य कार्यान्वयन विकल्प — और कदम-दर-कदम विवरण छोड़ दें। Claude Code में /compact यही करता है।

लागत का पहलू​

जो टोकन आप भेजते हैं, वे वही टोकन हैं जिनका आप भुगतान करते हैं — पैसे और लेटेंसी दोनों में। कॉन्टेक्स्ट को ढीली-ढाली प्रासंगिक सामग्री से ठूँसना दोनों को बढ़ा देता है। कॉन्टेक्स्ट इंजीनियरिंग और लागत-दक्षता एक ही समस्या हैं।

अधिक ठोस रूप से:

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

जो वहाँ होना ज़रूरी नहीं है उसे छाँटना एक साथ ही गुणवत्ता के लिए बेहतर और चलाने में सस्ता है।

Claude यूज़र्स के लिए व्यावहारिक रणनीतियाँ​

Claude.ai में:

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

Claude Code में:

  • अपनी CLAUDE.md फ़ाइल को दुबला रखें। उसमें हर पंक्ति हर सेशन में इंजेक्ट होती है। देखें CLAUDE.md और Context Management।
  • जब किसी सचमुच भिन्न कार्य पर स्विच करें तो /clear का उपयोग करें। जब आप जारी रखना चाहें लेकिन सेशन बढ़ रहा हो तो /compact का उपयोग करें।
  • जब वर्तमान चरण के लिए पूरी फ़ाइल की ज़रूरत न हो तो फ़ाइलों की सामग्री चिपकाने के बजाय उन्हें पथ द्वारा संदर्भित करें।

API स्तर पर:

  • सिस्टम प्रॉम्प्ट इस तरह डिज़ाइन करें कि उनमें केवल वही हो जो हर अनुरोध को वास्तव में चाहिए। कार्य-विशिष्ट निर्देशों को यूज़र टर्न में ले जाएँ।
  • दस्तावेज़-प्रधान उपयोग मामलों के लिए, पूरा संग्रह अपलोड करने के बजाय प्रासंगिक अंशों को रिट्रीव और इंजेक्ट करें।
  • प्रॉम्प्ट को इस तरह संरचित करें कि स्थिर, पुन: उपयोग योग्य उपसर्ग पहले आए — यह प्रॉम्प्ट कैशिंग को भी सक्षम करता है, जो कॉन्टेक्स्ट इंजीनियरिंग का एक स्वाभाविक साथी है।

जब आप किसी लंबे दस्तावेज़ को Claude को सौंपना चाहें, तो स्थान-निर्धारण का नियम हर बार कच्ची मात्रा को मात देता है:

निर्देश-पहले, दोहराव-अंत में

कार्य: हर वह खंड खोजें जहाँ यह अनुबंध हमारी देयता को सीमित करता है, और हर एक को उसके अनुभाग संख्या सहित अक्षरशः उद्धृत करें।

[... पूरा 40-पृष्ठ का अनुबंध यहाँ चिपकाएँ ...]

कार्य की याद दिलावट: ऊपर दिए गए हर देयता-सीमा खंड को सूचीबद्ध करें, अक्षरशः उद्धृत, अनुभाग संख्याओं सहित। यदि कोई नहीं है, तो स्पष्ट रूप से ऐसा कहें।

वही निर्देश शीर्ष पर और तल पर बैठता है — वे दो स्थितियाँ जिन्हें ध्यान प्राथमिकता देता है — ताकि वह एक बहुत लंबे बीच में भी टिका रहे।

मानसिकता में बदलाव​

प्रॉम्प्ट इंजीनियरिंग पूछती है: "मुझे क्या कहना चाहिए?" कॉन्टेक्स्ट इंजीनियरिंग पूछती है: "मॉडल को क्या देखना चाहिए, किस क्रम में, और मुझे जानबूझकर क्या बाहर रखना चाहिए?"

दूसरा प्रश्न कठिन है, लेकिन यही वह है जो बड़े पैमाने पर गुणवत्ता को वास्तव में निर्धारित करता है।

Check yourself

0/3
  1. प्रॉम्प्ट इंजीनियरिंग और कॉन्टेक्स्ट इंजीनियरिंग के बीच मूल अंतर क्या है?
  2. आप 100,000-टोकन वाले कॉन्टेक्स्ट के टोकन 60,000 पर सबसे महत्वपूर्ण एकल निर्देश को दबा देते हैं। संभावित परिणाम क्या है?
  3. एक कोडिंग एजेंट किसी लंबे कार्य पर कॉन्टेक्स्ट खत्म करने वाला है। कौन-सी रणनीति प्रगति को सबसे अच्छी तरह सुरक्षित रखती है?
शब्दावली पक्की करें
कार्ड पलटने के लिए Enter या Space दबाएँ। कार्ड बदलने के लिए बाएँ और दाएँ तीर कुंजियों का उपयोग करें।शब्द दिखाया गया।
1 / 6
Key takeaways
  • कॉन्टेक्स्ट विंडो एक अटेंशन बजट है, भंडारण नहीं — इसे केवल उच्च-संकेत वाले टोकनों पर खर्च करें।
  • स्थिति मात्रा को मात देती है: महत्वपूर्ण निर्देश शीर्ष पर और अंतिम टर्न से ठीक पहले रखें, कभी भी बीच में दबाकर नहीं।
  • कॉम्पैक्शन, नोट-लेना, और जस्ट-इन-टाइम रिट्रीवल वे तीन रणनीतियाँ हैं जो लंबे एजेंटों को सुसंगत रखती हैं।
  • कॉन्टेक्स्ट को सुव्यवस्थित करना वही लीवर है जो लागत घटाता है — कम टोकन, बेहतर उत्तर, कम बिल।

संबंधित​