Vector database là gì? Cách hoạt động và khi nào nên dùng

Thay vì so khớp từ khoá chính xác như các cơ sở dữ liệu truyền thống, nó vận hành dựa trên phép toán hình học để tìm dữ liệu có ngữ nghĩa gần nhau trong một không gian vector liên tục.

Khả năng cốt lõi của hệ thống là xử lý được dữ liệu không cấu trúc — văn bản, hình ảnh, âm thanh — sau khi chúng đã được chuyển thành vector qua các mô hình học máy (Machine Learning) gọi là embedding model. Khi thông tin được ánh xạ vào một không gian đa chiều, những thực thể gần nhau về ngữ nghĩa cũng nằm gần nhau về toạ độ, và truy vấn lân cận gần nhất (Nearest Neighbor) chạy được với hiệu suất cao.

Trong các kiến trúc AI hiện đại, đặc biệt là Retrieval-Augmented Generation (RAG), nó cho phép các mô hình ngôn ngữ lớn (LLM) truy xuất đúng ngữ cảnh liên quan mà không cần huấn luyện lại toàn bộ mô hình, nhờ đó tối ưu chi phí và giảm hiện tượng "ảo giác" (hallucination).

Vector database là gì?

Sự khác biệt cốt lõi giữa cơ sở dữ liệu truyền thống và vector database nằm ở logic truy vấn. Các hệ quản trị SQL truyền thống được tối ưu cho truy vấn chính xác hoặc theo dải giá trị — tìm ID = 123, hoặc lọc giá lớn hơn 50. Ngược lại, vector database tập trung vào truy vấn theo độ tương đồng (similarity search), trả về các kết quả gần giống nhất với đầu vào, đo bằng khoảng cách hình học.

Dữ liệu hiện đại như hình ảnh hoặc ngữ cảnh văn bản mang tính trừu tượng cao, không thể tìm kiếm hiệu quả bằng SQL thông thường. Không thể tìm một tấm ảnh con mèo bằng cách so khớp từng bit, nhưng qua vector hoá, các đặc điểm hình khối và màu sắc được mã hoá thành mảng số để so sánh.

Khi dữ liệu đạt quy mô hàng triệu hoặc hàng tỷ bản ghi, việc so sánh tuần tự (brute-force) với độ phức tạp O(n) là bất khả thi về mặt kỹ thuật do giới hạn CPU và độ trễ. Để giải quyết bài toán quy mô, vector database sử dụng các thuật toán tìm kiếm lân cận gần đúng (Approximate Nearest Neighbor — ANN) để thu hẹp không gian tìm kiếm, đánh đổi một phần nhỏ độ chính xác lấy tốc độ phản hồi tính bằng mili giây.

Dữ liệu trở thành vector như thế nào?

Quá trình chuyển dữ liệu thô thành vector gọi là vector hoá (vectorization), do các mô hình embedding như OpenAI text-embedding-3, GloVe hoặc các kiến trúc Transformer đảm nhiệm. Các mô hình này được huấn luyện để nắm bắt những đặc tính tiềm ẩn của dữ liệu.

Ví dụ, trong không gian vector, các từ như "cat" và "kitty" sẽ nằm gần nhau do có ngữ cảnh sử dụng tương đồng. Phép tính kinh điển "King − Man + Woman = Queen" minh hoạ cách không gian vector lưu giữ các mối quan hệ ngữ nghĩa — giới tính, hoàng tộc — dưới dạng toạ độ hình học.

Mỗi vector thường bao gồm từ hàng trăm đến hàng nghìn chiều (dimension). Một vector 1536 chiều đại diện cho 1536 đặc tính số học khác nhau của cùng một mẩu dữ liệu.

Khởi tạo và lưu trữ vector trong Postgres bằng extension pgvector trông như sau:

CREATE TABLE items (id bigserial PRIMARY KEY, embedding vector(3));
INSERT INTO items (embedding) VALUES ('[1.2, 2.3, 3.4]');

Vector database hoạt động ra sao?

Để xác định mức độ tương quan giữa các vector, hệ thống sử dụng các độ đo khoảng cách (distance metric), mỗi độ đo có quy ước điểm số riêng cần lưu ý:

