# केस स्टडी: Support सहायक को Demo से Production तक ले जाना — LLM Engineering की बुनियाद

Source: https://www.geekswithgeeks.com/hi/llm-engineering/z-case

> एक सुविधा के पूरे जीवनचक्र से गुज़रें।

## यात्रा

एक टीम ऐसा सहायक बनाती है जो support tickets वर्गीकृत करता है, help centre से उत्तर का मसौदा बनाता है और कठिन मामले मनुष्यों को सौंपता है। **परिभाषित**: लिखे लक्ष्य (category सटीकता कम से कम 92%, faithfulness कम से कम 95%, वैध आउटपुट कम से कम 99.5%, p95 latency अधिकतम 3 s, लागत प्रति हल ticket अधिकतम 1.50, शून्य गंभीर सुरक्षा विफलताएँ)। **मूल्यांकन**: 200 labelled tickets (अंग्रेज़ी, हिंदी, Hinglish, विरोधी और अनुत्तरणीय समेत), programmatic जाँचों के साथ calibrated judge वाला harness (80 मानव-labelled मामलों पर kappa मापा, क्रम बदला), एक held-out हिस्सा जिस पर कोई tune नहीं करता, और leakage जाँच। **दोहराव**: paired sign test और confidence intervals से तुलना किए prompt संस्करण; सिरे-से-सिरे जाँच के बाद cascade आसान tickets छोटे मॉडल को भेजता है; semantic-सुरक्षित FAQ cache। **मज़बूती**: दो-चरण repair loop और मानव fallback के साथ schema validation, timeouts, backoff के साथ retries, ख़र्च सीमाएँ, सुरक्षा नियंत्रण, हर अनुरोध पर release ID सहित tracing। **Release**: CI द्वार (गुणवत्ता, attack suite, latency, लागत), shadow सप्ताह, 2% canary, rollback नियमों के साथ बढ़ाना। **संचालन**: dashboards, PSI drift जाँच, साप्ताहिक नमूना समीक्षाएँ, प्रतिक्रिया मूल्यांकन set में लौटाना, system card, घटना runbook, और मॉडल चुनाव का त्रैमासिक पुनर्मूल्यांकन।

## मापें, द्वार लगाएँ, देखें, सुधारें

मापा हुआ, versioned, देखने-योग्य, सुरक्षित रूप से जारी system अचरज में भटकने की जगह लगातार सुधरता है।

![चार आदतें: मापें, द्वार, देखें, सीखें।](assets/figures/llm-engineering/section-8-map.svg) — चित्र 8.1 — मापें, द्वार, देखें और सीखें।

## एक पन्ने पर अभ्यास

हर पंक्ति इस कोर्स के एक खंड से जुड़ती है।

```text
Define      written targets: quality, faithfulness, validity, latency, cost, safety                (Sec 1)
Evaluate    200 labelled cases, harness, calibrated judge, held-out slice, leakage check, intervals  (Sec 2)
Engineer    versioned bundle + release ID, CI gate, schema validation + repair, FT only if needed (Sec 3)
Optimise    cache, cascade (checked end to end), hedging/timeouts, capacity + unit economics      (Sec 4)
Protect     traces, PSI drift, layered failure handling, failure drills                           (Sec 5)
Release     shadow -> canary -> ramp with rollback rules; hosted vs self-host decision by numbers  (Sec 6)
Govern      safety checklist, privacy map, system card, roles, blameless reviews                  (Sec 7)
```

## दोहराव से पहले लक्ष्य लिखें

परिणाम देखने के बाद चुने लक्ष्य आसानी से मोड़े जाते हैं।

**Quiz:** अपनाने से पहले cascade की जाँच सिरे-से-सिरे क्यों की जाती है?

- [ ] Cascades कभी नहीं चलते
- [x] लागत बचत कठिन श्रेणियों में गुणवत्ता हानि छिपा सकती है
- [ ] APIs इसे माँगती हैं
- [ ] Token उपयोग बढ़ाने के लिए

*Answer:* लागत बचत कठिन श्रेणियों में गुणवत्ता हानि छिपा सकती है. गुणवत्ता और लागत की तुलना हमेशा केवल-मज़बूत baseline से करें।