AI-Native कंपनी बनाना

xguru · 2024-07-01T11:22:02+09:00

2020 के दशक की शुरुआत में generative AI पर बहुत अधिक ध्यान केंद्रित था चर्चा मुख्य रूप से इस बात पर थी कि generative AI tools हमें कैसे आकार देंगे, और लेखन, coding, animation, तथा जानकारी उपभोग करने के हमारे तरीकों को कैसे प्रभावित करेंगे लेकिन हमारे tools के रूप को लेकर उतनी चर्चा नहीं हुई 1960 के दशक के उत्तरार्ध में, information systems को विशाल मात्रा में data के कारण प्रासंगिक जानकारी खोजने की प्रक्रिया के लगातार महंगा होते जाने की समस्या का सामना करना पड़ा 1980 और 90 के दशक में relational database प्रमुख समाधान बन गए उन्होंने सहज indexing प्रदान की और query efficiency सुनिश्चित की relational database ने data को structured relationships वाली tables के संग्रह के रूप में प्रस्तुत करना संभव बनाया SQL जैसी query languages के माध्यम से तेज़ data retrieval संभव हुआ database architecture के विकसित होने की प्रक्रिया में IBM, Oracle, Sun Microsystems, MongoDB जैसी कुछ कंपनियों ने उभरते हुए अलग-अलग बाज़ारों में अपनी स्थिति मज़बूत की Oracle ने relational database की दुनिया का नेतृत्व किया, लेकिन लोग जानकारी को store और access करने के तरीके लगातार बदलते रहे हर नए काम के साथ, लोगों ने उसे प्रबंधित करने के लिए नई architecture तैयार की हाल के वर्षों में database का विकास unstructured data को संभालने की आवश्यकता से प्रेरित रहा है पिछले 50 से अधिक वर्षों में schema मुख्य रूप से structured data relationships के इर्द-गिर्द बनाए गए थे लेकिन धीरे-धीरे अधिक लोगों को ऐसे tools की ज़रूरत होने लगी जो data ambiguity को कहीं बेहतर ढंग से संभाल सकें इसी से vector database सामने आए GPT जैसे transformer-based large language models (LLM) text में long-range dependencies को पकड़ सकते हैं लेकिन लंबे पाठ की समझ बनाए रखना computational रूप से महंगा हो सकता है vector database ऐसे models की context window को बढ़ा सकते हैं vector database AI use cases में शक्तिशाली हो सकते हैं, लेकिन वे अब भी input और output से चलने वाला एक मूर्ख infrastructure हैं उनमें data को समझने या व्याख्या करने की क्षमता नहीं होती वे बस निर्देशानुसार data को store और retrieve करने वाले repository की भूमिका निभाते हैं, उनमें कोई अंतर्निहित intelligence या situational awareness नहीं होती 2020 में GPT-3 के लॉन्च के साथ AI का उपयोग कंपनियों के products में परिशिष्ट की तरह नहीं, बल्कि core के रूप में बढ़ने लगा transformer architecture, data की बढ़ती मात्रा, और performance improvements ने AI-based product development की नींव तैयार की जैसे-जैसे AI-Native (AI-आधारित) कंपनियों की संख्या और उनका पैमाना बढ़ रहा है, वैसे-वैसे AI-based use cases को support करने वाले tools की ज़रूरत भी बढ़ रही है AI-first कंपनियों की पहली लहर मुख्य रूप से existing models का उपयोग करके inference पर केंद्रित थी लेकिन बेहतर performance वाले models, खासकर आसानी से उपलब्ध open source models, ने कंपनियों को AI-based business के रूप में अपनी क्षमताएँ और गहराई से बनाने में सक्षम किया है यह scalability इस बात की संभावनाओं की एक नई दुनिया खोल रही है कि AI-based technology stack कैसा दिख सकता है हमें आकार देने वाले tools (The Tools that Shape Us) 1967 में Marshall McLuhan के मित्र John M. Culkin ने कहा था, "हम tools बनाते हैं और फिर tools हमें बनाते हैं" technology बनाना भी इससे अलग नहीं है software बनाने के लिए हम जिस infrastructure का उपयोग करते हैं, वह हमारी build requirements के अनुरूप लगातार विकसित होता रहा है, और फिर हमारी build process उसी infrastructure से आकार लेती है जिसे हमने तैयार किया 2020 के दशक की शुरुआत में generative AI पर बहुत अधिक ध्यान केंद्रित था खास तौर पर output पर: जैसे generated text या code, rendered images, बनाए गए deepfakes, और synthesized music चर्चा मुख्य रूप से इस बात पर थी कि ये tools हमें कैसे आकार देंगे, और लेखन, coding, animation, तथा जानकारी उपभोग करने के हमारे तरीकों को कैसे प्रभावित करेंगे लोग open और proprietary large language models की comparative performance, hallucination के जोखिम, platform बनाम feature बहस, और incumbents बनाम startups की बहस पर चर्चा कर रहे थे लेकिन हमारे tools के रूप को लेकर उतनी चर्चा नहीं हुई मूल रूप से, हम technology को जिस तरह बनाते हैं, वह उसी infrastructure से आकार लेता है जिसे हमने उस निर्माण के लिए तैयार किया है SaaS का प्रसार internet ने तेज़ किया, smartphone की सर्वव्यापकता ने mobile development को संभव बनाया, और cloud computing ने application generations की scalability को आगे बढ़ाया applications में AI की सर्वव्यापकता computing, model capabilities, और business use cases के भीतर उन models के orchestration पर निर्भर करती है यह लेख orchestration तत्व पर ध्यान केंद्रित करेगा सभी AI use cases के orchestration में एक मुख्य तत्व कंपनी का database है data जहाँ store, manipulate, और call किया जाता है, वह इस पहेली का एक महत्वपूर्ण हिस्सा है लेकिन जैसा कि हम दिखाएँगे, database का इतिहास बड़े पैमाने पर मूर्ख infrastructure का इतिहास रहा है AI की उपयोगिता को अधिकतम करने के लिए database को generative equation का हिस्सा बनने लायक बनाना होगा data की नींव (A Base For Data) मई 1959 में, CODASYL (Conference on Data Systems Languages) की पहली बैठक बुलाई गई थी, जिसका उद्देश्य "बिज़नेस applications बनाने के लिए एक general-purpose language" तैयार करना था 1960 के दशक के अंत तक, information systems को विशाल मात्रा में data के कारण प्रासंगिक जानकारी खोजने की प्रक्रिया के लगातार महंगी होती जाने की समस्या का सामना करना पड़ा mainframe computers का उपयोग आम तौर पर application maintenance, patching, performance बनाए रखने के लिए ज़रूरी upgrades की लागत आदि के कारण, mainframe उपयोग बढ़ने के साथ MIPS (million instructions per second) लागत में वृद्धि का कारण बना database management की जटिलता, कठोर hierarchical structure, और complex navigation structure mapping के कारण, कंपनियों को अक्सर चुनी हुई जानकारी तक पहुँचने के लिए technical expertise की ज़रूरत पड़ती थी, और कुछ developers को तो संबंधित जानकारी तक पहुँचने के लिए पूरे programs लिखने पड़ते थे 1970 में E.F. Codd ने "A Relational Model of Data for Large Shared Data Banks" प्रकाशित किया, जिसमें उन्होंने ऐसा model प्रस्तावित किया जिसमें tables को shared properties के ज़रिये जोड़ा जा सकता था (यानी, unique records की पहचान करने वाली primary key और tables के बीच relationships स्थापित करने वाली foreign key) इससे एक ही query के माध्यम से अलग-अलग tables से data प्राप्त करना संभव हुआ Codd के relational database ने data items के बीच संबंधों के आधार पर data manipulation और उपयोग में flexibility संभव बनाई 1973 में IBM San Jose Research Laboratory के programmers के एक समूह ने System R project शुरू किया, ताकि यह साबित किया जा सके कि relational database systems production use के लिए आवश्यक पूरी functionality को समाहित करते हुए भी उच्च performance दे सकते हैं इस टीम ने database efficiency के लिए cost-based optimizer विकसित किया, और System R से निकले विकास बाद में IBM के पहले relational database product SQL/DS के launch तक पहुँचे 1980 और 1990 के दशकों में relational databases प्रमुख database solution बन गए उन्होंने intuitive indexing प्रदान की और query efficiency सुनिश्चित की relational databases ने data को structured relationships वाली tables के संग्रह के रूप में प्रस्तुत करना संभव बनाया SQL जैसी query language के माध्यम से तेज़ data retrieval संभव हुआ relational databases इस धारणा पर बनाए गए थे कि वे एक single machine पर चलेंगे लेकिन 1990 और 2000 के दशकों में internet के बड़े पैमाने पर अपनाए जाने से data का भारी प्रवाह आया, जिससे ऐसे workloads बने जिन्हें एक single computer संभाल नहीं सकता था पारंपरिक SQL databases को single server पर चलने के लिए design किया गया था, और users को storage capacity के अनुसार physical hardware बढ़ाना पड़ता था, जो बड़े workloads चलाने वाली कंपनियों के लिए बहुत महंगा साबित हुआ 2010 के दशक में OLTP (online transaction processing) के लिए data और users की संख्या तेज़ी से बढ़ी, जिससे distributed databases, data warehouses, और OLAP (online analytical processing) में व्यापक वृद्धि हुई relational databases और SQL अब application scale और complexity की आवश्यकताओं के लिए उपयुक्त नहीं रहे, और NoSQL databases performance बढ़ाने के साधन के रूप में उभरे (ACID capabilities की क़ीमत पर) relational databases structured data को store और manipulate कर सकते थे, लेकिन joins के overhead और CRUD operations की लागत को देखते हुए data के बीच relationships बनाए रखना मुश्किल था relational databases logical या discrete requirements वाले relational data को संभालने के लिए उपयुक्त थे, लेकिन आम तौर पर वे उन legacy systems के अनुरूप थे जो खास तौर पर relational structures के लिए बनाए गए थे NoSQL unstructured big data को संभालने के साधन के रूप में उभरा और non-relational approach के माध्यम से developers को data persistence प्रदान की SQL को primary query language के रूप में इस्तेमाल करने के बजाय, NoSQL ने API के माध्यम से access दिया, जिससे अधिक scalability, distributed computing, cost reduction, और schema flexibility सुनिश्चित हुई NoSQL databases ऐसे efficient architecture पर चलते हैं जिन्हें horizontally scale किया जा सकता है, इसलिए storage या computing capacity बढ़ाने के लिए सिर्फ़ अधिक servers या cloud instances की ज़रूरत होती है जिन कंपनियों के data workloads unstructured data की तेज़ processing या analysis से जुड़े थे, उनके लिए NoSQL databases को प्राथमिकता दी गई OG database युद्ध database architecture के विकसित होने के दौरान, कुछ कंपनियों ने हर उभरते बाज़ार में अपनी मज़बूत स्थिति बना ली IBM द्वारा System R launch करने के तुरंत बाद, 33 वर्षीय Larry Ellison ने Codd के relational database पर वही paper पढ़ा Ellison और उनके दो co-founders ने System R-compatible company बनाने की कोशिश की, लेकिन IBM ने इसे बहुत कठिन बना दिया परिणामस्वरूप, इस तिकड़ी ने अपने नए flagship database product Oracle Databases के इर्द-गिर्द व्यवसाय खड़ा किया तब से Oracle का database एक leading product बन गया, और मई 2024 तक इसकी market share लगभग 28.7% है Oracle के 1986 IPO से ठीक पहले के वर्षों में एक और company database क्षेत्र में उतरी Sun Microsystems ने 1982 में विभिन्न computer components बेचने से शुरुआत की, लेकिन बाद में Java programming language, Network File System आदि में अपने योगदान के लिए प्रसिद्ध हुई महत्वपूर्ण बात यह है कि 2008 में Sun Microsystems ने MySQL नामक open source database management system का अधिग्रहण किया सिर्फ़ 2 साल बाद Oracle ने Sun Microsystems (जिसमें MySQL भी शामिल था) का अधिग्रहण कर लिया लगभग 15 साल बाद, मई 2024 तक leading databases Oracle (28.7% market share) और MySQL (लगभग 17.3%) हैं हालाँकि Oracle relational database दुनिया का नेतृत्व कर रहा था, लेकिन लोगों के जानकारी store करने और access करने के तरीके लगातार बदलते रहे हर नए काम के साथ, लोगों ने उसे संभालने के लिए नई architecture तैयार की MongoDB (2007), Databricks (2013) जैसे document stores से लेकर InfluxDB (2013), Prometheus (2012) जैसे time-series databases, और Neo4j (2007), Cosmos (2017) जैसे graph databases तक, specialized databases की सूची लगातार बढ़ती रही relational databases की लोकप्रियता लगातार घटने के साथ, इन नई niche needs के लिए अलग-अलग solutions उभरे databases का नवीनतम evolution unstructured data को संभालने की आवश्यकता से आया पिछले 50 से अधिक वर्षों तक schemas मुख्य रूप से structured data relationships के इर्द-गिर्द बनाए गए थे लेकिन धीरे-धीरे अधिक लोगों को ऐसे tools की ज़रूरत होने लगी जो data ambiguity को कहीं बेहतर ढंग से संभाल सकें इसी के साथ vector databases सामने आए vector databases का उदय बड़े पैमाने के language models (LLM) और generative AI के व्यापक प्रसार के साथ vector database असंरचित multimodal data को प्रोसेस करने वाले टूल के रूप में उभरे हैं जहाँ पारंपरिक relational database (Postgres, MySQL) structured schema के लिए सबसे उपयुक्त हैं, वहीं vector database vector embeddings को स्टोर और क्वेरी करने के लिए उपयुक्त हैं, जो data का numerical representation होते हैं और language model के weights के सापेक्ष अर्थ को समाहित करते हैं relational database में आम तौर पर इस्तेमाल होने वाली rows और columns के बजाय, vector database data को multidimensional space में points के रूप में दर्शाते हैं और exact values के बजाय similarity के आधार पर data को match करते हैं embedding model के अनुसार data को अलग-अलग vector spaces और विभिन्न dimensions में प्रदर्शित किया जा सकता है vector embedding data points के अर्थ को कैप्चर करते हैं, जिससे vector database में सबसे निकट के objects को खोजकर समान objects को retrieve किया जा सकता है उदाहरण के लिए, Word2Vec शब्दों को vectors से map करता है, जिससे अर्थ, semantic similarity, और अन्य text के साथ contextual relationship को कैप्चर करने में मदद मिलती है यह algorithm shallow neural network का उपयोग करके बड़े text corpus से किसी विशेष शब्द का अर्थ infer करता है और logistic regression के जरिए synonyms की पहचान करता है singular value decomposition (SVD) और principal component analysis (PCA) जैसी विधियाँ भी हैं, जो deep neural network पर निर्भर हुए बिना embeddings निकालने में मदद करती हैं distance metrics vector space में points के बीच सापेक्ष "distance" तय करने में मदद करते हैं; आम तरीकों में Euclidean distance, Manhattan distance, cosine distance, और Jaccard similarity शामिल हैं K-nearest neighbors (KNN) और approximate nearest neighbors (ANN) images, video, या अन्य multimodal inputs के लिए similarity search को सरल बनाकर execution time बेहतर करने में मदद करते हैं Weaviate, Chroma, Qdrant, Pinecone जैसे vector-specific databases डेवलपर्स को बड़े पैमाने के data, खासकर असंरचित inputs, पर search को आसान बनाने में मदद करते हैं पारंपरिक relational database या NoSQL database के विपरीत, vector database खास तौर पर vector embeddings को संभालने के लिए डिज़ाइन किए गए हैं जहाँ पारंपरिक database data को scalar के रूप में स्टोर करते हैं, vector database केवल vectors स्टोर करते हैं और quantization तथा clustering जैसी indexing techniques का उपयोग करके retrieval operations को optimize करते हैं GPT जैसे transformer-आधारित LLM text में long-term dependencies को कैप्चर कर सकते हैं लेकिन long-form comprehension बनाए रखना computationally महंगा हो सकता है नवीनतम LLM input में token pairs की global dependencies को कैप्चर कर सकते हैं, लेकिन time और space complexity के कारण computational resource की समस्या पैदा होती है, जिससे training के दौरान input text की लंबाई और inference के दौरान effective context window सीमित हो जाती है multidimensional cases में relative positional encoding को implement करना कठिन होता है, और relative position को encode करने वाले अधिकांश approaches को मजबूत positional embedding mechanism की ज़रूरत होती है, जो inference के दौरान performance degradation में योगदान दे सकता है text की लंबाई बढ़ने पर भी vector database मॉडल की long-term memory की तरह काम करने में महत्वपूर्ण हो सकते हैं vector database का उपयोग text completion या summarization जैसे कार्यों को सरल बना सकता है, जहाँ सटीक परिणाम बनाने के लिए पूरे sentence context की आवश्यकता हो सकती है vector database retrieval-augmented generation (RAG) को support कर सकते हैं, जहाँ vector database का उपयोग original query के साथ अतिरिक्त context जोड़कर LLM को दिए जाने वाले prompt को बेहतर बनाने के लिए किया जा सकता है LLM अक्सर self-supervised learning models पर निर्भर होते हैं, इसलिए वे अक्सर domain-specific tasks में संघर्ष करते हैं, जहाँ विशिष्ट knowledge या अधिक accuracy threshold की आवश्यकता होती है RAG hallucinations को कम करने में मदद कर सकता है, जो समस्या की query के लिए context की कमी से उत्पन्न हो सकते हैं, साथ ही यह verify, trace, या explain करने में मदद करता है कि response कैसे निकाला गया डेवलपर्स knowledge graph और vector search को मिलाकर LLM को उसके training data से आगे तक विस्तारित कर सकते हैं Microsoft Research का GraphRAG जैसे टूल private datasets पर retrieval करते समय prompt augmentation को आसान बनाते हैं बेसिक RAG अक्सर बड़े data collections पर summary किए गए semantic concepts को समग्र रूप से समझने में कठिनाई महसूस करता है, इसलिए LlamaIndex और GraphRAG जैसे टूल private datasets के आधार पर knowledge graph बनाते हैं डेवलपर्स के लिए specific requirements या use case के आधार पर RAG की बजाय knowledge graph का उपयोग करना बेहतर हो सकता है vector database similarity search के लिए उपयुक्त हैं और document या image retrieval, recommendation generation के लिए सबसे अच्छे हैं, जबकि knowledge graph reasoning के लिए उपयुक्त हैं, खासकर data gathering, interconnected relationships के साथ entity extraction, और उन relationships को traverse करने में उपयोगी हैं जिन applications को real-time या near-real-time data processing की आवश्यकता होती है, उनके लिए कम latency queries के कारण vector database को प्राथमिकता दी जा सकती है embeddings को एकत्र और स्टोर करके, vector database similarity search के तेज retrieval को संभव बनाते हैं और input prompts को समान embeddings से match करते हैं similarity ranking recommendation systems, semantic search, image recognition, और अन्य natural language processing applications सहित विभिन्न machine learning tasks को support करने में मदद करती है vector database vector embeddings के efficient storage और retrieval को संभव बनाकर LLM के performance को बेहतर करने में महत्वपूर्ण भूमिका निभाते हैं इससे बड़े पैमाने पर natural language को अपने-आप समझना संभव हो सकता है हालांकि, vector embeddings N+1 innovation को दर्शाते हैं यह relational या time-series data जैसे पहले के data formats हैं legacy database vendors ने MongoDB के Atlas Vector Search, SingleStore के vector database, और Neo4J के vector search index जैसी vector capabilities जारी करना शुरू कर दिया है AI use cases में vector database शक्तिशाली हो सकते हैं, लेकिन वे अभी भी input और output से संचालित होने वाला साधारण infrastructure हैं उनमें data को समझने या interpret करने की क्षमता नहीं होती वे सिर्फ निर्देशानुसार data को स्टोर और retrieve करने वाले repository की तरह काम करते हैं; उनमें स्वाभाविक intelligence या situational awareness नहीं होती आधुनिक AI-आधारित applications के लिए केवल इतना पर्याप्त नहीं होगा कंपनियाँ अब बढ़ते हुए AI models को core में रखकर निर्माण कर रही हैं इसलिए यदि applications को लगातार अधिक intelligent capabilities दिखानी हैं, तो infrastructure में भी वही intelligent capabilities होनी चाहिए पहली पीढ़ी की AI-Native कंपनियाँ 1956 में Dartmouth College में अकादमिक जगत ने पहली बार artificial intelligence पर शोध शुरू किया, और तब से व्यावहारिक use case इस क्षेत्र को आगे बढ़ाते रहे हैं उदाहरण के लिए, 1960 के दशक के अंत में Joseph Weizenbaum ने ELIZA नाम का एक computer program बनाया, जिसमें pattern matching के जरिए बातचीत का simulation करने वाला सरल approach शुरुआती therapy-जैसी बातचीत में इस्तेमाल हुआ था (पहला chatbot) बिज़नेस use case में AI के उपयोग के अधिकांश इतिहास में AI का सुधार क्रमिक रहा AI शब्द के लोकप्रिय होने से पहले, इसी तकनीक के लिए machine learning शब्द ज़्यादा इस्तेमाल होता था यानी, "डेटा से सीखने और अनदेखे डेटा पर generalize करने में सक्षम statistical algorithm, जो explicit निर्देशों के बिना कार्य कर सकते हैं" सार्वजनिक धारणा के लिहाज़ से AI 30 नवंबर 2022 को OpenAI द्वारा ChatGPT लॉन्च किए जाने पर एक turning point पर पहुँचा, लेकिन तकनीकी दृष्टि से मोड़ उससे बहुत पहले आ चुका था नवंबर 2017 में, अंतरराष्ट्रीय regulatory body Financial Stability Board (FSB) ने financial services पर machine learning के प्रभाव का एक overview तैयार किया financial services कंपनियाँ बढ़ते हुए machine learning का उपयोग "credit quality assessment" जैसे कार्यों के लिए कर रही थीं और इससे "अधिक efficient financial system में योगदान" संभव था यानी, यह efficiency बढ़ा सकता था, लेकिन यह अस्तित्वगत अनिवार्यता नहीं था इसी बीच machine learning लगातार बेहतर होता गया, और मई 2018 में OpenAI ने large-scale model training के लिए आवश्यक compute के इतिहास पर एक research प्रकाशित की, जिसमें दिखाया गया कि 2012 के बाद से हर 3.4 महीने में यह दोगुना हुआ और compute 3 लाख गुना बढ़ गया अगले महीने, जून 2018 में, OpenAI ने GPT model का पहला परिचय प्रकाशित किया दो धाराओं के बीच बहस बन रही थी एक ओर बहुत से लोग मानते थे कि लगातार बड़े होते model अंततः diminishing returns के नियम से टकराएँगे दूसरी ओर OpenAI वाला समूह मानता था कि scale बढ़ने के साथ performance में सुधार जारी रहेगा जनवरी 2020 में, OpenAI researcher और Johns Hopkins University के professor Jared Kaplan ने अन्य लोगों के साथ मिलकर "Scaling Laws for Neural Language Models" प्रकाशित किया, जिसमें कहा गया: "मॉडल का आकार, डेटा और compute को उचित रूप से scale करने पर language modeling performance सहज और पूर्वानुमेय तरीके से बेहतर होती है। हमें उम्मीद है कि बड़े language model मौजूदा मॉडलों से बेहतर performance और अधिक sample efficiency दिखाएँगे।" मई 2020 में, OpenAI ने GPT-3 पर "Language Models are Few-Shot Learners" नाम का paper प्रकाशित किया, जिसने compute बढ़ने के साथ performance ke smooth scaling ko dikhaya OpenAI ने यह भी पाया कि scale बढ़ाने से generalization की क्षमता भी बेहतर होती है, और उसका दावा था कि "large language models का scaling task-agnostic few-shot performance को काफ़ी बढ़ाता है, जिससे वे कभी-kabhi पहले के state-of-the-art fine-tuning approach के साथ प्रतिस्पर्धा कर सकते हैं" स्वतंत्र researcher Gwern Branwen ने एक blog post में scaling hypothesis गढ़ी और कहा: "मई 2020 में OpenAI द्वारा जारी GPT-3 अब तक train किए गए neural network में सबसे बड़ा है, और यह एक अंक के गुणक से भी बड़ा है... कई लोगों (मेरे सहित) की अपेक्षाओं के विपरीत, scale में यह विशाल वृद्धि OpenAI की भविष्यवाणी के अनुसार scale के लाभ दिखाती रही और यह उस diminishing return या negative return से नहीं टकराई जिसकी कई लोगों ने अपेक्षा की थी।" Branwen ने जो आश्चर्य महसूस किया, वही परिदृश्य में बदलाव था AI अब किसी कंपनी के product का परिशिष्ट भर नहीं था; इसे बढ़ते हुए core के रूप में इस्तेमाल किया जा सकता था transformer architecture, बढ़ी हुई data quantity और बेहतर performance level—इन सबने AI-आधारित product development की नींव रखी GPT-3 जारी होने के तुरंत बाद, मई 2020 में Writer और Jasper जैसी कंपनियों ने copywriting products बनाए जिनमें AI model बिज़नेस के केंद्र में था Harvey और EvenUp जैसी कंपनियों ने AI को केंद्र में रखकर legal tech बनाया DeepScribe और Freed जैसी कंपनियों ने AI-केंद्रित medical transcription बनाया लेकिन जैसे अतीत में नए use case ने database के evolution को जन्म दिया था, वैसे ही AI-आधारित products के उदय का मतलब था कि हर कंपनी के tech stack के पीछे का infrastructure भी बदलना और अनुकूलित होना चाहिए AI-Native Database जैसे-जैसे AI-आधारित कंपनियों की संख्या और scale बढ़ा, AI-आधारित use case को support करने वाले tools की ज़रूरत भी बढ़ी AI-core कंपनियों की पहली लहर मुख्य रूप से मौजूदा models के inference पर केंद्रित थी उनके पास application, copywriting, medical transcription आदि के लिए purpose-built workflow tools थे product का core model द्वारा generated output था, जैसे generated text या generated image नवंबर 2023 में OpenAI के DevDay के बाद "OpenAI ruined my startup" वाला meme फैलने लगा specific expert GPT या AI agent मौजूदा models के inference पर केंद्रित थे, इसलिए वे शुरुआती AI-आधारित startup की भूमिका निभाते हुए दिखे OpenAI संयोगवश model और application दोनों का provider बन गया model capabilities के इर्द-गिर्द innovation इतनी तेज़ी से बढ़ने लगी कि यह startups के लिए ख़तरे जैसी महसूस होने लगी लेकिन दूसरी ओर, बेहतर performance वाले models—खासकर आसानी से उपलब्ध open source models—ने कंपनियों को AI-आधारित business के रूप में अपनी क्षमताएँ और गहराई से बनाने में सक्षम किया AI-आधारित tech stack बनाना सिर्फ model के आसपास components जोड़ देने से अधिक है उदाहरण के लिए, AI के लिए विशेष रूप से बना database कैसा दिखेगा? अगर inference महत्वपूर्ण output है, तो AI-आधारित database को सिर्फ data store और retrieve ही नहीं करना चाहिए, बल्कि उसे इस बारे में contextual instructions लेने में भी सक्षम होना चाहिए कि संग्रहीत data पर कौन-सा काम करना है एक उदाहरण e-commerce के लिए product description personalization हो सकता है vector database सिर्फ product SKU और description के vector embeddings ही नहीं, बल्कि user persona के embeddings भी store कर सकता है database में मौजूद इस contextual data का उपयोग करके infrastructure ऐसा generative feedback loop चला सकता है जिसमें product description के query के साथ संबंधित user persona का query भी trigger हो, और फिर उस प्रासंगिक user persona के आधार पर product description लिखा जाए इसी तरह language को भी generative feedback loop के रूप में इस्तेमाल किया जा सकता है उदाहरण के लिए, user अलग-अलग भाषाओं में product description generate करना चाह सकता है system ऐसा description generate कर सकता है जो user के लिए personalized हो और user द्वारा चुनी गई भाषा में translated भी हो इस तरह के निर्देश database में सीधे embed किए जा सकते हैं, क्योंकि generative AI जैसे use case अब application की केंद्रीय functionality बनते जा रहे हैं use case के अनुसार infrastructure को evolve करना कोई नई बात नहीं है शुरुआत में developers ने browser में application बनाकर website को interactive और dynamic बनाने के लिए JavaScript का उपयोग किया लेकिन जब developers ने समझा कि इसे backend में भी लाया जा सकता है, तब node.js पैदा हुआ फिर जैसे-जैसे developers ने अधिक mobile applications बनाना शुरू किया, वैसे-वैसे JSON (JavaScript Object Notation) उभरा, जिसने अधिक dynamic, responsive और data-driven applications को संभव बनाया MongoDB ऐसी company थी जो बदलती infrastructure आवश्यकताओं को हल करने के लिए उभरी, और यह इस लहर के लिए पूरी तरह उपयुक्त थी AI के साथ इतिहास खुद को दोहरा रहा है requirements बदलने पर infrastructure को भी उन आवश्यकताओं को पूरा करने के लिए evolve होना होगा सबसे बड़ा सवाल यह होगा कि लोग किस तरह की कंपनियाँ बनाना चाहते हैं, और किस तरह का infrastructure उन कंपनियों के लिए सबसे उपयुक्त है जैसा Bob ने Matthew Lynley के साथ एक interview में कहा: "मेरा दृढ़ विश्वास है कि भविष्य की हर application में AI होगा। कुछ applications में AI बस sprinkle किया जाएगा, और कुछ में AI application के केंद्र में होगा। AI को हटा दें तो वे रह ही नहीं जाएँगी। अगर आप एक web app बनाना चाहते हैं और उसके ऊपर AI sprinkle करना चाहते हैं, तो MongoDB का उपयोग करें। खासकर अगर आप पहले से इसका उपयोग कर रहे हैं... अगर आप ऐसा AI-native application बनाना चाहते हैं जिसमें AI application का core हो, तो Weaviate पर विचार करने का समय है।" आगे चलकर कंपनियाँ तय करेंगी कि वे AI को एक appendix की तरह जोड़कर product बनाएँगी, या Bob के शब्दों में "sprinkle" करेंगी, या उसे product का core बनाएँगी AI-Native तकनीकी स्टैक जो कंपनियाँ AI को प्रोडक्ट के मुख्य घटक के रूप में बनाना चाहती हैं, उनके लिए मौजूदा इन्फ्रास्ट्रक्चर संभवतः उपयुक्त नहीं होगा legacy tools का उपयोग करने पर data storage, organization और execution एक silo में बनते हैं और automation दूसरे silo में बनता है इस approach की कमी यह है कि generative feedback loop जैसी चीज़ों में context खो जाता है, जबकि वही प्रोडक्ट को बेहतर ढंग से जानकारी देने और सुधारने में मदद कर सकता है जो कंपनियाँ "AI-adjacent" stack से आती हैं, उनके मामले में किसी विशेष model का inference अक्सर context window तक सीमित होता है कुछ लोगों का मानना है कि यदि किसी दिए गए context window की क्षमता बढ़ जाए तो वह vector database की जगह ले सकती है लेकिन इसके उलट स्थिति, जिसमें vector database context window का विकल्प बनने की दिशा में विकसित हो, सच होने की संभावना अधिक है vector embedding generative model के लिए बहुत महत्वपूर्ण हैं, और generative output के लिए इन्फ्रास्ट्रक्चर को vector embedding को first-class citizen की तरह मानना चाहिए सिर्फ context window का आकार बढ़ाने के बजाय, vector database को model में इस तरह जोड़ा जा सकता है कि context window की contextual understanding के साथ database की reliability और scalability भी मिले खासकर, model जितना अधिक general-purpose होगा, उतनी ही कम संभावना होगी कि वह किसी खास task के लिए बना हो AI-powered vector database अधिक विशिष्ट functionality संभव बनाएंगे GPT-4 जैसे general-purpose model को जानबूझकर knowledge को सामान्यीकृत करने के लिए बनाया गया है यदि कोई product थोड़ी-सी simple fine-tuning पर निर्भर है, तो base model उस business का uniquely valuable हिस्सा नहीं बनेगा AI-आधारित product बनाना सिर्फ model का उपयोग करने से आगे की बात है; इसमें अधिक tightly connected stack के आसपास product बनाना शामिल होगा यह stack database के scale और model की capability प्रदान करके अधिक सक्षम product तैयार करेगा

