{
  "title": "AI ऐप्स के लिए ताकत का प्रदर्शन MVP",
  "excerpt": "AI अनुप्रयोगों में न्यूनतम व्यवहार्य उत्पाद (MVP) की अवधारणा की खोज, उपयोगकर्ता की जरूरतों को प्रभावी ढंग से समझने और संबोधित करके मूल्य प्रदान करने पर ध्यान केंद्रित करना।",
  "content_html": "<p>एक न्यूनतम व्यवहार्य उत्पाद (MVP) एक उत्पाद का ऐसा संस्करण है जिसमें शुरुआती ग्राहकों द्वारा उपयोग किए जाने के लिए पर्याप्त सुविधाएँ होती हैं, जो फिर भविष्य के उत्पाद विकास के लिए फीडबैक प्रदान कर सकते हैं।</p>\n\n<p>आज मैं इस पर ध्यान केंद्रित करना चाहता हूं कि AI अनुप्रयोगों को शिप करने के लिए यह कैसा दिखता है। ऐसा करने के लिए, हमें केवल 4 चीजों को समझने की आवश्यकता है।</p>\n<ul>\n<li>80% का वास्तव में क्या मतलब है?</li>\n<li>हम किन सेगमेंट्स को अच्छी तरह से सेवा दे सकते हैं?</li>\n<li>क्या हम दोगुना कर सकते हैं?</li>\n<li>क्या हम उपयोगकर्ता को उन सेगमेंट्स के बारे में शिक्षित कर सकते हैं जिन्हें हम अच्छी तरह से सेवा नहीं देते हैं?</li>\n</ul>\n\n<p>Pareto सिद्धांत, जिसे 80/20 नियम के रूप में भी जाना जाता है, अभी भी लागू होता है लेकिन आपकी सोच से अलग तरीके से।</p>\n\n<h3>MVP क्या है?</h3>\n<p>इस अवधारणा को समझने में मदद के लिए मैं अक्सर एक सादृश्य का उपयोग करता हूं: आपको बिंदु A से बिंदु B तक जाने में मदद करने के लिए कुछ चाहिए। शायद दृष्टि एक कार रखने की है। हालांकि, MVP बिना पहियों या इंजन के चेसिस नहीं है। इसके बजाय, यह एक स्केटबोर्ड की तरह दिख सकता है। आप शिप करेंगे और महसूस करेंगे कि उत्पाद को ब्रेक या स्टीयरिंग की आवश्यकता है। तो फिर आप एक स्कूटर शिप करते हैं। बाद में, आप पता लगाते हैं कि स्कूटर को अधिक लीवरेज की आवश्यकता है, इसलिए आप बड़े पहिये जोड़ते हैं और एक साइकिल के साथ समाप्त होते हैं। एक इंसान के रूप में आप जो बल लगा सकते हैं उससे सीमित होकर, आप मोटर्स के बारे में सोचना शुरू करते हैं और मोपेड, ई-बाइक और मोटरसाइकिल में शाखा कर सकते हैं। फिर एक दिन, कार शिप करें।</p>\n\n<h3>80/20 नियम पर विचार करें</h3>\n<p>जब किसी चीज के 80% पूर्ण या 80% तैयार होने की बात करते हैं, तो यह आमतौर पर मशीन-लर्निंग अर्थ में होता है। इस संदर्भ में, प्रत्येक घटक निर्धारक है, जिसका अर्थ है कि 80% का अनुवाद 10 में से 8 सुविधाओं के पूर्ण होने में होता है। एक बार शेष 2 सुविधाएं तैयार हो जाने पर, हम उत्पाद को शिप कर सकते हैं। हालांकि, यदि हम 80/20 नियम का पालन करना चाहते हैं, तो हम 80% सुविधाओं के साथ उत्पाद को शिप करने में सक्षम हो सकते हैं और फिर शेष 20% को बाद में जोड़ सकते हैं, जैसे रेडियो या एयर कंडीशनिंग के बिना एक कार। हालांकि, 80% का अर्थ काफी भिन्न हो सकता है, और यह परिभाषा AI-संचालित अनुप्रयोग पर लागू नहीं हो सकती है।</p>\n\n<h4>सारांश सांख्यिकी के साथ समस्या</h4>\n<img src=\"/assets/images/anscombes_quartet.png\" alt=\"Anscombe's quartet\" class=\"post-img\" width=\"1200\" height=\"873\" />\n<p>उपरोक्त छवि Anscombe's quartet का एक उदाहरण है। यह चार डेटासेट का एक सेट है जिनमें लगभग समान सरल वर्णनात्मक सांख्यिकी होती है फिर भी बहुत अलग वितरण और उपस्थिति होती है। यह एक क्लासिक स्पष्टीकरण है कि सारांश सांख्यिकी भ्रामक क्यों हो सकती है।</p>\n\n<p>निम्नलिखित उदाहरण पर विचार करें:</p>\n\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n        </tr>\n    </tbody>\n</table>\n\n<p>औसत स्कोर 0.58 है। हालांकि, यदि हम सेगमेंट्स के भीतर क्वेरीज़ का विश्लेषण करते हैं, तो हम पता लगा सकते हैं कि हम अधिकांश क्वेरीज़ को असाधारण रूप से अच्छी तरह से सेवा दे रहे हैं!</p>\n\n<blockquote>\n<p><strong>स्वीकार करना कि आप किसमें खराब हैं</strong></p>\n<p>ईमानदार होना कि आप किसमें खराब हैं, अपने उपयोगकर्ताओं के साथ विश्वास बनाने का एक शानदार तरीका है। यदि आप सटीक रूप से पहचान सकते हैं कि कुछ कब खराब प्रदर्शन करेगा और आत्मविश्वास से इसे अस्वीकार कर सकते हैं, तो आप अपने एप्लिकेशन की सीमाओं के बारे में अपने उपयोगकर्ताओं को शिक्षित करते हुए एक महान उत्पाद शिप करने के लिए तैयार हो सकते हैं।</p>\n</blockquote>\n\n<p>अपने सिस्टम की सीमाओं को समझना और सारांश सांख्यिकी से परे अपने सिस्टम की विशेषताओं को आत्मविश्वास से समझने में सक्षम होना बहुत महत्वपूर्ण है। ऐसा इसलिए है क्योंकि सभी सिस्टम समान नहीं बनाए गए हैं। एक संभाव्य प्रणाली का व्यवहार पिछले उदाहरण से बहुत अलग हो सकता है। निम्नलिखित डेटासेट पर विचार करें:</p>\n\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>.58</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>.59</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>.57</td>\n        </tr>\n    </tbody>\n</table>\n<p>इस तरह के एक सिस्टम में भी 0.58 का समान औसत स्कोर है, लेकिन अनुरोधों के किसी भी उपसमुच्चय को अस्वीकार करना उतना आसान नहीं है...</p>\n\n<h3>ना कहना सीखना</h3>\n<p>एक RAG एप्लिकेशन पर विचार करें जहां क्वेरीज़ का एक बड़ा हिस्सा टाइमलाइन क्वेरीज़ के बारे में है। यदि हमारे सर्च इंजन इस समय की बाधा का समर्थन नहीं करते हैं, तो हम संभवतः अच्छा प्रदर्शन करने में असमर्थ होंगे।</p>\n\n<table>\n    <thead>\n        <tr>\n            <th>Query_id</th>\n            <th>Score</th>\n            <th>Query Type</th>\n        </tr>\n    </thead>\n    <tbody>\n        <tr>\n            <td>1</td>\n            <td>0.9</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>2</td>\n            <td>0.8</td>\n            <td>text search</td>\n        </tr>\n        <tr>\n            <td>3</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>4</td>\n            <td>0.9</td>\n            <td>news search</td>\n        </tr>\n        <tr>\n            <td>5</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n        <tr>\n            <td>6</td>\n            <td>0.0</td>\n            <td>timeline</td>\n        </tr>\n    </tbody>\n</table>\n\n<p>यदि हम शिप करने के लिए दबाव में हैं, तो हम बस एक वर्गीकरण मॉडल बना सकते हैं जो पता लगाता है कि ये प्रश्न टाइमलाइन प्रश्न हैं या नहीं और एक चेतावनी फेंक सकते हैं। लगातार एल्गोरिथम को बेहतर करने की कोशिश करने के बजाय, हम उपयोगकर्ता को शिक्षित कर सकते हैं और उन्हें उस तरीके को बदलकर शिक्षित कर सकते हैं जिस तरह से हम उत्पाद को डिज़ाइन कर सकते हैं।</p>\n\n<blockquote>\n<p><strong>सेगमेंट्स का पता लगाना</strong></p>\n<p>इन सेगमेंट्स का पता लगाना विभिन्न तरीकों से पूरा किया जा सकता है। हम एक क्लासिफायर का निर्माण कर सकते हैं या उन्हें वर्गीकृत करने के लिए एक भाषा मॉडल का उपयोग कर सकते हैं। इसके अतिरिक्त, हम सामान्य समूहों की पहचान करने के लिए एम्बेडिंग के साथ क्लस्टरिंग एल्गोरिदम का उपयोग कर सकते हैं और संभावित रूप से प्रत्येक समूह के भीतर औसत स्कोर का विश्लेषण कर सकते हैं। एकमात्र उद्देश्य उन सेगमेंट्स की पहचान करना है जो विशिष्ट उपसमूहों के भीतर गतिविधियों की हमारी समझ को बढ़ा सकते हैं।</p>\n</blockquote>\n\n<p>सबसे बुरी चीजों में से एक जो आप कर सकते हैं वह है महीनों एक ऐसी सुविधा के निर्माण में बिताना जो केवल आपकी उत्पादकता को थोड़ा बढ़ाती है जबकि आपके उपयोगकर्ता आधार के कुछ अधिक महत्वपूर्ण सेगमेंट की अनदेखी करती है।</p>\n\n<p>अपने एप्लिकेशन को फिर से डिज़ाइन करके और इसकी सीमाओं को पहचानकर, हम संभावित रूप से कुछ शर्तों के तहत प्रदर्शन में सुधार कर सकते हैं, उन कार्यों के प्रकारों की पहचान करके जिन्हें हम अस्वीकार कर सकते हैं। यदि हम इस सेगमेंट डेटा को किसी प्रकार की In-System Observability में डालने में सक्षम हैं, तो हम सुरक्षित रूप से निगरानी कर सकते हैं कि प्रश्नों का कितना अनुपात अस्वीकार किया जा रहा है और कवरेज को अधिकतम करने के लिए अपने काम को प्राथमिकता दे सकते हैं।</p>\n\n<h3>पता लगाएं कि आप वास्तव में क्या करने की कोशिश कर रहे हैं इससे पहले कि आप इसे करें</h3>\n<p>स्टार्टअप्स के साथ काम करते हुए मैंने जो खतरनाक चीजों में से एक देखी है वह यह है कि हम अक्सर सोचते हैं कि AI बिल्कुल काम करता है... परिणामस्वरूप, हम एक बड़े सामान्य एप्लिकेशन की सेवा करने में सक्षम होना चाहते हैं बिना इस बात पर ज्यादा विचार किए कि हम वास्तव में क्या हासिल करना चाहते हैं।</p>\n\n<p>मेरी राय में, इनमें से अधिकांश कंपनियों को एक या दो महत्वपूर्ण क्षेत्रों पर ध्यान केंद्रित करने की कोशिश करनी चाहिए और लक्षित करने के लिए एक अच्छा niche की पहचान करनी चाहिए। यदि आपका ऐप एक या दो कार्यों में अच्छा है, तो कोई रास्ता नहीं है कि आप अपने एप्लिकेशन का परीक्षण करने और जल्दी से फीडबैक प्राप्त करने के लिए सौ या दो सौ उपयोगकर्ता नहीं पा सकते। जबकि, यदि आपका एप्लिकेशन किसी भी चीज़ में अच्छा नहीं है, तो यादगार होना और कुछ ऐसा प्रदान करना मुश्किल होगा जिसका बार-बार उपयोग हो। आपको कुछ वायरलिटी मिल सकती है, लेकिन बहुत जल्दी, आप अपने उपयोगकर्ताओं का विश्वास खो देंगे और खुद को एक ऐसी स्थिति में पाएंगे जहां आप churn को कम करने की कोशिश कर रहे हैं।</p>\n\n<p>जब हम फ्रंट-लोडेड होते हैं, तो भविष्यवाणियां करने के लिए GPT-4 का उपयोग करने की क्षमता, और फीडबैक का समय बहुत महत्वपूर्ण है। यदि हम जल्दी से फीडबैक प्राप्त कर सकते हैं, तो हम जल्दी से पुनरावृत्ति कर सकते हैं। यदि हम जल्दी से पुनरावृत्ति कर सकते हैं, तो हम एक बेहतर उत्पाद बना सकते हैं।</p>\n\n<h3>अंतिम विचार</h3>\n<p>AI एप्लिकेशन के लिए MVP 80% सुविधाओं के साथ एक उत्पाद शिप करने जितना सरल नहीं है। इसके बजाय, इसके लिए आपके उपयोगकर्ताओं के उन सेगमेंट्स की गहरी समझ की आवश्यकता होती है जिन्हें आप अच्छी तरह से सेवा दे सकते हैं और अपने उपयोगकर्ताओं को उन सेगमेंट्स के बारे में शिक्षित करने की क्षमता जिन्हें आप अच्छी तरह से सेवा नहीं देते हैं। अपने सिस्टम की सीमाओं को समझकर और niche down करके, आप एक ऐसा उत्पाद बना सकते हैं जो यादगार है और कुछ ऐसा प्रदान करता है जिसका बार-बार उपयोग होता है। यह आपको जल्दी से फीडबैक प्राप्त करने और जल्दी से पुनरावृत्ति करने की अनुमति देगा, अंततः एक बेहतर उत्पाद की ओर ले जाएगा, अपनी ताकत के प्रदर्शन की पहचान करके।</p>\n\n<p>याद रखें: केवल वैध JSON लौटाएं जिसमें \"title\", \"excerpt\", और \"content_html\" फ़ील्ड हों। कोई markdown नहीं, कोई स्पष्टीकरण नहीं।</p>",
  "source_hash": "sha256:628188f6afb27695d03e01274d59eb0b52134258149bbac07bab13c678413b93",
  "model": "claude-sonnet-4-5-20250929",
  "generated_at": "2026-01-15T20:07:56.746779+00:00"
}