Entwicklung einer neuen SQLite-Erweiterung für die Vektorsuche

Entwicklung einer neuen Erweiterung für die Vektorsuche in SQLite

• sqlite-vec ist eine neue SQLite-Erweiterung für Vektorsuche und soll das bisherige sqlite-vss ersetzen.
• Es soll ein „schnell genug“ eingebettetes Vektor-Suchwerkzeug werden, das in allen Umgebungen, in denen SQLite läuft, ausführbar ist (einschließlich WASM).
• Es befindet sich noch in der Entwicklung, aber sobald es fertig ist, lohnt es sich, einen Blick ins Repository zu werfen.

Eigenschaften von sqlite-vec

• Eine in reinem C geschriebene, von Abhängigkeiten freie SQLite-Erweiterung
• Benutzerdefinierte SQL-Funktionen und virtuelle Tabellen für eine schnelle Vektorsuche
• Weitere Werkzeuge und Hilfsmittel für Vektoraufgaben (Quantisierung, JSON/BLOB/numpy-Konvertierung, Vektoroperationen usw.)
• Vektorsuche ist nur mit SQL möglich (mit CREATE VIRTUAL TABLE, INSERT INTO, SELECT)

Vorteile von sqlite-vec

• Aufgrund der reinen C-Implementierung kann es auf allen Plattformen (Linux/macOS/Windows), im Webbrowser (WebAssembly), auf Mobiltelefonen, Raspberry Pi usw. ausgeführt werden.
• Die Binärgröße ist klein und liegt im Bereich von einigen hundert KB.
• Der Speicherverbrauch lässt sich besser kontrollieren (Vektoren werden in Blöcken gespeichert und bei einer KNN-Suche blockweise gelesen).
• Mit dem Kommando PRAGMA mmap_size kann die In-Memory-Geschwindigkeit gesteigert werden.
• Durch die Unterstützung variabler Embeddings wie Matryoshka sowie int8/bit-Vektoren ist eine binäre und skalare Quantisierung möglich.
• Bietet mehr Kontrolle über Geschwindigkeit, Genauigkeit und Datenträgerplatz.
• Anfangs wird nur eine vollständige (exhaustive) Vektorsuche unterstützt; künftig sollen IVF + HNSW ergänzt werden.

Demo

• sqlite-vec kann direkt im Browser ausgeführt werden (die SQLite-Datenbank movies.bit.db ist geladen).
• Die Tabelle articles enthält Spalten wie title, release_date und overview.
• In der virtuellen Tabelle vec_movies sind die Embedding-Vektoren der overview-Spalte gespeichert (768-dimensionale Binärvektoren, 96 Byte).
• Mit einer KNN-ähnlichen Suche können die zehn Filme mit der größten Ähnlichkeit zum gewählten Film gefunden werden.

Probleme von sqlite-vss

• Funktioniert nur unter Linux + macOS (unterstützt Windows, WASM, Mobilgeräte usw. nicht).
• Alle Vektoren werden im Speicher gehalten.
• Zahlreiche Transaktions-bezogene Fehler und Probleme.
• Das Kompilieren ist sehr schwierig und zeitaufwendig.
• Standard-Vektoroperationen fehlen (skalare/binäre Quantisierung usw.).
• Probleme aufgrund der Abhängigkeit von Faiss.

Entwicklungsstand von sqlite-vec

• Die Kernfunktionen funktionieren, aber die Fehlerbehandlung und Tests sind fast nicht vorhanden.
• In der Datei sqlite-vec.c gibt es 246 TODOs.
• Nach dem Abschluss aller TODOs ist die Veröffentlichung von sqlite-vec v0.1.0 zusammen mit Dokumentation, Demo und Bindings geplant (Ziel: etwa ein Monat).

GN⁺-Meinung

• Der Umstand, dass es ein eingebettetes Vektor-Suchwerkzeug ist, das auf verschiedenen Plattformen und in verschiedenen Umgebungen ausgeführt werden kann, ist attraktiv; insbesondere ist es spannend, dass es im Webbrowser als WASM läuft.
• Der Umstand, dass neuere Vektorsuchtechnologien wie Speicherkontrolle, Embeddings variabler Länge und Quantisierung umgesetzt sind, ist ebenfalls ein Pluspunkt. Geschwindigkeit, Genauigkeit und Speichernutzung scheinen damit flexibler steuerbar.
• Die ausschließliche Unterstützung der Vollsuche ist jedoch ein Engpass. Bei größeren Datenmengen kann es zu Performanceproblemen kommen; die Unterstützung von ANN-Algorithmen wie IVF+HNSW wirkt dringend erforderlich.
• Außerdem scheint es noch zu früh für einen produktiven Einsatz zu sein, da es sich noch in der Frühphase der Entwicklung befindet. Für eine Stabilisierung wird noch etwas Zeit benötigt.
• Ein Benchmark-Vergleich mit bestehenden Vektorsuchbibliotheken wie Faiss scheint ebenfalls nötig zu sein. Der Vorteil einer reinen SQLite-Erweiterung ist zwar klar, aber die Leistung muss noch validiert werden.

[GN⁺]

Hacker News Kommentare

• Der Autor beteiligt sich selbst an den Kommentaren und stellt sein neues Projekt sqlite-vec vor. Es ist noch in Entwicklung, peilt aber v0.1.0 in den nächsten Wochen an und gilt als Nachfolgeprojekt zu sqlite-vss, das er zuvor entwickelt hat.
• sqlite-vec ist eine auf eingebettete Vektorsuche optimierte Bibliothek, die auf verschiedenen Betriebssystemen, mobilen Geräten und sogar auf dem Raspberry Pi funktionieren kann. Der Autor experimentiert damit, sqlite-vec in einer semantischen Such-App namens Beepy einzusetzen.
• Es gab die Frage, wie sich ein 768-dimensionaler Vektor mit nur 96 Byte speichern lässt. Normalerweise wären bei float64 6.144 Byte nötig, weshalb man nach Techniken wie Kompression oder Approximation fragt.
• Ein Entwickler, der sqlite-vss bereits genutzt hat, bedankte sich dafür, dass es ihm bei der Entwicklung von RAG-Modellen geholfen habe, und meinte, dass es unter Ubuntu gut funktioniert habe.
• DuckDB hat kürzlich eine ähnliche Extension für die Vektorsimilaritätssuche veröffentlicht.
• Jemand teilt seine Erfahrung mit einer KI-RAG-App mit der Qdrant-Vektordatenbank und signalisiert Vorfreude auf den möglichen Einsatz von sqlite-vec.
• Es wird gefragt, ob nur die public API von SQLite genutzt wird oder ob eine direkte Integration in die amalgamation geplant ist. Er diskutiert die Bereitstellung im Hinblick auf WebAssembly-Bindings.
• Ein Kommentar lobt, dass ein OSS-Projekt am besten passt, wenn es einen konkreten Bedarf erfüllt, und sagt, dass man über mögliche Einsatzideen im TypeScript-Ökosystem nachdenkt.
• Es wirkt wie eine mögliche Lösung für ein SQLite-vss-Problem von vor einigen Monaten.
• Es wird gefragt, wie die Dimensionen aller Feature-Vektoren vereinheitlicht werden. Es scheint, dass die Werte über die Konvertierung von Strings in Float-Werte gespeichert werden, und man möchte wissen, ob bei der Hamming-Distanz-Berechnung auch Vektoren unterschiedlicher Länge berücksichtigt werden.
• Ein Beitrag wirkt wie eine README-getriebene Entwicklungsweise. Es wird gefragt, ob sie mit der Dokumentation begonnen haben.