I have been using Langchain Retriever wrappers to work with Qdrant DB. It has been good as a starting point. With Langchain’s V1.0 introduction, I have been thinking how to re-architect the software. Your comments would be very useful.
My first observation is a bit controversial: It is probably a good/better idea to decouple Qdrant APIs from Langchain-Qdrant APIs. In other words, I think these 3rd party integrations are limiting. Take the Langchain-Qdrant hybrid search as an example. It allows a combination of dense vector search and sparse vector search. However, if I use Qdrant APIs, I can do multi-vector searches, not limited by Langchain-Qdrant’s “hybrid” search of only 2 vector types.
The above is just one area of deficiency of using the integrated APIs. From my experiences, another real-world problem is that it would be more difficult for one company to take the ownership of the problems. For example, if GPU is not utilized, whom do I talk to in order to get the issue resolved.
So I am trying to determine how I should re-architect my software that uses both Langchain V1.0 and Qdrant. Specifically, would you use Langchain wrappers to interface with Qdrant (or any other vector DB)? If yes, do you use the Langchain-Qdrant APIs to treat Qdrant as a retriever, a tool, or something else? If no, where would you combine the Qdrant search output in the workflow?