towhee VS sqlite-vss

As another commenter noted, Milvus is overkill and a "bit much" if you're learning/playing.

A good intro to the field with progression towards a full Milvus implementation could be starting with towhee[0] (which is also supported by Milvus).

towhee has an example to do exactly what you want with CLIP[1].

[0] - https://towhee.io/

[1] - https://github.com/towhee-io/examples/tree/main/image/text_i...

The description of this is kind of confusing but I think the easiest way to understand it is that it is a data processing pipeline of sorts. Take unstructured data and apply transformation and computation. A similar project to this is Towhee (https://github.com/towhee-io/towhee). This project tries to simplify unstructured data processing and provides pretrained models and pipelines from their hub.

Milvus also has incredible flexibility when it comes to choosing an indexing strategy, and we also have a library specifically meant to help vectorize a variety of data called Towhee (https://github.com/towhee-io/towhee).

Benchmarking the models with towhee is as simple as:

I made a tutorial for building an image search engine with python. The code example is as simple as 10 lines of code, using Towhee and Milvus To put images into the search engine:

Traditionally, I've done this through PyTorch by adding a hook, but this requires knowledge of the model itself (i.e. model arch and layer names). I found https://github.com/Hironsan/awesome-embedding-models but it didn't provide many CV-focused open-source projects. There's also https://github.com/towhee-io/towhee which is great but more targeted towards application development.

image_decode and img2img_translation.animegan are predefined operators from towhee hub. We already have nearly a hundred operators, officially maintained or contributed by our users.

We have just released Towhee 0.6, a framework for doing ML jobs over unstructured data. Our latest release includes DataCollection, a new user-centric method-chaining API that enables rapid development and prototyping of embedding applications.

Re storing vectors in BLOB columns: ya, if it's not a lot of data and it's fast enough for you, then there's no problem doing it like that. I'd even just store then in JSON/npy files first and see how long you can get away with it. Once that gets too slow, then try SQLite/redis/valkey, and when that gets too slow, look into pgvector or other vector database solutions.

For SQLite specifically, very large BLOB columns might effect query performance, especially for large embeddings. For example, a 1536-dimension vector from OpenAI would take 1536 * 4 = 6144 bytes of space, if stored in a compact BLOB format. That's larger than SQLite default page size of 4096, so that extra data will overflow into overflow pages. Which again, isn't too big of a deal, but if the original table had small values before, then table scans can be slower.

One solution is to move it to a separate table, ex on an original `users` table, you can make a new `CREATE TABLE users_embeddings(user_id, embedding)` table and just LEFT JOIN that when you need it. Or you can use new techniques like Matryoshka embeddings[0] or scalar/binary quantization[1] to reduce the size of individual vectors, at the cost of lower accuracy. Or you can bump the page size of your SQLite database with `PRAGMA page_size=8192`.

I also have a SQLite extension for vector search[2], but there's a number of usability/ergonomic issues with it. I'm making a new one that I hope to release soon, which will hopefully be a great middle ground between "store vectors in a .npy files" and "use pgvector".

Re "do embeddings ever expire": nope! As long as you have access to the same model, the same text input should give the same embedding output. It's not like LLMs that have temperatures/meta prompts/a million other dials that make outputs non-deterministic, most embedding models should be deterministic and should work forever.

[0] https://huggingface.co/blog/matryoshka

[1] https://huggingface.co/blog/embedding-quantization

[2] https://github.com/asg017/sqlite-vss

Utilizing sqlite-vss to store and query vector embeddings managed by a local SQLite database, Semantify conducts fast, precise vector searches within these embeddings to find and recommend relevant content, ensuring readers are presented with articles that truly match their interests.

Whether you’re navigating through well-known options like SQLite, enriched with the sqlite-vss extension, or exploring other avenues like Chroma, an open-source vector database, selecting the right tool is paramount. This article compares these two choices, guiding you through the pros and cons of each, helping you choose the right tool for storing and querying vector embeddings for your project.

Here is a SQLite extension that uses Faiss under the hood.

https://github.com/asg017/sqlite-vss

Not associated with the project, just love SQLite and find it very useful.

Vector Databases: As your data grows, efficiently searching through millions of vectors can become a challenge. Specialized vector databases like FAISS, Annoy, or Elasticsearch's vector search capabilities can be explored to manage and search through large-scale vector data. Your sentence is grammatically correct. In addition, databases like SQLite and PostgreSQL have extensions, such as sqlite-vss and pgvector, that can be used to store and query vector embeddings, respectively.

I had a go at one of those a few months ago: https://datasette.io/plugins/datasette-faiss

Alex Garcia built a better one here as a SQLite Rust extension: https://github.com/asg017/sqlite-vss

As I searched for "sqlite vector plugin" I didn't find any results, before a couple of weeks ago. Two weeks ago I found Alex' SQLite VSS plugin for SQLite. The library was an amazing piece of engineering from an "idea perspective". However, as I started playing around with it, I realised it was ipso facto like "Titanic". Beautiful and amazing, but destined to leak water and sink to the bottom of the ocean because of what we software engineers refers to as "memory leaks".

alternative solution: - sqlite plugin - https://github.com/asg017/sqlite-vss - postgresql - https://github.com/pgvector/pgvector-go - redis - https://github.com/zhao-lang/redis_hnsw

That is great! I'll keep an eye.

I've been playing with this extension: https://github.com/asg017/sqlite-vss