(research.contrary.com)

23 पॉइंट द्वारा xguru 2024-07-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें

2020 के दशक की शुरुआत में generative AI पर बहुत अधिक ध्यान केंद्रित था
- चर्चा मुख्य रूप से इस बात पर थी कि generative AI tools हमें कैसे आकार देंगे, और लेखन, coding, animation, तथा जानकारी उपभोग करने के हमारे तरीकों को कैसे प्रभावित करेंगे
- लेकिन हमारे tools के रूप को लेकर उतनी चर्चा नहीं हुई
1960 के दशक के उत्तरार्ध में, information systems को विशाल मात्रा में data के कारण प्रासंगिक जानकारी खोजने की प्रक्रिया के लगातार महंगा होते जाने की समस्या का सामना करना पड़ा
1980 और 90 के दशक में relational database प्रमुख समाधान बन गए
- उन्होंने सहज indexing प्रदान की और query efficiency सुनिश्चित की
- relational database ने data को structured relationships वाली tables के संग्रह के रूप में प्रस्तुत करना संभव बनाया
- SQL जैसी query languages के माध्यम से तेज़ data retrieval संभव हुआ
database architecture के विकसित होने की प्रक्रिया में IBM, Oracle, Sun Microsystems, MongoDB जैसी कुछ कंपनियों ने उभरते हुए अलग-अलग बाज़ारों में अपनी स्थिति मज़बूत की
Oracle ने relational database की दुनिया का नेतृत्व किया, लेकिन लोग जानकारी को store और access करने के तरीके लगातार बदलते रहे
- हर नए काम के साथ, लोगों ने उसे प्रबंधित करने के लिए नई architecture तैयार की
हाल के वर्षों में database का विकास unstructured data को संभालने की आवश्यकता से प्रेरित रहा है
- पिछले 50 से अधिक वर्षों में schema मुख्य रूप से structured data relationships के इर्द-गिर्द बनाए गए थे
- लेकिन धीरे-धीरे अधिक लोगों को ऐसे tools की ज़रूरत होने लगी जो data ambiguity को कहीं बेहतर ढंग से संभाल सकें
- इसी से vector database सामने आए
GPT जैसे transformer-based large language models (LLM) text में long-range dependencies को पकड़ सकते हैं
- लेकिन लंबे पाठ की समझ बनाए रखना computational रूप से महंगा हो सकता है
- vector database ऐसे models की context window को बढ़ा सकते हैं
vector database AI use cases में शक्तिशाली हो सकते हैं, लेकिन वे अब भी input और output से चलने वाला एक मूर्ख infrastructure हैं
- उनमें data को समझने या व्याख्या करने की क्षमता नहीं होती
- वे बस निर्देशानुसार data को store और retrieve करने वाले repository की भूमिका निभाते हैं, उनमें कोई अंतर्निहित intelligence या situational awareness नहीं होती
2020 में GPT-3 के लॉन्च के साथ AI का उपयोग कंपनियों के products में परिशिष्ट की तरह नहीं, बल्कि core के रूप में बढ़ने लगा
- transformer architecture, data की बढ़ती मात्रा, और performance improvements ने AI-based product development की नींव तैयार की
जैसे-जैसे AI-Native (AI-आधारित) कंपनियों की संख्या और उनका पैमाना बढ़ रहा है, वैसे-वैसे AI-based use cases को support करने वाले tools की ज़रूरत भी बढ़ रही है
- AI-first कंपनियों की पहली लहर मुख्य रूप से existing models का उपयोग करके inference पर केंद्रित थी
लेकिन बेहतर performance वाले models, खासकर आसानी से उपलब्ध open source models, ने कंपनियों को AI-based business के रूप में अपनी क्षमताएँ और गहराई से बनाने में सक्षम किया है
- यह scalability इस बात की संभावनाओं की एक नई दुनिया खोल रही है कि AI-based technology stack कैसा दिख सकता है

