EN
|
VI
Vector database (cơ sở dữ liệu vector) là hệ thống lưu trữ dữ liệu dưới dạng vector số học (embedding) và cho phép tìm kiếm những vector "gần" nhau nhất về mặt ngữ nghĩa, thay vì tìm kiếm khớp chính xác như database truyền thống. Đây là thành phần bắt buộc trong mọi kiến trúc RAG (Retrieval-Augmented Generation), vì nó chính là nơi lưu trữ và truy xuất tri thức mà mô hình ngôn ngữ dùng để trả lời câu hỏi. Nếu bạn đã đọc bài RAG là gì và RAG vs Fine-tuning, bài này sẽ đi sâu vào "trái tim" kỹ thuật của RAG: vector database hoạt động ra sao, và nên chọn hệ thống nào cho dự án của bạn.
Trong pipeline RAG, mỗi đoạn văn bản (chunk) được chuyển thành một vector số thực nhiều chiều thông qua mô hình embedding (ví dụ: text-embedding-3, voyage-3, BGE, E5). Khi người dùng đặt câu hỏi, câu hỏi đó cũng được embedding thành vector, rồi hệ thống tìm những vector trong kho dữ liệu gần nhất về mặt hình học với vector câu hỏi — tương ứng với các đoạn văn bản gần nhất về mặt ngữ nghĩa.
Vấn đề là: với hàng triệu đến hàng tỷ vector, việc so sánh khoảng cách giữa vector truy vấn với từng vector trong kho dữ liệu (brute-force, độ phức tạp O(N)) là quá chậm để dùng trong sản phẩm thực tế. Vector database giải quyết bài toán này bằng các thuật toán tìm kiếm lân cận gần đúng (Approximate Nearest Neighbor Search — ANNS), đánh đổi một phần độ chính xác để đổi lấy tốc độ nhanh hơn nhiều bậc.
Ba phép đo phổ biến nhất:
| Metric | Cách tính | Khi nào dùng |
|---|---|---|
| Cosine similarity | Góc giữa hai vector | Phổ biến nhất cho embedding văn bản (không quan tâm độ dài vector) |
| Dot product | Tích vô hướng | Dùng khi embedding đã được chuẩn hóa (normalize) sẵn, tính nhanh hơn cosine |
| Euclidean distance (L2) | Khoảng cách hình học | Phù hợp với embedding hình ảnh, dữ liệu không chuẩn hóa |
Hầu hết mô hình embedding hiện đại (OpenAI, Voyage, BGE) khuyến nghị dùng cosine hoặc dot product.
Đây là phần lõi kỹ thuật của vector database. Ba nhóm thuật toán index chính: HNSW (Hierarchical Navigable Small World) — thuật toán phổ biến nhất hiện nay, được giới thiệu trong nghiên cứu nền tảng của Malkov và Yashunin, công bố trên IEEE Transactions on Pattern Analysis and Machine Intelligence. Cơ chế hoạt động:
Nhờ cấu trúc phân lớp này, thời gian tìm kiếm giảm từ O(N) xuống gần O(log N), đồng thời vẫn giữ được độ chính xác (recall) cao. Đây là lý do HNSW được tích hợp mặc định trong hầu hết vector database hiện nay: Qdrant, Weaviate, Milvus, pgvector. Nhược điểm của HNSW: toàn bộ index cần nằm trong RAM để đạt hiệu năng tốt nhất, và không hỗ trợ cập nhật incremental hiệu quả — dữ liệu thay đổi nhiều đòi hỏi rebuild định kỳ. IVF (Inverted File Index) — chia không gian vector thành các cụm (cluster) bằng k-means, khi truy vấn chỉ tìm trong các cụm gần nhất thay vì toàn bộ dữ liệu. Thường kết hợp với Product Quantization (IVF-PQ) để nén vector, giảm dung lượng bộ nhớ — đánh đổi bằng độ chính xác thấp hơn HNSW. DiskANN — thiết kế riêng cho dữ liệu tỷ vector, cho phép index nằm chủ yếu trên ổ đĩa (SSD/NVMe) thay vì RAM, giải quyết bài toán chi phí bộ nhớ ở quy mô cực lớn.
Với dataset lớn, lưu vector ở độ chính xác gốc (float32) rất tốn RAM. Các kỹ thuật lượng tử hóa như scalar quantization (giảm xuống int8) hoặc product quantization giúp giảm dung lượng 4-32 lần, đổi lại một phần độ chính xác — đây là kỹ thuật hầu hết vector database production đều áp dụng ở quy mô hàng chục triệu vector trở lên.
Thị trường vector database năm 2026 đã phân hóa rõ theo use case: các đội ngũ không còn hỏi "database nào tốt nhất" mà hỏi "database nào phù hợp với quy mô, ngân sách, và stack hiện tại của mình".
| Database | Mô hình | Điểm mạnh | Giới hạn thực tế | Phù hợp nhất |
|---|---|---|---|---|
| pgvector | Extension Postgres, self-host hoặc managed (Supabase, RDS) | Không cần hệ thống riêng, transaction consistency, SQL quen thuộc | Hiệu năng giảm rõ khi vượt ~10-50 triệu vector trên một node | Dự án đã dùng Postgres, dưới 10M vector |
| Qdrant | Rust, open-source + Qdrant Cloud | Filtered search nhanh nhất nhóm, quantization mạnh, self-host dễ | Cần tự vận hành nếu không dùng Cloud | Production cần lọc metadata phức tạp, muốn self-host |
| Weaviate | Open-source + Weaviate Cloud | Hybrid search (vector + BM25) tích hợp sẵn tốt, multi-tenancy native | Cấu hình multi-tenant đòi hỏi tạo tenant tường minh | Cần hybrid search out-of-the-box, đa khách hàng (multi-tenant) |
| Milvus | Open-source, kiến trúc phân tán | Mở rộng tốt nhất ở quy mô tỷ vector, tiered storage (RAM/NVMe/S3) | Độ phức tạp vận hành cao nhất trong nhóm | Quy mô 100M+ vector, đội ngũ có kinh nghiệm hạ tầng |
| Pinecone | Fully managed, closed-source | Zero-ops, dễ triển khai nhanh nhất | Chi phí tăng mạnh theo quy mô | Prototype, MVP, team không muốn quản lý hạ tầng |
| ChromaDB | Open-source, chạy in-process | Cài đặt bằng một dòng pip install, không cần service riêng |
Thiếu công cụ vận hành production (HA, snapshot, monitoring) | Prototyping, notebook, demo nội bộ |
Một số xu hướng đáng chú ý được ghi nhận trong năm 2026: nhiều đội ngũ engineering đã chuyển dịch khỏi các vector database managed truyền thống khi chi phí ở quy mô lớn trở nên đáng kể — ví dụ một số trường hợp công khai cho thấy hóa đơn Pinecone production có thể lên tới hàng nghìn USD/tháng khi dữ liệu tăng, khiến việc tự vận hành (self-host) trở nên hợp lý về kinh tế hơn (nguồn: Tensoria Vector DB Benchmark 2026). Đồng thời, nhiều dự án đã đơn giản hóa kiến trúc bằng cách gộp vector search vào Postgres sẵn có thay vì duy trì một hệ thống riêng biệt (nguồn: Kalvium Labs, 2026). Điểm chung của các case study này: quyết định đúng phụ thuộc vào quy mô dữ liệu thực tế và ngân sách vận hành, không phải benchmark tốc độ thuần túy — một hệ thống nhanh nhất trên giấy tờ chưa chắc là lựa chọn kinh tế nhất cho use case cụ thể của bạn.
Khung quyết định đơn giản dựa trên quy mô dữ liệu và stack hiện có:
python
from qdrant_client import QdrantClient
from qdrant_client.models import VectorParams, Distance, PointStruct
client = QdrantClient(url="http://localhost:6333")
# Tạo collection với 1536 chiều (tương ứng text-embedding-3-small)
client.create_collection(
collection_name="rag_documents",
vectors_config=VectorParams(size=1536, distance=Distance.COSINE),
)
# Insert vector kèm metadata
client.upsert(
collection_name="rag_documents",
points=[
PointStruct(
id=1,
vector=embedding_vector, # list[float] từ mô hình embedding
payload={"source": "tai_lieu_a.pdf", "chunk_index": 3},
)
],
)
# Truy vấn top-5 đoạn văn bản gần nhất
results = client.search(
collection_name="rag_documents",
query_vector=query_embedding,
limit=5,
)sql
-- Bật extension
CREATE EXTENSION IF NOT EXISTS vector;
-- Tạo bảng lưu chunk và embedding
CREATE TABLE rag_chunks (
id bigserial PRIMARY KEY,
content text,
source text,
embedding vector(1536)
);
-- Tạo HNSW index
CREATE INDEX ON rag_chunks USING hnsw (embedding vector_cosine_ops);
-- Truy vấn top-5 gần nhất
SELECT content, source
FROM rag_chunks
ORDER BY embedding <=> '[0.012, -0.045, ...]'
LIMIT 5;Một thay đổi quan trọng trong năm 2026 là hybrid search (kết hợp tìm kiếm vector ngữ nghĩa với tìm kiếm từ khóa truyền thống BM25) đã trở thành yêu cầu mặc định cho RAG production, thay vì chỉ dùng vector search thuần túy. Lý do: vector search đơn thuần thường bỏ sót các truy vấn chứa tên riêng, mã sản phẩm, hoặc thuật ngữ chính xác — trong khi tìm kiếm từ khóa lại bỏ sót các câu hỏi diễn đạt khác cách nhưng cùng ý nghĩa. Weaviate và Qdrant hiện được đánh giá là hai lựa chọn open-source có hỗ trợ hybrid search mạnh nhất. Bên cạnh đó, kỹ thuật quantization (đặc biệt là int8 và binary quantization) tiếp tục được áp dụng rộng rãi hơn để giảm chi phí RAM ở quy mô lớn, và kiến trúc tiered storage (nóng trong RAM, ấm trên NVMe, lạnh trên object storage) đang trở thành cách tiếp cận phổ biến để cân bằng giữa tốc độ và chi phí ở quy mô hàng trăm triệu vector trở lên.
Vector database khác gì so với database truyền thống? Database truyền thống (SQL/NoSQL) tìm kiếm bằng khớp chính xác hoặc điều kiện lọc. Vector database tìm kiếm bằng độ tương đồng ngữ nghĩa giữa các vector số học, cho phép tìm ra nội dung "có ý nghĩa gần giống" ngay cả khi không khớp từ ngữ. HNSW là gì và tại sao được dùng phổ biến nhất? HNSW là thuật toán tìm kiếm lân cận gần đúng dựa trên đồ thị nhiều lớp, cho phép tìm kiếm với độ phức tạp gần O(log N) thay vì O(N) như brute-force, trong khi vẫn giữ độ chính xác cao. Đây là lý do HNSW được tích hợp mặc định trong hầu hết vector database hiện nay. Nên dùng pgvector hay Pinecone cho dự án RAG mới? Nếu dự án đã dùng PostgreSQL và dữ liệu dưới khoảng 10 triệu vector, pgvector là lựa chọn đơn giản và tiết kiệm chi phí nhất vì không cần thêm hệ thống riêng. Nếu ưu tiên triển khai nhanh và không có đội ngũ hạ tầng, Pinecone phù hợp hơn dù chi phí cao hơn ở quy mô lớn. Vector database nào tốt nhất cho RAG? Không có lựa chọn "tốt nhất" tuyệt đối — quyết định phụ thuộc vào quy mô dữ liệu, ngân sách vận hành, và stack kỹ thuật hiện có. pgvector phù hợp dự án nhỏ đã dùng Postgres; Qdrant phù hợp khi cần filter mạnh và tự vận hành; Milvus phù hợp quy mô cực lớn; Pinecone phù hợp khi ưu tiên tốc độ triển khai hơn chi phí. Có cần vector database riêng nếu đã có Elasticsearch hoặc Postgres? Không bắt buộc. Elasticsearch từ phiên bản 8 trở đi hỗ trợ vector search tích hợp, và Postgres có thể dùng pgvector. Việc thêm một vector database chuyên biệt chỉ thực sự cần thiết khi khối lượng vector lớn hoặc yêu cầu hiệu năng vượt quá khả năng của hệ thống hiện có.
Bài viết thuộc chuỗi nội dung RAG & AI. Xem thêm: RAG là gì? · RAG vs Fine-tuning