• Cosine similarity: đo góc giữa hai vector. Thường dùng cho văn bản vì tập trung vào hướng thay vì độ dài. (Điểm cao = tương đồng cao; còn cosine distance — toán tử <=> trong pgvector — thì ngược lại, điểm thấp mới là gần nhau.)
• Euclidean distance (L2): đo khoảng cách đường thẳng giữa hai điểm. Dùng khi độ lớn (magnitude) của vector mang thông tin quan trọng. (Điểm thấp = tương đồng cao.)
• Dot product: tính toán dựa trên cả hướng và độ lớn, thường dùng trong hệ thống gợi ý. (Điểm cao = tương đồng cao.)

Quy trình truy vấn tiêu chuẩn gồm: nhận đầu vào → vector hoá câu hỏi bằng cùng một mô hình → tìm kiếm các lân cận gần nhất (K-Nearest Neighbors) trong chỉ mục.

Về mặt lưu trữ, các hệ thống chuyên dụng như Qdrant hay Weaviate giữ dữ liệu ngay trong RAM, hoặc dùng cơ chế ánh xạ bộ nhớ (memory-mapped file) trên ổ đĩa NVMe để đảm bảo I/O thấp và tốc độ truy xuất tối đa cho các tập dữ liệu lớn hơn dung lượng bộ nhớ vật lý.

Vì sao phải có chỉ mục ANN như HNSW?

HNSW (Hierarchical Navigable Small Worlds) là thuật toán ANN phổ biến nhất hiện nay, dựa trên cấu trúc đồ thị phân lớp (layered graph). Quá trình tìm kiếm diễn ra bằng cách nhảy từ các lớp trên — kết nối thưa, phạm vi dài — xuống các lớp dưới có kết nối dày để tìm kiếm cục bộ. Cách tiếp cận này giúp đạt độ phức tạp tìm kiếm O(log n). Đổi lại, HNSW đòi hỏi lượng RAM rất lớn vì phải lưu toàn bộ cấu trúc đồ thị tiệm cận (proximity graph) trong bộ nhớ.

Các tham số cần quan tâm gồm m (số kết nối tối đa mỗi node) và ef_construction (độ chính xác khi xây dựng đồ thị). Tăng các giá trị này sẽ cải thiện độ chính xác (recall) nhưng làm tăng chi phí RAM và thời gian xây dựng chỉ mục.

Một lưu ý kỹ thuật với pgvector: việc xây dựng chỉ mục HNSW mặc định chỉ dùng 2 worker song song (giá trị mặc định của max_parallel_maintenance_workers trong Postgres). Để tối ưu, hãy nâng tham số đó lên và tăng maintenance_work_mem — tài liệu pgvector gợi ý 8GB — trước khi chạy lệnh tạo chỉ mục, vì quá trình này nhanh hơn hẳn khi đồ thị nằm vừa trong bộ nhớ đó.

IVFFlat (Inverted File Index) đi theo hướng khác: nó phân cụm không gian vector thành các vùng Voronoi. Cách này tốn ít RAM hơn HNSW nhưng yêu cầu một giai đoạn huấn luyện để xác định tâm cụm, và hiệu năng truy vấn cũng thấp hơn.

Lọc metadata và hybrid search

Trong thực tế, tìm kiếm vector thường đi kèm điều kiện lọc — chẳng hạn "tìm ảnh tương tự nhưng chỉ của User X". Có hai chiến lược:

1. Post-filtering: tìm vector tương đồng trước rồi mới lọc metadata. Nhược điểm là nếu bộ lọc quá khắt khe, kết quả trả về thường ít hơn yêu cầu — bạn xin top 10 nhưng chỉ nhận về 2, vì 8 kết quả kia không khớp metadata.
2. Pre-filtering: lọc metadata trước rồi mới tìm vector. Đây là cách tiếp cận chính xác hơn. Các hệ thống như Qdrant sử dụng "payload-indexed HNSW" để thực hiện pre-filtering mà không làm giảm hiệu suất truy vấn.

