मूल बातें

LLM एजेंट का context window: उसमें क्या जाता है और agent नियम क्यों भूलता है

अपडेट किया गया: · Skillaria.Top

LLM का context window वह पूरा टेक्स्ट है जो model हर जवाब के समय देखता है: system prompt, निर्देश की फ़ाइलें, बातचीत का इतिहास, पढ़ी गई फ़ाइलें और tools का आउटपुट। इसकी सीमा tokens में तय है, पर ध्यान की गुणवत्ता उस सीमा से बहुत पहले गिरने लगती है, इसलिए लंबे सत्र में agent नियम खोने लगता है; मदद करते हैं छोटे निर्देश, compaction, फ़ाइल-योजना वाले नए सत्र और शोरगुल भरे काम subagents को देना।

LLM का context window क्या है

LLM का context window वह पूरा टेक्स्ट है जो model अगला जवाब बनाते समय इनपुट के रूप में पाता है। Model के पास इंसानों जैसी स्मृति नहीं है: जो कुछ वह इस समय आपके काम के बारे में «जानता» है, वह इसी window में है। जो window में नहीं है, वह model के लिए अस्तित्व में नहीं है।

Window का आकार tokens में मापा जाता है, यानी शब्दों के टुकड़ों में। हिंदी या रूसी जैसे टेक्स्ट में एक token अंग्रेज़ी की तुलना में आम तौर पर छोटा होता है, इसलिए वही निर्देश कई बार अधिक tokens लेता है। आधुनिक models की windows सैकड़ों हज़ार tokens की होती हैं, और लगता है कि सब कुछ समा जाएगा। व्यवहार में agent की जगह उम्मीद से जल्दी भरती है, और काम की गुणवत्ता उससे भी पहले गिरने लगती है।

Agent के context window में क्या जाता है

कोडिंग agent के पास जानकारी के ठीक तीन स्रोत होते हैं: कार्य का वर्णन करने वाला system prompt, उसने जो फ़ाइलें पढ़ीं उनकी सामग्री, और उसने जो tools चलाए उनका आउटपुट। तीनों एक ही window में रहते हैं और जगह के लिए आपस में होड़ करते हैं।

क्याकब जाता हैआम तौर पर कितना लगता है
Agent का system prompt और tools का विवरणहर सत्र की शुरुआत मेंस्थिर खर्च, जो आपके हाथ में लगभग नहीं है
CLAUDE.md, AGENTS.md और अन्य निर्देश फ़ाइलेंसत्र की शुरुआत में, पूरीसैकड़ों से दसियों हज़ार tokens — यह आप तय करते हैं
आपके संदेश और agent के जवाबपूरी बातचीत में जमा होते हैंहर बात के साथ बढ़ते हैं
पढ़ी गई फ़ाइलेंजब agent उन्हें खोलता हैबड़ी फ़ाइल — एक बार में हज़ारों tokens
कमांड का आउटपुट: tests, logs, build, grepहर tool-कॉल के बादअक्सर सबसे बड़ा और सबसे कम काम का हिस्सा

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

लंबे सत्र में agent नियम क्यों भूलता है

एक आम शिकायत: सत्र की शुरुआत में agent CLAUDE.md के नियमों का ठीक से पालन करता है, और एक घंटे बाद उन्हें तोड़ने लगता है। वह उन्हें शाब्दिक अर्थ में «भूला» नहीं — नियमों का टेक्स्ट अब भी window में है। समस्या यह है कि model लंबे टेक्स्ट पर अपना ध्यान कैसे बाँटता है।

Lost in the middle

Liu और साथियों के 2023 के एक शोध में दिखाया गया कि भाषा models लंबे context की शुरुआत और अंत की जानकारी का उपयोग बीच की तुलना में कहीं बेहतर करते हैं। निर्देश-फ़ाइल सत्र की शुरुआत में लोड होती है, पर बातचीत बढ़ने के साथ ऊपर और नीचे दोनों तरफ़ और टेक्स्ट जुड़ता है। जो नियम कभी सामने था, वह धीरे-धीरे उस हिस्से में चला जाता है जिसे model सबसे कम «देखता» है।

