Claude Architect · पाठ

आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड

ऐसे फ़ील्ड को कभी आवश्यक न बनाइए जो अनुपस्थित हो सकते हैं।

पाठ 3, कुल 4 में से13 चरण

आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड, CoddyKit पर Claude Architect का एक निःशुल्क पाठ है। यह 4 में से 3वाँ पाठ है। इस अध्ययन पथ के 3 तक कोई भी पाठ पूरा पढ़ना निःशुल्क है — इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ व्यावहारिक अभ्यास भी उपलब्ध कराता है। यह Claude Architect सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

मुख्य नियम

tool_use और JSON स्कीमा वाला संरचित आउटपुट वाक्य-विन्यास त्रुटियों को समाप्त करता है और आपको आवश्यक फ़ील्ड लागू करने देता है। लेकिन इस शक्ति का एक महत्वपूर्ण जोखिम भी है।

इस पाठ का परीक्षा-केन्द्रित नियम: किसी फ़ील्ड को required तभी चिह्नित करें जब वह हमेशा मौजूद हो। जो फ़ील्ड अनुपस्थित हो सकता है, उसे कभी आवश्यक न बनाएं।

क्यों? जब कोई फ़ील्ड आवश्यक होता है, तो मॉडल को उसका मान देना ही पड़ता है। यदि स्रोत डेटा में वह मान वास्तव में मौजूद नहीं है, तो स्कीमा पूरा करने के लिए मॉडल के पास उसे गढ़ने के अलावा कोई विकल्प नहीं रहता। आवश्यक फ़ील्ड ऐसा वादा है जिसे मॉडल तब भी निभाएगा, जब उसे नहीं निभाना चाहिए।

Required गढ़ने के लिए क्यों बाध्य करता है

JSON स्कीमा की required सारणी संकेत नहीं, बल्कि कठोर बाधा है। आवश्यक कुंजी को छोड़ते हुए मॉडल संरचनात्मक रूप से मान्य ऑब्जेक्ट वापस नहीं कर सकता।

किसी सहायता ईमेल से ग्राहक का phone_number निकालने पर विचार करें, जिसमें फ़ोन नंबर का कोई उल्लेख ही नहीं है। यदि phone_number आवश्यक है, तो मॉडल को कुछ न कुछ देना पड़ेगा — और विश्वसनीय दिखने वाला लेकिन गढ़ा हुआ नंबर बिल्कुल नंबर न होने से भी बदतर है, क्योंकि बाद की कोई प्रक्रिया उसे वास्तविक नंबर से अलग नहीं कर सकती।

समाधान संरचनात्मक है: वैकल्पिक फ़ील्ड को वैकल्पिक बनाएं, ताकि जानकारी अनुपस्थित होने पर मॉडल उन्हें उचित रूप से छोड़ सके।

गढ़ने को आमंत्रित करने वाला स्कीमा

यहाँ एक निष्कर्षण टूल है जिसमें हर फ़ील्ड को आवश्यक चिह्नित किया गया है। नीचे दिए गए ईमेल में फ़ोन नंबर नहीं है — फिर भी स्कीमा मॉडल को एक नंबर गढ़ने के लिए बाध्य करता है।

यह गलत तरीका है। required को ध्यान से पढ़ें: इसमें ऐसे फ़ील्ड सूचीबद्ध हैं जो वास्तविक इनपुट में सचमुच गायब हो सकते हैं।

tool = {
    "name": "extract_contact",
    "description": "Extract contact details from a support email.",
    "input_schema": {
        "type": "object",
        "properties": {
            "name": {"type": "string"},
            "email": {"type": "string"},
            "phone_number": {"type": "string"},
        },
        # BAD: phone_number is often absent, but it is required here
        "required": ["name", "email", "phone_number"],
    },
}

समाधान: केवल सुनिश्चित फ़ील्ड आवश्यक करें

required में केवल वे फ़ील्ड रखें जो हमेशा मौजूद हों। जो भी फ़ील्ड अनुपस्थित हो सकता है, उसे required से बाहर रखें — तब मॉडल उसे ईमानदारी से छोड़ सकता है।

ध्यान दें कि name और email आवश्यक बने रहते हैं क्योंकि हर सहायता टिकट में ये होते हैं, जबकि phone_number सूची से बाहर हो जाता है।

tool = {
    "name": "extract_contact",
    "description": "Extract contact details from a support email.",
    "input_schema": {
        "type": "object",
        "properties": {
            "name": {"type": "string"},
            "email": {"type": "string"},
            "phone_number": {"type": "string"},
        },
        # GOOD: only the always-present fields are required
        "required": ["name", "email"],
    },
}

वैकल्पिक और Nullable: दो अलग साधन

किसी फ़ील्ड को "गायब" रहने देने के दो तरीके हैं, और दोनों का अर्थ अलग है:

