हाल ही में के एक एपिसोड में प्रेसिडेंट कर्टिस, राष्ट्रपति दो अलग-अलग मौकों पर दरवाजा खोलने के संघर्ष में हैं। ये दरवाजे काम नहीं करते क्योंकि रास्ते में बाधाएं हैं: शुरुआत में एक शरीर, फिर लगभग एक अरब डॉलर मूल्य का सुना। दोनों मामलों में, निराशा के जवाब में, किरदार गुस्से से बोलता है "बेवकूफ चीज बुरी है।" यह दरवाजों का एक तार्किक मॉडल नहीं है! दरवाजे अस्पष्ट रूप से "बुरे" नहीं होने चाहिए! मैंने इन पलों को अत्यधिक हंसमुखता से पाया¹ लेकिन शायद मेरा बेवकूफ दिमाग़ बस बुरा है।

Jev: अधिक दरवाजे बनाए जो बुरे हैं इंटरनेट Jev के बारे में चर्चा कर रहा है, जो Type Safe AI द्वारा विकसित एक AI मॉडल है, जो प्रायिकता अनुमानों के साथ टाइप की गई मान लौटाता है। मेरे विचार में Jev की महत्वपूर्ण बातें ये हैं: यह तेज और सस्ती है, आप इस पर जल्दी बना सकते हैं, यह तेज है, और यह सस्ती है। मैं यह समझने में अच्छा नहीं हूँ कि कौन सी तकनीक अपनायी जाएगी। मैं अभी भी समझता नहीं² Slack। इंतजार करें। क्या आपको अभी भी कठिन हिस्सा करना होगा? शायद मेरी समस्या यह है कि मैं उत्पादों की उम्मीद करता हूँ। कोई भी इसे खरीददारी नहीं कर रहा है। वे बस Jev को अस्पष्ट सवाल दे रहे हैं और अस्पष्ट जवाब ले रहे हैं।

दयालुता से, यह उन्हें यह चेक करने में मदद करता है कि "AI-ड्राइव" बक्स चिह्नित किया गया है और शुक्रवार से पहले शिप किया जाए, और जब यह डाउनस्ट्रीम लॉजिक तोड़ देता है, तो वे हमेशा कंधे उठाकर कह सकते हैं "अच्छा, AI गलतियाँ करती है।" त्रुटि बजट? विफलता मोड? टेस्ट सेट? इन सबको बाद में हैं। उपयोगकर्ता विफलता दर का पता लगा सकता है! आपने पहले ही शिप कर दिया है!

गलत आत्मविश्वास "ओह," मेरे पोस्ट का जवाब देने वाला लोह कपास कहता है, "आपने यह तथ्य नहीं सोचा है कि Jev आपको आत्मविश्वास स्कोर देता है!" आप इनका क्या करेंगे? आत्मविश्वास स्कोर साथ कोई भी तर्कसंगत काम करने के लिए आपको चाहिए कि आपको इन आत्मविश्वास स्कोर के कैलिब्रेशन की समझ हो और साथ ही अनिश्चितता के लागत का मॉडल हो।

कैलिब्रेशन पक्ष: Jev का शीर्षक विज्ञापन अधिकांशतः यह बताता है कि वे विभिन्न बेंचमार्क पर कितने अच्छे स्कोर करते हैं, लेकिन यह नहीं कि उनके आत्मविश्वास स्कोर कितने कैलिब्रेटेड हैं। एक कुकबुक है जो आत्मविश्वास स्कोर का उपयोग करके वर्गीकरण के पेड़ पर जाने के बारे में बताता है लेकिन यह मूलतः यह बताता नहीं है कि आत्मविश्वास स्कोर कितने अच्छे हैं। अधिकतम मामले में, लोग आत्मविश्वास स्कोर को एक कार्गो कल्च के तरीके से उपयोग करते हैं। न्यूनतम मामले में, लोग इनका API कॉल विफल होने के लिए बहाना बनाते हैं। मॉडल केवल 73% आत्मविश्वास में था! इसका मतलब है कि मेरा त्रुटि बजट 27% है!

जवाबदेही जब किसी वेबसाइट पर एक बटन टूट जाता है, तो मेरे पास यह मॉडल है कि क्या होना चाहिए। कहीं एक संझौता टूट गया है। मेरा DNS टूट गया है। किसी ने गंदगी शिप की जिसमें केवल किसी पथ पर जावा स्क्रिप्ट सिंटैक्स त्रुटियाँ हैं। एक हैंडलर ने एक अपवाद फेंका जो उम्मीद नहीं थी कि फेंका जाए। मैं हो सकता है कि केवल HTTP 500 डिबग नहीं कर सकता, लेकिन मैं उम्मीद करता हूँ कि कोई होगा जिसका काम होगा समझना कि एंडपॉइंट 500 क्यों है। मालिकी परिभाषित है बावजूद अपचय³।

कई उपयोगकर्ताओं के लिए, वास्तविक अनुभव लगभग बस "बेवकूफ चीज बुरी है" है। सॉफ्टवेयर पहले ही अमूल्य है; अधिक विफलताएं बस निराशा की दर बदलती हैं। लगता है कि विफलता को एक ठोस कारण से जोड़ने की संभावना हटाने में बहुत कुछ खोना नहीं है। कभी-कभी बस चीजें बुरी होती हैं। यह अस्पष्टता का सामान्यीकरण लाता है।

मेरा डर यह नहीं है कि जब चीजें LLM-चालित विकास द्वारा तेज की जाती हैं तो अधिक चीजें विफल होंगी। वे होंगी। वे हो चुकी हैं। यह नए तरीके से चीजें बनाने के मूल्य का हिस्सा है। मेरा डर यह है कि "कभी-कभी बस बुरा होता है" अधिक और अधिक जांच का स्वीकृत अंत बन जाएगा। यह दुखद है क्योंकि LLM-चालित विकास वास्तव में हमें इन समस्याओं को हल करने में मदद कर सकता है। बहुत से ऑटोमेटेड QA वर्कफ्लो हैं जो इंजीनियरिंग समय की कमी के कारण नहीं लिखे गए हैं। वही मूल्यांकन जो आपको Jev को बदलने (या इसके उपयोग को चुनौती) के लिए अधिकतम रास्ते तक पहुंचाएगा, कुछ प्रश्नों की दूरी पर हो सकता है।

आजकल सॉफ्टवेयर इंजीनियरिंग की त्रासदी यह है कि हम सामान्यतः ऐसे सिस्टम बना रहे हैं जिनमें न तो उपयोगकर्ता और न ही निर्माता लगते हैं कि क्या दरवाजे के पीछे एक शरीर है या नहीं। हम बस...