हमें आकार देने वाले tools (The Tools that Shape Us)

1967 में Marshall McLuhan के मित्र John M. Culkin ने कहा था, "हम tools बनाते हैं और फिर tools हमें बनाते हैं"
- technology बनाना भी इससे अलग नहीं है
- software बनाने के लिए हम जिस infrastructure का उपयोग करते हैं, वह हमारी build requirements के अनुरूप लगातार विकसित होता रहा है, और फिर हमारी build process उसी infrastructure से आकार लेती है जिसे हमने तैयार किया
2020 के दशक की शुरुआत में generative AI पर बहुत अधिक ध्यान केंद्रित था
- खास तौर पर output पर: जैसे generated text या code, rendered images, बनाए गए deepfakes, और synthesized music
- चर्चा मुख्य रूप से इस बात पर थी कि ये tools हमें कैसे आकार देंगे, और लेखन, coding, animation, तथा जानकारी उपभोग करने के हमारे तरीकों को कैसे प्रभावित करेंगे
- लोग open और proprietary large language models की comparative performance, hallucination के जोखिम, platform बनाम feature बहस, और incumbents बनाम startups की बहस पर चर्चा कर रहे थे
लेकिन हमारे tools के रूप को लेकर उतनी चर्चा नहीं हुई
- मूल रूप से, हम technology को जिस तरह बनाते हैं, वह उसी infrastructure से आकार लेता है जिसे हमने उस निर्माण के लिए तैयार किया है
- SaaS का प्रसार internet ने तेज़ किया, smartphone की सर्वव्यापकता ने mobile development को संभव बनाया, और cloud computing ने application generations की scalability को आगे बढ़ाया
applications में AI की सर्वव्यापकता computing, model capabilities, और business use cases के भीतर उन models के orchestration पर निर्भर करती है
- यह लेख orchestration तत्व पर ध्यान केंद्रित करेगा
- सभी AI use cases के orchestration में एक मुख्य तत्व कंपनी का database है
- data जहाँ store, manipulate, और call किया जाता है, वह इस पहेली का एक महत्वपूर्ण हिस्सा है
- लेकिन जैसा कि हम दिखाएँगे, database का इतिहास बड़े पैमाने पर मूर्ख infrastructure का इतिहास रहा है
- AI की उपयोगिता को अधिकतम करने के लिए database को generative equation का हिस्सा बनने लायक बनाना होगा

