AI एजेंट्स के लिए कॉन्टेक्स्ट इंजीनियरिंग: कॉन्टेक्स्ट विंडो में असल में क्या जाना चाहिए

विषय-सूची

अगस्त 2026 में प्रकाशित।

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

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

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

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

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

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

जगह के लिए होड़ करने वाली चार चीज़ें

हर टर्न पर, चार श्रेणियाँ एक ही सीमित जगह के लिए लड़ती हैं:

1. सिस्टम निर्देश — पहचान, नियम, आउटपुट फॉर्मैट। सिस्टम प्रॉम्प्ट के लिए मैं जो पाँच परतें इस्तेमाल करता हूँ देखें — यह अकेली श्रेणी है जिसे लगभग स्थिर रहना चाहिए, क्योंकि प्रॉम्प्ट कैशिंग तभी फायदेमंद होती है जब प्रीफिक्स हिलता नहीं।
2. टूल परिभाषाएँ — हर उस टूल की स्कीमा जिसे एजेंट इस टर्न में बुला सकता है, चाहे उसे इसकी ज़रूरत हो या न हो।
3. प्राप्त डेटा — डेटाबेस, वेक्टर स्टोर, या API कॉल से निकाली गई कोई भी चीज़: मेमोरी, दस्तावेज़, ग्राहक रिकॉर्ड।
4. बातचीत या रन का इतिहास — इस सेशन या इस रन में अब तक क्या हुआ है।

इनमें से कोई भी मुफ़्त नहीं है। किसी भी श्रेणी का हर टोकन वह टोकन है जिसे मॉडल को अगला कदम तय करते समय बाकी सभी के मुक़ाबले तौलना पड़ता है, और हर टोकन वह टोकन है जिसका भुगतान आप हर उस अनुरोध पर करते हैं जो कैश हिट नहीं है।

गलती लगभग हमेशा बहुत ज़्यादा होने की होती है, बहुत कम की नहीं

जब कोई एजेंट गलत व्यवहार करता है, तो सहज प्रवृत्ति होती है और कॉन्टेक्स्ट जोड़ने की — और निर्देश, और पृष्ठभूमि, “बस एहतियातन” और इतिहास। मेरे अनुभव में यह अक्सर उल्टा ही सही होता है।

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

पुराना बातचीत का इतिहास। एक सपोर्ट एजेंट जो तीन असंबंधित पुराने मामलों से 60 टर्न का इतिहास घसीट रहा है, “ग्राहक को याद” नहीं रख रहा — वह मौजूदा अनुरोध को अप्रासंगिक शोर से पतला कर रहा है, और कभी-कभी ऐसी बात पर काम कर रहा है जो अब सच नहीं रही। यह ठीक वही विफलता का तरीका है जिसे सीमित विंडो वाली एपिसोडिक मेमोरी को रोकना चाहिए, और यह जाँचना उचित है कि आपकी विंडो वाकई सीमित है या चुपचाप असीमित होकर बढ़ गई है।

ऐसे प्राप्त दस्तावेज़ जिनकी किसी ने माँग नहीं की। एक सिमेंटिक रिट्रीवल जो 2 प्रासंगिक टुकड़ों की बजाय शीर्ष 10 “सबसे मिलते-जुलते” टुकड़े लौटाता है, जवाब को प्रामाणिक-सी दिखने वाली भटकाव में दबा देता है। ज़्यादा प्राप्त कॉन्टेक्स्ट का मतलब ज़्यादा सिग्नल नहीं है — एक बिंदु के बाद यह वाकई बदतर होता है, क्योंकि मॉडल को असल ज़रूरी हिस्सा ढूँढने के लिए ज़्यादा मेहनत करनी पड़ती है।

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

वह बजट जो मैं असल में चलाता हूँ

30+ प्रोडक्शन एजेंट्स में, मैं एजेंट बनाने से पहले हर श्रेणी के लिए एक स्पष्ट टोकन बजट तय करता हूँ — उसके गलत व्यवहार शुरू करने के बाद नहीं:

इस आख़िरी कॉलम का क्रम असली निर्णय ढाँचा है: पहले इतिहास, फिर रिट्रीवल की चौड़ाई, फिर टूल का दायरा, और सिस्टम निर्देश सबसे आख़िर में। सटीकता खोए बिना संकुचित करने में इतिहास सबसे सस्ता है — “टर्न 1-30 में क्या हुआ” का दो-वाक्य का सारांश आमतौर पर पूरे ट्रांसक्रिप्ट जितना ही परिचालन मूल्य देता है। सिस्टम निर्देश काटना सबसे ख़तरनाक है, क्योंकि एजेंट का असली व्यवहार वहीं बसा होता है।

छाँटने से पहले सारांश बनाएँ

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

// workers/compact-history.ts

interface HistoryDigest {
  summary: string; // 2-3 वाक्य: क्या तय हुआ, सुलझा, या अभी भी खुला है
  keyFacts: Record<string, string>; // स्थिर तथ्य जिन्हें ज्यों-का-त्यों रखना उचित है
  turnCount: number; // यह डाइजेस्ट कितने कच्चे टर्न की जगह लेता है
}

