बीच में खो जाने का प्रभाव
मॉडल बीच की तुलना में शुरुआत और अंत को अधिक विश्वसनीयता से पढ़ते हैं।
बीच में खो जाने का प्रभाव, CoddyKit पर Claude Architect का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Claude Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
प्रभाव को सरल शब्दों में समझिए
जब आप किसी लंबे प्रॉम्प्ट को Claude की संदर्भ विंडो में रखते हैं, तो मॉडल हर टोकन पर समान रूप से ध्यान नहीं देता। संदर्भ के आरंभ और अंत के पास की जानकारी, बीच में दबे हुए विवरण की तुलना में कहीं अधिक विश्वसनीय रूप से याद की जाती है।
इसे बीच में खो जाने का प्रभाव कहते हैं। यह ऐसी बग नहीं है जिसे पैच करके ठीक किया जा सके — यह लंबे इनपुट पर ध्यान के व्यवहार का एक गुण है। एक आर्किटेक्ट के रूप में आपको इसके अनुकूल डिज़ाइन करना चाहिए।
विश्वसनीयता के लिए इसका महत्व
Claude प्रमाणित आर्किटेक्ट परीक्षा में यह क्षेत्र 5: संदर्भ प्रबंधन और विश्वसनीयता के अंतर्गत आता है। व्यावहारिक जोखिम यह है कि बहुत बड़े प्रॉम्प्ट के बीच रखे गए किसी महत्वपूर्ण निर्देश, नीति-नियम या लेन-देन के तथ्य को चुपचाप अनदेखा कर दिया जाए।
विफलता शांत होती है। मॉडल अब भी सहज उत्तर देता है — बस वह उस सीमा को छोड़ देता है जिसकी आपको चिंता थी। इसलिए बीच में खो जाना विश्वसनीयता की समस्या है, प्रारूप की पसंद नहीं।
अपने प्रमुख निर्देशों की स्थिति तय कीजिए
सबसे सरल उपाय है: अपने सबसे महत्वपूर्ण निर्देश वहाँ रखें जहाँ ध्यान सबसे मजबूत हो। उन्हें system प्रॉम्प्ट में सबसे पहले रखें और मॉडल के परिणाम उत्पन्न करने से ठीक पहले, अंत में महत्वपूर्ण सीमा को फिर से लिखें।
एपीआई अनुबंध याद रखें: मॉडल कोई स्थिति नहीं रखता। आप हर चरण में FULL messages इतिहास भेजते हैं। इसलिए हर चरण बीच की सामग्री को कम महत्व दिए जाने का एक नया अवसर — और नया जोखिम — होता है।
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system=(
"You are a refund agent. CRITICAL RULE: never "
"process a refund before get_customer returns a "
"verified ID."
),
# ...long retrieved context goes in the middle...
messages=messages,
)महत्वपूर्ण सीमा को दोनों सिरों पर रखिए
एक मजबूत पैटर्न है दोनों सिरों पर रखना: नियम को system में शुरुआत में बताइए, फिर अंतिम उपयोगकर्ता-चरण की आखिरी पंक्ति के रूप में उसका छोटा-सा अनुस्मारक दोहराइए। शुरुआत उसे आधार देती है; अंत परिणाम उत्पन्न करते समय उसे ध्यान में बनाए रखता है।
दोहराव छोटा रखें। आप पूरे निर्देश की नकल नहीं कर रहे हैं — केवल उस एक निर्णय की, जिसे मॉडल को नहीं भूलना चाहिए।
messages = [
{"role": "user", "content": (
retrieved_docs
+ "\n\n---\nReminder: cite a source URL for every "
"claim. If a fact is absent from the docs above, "
"say so explicitly — do not invent it."
)},
]विस्तृत उपकरण परिणाम को सीमित कीजिए
बीच में सामग्री के अत्यधिक भराव का एक बड़ा स्रोत कच्चे उपकरण परिणाम हैं। कोई एपीआई या MCP उपकरण सैकड़ों क्षेत्र लौटा सकता है, जबकि आपको केवल तीन चाहिए। यह सब डाल देने से आपका वास्तविक संकेत कम-ध्यान वाले बीच में धकेल दिया जाता है।
उपकरण परिणामों को संदेश इतिहास में जोड़ने से पहले उन्हें प्रासंगिक क्षेत्रों तक सीमित कर दें। बीच में कम शोर होने पर मॉडल अपना ध्यान महत्वपूर्ण बातों पर लगा पाता है।
def trim_order(raw: dict) -> dict:
# keep only what the model needs to reason about
return {
"order_id": raw["order_id"],
"status": raw["status"],
"total": raw["total"],
"refundable": raw["refundable"],
}
# append the trimmed result, not the 200-field blob
messages.append({
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": tu_id,
"content": json.dumps(trim_order(raw_result)),
}],
})केस तथ्यों को ज्यों का त्यों रखिए
जब संदर्भ बढ़ता है, तो टीमें क्रमिक सारांशीकरण अपनाती हैं। यह उपयोगी है — लेकिन इससे संख्याएँ, प्रतिशत और तिथियाँ अस्पष्ट हो जाती हैं। बीच में खो जाने के प्रभाव के साथ मिलकर, संदर्भ के बीच में बैठा सारांशित लेन-देन का तथ्य दोहरी तरह से कमजोर हो जाता है।
समाधान: लेन-देन के तथ्यों को सारांश से बाहर अलग "केस तथ्य" ब्लॉक में ज्यों का त्यों रखें। किसी ऑर्डर की कुल राशि या धनवापसी की सीमा को सारांश के बीच में केवल परिभाषित रूप में ही जीवित न रहने दें।
case_facts = (
"CASE FACTS (verbatim, do not summarize):\n"
"- order_id: A-4821\n"
"- order_total: $612.40\n"
"- refund_policy_cap: $500.00\n"
"- customer_verified: true"
)
system = case_facts + "\n\n" + rolling_summary/compact में भी वही जोखिम है
Claude Code में, /compact बातचीत को संक्षिप्त करके संदर्भ में जगह खाली करता है। लाभ यह है कि काम जारी रखने के लिए जगह मिलती है; जोखिम क्रमिक सारांशीकरण जैसा ही है: संख्याएँ और तिथियाँ अस्पष्ट हो जाती हैं।
सटीक मानों पर निर्भर सत्र को संक्षिप्त करने से पहले, उन मानों को किसी टिकाऊ स्थान पर सुरक्षित कर लें — उदाहरण के लिए /memory के माध्यम से CLAUDE.md में, जो सत्रों के बीच भी बना रहता है — ताकि वे संक्षिप्तीकरण के बाद भी सुरक्षित रहें और अस्पष्ट मध्य-सारांश में विलीन न हों।
# In a Claude Code session:
/memory # write exact build numbers / API contract to CLAUDE.md
/compact # now safe(r): the hard facts persist outside the summaryपुनः प्राप्त दस्तावेज़ों का क्रम सोच-समझकर तय कीजिए
यदि आप N पुनः प्राप्त खंड डालते हैं, तो उनका क्रम यह बदल देता है कि मॉडल किसका उपयोग करता है। सबसे प्रासंगिक प्रमाण ब्लॉक के आरंभ या अंत में होना चाहिए — 14 में से खंड संख्या 7 पर नहीं।
दो व्यावहारिक कदम:
- क्रम फिर से तय करें, ताकि सबसे अधिक प्रासंगिक खंड ब्लॉक के दोनों सिरों पर हों।
- ब्लॉक छोटा करें। ध्यान को कमजोर करने वाले सीमांत प्रासंगिकता वाले लंबे क्रम की तुलना में कम, अधिक सटीक खंड बेहतर होते हैं।
ranked = rerank(query, chunks) # best first
top = ranked[:6] # cut the long tail
# bracket: strongest at start AND end
ordered = [top[0]] + top[2:] + [top[1]]
context = "\n\n".join(c.text for c in ordered)काम बाँटिए, ध्यान को कमजोर मत कीजिए
बीच में खो जाना उन कारणों में से एक है जिनसे एक ही चरण में कई फ़ाइलों की समीक्षा ध्यान को कमजोर करती है। दस फ़ाइलों को एक प्रॉम्प्ट में ठूँसने से बीच की फ़ाइलें दब जाती हैं।
इसके बजाय काम को विभाजित करें: हर फ़ाइल के लिए एक स्थानीय चरण, फिर अलग फ़ाइलों के बीच एकीकरण चरण। प्रत्येक चरण में केंद्रित, छोटा संदर्भ होता है, जहाँ कोई महत्वपूर्ण बात बीच में नहीं फँसती।
# Multi-pass review (avoids single-prompt dilution)
for path in changed_files:
review_local(path) # focused, short context per file
review_cross_file(changed_files) # separate integration passउप-एजेंटों को स्पष्ट संदर्भ चाहिए
बहु-एजेंट प्रणालियाँ केंद्र और शाखाओं के ढाँचे पर आधारित होती हैं। उप-एजेंट समन्वयक का बातचीत इतिहास स्वतः प्राप्त नहीं करते — प्रत्येक तथ्य हर उप-एजेंट प्रॉम्प्ट में स्पष्ट रूप से भेजना पड़ता है।
यह बीच में खो जाने के प्रभाव से जुड़ा है: जब समन्वयक वह उप-एजेंट प्रॉम्प्ट बनाता है, तब भी महत्वपूर्ण निर्देश आरंभ और अंत में होने चाहिए और विस्तृत सामग्री को सीमित किया जाना चाहिए। संदर्भ का अलगाव प्रत्येक उप-एजेंट को विरासत में मिली अव्यवस्था के बजाय एक साफ़, सही स्थिति में रखा हुआ प्रॉम्प्ट देने का अवसर है।
Task(
description="Summarize Q3 revenue",
prompt=(
"TASK: extract Q3 net revenue from the report below.\n"
+ report_text +
"\n\nOUTPUT: a single number in USD, plus the source "
"page. If absent, reply 'NOT FOUND'."
),
)मानसिक जाँच-सूची
लंबे-संदर्भ वाला प्रॉम्प्ट भेजने से पहले यह जाँच-सूची चलाइए:
- ऊपर: सबसे महत्वपूर्ण निर्देश
systemमें स्पष्ट रूप से लिखा हुआ। - नीचे: अंत में एकमात्र महत्वपूर्ण सीमा का छोटा अनुस्मारक।
- बीच: सीमित उपकरण परिणाम, पुनः क्रमित दस्तावेज़, कोई कच्ची सामग्री नहीं।
- तथ्य: सटीक संख्याएँ और तिथियाँ केस-तथ्य ब्लॉक में ज्यों की त्यों रखी हुई, केवल सारांश में नहीं।
- लंबाई: यदि यह बहुत बड़ा है, तो इसे केंद्रित चरणों में बाँट दें।
स्थिति ही डिज़ाइन है। बीच को कम-विश्वसनीय क्षेत्र मानिए।
त्वरित जाँच
इस पाठ को एक ठोस आर्किटेक्चर निर्णय पर लागू कीजिए।
पुनरावलोकन
बीच में खो जाने के प्रभाव से जुड़े मुख्य निष्कर्ष:
- मॉडल संदर्भ के आरंभ और अंत पर बीच की तुलना में अधिक ध्यान देते हैं — इसलिए बीच के हिस्से को कम-विश्वसनीय क्षेत्र मानें।
- महत्वपूर्ण निर्देश
systemमें रखें और अंत में उस एक महत्वपूर्ण बाध्यता को दोहराएँ। - विस्तृत उपकरण-परिणाम को संक्षिप्त करें और प्राप्त दस्तावेज़ों को पुनः क्रमित करें, ताकि महत्वपूर्ण जानकारी संदर्भ की शुरुआत और अंत — दोनों ओर रहे।
- सटीक संख्याएँ और तिथियाँ केस-तथ्य खंड में ज्यों की त्यों रखें; सारांशीकरण और
/compactउन्हें अस्पष्ट बना देते हैं। - बड़े कार्यों के लिए एक कमजोर, पतले प्रॉम्प्ट के बजाय केंद्रित चरणों में विभाजित करें।
- स्थिति बदलने से लक्षण कम हो सकते हैं — लेकिन वित्तीय, कानूनी या सुरक्षा संबंधी महत्त्व वाले नियमों को स्थान-निर्धारण से नहीं, बल्कि हुक से लागू करें।
एआई शिक्षक के साथ Python सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 26
- पाठ
- 104
अक्सर पूछे जाने वाले प्रश्न
क्या “बीच में खो जाने का प्रभाव” पाठ निःशुल्क है?
हाँ — Claude Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “बीच में खो जाने का प्रभाव” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“बीच में खो जाने का प्रभाव” में मैं क्या सीखूँगा?
मॉडल बीच की तुलना में शुरुआत और अंत को अधिक विश्वसनीयता से पढ़ते हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Claude Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Claude Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Claude Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।
“बीच में खो जाने का प्रभाव” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Claude Architect पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Claude Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- पूरा इतिहास आवश्यक है
- क्रमिक सारांश के जोखिम
- बीच में खो जाने का प्रभाव
- केस-तथ्य ब्लॉक और आउटपुट छोटा करना