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

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

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

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

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

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

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

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

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

कॉन्टेक्स्ट रॉट और "लॉस्ट इन द मिडल"

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

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

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

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

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

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

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

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

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

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

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

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

इंटरैक्टिव सेशनों के लिए वही तर्क लागू होता है: सब कुछ इकट्ठा करते जाने के बजाय, समय-समय पर इतिहास को कॉम्पैक्ट या क्लियर करें ताकि वह सामग्री हटाई जा सके जो अब मौजूदा काम के लिए प्रासंगिक नहीं है। Claude Code के /compact और /clear कमांड कॉन्टेक्स्ट इंजीनियरिंग के औजार हैं, सिर्फ सेशन प्रबंधन नहीं।

लागत का पहलू

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

ज्यादा ठोस रूप में:

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

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

Claude उपयोगकर्ताओं के लिए व्यावहारिक रणनीतियाँ

Claude.ai में:

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

Claude Code में:

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

API स्तर पर:

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

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

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

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

संबंधित