लगता है कि कोरिया में समस्या बहुत बड़ी नहीं है.

  • भूमि, अवसंरचना और परिवहन मंत्रालय तथा विमानन उद्योग के अनुसार, घरेलू एयरलाइनों में A320 सीरीज़ के यात्री विमान संचालित करने वाली 6 कंपनियां हैं: Korean Air (18), Asiana Airlines (24), Air Busan (21), Air Seoul (6), Aero K (9), Parata Air (2)
  • इनमें से 42 विमान इस रिकॉल के दायरे में हैं, लेकिन इनमें ऐसा कोई पुराना मॉडल नहीं है जिसमें 3 से 4 घंटे लगने वाला हार्डवेयर बदलना पड़े
  • मंत्रालय के अनुसार, रिकॉल के दायरे में आने वाले सभी विमानों में कॉकपिट से software update के जरिए 1 घंटे के भीतर जरूरी कार्रवाई पूरी की जा सकती है, और 11/30 को 6 बजे तक 42 में से 40 विमानों (95%) का update पूरा हो चुका था
 

मैं इस बार सच में Windows छोड़ने के इरादे से एक UMPC खरीदकर Bazzite इस्तेमाल कर रहा हूँ, और इससे बहुत संतुष्ट हूँ. Korean input वाले हिस्से में KDE थोड़ा मुश्किल था, इसलिए GNOME environment पर आ गया, जो Mac जैसा लगता है और मुझे बहुत पसंद आ रहा है. GPT भी काफी मदद करता है.

 

वेक्टर DB वगैरह कुछ भी हो, असल में तो बस search implement करना ही काफी होगा...

 

अगर सिस्टम को अच्छी क्वालिटी देनी है, तो अच्छा होगा कि उसे कुछ गुंजाइश और लचीलापन रखते हुए बनाया जाए। और यह भी तय है कि संगठन इंजीनियरिंग और development methodology आज की तुलना में कम विकसित होने वाले दौर के मुकाबले, औसतन अब स्थिति बेहतर ही होगी.

लेकिन मेरी नज़र में यह ऐसे लगता है जैसे कोई व्यक्ति, जिसका इंजीनियर के रूप में अहं बहुत फूला हुआ है लेकिन संगठन के सदस्य के रूप में जिम्मेदारी की भावना कम है, यह सफाई दे रहा हो कि यह सब उसकी गलती नहीं बल्कि management की गलती है।

क्या architectural engineers, industrial designers, animators के पास deadline नहीं होती, और क्या उनका मूल्यांकन productivity के बजाय सिर्फ creativity और quality से होता है, जबकि केवल programmers के पास ही deadline होती है?

 

मेरे अनुभव में, अगर CS, खासकर PLT, की बुनियाद मज़बूत हो तो आखिरकार किसी भी माहौल में अपेक्षाकृत बेहतर कोड लिखा जाता है।

बहुत गहरी जानकारी न भी हो, फिर भी जो व्यक्ति सबसे बुनियादी सिद्धांतों को समझता हो, उसके पास अगर पर्याप्त समय हो और कोड परिचित हो, तो वह अपने स्तर पर ठीक-ठाक code quality निकाल लेता है। n बार refactoring कर दें तो AI के लिखे कोड भी कुछ हद तक काफ़ी ठीक-ठाक लगने लगते हैं।

किसी एक source को चाहे जितने लंबे समय तक पकड़े रहें, फिर भी ऐसे बहुत से लोग होते हैं जो खुद को 20 साल का अनुभवी बताते हैं लेकिन spaghetti code के अलावा कुछ नहीं बना पाते, और यह भी नहीं जानते कि ऐसा क्यों नहीं करना चाहिए।

जब तक एकदम परफेक्ट माहौल में अनंत समय और बजट नहीं दिया जा सकता, यह मुझे काफ़ी हद तक खोखली बात लगती है जिसका बहुत बड़ा मतलब नहीं है। क्या किसी भी दौर में, किसी भी role में, बात आखिर यही नहीं रही है?

उसी system में बेहतर कोड लिख पाना स्पष्ट रूप से engineer की क्षमता है.

 

यहाँ पोस्ट होने वाले लेख आमतौर पर घरेलू SI बाज़ार के कुछ दृष्टिकोणों या अनुभवों से कुछ अलग माहौल के हो सकते हैं, जहाँ OCP तक को नज़रअंदाज़ किया जाता है.

खैर, Linus Torvalds कोई जूनियर तो नहीं हैं...

 

