व्यक्तिगत रूप से जब मैंने SDD(Specs Driven Development) के साथ प्रोजेक्ट डेवलप किए, तो शुरुआत में मुझे स्पष्ट productivity improvement महसूस हुआ, लेकिन अभी भी मैं सारा code spec-आधारित नहीं लिख सकता, और जब भी direct modification की ज़रूरत पड़ती है, code और spec दोनों को साथ में update करना पड़ता है, इसलिए उल्टा productivity कम होने का अनुभव हुआ।
क्या आप समझ सकते हैं कि आपकी बात एक pattern है या एक principle? बात आखिर बात क्यों है, pattern pattern क्यों है, principle principle क्यों है, और perception perception क्यों है?
मूल्य, मूल्य क्यों है; संसाधन, संसाधन क्यों है; दृष्टिकोण, दृष्टिकोण क्यों है? सवाल, सवाल क्यों है और कुछ बनाना आखिर किस अर्थ में बनाना है? अमल क्या है, और किसे अमल कहा जाए? इंसान सवालों के सामने समर्पित होकर सोचना छोड़ चुका है, इसलिए वह AI से अलग नहीं रह गया। सिद्धांतों की समझ गायब हो गई है, और केवल पैटर्न को ही सच मानने की भूल की जा रही है।
कोड, कोड क्यों है और software, software क्यों है—इस बारे में समझ और विचार की गहराई नहीं है। सिर्फ नतीजे के लिए बनाई गई सतही अभिव्यक्ति आखिरकार बाबेल बना देती है
कोड लिखना execution में बस एक प्रवेश-द्वार भर है। किसी product को लॉन्च करना, बेचना और maintain करना उससे कहीं ज़्यादा महंगा और मुश्किल काम है। जैसे सिर्फ़ मोबाइल फ़ोन होने से कोई भी YouTuber तो बन सकता है, लेकिन उससे पैसे कमा पाने वाले लोग बहुत कम होते हैं।
दोहराव की गति — जल्दी बनाना, यूज़र फ़ीडबैक लेना, और सुधारने का cycle (learning loop)
रुचि·निर्णय क्षमता (taste) — किस चीज़ को बनाना सार्थक है और किसे नहीं, यह परखने की नज़र (ज़्यादातर चीज़ें नहीं बनानी चाहिए)
वितरण·नेटवर्क (distribution) — सबसे पहले किसे पता चलता है, कौन भरोसा करता है, और शुरुआती यूज़र्स को कितनी जल्दी जुटाया जा सकता है
समस्या का चयन — ऐसी समस्या ढूँढना जिसे असली लोग पैसे देकर हल करना चाहें (यह पहले भी सबसे कठिन था, और अब और ज़्यादा महत्वपूर्ण है)
अगर आपको ऐसा महसूस हुआ, तो उसके लिए क्षमा चाहता हूँ। मेरा मानना है कि हर व्यक्ति शीर्षक देखकर अलग तरह की सामग्री की अपेक्षा करता है। फिर भी, यह सही है कि मुझे ऐसा शीर्षक लिखना चाहिए जो अपेक्षित सामग्री को यथासंभव स्पष्ट और समान रूप से दर्शाए। मैं आगे इसका ध्यान रखूँगा.
साथ ही, कृपया इसे पिछले लेख से अलग करके देखें। पिछले लेख में मैंने दो निष्क्रिय खातों का उपयोग करके upvote करने की कोशिश की थी, जिसके कारण उसे flagged किया गया। यह पूरी तरह मेरी गलती थी, और मैं बताना चाहता हूँ कि यह लेख की सामग्री की समस्या नहीं थी।
नमस्ते! सबसे पहले, फीडबैक कमेंट छोड़ने के लिए आपका सच में बहुत धन्यवाद।
हमने तय किया कि इस मामले में GIN index की ज़रूरत नहीं है! मौजूदा search autocomplete recommendation API में सिर्फ term ही चाहिए। यह जानना ज़रूरी नहीं है कि वह term किन article में शामिल है।
वहीं दूसरी ओर, search API में हम GIN index से मिलते-जुलते index का उपयोग कर रहे हैं। Postgres के extension paradeDB का इस्तेमाल करके BM25 index का उपयोग करते हैं।
पोस्टिंग में यह विस्तार से नहीं आया है, लेकिन फिलहाल हम अलग से ExecutorService निर्दिष्ट करके उपयोग कर रहे हैं। हालांकि, जैसा आपने कहा, reactive तरीका या virtual threads पर भी आगे चलकर विचार करेंगे!!
मैंने ब्लॉग पर जाकर मूल लेख भी पढ़ा। शीर्षक और वास्तविक सामग्री के बीच थोड़ा अंतर महसूस होता है। आपने जो फीचर इम्प्लीमेंट किए हैं या सुधार की दिशा में जो काम किया है, वे पहले से मौजूद कई open source प्रोजेक्ट्स में पहले ही इम्प्लीमेंट और रिफ्लेक्ट हो चुके हिस्से हैं, और आपने जो काम किया है वह मूल रूप से अपनी सेवा में पहले बहुत साधारण रूप से इम्प्लीमेंट किए गए सर्च को अधिक उन्नत बनाने वाला हिस्सा है। लेकिन सिर्फ शीर्षक देखें तो ऐसा लगता है मानो एल्गोरिदम में बड़े पैमाने पर सुधार किया गया हो,, पिछली पोस्ट भी प्रचार के रूप में flagged हुई थी, इसलिए लगता है कि लिखते समय थोड़ा और सोच-विचार जरूरी नहीं होगा क्या।
यह एक दिलचस्प और काफ़ी रचनात्मक तरीका है।
व्यक्तिगत रूप से जब मैंने SDD(Specs Driven Development) के साथ प्रोजेक्ट डेवलप किए, तो शुरुआत में मुझे स्पष्ट productivity improvement महसूस हुआ, लेकिन अभी भी मैं सारा code spec-आधारित नहीं लिख सकता, और जब भी direct modification की ज़रूरत पड़ती है, code और spec दोनों को साथ में update करना पड़ता है, इसलिए उल्टा productivity कम होने का अनुभव हुआ।
मुद्दा AI बनाम इंसान का नहीं है,
बल्कि यह है कि क्या कोई "यूज़र के प्रति सहानुभूति, जानकारी जुटाना, और स्पष्ट तरीके से संप्रेषित" कर सकता है या नहीं।
आह, तो Mac पर यह नहीं चलेगा। कह रहा है
No GPU or XPU foundहाहा,,क्या आप समझ सकते हैं कि आपकी बात एक pattern है या एक principle? बात आखिर बात क्यों है, pattern pattern क्यों है, principle principle क्यों है, और perception perception क्यों है?
मूल्य, मूल्य क्यों है; संसाधन, संसाधन क्यों है; दृष्टिकोण, दृष्टिकोण क्यों है? सवाल, सवाल क्यों है और कुछ बनाना आखिर किस अर्थ में बनाना है? अमल क्या है, और किसे अमल कहा जाए? इंसान सवालों के सामने समर्पित होकर सोचना छोड़ चुका है, इसलिए वह AI से अलग नहीं रह गया। सिद्धांतों की समझ गायब हो गई है, और केवल पैटर्न को ही सच मानने की भूल की जा रही है।
रेत का महल बस और बेहतर तरीके से ढहता है lol
कोड, कोड क्यों है और software, software क्यों है—इस बारे में समझ और विचार की गहराई नहीं है। सिर्फ नतीजे के लिए बनाई गई सतही अभिव्यक्ति आखिरकार बाबेल बना देती है
वह AI की चापलूसी है
पैसा कमाने वाली लेक्चर बेचकर पैसा कमाना ही इसका बिज़नेस मॉडल है। इसे एक तरह का porn समझ सकते हैं lol
काफ़ी टिकाऊ है.. हाहा
कोड लिखना execution में बस एक प्रवेश-द्वार भर है। किसी product को लॉन्च करना, बेचना और maintain करना उससे कहीं ज़्यादा महंगा और मुश्किल काम है। जैसे सिर्फ़ मोबाइल फ़ोन होने से कोई भी YouTuber तो बन सकता है, लेकिन उससे पैसे कमा पाने वाले लोग बहुत कम होते हैं।
ऐसा लगता है जैसे कोई अनुभवहीन जूनियर एक ही बार में जरूरत से ज़्यादा जानकारी ठूंसने की कोशिश कर रहा हो..
दोहराव की गति — जल्दी बनाना, यूज़र फ़ीडबैक लेना, और सुधारने का cycle (learning loop)
रुचि·निर्णय क्षमता (taste) — किस चीज़ को बनाना सार्थक है और किसे नहीं, यह परखने की नज़र (ज़्यादातर चीज़ें नहीं बनानी चाहिए)
वितरण·नेटवर्क (distribution) — सबसे पहले किसे पता चलता है, कौन भरोसा करता है, और शुरुआती यूज़र्स को कितनी जल्दी जुटाया जा सकता है
समस्या का चयन — ऐसी समस्या ढूँढना जिसे असली लोग पैसे देकर हल करना चाहें (यह पहले भी सबसे कठिन था, और अब और ज़्यादा महत्वपूर्ण है)
अगर आपको ऐसा महसूस हुआ, तो उसके लिए क्षमा चाहता हूँ। मेरा मानना है कि हर व्यक्ति शीर्षक देखकर अलग तरह की सामग्री की अपेक्षा करता है। फिर भी, यह सही है कि मुझे ऐसा शीर्षक लिखना चाहिए जो अपेक्षित सामग्री को यथासंभव स्पष्ट और समान रूप से दर्शाए। मैं आगे इसका ध्यान रखूँगा.
साथ ही, कृपया इसे पिछले लेख से अलग करके देखें। पिछले लेख में मैंने दो निष्क्रिय खातों का उपयोग करके upvote करने की कोशिश की थी, जिसके कारण उसे flagged किया गया। यह पूरी तरह मेरी गलती थी, और मैं बताना चाहता हूँ कि यह लेख की सामग्री की समस्या नहीं थी।
नमस्ते! सबसे पहले, फीडबैक कमेंट छोड़ने के लिए आपका सच में बहुत धन्यवाद।
हमने तय किया कि इस मामले में GIN index की ज़रूरत नहीं है! मौजूदा search autocomplete recommendation API में सिर्फ term ही चाहिए। यह जानना ज़रूरी नहीं है कि वह term किन article में शामिल है।
वहीं दूसरी ओर, search API में हम GIN index से मिलते-जुलते index का उपयोग कर रहे हैं। Postgres के extension paradeDB का इस्तेमाल करके BM25 index का उपयोग करते हैं।
पोस्टिंग में यह विस्तार से नहीं आया है, लेकिन फिलहाल हम अलग से ExecutorService निर्दिष्ट करके उपयोग कर रहे हैं। हालांकि, जैसा आपने कहा, reactive तरीका या virtual threads पर भी आगे चलकर विचार करेंगे!!
ऐसी चीज़ें प्रोजेक्ट में कैसे खोजी जा सकती हैं? सिर्फ AI चलाने से इसका पता चलना मुश्किल लगता है..
ऐसे उदाहरणों को देखकर मुझे भी लगता है कि सीखकर इसे ज़रूर खुद अनुभव करना चाहिए।
ये कैसी तस्वीरें हैं.... वाह... बिल्कुल पारंपरिक लैंडस्केप पेंटिंग जैसी लग रही हैं।
मैंने ब्लॉग पर जाकर मूल लेख भी पढ़ा। शीर्षक और वास्तविक सामग्री के बीच थोड़ा अंतर महसूस होता है। आपने जो फीचर इम्प्लीमेंट किए हैं या सुधार की दिशा में जो काम किया है, वे पहले से मौजूद कई open source प्रोजेक्ट्स में पहले ही इम्प्लीमेंट और रिफ्लेक्ट हो चुके हिस्से हैं, और आपने जो काम किया है वह मूल रूप से अपनी सेवा में पहले बहुत साधारण रूप से इम्प्लीमेंट किए गए सर्च को अधिक उन्नत बनाने वाला हिस्सा है। लेकिन सिर्फ शीर्षक देखें तो ऐसा लगता है मानो एल्गोरिदम में बड़े पैमाने पर सुधार किया गया हो,, पिछली पोस्ट भी प्रचार के रूप में flagged हुई थी, इसलिए लगता है कि लिखते समय थोड़ा और सोच-विचार जरूरी नहीं होगा क्या।
बहुत बढ़िया है। लेकिन बनाते समय अगर target resource address भी साथ में दिया जाए तो अच्छा होगा। यूं ही बस इंस्टॉल नहीं कर सकते, हाहा