वेक्टर डेटाबेस एक गलत abstraction हैं

 (timescale.com)
11 पॉइंट द्वारा GN⁺ 2024-10-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AI applications बनाने की कोशिश कर रही engineering teams को परेशान करने वाला संदेश: "embeddings दोबारा sync नहीं हुए हैं"
  • एक साधारण vector search implementation monitoring, synchronization और troubleshooting की जटिल orchestration में बदल जाती है
  • vector databases के साथ AI systems बना रही engineering teams से बात करने पर पता चला कि vector databases का abstraction गलत है और आज उन्हें जिस तरह इस्तेमाल किया जा रहा है, उसमें खामियां हैं

"RAG system बनाने का एक आम मामला"

  • embeddings को store और retrieve करने के लिए Pinecone को vector database के रूप में इस्तेमाल किया जाता है
  • text data Pinecone के metadata में ठीक से fit नहीं होता, इसलिए blobs और application data को संभालने के लिए DynamoDB का इस्तेमाल किया जाता है
  • lexical search के लिए OpenSearch की जरूरत पड़ी
  • अब 3 systems को जोड़ना और sync में रखना एक nightmare है

source documents को delete करते समय यह करना पड़ता है:

  1. DynamoDB से record हटाने के लिए boto3 चलाएं
  2. Pinecone को update करें ताकि embeddings delete होना सुनिश्चित हो
  3. lexical search index को update करने के लिए POST request भेजें
  • source documents में हर update, addition या deletion पर यह करना पड़ता है
  • configuration management सिर्फ messy नहीं बल्कि risky भी है
  • कुछ teams ने ऐसे indexes के लिए हर महीने $2,000 चुकाए जिन्हें 4 महीने पहले delete हो जाना चाहिए था
  • users को गलत या पुराना data लौटाने का जोखिम रहता है

vector databases एक गलत abstraction पर बने हैं

  • vector databases embeddings को derived data के बजाय independent data की तरह treat करते हैं
  • embeddings को independent data की तरह treat करना अनावश्यक complexity पैदा करता है

एक बेहतर तरीका: "Vectorizer" abstraction

  • एक "vectorizer" abstraction का प्रस्ताव है, जो embeddings को database index की तरह treat करता है
  • यह approach embeddings को source data के साथ automatically sync में रखती है और maintenance cost हटा देती है
  • CREATE INDEX command के समकक्ष vectorizer ऐसा दिखता है:
SELECT ai.create_vectorizer(
    'public.blogs'::regclass,
    embedding => ai.embedding_openai('text-embedding-3-small', 1536),
    chunking => ai.chunking_recursive_character_text_splitter('content')
);
  • यह command blog table की सभी entries के लिए embeddings बनाती है और table का data बदलने पर embeddings को update करती रहती है

vector databases (और vector data types) की समस्या

  • vector databases को text, image और multimodal data के लिए बड़ी मात्रा में vector embeddings संभालने हेतु विकसित किया गया था
  • PostgreSQL, MySQL, MongoDB, Oracle जैसे general-purpose databases ने भी vector search support जोड़ लिया है
  • लेकिन standalone systems या existing databases में जोड़े गए vector search feature का abstraction एक घातक flaw रखता है
  • database में embedding insert होते ही embedded unstructured data और vector embedding के बीच का संबंध टूट जाता है
  • इस संबंध के बिना embeddings को derived data के बजाय गलत तरीके से independent data atoms की तरह treat किया जाता है, जिन्हें developers को manage करना पड़ता है
  • embeddings को derived data के रूप में फिर से देखने पर साफ दिखता है कि मौजूदा vector database abstraction कितना बेतुका है, क्योंकि embeddings source data से जुड़ी नहीं रहतीं

development teams को यह सब manage करना पड़ता है:

  • complex ETL (extract-load-transform) pipelines

  • embeddings के लिए vector database, metadata और app data के लिए दूसरा database, और lexical search index

  • data synchronization services

  • updates और synchronization के लिए queueing systems

  • data drift पकड़ने और embedding service rate limits जैसी चीजें संभालने के लिए monitoring tools

  • जब search पुराने results लौटाए तब alerting systems

  • सभी systems के लिए validation checks

  • नए embedding model पर upgrade करने या दूसरी chunking method आज़माने के लिए custom code लिखना पड़ता है और कई data services व databases में changes coordinate करने पड़ते हैं

  • इससे development teams पर यह बोझ पड़ता है कि source data बदलने पर embeddings समय पर generate हों

  • नहीं तो embeddings अक्सर stale हो जाते हैं और users को खराब application experience मिलने का जोखिम बढ़ता है

