SQLite के लिए नया वेक्टर सर्च एक्सटेंशन sqlite-vec विकसित हो रहा है

 (alexgarcia.xyz)
3 पॉइंट द्वारा GN⁺ 2024-05-04 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • मौजूदा sqlite-vss की सीमाओं को कम करने के लिए sqlite-vec को pure C आधारित embedded vector search extension के रूप में विकसित किया जा रहा है, और इसका लक्ष्य उन सभी environments को कवर करना है जहाँ SQLite चलता है
  • SQL usage flow को CREATE VIRTUAL TABLE, INSERT INTO, SELECT के इर्द-गिर्द सरल बनाया गया है, और यह KNN-style search के साथ JSON और compact binary vector input को support करता है
  • Faiss dependency हटाकर यह Linux, macOS के साथ-साथ Windows, WebAssembly, mobile और Raspberry Pi तक को target करता है, और binary size भी मौजूदा 3MB~5MB से छोटा, कुछ सौ KB के स्तर का अपेक्षित है
  • vectors को shadow table में chunk units में store करके पूरे data को RAM में load करने की जरूरत घटाई जाती है, और PRAGMA mmap_size से memory-based search speed बढ़ाई जा सकती है
  • शुरुआती version केवल exhaustive full-scan देगा, ANN शामिल नहीं होगा, और sqlite-vec.c के 246 TODO पूरे होने के बाद v0.1.0 release planned है

sqlite-vec SQLite vector search में क्या बदलना चाहता है

  • sqlite-vec pure C में लिखा जा रहा नया SQLite extension है, और यह फरवरी 2023 में जारी sqlite-vss को replace करने वाला project है
  • लक्ष्य scope में तेज vector search के लिए user-defined SQL functions, virtual tables, और vector operations के tools व utilities शामिल हैं
    • quantization
    • JSON/BLOB/numpy conversion
    • vector arithmetic
  • users सिर्फ pure SQL से vector store बना और search कर सकते हैं
    • CREATE VIRTUAL TABLE से vectors के लिए virtual table बनाना
    • INSERT INTO से vectors insert करना
    • SELECT ... WHERE sample_embedding MATCH ... ORDER BY distance LIMIT ... format में KNN-style search
  • vector input के लिए JSON string या compact binary format इस्तेमाल किया जा सकता है

Pure C और dependency-free design से खुलने वाले runtime environments

  • sqlite-vec का लक्ष्य dependency-free pure C extension होना है, और यही choice supported platforms को बढ़ाने की मुख्य शर्त है
  • मौजूदा sqlite-vss C++ dependencies की वजह से केवल Linux और macOS पर ही reliably चलता था, और binary size 3MB~5MB range में था
  • नया extension इन environments में चलने का लक्ष्य रखता है
    • Linux
    • macOS
    • Windows
    • browser में WebAssembly
    • mobile devices
    • Raspberry Pi जैसे छोटे devices
  • expected binary size कुछ सौ KB range में है

Memory usage और search speed control

  • sqlite-vec vectors को shadow table के अंदर chunks में बाँटकर store करने के तरीके से memory usage control करता है
    • KNN search के समय सभी vectors को एक साथ RAM में load नहीं करता, बल्कि chunk by chunk पढ़ता है
    • पूरे vectors को memory में resident रखना जरूरी नहीं होता
  • अगर memory-based speed चाहिए, तो SQLite के PRAGMA mmap_size का इस्तेमाल करके KNN search को और तेज बनाया जा सकता है

नई vector capabilities और शुरुआती सीमाएँ

  • sqlite-vec हालिया vector search tools और research trends को reflect करते हुए नीचे की capabilities को बेहतर support करना चाहता है
  • ये capabilities vectors की speed, accuracy, disk usage को अधिक fine-grained तरीके से control करने की foundation हैं
  • शुरुआती sqlite-vec केवल exhaustive full-scan vector search support करेगा
    • “approximate nearest neighbors” option शुरुआत में नहीं होगा
    • IVF और HNSW वे capabilities हैं जिन्हें आगे जोड़ने की उम्मीद है

Browser demo configuration

  • demo browser में चलने वाले sqlite-vec का इस्तेमाल करता है
  • developer tools में दिखने वाली configuration इस प्रकार है
    • non-optimized 5.9MB sqlite3.wasm
    • sqlite-vec के साथ compile किया गया official SQLite WASM build
    • 2.6MB size की movies.bit.db SQLite database
  • movies.bit.db में TMDB movie metadata पर आधारित 4,800 movie overviews articles table में हैं
  • अलग vec_movies virtual table उन overview embeddings का vector index है
    • embeddings Nomic 1.5 embeddings model का इस्तेमाल करते हैं
    • vectors को binary vector में quantize किया गया है