data की नींव (A Base For Data)

मई 1959 में, CODASYL (Conference on Data Systems Languages) की पहली बैठक बुलाई गई थी, जिसका उद्देश्य "बिज़नेस applications बनाने के लिए एक general-purpose language" तैयार करना था
- 1960 के दशक के अंत तक, information systems को विशाल मात्रा में data के कारण प्रासंगिक जानकारी खोजने की प्रक्रिया के लगातार महंगी होती जाने की समस्या का सामना करना पड़ा
mainframe computers का उपयोग आम तौर पर application maintenance, patching, performance बनाए रखने के लिए ज़रूरी upgrades की लागत आदि के कारण, mainframe उपयोग बढ़ने के साथ MIPS (million instructions per second) लागत में वृद्धि का कारण बना
- database management की जटिलता, कठोर hierarchical structure, और complex navigation structure mapping के कारण, कंपनियों को अक्सर चुनी हुई जानकारी तक पहुँचने के लिए technical expertise की ज़रूरत पड़ती थी, और कुछ developers को तो संबंधित जानकारी तक पहुँचने के लिए पूरे programs लिखने पड़ते थे
1970 में E.F. Codd ने "A Relational Model of Data for Large Shared Data Banks" प्रकाशित किया, जिसमें उन्होंने ऐसा model प्रस्तावित किया जिसमें tables को shared properties के ज़रिये जोड़ा जा सकता था (यानी, unique records की पहचान करने वाली primary key और tables के बीच relationships स्थापित करने वाली foreign key)
- इससे एक ही query के माध्यम से अलग-अलग tables से data प्राप्त करना संभव हुआ
- Codd के relational database ने data items के बीच संबंधों के आधार पर data manipulation और उपयोग में flexibility संभव बनाई
1973 में IBM San Jose Research Laboratory के programmers के एक समूह ने System R project शुरू किया, ताकि यह साबित किया जा सके कि relational database systems production use के लिए आवश्यक पूरी functionality को समाहित करते हुए भी उच्च performance दे सकते हैं
- इस टीम ने database efficiency के लिए cost-based optimizer विकसित किया, और System R से निकले विकास बाद में IBM के पहले relational database product SQL/DS के launch तक पहुँचे
1980 और 1990 के दशकों में relational databases प्रमुख database solution बन गए
- उन्होंने intuitive indexing प्रदान की और query efficiency सुनिश्चित की
- relational databases ने data को structured relationships वाली tables के संग्रह के रूप में प्रस्तुत करना संभव बनाया
- SQL जैसी query language के माध्यम से तेज़ data retrieval संभव हुआ
relational databases इस धारणा पर बनाए गए थे कि वे एक single machine पर चलेंगे
- लेकिन 1990 और 2000 के दशकों में internet के बड़े पैमाने पर अपनाए जाने से data का भारी प्रवाह आया, जिससे ऐसे workloads बने जिन्हें एक single computer संभाल नहीं सकता था
- पारंपरिक SQL databases को single server पर चलने के लिए design किया गया था, और users को storage capacity के अनुसार physical hardware बढ़ाना पड़ता था, जो बड़े workloads चलाने वाली कंपनियों के लिए बहुत महंगा साबित हुआ
2010 के दशक में OLTP (online transaction processing) के लिए data और users की संख्या तेज़ी से बढ़ी, जिससे distributed databases, data warehouses, और OLAP (online analytical processing) में व्यापक वृद्धि हुई
relational databases और SQL अब application scale और complexity की आवश्यकताओं के लिए उपयुक्त नहीं रहे, और NoSQL databases performance बढ़ाने के साधन के रूप में उभरे (ACID capabilities की क़ीमत पर)
- relational databases structured data को store और manipulate कर सकते थे, लेकिन joins के overhead और CRUD operations की लागत को देखते हुए data के बीच relationships बनाए रखना मुश्किल था
- relational databases logical या discrete requirements वाले relational data को संभालने के लिए उपयुक्त थे, लेकिन आम तौर पर वे उन legacy systems के अनुरूप थे जो खास तौर पर relational structures के लिए बनाए गए थे
- NoSQL unstructured big data को संभालने के साधन के रूप में उभरा और non-relational approach के माध्यम से developers को data persistence प्रदान की
- SQL को primary query language के रूप में इस्तेमाल करने के बजाय, NoSQL ने API के माध्यम से access दिया, जिससे अधिक scalability, distributed computing, cost reduction, और schema flexibility सुनिश्चित हुई
- NoSQL databases ऐसे efficient architecture पर चलते हैं जिन्हें horizontally scale किया जा सकता है, इसलिए storage या computing capacity बढ़ाने के लिए सिर्फ़ अधिक servers या cloud instances की ज़रूरत होती है
- जिन कंपनियों के data workloads unstructured data की तेज़ processing या analysis से जुड़े थे, उनके लिए NoSQL databases को प्राथमिकता दी गई