Gemini :
हाँ, RAG (Retrieval-Augmented Generation) में vector database (Vector Database) के उपयोग की अवधारणात्मक नींव 2020 में संबंधित पेपर पहली बार प्रकाशित होने के साथ ही रखी गई थी।
RAG मूल रूप से retrieval और generation को जोड़ने का तरीका है, और इस retrieval चरण में vector embedding तथा उन्हें कुशलतापूर्वक स्टोर और सर्च करने वाला vector database अनिवार्य भूमिका निभाता है।
💡 RAG और vector DB की शुरुआत
RAG में vector DB की आवश्यकता का विचार निम्नलिखित प्रमुख पेपरों और अवधारणाओं से शुरू हुआ।

  1. RAG का जन्म: Lewis et al. (2020) पेपर
  • पेपर का शीर्षक: "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (ज्ञान-गहन प्राकृतिक भाषा प्रसंस्करण कार्यों के लिए retrieval-augmented generation)
  • मुख्य बिंदु: इस पेपर में पहली बार RAG शब्द और framework प्रस्तुत किया गया था।
  • Retriever की भूमिका: पेपर में प्रस्तावित RAG मॉडल Retriever और Generator से मिलकर बना है। Retriever, Wikipedia जैसे बड़े dataset से query से संबंधित document (latent documents) खोजता है।
  • vector index का उपयोग: इस शुरुआती RAG मॉडल ने documents को खोजने के लिए dataset में vector index (Vector Index) का उपयोग किया, ताकि pretrained retriever documents ला सके।
  • निष्कर्ष: चूँकि RAG का मुख्य चरण 'retrieval' query और document के vector representation पर आधारित similarity की गणना करके किया जाता है, इसलिए कुशल खोज के लिए vector store (Vector Store) या vector index की अवधारणा स्वाभाविक रूप से अनिवार्य रूप में शामिल थी।
  1. vector embedding और similarity search
    vector database के RAG का अनिवार्य तत्व बनने के मूल कारण इस प्रकार हैं।
  • embedding (Embedding): RAG सिस्टम में external knowledge (documents, text) और user query (प्रश्न) दोनों को vector नामक गणितीय representation में बदला जाता है। यह vector, text के अर्थ को high-dimensional space में dense संख्यात्मक array के रूप में दर्शाता है।
  • similarity search (Similarity Search): vector space में query vector के सबसे नज़दीकी distance पर मौजूद document vector को खोजना, अर्थ के स्तर पर सबसे अधिक समान (relevant) document को खोजना होता है।
  • vector DB की भूमिका: vector database ऐसे बहुत सारे document vectors को स्टोर करता है और दिए गए query vector के लिए सबसे समान vector को तेज़ी और कुशलता से खोजने के लिए विशेष रूप से डिज़ाइन किया गया database है। इसलिए RAG की retrieval performance को अधिकतम करने में यह अनिवार्य है।
    सारांश: vector DB की ज़रूरत क्यों है
    यदि LLM को ऐसे नवीनतम या domain-specific ज्ञान तक पहुँच देनी है, जो उसने training में नहीं सीखा, तो केवल keyword matching (पारंपरिक खोज) से काम नहीं चलेगा; जानकारी को semantic similarity के आधार पर खोजना होगा। vector DB इसी semantic similarity-आधारित खोज को कुशलतापूर्वक करने के लिए RAG framework में स्वाभाविक रूप से एकीकृत की गई मुख्य तकनीक है.
 

सब कुछ कितना बेतुका फैला हुआ है.. बुरा code, अच्छा code जैसी बातें तो junior लोग करते हैं, उससे ज़्यादा अहम यह है कि उस उद्योग के हिसाब से software design अच्छी तरह करने वाला senior है या नहीं..

 

विज्ञापन तो बस शुरुआत है, और यह आगे चलकर प्रोडक्ट व सेवाओं की खरीद तक ले जाने वाला user experience देगा। कौन जाने, शायद Worldcoin भी ऑफर कर दें।

 

यह बात कि RAG के लिए vector DB ज़रूरी है, आखिर शुरू कहाँ से हुई…

 

यह पढ़कर बहुत मज़ा आया। अगर आप इसे लगातार जारी रखें तो अच्छा लगेगा, हाहा

 

जब filebeat जैसे processor फीचर इम्प्लीमेंट करने हों, तब यह काम का लग सकता है..
https://www.elastic.co/docs/reference/beats/filebeat/processor-script

 

बजट तो पर्याप्त था, इसलिए जब हमने किसी तरह प्रवेश शुल्क हटा दिया, तो नो-शो की संख्या आधे से भी ज़्यादा हो गई। बिना सोचे-समझे रजिस्टर कर के फिर न आने वाले लोग वाकई...

 

> मैं डेवलपर नहीं हूँ, इसलिए अंदरूनी हालात नहीं जानता, लेकिन लगता है कि पहले इस तरह सॉफ़्टवेयर न तो बनाया जाता था और न ही चलाया जाता था। ऐसा महसूस होता है कि समस्याओं से बचने के लिए ज़्यादा सावधान रहने वाले "समझदार लोग" पहले अधिक हुआ करते थे।

लगता है, वह डेवलपर भी नहीं है..

 

> यह देखते हुए कि ऐसी सारी बहसें पहले भी सचमुच अनगिनत बार आ चुकी हैं, मैं बहुत ज़्यादा निराशावादी नहीं होना चाहता।
assembler से high-level language की ओर बदलाव, OOP की शुरुआत, component architecture/COM/CORBA, web browser का आगमन, Java को अपनाना आदि—2018 "गिरावट की शुरुआत का बिंदु" नहीं था, बल्कि अतीत से लगातार चली आ रही data points में से सिर्फ़ एक था।

एक बात पर आपत्ति करूँ तो, लगता है कि यह टिप्पणी लिखने वाले ने मूल लेख में बताई गई समस्या की परिभाषा को समझा ही नहीं। ऊपर कही गई high-level language की ओर जाने की बात का AI द्वारा जनरेट किए गए code की vulnerabilities और उस संरचना से, जिसमें senior engineer उभर ही नहीं सकते, कोई लेना-देना नहीं है। बल्कि इस टिप्पणी को लिखने वाले ने खुद ही मूल लेख की समस्या को साबित कर दिया। बात engineering के महत्व की हो रही है, लेकिन लगता है कि इन्हें मुश्किल engineering पसंद नहीं, और सीखना भी नहीं चाहते, इसलिए बहुत ज़्यादा बहाने बना रहे हैं। बात को बहुत खींच रहे हैं.

 

सबसे नीचे दी गई सबसे अहम सलाह वाकई कमाल की है।

 

कुल मिलाकर सहमत हूँ
खासकर context switching? prompt भेजकर इंतज़ार करने के दौरान फोकस टूट जाता है और productivity घटती है। अगर LLM की speed बढ़कर तुरंत response आने लगे, तो शायद इसका समाधान हो सकता है