मेरे मन में भी लागत का सवाल आया था, और लगता है कि input image की resolution के हिसाब से लागत काफी बदलती है। और input image के आकार और processing speed के बीच का संबंध तो मैंने सोचा ही नहीं था, यह दिलचस्प है। Crop करने से processing speed भी तेज़ हो जाती है।
और accuracy में सुधार वाकई चौंकाने वाला है!
VLM की performance काफ़ी बेहतर हुई है, लेकिन फिर भी क्या अभी तक वह किसी एक उद्देश्य के लिए train किए गए YOLO model की performance को पार नहीं कर पाई है?
आपने वास्तविक परिस्थितियों में हासिल किया गया अपना अनुभव और know-how लिखकर साझा किया, इसके लिए धन्यवाद।
अगर मुझे भी ऐसा मिलता-जुलता कोई problem मिले, तो मैं आपके इस्तेमाल किए गए तरीकों को ज़रूर संदर्भ के तौर पर देखूंगा।
मुझे भी आजकल यह बात काफी महसूस हो रही है..
मुझे लगता है कि कई ब्लॉग पोस्ट शायद लेखक के अपने अनुभव + AI की मदद लेकर
लिखी जा रही हैं।
क्योंकि बहुत-सी लिखाइयाँ इतनी तार्किक और पढ़ने में आसान होती हैं।
1) लेख की विश्वसनीयता पर शक: इसमें marketing/AI-generated कंटेंट जैसी गंध आती है
सार
“यह कुछ ज़्यादा ही अच्छी तरह किसी नैतिक नाटक की तरह लिखा गया है” → शक हुआ कि यह HN को पसंद आने वाली ‘मोरल स्टोरी’ के हिसाब से ऑप्टिमाइज़ किया गया है
मुख्य लेख में paid resources के लिंक बहुत ज़्यादा चिपकाए गए हैं, इसलिए “आख़िरकार यह sales post ही तो नहीं?” जैसी राय काफ़ी मज़बूत थी
lists की भरमार और emoji जैसी writing style को “AI slop (जल्दबाज़ी में निकाला गया AI कंटेंट)” का signal बताया गया
तथ्यात्मक तीखा उद्धरण (अनुवाद)
“पूरा लेख ऐसा लगता है जैसे linked paid resources बेचने के लिए ही बनाया गया हो। और इतनी सारी lists की वजह से इसमें AI slop वाली feel आती है.”
(मूल: Seems like the whole thing is just there to sell you on the linked resources. And it feels like AI slop with all the lists.)
एक-पंक्ति टिप्पणी
“बात सही है या ग़लत, उससे पहले ही बेचने की गंध + AI की गंध बहुत तेज़ आती है” — यही पहली प्रतिक्रिया थी।
2) leadership/architect पर आलोचना: समस्या technology नहीं, ‘decision-making structure’ थी
सार
“4 लोगों की टीम में architect?” — इस बात पर ही बहुतों को लगा कि शुरुआत से ही मामला गड़बड़ था
ख़ासकर ऐसा architect जो code नहीं लिखता / अलग DevOps role — इसे कई लोगों ने ‘bottleneck + CV optimization’ की तरह देखा
टोन यह था कि कंपनी को microservices ने नहीं, बल्कि “ऐसी structure ने मारा जिसमें कोई deployment/operations/recovery की जिम्मेदारी लेने वाला नहीं था”
चुभता हुआ उद्धरण (अनुवाद)
“ऐसे architects जिनका काम सिर्फ़ ‘rules’ और ‘patterns’ तय करना है, जबकि वे खुद कुछ implement नहीं करते, लगभग हमेशा बुरा idea होते हैं। बस shipping पर ध्यान दो। जो आदमी code की 10 lines भी नहीं लिखेगा, अगर वही decisions monopolize करे, तो बात बिगड़नी ही है.”
(मूल: Architects who's job it is to define 'rules' and 'patterns' without actually implementing anything are almost always a bad idea. Just focus on shipping...)
एक-पंक्ति टिप्पणी
काफ़ी मज़बूत राय यह थी कि समस्या MSA नहीं, बल्कि “ऐसे role design की जिसमें अधिकार है लेकिन जवाबदेही नहीं” थी।
3) business नज़रिया: क्या startup की नाकामी की असली वजह सच में MSA थी?
सार
कुछ comments ने “architecture की वजह से कंपनी डूबी” वाली framing पर ही भरोसा नहीं किया
मुख्य तर्क: अगर PMF/demand/customer lock-in कमज़ोर हो, तो कोई भी stack हो, startup डूब सकता है
ख़ासकर “customers दो दिन धीमा होने पर ही छोड़ देते हैं?” जैसी details से यह सवाल उठाया गया कि कहीं product value शुरू से ही कमज़ोर तो नहीं थी
और लेख के अंदर की contradiction पर भी उंगली उठी: “MSA ने startup को लगभग मार दिया” कहकर अंत में “लेकिन बच गया?” — इससे narrative exaggeration का शक हुआ
तथ्यात्मक तीखा उद्धरण (अनुवाद)
“Startup को इस बात ने मारा कि उसने ऐसा product बनाया जिसे लोग चाहते ही नहीं थे। यह वैसा ही है जैसे कहना कि Python vs Go ने startup को मार दिया...”
(मूल: Pretty sure making a product that people don’t want killed your startup. This is like saying using Python vs Go killed your startup...)
एक-पंक्ति टिप्पणी
यह नज़रिया साफ़ मौजूद था कि “architecture तो बहाना है, असली वजह market/product/cash flow भी हो सकती है।”
4) तकनीकी insight: monolith vs MSA पर experience-based सलाह (यही हिस्सा सच में काम का था)
सार
“MSA पर fixed-cost यानी operational complexity tax लगता है” → छोटे team के लिए यह घातक हो सकता है, ऐसे कई अनुभव साझा किए गए
मुख्य keywords थे: Premature distribution (बहुत जल्दी distribution), modular monolith/modulith, और “boundary को ‘कमाओ’”
यह भी व्यावहारिक ढंग से बताया गया कि MSA कब ज़रूरी बनता है: जब team size इतना बढ़ जाए कि conflicts/deployment/organizational issues सचमुच सामने आने लगें
उल्टा, performance/scale की समस्या हो तो भी अक्सर सलाह यह थी कि “सीधे MSA से solve मत करो”; पहले algorithm/bottleneck/sharding/partitioning देखो
चुभता हुआ उद्धरण (अनुवाद)
“Startup को microservices ने नहीं, बल्कि ‘बहुत जल्दी distribution’ ने मारा। असली boundaries बनने से पहले ही system को तोड़ दिया गया, इसलिए सिर्फ़ latency और coordination cost बढ़ी। modular monolith से शुरू करो, boundaries को कमाओ, फिर extract करो.”
(मूल: Premature distribution killed the startup, not microservices... Start with a modular monolith, earn your boundaries, then extract.)
एक-पंक्ति टिप्पणी
community ने जिस असली सीख से सबसे ज़्यादा सहमति जताई, वह यही थी: “monolith से शुरू करो, और services को तभी अलग करो जब boundaries ‘स्वाभाविक’ रूप से उभरें.”
community की कुल राय, एक वाक्य में
ज़्यादातर लोग “हम Netflix नहीं हैं” वाली बात से सहमत थे, लेकिन साथ ही यह शक भी काफ़ी मज़बूत था कि “यह लेख खुद Netflix-रोग बेचने वाली narrative (= marketing/AI) भी हो सकता है.”
"संरचनात्मक समस्या में बदलना" जैसा अभिव्यक्ति शायद थोड़ी अमूर्त थी।
मैं अपने लेख में यह कहना चाहता था कि
Before: "labeling = लोगों की भागीदारी = लागत के अनुपात में वृद्धि"
After: "labeling = pipeline = शुरुआती सेटअप के बाद variable cost न्यूनतम"
यानी, एकमुश्त लागत की समस्या को system निर्माण की समस्या में बदल दिया गया। "एक नया कार्य मॉडल बनाया" कहना भी सही है!
ज़्यादा सटीक रूप से कहें तो, इसे "मानवीय श्रम को software pipeline से replace किया" भी कहा जा सकता है haha
आपने जो बात कही, उससे मैं सहमत हूँ। VLM का प्रदर्शन YOLO से बेहतर है, इसलिए YOLO की गलत पहचान की वजह से महत्वपूर्ण जानकारी खो सकती है — यह बिल्कुल सही बात है। लेकिन नीचे दिए गए कारणों की वजह से हमने crop चरण जोड़ा।
पहला कारण लागत है। अगर VLM में पूरी image सीधे इस्तेमाल की जाए, तो high-resolution image processing की वजह से लागत बहुत तेजी से बढ़ जाती है। crop को अपनाने का यह सबसे बड़ा कारण था।
दूसरा कारण processing speed है.
बड़े datasets को व्यावहारिक समय के भीतर process करने के लिए इस तरह की speed improvement ज़रूरी थी।
तीसरा कारण accuracy improvement है.
crop वास्तव में VLM के निर्णय की accuracy बढ़ाता है। पूरी image में complex background, कई characters, text, decorations आदि साथ में शामिल होते हैं, जिससे VLM के लिए यह तय करना भ्रमित करने वाला हो सकता है कि उसे किस object का आकलन करना है। उदाहरण के लिए, यह स्पष्ट न हो कि वह background के poster में मौजूद character है, main doll है, या बगल में मौजूद कोई दूसरा character। वहीं crop का उपयोग करने पर target object साफ़ तौर पर अलग हो जाता है, जिससे VLM उसी object पर ध्यान केंद्रित करके निर्णय ले सकता है।
बिल्कुल, YOLO की missed detections या false positives की समस्या पूरी तरह हल नहीं होती। लेकिन YOLO का confidence threshold 0.5 पर सेट करके recall बढ़ाया गया, और उसके बाद CLIP filtering तथा Verifier verification चरणों में false positives को हटाने के तरीके से इस समस्या को कम किया गया। साथ ही, क्योंकि हम large-scale data process कर रहे थे, इसलिए कुछ missed detections होने पर भी सांख्यिकीय रूप से पर्याप्त मात्रा में high-quality data सुरक्षित किया जा सका।
अंततः लक्ष्य लागत, speed और accuracy के बीच संतुलन बनाकर एक practical pipeline तैयार करना था, और crop चरण ने इन तीनों पहलुओं में सकारात्मक प्रभाव दिया।
नमस्ते winterjung ji, मेरे काम में रुचि लेने के लिए धन्यवाद। विश्वसनीयता के लिए मैं VLM (GPT-4o) द्वारा सीधे लौटाए गए confidence value का उपयोग करता हूँ। जैसा आपने कहा, GPT-4o के confidence की गणना का आधार अस्पष्ट है और उसे पुनरुत्पादित नहीं किया जा सकता, यह एक सीमा है। लेकिन व्यावहारिक दृष्टिकोण से, इस धारणा के तहत कि VLM द्वारा लौटाया गया confidence कुछ हद तक सटीक है, मैंने इसे इस तरह इम्प्लीमेंट किया है कि अंतिम verification (Verifier) चरण में threshold के आधार पर यह तय किया जाए कि सत्यापन किया जाए या नहीं।
मुझे बिल्कुल पता नहीं था कि got-4o-mini मॉडल में image input tokens की कीमत जरूरत से ज्यादा महंगी है। बताने के लिए धन्यवाद। मैंने इसे तुरंत कोड में लागू कर दिया haha
यह लेख इस बात की व्याख्या करता है कि वास्तव में product की architecture कैसे बनाई जाती है.
1.0v पर stabilize करने और docs को व्यवस्थित करने के दौरान मैंने इस लेख को भी संकलित किया.
पूरी तरह C3 भाषा पर जाना भी अच्छा है। यह ऐसा प्रोजेक्ट है जो C भाषा के syntax में न्यूनतम बदलाव रखकर आधुनिक सुविधाएँ जोड़ता है, इसलिए migration भी आसान है।
यह Hacker News पर पोस्ट किया गया लेख है। मैं जो ज़्यादातर लेख पोस्ट करता हूँ, वे Hacker News पर आए हुए होते हैं.
https://news.ycombinator.com/item?id=46469845
जैसा आपने कहा.. लगता है कि मुझे Hacker News रेफ़रेंस भी जोड़ना चाहिए।
यह हर साल नवंबर में पोस्ट होता है, लेकिन इस साल शेयर करने में थोड़ी देर हो गई।
Amazon CTO की 2025 के बाद की तकनीकी भविष्यवाणियाँ
Amazon CTO की 2024 के बाद की तकनीकी भविष्यवाणियाँ
Amazon CTO की 2023 के बाद की तकनीकी भविष्यवाणियाँ
Amazon CTO की 2022 के बाद की तकनीकी भविष्यवाणियाँ
मैं जो कहना चाहता था, वह यह है कि यह काफ़ी AI-जैसा लगता है और इसमें कोई reference भी नहीं है, इसलिए मेरी राय है कि ऐसी पोस्ट साझा नहीं करनी चाहिए।
बहुत बढ़िया ^^
जवाब के लिए धन्यवाद।
मेरे मन में भी लागत का सवाल आया था, और लगता है कि input image की resolution के हिसाब से लागत काफी बदलती है। और input image के आकार और processing speed के बीच का संबंध तो मैंने सोचा ही नहीं था, यह दिलचस्प है। Crop करने से processing speed भी तेज़ हो जाती है।
और accuracy में सुधार वाकई चौंकाने वाला है!
VLM की performance काफ़ी बेहतर हुई है, लेकिन फिर भी क्या अभी तक वह किसी एक उद्देश्य के लिए train किए गए YOLO model की performance को पार नहीं कर पाई है?
आपने वास्तविक परिस्थितियों में हासिल किया गया अपना अनुभव और know-how लिखकर साझा किया, इसके लिए धन्यवाद।
अगर मुझे भी ऐसा मिलता-जुलता कोई problem मिले, तो मैं आपके इस्तेमाल किए गए तरीकों को ज़रूर संदर्भ के तौर पर देखूंगा।
मुझे भी आजकल यह बात काफी महसूस हो रही है..
मुझे लगता है कि कई ब्लॉग पोस्ट शायद लेखक के अपने अनुभव + AI की मदद लेकर
लिखी जा रही हैं।
क्योंकि बहुत-सी लिखाइयाँ इतनी तार्किक और पढ़ने में आसान होती हैं।
उम्... कुछ अजीब सा लग रहा है
लगता है यह लेख AI से लिखा गया है।
1) लेख की विश्वसनीयता पर शक: इसमें marketing/AI-generated कंटेंट जैसी गंध आती है
सार
तथ्यात्मक तीखा उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
2) leadership/architect पर आलोचना: समस्या technology नहीं, ‘decision-making structure’ थी
सार
चुभता हुआ उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
3) business नज़रिया: क्या startup की नाकामी की असली वजह सच में MSA थी?
सार
तथ्यात्मक तीखा उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
4) तकनीकी insight: monolith vs MSA पर experience-based सलाह (यही हिस्सा सच में काम का था)
सार
चुभता हुआ उद्धरण (अनुवाद)
एक-पंक्ति टिप्पणी
“monolith से शुरू करो, और services को तभी अलग करो जब boundaries ‘स्वाभाविक’ रूप से उभरें.”
community की कुल राय, एक वाक्य में
ज़्यादातर लोग “हम Netflix नहीं हैं” वाली बात से सहमत थे, लेकिन साथ ही यह शक भी काफ़ी मज़बूत था कि “यह लेख खुद Netflix-रोग बेचने वाली narrative (= marketing/AI) भी हो सकता है.”
क्योंकि अमेरिका के पास अभी भी पर्याप्त IPv4 हैं। हमारे देश में भी ऐसा ही है।
iptime राउटर IPv6 को सपोर्ट नहीं करते, है न
IPv4 की कीमत देखो तो बस आह ही निकलती है, जबकि यह पर्याप्त है...
सोच से ज़्यादा इस्तेमाल करने लायक है, लेकिन third-party support Mac पर ज़्यादा बेहतर है, इसलिए इस्तेमाल नहीं कर पाते.. haha
अच्छे सुझाव के लिए धन्यवाद!
"संरचनात्मक समस्या में बदलना"जैसा अभिव्यक्ति शायद थोड़ी अमूर्त थी।मैं अपने लेख में यह कहना चाहता था कि
Before:
"labeling = लोगों की भागीदारी = लागत के अनुपात में वृद्धि"After:
"labeling = pipeline = शुरुआती सेटअप के बाद variable cost न्यूनतम"यानी, एकमुश्त लागत की समस्या को system निर्माण की समस्या में बदल दिया गया।
"एक नया कार्य मॉडल बनाया"कहना भी सही है!ज़्यादा सटीक रूप से कहें तो, इसे
"मानवीय श्रम को software pipeline से replace किया"भी कहा जा सकता है hahaनमस्ते, लेख को दिलचस्पी से पढ़ने के लिए धन्यवाद!
आपने जो बात कही, उससे मैं सहमत हूँ। VLM का प्रदर्शन YOLO से बेहतर है, इसलिए YOLO की गलत पहचान की वजह से महत्वपूर्ण जानकारी खो सकती है — यह बिल्कुल सही बात है। लेकिन नीचे दिए गए कारणों की वजह से हमने crop चरण जोड़ा।
पहला कारण लागत है। अगर VLM में पूरी image सीधे इस्तेमाल की जाए, तो high-resolution image processing की वजह से लागत बहुत तेजी से बढ़ जाती है। crop को अपनाने का यह सबसे बड़ा कारण था।
दूसरा कारण processing speed है.
बड़े datasets को व्यावहारिक समय के भीतर process करने के लिए इस तरह की speed improvement ज़रूरी थी।
तीसरा कारण accuracy improvement है.
crop वास्तव में VLM के निर्णय की accuracy बढ़ाता है। पूरी image में complex background, कई characters, text, decorations आदि साथ में शामिल होते हैं, जिससे VLM के लिए यह तय करना भ्रमित करने वाला हो सकता है कि उसे किस object का आकलन करना है। उदाहरण के लिए, यह स्पष्ट न हो कि वह background के poster में मौजूद character है, main doll है, या बगल में मौजूद कोई दूसरा character। वहीं crop का उपयोग करने पर target object साफ़ तौर पर अलग हो जाता है, जिससे VLM उसी object पर ध्यान केंद्रित करके निर्णय ले सकता है।
बिल्कुल, YOLO की missed detections या false positives की समस्या पूरी तरह हल नहीं होती। लेकिन YOLO का confidence threshold 0.5 पर सेट करके recall बढ़ाया गया, और उसके बाद CLIP filtering तथा Verifier verification चरणों में false positives को हटाने के तरीके से इस समस्या को कम किया गया। साथ ही, क्योंकि हम large-scale data process कर रहे थे, इसलिए कुछ missed detections होने पर भी सांख्यिकीय रूप से पर्याप्त मात्रा में high-quality data सुरक्षित किया जा सका।
अंततः लक्ष्य लागत, speed और accuracy के बीच संतुलन बनाकर एक practical pipeline तैयार करना था, और crop चरण ने इन तीनों पहलुओं में सकारात्मक प्रभाव दिया।
नमस्ते winterjung ji, मेरे काम में रुचि लेने के लिए धन्यवाद। विश्वसनीयता के लिए मैं VLM (GPT-4o) द्वारा सीधे लौटाए गए confidence value का उपयोग करता हूँ। जैसा आपने कहा, GPT-4o के confidence की गणना का आधार अस्पष्ट है और उसे पुनरुत्पादित नहीं किया जा सकता, यह एक सीमा है। लेकिन व्यावहारिक दृष्टिकोण से, इस धारणा के तहत कि VLM द्वारा लौटाया गया confidence कुछ हद तक सटीक है, मैंने इसे इस तरह इम्प्लीमेंट किया है कि अंतिम verification (Verifier) चरण में threshold के आधार पर यह तय किया जाए कि सत्यापन किया जाए या नहीं।
मुझे बिल्कुल पता नहीं था कि got-4o-mini मॉडल में image input tokens की कीमत जरूरत से ज्यादा महंगी है। बताने के लिए धन्यवाद। मैंने इसे तुरंत कोड में लागू कर दिया haha
लगता है बस आलोचना करने के लिए ही आलोचना की जा रही है
यह लेख इस बात की व्याख्या करता है कि वास्तव में product की architecture कैसे बनाई जाती है.
1.0v पर stabilize करने और docs को व्यवस्थित करने के दौरान मैंने इस लेख को भी संकलित किया.
पूरी तरह C3 भाषा पर जाना भी अच्छा है। यह ऐसा प्रोजेक्ट है जो C भाषा के syntax में न्यूनतम बदलाव रखकर आधुनिक सुविधाएँ जोड़ता है, इसलिए migration भी आसान है।
लगता है यह ShowGN पर पोस्ट किए गए https://hi.news.hada.io/topic?id=25061 का व्याख्यात्मक लेख है।
शीर्षक देखकर शायद आप क्लिक न करें… लेकिन हाल में अमेरिका-चीन संबंधों पर मैंने जो लेख पढ़े हैं, उनमें यह मुझे सबसे दिलचस्प लगा।