OG database युद्ध

database architecture के विकसित होने के दौरान, कुछ कंपनियों ने हर उभरते बाज़ार में अपनी मज़बूत स्थिति बना ली
- IBM द्वारा System R launch करने के तुरंत बाद, 33 वर्षीय Larry Ellison ने Codd के relational database पर वही paper पढ़ा
- Ellison और उनके दो co-founders ने System R-compatible company बनाने की कोशिश की, लेकिन IBM ने इसे बहुत कठिन बना दिया
- परिणामस्वरूप, इस तिकड़ी ने अपने नए flagship database product Oracle Databases के इर्द-गिर्द व्यवसाय खड़ा किया
- तब से Oracle का database एक leading product बन गया, और मई 2024 तक इसकी market share लगभग 28.7% है
Oracle के 1986 IPO से ठीक पहले के वर्षों में एक और company database क्षेत्र में उतरी
- Sun Microsystems ने 1982 में विभिन्न computer components बेचने से शुरुआत की, लेकिन बाद में Java programming language, Network File System आदि में अपने योगदान के लिए प्रसिद्ध हुई
- महत्वपूर्ण बात यह है कि 2008 में Sun Microsystems ने MySQL नामक open source database management system का अधिग्रहण किया
- सिर्फ़ 2 साल बाद Oracle ने Sun Microsystems (जिसमें MySQL भी शामिल था) का अधिग्रहण कर लिया
- लगभग 15 साल बाद, मई 2024 तक leading databases Oracle (28.7% market share) और MySQL (लगभग 17.3%) हैं
हालाँकि Oracle relational database दुनिया का नेतृत्व कर रहा था, लेकिन लोगों के जानकारी store करने और access करने के तरीके लगातार बदलते रहे
- हर नए काम के साथ, लोगों ने उसे संभालने के लिए नई architecture तैयार की
- MongoDB (2007), Databricks (2013) जैसे document stores से लेकर InfluxDB (2013), Prometheus (2012) जैसे time-series databases, और Neo4j (2007), Cosmos (2017) जैसे graph databases तक, specialized databases की सूची लगातार बढ़ती रही
- relational databases की लोकप्रियता लगातार घटने के साथ, इन नई niche needs के लिए अलग-अलग solutions उभरे
databases का नवीनतम evolution unstructured data को संभालने की आवश्यकता से आया
- पिछले 50 से अधिक वर्षों तक schemas मुख्य रूप से structured data relationships के इर्द-गिर्द बनाए गए थे
- लेकिन धीरे-धीरे अधिक लोगों को ऐसे tools की ज़रूरत होने लगी जो data ambiguity को कहीं बेहतर ढंग से संभाल सकें
- इसी के साथ vector databases सामने आए

