AI hay gặpDB truyền thống tra cứu bằng khớp chính xác hoặc khoảng giá trị với B-tree hay hash — cực nhanh cho WHERE id = ?. Nhưng câu hỏi "vector nào gần vector này nhất trong 10 triệu vector" thì index đó vô dụng, và quét tuần tự tốn O(n·d).
Vector DB giải bài toán khác: tìm láng giềng gần đúng (ANN). Chấp nhận bỏ sót vài phần trăm kết quả để đổi lấy tốc độ nhanh hơn hàng trăm lần. Đây là đánh đổi cốt lõi cần nắm — kết quả không đảm bảo chính xác tuyệt đối, và mức recall là tham số bạn tự chọn.
Hai họ thuật toán chính:
- HNSW — dựng một đồ thị nhiều tầng, mỗi node là một vector, cạnh nối các vector gần nhau. Tìm kiếm bắt đầu ở tầng trên cùng (thưa, nhảy xa được), tham lam đi về phía láng giềng gần hơn, rồi tụt dần xuống tầng dưới để tinh chỉnh. Giống như tìm địa chỉ bằng cách đi máy bay tới thành phố, rồi taxi tới quận, rồi đi bộ. Thời gian cỡ logarit, recall cao, đổi lại tốn RAM vì phải giữ cả đồ thị. Đây là mặc định của Qdrant, Weaviate, pgvector.
- IVF — gom vector thành các cụm bằng k-means; khi truy vấn chỉ so với vector trong vài cụm gần nhất. Ít tốn bộ nhớ hơn HNSW nhưng recall thấp hơn, và vector nằm sát ranh giới cụm hay bị bỏ sót. Thường ghép với product quantization (PQ) để nén vector xuống hàng chục lần khi corpus tới hàng tỉ.
Độ đo: cosine, tích vô hướng, hoặc Euclid. Nếu embedding đã chuẩn hoá thì cả ba cho cùng thứ tự xếp hạng — nên đừng mất thời gian chọn.
Những thứ vector DB có mà thư viện ANN thuần không có: lọc theo metadata, hybrid search với BM25, tách namespace cho nhiều tenant, và sharding để scale ngang. Đây mới là lý do dùng một vector DB thay vì tự nhúng Faiss.
Chọn: đã có Postgres và dưới ~10 triệu vector thì pgvector là đủ và đơn giản nhất; cần hiệu năng và tính năng lọc mạnh thì Qdrant hoặc Weaviate; không muốn vận hành thì Pinecone; quy mô hàng tỉ thì Milvus.