Window में नियमों का हिस्सा घटता है

नए सत्र में निर्देश context का काफ़ी बड़ा हिस्सा होते हैं। सैकड़ों tool-कॉल के बाद वे logs, diffs और पढ़े गए कोड के बीच एक छोटा टुकड़ा रह जाते हैं। संकेत वही है, पर उसके आसपास का शोर दसियों गुना बढ़ गया है।

ताज़ा उदाहरण पुराने नियमों से भारी पड़ते हैं

Model बातचीत में हाल की घटनाओं पर बहुत निर्भर रहता है। अगर agent ने कई बार नियम के उलट कुछ किया और उसे कोई परिणाम नहीं भुगतना पड़ा, तो वह पैटर्न इतिहास में निर्देश की किसी पंक्ति से ज़्यादा वज़न पाने लगता है।

Context rot: window भरने के साथ गुणवत्ता का गिरना

Context rot («context का सड़ना») उस प्रभाव का नाम है जिसमें window भरने के साथ model के जवाबों की गुणवत्ता गिरती है, भले ही तकनीकी सीमा अभी दूर हो। Model औपचारिक रूप से 200 हज़ार tokens स्वीकार करता है, पर 150 हज़ार पर वह 20 हज़ार की तुलना में बदतर काम करता है: विवरणों में ज़्यादा गड़बड़ी करता है, पहले खारिज किए गए समाधान दोहराता है, निर्देश भूलता है।

संकेत कि सत्र «सड़ गया» है:

  • agent ऐसा तरीका सुझाता है जिससे आप आधे घंटे पहले साथ मिलकर मना कर चुके हैं;
  • उन फ़ाइलों और functions के नाम गड़बड़ाता है जो पहले चर्चा में आ चुके हैं;
  • जो जाँचें शुरुआत में खुद चलाता था, उन्हें चलाना बंद कर देता है;
  • जवाब लंबे और धुंधले होते जाते हैं, और «साथ में यह भी ठीक कर दिया» जैसी अनचाही बदलाव बढ़ते हैं।

इसका इलाज एक और नियम जोड़ना नहीं है: नया नियम भी उसी शोर में खो जाएगा। शोर घटाना होगा।

Context compaction

Compaction सत्र के इतिहास का संक्षेपण है: model लिखता है कि अब तक क्या हुआ, और आगे की बातचीत पूरे इतिहास की जगह इसी सार के साथ चलती है। Window खाली होती है, और काम का सार बचा रहता है।

Claude Code में इसके लिए /compact कमांड है, जिसे संक्षेपण पर ध्यान केंद्रित करने का संकेत दिया जा सकता है। जब window सीमा के करीब पहुँचती है, तो Claude Code compaction अपने-आप भी करता है। /clear इतिहास को पूरी तरह साफ़ करता है और खाली पन्ने से शुरू करता है, और /context दिखाता है कि window में अभी क्या कितना जगह घेरे हुए है।

/context
/compact सहेजो: कार्य का लक्ष्य, लिए गए फ़ैसले और उनके कारण, बदली गई फ़ाइलों की सूची, क्या जाँचना बाकी है
/clear

Compaction में क्या खतरा है

सार हमेशा विवरण खोता है। संक्षेपित टेक्स्ट में खारिज किया गया विकल्प और उसका कारण नहीं आ सकता, आवश्यकता की सटीक शब्दावली नहीं आ सकती, या कोई बारीकी जिस पर आपने बीच में बात की थी। Compaction के बाद agent अपने ही सत्र का किसी और का लिखा सार पढ़ता है। इसलिए ज़रूरी बातें बातचीत के इतिहास में नहीं, ऐसी फ़ाइलों में रखना बेहतर है जो किसी भी compaction के बाद बची रहें।

Compaction या नया सत्र

स्थितिक्या करें
कार्य लगभग पूरा है, बस थोड़ी और जगह चाहिएसंकेत के साथ compaction, कि क्या सहेजना है
एक कार्य खत्म किया, अब दूसरा शुरू करना हैनया सत्र, पुराना इतिहास सिर्फ़ रुकावट है
सत्र «सड़ गया», agent चक्कर लगा रहा हैस्थिति योजना-फ़ाइल में लिखें, नया सत्र शुरू करें
कोड या logs की लंबी छानबीन चाहिएछानबीन subagent को दें