वैकल्पिक — कुंजी को बस required से बाहर रखा जाता है। मॉडल कुंजी को पूरे ऑब्जेक्ट से छोड़ सकता है।
Nullable — कुंजी हमेशा मौजूद रहती है, लेकिन उसका प्रकार null की अनुमति देता है, जो संकेत देता है कि "इस स्थान की जाँच की गई और यह खाली मिला।"

वैकल्पिक पूछता है, "क्या मॉडल ने इस फ़ील्ड के बारे में कोई जानकारी दी?" Nullable पूछता है, "मॉडल ने जाँच की और मान स्पष्ट रूप से अनुपस्थित है?" जब बाद की प्रक्रिया को स्थिर संरचना के लिए हर कुंजी मौजूद चाहिए, तब nullable चुनें।

JSON स्कीमा में Nullable व्यक्त करना

किसी फ़ील्ड को nullable बनाने के लिए उसके प्रकारों में null को शामिल करें। संरचित आउटपुट में आम तौर पर इसे anyOf (समर्थित कीवर्ड) से व्यक्त किया जाता है, जो वास्तविक प्रकार और null को मिलाता है।

यहाँ phone_number कुंजी के रूप में हमेशा भेजा जाता है, लेकिन जब ईमेल में कोई नंबर नहीं होता, तब उसका मान null होता है — गढ़ी हुई अंकों की स्ट्रिंग नहीं, बल्कि ईमानदार "खाली" मान।

"phone_number": {
    "anyOf": [
        {"type": "string"},
        {"type": "null"}
    ],
    "description": "Customer phone number, or null if none is stated in the email."
}

Nullable को भी ईमानदार निर्देश चाहिए

Nullable प्रकार null की अनुमति देता है, लेकिन इसका उपयोग कब करना है, यह निर्णय मॉडल ही लेता है। फ़ील्ड के description में आशय स्पष्ट करें: मॉडल से कहें कि अनुमान लगाने के बजाय null लौटाए।

इससे संरचनात्मक गारंटी (प्रकार null की अनुमति देता है) और व्यवहार संबंधी गारंटी (विवरण बताता है कि इसका उपयोग कब करना है) साथ आती हैं। स्कीमा संरचना निर्धारित करता है; विवरण निर्णय को दिशा देता है।

"discount_code": {
    "anyOf": [{"type": "string"}, {"type": "null"}],
    "description": "The promo code the customer mentioned. Return null if no code is present — do not invent or infer one."
}

एनम और 'Other' का निकास विकल्प

गढ़ने का यही जोखिम एनम के साथ भी दिखाई देता है। यदि किसी फ़ील्ड का मान निश्चित मानों के समूह में से एक होना चाहिए और वास्तविक इनपुट उनमें से किसी से मेल नहीं खाता, तो कठोर एनम मॉडल को सबसे निकट का गलत उत्तर चुनने के लिए बाध्य करता है।

विस्तार-योग्यता के लिए परीक्षा में सुझाया गया तरीका है: एनम में "other" मान और साथ में मुक्त-पाठ विवरण फ़ील्ड शामिल करें। इससे जब वास्तविकता आपके एनम से आगे निकल जाए, तो मॉडल के पास गलत वर्गीकरण करने के बजाय ईमानदार विकल्प रहता है।

"category": {
    "type": "string",
    "enum": ["billing", "technical", "account", "other"]
},
"category_detail": {
    "anyOf": [{"type": "string"}, {"type": "null"}],
    "description": "Free-text description used when category is 'other'; otherwise null."
}

दोबारा प्रयास अनुपस्थित मान को नहीं बचा सकता

जब सत्यापन विफल होता है, तो प्रतिक्रिया के साथ दोबारा प्रयास शक्तिशाली होता है — आप मूल दस्तावेज़, मॉडल का गलत आउटपुट और प्रारूप, संरचनात्मक या अंकगणितीय गलतियों को सुधारने के लिए ठीक-ठीक सत्यापन त्रुटि फिर भेजते हैं।

लेकिन जब जानकारी स्रोत में ही अनुपस्थित हो, तो दोबारा प्रयास NOT मदद करता। यदि ईमेल में फ़ोन नंबर नहीं है, तो बार-बार प्रॉम्प्ट देने से सही नंबर उत्पन्न नहीं होगा। सही डिज़ाइन में फ़ील्ड को शुरू से अनुपस्थित रहने की अनुमति होती है — आवश्यक लेकिन गायब फ़ील्ड दोबारा प्रयास करने योग्य अस्थायी त्रुटि नहीं, बल्कि स्कीमा की गलती है।

स्व-सुधार पहचानता है, स्कीमा रोकता है

उन मानों के लिए जो होने चाहिए और सत्यापित किए जा सकते हैं, एक पूरक तकनीक स्व-सुधार है: calculated_total और stated_total दोनों निकालें, ताकि असंगति सामने आए और आप उसे पकड़ सकें।

