पुनःप्रयास कब सहायक है (और कब नहीं)
प्रारूप त्रुटियों के लिए उपयोगी; अनुपलब्ध डेटा के लिए बेकार।
पुनःप्रयास कब सहायक है (और कब नहीं), CoddyKit पर Claude Architect का एक निःशुल्क पाठ है। यह 4 में से 1वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Claude Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
पुनः प्रयास की सहज प्रवृत्ति
जब मॉडल का आउटपुट सत्यापन में विफल होता है, तो तुरंत फिर से प्रयास करना स्वाभाविक लगता है। कभी-कभी यह बहुत अच्छा काम करता है। कभी-कभी यह बिना लाभ के टोकन और विलंबता खर्च करता है।
वास्तुकार के रूप में आपका काम है कि पुनः प्रयास का चक्र जोड़ने से पहले यह समझें कि आप किस विफलता को देख रहे हैं। पुनः प्रयास एक सटीक उपकरण है, हर स्थिति के लिए सुरक्षा-जाल नहीं।
यह पाठ एक स्पष्ट सीमा बताता है: पुनः प्रयास प्रारूप और संरचनात्मक त्रुटियों के लिए उत्कृष्ट है, लेकिन तब बेकार है जब आवश्यक जानकारी स्रोत में अनुपस्थित हो।
दो बिल्कुल अलग विफलताएँ
निष्कर्षण और संरचित-आउटपुट पाइपलाइन दो मूलभूत तरीकों से विफल होती हैं:
- प्रारूप / संरचनात्मक / अंकगणितीय त्रुटियाँ — उत्तर स्रोत में मौजूद है, लेकिन मॉडल ने उसे गलत रूप में प्रस्तुत किया: अमान्य JSON, ऐसा अनिवार्य फ़ील्ड जो वास्तव में उपलब्ध डेटा के बावजूद छूट गया, या ऐसा कुल जो जोड़ने पर सही नहीं बैठता।
- अनुपस्थित जानकारी — स्रोत दस्तावेज़ में वह मान है ही नहीं। निकालने के लिए कुछ मौजूद नहीं है।
प्रतिक्रिया के साथ पुनः प्रयास पहली श्रेणी को ठीक कर सकता है। जो डेटा कभी था ही नहीं, उसे यह उत्पन्न नहीं कर सकता। दोनों को एक समझ लेना एक सामान्य गलत पैटर्न है।
प्रतिक्रिया के साथ पुनः प्रयास वास्तव में क्या भेजता है
अच्छा पुनः प्रयास "वही prompt फिर चलाएँ और उम्मीद करें" नहीं होता। यह सुधारात्मक पुनः प्रयास होता है। आप मॉडल को तीन चीज़ें भेजते हैं:
- मूल स्रोत दस्तावेज़
- उसके द्वारा बनाया गया गलत आउटपुट
- उत्पन्न हुई सटीक सत्यापन त्रुटि
इससे मॉडल को स्व-सुधार के लिए आवश्यक विशिष्ट संकेत मिलता है। "यह गलत था, और कोशिश करें" जैसी अस्पष्ट प्रतिक्रिया, सटीक सत्यापनकर्ता संदेश देने की तुलना में बहुत खराब परिणाम देती है।
def retry_with_feedback(client, source_doc, bad_output, validation_error):
return client.messages.create(
model="claude-sonnet-4-5",
max_tokens=1024,
messages=[
{"role": "user", "content": (
"Extract the invoice fields as JSON.\n\n"
f"SOURCE DOCUMENT:\n{source_doc}\n\n"
f"YOUR PREVIOUS OUTPUT (rejected):\n{bad_output}\n\n"
f"VALIDATION ERROR:\n{validation_error}\n\n"
"Fix only what the error names. Return corrected JSON."
)}
],
)प्रारूप त्रुटियाँ: पुनः प्रयास का सबसे प्रभावी क्षेत्र
प्रारूप और संरचनात्मक समस्याएँ ठीक वही क्षेत्र हैं जहाँ पुनः प्रयास सबसे अच्छा काम करता है, क्योंकि सही उत्तर उसी इनपुट से फिर प्राप्त किया जा सकता है:
- गलत संरचना वाला JSON या अनावश्यक अंतिम अल्पविराम
- दस्तावेज़ में मौजूद लेकिन आउटपुट में अनुपस्थित फ़ील्ड
- गलत enum अक्षर-रूप या अनपेक्षित कुंजी
- ऐसी अंकगणित जिसका मिलान नहीं बैठता
दूसरे चरण में सत्यापनकर्ता के संदेश के आधार पर मॉडल लगभग हमेशा सही संरचना दे देता है। इससे भी बेहतर है कि शुरुआत में ही tool_use + JSON Schema से संरचना लागू करें, ताकि अधिकांश वाक्य-विन्यास त्रुटियाँ हों ही नहीं।
स्व-सुधार से अंकगणित पकड़ना
अंकगणितीय विसंगतियाँ ऐसी प्रारूप-श्रेणी की त्रुटि हैं जिन्हें पुनः प्रयास ठीक कर सकता है — लेकिन पहले आपको उन्हें पकड़ना होगा। तरीका यह है: मॉडल द्वारा निकाले गए दोनों मान और दस्तावेज़ में लिखे मान को निकालकर उनकी तुलना करें।
calculated_total (पंक्ति मदों का योग) AND stated_total (मुद्रित कुल) निकालें। यदि दोनों अलग हैं, तो आपके पास प्रतिक्रिया में भेजने योग्य एक ठोस, पुनः प्रयास की जा सकने वाली सत्यापन त्रुटि है — कोई अस्पष्ट अनुमान नहीं।
from pydantic import BaseModel, model_validator
class Invoice(BaseModel):
line_items: list[float]
calculated_total: float
stated_total: float
@model_validator(mode="after")
def totals_match(self):
if round(self.calculated_total, 2) != round(self.stated_total, 2):
raise ValueError(
f"calculated_total {self.calculated_total} != "
f"stated_total {self.stated_total}"
)
return selfजहाँ पुनः प्रयास की सीमा आ जाती है
अब कठिन सीमा समझिए। यदि कोई फ़ील्ड स्रोत में मौजूद नहीं है, तो पुनः प्रयास करने से कोई उपयोगी परिणाम नहीं मिलता। हर चक्र में मॉडल के सामने दो खराब विकल्प होते हैं:
- वही "missing" परिणाम लौटाना — विलंबता और लागत की बर्बादी।
- सत्यापनकर्ता को संतुष्ट करने के लिए कोई विश्वसनीय दिखने वाला मान गढ़ना — यह और भी बुरा है, क्योंकि अब आपने भरोसेमंद डेटा में मनगढ़ंत जानकारी डाल दी है।
अनुपस्थित डेटा पर पुनः प्रयास का दबाव सक्रिय रूप से गढ़ने के लिए प्रेरित करता है। बार-बार prompt देने से उस मान को नहीं निकाला जा सकता जो कभी लिखा ही नहीं गया।
Schema का जाल: अनिवार्य फ़ील्ड
यहीं पर स्कीमा के डिज़ाइन का एक सूक्ष्म निर्णय समस्या पैदा करता है। किसी फ़ील्ड को required तभी चिह्नित करें जब वह हमेशा मौजूद हो। जो फ़ील्ड अनुपस्थित हो सकता है, उसे कभी आवश्यक न बनाएं — स्कीमा को संतुष्ट करने के लिए मॉडल उसे गढ़ देगा, और आपका पुनःप्रयास चक्र लगातार गलत डेटा स्वीकार करता रहेगा।
वैकल्पिक डेटा के लिए फ़ील्ड को वैकल्पिक बनाएं और मॉडल को ईमानदारी से अनुपस्थिति बताने दें। ऐसा स्कीमा, जो आविष्कार करने के लिए मजबूर करता है, उसे कोई पुनःप्रयास नहीं बचा सकता।
tax_id_tool = {
"name": "extract_vendor",
"description": "Extract vendor fields from an invoice.",
"input_schema": {
"type": "object",
"properties": {
"vendor_name": {"type": "string"},
# tax_id is OFTEN absent -> optional, never required
"tax_id": {"type": ["string", "null"]},
},
# require ONLY the always-present field
"required": ["vendor_name"],
},
}अनुपस्थिति को प्रथम-श्रेणी परिणाम बनाएं
अनुपस्थित डेटा का समाधान पुनःप्रयास करना नहीं, बल्कि मॉडल को इसे स्पष्ट रूप से बताने देना है। वास्तविक पहुँच/प्रारूप विफलता (जिस पर शायद पुनःप्रयास किया जा सके) और वैध खाली परिणाम (कोई मान मौजूद नहीं है — रुकें, चक्र न चलाएं) में अंतर करें।
"other"/"not_present" मान वाले एनम के साथ मुक्त-पाठ विवरण फ़ील्ड का उपयोग करें। इससे स्कीमा विस्तार योग्य रहता है और आगे का कोड फ़ील्ड को छोड़ने के लिए स्पष्ट संकेत प्राप्त करता है, बजाय इसके कि एक निष्फल पुनःप्रयास शुरू हो।
{
"properties": {
"discount_status": {
"type": "string",
"enum": ["applied", "none", "not_present", "other"]
},
"discount_detail": { "type": "string" }
},
"required": ["discount_status"]
}प्रतिक्रिया-विधि से नहीं, त्रुटि के प्रकार से मार्ग चुनें
परिपक्व प्रसंस्करण-श्रृंखलाएं सत्यापन विफल होने के कारण के आधार पर अलग-अलग मार्ग चुनती हैं। संरचित त्रुटियां यह संभव बनाती हैं; सामान्य त्रुटियां ("ऑपरेशन विफल हुआ") इसे रोक देती हैं।
- सत्यापन / प्रारूप / अंकगणितीय असंगति → प्रतिक्रिया सहित पुनःप्रयास।
- क्षणिक (समय-सीमा समाप्ति, दर सीमा) → स्थानीय रूप से पुनःप्रयास करें, मान अभी भी मौजूद है।
- अनुपस्थित डेटा / वैध खाली परिणाम → "मौजूद नहीं" दर्ज करें और आगे बढ़ें। पुनःप्रयास न करें।
यह संरचित MCP त्रुटियों जैसा ही है: एक errorCategory और isRetryable फ़्लैग आपके चक्र को अंधाधुंध चलते रहने के बजाय समझदारी से मार्ग चुनने देते हैं।
def handle(result):
if result.error_category in ("validation", "arithmetic"):
return "retry_with_feedback" # answer is recoverable
if result.error_category == "transient" and result.is_retryable:
return "retry_local" # network/rate-limit blip
if result.error_category == "absent":
return "record_not_present" # NEVER retry absent data
return "escalate"चक्र की सीमा तय करें, लेकिन उस पर निर्भर न रहें
वास्तव में पुनःप्रयास योग्य प्रारूप त्रुटियों के लिए भी चक्र की सीमा तय करें। 2–3 प्रयासों का बजट पर्याप्त है — यदि सुधारात्मक पुनःप्रयास तब तक सही परिणाम तक नहीं पहुंचा है, तो समस्या आमतौर पर प्रारूप की नहीं, बल्कि अनुपस्थित डेटा या अत्यधिक सख्त स्कीमा की होती है।
सीमा को सुरक्षा-जाल मानें, कभी भी रुकने का प्राथमिक साधन नहीं। वास्तविक समाप्ति-शर्त है "सत्यापन सफल हुआ"। यदि आप बाहर निकलने के लिए सीमा पर निर्भर हैं, तो यह संकेत है कि आप ऐसी चीज़ का पुनःप्रयास कर रहे हैं जिसे पुनःप्रयास ठीक नहीं कर सकता।
def extract(client, doc, validate, max_attempts=3):
out = first_pass(client, doc)
for _ in range(max_attempts):
try:
return validate(out) # PRIMARY stop: it's valid
except ValidationError as e:
out = retry_with_feedback(client, doc, out, str(e))
# SAFETY NET only -- not the intended exit path
raise RuntimeError("unresolved after retries; likely absent data")जब अच्छा पुनःप्रयास भी आपको नहीं बचा सकता
आर्किटेक्ट को दो और वास्तविक सीमाओं का सम्मान करना चाहिए:
- नया, स्वतंत्र समीक्षक उसी सत्र में की गई स्व-समीक्षा से बेहतर होता है। लेखक अपनी तर्क-प्रक्रिया से जुड़ा रहता है और स्वयं को चुनौती नहीं देगा — इसलिए वास्तविक दूसरी राय के लिए उसी संदर्भ में एक और संदेश भेजने के बजाय नए इंस्टेंस से सत्यापन करें।
- रोकने वाली, समय-संवेदी जांचें तत्काल प्रवाह में होनी चाहिए। Batch API 50% सस्ता है, लेकिन इसमें कोई विलंबता SLA नहीं है और इसकी अवधि 24 घंटे तक हो सकती है — रात भर चलने वाले ऑडिट के लिए बढ़िया, पर मर्ज से पहले या वास्तविक समय के सत्यापन-द्वार के लिए अनुपयुक्त।
पुनःप्रयास का समायोजन इसके नीचे मौजूद गलत सत्यापन-वास्तुकला की भरपाई नहीं कर सकता।
त्वरित जांच: पुनःप्रयास करें या नहीं?
एक संरचित-निष्कर्षण प्रसंस्करण-श्रृंखला आपूर्तिकर्ता के चालानों से फ़ील्ड निकालती है। Pydantic सत्यापक किसी आउटपुट को इसलिए अस्वीकार करता है क्योंकि tax_id फ़ील्ड खाली है। जांच करने पर पता चलता है कि इस विशेष चालान पर कहीं भी कर पहचान संख्या छपी हुई नहीं है। सही वास्तुकला क्या होगी?
पुनरावलोकन: पुनःप्रयास छेनी है, हथौड़ा नहीं
मुख्य बातें:
- पुनःप्रयास प्रारूप, संरचनात्मक और अंकगणितीय त्रुटियों को ठीक करता है — मूल दस्तावेज़ + गलत आउटपुट + सटीक सत्यापन त्रुटि भेजें।
- पुनःप्रयास अनुपस्थित डेटा को ठीक नहीं कर सकता। यदि स्रोत में वह मौजूद नहीं है, तो चक्र चलाने से केवल लागत बढ़ती है और गढ़े हुए डेटा का जोखिम पैदा होता है।
- संभवतः अनुपस्थित फ़ील्ड को कभी आवश्यक न बनाएं — उसे वैकल्पिक बनाएं और मॉडल को "मौजूद नहीं" बताने दें।
- त्रुटि के प्रकार से मार्ग चुनें: सत्यापन/अंकगणित → प्रतिक्रिया सहित पुनःप्रयास; क्षणिक त्रुटि → स्थानीय पुनःप्रयास; अनुपस्थित → दर्ज करें और रुकें।
- प्रयासों की सीमा (2–3) को सुरक्षा-जाल के रूप में रखें; प्राथमिक रुकने की शर्त है "सत्यापन सफल हुआ"।
- वास्तविक दूसरी राय के लिए नए इंस्टेंस का उपयोग करें; रोकने वाली जांचों को Batch API पर नहीं, तत्काल प्रवाह में रखें।
एआई शिक्षक के साथ Python सीखें — निःशुल्क
अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।
- पाठ्यक्रम
- 26
- पाठ
- 104
अक्सर पूछे जाने वाले प्रश्न
क्या “पुनःप्रयास कब सहायक है (और कब नहीं)” पाठ निःशुल्क है?
हाँ — Claude Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “पुनःप्रयास कब सहायक है (और कब नहीं)” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।
“पुनःप्रयास कब सहायक है (और कब नहीं)” में मैं क्या सीखूँगा?
प्रारूप त्रुटियों के लिए उपयोगी; अनुपलब्ध डेटा के लिए बेकार। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Claude Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।
क्या Claude Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?
पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Claude Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 1वाँ पाठ है।
“पुनःप्रयास कब सहायक है (और कब नहीं)” पाठ पूरा करने में कितना समय लगता है?
CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।
क्या मैं इस Claude Architect पाठ में कोड लिख और चला सकता हूँ?
हाँ। हर Claude Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।
इस पाठ्यक्रम के सभी पाठ
- पुनःप्रयास कब सहायक है (और कब नहीं)
- प्रतिक्रिया सहित पुनःप्रयास प्रॉम्प्ट
- स्व-सुधार
- बहु-चरणीय और स्वतंत्र समीक्षा