# LLM Engineering क्या है — LLM Engineering की बुनियाद

Source: https://www.geekswithgeeks.com/hi/llm-engineering/i-what

> देखें मॉडल उत्पाद का घटक बनने पर क्या बदलता है।

## ऐसा घटक जो function की तरह व्यवहार नहीं करता

Demo को अच्छा prompt और कुछ भाग्यशाली उदाहरण चाहिए। उत्पाद को चाहिए कि मॉडल **हज़ारों अलग इनपुट** पर, हफ़्ते-दर-हफ़्ते, बजट में, हमले के बीच, और आसपास सब बदलते हुए भी स्वीकार्य व्यवहार करे। इसे सच बनाने का अनुशासन **LLM engineering** है। यह उस घटक की भिन्नता से शुरू होती है: उसका आउटपुट **अनिश्चित** है (वही इनपुट अलग उत्तर दे सकता है), **निर्दिष्ट करना कठिन** है ("इसका सार करो" का कोई एक सही उत्तर नहीं), **महँगा** है (हर call की क़ीमत और latency है), **अपारदर्शी** है (आप उसके तर्क में step नहीं कर सकते) और **बदलता** है (providers मॉडल अद्यतन या सेवानिवृत्त करते हैं)। उत्तर परिचित engineering है जो सावधानी से लागू हो: स्पष्ट आवश्यकताएँ और metrics, **स्वचालित मूल्यांकन**, prompts व configuration के लिए version control, tests, **observability**, लागत व latency बजट, चरणबद्ध releases और सुरक्षा नियंत्रण। यह कोर्स वे बुनियादें कवर करता है। पिछले कोर्स हिस्से कवर करते हैं (prompting, RAG, APIs, embeddings, सुरक्षा); यहाँ हम उन्हें काम करने वाले अभ्यास में जोड़ते हैं।

## "मेरे prompt पर चलता है" ship करना नहीं है

LLM engineering साधारण engineering अनुशासन को ऐसे घटक पर लागू करती है जो अनिश्चित, संभाव्य और महँगा है।

![चार चरण: परिभाषित, निर्माण, माप, संचालन।](assets/figures/llm-engineering/section-1-map.svg) — चित्र 1.1 — परिभाषित, निर्माण, माप और संचालन।

## Demo बनाम उत्पाद

ship करने पर क्या बदलता है।

```text
Demo                              Product
5 hand-picked examples            thousands of real, messy inputs, including hostile ones
"looks good"                      measured pass rate with a confidence interval
prompt lives in a notebook        prompt + model + settings versioned and reviewed
one happy path                    retries, fallbacks, timeouts, "I don't know" paths
cost: ignored                     cost per resolved task tracked against a budget
no monitoring                     traces, dashboards, alerts, feedback loop
safety: hope                      least privilege, validation, approvals, red-team tests
```

## सबसे डरावनी विफलता से शुरू करें

पूछें कि ग़लत उत्तर की क्या क़ीमत होगी, और उसी से तय होने दें कि सुविधा को कितनी testing और नियंत्रण चाहिए।

**Quiz:** LLM घटकों का कौन-सा गुण उनकी testing का तरीक़ा सबसे अधिक बदलता है?

- [ ] वे हमेशा laptops पर चलते हैं
- [ ] वे Python में लिखे हैं
- [x] आउटपुट अनिश्चित हैं और कोई एक सही उत्तर नहीं
- [ ] वे कभी नहीं बदलते

*Answer:* आउटपुट अनिश्चित हैं और कोई एक सही उत्तर नहीं. इसलिए हम व्यवहार को कई मामलों पर सांख्यिकीय रूप से मापते हैं।