द कैपेबिलिटी-रिलायबिलिटी गैप
यहाँ एक पैटर्न है जो लगभग हर उस व्यक्ति को जलाता है जो पहली बार AI को असली उपयोगकर्ताओं तक पहुँचाता है:
मॉडल आपके परीक्षण में वह काम पूरी तरह सही करता है। यह प्रोडक्शन में विफल हो जाता है। आप उलझन में हैं, क्योंकि आपने इसे काम करते देखा था।
जिससे आप टकराए वह है कैपेबिलिटी-रिलायबिलिटी गैप।
कैपेबिलिटी (क्षमता) का मतलब है कि मॉडल कोई काम कर सकता है — यह कुछ शर्तों के तहत, कम से कम एक बार, एक सही आउटपुट पैदा करता है।
रिलायबिलिटी (विश्वसनीयता) का मतलब है कि मॉडल काम को लगातार सही करता है — अलग-अलग इनपुट्स पर, बार-बार के रन पर, शब्दावली या कॉन्टेक्स्ट में हल्के बदलावों पर।
डेमो कैपेबिलिटी साबित करते हैं। प्रोडक्शन को रिलायबिलिटी चाहिए। ये अलग गुण हैं, और ज्यादातर गाइड इन्हें घालमेल कर देती हैं।
डेमो झूठ क्यों बोलते हैं
जब आप किसी प्रॉम्प्ट का परीक्षण करते हैं, तो आप आमतौर पर:
- इसे उन इनपुट्स पर चलाते हैं जिन्हें आपने खुद डिजाइन किया
- इसे मुट्ठी भर बार चलाते हैं
- उस आउटपुट को चुन लेते हैं जो अच्छा दिखता है
- प्रॉम्प्ट को तब तक मरोड़ते हैं जब तक यह सही न दिखे
यह प्रक्रिया कैपेबिलिटी के लिए अनुकूलित करती है। प्रॉम्प्ट अब आपके उदाहरणों पर काम करता है। आपने एक सही आउटपुट देखा है। आप इसे शिप कर देते हैं।
समस्या यह है कि प्रोडक्शन में उपयोगकर्ता के इनपुट्स आपके उदाहरण नहीं हैं। वे ज्यादा अव्यवस्थित, ज्यादा विविध हैं, ऐसे तरीकों से कहे गए हैं जिनका आपने अनुमान नहीं लगाया। मॉडल का उन पर कभी परीक्षण नहीं हुआ। आपको कोई अंदाजा नहीं कि यह उन पर कैसा प्रदर्शन करता है।
एक अकेला अच्छा आउटपुट कोई प्रदर्शन-अनुमान नहीं है। यह एक किस्सा है।
वैरिएंस छिपा हुआ चर है
LLM स्टोकैस्टिक होते हैं। वही प्रॉम्प्ट दो बार चलाएँ और आपको अक्सर अलग आउटपुट मिलते हैं। यह वैरिएंस सामान्य है और आमतौर पर ठीक है। पर इसका मतलब है कि प्रासंगिक सवाल "क्या इसने काम किया?" नहीं है — यह है "यह कितने अंश समय काम करता है?"
एक ऐसा काम जहाँ मॉडल 95% समय सफल होता है, डेमो में शानदार दिखता है और मोटे तौर पर हर बीस में से एक उपयोगकर्ता पर टूट जाता है। एक ऐसा काम जहाँ यह 60% समय सफल होता है, जब आप ही इसे चला रहे हों तो ठीक लगता है। ये बहुत अलग स्थितियाँ हैं, और आप इन्हें मापे बिना एक-दूसरे से अलग नहीं बता सकते।
व्यवहार में कैपेबिलिटी-रिलायबिलिटी स्पेक्ट्रम
| आयाम | सक्षम पर अविश्वसनीय | विश्वसनीय |
|---|---|---|
| परीक्षित इनपुट | लेखक-डिजाइन किए उदाहरण | विविध, असली-उपयोगकर्ता इनपुट |
| सैंपल आकार | कुछ रन | कई उदाहरणों पर बार-बार के रन |
| विफलता-मोड की दृश्यता | विफलताएँ परीक्षण में दुर्लभ, प्रोडक्शन में आम | विफलताएँ मापी और समझी जाती हैं |
| आपको कैसे पता चलता है कि यह टूटा | उपयोगकर्ता शिकायतें | आपका eval सूट |
| आप इसे कैसे सुधारते हैं | प्रॉम्प्ट का अंदाजा लगाकर जाँचना | पास रेट ट्रैक करना, विफलताओं को व्यवस्थित ढंग से डीबग करना |
| डिप्लॉयमेंट का आत्मविश्वास | वाइब-आधारित | सबूत-आधारित |
Evals ही असली खाई (मोट) हैं
बेहतर प्रॉम्प्ट कैपेबिलिटी बढ़ा सकते हैं। सिर्फ evals आपको बता सकते हैं कि आपने रिलायबिलिटी बढ़ाई या नहीं।
एक eval एक संरचित परीक्षण है: इनपुट्स का एक सेट, अपेक्षित आउटपुट या मूल्यांकन मानदंड, और पास रेट मापने का एक तरीका। आप मॉडल को इनपुट्स पर चलाते हैं, आउटपुट्स को स्कोर करते हैं, और एक संख्या पाते हैं। फिर आप कुछ बदलते हैं — प्रॉम्प्ट, मॉडल, टेम्परेचर — और इसे दोबारा चलाते हैं। अब आपके पास एक संकेत है।
यह चमकदार नहीं है। यह AI प्रोडक्ट काम का वह हिस्सा है जिसे ज्यादातर ट्यूटोरियल पूरी तरह छोड़ देते हैं। पर जब आप शिप कर रहे हों, तो उस सवाल का जवाब देने का यही एकमात्र तरीका है जो असल में मायने रखता है: "यह उन इनपुट्स पर कितनी बार काम करता है जिन्हें मैंने नहीं देखा?"
शुरू करने का एक सरल तरीका
शुरू करने के लिए आपको इन्फ्रास्ट्रक्चर की जरूरत नहीं। यहाँ एक न्यूनतम व्यवहार्य eval लूप है:
-
एक गोल्डन सेट बनाएँ। 20–50 असली या यथार्थवादी इनपुट इकट्ठा करें। हर एक के लिए लिखें कि एक सही आउटपुट कैसा दिखता है (या उसे आँकने के मानदंड)। ये आपके गोल्डन उदाहरण हैं।
-
इसे N बार चलाएँ। अपने प्रॉम्प्ट को हर उदाहरण पर कई बार चलाएँ। रन-दर-रन वैरिएंस आपको प्रॉम्प्ट की स्थिरता के बारे में बताता है; उदाहरण-दर-उदाहरण वैरिएंस आपको कवरेज के बारे में बताता है।
-
पास रेट ट्रैक करें। हर (इनपुट, रन) जोड़ी के लिए, पास या फेल दर्ज करें। कुल दर निकालें। यह संख्या आपकी रिलायबिलिटी तस्वीर की शुरुआत है।
-
इसे एक रिग्रेशन टेस्ट बनाएँ। हर बार जब आप प्रॉम्प्ट बदलें, eval दोबारा चलाएँ। अगर पास रेट गिरता है, तो आपने कुछ तोड़ दिया है। अगर बढ़ता है, तो आपने असली सुधार किया है।
बस इतना ही। एक स्प्रेडशीट काम करती है। अनुशासन औजार से ज्यादा मायने रखता है।
यह क्यों एक इंजीनियरिंग समस्या है, प्रॉम्प्टिंग समस्या नहीं
जब कोई मॉडल विफल होता है तो सहज प्रवृत्ति प्रॉम्प्ट को फिर से लिखने की होती है। कभी-कभी यह सही है। पर अक्सर यह उस विफलता-मामले के लिए अनुकूलित करने का एक तरीका है जो आपने देखा, उन मामलों पर पीछे हटने की कीमत पर जिन्हें आपने नहीं जाँचा।
AI के लिए रिलायबिलिटी इंजीनियरिंग ऐसी दिखती है:
- कुछ भी चलाने से पहले परिभाषित करना कि "सही" का क्या मतलब है
- एक प्रतिनिधि इनपुट वितरण के विरुद्ध मापना
- एक सुसंगत पद्धति से समय के साथ बदलावों को ट्रैक करना
- "यह मॉडल यह काम नहीं कर सकता" को "यह काम कम-निर्दिष्ट है" से अलग करना
प्रॉम्प्ट इंजीनियरिंग उस प्रक्रिया के भीतर एक औजार है। यह उसका विकल्प नहीं है।
ईमानदार ढाँचा
ज्यादातर AI क्षमताएँ असली हैं। मॉडल सचमुच उल्लेखनीय चीजें कर सकते हैं। कैपेबिलिटी-रिलायबिलिटी गैप यह तर्क नहीं है कि क्षमताएँ नकली हैं — यह तर्क है कि उनके मौजूद होने को जानना काफी नहीं है।
अगर आपको किसी काम को 95% समय काम करवाना है, तो आपको सबूत चाहिए कि यह 95% समय काम करता है। वह सबूत संरचित परीक्षण चलाने से आता है, डेमो में आत्मविश्वास से नहीं।
जो इंजीनियर टिकाऊ AI प्रोडक्ट बनाते हैं वे जरूरी नहीं कि वही हों जो सबसे अच्छे प्रॉम्प्ट लिखते हैं। वे वे हैं जो शिप करने से पहले जानते हैं कि "काम करना" का क्या मतलब है, और जिनके पास एक माप है जो उन्हें बताता है कि यह सच है या नहीं।