Demo data और KNN search flow

  • articles table में title, release_date, overview जैसे columns हैं
  • overview column movie plot को छोटे sentences में रखता है, और demo में यही embedding target है
  • vec_movies virtual table articles.overview की embeddings को overview_embeddings column में store करता है
    • vector 768-dimensional binary vector है
    • storage size 768 / 8 = 96, यानी 96 bytes है
  • user radio button से movie चुनता है तो selected movie ID KNN SQL query के :selected_movie parameter में भर जाती है
  • search results selected movie के सबसे करीब 10 movies होते हैं
    • binary vector होने के कारण distance calculation में hamming distance इस्तेमाल होता है
    • सबसे करीबी result हमेशा वही movie होती है और distance 0 होता है
  • छोटे one-line plots और छोटे movie dataset को embed करने के नतीजे top quality नहीं हैं, और binary quantization quality को और sacrifice करता है, लेकिन focus browser के अंदर तेज और “good enough” vector search दिखाने पर है
  • internal behavior देखने के लिए SELECT से पहले EXPLAIN QUERY PLAN जोड़ सकते हैं, और vec_movies द्वारा इस्तेमाल किया जाने वाला 0:knn “index” दिखेगा

sqlite-vss की सीमाएँ और Faiss dependency

  • sqlite-vss development और adoption में कई blockers थे
    • यह सिर्फ Linux और macOS पर चलता है, Windows, WASM, mobile devices आदि support नहीं कर पाता
    • सभी vectors को memory के अंदर store करता है
    • transactions से जुड़े bugs और issues हैं
    • compile करना बहुत कठिन और समय लेने वाला है
    • scalar/binary quantization जैसे common vector operations गायब हैं
  • इन समस्याओं में से लगभग सभी Faiss dependency से निकली हैं
  • कुछ issues बहुत समय और मेहनत लगाकर solve हो सकते हैं, लेकिन काफी issues Faiss की वजह से blocked रह सकते हैं
  • dependency-free low-level solution एक आकर्षक option बन गया, और vector search खुद बहुत जटिल नहीं है—इस judgment से sqlite-vec शुरू हुआ

Release status और sponsorship request

  • sqlite-vec की core functionality काम करती है, लेकिन error handling और tests अभी बहुत कम हैं
  • sqlite-vec.c file में 246 TODO बाकी हैं
    • 191 todo_assert()
    • 41 // TODO comments
    • 14 todo panic
    • overall progress sqlite-vec v0 के आधार पर 0/246, 0% के रूप में दिखता है
  • 246 TODO पूरे होने पर पहला v0.1.0 release आने की योजना है
    • documentation
    • demo
    • bindings
    • अन्य components साथ में दिए जाएंगे
  • target timeline लगभग एक महीने की है, लेकिन schedule निश्चित नहीं है
  • sqlite-vec की सफलता में रुचि रखने वाली companies से sponsorship की तलाश है, और email के जरिए संपर्क किया जा सकता है

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

