केस-तथ्य ब्लॉक और आउटपुट छोटा करना
तथ्यों को सारांश से बाहर स्थिर रखिए; विस्तृत टूल परिणाम छोटे कीजिए।
केस-तथ्य ब्लॉक और आउटपुट छोटा करना, CoddyKit पर Claude Architect का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Claude Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
लंबी बातचीत की समस्या
किसी लंबी एजेंट-आधारित बातचीत में संदेशों का पूरा इतिहास उस सीमा से आगे बढ़ जाता है जिसे संदर्भ में रखना सुविधाजनक होता है। सामान्य समाधान क्रमिक सारांशीकरण है: पुराने संवाद-चरणों को एक निरंतर सारांश में संक्षिप्त करना, ताकि संदर्भ-विंडो संभालने योग्य बनी रहे।
लेकिन सारांशीकरण में एक छिपी हुई विफलता होती है। यह बातचीत का सार बचाए रखने में अच्छा है, पर सटीक मान बचाए रखने में बहुत खराब। जैसे-जैसे आप संक्षिप्त करते हैं, मॉडल को सही ढंग से कार्य करने के लिए आवश्यक सटीक बातें धुंधली होने लगती हैं।
सारांशीकरण क्या नष्ट करता है
क्रमिक सारांशीकरण संख्याओं, प्रतिशतों और तिथियों को अस्पष्ट बना देता है। जिस संवाद-चरण में कहा गया था, "ऑर्डर #88231 को 2026-03-14 को भेज दिया गया, और $412.50 की वापसी स्वीकृत हो गई", वह घटकर "ग्राहक का ऑर्डर हाल ही में भेजा गया और वापसी स्वीकृत हो गई" बन सकता है।
कहानी के प्रवाह के लिए यह ठीक है, लेकिन ऐसे उपकरण-कॉल करने वाले एजेंट के लिए विनाशकारी है जिसे order_id=88231 भेजना हो या $412.50 की सीमा पर तर्क करना हो। सारांश द्वारा मिटाए गए मान को मॉडल फिर से प्राप्त नहीं कर सकता।
समाधान: केस-तथ्य खंड
वास्तुशिल्पीय तरीका यह है कि लेन-देन संबंधी तथ्यों को एक अलग "केस तथ्य" खंड में लाया जाए, जहाँ उन्हें सारांश से बाहर ज्यों का त्यों रखा जाए। सारांश बातचीत की कथा संभालता है; केस-तथ्य खंड में वे सटीक, निर्णायक मान रहते हैं।
महत्त्वपूर्ण बात यह है कि इस खंड का कभी सारांशीकरण या संपीड़न नहीं किया जाता। जब आप पुराने संवाद-चरणों को संक्षिप्त करते हैं, तब केस-तथ्य खंड बिना बदलाव के आगे भेजा जाता है। सारांश में जानकारी खो सकती है; तथ्यों में नहीं।
केस-तथ्यों में क्या शामिल होना चाहिए
केस-तथ्य खंड में ऐसी हर चीज़ रखें जो सटीक और परिणामकारी हो:
- पहचान-संकेतक: ऑर्डर नंबर, ग्राहक पहचान-संकेतक, टिकट नंबर, SKU
- राशियाँ और सीमाएँ: वापसी की कुल राशियाँ, शेषराशि, सीमाएँ
- तिथियाँ और समय-मुहरें: भेजने की तिथियाँ, अंतिम तिथियाँ, SLA की समय-सीमाएँ
- सत्यापित पहचान स्थिति: जैसे, "ग्राहक की पहचान ग्राहक-पहचान प्राप्त करने की प्रक्रिया के माध्यम से पुष्ट की गई"
हल्की-फुल्की बातचीत, दोबारा कही गई बातें और व्याख्यात्मक गद्य सारांश में रहने दें। जाँच यह है: क्या यहाँ कोई गलत या अस्पष्ट मान गलत कार्रवाई करवा सकता है? यदि हाँ, तो वह केस-तथ्य है।
खंड की संरचना
केस-तथ्य खंड को संक्षिप्त, सुव्यवस्थित कुंजी/मान वाली पंक्तियों के रूप में रखें — ताकि मॉडल उन्हें आसानी से देख सके और उपकरण के इनपुट में ज्यों का त्यों कॉपी कर सके। इसे system प्रॉम्प्ट में डालें या ऐसे पिन किए गए संदर्भ खंड के रूप में रखें जो हर संवाद-चरण के साथ जाता रहे।
CASE_FACTS = """
<case_facts>
customer_id: CUST-77421 (identity: VERIFIED via get_customer)
order_id: 88231
ship_date: 2026-03-14
refund_requested: 412.50 USD
refund_policy_threshold: 500.00 USD
</case_facts>
"""
system = (
"You are a support agent. The values in <case_facts> are "
"authoritative and exact. Always copy IDs and amounts from "
"<case_facts> verbatim; never reconstruct them from the summary.\n\n"
+ CASE_FACTS
)सारांश और तथ्य साथ मिलकर कैसे काम करते हैं
ये दोनों हिस्से एक-दूसरे के पूरक हैं। हर संवाद-चरण पर आप भेजते हैं: पुराने कथात्मक हिस्से का संपीड़ित सारांश, ज्यों का त्यों रखा गया केस-तथ्य खंड, और हाल के मूल संवाद-चरण। याद रखें, मॉडल कोई स्थिति नहीं रखता — इसलिए हर अनुरोध पर यह पूरा संयोजन फिर से भेजना पड़ता है।
सारांश विंडो को छोटा रखता है; केस-तथ्य खंड यह सुनिश्चित करता है कि सटीक मान सुरक्षित रहें। सारांश को आक्रामक ढंग से संक्षिप्त करें, यह जानते हुए कि महत्त्वपूर्ण तथ्य कहीं और सुरक्षित हैं।
def build_messages(summary, recent_turns):
# case_facts lives in `system`; summary + recent turns in messages
return [
{"role": "user",
"content": f"<conversation_summary>{summary}</conversation_summary>"},
*recent_turns, # last few raw turns, uncompressed
]
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
system=system, # contains the verbatim CASE_FACTS block
messages=build_messages(summary, recent_turns),
tools=tools,
)बीच में खो जाना
स्थिति महत्त्वपूर्ण होने का एक दूसरा कारण भी है। मॉडल बीच में खो जाने का प्रभाव दिखाते हैं: वे संदर्भ के आरंभ और अंत पर बीच की तुलना में अधिक ध्यान देते हैं।
इसलिए किसी विशाल उपकरण-डंप या लंबे सारांश के बीच में दबा हुआ महत्त्वपूर्ण तथ्य अनदेखा होने की सबसे अधिक संभावना रखता है। अपने केस-तथ्य खंड को वहाँ रखें जहाँ ध्यान सबसे अधिक होता है — system प्रॉम्प्ट के आरंभ में या इनपुट के अंत के पास पिन करके।
दूसरा पहलू: विस्तृत उपकरण-परिणाम
केस-तथ्य स्मरण की समस्या हल करते हैं। दूसरा अनुशासन यह नियंत्रित करना है कि शुरुआत में संदर्भ-विंडो में क्या प्रवेश करता है। उपकरण — API, डेटाबेस क्वेरी और फ़ाइल-पठन — अक्सर बहुत बड़े, गहराई से नेस्ट किए गए JSON पेलोड लौटाते हैं, जिनका अधिकांश हिस्सा वर्तमान निर्णय के लिए अप्रासंगिक होता है।
उस कच्चे डेटा को इतिहास में जोड़ने से विंडो अनावश्यक रूप से भर जाती है, महत्त्वपूर्ण सामग्री बीच में खो जाने वाले क्षेत्र में चली जाती है और मॉडल का ध्यान बिखर जाता है। नियम यह है: मॉडल के देखने से पहले विस्तृत उपकरण-परिणाम को प्रासंगिक फ़ील्ड तक सीमित करें।
कोड में संक्षिप्तीकरण
कच्चा परिणाम प्राप्त करने और उसे संदेश-इतिहास में जोड़ने के बीच, अपने कोड में संक्षिप्तीकरण निश्चित रूप से करें। केवल वे फ़ील्ड निकालें जिनकी मॉडल को तर्क करने या अगली उपकरण-कॉल भरने के लिए वास्तव में आवश्यकता है।
raw = lookup_order(order_id=88231)
# raw has 60+ fields: internal flags, audit log, warehouse meta, etc.
trimmed = {
"order_id": raw["order_id"],
"status": raw["status"],
"total": raw["total"],
"ship_date": raw["fulfillment"]["ship_date"],
}
messages.append({
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": tool_use_id,
"content": json.dumps(trimmed),
}],
})PostToolUse हुक से संक्षिप्तीकरण
आप PostToolUse हुक से संक्षिप्तीकरण लागू भी कर सकते हैं। यह हुक मॉडल के परिणाम देखने से पहले उपकरण-परिणाम को रोक लेता है। इससे संक्षिप्तीकरण निश्चित और केंद्रीकृत रहता है, बजाय इसके कि हर उपकरण के कार्यान्वयन पर सही व्यवहार करने के लिए निर्भर रहना पड़े।
फ़ील्ड के कठोर, हमेशा लागू होने वाले चयन के लिए हुक सही स्थान है — वही निश्चित-प्रवर्तन तर्क, जिसका उपयोग ऐसी किसी नीति के लिए किया जाएगा जिसे हर बार 100% चलना आवश्यक हो, न कि प्रॉम्प्ट की तरह लगभग 90% बार।
# PostToolUse hook: keep only whitelisted fields per tool
KEEP = {
"lookup_order": ["order_id", "status", "total", "ship_date"],
}
def on_post_tool_use(tool_name, result):
keys = KEEP.get(tool_name)
if not keys:
return result
return {k: result[k] for k in keys if k in result}संक्षिप्त करें, पर स्रोत-संदर्भ न खोएँ
प्रासंगिकता के लिए संक्षिप्त करें — इतना नहीं कि बाद में कार्य करने या उद्धृत करने के लिए आवश्यक चीज़ ही हट जाए। यदि कोई मान उपकरण-कॉल चलाने या ग्राहक के सामने किए जाने वाले दावे को प्रभावित करेगा, तो उसे हटाने के बजाय केस-तथ्य खंड में शामिल करें।
काम का एक स्पष्ट विभाजन यह है: इतिहास में जाने वाले उपकरण-परिणाम को संक्षिप्त करें, और जिन सटीक मानों का बचा रहना आवश्यक है उन्हें ज्यों के त्यों रखे गए केस-तथ्य खंड में पिन करें। जहाँ सुरक्षित हो वहाँ जानकारी घटाएँ, जहाँ आवश्यक हो वहाँ उसे ज्यों का त्यों रखें।
त्वरित जाँच
एक सहायता एजेंट कई संवाद-चरणों वाले लंबे सत्र चलाता है। बजट के भीतर रहने के लिए पुराने संवाद-चरणों का क्रमिक सारांशीकरण किया जाता है। परीक्षक बताते हैं कि कुछ समय बाद यह कभी-कभी गलत राशि वापस कर देता है या पुराना ऑर्डर नंबर भेज देता है। सबसे अच्छा समाधान क्या है?
पुनरावलोकन
मुख्य निष्कर्ष:
- क्रमिक सारांशीकरण सटीक मानों को धुंधला कर देता है — संख्याएँ, प्रतिशत और तिथियाँ अस्पष्ट हो जाती हैं।
- लेन-देन संबंधी तथ्यों को सारांश से बाहर, ज्यों के त्यों रखे गए केस-तथ्य खंड में पिन करें; सारांश में जानकारी घट सकती है, तथ्यों में नहीं।
- बीच में खो जाने का प्रभाव: मॉडल आरंभ और अंत पर सबसे अधिक ध्यान देते हैं — महत्त्वपूर्ण तथ्य वहीं रखें, संदर्भ के बीच में दबे हुए नहीं।
- इतिहास में जोड़ने से पहले विस्तृत उपकरण-परिणाम को प्रासंगिक फ़ील्ड तक सीमित करें; PostToolUse हुक इसे निश्चित बनाता है।
- काम का विभाजन: इतिहास में जाने वाली चीज़ को संक्षिप्त करें और जो ज्यों का त्यों बचना चाहिए उसे पिन करें। जहाँ सुरक्षित हो वहाँ जानकारी घटाएँ, जहाँ महत्त्व हो वहाँ सटीकता रखें।
एआई शिक्षक के साथ Python सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 26
- पाठ
- 104
अक्सर पूछे जाने वाले प्रश्न
क्या “केस-तथ्य ब्लॉक और आउटपुट छोटा करना” पाठ निःशुल्क है?
हाँ — Claude Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “केस-तथ्य ब्लॉक और आउटपुट छोटा करना” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“केस-तथ्य ब्लॉक और आउटपुट छोटा करना” में मैं क्या सीखूँगा?
तथ्यों को सारांश से बाहर स्थिर रखिए; विस्तृत टूल परिणाम छोटे कीजिए। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Claude Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Claude Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Claude Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“केस-तथ्य ब्लॉक और आउटपुट छोटा करना” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Claude Architect पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Claude Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- पूरा इतिहास आवश्यक है
- क्रमिक सारांश के जोखिम
- बीच में खो जाने का प्रभाव
- केस-तथ्य ब्लॉक और आउटपुट छोटा करना