Claude Architect · पाठ

समेकित मेट्रिक्स विफलताएँ छिपाते हैं

कुल 97% किसी एक विफल दस्तावेज़ प्रकार को छिपा सकता है।

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

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

मुख्य संख्या झूठ बोलती है

आपका extraction pipeline 97% accuracy रिपोर्ट करता है। Dashboard हरा है, stakeholders खुश हैं और कोई human review पूरी तरह बंद करने का प्रस्ताव रखता है।

रुकिए। एकल aggregate number किसी production Claude system की सबसे खतरनाक artifacts में से एक है। यह 97% एक मिश्रित population का औसत है। Averages उन failures को समतल करके छिपाने में माहिर होते हैं जो आपको सबसे अधिक नुकसान पहुँचाते हैं।

इस पाठ में आप सीखेंगे कि केवल aggregate accuracy एक documented anti-pattern क्यों है और human oversight को automate करके हटाने से पहले इसके बजाय क्या measure करना चाहिए।

भ्रामक औसत की संरचना

कल्पना कीजिए कि आपका pipeline समान मात्रा में तीन document types process करता है। Blended score 97% है। एकसमान लगता है, है न?

लेकिन blended numbers risk के आधार पर नहीं, volume के आधार पर weighted होते हैं। कम संख्या वाला, high-stakes document type पूरी तरह दब सकता है। Aggregate आपको यह नहीं बताता कि errors का 3% कहाँ पड़ता है — और व्यवहार में errors लगभग कभी समान रूप से वितरित नहीं होते।

# Same 97% aggregate, two very different realities
docs = {
    "invoices":   {"n": 1000, "correct": 990},  # 99.0%
    "receipts":   {"n": 1000, "correct": 985},  # 98.5%
    "contracts":  {"n": 1000, "correct": 935},  # 93.5%
}
total = sum(d["n"] for d in docs.values())
hits = sum(d["correct"] for d in docs.values())
print(f"aggregate = {hits/total:.1%}")  # 97.0% — hides contracts
for name, d in docs.items():
    print(name, f"{d['correct']/d['n']:.1%}")

एक असफल document type

यह वह failure mode है जिसे परीक्षा में पहचानना है: aggregate accuracy किसी विशिष्ट document type या field पर खराब performance छिपा सकती है।

Contracts की 93.5% accuracy वाले documents आपके सबसे अधिक मूल्यवान और सबसे अधिक liability वाले हो सकते हैं। Contracts से निकाली गई कुछ गलत clauses से उतना नुकसान हो सकता है जितनी बचत हजारों सही receipts से भी नहीं होगी। फिर भी dashboard खुशी-खुशी 97% रिपोर्ट करता है और आपको automation के लिए प्रेरित करता है।

संख्या गलत नहीं है। वह बस गलत प्रश्न का उत्तर दे रही है। "औसतन हम कितने अच्छे हैं?" शायद ही कभी महत्वपूर्ण प्रश्न होता है। "हम सबसे कमजोर कहाँ हैं और उस कमजोरी की कीमत कितनी है?" यही प्रश्न महत्वपूर्ण है।

Field-level failures और भी गहराई में छिपी होती हैं

बात इससे भी सूक्ष्म है। एक ही document type के भीतर भी failure किसी एक field में हो सकती है। Contract extractor parties, dates और addresses को बिल्कुल सही निकाल सकता है — और termination_clause या liability_cap को 20% बार चुपचाप बिगाड़ सकता है।

इन fields का औसत निकालने पर भी आपको एक संतोषजनक score दिखेगा। इसलिए दोनों axes के आधार पर stratify करें: document type AND field के आधार पर। जहाँ critical document type और critical field मिलते हैं, वहीं आपका वास्तविक risk केंद्रित होता है।

# Stratify a labeled validation set by (doc_type, field)
import collections
stats = collections.defaultdict(lambda: [0, 0])  # [correct, total]
for row in labeled_validation_set:
    key = (row["doc_type"], row["field"])
    stats[key][1] += 1
    stats[key][0] += int(row["pred"] == row["gold"])

for (doc, field), (ok, n) in sorted(stats.items()):
    acc = ok / n
    flag = "  <-- REVIEW" if acc < 0.95 else ""
    print(f"{doc:10} {field:18} {acc:.1%} (n={n}){flag}")

स्तरीकृत random sampling

इन छिपे हुए cells को कैसे सामने लाएँ? 100 random documents का sample लेकर नहीं — random sampling आपके volume distribution को दोहराती है, इसलिए rare-but-critical types को लगभग कोई coverage नहीं मिलती।

stratified random sampling का उपयोग करें: population को strata में बाँटें (document type, source, field criticality), फिर हर stratum के भीतर random sample लें। अब आपके low-volume contract type को तीन भाग्यशाली draws के बजाय statistically meaningful sample मिलेगा।

Aggregates जो छिपा देते हैं, उन्हें पकड़ने के लिए यही परीक्षा में सुझाई गई technique है।

from collections import defaultdict
import random