1 टिप्पणियां

 
GN⁺ 2024-05-04
Hacker News की राय

  • मैं लेखक हूँ — सवाल हों तो जवाब दूँगा। यह आधिकारिक रिलीज़ से ज़्यादा “एक नए प्रोजेक्ट पर काम चल रहा है” जैसी चीज़ है, और extension खुद भी अभी प्रगति में है। प्रोजेक्ट लिंक: https://github.com/asg017/sqlite-vec
    इस extension का v0.1.0 कैसा दिखेगा, इसकी काफी ठोस तस्वीर है, लेकिन वहाँ तक पहुँचने में शायद कुछ और हफ्ते लगेंगे। इस पोस्ट का मकसद मुख्यतः मेरे पहले बनाए SQLite vector search extension sqlite-vss के यूज़र्स को बताना था कि आगे क्या आने वाला है, और तैयार होने पर एक बड़ी रिलीज़ होगी।
    कुल मिलाकर, आसानी से embed हो सकने वाला vector search alternative मिलने को लेकर मैं बहुत उत्साहित हूँ। यह सभी operating systems, WASM, mobile devices, Raspberry Pi आदि पर चल सकेगा, यह खास तौर पर अच्छा है; और निजी तौर पर मैं Beepy पर एक छोटा semantic search app चलाकर देखने की कोशिश कर रहा हूँ, इसलिए यह मज़ेदार है।
    [0] https://beepy.sqfmi.com/

    • जानना चाहता हूँ कि कौन-कौन से distance functions support होंगे। लगता है कि binary vectors पहले से support हैं, तो क्या Hamming distance भी support होगा?
      sqlite-vss की तुलना में performance भी जानना चाहूँगा। query speed और memory usage, दोनों के profiling numbers देखने में दिलचस्पी है।
      कुल मिलाकर यह सच में शानदार लग रहा है, और यह दिशा मुझे पसंद है।
      शुरुआत में sqlite-vec केवल exhaustive full-scan vector search support करता है और approximate nearest neighbor (ANN) option नहीं है, लेकिन बाद में IVF और HNSW जोड़ना चाहते हैं — यह approach मुझे 1000% सही लगता है। शुरुआत से ही इसे ज़रूरत से ज़्यादा जटिल न बनाना अच्छा है।
      मैंने पहले on-device vector search launch किया है, और 128-bit binary vectors व Hamming distance के combination में, database में 200k से ज़्यादा entries होने पर भी हर camera frame पर पूरी brute-force distance search चलाने के लिए यह काफी तेज़ था। low-end phones पर भी 10fps से ज़्यादा मिला, और अच्छे phones पर बहुत smooth था। हैरानी की बात है कि brute force कई cases में काफी होता है।
      हालांकि HNSW जैसे ANN algorithms implement करते समय अगर इसे table index paradigm के रूप में handle किया जा सके तो बढ़िया होगा। तब brute-force search से ANN पर जाना table पर index बनाने जितना सरल हो जाएगा, और अलग-अलग ANN algorithms व parameters के साथ प्रयोग भी index creation parameters adjust करके किए जा सकेंगे। हो सकता है पहले से उसी दिशा में हो, लेकिन सोचा उल्लेख कर दूँ।
    • जानना चाहता हूँ कि HNSW जैसी indexing strategies भी implement करने की योजना है या नहीं। linear scan शुरुआत के लिए स्वाभाविक रूप से अच्छा है, और अगर data reasonable order में sorted हो और मान लें 10MB से कम हो, तो यह काफी तेज़ हो सकता है, इसलिए beta release रोकने की वजह नहीं दिखती।
      यह भी जानना चाहूँगा कि क्या यह sqlite-httpvfs के साथ build होता है। यह project इसके साथ अच्छा fit लगता है: https://github.com/phiresky/sql.js-httpvfs
    • Wasm शामिल होना सच में अच्छा है। आम तौर पर browser में SQLite के अंदर vector search इस्तेमाल करना मुश्किल था।
      क्या common SQL vector DSL के लिए pgvector के साथ syntax-compatible बनाने पर भी विचार किया है? लगता है drawbacks शायद benefits से बहुत कम नहीं होंगे, लेकिन जानना चाहता हूँ कि यह संभव है या नहीं।
    • क्या इसे Rust में implement किया जा सकता है? यह भी जानना चाहता हूँ कि sqlite-loadable-rs project WASM support करता है या नहीं।
      https://observablehq.com/@asg017/introducing-sqlite-loadable...
    • पहले मैंने sqlite-vss को Langchain में vector store के रूप में add किया था। क्या आपको लगता है कि यह नया project Langchain में add करने लायक mature है, या थोड़ा और इंतज़ार करना बेहतर होगा?
      sqlite-vss पहले से ही कुछ projects में अच्छी तरह इस्तेमाल हो रहा है।

  • “768-dimensional binary vector है इसलिए 96 bytes लेता है (768 / 8 = 96)” वाला हिस्सा मुझे उलझाने वाला लगा। ज़्यादातर vector stores जिस समस्या से जूझते हैं, यानी curse of dimensionality, वही यही हिस्सा है, और मेरे हिसाब से यह indexing से पहले की समस्या है।
    मुझे लगा शायद मतलब 768 dimensions * 8 bytes (f64), यानी 6144 bytes होगा। आम तौर पर थोड़े loss को स्वीकार करके f32 या f16, या उससे भी छोटे representation में घटाया जाता है।
    अगर compression या trie जैसी amortization technique आदि से 768 dimensions को 96 bytes में रखने का कोई तरीका है, तो इस पर अलग पोस्ट में और सुनना चाहूँगा। अगर हर dimension को 1 bit के रूप में treat करने की बात है तो समझ आता है, लेकिन तब search quality को लेकर अभी भी सवाल हैं।

    • मैं लेखक हूँ — यहाँ binary vector का मतलब है कि हर dimension को 1 bit में quantize किया जाता है। आम तौर पर एक vector के लिए 4 * dimensions की संख्या bytes चाहिए होते हैं। यहाँ 4 sizeof(float) है।
      nomic v1.5[0] या mixedbread के नए model[1] जैसे कुछ embedding models को खास तौर पर इस तरह train किया जाता है कि binary quantization के बाद भी quality बनी रहे। सभी models ऐसे नहीं होते, इसलिए results अलग हो सकते हैं। आम तौर पर OpenAI के 3072-dimensional large embedding model जैसे बहुत बड़े vectors में, इसके लिए खास तौर पर train न किए जाने पर भी यह कुछ हद तक काम करता लगता है।
      [0] https://twitter.com/nomic_ai/status/1769837800793243687
      [1] https://www.mixedbread.ai/blog/binary-mrl
    • binary का मतलब है हर dimension को +1 या -1 में quantize करना।
      अगर data पर FAISS index इस्तेमाल करके Product Quantization apply करें, तो binary features के मामले में PQ768x1 जैसी scheme से binary vectors test किए जा सकते हैं, और vector pairs के लिए चार values में से एक में quantize करने जैसी approaches की भी तुलना की जा सकती है: https://github.com/facebookresearch/faiss/wiki/The-index-fac...
    • संदर्भ के लिए, curse of dimensionality का सख्त अर्थ है कि high-dimensional space relatively sparse हो जाता है, और उस space को भरने के लिए data को exponentially बढ़ना पड़ता है। इसका storage capacity से कोई संबंध नहीं है।
      आम तौर पर vector databases में storage से पहले data को lower-dimensional space में compress या project किया जाता है, इसलिए यह स्थिति उलटे बेहतर हो जाती है।

  • sqlite-vss की वजह से मैं सीख पाया कि RAG कैसे काम करता है और उसे एक toy project में लागू कर पाया। Debugging थोड़ी मुश्किल थी, लेकिन सही तरह से set करने पर यह Ubuntu पर बिना किसी दिक्कत के चलता था, और मैं अब भी इसका इस्तेमाल कर रहा हूँ
    सीमित dependencies के बिना एक बेहतर नया version बनाया जा रहा है, यह सुनकर अच्छा लगा

  • जिज्ञासा है कि योजना सिर्फ public SQLite API इस्तेमाल करने की है, या SQLite amalgamation से जोड़ने जैसा रूप सोचा जा रहा है
    इस तरह की functionality में निश्चित रूप से दिलचस्पी है, लेकिन Wasm-आधारित Go bindings में इसे SQLite से अलग कैसे distribute किया जाए, इस पर सोचना होगा। अब तक Wasm “dynamic linking” की तुलना में यह काफी सरल रहा है, इसलिए हम सारा C code bundle करके distribute करते आए हैं
    साथ ही आपने incremental BLOB I/O का जिक्र किया था; शायद आपको पहले से पता होगा, लेकिन ध्यान रखना चाहिए कि बड़े BLOB pages की linked list के रूप में store होते हैं, इसलिए BLOB I/O बिल्कुल भी random access नहीं होता

    • योजना सिर्फ public SQLite API इस्तेमाल करने की है। इसलिए amalgamation से जोड़ने की जरूरत नहीं होगी
      मुझे wazero SQLite bindings सच में बहुत पसंद हैं। असल में योजना है कि 1) sqlite-vec के लिए CGO bindings और 2) go-sqlite3 में सीधे इस्तेमाल हो सकने वाला custom WASI build sqlite-vec उपलब्ध कराया जाए। मूल रूप से सोचा था कि उसी repository की build script का इस्तेमाल करके sqlite3.wasm file बनाई जाए। अगर आप project में सीधे support करना चाहें, तो शायद sqlite-vec.c/h files को go-sqlite3/sqlite3 में डाल देना ही काफी होगा
      incremental BLOB I/O मैंने कठिन तरीके से सीखा। sqlite-vec की query speed में यह निश्चित रूप से एक limiting factor है। chunk size को अपेक्षाकृत छोटा, low MB range में रखना और page_size बढ़ाना एक ठीक संतुलन देता था, लेकिन खासकर page_size के side effects हैं। PRAGMA mmap_size भी pages को memory में रखकर overflow lookups को तेज बनाता दिखता है, इसलिए बहुत मदद करता है, लेकिन जाहिर है memory usage काफी बढ़ जाता है। यह कठिन संतुलन है
    • अगर यह feature Wasm Go bindings में आता है, तो मुझे सच में दिलचस्पी होगी

  • DuckDB ने आज “Vector Similarity Search in DuckDB” extension की घोषणा की
    https://duckdb.org/2024/05/03/vector-similarity-search-vss.h...

    • यह काफी promising है। लगता है इससे मेरा पहले बनाया छोटा CDN-आधारित HNSW project काफी सरल हो सकता है: https://github.com/jasonjmcghee/portable-hnsw
      DuckDB VSS इस्तेमाल करके embeddings बनाना, उन्हें DuckDB format में store करना, और फिर CDN के अंदर SQL चलाना संभव लगता है

  • मुझे इस style के projects पसंद हैं। यह बहुत specific problem को target करने वाला open source project है, इसलिए अच्छा है
    TypeScript/Next.js/React ecosystem में भी क्या किसी technical niche के लिए कुछ बहुत उपयोगी बनाया जा सकता है, इस बारे में मैं सोचता रहता हूँ, लेकिन अभी तक inspiration नहीं मिली

  • AI RAG app https://github.com/rnadigital/agentcloud में end-to-end automation के लिए Qdrant vector DB इस्तेमाल किया था, इसलिए इसका successor बन रहा है, यह सुनकर उत्साहित हूँ। जानना चाहूँगा कि यह कब तक use करने के लिए ready होगा और क्या कोई quick start guide है
    शायद blog लिखने में भी मदद कर सकूँ

    • v0.1.0 का लक्ष्य करीब एक महीने बाद का है। docs और quick start guide काफी शामिल करने की योजना है
      एक undocumented sqlite-vec pip package है, इसलिए अगर आप Python के “Agent Backend” से सीधे call करना चाहें, तो अभी भी try कर सकते हैं

  • यह “README-driven development” कैसा दिखेगा, इसकी मेरी कल्पना से काफी मिलता-जुलता है। जिज्ञासा है कि क्या author ने documentation से शुरुआत की थी

    • शुरुआत code से की थी। extension खुद पहले से ही काफी हद तक लिखा जा चुका है[0]
      हालांकि यह “20% effort से 80% बना लेने” वाली अवस्था में है, इसलिए बाकी 20% — error handling, fuzz testing, correctness testing — शायद समय का 80% लेगा। फिर भी लोग मौजूदा sqlite-vss की स्थिति के बारे में पहले से सवाल पूछ रहे थे, इसलिए लगा कि यह “work in progress” blog post कुछ सवालों के जवाब दे सकती है
      documentation से शुरुआत करने का idea भी अच्छा लगता है। खासकर SQLite extensions में SQL API कैसा दिखता है — यानी scalar functions और virtual tables वगैरह — यह बहुत महत्वपूर्ण है। ज्यादातर code लिखने से पहले मैंने काफी sketch किया था कि sqlite-vec का SQL वाला हिस्सा कैसा होना चाहिए
      [0] https://github.com/asg017/sqlite-vec/blob/main/sqlite-vec.c

  • लगता है यह कुछ महीने पहले SQLite-vss पर डाले गए मेरे GitHub issue के जवाब जैसा है। सख्ती से कहें तो यह उस issue का जवाब नहीं है, लेकिन
    https://github.com/asg017/sqlite-vss/issues/124

    • सही है। वहाँ follow-up reply न कर पाने के लिए माफ़ी
      सच कहूँ तो जब मैंने पहली बार वह ticket पढ़ा, तो मैं “sqlite-vss को और बेहतर कैसे बनाया जा सकता है” वाली rabbit hole में चला गया, और अंततः “sqlite-vec बनाना चाहिए” तक पहुँचा। इस रास्ते पर जाने में मदद करने के लिए धन्यवाद
      sqlite-vec की built-in binary quantization इस्तेमाल करके लगभग इस तरह किया जा सकता है:
      CREATE VIRTUAL TABLE vec_files USING vec0 ( contents_embedding bit[1536] );
      INSERT INTO vec_files(rowid,contents_embedding) VALUES ((1, vec_quantize_binary( /* 1536-dimension float vector here*/)))

  • ब्राउज़र के अंदर चलाते समय क्या sqlite-vec ब्राउज़र के native IndexedDB में डेटा को persist कर सकता है, यह जानना चाहता हूँ। या फिर यह हिस्सा user को खुद संभालना होगा?
    अगर जवाब यह भी हो कि अभी इस पर सोचा नहीं है, तो भी उस दिशा में आपकी सोच साझा करें तो अच्छा लगेगा

    • संभव हो सकता है। यह official SQLite WASM build पर आधारित है, इसलिए वहाँ उपलब्ध वही persistence options[0] इस्तेमाल किए जा सकते हैं
      IndexedDB खास तौर पर supported है या नहीं, यह पक्का नहीं है, लेकिन localStorage/OPFS VFS इस्तेमाल किए जा सकते हैं
      [0] https://sqlite.org/wasm/doc/trunk/persistence.md#kvvfs