Hybrid search kết hợp giữa tìm kiếm ngữ nghĩa (dense vector) và tìm kiếm từ khoá truyền thống (sparse vector, BM25). Cơ chế này đặc biệt quan trọng khi phải xử lý các từ hiếm hoặc mã sản phẩm chính xác. Thuật toán RRF (Reciprocal Rank Fusion) thường được dùng để hợp nhất và xếp hạng lại kết quả từ hai nguồn tìm kiếm này.

Vector search yếu ở đâu?

Theo nghiên cứu "Vector Bottleneck" của DeepMind, các mô hình đơn vector (single-vector) có giới hạn về khả năng biểu diễn logic tổ hợp phức tạp (combinatorial complexity). Ví dụ, truy vấn "So sánh chính sách của FDR và Reagan" thường thất bại vì một vector duy nhất không thể đại diện đồng thời cho hai thực thể đối lập một cách chính xác.

Nghiên cứu cũng chỉ ra "critical-n point": với vector 1024 chiều, độ chính xác bắt đầu suy giảm rõ rệt khi số lượng tài liệu vượt mốc 4 triệu. Lúc này, việc tăng số chiều không còn mang lại hiệu quả tương xứng với chi phí RAM và độ trễ.

Vì những điểm yếu này — không xử lý tốt các hằng số cứng như mã SKU hay tên riêng chính xác — hybrid search không còn là một tính năng cộng thêm mà trở thành yêu cầu bắt buộc cho hệ thống chạy thật. Ngoài ra, việc duy trì HNSW hoàn toàn trên RAM dẫn đến chi phí hạ tầng rất cao khi quy mô dữ liệu tăng trưởng.

Có cần một vector database riêng không?

Có hai hướng tiếp cận chính:

1. Extension (tích hợp): như pgvector trên Postgres hay DynamoDB Vector Search. Ưu điểm là duy trì tính nhất quán dữ liệu (ACID), join được với dữ liệu quan hệ, và không phát sinh thêm hạ tầng vận hành. Nhược điểm là buffer pool của Postgres không được tối ưu cho vector workload, dẫn đến suy giảm hiệu năng khi chỉ mục vượt quá 10 triệu vector.
2. Dedicated DB (chuyên dụng): như Pinecone, Qdrant, Weaviate. Ưu điểm là tối ưu sâu cho ANN, hỗ trợ hybrid search và lọc metadata phức tạp tốt hơn.

Về chi phí: ở mốc 10 triệu vector, dịch vụ quản lý như Pinecone có thể tốn hơn $700 một tháng, trong khi tự vận hành Qdrant trên cloud tiêu chuẩn chỉ mất khoảng $120–$180.

Bạn nên bắt đầu từ đâu?

Dưới góc nhìn của một kỹ sư hệ thống, lời khuyên là chọn giải pháp vừa đủ thay vì chạy theo công nghệ mới nhất.

• Dưới 5 triệu vector: ưu tiên dùng các extension tích hợp sẵn như pgvector. Cách này tận dụng hạ tầng Postgres có sẵn, bảo đảm tính ACID và giảm thiểu rủi ro vận hành.
• Trên 10 triệu vector, hoặc cần hybrid search và pre-filtering hiệu năng cao: chuyển sang các giải pháp chuyên dụng như Qdrant hoặc Weaviate.
• Giai đoạn prototype: dùng Chroma để triển khai nhanh trên máy cục bộ.

Chỉ tách riêng vector database khi bạn đo được hiệu năng đang suy giảm, hoặc khi cần những tính năng chuyên sâu như payload-indexing mà cơ sở dữ liệu truyền thống không đáp ứng tốt.

Tài liệu tham khảo

• What is a Vector Database & How Does it Work? Use Cases + Examples — Pinecone
• Vector Embeddings Explained — Weaviate
• Vector Databases Explained in 3 Levels of Difficulty — MachineLearningMastery
• Understanding Hierarchical Navigable Small Worlds (HNSW) for Vector Search — Milvus
• pgvector: Open-source vector similarity search for Postgres — GitHub
• pgvector Guide: Vector Search and RAG in PostgreSQL — Encore
• The Vector Bottleneck in Embedding-Based Retrieval — Tullie Murrell
• Vector Database Comparison: Pinecone vs Qdrant vs Weaviate vs pgvector in Production — Tensoria
• Amazon DynamoDB now supports real-time vector search at any scale — AWS News Blog