vector databases का उदय

बड़े पैमाने के language models (LLM) और generative AI के व्यापक प्रसार के साथ vector database असंरचित multimodal data को प्रोसेस करने वाले टूल के रूप में उभरे हैं
- जहाँ पारंपरिक relational database (Postgres, MySQL) structured schema के लिए सबसे उपयुक्त हैं, वहीं vector database vector embeddings को स्टोर और क्वेरी करने के लिए उपयुक्त हैं, जो data का numerical representation होते हैं और language model के weights के सापेक्ष अर्थ को समाहित करते हैं
- relational database में आम तौर पर इस्तेमाल होने वाली rows और columns के बजाय, vector database data को multidimensional space में points के रूप में दर्शाते हैं और exact values के बजाय similarity के आधार पर data को match करते हैं
embedding model के अनुसार data को अलग-अलग vector spaces और विभिन्न dimensions में प्रदर्शित किया जा सकता है
- vector embedding data points के अर्थ को कैप्चर करते हैं, जिससे vector database में सबसे निकट के objects को खोजकर समान objects को retrieve किया जा सकता है
उदाहरण के लिए, Word2Vec शब्दों को vectors से map करता है, जिससे अर्थ, semantic similarity, और अन्य text के साथ contextual relationship को कैप्चर करने में मदद मिलती है
- यह algorithm shallow neural network का उपयोग करके बड़े text corpus से किसी विशेष शब्द का अर्थ infer करता है और logistic regression के जरिए synonyms की पहचान करता है
- singular value decomposition (SVD) और principal component analysis (PCA) जैसी विधियाँ भी हैं, जो deep neural network पर निर्भर हुए बिना embeddings निकालने में मदद करती हैं
distance metrics vector space में points के बीच सापेक्ष "distance" तय करने में मदद करते हैं; आम तरीकों में Euclidean distance, Manhattan distance, cosine distance, और Jaccard similarity शामिल हैं
- K-nearest neighbors (KNN) और approximate nearest neighbors (ANN) images, video, या अन्य multimodal inputs के लिए similarity search को सरल बनाकर execution time बेहतर करने में मदद करते हैं
Weaviate, Chroma, Qdrant, Pinecone जैसे vector-specific databases डेवलपर्स को बड़े पैमाने के data, खासकर असंरचित inputs, पर search को आसान बनाने में मदद करते हैं
- पारंपरिक relational database या NoSQL database के विपरीत, vector database खास तौर पर vector embeddings को संभालने के लिए डिज़ाइन किए गए हैं
- जहाँ पारंपरिक database data को scalar के रूप में स्टोर करते हैं, vector database केवल vectors स्टोर करते हैं और quantization तथा clustering जैसी indexing techniques का उपयोग करके retrieval operations को optimize करते हैं
GPT जैसे transformer-आधारित LLM text में long-term dependencies को कैप्चर कर सकते हैं
- लेकिन long-form comprehension बनाए रखना computationally महंगा हो सकता है
- नवीनतम LLM input में token pairs की global dependencies को कैप्चर कर सकते हैं, लेकिन time और space complexity के कारण computational resource की समस्या पैदा होती है, जिससे training के दौरान input text की लंबाई और inference के दौरान effective context window सीमित हो जाती है
multidimensional cases में relative positional encoding को implement करना कठिन होता है, और relative position को encode करने वाले अधिकांश approaches को मजबूत positional embedding mechanism की ज़रूरत होती है, जो inference के दौरान performance degradation में योगदान दे सकता है
- text की लंबाई बढ़ने पर भी vector database मॉडल की long-term memory की तरह काम करने में महत्वपूर्ण हो सकते हैं
- vector database का उपयोग text completion या summarization जैसे कार्यों को सरल बना सकता है, जहाँ सटीक परिणाम बनाने के लिए पूरे sentence context की आवश्यकता हो सकती है
vector database retrieval-augmented generation (RAG) को support कर सकते हैं, जहाँ vector database का उपयोग original query के साथ अतिरिक्त context जोड़कर LLM को दिए जाने वाले prompt को बेहतर बनाने के लिए किया जा सकता है
- LLM अक्सर self-supervised learning models पर निर्भर होते हैं, इसलिए वे अक्सर domain-specific tasks में संघर्ष करते हैं, जहाँ विशिष्ट knowledge या अधिक accuracy threshold की आवश्यकता होती है
- RAG hallucinations को कम करने में मदद कर सकता है, जो समस्या की query के लिए context की कमी से उत्पन्न हो सकते हैं, साथ ही यह verify, trace, या explain करने में मदद करता है कि response कैसे निकाला गया
डेवलपर्स knowledge graph और vector search को मिलाकर LLM को उसके training data से आगे तक विस्तारित कर सकते हैं
- Microsoft Research का GraphRAG जैसे टूल private datasets पर retrieval करते समय prompt augmentation को आसान बनाते हैं
- बेसिक RAG अक्सर बड़े data collections पर summary किए गए semantic concepts को समग्र रूप से समझने में कठिनाई महसूस करता है, इसलिए LlamaIndex और GraphRAG जैसे टूल private datasets के आधार पर knowledge graph बनाते हैं
डेवलपर्स के लिए specific requirements या use case के आधार पर RAG की बजाय knowledge graph का उपयोग करना बेहतर हो सकता है
- vector database similarity search के लिए उपयुक्त हैं और document या image retrieval, recommendation generation के लिए सबसे अच्छे हैं, जबकि knowledge graph reasoning के लिए उपयुक्त हैं, खासकर data gathering, interconnected relationships के साथ entity extraction, और उन relationships को traverse करने में उपयोगी हैं
जिन applications को real-time या near-real-time data processing की आवश्यकता होती है, उनके लिए कम latency queries के कारण vector database को प्राथमिकता दी जा सकती है
embeddings को एकत्र और स्टोर करके, vector database similarity search के तेज retrieval को संभव बनाते हैं और input prompts को समान embeddings से match करते हैं
similarity ranking recommendation systems, semantic search, image recognition, और अन्य natural language processing applications सहित विभिन्न machine learning tasks को support करने में मदद करती है
vector database vector embeddings के efficient storage और retrieval को संभव बनाकर LLM के performance को बेहतर करने में महत्वपूर्ण भूमिका निभाते हैं
- इससे बड़े पैमाने पर natural language को अपने-आप समझना संभव हो सकता है
हालांकि, vector embeddings N+1 innovation को दर्शाते हैं
- यह relational या time-series data जैसे पहले के data formats हैं
legacy database vendors ने MongoDB के Atlas Vector Search, SingleStore के vector database, और Neo4J के vector search index जैसी vector capabilities जारी करना शुरू कर दिया है
AI use cases में vector database शक्तिशाली हो सकते हैं, लेकिन वे अभी भी input और output से संचालित होने वाला साधारण infrastructure हैं
- उनमें data को समझने या interpret करने की क्षमता नहीं होती
- वे सिर्फ निर्देशानुसार data को स्टोर और retrieve करने वाले repository की तरह काम करते हैं; उनमें स्वाभाविक intelligence या situational awareness नहीं होती
आधुनिक AI-आधारित applications के लिए केवल इतना पर्याप्त नहीं होगा
- कंपनियाँ अब बढ़ते हुए AI models को core में रखकर निर्माण कर रही हैं
- इसलिए यदि applications को लगातार अधिक intelligent capabilities दिखानी हैं, तो infrastructure में भी वही intelligent capabilities होनी चाहिए

