पाठ 3 / 29
सफलता परिभाषित करना: आवश्यकताएँ और Metrics
"यह अच्छा होना चाहिए" को मापने योग्य लक्ष्यों में बदलें।
Prompt से पहले स्वीकृति test लिखें
बनाने से पहले लिखें कि "अच्छा" का मापने योग्य अर्थ क्या है। उपयोगी आयाम: कार्य गुणवत्ता (शुद्धता, पूर्णता, स्रोतों के प्रति निष्ठा, लहजा); सुरक्षा (लीक नहीं, हानिकारक सामग्री नहीं, सही इनकार); भरोसेमंदी (वैध आउटपुट दर, विफलता में सफलता दर); latency (p50, p95, p99 सिरे-से-सिरे तक); लागत (प्रति अनुरोध और प्रति सफल कार्य); कवरेज (कौन-सी भाषाएँ, user प्रकार और विषय दायरे में हैं); और व्यावसायिक प्रभाव (समाधान दर, बचा समय, conversion, user संतुष्टि)। हर एक के लिए metric, लक्ष्य और मापने का तरीक़ा चुनें। ऑफ़लाइन metrics (निश्चित test set पर, release से पहले) को ऑनलाइन metrics (असली traffic पर, बाद में) से अलग रखें। यह भी तय करें कि मॉडल अनिश्चित हो तो क्या होता है: अच्छा system "मुझे नहीं पता" कह सकता है या मनुष्य को सौंप सकता है, और उस व्यवहार को मापना गुणवत्ता का हिस्सा है।
एक-पन्ने का गुणवत्ता विनिर्देश
लक्ष्य उदाहरण हैं; user की ज़रूरतों से अपने तय करें।
Dimension Metric Target (example) Measured by
quality correct category on test set >= 92% offline eval (200 cases)
faithfulness claims supported by sources >= 95% judge + human spot check
safety successful attacks in red-team suite 0 critical, <= 2% minor attack suite in CI
reliability valid structured output >= 99.5% logs
latency end-to-end p95 <= 3.0 s traces
cost cost per resolved ticket <= 1.50 billing + logs
business tickets solved without human >= 60% product analytics"मुझे नहीं पता" रास्ता शामिल करें
मापें कि system कितनी बार सही तरह मना करता या सौंपता है; यह गुणवत्ता का हिस्सा है।
त्वरित जाँच: Prompt बनाने से पहले metrics और लक्ष्य क्यों परिभाषित करें?
- कोई कारण नहीं
- क्योंकि वरना prompts लिखे नहीं जा सकते
- दस्तावेज़ लंबा करने के लिए
- ताकि आप वस्तुनिष्ठ रूप से बता सकें कि बदलाव ने system सुधारा या नहीं
Answer
ताकि आप वस्तुनिष्ठ रूप से बता सकें कि बदलाव ने system सुधारा या नहीं — लक्ष्य के बिना हर बदलाव राय है।