7.1 Qdrant là gì, và khi nào đừng dùng
Câu trả lời ngắn: Qdrant là một cơ sở dữ liệu chuyên đi tìm hàng xóm gần nhất trong không gian vector, kèm khả năng lọc theo metadata mà không làm hỏng phép tìm đó.
Vế sau của câu là phần đắt giá. Đi tìm hàng xóm gần nhất thì thư viện nào cũng làm được — FAISS, hnswlib, thậm chí vài chục dòng NumPy. Việc khó là làm chuyện đó trong khi dữ liệu vẫn đang thay đổi, và người dùng vẫn đang thêm điều kiện lọc. Đó là ranh giới giữa một thư viện ANN và một vector database, và cũng là chỗ 7.8 sẽ đào rất sâu.
Ba thứ rất dễ lẫn
Phần tiêu đề “Ba thứ rất dễ lẫn”1.3 đã tách ba loại model. Đây là lát cắt tương ứng cho ba loại hạ tầng:
| Thư viện ANN | Vector database | Search engine đầy đủ | |
|---|---|---|---|
| Ví dụ | FAISS, hnswlib, ScaNN | Qdrant, Milvus, Weaviate | Elasticsearch, Vespa, OpenSearch |
| Đơn vị bạn thao tác | mảng vector trong RAM tiến trình của bạn | điểm có ID + metadata, qua mạng | tài liệu có schema, qua mạng |
| Xoá/sửa một phần tử | thường phải dựng lại index | có, trực tuyến | có, trực tuyến |
| Lọc theo metadata | tự làm ở ngoài | có, trong lúc tìm | có, rất mạnh |
| Bền vững sau khi tắt máy | tự lưu file | có (WAL + snapshot) | có |
| Phân tán | tự làm | có | có |
Qdrant không là một search engine đầy đủ. Nó có full-text search, nhưng đó là công cụ lọc và sparse retrieval, không phải một Lucene thay thế: không có analyzer chain kiểu Elasticsearch, không có aggregation phong phú, không có query DSL cho văn bản ở mức đó. Nếu bài toán của bạn thật sự là tìm kiếm văn bản truyền thống, hãy đọc lại 3.14 — Bảng chọn cấu trúc trước.
Khi nào đừng dùng Qdrant
Phần tiêu đề “Khi nào đừng dùng Qdrant”Ba trường hợp, xếp theo mức độ hay gặp:
1. Dữ liệu của bạn còn nhỏ, và bạn đã có Postgres. Dưới khoảng vài trăm nghìn đến
vài triệu vector, pgvector thường là lựa chọn đúng: không thêm hạ tầng, không thêm một
hệ thống nữa phải backup và giám sát, và bạn được transaction thật — vector và dữ liệu
nghiệp vụ nằm trong cùng một lần commit. Cái giá bạn trả là hiệu năng ở đuôi phân phối và
khả năng lọc trong lúc tìm. Đó thường là cái giá rẻ, cho tới khi nó không rẻ nữa.
2. Bạn chưa đo được stage 1 đang hỏng ở đâu. Đổi từ một for loop cosine sang Qdrant
không cải thiện chất lượng. Nó cải thiện tốc độ và khả năng vận hành. Nếu
recall@k của bạn thấp thì nguyên nhân gần như luôn nằm ở chunking, embedding, hoặc
truy vấn — không nằm ở việc bạn đang dùng NumPy thay vì HNSW. Xem
5.4 — Trần recall@k.
3. Bạn thật sự cần quy mô tỷ vector và có đội vận hành riêng. Ở mức đó, kiến trúc tách compute/storage của Milvus và các hệ tương tự có lý do tồn tại. Qdrant chạy được ở quy mô lớn, nhưng nó là một hệ stateful, tự quản shard, không phải một hệ dựng trên object storage.
So với các lựa chọn khác
Phần tiêu đề “So với các lựa chọn khác”Bảng dưới là định tính, tổng hợp từ tài liệu chính thức và các so sánh 2026 trong mục
Đọc thêm, không phải số đo của cẩm nang. Đừng dùng nó thay cho việc đo trên dữ liệu của
bạn:
| Điểm mạnh riêng | Điểm yếu / cái giá | |
|---|---|---|
| Qdrant | Lọc + vector search làm chung một bước rất tốt; Rust nên tiết kiệm bộ nhớ; self-host dễ; API truy vấn thống nhất | Không có hệ sinh thái text search sâu; phân tán do bạn tự quản shard |
| pgvector | Bạn đã có Postgres; transaction thật; zero hạ tầng mới | Đuối dần khi vector nhiều; filter + ANN kém tinh vi hơn |
| Weaviate | Vectorizer cắm sẵn, hybrid BM25 có sẵn theo kiểu “bật là chạy” | Ràng buộc vào mô hình schema của nó |
| Milvus | Kiến trúc phân tán cho quy mô rất lớn, GPU index | Vận hành nặng; thừa cho phần lớn hệ RAG |
| Elasticsearch / OpenSearch | Text search trưởng thành, aggregation, đã có sẵn trong nhiều công ty | Indexing vector chậm hơn đáng kể; ANN là tính năng thêm vào, không phải lõi |
Câu hỏi đúng không phải “cái nào tốt nhất” mà là: bạn đang đau ở đâu? Đau vì recall thì đổi database không chữa. Đau vì latency ở tail khi có filter thì đây đúng là chỗ Qdrant khác biệt.
Cái Qdrant chọn khác
Phần tiêu đề “Cái Qdrant chọn khác”Ba quyết định thiết kế xuyên suốt phần này, nêu trước để bạn có khung khi đọc tiếp:
- Không có “một index cho cả collection”. Dữ liệu chia thành nhiều segment, mỗi segment mang index riêng, và một tiến trình nền (optimizer) liên tục sắp xếp lại chúng. Gần như mọi hành vi latency khó hiểu đều truy về câu này.
- Filter được đưa vào trong đồ thị HNSW, chứ không đặt trước hay đặt sau nó (7.8).
- Mặc định nghiêng về availability và throughput, không phải consistency (7.16). Đọc ngay sau khi ghi có thể chưa thấy dữ liệu, và đó là thiết kế chứ không phải lỗi.