feat: Qdrant Search Index

[Anush008]

Resolves #5698

Description

This PR adds Qdrant as a vector search backend alongside FAISS and Elasticsearch. Associated documentation and tests are also included. The Qdrant client dependency is marked optional and installed on demand.

Qdrant is an open-source vector search engine built for high-performance. It offers extensive filtering support with its filterable HNSW implementation.

I've tested the integration end-to-end against a local Qdrant instance.

Setup

You can run Qdrant with

docker run -p 6333:6333 -p 6334:6334 qdrant/qdrant

The dashboard is accessible at http://localhost:6333/dashboard

[ebarkhordar]

The Qdrant path works against a real client. I ran add_qdrant_index, get_nearest_examples and search_batch (with and without a query_filter) at f53e276 in a clean container and the results were correct, including with set_format("numpy") and set_format("torch") active on the dataset.

One suggestion, on the test rather than the implementation. QdrantIndexTest drives a Mock() client, so no part of the upload or retrieval path actually executes. qdrant-client has a local mode that runs the real engine in-process with no server (QdrantClient(":memory:")), and qdrant-client is already in TESTS_REQUIRE, so using it costs nothing in CI.

The specific gap is the point-id mapping, which is what the index rests on: load_qdrant_index documents "point IDs equal to the zero-based dataset row numbers", and search/search_batch hand int(point.id) straight back as dataset indices. If id=offset + i in point_generator were to regress to id=i (batch-local index), every assertion in QdrantIndexTest still passes, because the ids only ever reach a Mock and the query results are hardcoded.

Against a local client the same regression shows up at once. Four rows, batch_size=2:

[A] id=offset + i    points_in_collection = 4    nearest_to_row3 = ['row3']
[B] id=i             points_in_collection = 2    nearest_to_row3 = ['row1']

Duplicate ids overwrite the earlier batch, so the collection silently holds half the rows and retrieval returns the wrong ones with no error.

Payload indexes are the one thing local mode does not support (it warns and no-ops), so the mock is still the right tool for the create_payload_index kwargs and ordering assertions and for the query_filter propagation check. The suggestion is to add a local-mode case next to it covering retrieval, not to replace what is already there.

[Anush008]

The test case issue you mentioned is covered.