Context window की बचत कैसे करें

Context बचाना tokens की कीमत के बारे में नहीं, काम की गुणवत्ता के बारे में है। Window में जितना कम शोर, उतना ज़्यादा ध्यान कार्य और नियमों को मिलता है।

1. छोटी निर्देश-फ़ाइल, जो रास्ता दिखाए

प्रवेश-फ़ाइल CLAUDE.md या AGENTS.md हर सत्र में पूरी पढ़ी जाती है। 600 पंक्तियों की फ़ाइल का मतलब है लगभग 10–20 हज़ार tokens का स्थायी खर्च। उसमें जाँच की कमांड, सख्त सीमाएँ और प्रोजेक्ट का नक्शा रखें, और विषय-वार विवरण अलग दस्तावेज़ों में, जिन्हें agent ज़रूरत पड़ने पर ही खोले।

2. ज्ञान जो ज़रूरत पर लोड हो

Claude Code skills इस तरह बनी हैं कि context में पहले केवल उनका छोटा विवरण जाता है, और पूरा निर्देश तभी लोड होता है जब काम को उसकी ज़रूरत हो। यह दुर्लभ प्रक्रियाओं — deploy, migrations, release — को हाथ में रखने का सुविधाजनक तरीका है, बिना हर सत्र में उनका खर्च उठाए।

3. शोरगुल भरे काम के लिए subagents

Subagent अपनी अलग context window में काम करता है और मुख्य सत्र को केवल परिणाम लौटाता है। बड़े कोड में खोज, लंबे log का विश्लेषण, किसी अनजान module को समझना — यह सब subagent को दिया जा सकता है, और बदले में कच्चे आउटपुट की हज़ारों पंक्तियों की जगह कुछ अनुच्छेद निष्कर्ष मिलते हैं।

4. चुप रहने वाला tool-आउटपुट

कमांड का आउटपुट window का सबसे बड़ा खाने वाला है। जाँच की कमांड ऐसी सेट करें कि सफलता पर एक पंक्ति छापें, और विफलता पर केवल सार: गिरा हुआ टेस्ट और उसका संदेश, पूरा build-log नहीं।

# शोरगुल: हर चलने पर हज़ारों पंक्तियाँ window में
pytest -v

# चुप: सफलता पर एक पंक्ति, विफलता पर केवल गिरे टेस्ट
pytest -q --tb=short

# log पूरा नहीं, केवल अंत और गलतियाँ
tail -n 50 app.log | grep -i error

5. एक कार्य — एक सत्र

एक ही सत्र में तीन असंबंधित कार्य न खींचें। पहले कार्य का इतिहास तीसरे के लिए बेकार है, पर जगह घेरता है और agent को उलझाता है। काम खत्म हुआ — परिणाम दर्ज किया — नया सत्र खोला।

6. स्थिति फ़ाइलों में, इतिहास में नहीं

जो कुछ compaction और नए सत्र के बाद भी बचा रहना चाहिए, उसे रिपॉज़िटरी में लिखें: लक्ष्य, फ़ैसले और उनके कारण, खारिज किए गए विकल्प, क्या हुआ और कैसे जाँचा गया, अगला कदम। उदाहरण के लिए PLAN.md और PROGRESS.md। तब नया सत्र दोबारा सुनाने से नहीं, एक सटीक दस्तावेज़ से शुरू होता है, और आप इतिहास बेझिझक साफ़ कर सकते हैं।

# PROGRESS.md
## लक्ष्य
छूट की गणना को पूरे पैसों (कोपेक) में बदलना

## किया गया (जाँचा हुआ)
- app/payments/discount.py: float → int, make test हरा
- Migration 041 जोड़ी गई, स्थानीय रूप से लागू

## फ़ैसले
- राउंडिंग — बैंकिंग वाली, जैसे भुगतान प्रदाता की