एक बेहतर तरीका: database को complexity संभालने दें

  • embeddings को derived data के रूप में फिर से परिभाषित करने से base data बदलने पर embeddings generate और update करने की जिम्मेदारी database management system को दी जा सकती है
  • इस बदलाव से developers को embeddings को source data के साथ manually sync में रखने के बोझ से मुक्ति मिलती है
  • RAG के लिए one-time data import करने वाले simple applications में यह फर्क उतना महत्वपूर्ण नहीं लग सकता
  • लेकिन अधिकतर वास्तविक applications में data लगातार बदलता रहता है
  • उन ecommerce platforms या product assistant RAG apps के बारे में सोचें जो embedding-based semantic search का इस्तेमाल करते हैं और जिन्हें नई product information के साथ up to date रहना होता है
  • इन changes को manually track करना और embeddings फिर से generate करना न सिर्फ labor-intensive और error-prone है, बल्कि developers को core business goals पर focus करने से भी रोकता है
  • जब database system इसे अपने आप संभाल सकता है, तो developer time क्यों बर्बाद करें?

vectorizer: index के रूप में vector embeddings

  • vector embeddings को independent tables या data types के बजाय embedded data के लिए एक special index के रूप में सोचना ज्यादा प्रभावी abstraction है
  • vector embeddings पारंपरिक अर्थ में index नहीं हैं
  • बल्कि वे embeddings के आधार पर data के सबसे relevant हिस्सों को retrieve करने वाले indexing mechanism की तरह काम करते हैं
  • इस नए index-जैसे abstraction को हम "vectorizer" कह सकते हैं

vectorizer abstraction के मुख्य फायदे:

automatic synchronization

  • database indexing का एक बड़ा फायदा यह है कि base data और index अपने आप sync में बने रहते हैं
  • column का data बदलते ही index उसी के अनुसार update हो जाता है
  • vector embeddings को indexing के एक रूप की तरह treat करके यही automatic synchronization हासिल किया जा सकता है
  • system यह सुनिश्चित करता है कि vector embeddings हमेशा ताज़ा data के साथ up to date रहें, जिससे manual updates की जरूरत खत्म होती है और errors का risk घटता है

मजबूत data-embedding संबंध

  • जब vectors को अलग से store किया जाता है, तो उनका original data से संबंध खोना आसान हो जाता है
  • क्या यह vector data के हालिया update से बना है? या किसी पुराने embedding model का stale vector है?
  • ये सवाल महत्वपूर्ण हैं, और यहां भ्रम होने पर गंभीर errors हो सकते हैं
  • vector embeddings को index की तरह सीधे data से जोड़ने पर यह संबंध स्पष्ट रहता है और automatically maintain होता है

सरल data management

  • developers को data synchronization manually manage करते समय अक्सर कठिनाइयों का सामना करना पड़ता है
  • उदाहरण के लिए, base data delete होने पर अगर पुराने embedding model का data हटाना भूल जाएं, तो inconsistencies पैदा हो सकती हैं
  • vectorizer abstraction इन संबंधों को manage करने की जिम्मेदारी system की बना देता है, जिससे developers का cognitive load कम होता है और mistakes की संभावना घटती है

vectorizer core DBMS promise का स्वाभाविक evolution है

  • vectorizer का विचार modern database management systems (DBMS) की क्षमताओं का एक natural evolution है
  • आज के DBMS declarative structures जैसे indexes, triggers और materialized views के जरिए data transformation और synchronization manage करने में पहले से सक्षम हैं
  • vectorizer abstraction इस paradigm में अच्छी तरह fit बैठता है, क्योंकि यह vector embedding management के लगातार महत्वपूर्ण होते जा रहे काम के लिए नया tool देता है
  • इस capability को सीधे DBMS में शामिल करके हम database systems के अंतिम वादे को साकार करने के और करीब पहुंचते हैं
  • यानी data को इस तरह manage करना कि complexity abstract हो जाए और users application building, data analysis और innovation driving जैसे अपने सबसे अच्छे काम पर focus कर सकें

PostgreSQL के लिए vectorizer implementation: pgai Vectorizer

  • developers का बोझ कम करने के वादे से प्रेरित होकर Timescale की AI engineering team ने PostgreSQL के लिए vectorizer implement किया है
  • इसका नाम pgai Vectorizer है और यह फिलहाल Early Access में है
  • यह PGAI project का हिस्सा है, जिसका लक्ष्य PostgreSQL को AI systems के लिए ज्यादा उपयुक्त बनाना और PostgreSQL से परिचित developers के लिए AI development आसान करना है
  • PostgreSQL के data के लिए pgai Vectorizer कैसे automatically vector embeddings generate और update करता है, यह देखने के लिए demo video देखें

pgai Vectorizer कैसे काम करता है

  • vectorizer को SQL में define और create किया जाता है
  • नीचे दिया गया query vectorizer बनाता है और यह specify करता है कि वह किस table पर काम करेगा, कौन से columns को vectorize करेगा, कौन सा embedding model इस्तेमाल होगा, और embedding होने वाले source data में कौन सी अतिरिक्त जानकारी शामिल होगी
