4 ms·

Qdrant 1.7.0

87 points by timvisee 3y ago

deleted 3y ago
[deleted]
deleted 3y ago
[deleted]
marginalia_nu 3y ago
> 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)
- Tomte 3y ago
  > e.g. as in Croft, Metzler & Strohman 7.2.1 https://ciir.cs.umass.edu/downloads/SEIRiP.pdf https://ciir.cs.umass.edu/downloads/SEIRiP.pdf
  - marginalia_nu 3y ago
    Actually I think I transposed two digits in that reference, it's 7.1.2.
mritchie712 3y ago
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 https://twitter.com/simonw/status/1722011967886688696
- alchemist1e9 3y ago
  Interesting they both do. Does Qdrant look like a winning horse then? Was about to use Weaviate for a project today and this gives me pause. Anyone have some strong opinions? pg_vector also been on my radar recently. Qdrant vs Weaviate I know is partially a rust vs go topic.
  - gk1 3y ago
    As another signal, check out this report by Streamlit, which shows the popularity of different vector databases among Streamlit apps: https://state-of-llm.streamlit.app/#third https://state-of-llm.streamlit.app/#third Faiss and Pinecone are at the top (disclosure: I'm from Pinecone). But Faiss isn't really a full-fledged vector DB. Pinecone is a managed option which is out of the question for a company like Twitter and maybe for you (although you should consider it). After that comes Chroma in third, and then Qdrant, and then Weaviate. Chroma has a big following by virtue of being plugged into the AI ecosystem in SF. Qdrant seems to be doing great work but their location in Europe is probably not helping.
    - beernet 3y ago
      Regarding your last sentence: the European HQ might not exactly help for non-EU customers, but much much more so for actual EU customers (which is a multi billion Dollar market by itself). Sensitive EU companies would not use Pinecone, even if they wanted to.
    - smurda 3y ago
      Disagree on location as a determining factor for great technology. You’re citing stats around market adoption because of marketing - not quality of the technology. If Twitter chose to use Qdrant for Grok, it doesn’t matter that Qdrant is out of Berlin. What matters is that Qdrant is the most performant, and it’s an open-source vectordb, not a closed-source vectordb like Pinecone.
    - mac-chaffee 3y ago
      We have been working this year to increase our US presence, and we're hiring now: https://join.com/companies/qdrant/9929148-cloud-platform-devops-engineer-us-timezone https://join.com/companies/qdrant/9929148-cloud-platform-dev... Source: I work at Qdrant from the US :)
diarrhea 3y ago
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 https://qdrant.tech/documentation/quick-start/#run-a-query [1]: `sentence-transformers/all-MiniLM-L6-v2`, following https://qdrant.tech/documentation/tutorials/neural-search-fastembed/#upload-data-to-qdrant https://qdrant.tech/documentation/tutorials/neural-search-fa...
- syntaxers 3y ago
  Your observations for using a vector DB for retrieval-augmented generation are consistent with my own. For my applications, I use pgvector since I can also use fulltext indexes and JOINs with the rest of my business logic which is stored in a postgres database. This also makes it easier to implement hybrid search, where the fulltext results and semantic search results are combined and reranked. I think the main selling-point for standalone vector databases is scale, i.e., when you have a single "corpus" of over 10^7 chunks and embedding vectors that needs to serve hundreds of req/s. In my opinion, the overhead of maintaining a separate database that requires syncing with your primary database did not make sense for my application.
- liminal 3y ago
  1. Yes, that's reasonable and saves running another DB 2. You often can perform the embedding in the DB, but there are a lot of use cases where you want to manage your embedding models outside the DB. This way you aren't dependent on which models the DB supports and you don't duplicate them throughout your system
J_Shelby_J 3y ago
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?
- iansinnott 3y ago
  Would also be curious. Wondering what the state of the art is for local vector stores. i.e. the sqlite of vector stores.
- kacperlukawski 3y ago
  If you will be the only app user, then the Python SDK's local mode might be suitable. However, in the long run, when you decide to publish the app, you rather have to switch to an on-premise or cloud environment. Using Qdrant from the very beginning might be a good idea, as the interfaces are kept the same, and the switch is seamless. Local mode: https://github.com/qdrant/qdrant-client#local-mode https://github.com/qdrant/qdrant-client#local-mode
- zzleeper 3y ago
  I was in that spot a few weeks ago. My requirements were not huge but a) I was on Windows and b), didn't want to waste too much time setting it up. Tried a few DBs that didn't work well (e.g. I think it was ChromaDB that didn't support Python 3.12) and ended up picking LanceDB. Very simple onboarding (just built on top of parquet) but there are a few rough edges. Curious how it compares with qdrant for non-crazy problems
  - kacperlukawski 3y ago
    I'm unsure if there is any comparison of LanceDB and Qdrant available out there, but there shouldn't be any issues with Python 3.12 and qdrant-client compatibility. Windows is also not a problem, as the typical local setup is usually based on Docker. Are there any specific features you are interested in?
karmakaze 3y ago
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/ https://qdrant.tech/pricing/
vasergen 3y ago
Any suggestion what should one read/watch to understand the difference between this and relational DB?
- generall 3y ago
  https://qdrant.tech/articles/dedicated-service/ https://qdrant.tech/articles/dedicated-service/ - we have some arguments on this
liminal 3y ago
Qdrant is great vector DB ...with the strangest hero image on their release announcement. A robot crab with a galleon in the background??
- dpbrinkm 3y ago
  In rust we trust. I think the whole thing is built with rust hence the crab references all over the place
tristenharr 3y ago
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 1.7.0

87 points by timvisee 3y ago

deleted 3y ago

[deleted]

deleted 3y ago

[deleted]

marginalia_nu 3y ago

> 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)