## खारिज
- मॉडल में Decimal: webhooks का serialization टूटता है

## अगला कदम
ऑर्डर-चेकआउट का e2e परिदृश्य अपडेट करें और make e2e चलाएँ

महत्वपूर्ण नियम केवल window में नहीं रह सकते

सबसे अच्छी तरह बना context भी नियमों के पालन की गारंटी नहीं देता: window का टेक्स्ट model पर प्रभाव है, लागू होने वाला प्रतिबंध नहीं। अगर उल्लंघन अस्वीकार्य है, तो नियम मशीनी तरीके से जाँचा जाना चाहिए। Claude Code में इसके लिए hooks हैं — ऐसी कमांड जो agent के events पर चलती हैं और कार्रवाई रोक सकती हैं — और अनुमति की सेटिंग्स, जो कुछ tools या कमांड पर रोक लगाती हैं। Linters, tests और CI agent के window में क्या चल रहा है, इससे स्वतंत्र रूप से काम करते हैं।

हार्नेस का एक अच्छा नियम: जो कुछ अपने-आप जाँचा जा सकता है, वह अपने-आप जाँचा जाए, और context में केवल वही रहे जिसके लिए विवेक चाहिए।

निष्कर्ष

LLM का context window ही वह एकमात्र जगह है जहाँ agent आपका काम देखता है, और वह लगता है उससे तेज़ी से भरता है: निर्देश, इतिहास, पढ़ी गई फ़ाइलें और कमांड का आउटपुट सत्र के अंत तक जमा होते रहते हैं। गुणवत्ता तकनीकी सीमा से बहुत पहले गिरती है, लंबे context के बीच के नियम खो जाते हैं, और compaction जगह बचाता है पर विवरण की कीमत पर। निर्देश छोटे रखें, दुर्लभ ज्ञान को ज़रूरत पर लोड करें, शोरगुल भरा काम subagents को दें, स्थिति फ़ाइलों में रखें, और अहम नियमों को hooks और जाँचों से सहारा दें। Agent के context के साथ काम हम harness engineering के कोर्स में व्यावहारिक रूप से करते हैं।

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

Claude का context window कितने tokens का होता है?

यह model और plan पर निर्भर करता है; एक सामान्य अनुमान लगभग 200 हज़ार tokens है, कुछ models और configurations में अधिक। सटीक मान उस model के लिए Anthropic के दस्तावेज़ में देखें।

क्या बड़ा window भूले हुए नियमों की समस्या हल कर देता है?

आंशिक रूप से: जगह ज़्यादा है, पर lost in the middle और context rot का प्रभाव बना रहता है। बड़ा window छोटे निर्देशों और साफ़ सत्र की जगह नहीं लेता।

अगर agent कोई महत्वपूर्ण नियम तोड़े, तो क्या उसे संदेश में दोबारा लिखना चाहिए?

एक बार की याद दिलाने से मदद मिलती है, क्योंकि context के अंत में ताज़ा टेक्स्ट model बेहतर देखता है। पर अगर बार-बार याद दिलाना पड़े, तो नियम को जाँच या hook से पक्का करना चाहिए।

Claude Code में पता कैसे करें कि context window में क्या कितना जगह घेर रहा है?

<code>/context</code> कमांड दिखाती है कि system prompt, tools, memory फ़ाइलें और संदेशों का इतिहास कितनी जगह लेते हैं। यह देखने का तेज़ तरीका है कि फूली हुई CLAUDE.md या लंबा इतिहास window खा रहे हैं या नहीं।

Compaction में सबसे पहले क्या खो जाता है?

वे समझौते जो केवल बातचीत में थे: खारिज किए गए विकल्प, आवश्यकता के स्पष्टीकरण, छोटी बारीकियाँ। जो कुछ रिपॉज़िटरी की फ़ाइलों में लिखा है, उसे agent दोबारा पढ़ सकता है।

इस विषय को वीडियो में सीखें

यह विषय “Harness Engineering: инженерия надёжности AI-агентов” कोर्स में अभ्यास के साथ विस्तार से समझाया गया है।

कोर्स पर जाएँ