-- blogs table के data को automatically embed करने वाला vectorizer बनाएं
SELECT ai.create_vectorizer(
   'public.blogs'::regclass
   -- OpenAI text-embedding-3-small model का उपयोग
 , embedding=>ai.embedding_openai('text-embedding-3-small', 1536, api_key_name=>'OPENAI_API_KEY')
   -- table में 100k rows होने पर StreamingDiskANN index अपने आप बनाएं
 , indexing => ai.indexing_diskann(min_rows => 100000, storage_layout => 'memory_optimized'),
   -- content column पर recursive chunking लागू करें
 , chunking=>ai.chunking_recursive_character_text_splitter('content')
   -- बेहतर search के लिए दूसरे columns का metadata embedding में जोड़ें
 , formatting=>ai.formatting_python_template('Blog title: $title url: $url blog chunk: $chunk')
);
-- source table बदलने पर vectorizer embeddings update करता है
-- किसी और user action की जरूरत नहीं
  • साथ ही लंबे text को embedding model की token limits के अनुरूप कई छोटे chunks में बांटना पड़ता है, इसलिए basic chunking functions भी define किए गए हैं

source data changes को track करना

  • pgai Vectorizer अंदरूनी तौर पर source table में हुए modifications (insert, update, delete) को देखता है और vector embeddings को asynchronously generate व update करता है
  • pgai Vectorizer को दो deployment types के लिए बनाया गया है: self-hosted और Timescale Cloud पर fully managed
  • pgai Vectorizer के cloud-hosted implementation में embedding generation के लिए Timescale Cloud platform की cloud capabilities का इस्तेमाल होता है
  • pgai Vectorizer के open source version में embeddings generate करने के लिए external worker चलाया जाता है
  • pgai Vectorizer configuration और catalog information को database के अंदर मुख्य internal bookkeeping data के साथ store करता है

embeddings वास्तव में कहां generate होते हैं?

  • actual embedding process database के बाहर एक external process में होता है
  • इसका मतलब है कि database server पर load कम रहता है और vectorizer, application queries संभालने की database की क्षमता को प्रभावित नहीं करता
  • इससे embedding work को दूसरी database activities से स्वतंत्र रूप से scale करना भी आसान हो जाता है
  • यह process पहले database को पढ़कर देखता है कि कोई काम लंबित है या नहीं
  • अगर है, तो यह database से data पढ़ता है, chunking और formatting करता है, OpenAI जैसे embedding model provider को call करके embeddings बनाता है, और result को वापस database में लिख देता है

process customization

  • pgai Vectorizer flexible है: embeddings बनाने के लिए इस्तेमाल होने वाले chunking और formatting rules specify किए जा सकते हैं
  • खास तौर पर, source table के कौन से columns vectorize करने हैं, और ऐसे कौन से chunking व formatting rules होंगे जिनसे source data embedding token limits के भीतर रहे और relevant data हर embedding में शामिल हो, यह configure किया जा सकता है
  • pgai Vectorizer की Early Access release में OpenAI embedding model selection, text को छोटे chunks में बांटने की chunking strategy, हर chunk में अतिरिक्त context inject करने के formatting options, और automatic index creation व performance tuning के लिए custom indexing configuration को customize किया जा सकता है
  • जल्द ही इसे और flexible बनाने के लिए users को अपना Python code submit करने की सुविधा देने की योजना है, ताकि वे chunking, embedding और formatting को पूरी तरह customize कर सकें

उदाहरण के लिए, नीचे दिया गया vectorizer HTML source files को recursively split करने और source data से OpenAI embeddings बनाने के लिए configured है। code, documentation, markdown आदि जैसे application data के अनुसार chunking और formatting configure किए जा सकते हैं

-- उन्नत vectorizer configuration
SELECT ai.create_vectorizer(
   'public.blogs'::regclass,
   destination => 'blogs_embedding_recursive',
   embedding => ai.embedding_openai('text-embedding-3-small', 1536),
   -- HTML content के लिए दिए गए settings के साथ recursive chunking लागू करें
   chunking => ai.chunking_recursive_character_text_splitter(
       'content',
       chunk_size => 800,
       chunk_overlap => 400,
       -- HTML-aware separators, highest priority से lowest तक
       separator => array[
           E'

', -- मुख्य document sections पर split करें
           E'

',    -- div boundaries पर split करें
           E'

',
           E'

',      -- paragraphs पर split करें
           E'
',      -- line breaks पर split करें
           E'
',     -- list items पर split करें
           E'. ',        -- fallback के रूप में sentence boundaries
           ' '          -- अंतिम उपाय: spaces पर split करें
       ]
   ),
   formatting => ai.formatting_python_template('title: $title url: $url $chunk')
);

