> Traditional keyword-based search mechanisms often rely on algorithms like TF-IDF, BM25, or comparable methods. While these techniques internally utilize vectors, they typically involve sparse vector representations. In these methods, the vectors are predominantly filled with zeros, containing a relatively small number of non-zero values. Those sparse vectors are theoretically high dimensional, definitely way higher than the dense vectors used in semantic search. However, since the majority of dimensions are usually zeros, we store them differently and just keep the non-zero dimensions.

Yeah Heap's Law is a bit of a bitch in these situations. Like you'll definitely make sure those vectors are 64 bit if you plan of indexing a proper large number of documents.

I'd also advise caution leaning too much into the vector interpretation of these algorithms, as it's largely viewed as a quaint historical artifact that was bit of a dead end (e.g. as in Croft, Metzler & Strohman 7.2.1)

I like their pricing page[0] and their business model which it shows: (1) Apache-2.0 license source library, (2) Free to try and tiny hosting, (3) profit from serious hosting and/or consulting services.

I was looking for the fine print on their "Try For Free"/"Free Tier Available" and was pleasantly surprised by

  Qdrant Vector Search Cloud

  Start building now!
  A free forever 1GB cluster included for trying out.
  No credit card required.

[0] https://qdrant.tech/pricing/

Just the other day I played with qdrant, using its Python client. Pretty smooth onboarding experience.

I came across two questions. Perhaps some kind folks with more experience can shed some light on these qdrant use cases.

1. for embeddings for use cases such as LLM chat bots, I split internal data into chunks. Those chunks are then vectorized and stored. Alongside the entry itself, I stored the original chunk in metadata. That way, a lookup can immediately feed that into the LLM prompt context, without lookup in a secondary data store by some ID. Feels like a hack. Is that a sensible use case?

2. I resorted to using `fastembed` and generated all embedding client-side. Why is it that qdrant queries, in the ordinary case (also showcased a lot in their docs, e.g. [0]), expect a ready-made vector? I thought the point of vector DBs was to vectorize input data, store it, and later vectorize any text queries themselves?

Having to do all that client-side feels besides the point; for example, what if two separate clients use separate models (I used [1])? Their vectorizations will differ. I thought the DB is the source of truth here.

In any case, fascinating technology. Thanks for putting it together and making it this accessible.

[0]: https://qdrant.tech/documentation/quick-start/#run-a-query

[1]: `sentence-transformers/all-MiniLM-L6-v2`, following https://qdrant.tech/documentation/tutorials/neural-search-fa...

Qdrant is the vectordb that ChatGPT and Grok use (e.g. when you add docs to a custom GPT or tweets in Grok)

https://twitter.com/simonw/status/1722011967886688696

I’m interested in building a locally ran app. Is qdrant appropriate for that? Is it like SQLite where there is little overhead for doing a server less implementation?

I’m a big fan of Qdrant, I also have heard rumors than OpenAI uses Qdrant as their vector database of choice.

I’ve been building a Hasura Data Connector for Qdrant and it’s been too much fun. Glad to see them getting talked about here.

Qdrant is great vector DB ...with the strangest hero image on their release announcement. A robot crab with a galleon in the background??

Any suggestion what should one read/watch to understand the difference between this and relational DB?