Vector Database: एक तकनीकी परिचय [PDF]
(tge-data-web.nyc3.digitaloceanspaces.com)- AI एप्लिकेशन जब असंरचित और उच्च-आयामी डेटा को संभालते हैं, तब vector database डेटा को संख्यात्मक array के रूप में स्टोर और सर्च करने वाली एक विशेष प्रणाली के रूप में महत्वपूर्ण हो जाते हैं
- इसका मूल विचार यह है कि पंक्तियों-स्तंभों या स्पष्ट संबंधों की बजाय, डेटा गुणों के बीच similarity के आधार पर रिकॉर्ड्स को जोड़ा जाए ताकि निहित अर्थ का उपयोग किया जा सके
- जब अर्थ-संबंधों को बहु-आयामी vector के रूप में encode किया जाता है, तब similarity search, clustering और classification जैसे विश्लेषण कार्य अधिक तेज़ी से किए जा सकते हैं
- generative AI में इनका उपयोग बड़े पैमाने के उच्च-आयामी डेटा को प्रबंधित करने और समान vector खोज के माध्यम से training और inference की गति तथा personalization परिणामों को बेहतर बनाने के लिए होता है
- उन्नत indexing, खोज के दायरे को उच्च-प्रासंगिकता वाले subset तक सीमित करके search time कम करती है, और similarity को अन्य शर्तों के साथ मिलाकर जटिल query को संभव बनाती है
Vector Database किस प्रकार का डेटा संभालते हैं
- vector database, उच्च-आयामी डेटा प्रतिनिधित्व यानी vector को स्टोर, मैनेज और प्रोसेस करने के लिए बना एक विशेष database है
- पारंपरिक database जहाँ डेटा को rows और columns में स्टोर करते हैं, वहीं vector database डेटा को बहु-आयामी space के vector के रूप में स्टोर करते हैं
- प्रत्येक vector, डेटा point की विशेषताओं या गुणों को दर्शाने वाला संख्यात्मक array होता है
अर्थ और similarity-आधारित कनेक्शन
- पारंपरिक database, तत्वों के बीच संबंध स्थापित करने के लिए स्पष्ट links या hierarchy का उपयोग करते हैं
- vector database, डेटा गुणों की similarity के आधार पर रिकॉर्ड्स को algorithmic तरीके से जोड़ते हैं
- यह तरीका database के तत्वों में मौजूद निहित अर्थ के आधार पर अधिक सहज कनेक्शन बना सकता है
विश्लेषणात्मक query के लिए अनुकूल संरचना
- जब डेटा को अर्थ-संबंधों को दर्शाने वाले बहु-आयामी vector, यानी संख्यात्मक array, के रूप में encode किया जाता है, तब उन्नत विश्लेषणात्मक कार्य तेज़ी से किए जा सकते हैं
- समर्थित कार्यों में similarity search, clustering और classification शामिल हैं
- यह computational model pattern detection, predictive analytics और उच्च विश्लेषणात्मक मांग वाले एप्लिकेशन के लिए उपयुक्त है
AI और generative AI में उपयोग
- AI और machine learning का प्रसार, vector database की बढ़ती मांग की प्रमुख पृष्ठभूमि है
- generative AI क्षेत्र में vector database को बड़े पैमाने के उच्च-आयामी डेटा को कुशलता से स्टोर और मैनेज करने के लिए डिज़ाइन किया गया है
- समान vector को तेज़ी से खोजकर परिणाम वापस लाने की क्षमता, generative AI मॉडल की training और inference प्रक्रिया को काफी तेज़ बना सकती है
- इनका उपयोग generative AI सिस्टम को उपयोगकर्ताओं के लिए अधिक personalized और प्रासंगिक content देने में भी किया जाता है
indexing और जटिल search conditions
- vector database उन्नत indexing तकनीकों के ज़रिए समान vector को तेज़ी से खोजते और retrieve करते हैं
- index, खोज के दायरे को छोटे और अधिक प्रासंगिक vector subset तक सीमित करके search time को काफ़ी घटा देता है
- ये जटिल query भी संभाल सकते हैं जो similarity conditions को अन्य search criteria के साथ जोड़ती हैं
- ऐसी लचीलापन, उन्नत AI एप्लिकेशन में महत्वपूर्ण है जहाँ परिष्कृत search capabilities की आवश्यकता होती है
1 टिप्पणियां
Hacker News राय
A Comprehensive Survey on Vector Database: Storage and Retrieval Technique, Challenge: https://arxiv.org/abs/2310.11703
Survey of Vector Database Management Systems: https://arxiv.org/abs/2310.14021
What are Embeddings: https://raw.githubusercontent.com/veekaybee/what_are_embeddi...
स्रोत का श्रेय: https://twitter.com/eatonphil/status/1745524630624862314 और https://twitter.com/ChristophMolnar/status/17457316026829826...
यह annotations वाली presentation सामग्री और वैकल्पिक 38 मिनट के वीडियो के रूप में भी उपलब्ध है
Wikipedia लेख: https://en.wikipedia.org/wiki/Vector_database
Vector Database 101: https://zilliz.com/learn/introduction-to-unstructured-data
Approximate nearest neighbor और similarity search: https://vinija.ai/concepts/ann-similarity-search/
Distributed databases: https://15445.courses.cs.cmu.edu/fall2021/notes/21-distribut...
यह हिस्सा मुझे भी जानना था, इसलिए अगर कोई criteria या rule of thumb हो तो अच्छा होगा
हाल ही में Simon Willison के बेहतरीन
llmtool के साथ embeddings पर काम किया, और उसका approach सबसे सरल है: distance calculation के लिए कुछ UDFs के साथ embeddings को SQLite में store करनायह simplicity आकर्षक है, लेकिन traffic और data एक निश्चित level से ऊपर जाएँ तो शायद ज्यादा specialized database की जरूरत पड़ेगी; वह सीमा कहाँ के आसपास है, इसका अंदाज़ जानना चाहूँगा/चाहूँगी
Search सबसे सरल तरीके से सब कुछ scan करके और Hamming distance (
xorऔरpopcount) से compare करके किया था; 2011 के MBP के single core पर 200,000 hashes को 10ms से कम में scan करके सबसे मिलती-जुलती item ढूंढ सकता थायह लगभग 1,000 lines का code था, इसलिए आखिरकार external vector database की जरूरत नहीं पड़ी
लेकिन उससे आगे Pinecone जैसे ठीक-ठाक options जटिल, धीमे और हास्यास्पद रूप से महंगे हो जाते हैं
मेरी जानकारी में सबसे बेहतर option turbopuffer.com है; यह Pinecone से लगभग 100 गुना सस्ता है और सच में scale होता हुआ दिखता है
Slides की recommended vector DB list में यह नहीं था, इसलिए इसे एक अच्छी recommendation के तौर पर डाल रहा/रही हूँ
https://news.ycombinator.com/item?id=38703943
इस lecture में vectors, vector databases, indexing और similarity search के basic concepts को theory और demo के mix के रूप में cover किया गया, और अंत में Pinecone और Weaviate databases के demo के साथ खत्म होता है
इस stage पर human judgment बहुत subtle तरीके से, कभी-कभी लगभग नज़रअंदाज़ होने लायक मात्रा में, शामिल होता है, लेकिन बाहर से यह बहुत automated “बस mathematics” system जैसा दिखने लगता है
Audio को उदाहरण के तौर पर लें: N-dimensional vector बनाने के लिए कौन-सी features निकाली जाएँगी? आसान जवाब हो सकता है, “जितनी संभव हों उतनी”
लेकिन पहली बात, जिन features को आसानी से नाम दिया जा सकता है, उनके लिए भी featureization data तक access नहीं हो सकता
दूसरी बात, अगर domain knowledge गहरी नहीं है, तो आपको उन latent features के अस्तित्व का भी पता नहीं हो सकता जिन्हें इस्तेमाल करना चाहिए
तीसरी बात, domain knowledge गहरी होने पर भी आपको फिर भी उन latent features का पता नहीं हो सकता जिन्हें इस्तेमाल करना चाहिए
उदाहरण के लिए मान लें कि आप Reich-style phase-shifting minimalist music के fan हैं। इस genre के representative piece, जैसे Piano Phase, जैसी music खोजने के लिए आप vector database से indirect query करते हैं
Database dominant frequency, note onset interval, volume, frequency distribution-based timbre features, apparent root note और scale जैसी कई audio/music features का इस्तेमाल करता है
लेकिन अगर डेटाबेस के feature set में “समय के साथ सुरों के बीच का अंतराल स्थिर रहता है” शामिल नहीं है, तो query timbre, harmony, melody और rhythm में मिलती-जुलती चीज़ें तो ढूँढ सकती है, लेकिन मुख्य विशेषता—दो melodic lines का relative phase लगातार बदलना—साझा करने वाले गाने ढूँढना पूरी तरह किस्मत पर छोड़ देगी
visual, text, numeric आदि किसी भी डेटा के लिए ऐसे मिलते-जुलते उदाहरण बनाना मुश्किल नहीं है
बेशक, इसका मतलब यह नहीं है कि vector databases और feature classification बेकार हैं
किसी खास dataset में matching patterns मिलते हैं या नहीं, शुरुआत में पूछे जाने वाले सवालों में से एक यह होना चाहिए कि क्या feature set के complete होने की मजबूत guarantee है, और अगर नहीं, तो उसे कैसे expand करना है
vector database search और search results retrieval के लिए बने होते हैं
आम तौर पर vectors बनाने का तरीका बड़े pretrained model को fine-tune करना और उसकी internal representations निकालना होता है
dataset में successful queries और retrieved results होते हैं, इसलिए raw input का इस्तेमाल करके vector database जिस similarity objective को support करता है, उसके लिए loss function optimize किया जा सकता है
tables, text, images, audio जैसी common modalities में feature selection में human judgment लगभग नहीं लगता; बस attention apply कर दिया जाता है
संदर्भ के लिए, E5-Mistral जैसे latest text-to-vector models को dataset में human curation तक की जरूरत नहीं होती
“जो नहीं जानते, वह भी नहीं जानते” वाली बात आपने सही पकड़ी
एक और Steve Reich fan देखकर अच्छा लगा, और मुझे यह जानने की उत्सुकता है कि मेरी पसंदीदा Music for 18 Musicians जैसी कौन-सी रचनाएँ recommend होंगी
overview शानदार है, लेकिन आखिरी section Postgres+pgvector जैसे vector store और Pinecone जैसे vector database में से क्या इस्तेमाल करना है, इस obvious सवाल को address नहीं करता
query speed, insertion/index build speed, ease of use जैसी trade-offs पर चर्चा करके हर application के लिए सही choice करने में मदद करने वाली presentations और देखना चाहूँगा
PR हमेशा welcome हैं
database असल में storage पर तरह-तरह की सुविधाएँ जुड़ी हुई चीज़ है
digitaloceanspaces.com एक S3-style hosting provider है, इसलिए अच्छा होगा अगर Hacker News इसे special-case करके domain को सिर्फ digitaloceanspaces.com दिखाने के बजाय tge-data-web.nyc3.digitaloceanspaces.com जैसे रूप में दिखाए
हालांकि S3 में भी यही समस्या दिखती है: https://news.ycombinator.com/item?id=38876761
दूसरी जगहों पर precedent है। x.github.io subdomain sites को यहाँ special-case किया जाता है: https://news.ycombinator.com/from?site=lfranke.github.io
यह material engineers के लिए starting point के रूप में काफी risky लगता है
semantic आधार पर clustering होती है या analytics के लिए optimized है—ऐसी phrasing संदिग्ध है
clustering computed embeddings पर निर्भर करती है। अगर आप मानते हैं कि embeddings डेटा के meaning का अच्छा approximation हैं, तो इस तरह सोचना ठीक हो सकता है
लेकिन ऐसी embeddings की कल्पना करना आसान है जो इसे तोड़ दें। उदाहरण के लिए, समान meaning वाली audio file और text file को उसी embedding process में डालें, तो अगर वह multimodal नहीं है तो embedding vector space में वे काफी दूर होने की संभावना है
आगे चलकर semantic similarity से ज्यादा usage pattern के आधार पर vector space में पास रखने वाली embeddings भी निश्चित रूप से आएँगी, ऐसा मुझे लगता है
अगर recommendation system बना रहे हैं, तो आप one-time purchase के कई variants को पास-पास group नहीं करना चाहेंगे
उदाहरण के लिए, semantically सबसे मिलती-जुलती flights उसी destination की अलग time-slot वाली flights या पास के airport की flights होंगी, लेकिन असल में आप उन flights को खरीदने वाले लोगों द्वारा अक्सर साथ खरीदे गए hotels को group करना चाह सकते हैं
vector database डेटा में time awareness जैसे extra dimensions भी डाल सकता है। meaning encode करने वाले vectors का इस्तेमाल करना जरूरी नहीं है
इसलिए vector database input vectors पर आधारित lookup या search के लिए optimized होते हैं, OLAP queries जैसे नहीं
यह Snowflake से ज्यादा Elasticsearch के करीब है। अगर आप vector space पर reporting या large-scale analytics की उम्मीद में vector database इस्तेमाल कर रहे हैं, तो मेरी जानकारी में फिलहाल इस्तेमाल लायक कोई product नहीं है
apple की photo से “apple-ness” दिखाने वाले vector तक जाना, और उस vector को सामान्य math से दूसरे vectors के साथ compare करना मैं समझता हूँ
जो समझ नहीं आता वह यह है कि कौन/क्या image को input के रूप में लेकर vector output करता है
documents के लिए भी यही बात है। अगर मैं array में एक number और जोड़ने की तरह dimension add करना चाहूँ, तो vector database के किस हिस्से को modify करना होगा ताकि वह dimension vector calculation में शामिल हो?
या document, image, कुछ भी हो—उसे vector representation में बदलने की प्रक्रिया database के बाहर किसी और तरीके से होती है?
edit: embedding computation machine learning algorithm का काम लगता है, लेकिन फिर उस algorithm को भी पहले train करना होगा। यानी आखिर में यह अंतहीन training तक पहुँचता है
समझ नहीं आता कि PQ को “indexing strategy” के रूप में क्यों list किया गया है
PQ vector compression/quantization technique है, search space को partition करने का तरीका नहीं
exhaustive search/flat index, IVF index, HNSW में PQ से vectors encode किए जा सकते हैं, और Faiss में ये क्रमशः IndexPQ, IndexIVFPQ, IndexHNSWPQ के रूप में मौजूद हैं
चाहें तो इसे k-D tree या ANNOY के साथ भी इस्तेमाल कर सकते हैं
“जब query speed precision से ज्यादा important हो तो बहुत बड़े datasets के लिए HNSW या Annoy इस्तेमाल करें” कहना भी problematic है
graph-based techniques में memory overhead और build cost ज्यादा होती है, और billion-scale datasets के लिए practical नहीं हैं
आम तौर पर ये IVF techniques से ज्यादा accurate और fast होती हैं, क्योंकि similar accuracy पाने के लिए IVF को बहुत सारे cells visit करने पड़ते हैं
दूसरी तरफ IVF अन्य techniques के विपरीत, बड़े overhead के बिना trillion-scale databases तक scale कर सकता है और फिर भी reasonable speed/accuracy trade-off देता है
मैं कहूँगा, “जब query speed important हो लेकिन high accuracy भी चाहिए, और flat/exhaustive index impractical हो, ऐसे medium-scale datasets के लिए इस्तेमाल करें”
पहले PQ करें, फिर नए discrete vectors पर KNN चलाएँ
इससे vocabulary space को fixed size में compress किया जा सकता है
स्लाइड 15 की तालिका में Traditional Databases और Vector Databases के Indexing & Search Efficiency वाले कॉलम आपस में बदले हुए लगते हैं
क्या SQLite की तरह कोई embedded embedding database की सिफारिश है?
छोटे पैमाने की समस्याओं के लिए है, लेकिन LMDB + FAISS से ज़्यादा सुविधाजनक हो तो अच्छा होगा
इसे Python process के अंदर चलाया जा सकता है, content SQLite में store होता है और embedding vectors को local vector index formats (Faiss, HNSW, Annoy) में store करने की capability support करता है
संदर्भ के लिए, मैं txtai का मुख्य author हूँ
https://github.com/patricktrainer/hackernews-comment-search
llmtool सिर्फ SQLite और कुछ UDFs का इस्तेमाल करता हैउसकी simplicity आकर्षक है, लेकिन कब और क्यों वह पर्याप्त नहीं रहती, इसका मुझे ठीक अंदाज़ा नहीं है
Go के लिए, हाल ही में Chroma interface से प्रेरित होकर मैंने chromem-go बनाना शुरू किया है: https://github.com/philippgille/chromem-go
इसमें अभी advanced features या बड़े scale के use cases नहीं हैं, लेकिन RAG demo काम करता है
[1] https://github.com/chroma-core/chroma