async function compactIfNeeded(
  history: ConversationTurn[],
  env: Env
): Promise<{ digest: HistoryDigest | null; recent: ConversationTurn[] }> {
  const RECENT_WINDOW = 10;
  if (history.length <= RECENT_WINDOW) {
    return { digest: null, recent: history };
  }

  const toCompact = history.slice(0, -RECENT_WINDOW);
  const recent = history.slice(-RECENT_WINDOW);

  // इस कदम के लिए सारांश बनाने वाला एक सस्ता मॉडल लगभग हमेशा काफ़ी होता है
  const digest = await summarizeTurns(toCompact, env);
  return { digest, recent };
}

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

रिट्रीवल: ज़्यादा नतीजों से बेहतर हैं कम, ज़्यादा प्रासंगिक नतीजे

यही अनुशासन उस हर चीज़ पर लागू होता है जो वेक्टर स्टोर या डेटाबेस से निकाली जाती है। यह लुभावना है कि इस सिद्धांत के तहत उदारता से रिट्रीव करें — top-10, top-20 — कि ज़्यादा कॉन्टेक्स्ट नुक़सान नहीं कर सकता। कर सकता है। हर अप्रासंगिक टुकड़ा वह टुकड़ा है जिसे मॉडल को पढ़ना, तौलना, और छोड़ना पड़ता है, और लगभग-मेल खाते नतीजों का काफ़ी बड़ा ढेर उस अकेले टुकड़े से भारी पड़ सकता है जो वाकई सवाल का जवाब देता है।

मेरा डिफॉल्ट है एक छोटे k (2-4) से शुरू करना और इसे तभी बढ़ाना जब मैं असली मामलों से दिखा सकूँ कि उस चौड़ाई पर जवाब वाकई गायब है — न कि इसलिए कि एक चौड़ा जाल ज़्यादा सुरक्षित महसूस होता है। अगर रिट्रीवल की गुणवत्ता असंगत है, तो सुधार आमतौर पर एक बेहतर क्वेरी या एक री-रैंकिंग कदम है, बड़ा k नहीं।

इसे लागत और सटीकता से जोड़ें

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

मैं जो भी एजेंट चलाता हूँ वह Claude पर चलता है, और मॉडल टियर का फ़ैसला तभी मायने रखता है जब कॉन्टेक्स्ट बजट तय हो चुका हो — एक फूले हुए, असीमित कॉन्टेक्स्ट पर लागत की तुलना करना आपको यह नहीं बताता कि काम को वाकई क्या चाहिए।

और क्योंकि कॉन्टेक्स्ट विंडो में जो है उसे बदलना उतना ही व्यवहार बदलता है जितना प्रॉम्प्ट बदलना, हर कॉन्टेक्स्ट बदलाव उसी गेट से गुज़रता है जिससे प्रॉम्प्ट बदलाव गुज़रता है: लॉन्च करने से पहले इसे असली प्रोडक्शन विफलताओं से बने इवैल सेट के मुक़ाबले चलाएँ। इतिहास काटना या रिट्रीवल की चौड़ाई घटाना ठीक उसी तरह का “स्पष्ट रूप से सुरक्षित” बदलाव है जो जाँच न करने पर चुपचाप किसी एज केस को पीछे धकेल देता है।

ऑपरेटर का निष्कर्ष

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

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

AI एजेंट्स के लिए कॉन्टेक्स्ट इंजीनियरिंग क्या है?

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

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

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

एक AI एजेंट को कितना बातचीत का इतिहास रखना चाहिए?

जितना आप सोचते हैं उससे कम। एक सीमित स्लाइडिंग विंडो (आमतौर पर 10-20 हालिया टर्न) और उससे पुरानी हर चीज़ का संक्षिप्त सारांश आमतौर पर पूरे कच्चे ट्रांसक्रिप्ट से बेहतर परफॉर्म करता है, क्योंकि यह ज़रूरी तथ्य खोए बिना शोर हटा देता है। इतिहास हटाने से पहले संकुचित करें, बस काट न दें।

क्या एक बड़ी कॉन्टेक्स्ट विंडो का मतलब है कि मुझे कम कॉन्टेक्स्ट इंजीनियरिंग चाहिए?

नहीं — यह कठोर तकनीकी सीमा हटाती है पर लागत या शोर की समस्या नहीं। एक बड़ी विंडो लापरवाही को सस्ता बनाती है, पर हर अप्रासंगिक टोकन अब भी उस सिग्नल को पतला करता है जिस पर मॉडल को विचार करना है, और अब भी हर उस अनुरोध पर पैसा ख़र्च करता है जो कैश हिट नहीं है। यह अनुशासन 200K टोकन पर उतना ही मायने रखता है जितना 8K पर।

संबंधित: ऐसे AI एजेंट सिस्टम प्रॉम्प्ट कैसे लिखें जो प्रोडक्शन में फेल न हों · किसी AI एजेंट में मेमोरी कैसे जोड़ें · प्रॉम्प्ट कैशिंग: बिना मॉडल बदले अपनी Claude लागत घटाएँ · AI एजेंट्स लॉन्च करने के लिए मैं जो इवैल हार्नेस इस्तेमाल करता हूँ

अपने उपयोग के मामले के लिए किसी एजेंट का कॉन्टेक्स्ट और मेमोरी डिज़ाइन करने में मदद चाहिए? संपर्क करें — मैं ऑपरेटर टीमों के लिए प्रोडक्शन एजेंट सिस्टम डिज़ाइन करता हूँ।