def stratified_sample(docs, key_fn, per_stratum=50):
    strata = defaultdict(list)
    for d in docs:
        strata[key_fn(d)].append(d)
    sample = []
    for stratum, items in strata.items():
        k = min(per_stratum, len(items))
        sample += random.sample(items, k)  # random WITHIN stratum
    return sample

audit_set = stratified_sample(all_docs, key_fn=lambda d: d["doc_type"])

Field-level confidence का calibration

Stratified sampling आपको offline स्थिति बताती है। Production में हर document के लिए यह तय करने हेतु कि उसे auto-accept करना है या human के पास भेजना है, आपको labeled validation set पर calibrated field-level confidence चाहिए।

यहाँ "Calibrated" सबसे महत्वपूर्ण शब्द है। कच्चा confidence-जैसा score तब तक कोई अर्थ नहीं रखता जब तक आप ground truth के आधार पर जाँच न लें कि 0.9 चिह्नित documents वास्तव में लगभग 90% समय सही होते हैं। पहले calibrate करें; तभी "0.97 से ऊपर auto-accept" जैसी threshold का वही अर्थ होगा जो आप समझते हैं।

# Calibrate, then gate per field
def route_extraction(field_name, value, confidence, thresholds):
    # thresholds[field] derived from a LABELED validation set,
    # tighter for high-stakes fields
    if confidence >= thresholds[field_name]:
        return "auto_accept"
    return "human_review"

thresholds = {
    "vendor_name":      0.92,
    "liability_cap":    0.99,   # critical -> stricter gate
    "termination_clause": 0.99,
}

Self-Correction विसंगतियों को सामने लाता है

Calibrated confidence ही एकमात्र signal नहीं है। Numeric extraction के लिए आप मॉडल से उसका अपना काम सामने रखने को कह सकते हैं, ताकि errors को deterministic तरीके से पकड़ा जा सके।

दोनों extract करें: calculated_total (line items का योग) और stated_total (मुद्रित total)। जब दोनों असहमत हों, तो आपको ऐसी discrepancy मिल जाती है जिसे कोई aggregate metric कभी नहीं दिखा सकता — document-level का सत्यापित red flag, जो सीधे review के लिए भेजा जाता है।

# Self-correction: extract both, compare deterministically
schema = {
  "type": "object",
  "properties": {
    "line_items": {"type": "array", "items": {"type": "number"}},
    "calculated_total": {"type": "number"},  # model sums line items
    "stated_total": {"type": "number"}       # printed on the doc
  },
  "required": ["line_items", "calculated_total", "stated_total"]
}

def needs_review(out):
    return abs(out["calculated_total"] - out["stated_total"]) > 0.01

Calibration से सामने आई समस्या को retry न करें

जब low-confidence या discrepant document सामने आए, तो सुधार के बारे में सटीक रहें। Retry-with-feedback format, structural और arithmetic errors को ठीक करता है — मूल document, गलत output और सटीक validation error को मॉडल के पास वापस भेजें।

लेकिन जब जानकारी source में अनुपस्थित हो, तब retry मदद नहीं करता। यदि contract में liability cap कभी बताई ही नहीं गई, तो बार-बार prompt देने से वह उत्पन्न नहीं होगी — और उसे गढ़ने वाला मॉडल ठीक वही failure है जिसे आपके metrics को पकड़ना चाहिए। अनुपस्थित data escalation का मामला है, retry का नहीं।

def handle_low_confidence(doc, output, error):
    if error.kind in ("format", "arithmetic", "schema"):
        # retry with original doc + wrong output + exact error
        return retry_with_feedback(doc, output, error)
    if error.kind == "absent":
        # info not in source -> never retry; route to human
        return escalate_to_human(doc, reason="field absent in source")

Schemas को fabrication के लिए बाध्य नहीं करना चाहिए

यह structured-output के उस नियम से जुड़ा है जो आपके metrics को सीधे प्रभावित करता है। किसी schema field को तभी required चिह्नित करें जब वह हमेशा मौजूद हो। ऐसी field को कभी required न बनाएँ जो अनुपस्थित हो सकती है — schema पूरा करने के लिए मॉडल कोई मान गढ़ देगा, और fabricated value फिर भी confident answer के रूप में गिनी जाएगी।

यह fabrication aggregate accuracy check से सीधे निकल सकती है, जबकि आपके सबसे महत्वपूर्ण field को दूषित कर सकती है। Optional fields को optional रखें और extensibility के लिए "other" value वाले enum के साथ free-text detail field का उपयोग करें।

{
  "type": "object",
  "properties": {
    "vendor_name":   {"type": "string"},
    "liability_cap": {"type": ["number", "null"]},
    "doc_category": {
      "type": "string",
      "enum": ["invoice", "receipt", "contract", "other"]
    },
    "category_detail": {"type": "string"}
  },
  "required": ["vendor_name", "doc_category"]
}

Provenance failures को audit योग्य बनाती है

