उदाहरणों के साथ क्रमिक सुधार
2-4 input/output उदाहरण और test-आधारित पुनरावृत्ति।
उदाहरणों के साथ क्रमिक सुधार, CoddyKit पर Claude Architect का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Claude Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
उदाहरण विशेषणों से बेहतर क्यों हैं
जब कोई प्रॉम्प्ट अपेक्षित परिणाम नहीं देता, तो वास्तुकार "अधिक सटीक बनो" या "और कोशिश करो" जैसे अस्पष्ट सुधारों का सहारा लेते हैं। इनसे शायद ही कभी वास्तविक सुधार होता है। भरोसेमंद उपाय है स्पष्ट मानदंड और ठोस उदाहरण।
तुलना करें: "be more precise" बनाम "flag a comment only when it contradicts the code"। दूसरा मॉडल को ठीक-ठीक बताता है कि निर्णय की सीमा कहाँ है। इस पाठ में आप सीखेंगे कि 2-4 लक्षित इनपुट/आउटपुट उदाहरणों और एक सघन परीक्षण-तथा-पुनरावृत्ति चक्र की सहायता से प्रॉम्प्ट को उत्पादन-स्तर की गुणवत्ता तक कैसे पहुँचाएँ।
Few-Shot वास्तव में कैसे काम करता है
कम-उदाहरण प्रॉम्प्टिंग में आपके निर्देशों के साथ हल किए गए कुछ उदाहरण जोड़े जाते हैं। मुख्य बात यह है कि मॉडल उदाहरणों से सामान्यीकरण करता है — वह केवल उनकी नकल नहीं करता। 3 प्रतिनिधि मामलों से वह अंतर्निहित नियम का अनुमान लगाता है और उसे ऐसे इनपुट पर लागू करता है जिन्हें उसने पहले नहीं देखा है।
कम-उदाहरण प्रॉम्प्टिंग इन चार कार्यों के लिए सबसे प्रभावी है:
- कई बार किए गए अनुरोधों में संगति
- ऐसे सीमांत मामले जिन्हें केवल शब्दों में ठीक से समझाना कठिन हो
- वह आउटपुट प्रारूप जिसकी मॉडल को नकल करनी हो
- व्यवहार को स्पष्ट आधार देकर मनगढ़ंत उत्तरों को कम करना
हर अस्पष्टता के लिए 2-4 उदाहरण रखें — पैटर्न परिभाषित करने के लिए पर्याप्त, लेकिन संदर्भ को संक्षिप्त रखने के लिए इतने कम।
एक अच्छे उदाहरण की संरचना
एक प्रभावी कम-उदाहरण, इनपुट और आपके इच्छित सटीक आउटपुट की जोड़ी होता है। आउटपुट उस वास्तविक स्कीमा या संरचना से मेल खाना चाहिए जिसे आप उत्पादन परिवेश में उपयोग करेंगे — वही फ़ील्ड, वही अक्षर-रूप, वही संरचना।
नीचे, हर उदाहरण में एक इनपुट टिप्पणी और सटीक निर्णय दिखाया गया है। मॉडल सीमा सीखता है: केवल वास्तविक विरोधाभासों को चिह्नित करना है, शैली संबंधी छोटी आपत्तियों को नहीं।
examples = [
{
"input": "# returns the user's age\n def get_name(u): return u.name",
"output": {"flag": True, "reason": "comment says age, code returns name"},
},
{
"input": "# sort ascending\n items.sort()",
"output": {"flag": False, "reason": "comment matches behavior"},
},
]
system = (
"Flag a comment ONLY when it contradicts the code. "
"Style or wording issues are not contradictions.\n\n"
"Examples:\n" + "\n".join(
f"INPUT: {e['input']}\nOUTPUT: {e['output']}" for e in examples
)
)मानदंडों को उदाहरणों के साथ जोड़ें
उदाहरण और स्पष्ट मानदंड एक-दूसरे के सहायक हैं, विकल्प नहीं। मानदंड नियम बताते हैं; उदाहरण उस धुंधले क्षेत्र को सही सीमा पर स्थापित करते हैं जिसे नियम गद्य में पूरी तरह नहीं समझा सकता।
वास्तुकारों की एक सामान्य गलती है कि वे किसी मार्गदर्शक निर्देश के बिना उदाहरणों का ढेर लगा देते हैं। तब मॉडल नमूनों की ऊपरी विशेषताओं के अनुसार जरूरत से ज्यादा अनुकूलित हो जाता है। हमेशा एक स्पष्ट मानदंड से शुरुआत करें — "केवल तभी चिह्नित करें जब X, Y का विरोध करे" — फिर 2-4 उदाहरणों से यह स्पष्ट करें कि X और Y की सीमाएँ कहाँ धुंधली होती हैं।
सामान्य नियम: यदि आप मानदंड को एक वाक्य में नहीं लिख सकते, तो आपका कार्य अभी भी अपर्याप्त रूप से निर्दिष्ट है और अधिक उदाहरण उसे ठीक नहीं करेंगे।
पहले परीक्षण-समूह बनाएँ
क्रमिक परिष्कार परीक्षण-आधारित होता है। प्रॉम्प्ट को बेहतर बनाने से पहले, ज्ञात-सही आउटपुट वाले प्रतिनिधि इनपुट का एक छोटा, लेबलयुक्त समूह तैयार करें। यही आपका वास्तविक आधार है — प्रॉम्प्ट में हर बदलाव का मूल्यांकन इसी के आधार पर होना चाहिए, अपने अनुमान के आधार पर नहीं।
परीक्षण-समूह को अपने कम-उदाहरणों से अलग रखें। यदि आप उन्हीं मामलों पर सुधार करते हैं जिनसे आप सिखाते हैं, तो आप सामान्यीकरण नहीं कर रहे, बल्कि याद कर रहे हैं।
test_cases = [
{"input": "# deletes the record\n def archive(r): r.archived = True",
"expected": {"flag": True}},
{"input": "# cache result for 60s\n cache.set(k, v, ttl=60)",
"expected": {"flag": False}},
{"input": "# returns count\n def total(rows): return sum(r.amt for r in rows)",
"expected": {"flag": True}},
]क्रमिक सुधार चक्र
सुधार चक्र यांत्रिक और दोहराने योग्य है:
- प्रत्येक परीक्षण मामले पर प्रॉम्प्ट चलाएँ
- आउटपुट की अपेक्षित लेबल से तुलना करें
- विफलताओं का निरीक्षण करें — मॉडल कौन-सी सीमा चूक गया?
- उस विफलता को लक्ष्य करने वाला एक उदाहरण (या एक मानदंड) जोड़ें या अधिक स्पष्ट करें
- पूरे समूह को फिर चलाएँ और जाँचें कि कोई पुराना परिणाम खराब तो नहीं हुआ
हर पुनरावृत्ति में एक ही चीज़ बदलें। एक साथ कई संपादन करने पर यह जानना असंभव हो जाता है कि किस बदलाव से लाभ या नुकसान हुआ।
परीक्षण-समूह का मूल्यांकन
तुलना को स्वचालित करें, ताकि पुनरावृत्ति तेज़ हो। एक छोटा परीक्षण ढाँचा हर मामले को चलाता है, उसका अंक देता है और छूटे हुए मामलों को दिखाता है। संरचित आउटपुट के साथ आप गद्य को पार्स करने के बजाय फ़ील्ड की सीधे तुलना कर सकते हैं।
नीचे दिए गए tool_choice पर ध्यान दें: किसी टूल कॉल को अनिवार्य करने से यह सुनिश्चित होता है कि मॉडल हर बार स्कीमा-अनुरूप JSON लौटाए, इसलिए आपका मूल्यांकनकर्ता मुक्त-पाठ के कारण विफल नहीं होता।
def score(client, system, cases):
misses = []
for c in cases:
resp = client.messages.create(
model="claude-sonnet-4-5",
max_tokens=256,
system=system,
tools=[verdict_tool],
tool_choice={"type": "any"}, # must call a tool -> structured output
messages=[{"role": "user", "content": c["input"]}],
)
out = resp.content[0].input
if out["flag"] != c["expected"]["flag"]:
misses.append((c["input"], out))
return missesनए उदाहरणों से विफलताओं को लक्ष्य बनाएँ
जब आपको कोई चूका हुआ मामला मिले, तो पूछें: इसका कारण कौन-सी अस्पष्टता थी? फिर ऐसा उदाहरण जोड़ें जो ठीक उसी सीमा पर हो — कोई बेतरतीब नया मामला नहीं। हर विफलता-प्रकार के लिए एक स्पष्ट उदाहरण, दस सामान्य उदाहरणों की तुलना में कहीं बेहतर सामान्यीकरण करता है।
मान लीजिए मॉडल ने उस टिप्पणी को गलत तरीके से चिह्नित किया जिसमें कोड का पुनर्कथन था। आप एक ऐसा युग्मित उदाहरण जोड़ेंगे जिसमें दिखाया जाए कि पुनर्कथन = विरोधाभास नहीं। मॉडल अपनी आंतरिक सीमा को अपडेट करता है और इसी प्रकार की सभी चूकी हुई घटनाएँ दूर हो जाती हैं।
लगातार उदाहरण जोड़ते जाने के आग्रह से बचें। किसी अस्पष्टता के लिए लगभग 4 से अधिक उदाहरण देने पर संदर्भ अनावश्यक रूप से बड़ा हो जाता है और बीच में खो जाने का जोखिम बढ़ता है, जिसमें मॉडल लंबे प्रॉम्प्ट के बीच के हिस्से पर कम ध्यान देता है।
# Add ONE example aimed at the observed miss:
examples.append({
"input": "# loop over each item\n for x in items: process(x)",
"output": {"flag": False,
"reason": "paraphrase of code, not a contradiction"},
})प्रारूप संबंधी त्रुटियाँ? प्रतिक्रिया के साथ पुनः प्रयास करें
कुछ विफलताएँ प्रारूप या संरचना संबंधी होती हैं, तर्क संबंधी त्रुटियाँ नहीं — जैसे गलत संरचित फ़ील्ड, गलत अंकगणितीय योग या गायब कोष्ठक। इनके लिए प्रतिक्रिया के साथ पुनः प्रयास समाधान है: मूल इनपुट, गलत आउटपुट और सटीक सत्यापन त्रुटि वापस भेजें।
महत्वपूर्ण सीमा: पुनः प्रयास तब मदद करता है जब मॉडल सही उत्तर दे सकता हो, लेकिन उससे चूक हो गई हो। यह तब मदद नहीं करता जब आवश्यक जानकारी स्रोत में मौजूद ही न हो — बार-बार प्रयास करने से भी अनुपस्थित डेटा उत्पन्न नहीं किया जा सकता।
def retry_with_feedback(client, system, original, bad_output, error):
return client.messages.create(
model="claude-sonnet-4-5",
max_tokens=512,
system=system,
messages=[
{"role": "user", "content": original},
{"role": "assistant", "content": str(bad_output)},
{"role": "user", "content":
f"That output failed validation: {error}. "
"Return corrected output that satisfies the schema."},
],
)संरचित आउटपुट से गुणवत्ता सुनिश्चित करें
एक बार उदाहरणों से व्यवहार तय हो जाने पर, टूल के उपयोग से JSON Schema द्वारा उसकी संरचना निश्चित करें। इससे वाक्यविन्यास संबंधी त्रुटियाँ समाप्त होती हैं और आवश्यक फ़ील्ड लागू होते हैं। सबसे महत्वपूर्ण अनुशासन यह है: किसी फ़ील्ड को केवल तभी आवश्यक चिह्नित करें जब वह हमेशा मौजूद हो।
किसी ऐसे फ़ील्ड को कभी आवश्यक न बनाएँ जो अनुपस्थित हो सकता है — स्कीमा पूरा करने के लिए मॉडल उसका मान गढ़ देगा। वैकल्पिक या खुले प्रकार के डेटा के लिए "other" मान वाला enum और उसके साथ मुक्त-पाठ विवरण फ़ील्ड उपयोग करें। इससे मनगढ़ंत उत्तर के लिए मजबूर किए बिना अनुबंध का विस्तार संभव रहता है।
verdict_tool = {
"name": "record_verdict",
"description": "Record whether a comment contradicts its code.",
"input_schema": {
"type": "object",
"properties": {
"flag": {"type": "boolean"},
"category": {"type": "string",
"enum": ["contradiction", "style", "other"]},
"detail": {"type": "string"},
},
"required": ["flag"], # only the always-present field
},
}नए समीक्षक से सत्यापित करें
परिष्कृत प्रॉम्प्ट पर भरोसा करने से पहले, उसे स्वतंत्र, नए इंस्टेंस से सत्यापित करें — उसी सत्र से नहीं जिसने आउटपुट तैयार किया था। उसी सत्र की स्व-समीक्षा पक्षपाती होती है: लेखक अपने तर्क को बनाए रखता है और स्वयं को चुनौती नहीं देता।
केवल समग्र अंक पर भरोसा न करें। 97% सटीकता जैसा प्रमुख आँकड़ा किसी फ़ील्ड या इनपुट प्रकार की गंभीर विफलता छिपा सकता है। स्वचालित करने से पहले, लेबलयुक्त सत्यापन-समूह पर कैलिब्रेट किए गए स्तरीकृत नमूने और फ़ील्ड-स्तरीय भरोसे का उपयोग करें। सुधार तब पूरा नहीं होता जब औसत अच्छा दिखे — वह तब पूरा होता है जब हर वर्ग निर्धारित सीमा पार कर ले।
त्वरित जाँच: विफल प्रॉम्प्ट को ठीक करना
एक वर्गीकरण प्रॉम्प्ट आपके लेबलयुक्त परीक्षण-समूह के 92% मामलों में सफल होता है, लेकिन कोड का पुनर्कथन करने वाली टिप्पणियों को लगातार विरोधाभास के रूप में गलत लेबल करता है। कौन-सा सुधार कदम सबसे प्रभावी होगा?
पुनरावलोकन: उदाहरणों से सुधारें, परीक्षणों से प्रमाणित करें
मुख्य बातें:
- उदाहरण विशेषणों से बेहतर होते हैं। स्पष्ट मानदंड और 2-4 लक्षित उदाहरण, 'अधिक सटीक बनें' जैसे अस्पष्ट निर्देशों से बेहतर परिणाम देते हैं।
- मॉडल कम-उदाहरणों से सामान्यीकरण करता है — ये संगति, सीमांत मामलों, आउटपुट प्रारूप और मनगढ़ंत उत्तरों को कम करने के लिए सबसे उपयोगी हैं।
- परीक्षण-आधारित रहें: एक लेबलयुक्त समूह बनाएँ, उसका मूल्यांकन करें, हर विफलता-प्रकार के लिए सीमा पर एक उदाहरण जोड़ें, फिर से चलाएँ और एक समय में एक ही चीज़ बदलें।
- प्रतिक्रिया के साथ पुनः प्रयास प्रारूप संबंधी त्रुटियों को ठीक करता है (मूल इनपुट + गलत आउटपुट + सटीक त्रुटि भेजें) — स्रोत में अनुपस्थित डेटा को नहीं।
- संरचना निश्चित करें JSON Schema से; केवल हमेशा मौजूद फ़ील्ड आवश्यक करें; विस्तार की सुविधा के लिए enum + 'other' + विवरण का उपयोग करें।
- स्वतंत्र रूप से सत्यापित करें: नए इंस्टेंस की समीक्षा उसी सत्र की स्व-समीक्षा से बेहतर होती है, और स्तरीकृत फ़ील्ड-स्तरीय जाँच केवल समग्र सटीकता से बेहतर होती है।
एआई शिक्षक के साथ Python सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 26
- पाठ
- 104
अक्सर पूछे जाने वाले प्रश्न
क्या “उदाहरणों के साथ क्रमिक सुधार” पाठ निःशुल्क है?
हाँ — Claude Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “उदाहरणों के साथ क्रमिक सुधार” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“उदाहरणों के साथ क्रमिक सुधार” में मैं क्या सीखूँगा?
2-4 input/output उदाहरण और test-आधारित पुनरावृत्ति। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Claude Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Claude Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Claude Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।
“उदाहरणों के साथ क्रमिक सुधार” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Claude Architect पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Claude Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- कस्टम कमांड बनाम स्किल्स
- स्किल Frontmatter
- प्लान मोड बनाम प्रत्यक्ष निष्पादन
- उदाहरणों के साथ क्रमिक सुधार