पहली पीढ़ी की AI-Native कंपनियाँ

1956 में Dartmouth College में अकादमिक जगत ने पहली बार artificial intelligence पर शोध शुरू किया, और तब से व्यावहारिक use case इस क्षेत्र को आगे बढ़ाते रहे हैं
- उदाहरण के लिए, 1960 के दशक के अंत में Joseph Weizenbaum ने ELIZA नाम का एक computer program बनाया, जिसमें pattern matching के जरिए बातचीत का simulation करने वाला सरल approach शुरुआती therapy-जैसी बातचीत में इस्तेमाल हुआ था (पहला chatbot)
बिज़नेस use case में AI के उपयोग के अधिकांश इतिहास में AI का सुधार क्रमिक रहा
AI शब्द के लोकप्रिय होने से पहले, इसी तकनीक के लिए machine learning शब्द ज़्यादा इस्तेमाल होता था
- यानी, "डेटा से सीखने और अनदेखे डेटा पर generalize करने में सक्षम statistical algorithm, जो explicit निर्देशों के बिना कार्य कर सकते हैं"
सार्वजनिक धारणा के लिहाज़ से AI 30 नवंबर 2022 को OpenAI द्वारा ChatGPT लॉन्च किए जाने पर एक turning point पर पहुँचा, लेकिन तकनीकी दृष्टि से मोड़ उससे बहुत पहले आ चुका था
नवंबर 2017 में, अंतरराष्ट्रीय regulatory body Financial Stability Board (FSB) ने financial services पर machine learning के प्रभाव का एक overview तैयार किया
- financial services कंपनियाँ बढ़ते हुए machine learning का उपयोग "credit quality assessment" जैसे कार्यों के लिए कर रही थीं और इससे "अधिक efficient financial system में योगदान" संभव था
- यानी, यह efficiency बढ़ा सकता था, लेकिन यह अस्तित्वगत अनिवार्यता नहीं था
इसी बीच machine learning लगातार बेहतर होता गया, और मई 2018 में OpenAI ने large-scale model training के लिए आवश्यक compute के इतिहास पर एक research प्रकाशित की, जिसमें दिखाया गया कि 2012 के बाद से हर 3.4 महीने में यह दोगुना हुआ और compute 3 लाख गुना बढ़ गया
अगले महीने, जून 2018 में, OpenAI ने GPT model का पहला परिचय प्रकाशित किया
दो धाराओं के बीच बहस बन रही थी
- एक ओर बहुत से लोग मानते थे कि लगातार बड़े होते model अंततः diminishing returns के नियम से टकराएँगे
- दूसरी ओर OpenAI वाला समूह मानता था कि scale बढ़ने के साथ performance में सुधार जारी रहेगा
जनवरी 2020 में, OpenAI researcher और Johns Hopkins University के professor Jared Kaplan ने अन्य लोगों के साथ मिलकर "Scaling Laws for Neural Language Models" प्रकाशित किया, जिसमें कहा गया:
- "मॉडल का आकार, डेटा और compute को उचित रूप से scale करने पर language modeling performance सहज और पूर्वानुमेय तरीके से बेहतर होती है। हमें उम्मीद है कि बड़े language model मौजूदा मॉडलों से बेहतर performance और अधिक sample efficiency दिखाएँगे।"
मई 2020 में, OpenAI ने GPT-3 पर "Language Models are Few-Shot Learners" नाम का paper प्रकाशित किया, जिसने compute बढ़ने के साथ performance ke smooth scaling ko dikhaya
OpenAI ने यह भी पाया कि scale बढ़ाने से generalization की क्षमता भी बेहतर होती है, और उसका दावा था कि "large language models का scaling task-agnostic few-shot performance को काफ़ी बढ़ाता है, जिससे वे कभी-kabhi पहले के state-of-the-art fine-tuning approach के साथ प्रतिस्पर्धा कर सकते हैं"
स्वतंत्र researcher Gwern Branwen ने एक blog post में scaling hypothesis गढ़ी और कहा:
- "मई 2020 में OpenAI द्वारा जारी GPT-3 अब तक train किए गए neural network में सबसे बड़ा है, और यह एक अंक के गुणक से भी बड़ा है... कई लोगों (मेरे सहित) की अपेक्षाओं के विपरीत, scale में यह विशाल वृद्धि OpenAI की भविष्यवाणी के अनुसार scale के लाभ दिखाती रही और यह उस diminishing return या negative return से नहीं टकराई जिसकी कई लोगों ने अपेक्षा की थी।"
Branwen ने जो आश्चर्य महसूस किया, वही परिदृश्य में बदलाव था
AI अब किसी कंपनी के product का परिशिष्ट भर नहीं था; इसे बढ़ते हुए core के रूप में इस्तेमाल किया जा सकता था
transformer architecture, बढ़ी हुई data quantity और बेहतर performance level—इन सबने AI-आधारित product development की नींव रखी
GPT-3 जारी होने के तुरंत बाद, मई 2020 में Writer और Jasper जैसी कंपनियों ने copywriting products बनाए जिनमें AI model बिज़नेस के केंद्र में था
Harvey और EvenUp जैसी कंपनियों ने AI को केंद्र में रखकर legal tech बनाया
DeepScribe और Freed जैसी कंपनियों ने AI-केंद्रित medical transcription बनाया
लेकिन जैसे अतीत में नए use case ने database के evolution को जन्म दिया था, वैसे ही AI-आधारित products के उदय का मतलब था कि हर कंपनी के tech stack के पीछे का infrastructure भी बदलना और अनुकूलित होना चाहिए