GN⁺ की राय

  • pgai Vectorizer एक शक्तिशाली और नवोन्मेषी tool लगता है, जो embedding management को काफी सरल बना सकता है। vectorizer abstraction developers पर embeddings को manually manage करने का बोझ कम करता है और यह सुनिश्चित करता है कि embeddings source data के साथ sync में रहें।
  • खासकर embedding model upgrade करने या chunking strategy बदलने जैसे बदलाव लागू करते समय यह बहुत उपयोगी लग सकता है। पारंपरिक vector databases में ऐसे बदलाव कई systems में custom code लिखने और changes coordinate करने की जटिल प्रक्रिया पैदा कर सकते हैं, लेकिन pgai Vectorizer में सिर्फ vectorizer configuration update करना काफी हो सकता है।
  • PostgreSQL जैसे general-purpose database में embeddings manage करने से कई specialized systems को orchestrate करने की समस्या से भी बचा जा सकता है। इससे application development काफी सरल हो सकता है।
  • एक बात ध्यान देने योग्य है कि actual embeddings एक external Python process में generate होते हैं। यह database performance पर असर न पड़े, इसके लिए अच्छा design choice है, लेकिन इसका मतलब यह भी है कि embedding generation process को अलग से monitor और manage करना होगा।
  • अंततः, pgai Vectorizer AI applications के लिए embeddings manage करने के तरीके में एक महत्वपूर्ण प्रगति दिखाता है। जैसे-जैसे अधिक teams इसे अपनाएंगी और feedback देंगी, उम्मीद है कि यह शक्तिशाली tool और विकसित होगा। Postgres जैसे परिचित tools में embedding management को integrate करने से अधिक developers advanced AI capabilities का लाभ उठा सकेंगे।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-10-30
Hacker News राय

  • डेटा सिंक्रोनाइज़ेशन के ओवरहेड को बढ़ा-चढ़ाकर आंका जा रहा है, और अधिकांश embedding-आधारित workflows में updates या deletes बहुत ज़्यादा नहीं होते। छोटे डेटा सेट्स में भी consistency समस्याओं को पहचानना मुश्किल होता है। फिर भी, डेटा सिंक्रोनाइज़ेशन की चिंता न होना अब भी शानदार है

    • Postgres डेटाबेस में embeddings स्टोर करने का सबसे बड़ा नुकसान यह है कि workload बहुत अलग होता है। HNSW index बहुत resources खर्च करता है और resource contention की समस्या पैदा कर सकता है। डेटाबेस को migrate करने पर consistency समस्या फिर से आ जाती है
    • filtering के साथ इसकी interaction को लेकर सवाल है। partial indexes का उपयोग किया जा सकता है या नहीं, और क्या pgvector के HNSW implementation की limitations अब भी मौजूद हैं, यह जानने की जिज्ञासा है

  • Elastic के एक कर्मचारी के रूप में, यह बताया गया है कि Elasticsearch ने हाल ही में semantic_text नाम का एक data type जोड़ा है। यह text को अपने-आप chunks में बांटता है और embeddings की गणना करके स्टोर करता है। queries भी सरल हो जाती हैं, जिससे I/O कम होता है और client code आसान बनता है

  • PostgreSQL tool का परिचय देते हुए, vector embeddings को database index के रूप में फिर से सोचने की बात कही गई है। अभी केवल OpenAI समर्थित है, लेकिन जल्द ही local और OSS models के support की योजना है। feedback और प्रतिक्रियाओं की उम्मीद है

  • FAISS को एक single database की तरह उपयोग करने पर सवाल उठाया गया है। यह vector embeddings के लिए sqlite जैसा है, और metadata व vectors को साथ में स्टोर करके relationships बनाए रख सकता है

  • Postgres में vectors उपयोग करने को लेकर सकारात्मक राय है, और SQL query में vector search व logic शामिल होने पर filtering order को लेकर सवाल उठाया गया है। pg_vector का DX पसंद है, लेकिन vector search के बाद filtering speed को धीमा कर सकती है

  • यह कहा गया है कि raw embeddings को vector database में स्टोर करना ऐसा है जैसे text के raw n-grams को database में स्टोर करना। documents को स्टोर करना अधिक उचित है

  • SQLite में sqlite-vec और FTS5 का उपयोग किया जा रहा है, और इसे बहुत उपयोगी बताया गया है

  • Node.js में PostgreSQL ORM बनाया गया है ताकि vector fields सहित code लिखा जा सके। इससे data या embedding content को query किया जा सकता है, और यह परिभाषित किया जा सकता है कि model के fields को embeddings के रूप में कैसे स्टोर किया जाए

  • Materialized Views को अच्छा बताया गया है

  • यह कहा गया है कि character-आधारित chunks का उपयोग करने वाले AI apps PoC चरण से आगे नहीं बढ़े हैं