Tomte 3y ago
> e.g. as in Croft, Metzler & Strohman 7.2.1 https://ciir.cs.umass.edu/downloads/SEIRiP.pdf https://ciir.cs.umass.edu/downloads/SEIRiP.pdf
- marginalia_nu 3y ago
  Actually I think I transposed two digits in that reference, it's 7.1.2.

mritchie712 3y ago

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 https://twitter.com/simonw/status/1722011967886688696

alchemist1e9 3y ago
Interesting they both do. Does Qdrant look like a winning horse then? Was about to use Weaviate for a project today and this gives me pause. Anyone have some strong opinions? pg_vector also been on my radar recently. Qdrant vs Weaviate I know is partially a rust vs go topic.
- gk1 3y ago
  As another signal, check out this report by Streamlit, which shows the popularity of different vector databases among Streamlit apps: https://state-of-llm.streamlit.app/#third https://state-of-llm.streamlit.app/#third Faiss and Pinecone are at the top (disclosure: I'm from Pinecone). But Faiss isn't really a full-fledged vector DB. Pinecone is a managed option which is out of the question for a company like Twitter and maybe for you (although you should consider it). After that comes Chroma in third, and then Qdrant, and then Weaviate. Chroma has a big following by virtue of being plugged into the AI ecosystem in SF. Qdrant seems to be doing great work but their location in Europe is probably not helping.
  - beernet 3y ago
    Regarding your last sentence: the European HQ might not exactly help for non-EU customers, but much much more so for actual EU customers (which is a multi billion Dollar market by itself). Sensitive EU companies would not use Pinecone, even if they wanted to.
  - smurda 3y ago
    Disagree on location as a determining factor for great technology. You’re citing stats around market adoption because of marketing - not quality of the technology. If Twitter chose to use Qdrant for Grok, it doesn’t matter that Qdrant is out of Berlin. What matters is that Qdrant is the most performant, and it’s an open-source vectordb, not a closed-source vectordb like Pinecone.
  - mac-chaffee 3y ago
    We have been working this year to increase our US presence, and we're hiring now: https://join.com/companies/qdrant/9929148-cloud-platform-devops-engineer-us-timezone https://join.com/companies/qdrant/9929148-cloud-platform-dev... Source: I work at Qdrant from the US :)

diarrhea 3y ago

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 https://qdrant.tech/documentation/quick-start/#run-a-query [1]: `sentence-transformers/all-MiniLM-L6-v2`, following https://qdrant.tech/documentation/tutorials/neural-search-fastembed/#upload-data-to-qdrant https://qdrant.tech/documentation/tutorials/neural-search-fa...

syntaxers 3y ago
Your observations for using a vector DB for retrieval-augmented generation are consistent with my own. For my applications, I use pgvector since I can also use fulltext indexes and JOINs with the rest of my business logic which is stored in a postgres database. This also makes it easier to implement hybrid search, where the fulltext results and semantic search results are combined and reranked. I think the main selling-point for standalone vector databases is scale, i.e., when you have a single "corpus" of over 10^7 chunks and embedding vectors that needs to serve hundreds of req/s. In my opinion, the overhead of maintaining a separate database that requires syncing with your primary database did not make sense for my application.
liminal 3y ago
1. Yes, that's reasonable and saves running another DB 2. You often can perform the embedding in the DB, but there are a lot of use cases where you want to manage your embedding models outside the DB. This way you aren't dependent on which models the DB supports and you don't duplicate them throughout your system

J_Shelby_J 3y ago

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?

iansinnott 3y ago
Would also be curious. Wondering what the state of the art is for local vector stores. i.e. the sqlite of vector stores.
kacperlukawski 3y ago
If you will be the only app user, then the Python SDK's local mode might be suitable. However, in the long run, when you decide to publish the app, you rather have to switch to an on-premise or cloud environment. Using Qdrant from the very beginning might be a good idea, as the interfaces are kept the same, and the switch is seamless. Local mode: https://github.com/qdrant/qdrant-client#local-mode https://github.com/qdrant/qdrant-client#local-mode
zzleeper 3y ago
I was in that spot a few weeks ago. My requirements were not huge but a) I was on Windows and b), didn't want to waste too much time setting it up. Tried a few DBs that didn't work well (e.g. I think it was ChromaDB that didn't support Python 3.12) and ended up picking LanceDB. Very simple onboarding (just built on top of parquet) but there are a few rough edges. Curious how it compares with qdrant for non-crazy problems
- kacperlukawski 3y ago
  I'm unsure if there is any comparison of LanceDB and Qdrant available out there, but there shouldn't be any issues with Python 3.12 and qdrant-client compatibility. Windows is also not a problem, as the typical local setup is usually based on Docker. Are there any specific features you are interested in?

karmakaze 3y ago

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/ https://qdrant.tech/pricing/

vasergen 3y ago

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

generall 3y ago
https://qdrant.tech/articles/dedicated-service/ https://qdrant.tech/articles/dedicated-service/ - we have some arguments on this

liminal 3y ago

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

dpbrinkm 3y ago
In rust we trust. I think the whole thing is built with rust hence the crab references all over the place

tristenharr 3y ago

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.