I'm evaluating different vector databases for a legal-tech app. We need to perform similarity searches but filtered by very specific attributes like date, jurisdiction, and case type. I've been looking at Qdrant and its filtering DSL. Is it flexible enough for nested conditions? I need to know if it can handle the complexity of our queries without a significant performance hit.
3 answers
Qdrant's filtering API is arguably its most powerful feature compared to its competitors. It uses a "Condition" system that allows for "must," "should," and "must_not" logic, which is very similar to Elasticsearch. This makes it incredibly flexible for nested conditions. In a legal-tech context, you could easily combine a range filter for dates with a match filter for jurisdictions. Because Qdrant builds "filtered indices," it doesn't just do a post-search filter; it intelligently narrows down the search space beforehand, ensuring that the latency remains low even as your metadata grows in complexity.
Does this filtering work well with multi-vector points? For example, if a document has multiple embeddings for different paragraphs, can I filter at the document level efficiently?
The "Has ID" filter is also very useful for excluding specific records from a search in real-time. It’s very fast and helps with privacy-related data redaction.
Spot on, Rebecca. Being able to instantly exclude IDs is a must-have for GDPR compliance and user-specific data filtering in my experience with AI apps.
Daniel, Qdrant handles this via named vectors within a single point. You can attach multiple vectors to one point, and the filters apply to the point as a whole. This is much more efficient than managing multiple collections. You can query a specific named vector while applying metadata filters that are global to that point, which sounds perfect for your document-level requirement in legal-tech applications.