AI-Native Database

जैसे-जैसे AI-आधारित कंपनियों की संख्या और scale बढ़ा, AI-आधारित use case को support करने वाले tools की ज़रूरत भी बढ़ी
AI-core कंपनियों की पहली लहर मुख्य रूप से मौजूदा models के inference पर केंद्रित थी
- उनके पास application, copywriting, medical transcription आदि के लिए purpose-built workflow tools थे
- product का core model द्वारा generated output था, जैसे generated text या generated image
नवंबर 2023 में OpenAI के DevDay के बाद "OpenAI ruined my startup" वाला meme फैलने लगा
- specific expert GPT या AI agent मौजूदा models के inference पर केंद्रित थे, इसलिए वे शुरुआती AI-आधारित startup की भूमिका निभाते हुए दिखे
- OpenAI संयोगवश model और application दोनों का provider बन गया
model capabilities के इर्द-गिर्द innovation इतनी तेज़ी से बढ़ने लगी कि यह startups के लिए ख़तरे जैसी महसूस होने लगी
लेकिन दूसरी ओर, बेहतर performance वाले models—खासकर आसानी से उपलब्ध open source models—ने कंपनियों को AI-आधारित business के रूप में अपनी क्षमताएँ और गहराई से बनाने में सक्षम किया
AI-आधारित tech stack बनाना सिर्फ model के आसपास components जोड़ देने से अधिक है
- उदाहरण के लिए, AI के लिए विशेष रूप से बना database कैसा दिखेगा?
- अगर inference महत्वपूर्ण output है, तो AI-आधारित database को सिर्फ data store और retrieve ही नहीं करना चाहिए, बल्कि उसे इस बारे में contextual instructions लेने में भी सक्षम होना चाहिए कि संग्रहीत data पर कौन-सा काम करना है
एक उदाहरण e-commerce के लिए product description personalization हो सकता है
- vector database सिर्फ product SKU और description के vector embeddings ही नहीं, बल्कि user persona के embeddings भी store कर सकता है
- database में मौजूद इस contextual data का उपयोग करके infrastructure ऐसा generative feedback loop चला सकता है जिसमें product description के query के साथ संबंधित user persona का query भी trigger हो, और फिर उस प्रासंगिक user persona के आधार पर product description लिखा जाए
इसी तरह language को भी generative feedback loop के रूप में इस्तेमाल किया जा सकता है
- उदाहरण के लिए, user अलग-अलग भाषाओं में product description generate करना चाह सकता है
- system ऐसा description generate कर सकता है जो user के लिए personalized हो और user द्वारा चुनी गई भाषा में translated भी हो
- इस तरह के निर्देश database में सीधे embed किए जा सकते हैं, क्योंकि generative AI जैसे use case अब application की केंद्रीय functionality बनते जा रहे हैं
use case के अनुसार infrastructure को evolve करना कोई नई बात नहीं है
- शुरुआत में developers ने browser में application बनाकर website को interactive और dynamic बनाने के लिए JavaScript का उपयोग किया
- लेकिन जब developers ने समझा कि इसे backend में भी लाया जा सकता है, तब node.js पैदा हुआ
- फिर जैसे-जैसे developers ने अधिक mobile applications बनाना शुरू किया, वैसे-वैसे JSON (JavaScript Object Notation) उभरा, जिसने अधिक dynamic, responsive और data-driven applications को संभव बनाया
- MongoDB ऐसी company थी जो बदलती infrastructure आवश्यकताओं को हल करने के लिए उभरी, और यह इस लहर के लिए पूरी तरह उपयुक्त थी
AI के साथ इतिहास खुद को दोहरा रहा है
- requirements बदलने पर infrastructure को भी उन आवश्यकताओं को पूरा करने के लिए evolve होना होगा
- सबसे बड़ा सवाल यह होगा कि लोग किस तरह की कंपनियाँ बनाना चाहते हैं, और किस तरह का infrastructure उन कंपनियों के लिए सबसे उपयुक्त है
- जैसा Bob ने Matthew Lynley के साथ एक interview में कहा:
  - "मेरा दृढ़ विश्वास है कि भविष्य की हर application में AI होगा। कुछ applications में AI बस sprinkle किया जाएगा, और कुछ में AI application के केंद्र में होगा। AI को हटा दें तो वे रह ही नहीं जाएँगी। अगर आप एक web app बनाना चाहते हैं और उसके ऊपर AI sprinkle करना चाहते हैं, तो MongoDB का उपयोग करें। खासकर अगर आप पहले से इसका उपयोग कर रहे हैं... अगर आप ऐसा AI-native application बनाना चाहते हैं जिसमें AI application का core हो, तो Weaviate पर विचार करने का समय है।"
आगे चलकर कंपनियाँ तय करेंगी कि वे AI को एक appendix की तरह जोड़कर product बनाएँगी, या Bob के शब्दों में "sprinkle" करेंगी, या उसे product का core बनाएँगी

AI-Native तकनीकी स्टैक

जो कंपनियाँ AI को प्रोडक्ट के मुख्य घटक के रूप में बनाना चाहती हैं, उनके लिए मौजूदा इन्फ्रास्ट्रक्चर संभवतः उपयुक्त नहीं होगा
- legacy tools का उपयोग करने पर data storage, organization और execution एक silo में बनते हैं और automation दूसरे silo में बनता है
- इस approach की कमी यह है कि generative feedback loop जैसी चीज़ों में context खो जाता है, जबकि वही प्रोडक्ट को बेहतर ढंग से जानकारी देने और सुधारने में मदद कर सकता है
जो कंपनियाँ "AI-adjacent" stack से आती हैं, उनके मामले में किसी विशेष model का inference अक्सर context window तक सीमित होता है
- कुछ लोगों का मानना है कि यदि किसी दिए गए context window की क्षमता बढ़ जाए तो वह vector database की जगह ले सकती है
- लेकिन इसके उलट स्थिति, जिसमें vector database context window का विकल्प बनने की दिशा में विकसित हो, सच होने की संभावना अधिक है
- vector embedding generative model के लिए बहुत महत्वपूर्ण हैं, और generative output के लिए इन्फ्रास्ट्रक्चर को vector embedding को first-class citizen की तरह मानना चाहिए
सिर्फ context window का आकार बढ़ाने के बजाय, vector database को model में इस तरह जोड़ा जा सकता है कि context window की contextual understanding के साथ database की reliability और scalability भी मिले
- खासकर, model जितना अधिक general-purpose होगा, उतनी ही कम संभावना होगी कि वह किसी खास task के लिए बना हो
- AI-powered vector database अधिक विशिष्ट functionality संभव बनाएंगे
GPT-4 जैसे general-purpose model को जानबूझकर knowledge को सामान्यीकृत करने के लिए बनाया गया है
- यदि कोई product थोड़ी-सी simple fine-tuning पर निर्भर है, तो base model उस business का uniquely valuable हिस्सा नहीं बनेगा
- AI-आधारित product बनाना सिर्फ model का उपयोग करने से आगे की बात है; इसमें अधिक tightly connected stack के आसपास product बनाना शामिल होगा
- यह stack database के scale और model की capability प्रदान करके अधिक सक्षम product तैयार करेगा

1 टिप्पणियां

savvykang 2024-07-01

उम्मीद है कि vector embedding generation और vector DB के use case और ज़्यादा सामने आएँ, ताकि एक standard workflow बन सके। क्या इसके लिए लगभग 1 साल इंतज़ार करना पड़ेगा?