किसी छिपी हुई विफलता की जाँच करने के लिए, आपको किसी भी निकाले गए दावे का उसके मूल स्रोत तक पता लगाने में सक्षम होना चाहिए। दावे-से-स्रोत मैपिंग बनाए रखें: स्रोत दस्तावेज़ का नाम, सटीक उद्धरण, स्थान और प्रकाशन की तारीख।

जब स्तरीकृत ऑडिट अनुबंध स्तर को चिह्नित करता है, तो स्रोत-उत्पत्ति विवरण समीक्षक को सीधे उस उद्धरण तक पहुँचा देता है जिससे गलत liability_cap बना था — पूरे दस्तावेज़ को दोबारा पढ़ने के बजाय। स्रोत-उत्पत्ति विवरण "हमारा मेट्रिक कहीं गलत लग रहा है" को बदलकर "यह फ़ील्ड, इस उद्धरण से, इस पृष्ठ पर, गलत है" कर देता है।

extraction = {
    "field": "liability_cap",
    "value": 500000,
    "provenance": {
        "source_doc": "acme_msa_2026.pdf",
        "quote": "liability shall not exceed five hundred thousand dollars",
        "page": 7,
        "published": "2026-01-15"
    }
}

अनुमानों पर नहीं, प्रमाण पर निर्णय लें

इसे मिलाकर स्वचालन का निर्णय लें। किसी स्तर पर मानवीय निगरानी घटाने का अधिकार आपको तभी मिलता है, जब उस विशिष्ट स्तर के प्रमाण ऐसा करने का समर्थन करें।

  • स्तरीकृत ऑडिट दिखाता है कि वह स्तर लक्ष्य सटीकता पूरी करता है।
  • फ़ील्ड-स्तरीय विश्वास-स्तर को लेबल किए गए डेटा पर अंशांकित किया गया है।
  • स्व-सुधार और स्रोत-उत्पत्ति विवरण शेष त्रुटियों को पकड़ते हैं।

और ध्यान दें कि इस सूची में क्या नहीं है: मॉडल का स्वयं आँका गया विश्वास-स्तर (1-10) या भावना-स्कोर खराब एस्केलेशन ट्रिगर है। अच्छे ट्रिगर हैं सीमा-उल्लंघन, नीति की कमियाँ, प्रगति न होना और स्पष्ट मानवीय अनुरोध — मॉडल का अपना अप्रशिक्षित आत्म-मूल्यांकन नहीं।

त्वरित जाँच: 97% को समझना

मेट्रिक्स और निगरानी पर आधारित एक परिदृश्य-शैली का प्रश्न।

पुनरावलोकन: छिपी विफलताओं को दृश्यमान बनाएँ

मुख्य बातें:

  • समग्र सटीकता, प्रत्येक प्रकार और प्रत्येक फ़ील्ड की विफलताओं को छिपा देती है — यह जोखिम के आधार पर नहीं, मात्रा के आधार पर भारित होती है।
  • विश्वास करने से पहले स्तरों में बाँटें: दस्तावेज़ प्रकार और फ़ील्ड के अनुसार स्तरीकृत यादृच्छिक नमूनाकरण उन कमजोर खानों को सामने लाता है जिन्हें यादृच्छिक नमूनाकरण छोड़ देता है।
  • किसी भी सीमा का उपयोग करके स्वतः-स्वीकृति देने से पहले, फ़ील्ड-स्तरीय विश्वास-स्तर को लेबल किए गए सत्यापन-समुच्चय पर अंशांकित करें।
  • स्व-सुधार (calculated_total और stated_total निकालना) और स्रोत-उत्पत्ति विवरण (दावे का स्रोत-उद्धरण, पृष्ठ, तारीख) शेष त्रुटियों को पकड़ते और समझाते हैं।
  • संभवतः अनुपस्थित फ़ील्ड को आवश्यक न बनाएँ (गढ़ंत) और स्वयं आँके गए विश्वास-स्तर या भावना के आधार पर एस्केलेट न करें — सीमा-उल्लंघन, नीति की कमियाँ, प्रगति न होना और स्पष्ट मानवीय अनुरोध इस्तेमाल करें।

प्रमाण के आधार पर, हर स्तर के लिए स्वचालन का अधिकार अर्जित करें। हरा डैशबोर्ड जाँच की शुरुआत है, अंत नहीं।

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

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

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

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

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

क्या “समेकित मेट्रिक्स विफलताएँ छिपाते हैं” पाठ निःशुल्क है?

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

“समेकित मेट्रिक्स विफलताएँ छिपाते हैं” में मैं क्या सीखूँगा?

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

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

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

“समेकित मेट्रिक्स विफलताएँ छिपाते हैं” पाठ पूरा करने में कितना समय लगता है?

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

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

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

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

  1. दावे से स्रोत का मानचित्रण
  2. परस्पर-विरोधी डेटा और तिथियाँ
  3. समेकित मेट्रिक्स विफलताएँ छिपाते हैं
  4. स्तरीकृत सैंपलिंग और कैलिब्रेशन
← Claude Architect पर वापस जाएँ