लेकिन स्व-सुधार मौजूद डेटा की त्रुटियाँ पहचानता है; वह ऐसे फ़ील्ड को सत्यापित नहीं कर सकता जो स्रोत में कभी था ही नहीं। गढ़े गए मानों के विरुद्ध रक्षा की पहली पंक्ति अब भी स्कीमा ही है: जो अनुपस्थित हो सकता है, उसे आवश्यक न बनाएं। परिणाम पर Pydantic-शैली का सत्यापन लागू करके कोड में इन अपरिवर्तनीय शर्तों को लागू करें।

from pydantic import BaseModel
from typing import Optional

class Invoice(BaseModel):
    invoice_id: str            # always present → required
    po_number: Optional[str]   # may be absent → optional / nullable
    calculated_total: float
    stated_total: float        # compare the two to detect discrepancies

खालीपन और विफलता में अंतर करें

वास्तुकार-स्तर का एक और महत्वपूर्ण अंतर: मान्य खाली परिणाम ("ईमेल में फ़ोन नंबर नहीं है") और पहुँच विफलता ("निष्कर्षण टूल में त्रुटि हुई") एक जैसे नहीं हैं।

Nullable फ़ील्ड पहले मामले को स्पष्ट रूप से दर्शाता है। वास्तविक अनुपस्थिति को दोबारा प्रयास करने योग्य त्रुटि न बनाएं और वास्तविक विफलता को चुपचाप null के रूप में न छिपाएं। स्कीमा में स्पष्ट करें कि कौन-सा मामला कौन-सा है: उचित रूप से खाली होने पर null, और पहुँच विफलताओं के लिए अलग त्रुटि मार्ग। अस्पष्ट संकेतों की तुलना में स्पष्ट, संरचित संकेत बाद की प्रक्रियाओं के लिए बेहतर होते हैं।

त्वरित जाँच: वैकल्पिक फ़ील्ड डिज़ाइन

इस नियम को एक वास्तविक निष्कर्षण परिस्थिति पर लागू करें।

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: शायद अनुपस्थित फ़ील्ड को कभी आवश्यक न बनाएं

मुख्य बातें:

केवल हमेशा मौजूद रहने वाले फ़ील्ड अनिवार्य रखें। संभवतः अनुपस्थित फ़ील्ड को अनिवार्य करने पर मॉडल को कोई मान गढ़ना पड़ता है।
वैकल्पिक = कुंजी छोड़ी जा सकती है; नल-स्वीकारी = कुंजी हमेशा मौजूद रहती है, लेकिन उसका मान null हो सकता है। जब उपभोक्ताओं को कुंजियों का स्थिर समूह चाहिए, तब नल-स्वीकारी विकल्प चुनें।
नल-स्वीकारी प्रकारों के साथ ऐसा विवरण दें जिसमें लिखा हो: "अनुपस्थित होने पर null लौटाएँ — अनुमान न लगाएँ।"
सीमित मान-समूहों के लिए विस्तारशीलता हेतु "other" enum मान और मुक्त-पाठ विवरण फ़ील्ड जोड़ें।
प्रतिक्रिया के साथ पुनः प्रयास प्रारूप, संरचनात्मक और अंकगणितीय त्रुटियाँ ठीक करता है, अनुपस्थित जानकारी नहीं। स्व-सुधार मौजूद डेटा में विसंगतियाँ पकड़ता है, अनुपस्थित फ़ील्ड नहीं।
वैध खाली परिणाम को पहुँच विफलता से अलग रखें — दोनों में से किसी को भी चुपचाप न दबाएँ।

शुरुआत निःशुल्क

एआई शिक्षक के साथ Python सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 26
पाठ: 104

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

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

क्या “आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड” पाठ निःशुल्क है?

हाँ — Claude Architect अध्ययन पथ के 3 तक कोई भी पाठ, जिसमें “आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड” भी शामिल है, यहाँ वेब पर पूरा पढ़ना निःशुल्क है। इसके बाद CoddyKit PRO हर पाठ अनलॉक करता है, साथ ही अंतर्निर्मित कोड संपादक और चौबीसों घंटे एआई शिक्षक के साथ इंटरैक्टिव अभ्यास भी उपलब्ध कराता है। Claude Architect पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड” में मैं क्या सीखूँगा?

ऐसे फ़ील्ड को कभी आवश्यक न बनाइए जो अनुपस्थित हो सकते हैं। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Claude Architect का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Claude Architect शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Claude Architect शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 3वाँ पाठ है।

“आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Claude Architect पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Claude Architect पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

गारंटीकृत संरचना के लिए tool_use
JSON स्कीमा डिज़ाइन करना
आवश्यक बनाम वैकल्पिक/Nullable फ़ील्ड
विस्तार-योग्यता के लिए 'other' वाले Enums

← Claude Architect पर वापस जाएँ