Cơ sở dữ liệu vector (Vector Database)
1. Tổng quan
Cơ sở dữ liệu vector là hệ thống quản lý dữ liệu lưu trữ các vector nhiều chiều được chuyển đổi từ dữ liệu phi cấu trúc như văn bản·hình ảnh·giọng nói bằng mô hình nhúng (Embedding), và nhanh chóng tìm kiếm·trả về các kết quả có độ tương đồng ngữ nghĩa (Similarity) với vector truy vấn bằng tìm kiếm láng giềng gần nhất xấp xỉ (ANN, Approximate Nearest Neighbor).
Cơ sở dữ liệu quan hệ truyền thống được tối ưu cho khớp chính xác (Exact Match) giá trị và điều kiện khoảng, nên không thể xử lý các truy vấn như “hãy tìm các tài liệu có ý nghĩa tương tự câu này”. Tuy nhiên, khi AI tạo sinh và sinh tăng cường truy xuất (RAG) lan rộng, nhu cầu tìm kiếm theo thời gian thực các tri thức gần với ý nghĩa của câu hỏi ngôn ngữ tự nhiên để đưa vào prompt của LLM đã tăng vọt. Khi đó, nếu biểu diễn tài liệu·hình ảnh thành vector hàng trăm~hàng nghìn chiều thì “gần về ý nghĩa” trở thành “gần về khoảng cách trong không gian vector”, nên cần có công cụ tìm kiếm tương đồng tốc độ cao cho khối lượng vector lớn. Cơ sở dữ liệu vector xuất hiện chính là để lấp khoảng trống này.
Giá trị cốt lõi của cơ sở dữ liệu vector có ba điểm. Thứ nhất, tìm kiếm dựa trên ngữ nghĩa tìm ra kết quả liên quan về ngữ cảnh ngay cả khi từ khóa không khớp chính xác. Thứ hai, dùng chỉ mục ANN để cân bằng giữa độ chính xác và độ trễ, cho phép phản hồi ở mức mili giây ngay cả với hàng trăm triệu vector. Thứ ba, đảm nhận vai trò kho tri thức (Knowledge Store) cho nhiều pipeline AI khác nhau như RAG, gợi ý, phát hiện bất thường, loại bỏ trùng lặp.
2. Nguyên lý hoạt động và cấu trúc tổng thể
Cơ sở dữ liệu vector được chia thành luồng nạp dữ liệu (Ingestion) chuyển dữ liệu gốc thành embedding, và luồng tìm kiếm (Query) vector hóa truy vấn để tìm các vector tương tự. Ở bước nạp, tài liệu được chia thành kích thước phù hợp (Chunking) rồi vector hóa bằng mô hình nhúng, và vector được lưu vào chỉ mục cùng với văn bản gốc·metadata. Ở bước tìm kiếm, truy vấn của người dùng được vector hóa bằng cùng mô hình nhúng và duyệt chỉ mục ANN để lấy về K vector tương tự nhất (Top-K).
flowchart LR
subgraph Ingestion["Luồng nạp dữ liệu"]
D["Dữ liệu gốc (tài liệu/hình ảnh)"] --> C["Chia đoạn (Chunking)"]
C --> E1["Mô hình nhúng"]
E1 --> V1["Vector + metadata"]
V1 --> IDX["Lưu chỉ mục ANN"]
end
subgraph Query["Luồng tìm kiếm"]
Q["Truy vấn người dùng"] --> E2["Mô hình nhúng"]
E2 --> V2["Vector truy vấn"]
V2 --> SR["Tìm kiếm tương đồng (Top-K)"]
IDX --> SR
SR --> R["Kết quả + lọc metadata"]
end
R --> LLM["Đưa vào prompt LLM (RAG)"]
Nguyên lý quan trọng ở đây là phải dùng cùng một mô hình nhúng cho cả nạp dữ liệu và tìm kiếm. Bởi vì vector tạo từ các mô hình khác nhau có hệ tọa độ khác nhau nên việc so sánh khoảng cách trở nên vô nghĩa. Do đó, khi thay mô hình nhúng thì phải tính lại toàn bộ vector đã lưu (Re-indexing), và đây là yếu tố chi phí vận hành lớn.
A. Phương thức đo độ tương đồng
Độ tương đồng được định nghĩa bằng khoảng cách giữa các vector. Tiêu biểu có độ tương đồng cosine xem xét cosine của góc giữa hai vector, tích vô hướng (Dot Product) dùng trực tiếp tích vô hướng của vector, và khoảng cách Euclid (L2) xem xét khoảng cách đường thẳng giữa các tọa độ. Khi hướng (ý nghĩa) của vector quan trọng và muốn giảm ảnh hưởng của độ lớn (độ dài tài liệu) như trong tìm kiếm tài liệu, độ tương đồng cosine được dùng rộng rãi. Nếu chuẩn hóa embedding thì độ tương đồng cosine và tích vô hướng thực chất trở nên giống nhau, nên các dịch vụ quy mô lớn đôi khi ưa dùng tích vô hướng vì tính toán đơn giản.
| Phương thức đo | Khái niệm tính toán | Nơi dùng chính | Đặc điểm |
|---|---|---|---|
| Độ tương đồng cosine | Góc hướng vector | Tìm kiếm tài liệu/câu | Loại bỏ ảnh hưởng độ lớn, coi trọng hướng |
| Tích vô hướng (Dot) | Tích vô hướng vector | Gợi ý, embedding đã chuẩn hóa | Tính toán đơn giản, phản ánh độ lớn |
| Euclid (L2) | Khoảng cách đường thẳng | Hình ảnh/tọa độ | Nhạy với khoảng cách tuyệt đối |
B. Thuật toán chỉ mục ANN
Tìm kiếm vét cạn (Brute-force) so sánh toàn bộ hàng trăm triệu vector thì chính xác nhưng chậm. Vì vậy người ta dùng chỉ mục ANN hy sinh một chút độ chính xác để đổi lấy tốc độ tăng vượt bậc. Các thuật toán tiêu biểu là HNSW (Hierarchical Navigable Small World) dựa trên đồ thị, IVF (Inverted File) dựa trên phân cụm, và PQ (Product Quantization) nén vector để tiết kiệm bộ nhớ. HNSW duyệt láng giềng theo đồ thị phân tầng, đồng thời đạt recall cao và độ trễ thấp nên đã trở thành tiêu chuẩn trên thực tế của ngành, nhưng có nhược điểm là dùng nhiều bộ nhớ. IVF chia không gian vector thành nhiều ô và chỉ duyệt một số ô gần truy vấn nên có lợi cho dữ liệu lớn, và khi kết hợp với PQ (IVF-PQ) có thể tiết kiệm đáng kể bộ nhớ nên được ưa chuộng trong các dịch vụ siêu quy mô.
flowchart TB
Q["Vector truy vấn"] --> ENTRY["Điểm vào (tầng trên)"]
ENTRY --> L2["Duyệt đồ thị tầng giữa"]
L2 --> L1["Duyệt chi tiết tầng dưới"]
L1 --> TOPK["Ứng viên láng giềng gần Top-K"]
TOPK --> RERANK["Xếp hạng lại chính xác (Re-rank)"]
RERANK --> OUT["Trả về kết quả cuối cùng"]
Khi đó, độ chính xác (recall) và tốc độ·bộ nhớ có quan hệ đánh đổi. Tăng ef_search (độ rộng tìm kiếm) của HNSW thì recall tăng nhưng độ trễ cũng tăng, và tăng số ô duyệt (nprobe) của IVF cũng tương tự. Trong thực tiễn, người ta xác định trước SLA mục tiêu (VD: p99 50ms, recall 95%) rồi tinh chỉnh tham số.
C. Lọc metadata và tìm kiếm lai
Trong dịch vụ thực tế, cần áp dụng đồng thời độ tương đồng vector và điều kiện có cấu trúc, chẳng hạn “các tài liệu thuộc danh mục bảo mật, viết từ năm 2024 trở đi và có ý nghĩa tương tự”. Để làm vậy, thực hiện lọc trước/lọc sau (Pre/Post-filtering) bằng metadata được lưu cùng vector. Hơn nữa, tìm kiếm lai (hybrid) kết hợp tìm kiếm thưa (BM25, v.v.) mạnh về khớp chính xác từ khóa với tìm kiếm vector dày đặc mạnh về tìm kiếm ngữ nghĩa đang trở thành tiêu chuẩn gần đây, vì tìm kiếm từ khóa bổ sung cho những phần embedding còn yếu như danh từ riêng·mã·con số.
3. So sánh các loại hình xây dựng
Tìm kiếm vector có thể được xây dựng bằng một engine chuyên dụng riêng, hoặc hiện thực như chức năng mở rộng của cơ sở dữ liệu hiện có. DB vector chuyên dụng (VD: Pinecone, Milvus, Weaviate, Qdrant) có thế mạnh về xử lý quy mô lớn và đa dạng chức năng chỉ mục·lọc, nhưng thêm một hệ thống nên độ phức tạp vận hành tăng. Ngược lại, mở rộng của DB quan hệ (pgvector của PostgreSQL, v.v.) cho phép dùng chung giao dịch·join với dữ liệu hiện có nên rào cản áp dụng thấp, nhưng có thể thua engine chuyên dụng trước yêu cầu siêu quy mô·siêu độ trễ thấp. Vì vậy cần cân nhắc đồng thời quy mô dữ liệu, stack hiện có và năng lực đội ngũ khi lựa chọn.
| Hạng mục | DB vector chuyên dụng | Mở rộng RDB (pgvector, v.v.) | Tích hợp search engine (Elasticsearch, v.v.) |
|---|---|---|---|
| Thế mạnh | Siêu quy mô·đa dạng ANN | Tích hợp·join với dữ liệu hiện có | Lai từ khóa + vector |
| Điểm yếu | Gánh nặng vận hành riêng | Giới hạn hiệu năng siêu quy mô | Chức năng vector đi sau tương đối |
| Tình huống phù hợp | Dịch vụ AI hàng trăm triệu vector | Quy mô vừa và nhỏ·song hành giao dịch | Tái sử dụng tài sản tìm kiếm hiện có |
Ví dụ, với chatbot RAG nhắm tới vài chục nghìn tài liệu quy chế nội bộ, bắt đầu bằng pgvector để đơn giản hóa vận hành là hợp lý, nhưng với hệ thống gợi ý thương mại điện tử xử lý hàng trăm triệu sản phẩm·đánh giá thì kiểm soát bộ nhớ và độ trễ bằng engine chuyên dụng dựa trên IVF-PQ sẽ tốt hơn.
4. Chuyên sâu — Chất lượng RAG và xu hướng mới
Thành bại của cơ sở dữ liệu vector gắn trực tiếp với chất lượng câu trả lời của RAG. Nếu tìm kiếm kém, LLM sẽ sinh ra câu trả lời không có căn cứ (ảo giác - hallucination), nên việc kết hợp chiến lược chia đoạn (chia theo đoạn văn·đơn vị ngữ nghĩa), lựa chọn mô hình nhúng (phù hợp miền), số lượng Top-K và mô hình xếp hạng lại (Re-ranking) sắp xếp lại các ứng viên đã lấy về là quan trọng. Gần đây, để bổ sung vấn đề một vector duy nhất nén nhiều câu bị mất thông tin, kỹ thuật tương tác muộn (Late Interaction) kiểu ColBERT nâng độ chính xác bằng nhiều vector theo đơn vị token, và chiến lược tìm kiếm nhiều bước tìm bằng bản tóm tắt rồi trả về văn bản gốc đang được chú ý. Ngoài ra, Matryoshka embedding cắt bớt số chiều embedding tùy tình huống đang lan rộng như phương tiện điều chỉnh linh hoạt chi phí lưu trữ và độ chính xác. Về mặt chuẩn hóa, xu hướng pgvector trở thành tiêu chuẩn mở trên thực tế và được tích hợp rộng rãi vào các DB được quản lý của các nhà cung cấp đám mây lớn là rất rõ nét.
5. Các điểm cần lưu ý và hàm ý
Từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer), việc áp dụng cơ sở dữ liệu vector không đơn thuần là chọn kho lưu trữ, mà là quyết định điều phối các đánh đổi trên toàn bộ kiến trúc dịch vụ AI.
- Đánh đổi tam giác độ chính xác-hiệu năng-chi phí: Tham số HNSW/IVF, số chiều vector và mức lượng tử hóa đồng thời chi phối recall·độ trễ·bộ nhớ. Nên định nghĩa trước SLA mục tiêu và ngân sách rồi suy ngược bằng benchmark.
- Phụ thuộc mô hình nhúng và chiến lược tái lập chỉ mục: Thay mô hình dẫn đến tính lại toàn bộ vector, nên phải thiết kế trước cơ chế tái lập chỉ mục không gián đoạn (Blue-Green Index) và hệ thống quản lý phiên bản.
- Quản trị dữ liệu·bảo mật: Văn bản gốc và embedding có thể chứa thông tin cá nhân, và có rủi ro văn bản gốc bị khôi phục một phần bằng suy ngược embedding (Embedding Inversion), nên phải mở rộng kiểm soát truy cập·mã hóa·masking đến tận tầng vector.
- Song hành tìm kiếm lai·xếp hạng lại: Chỉ tìm kiếm vector thuần túy thì yếu với danh từ riêng·con số, nên kết hợp tìm kiếm từ khóa và mô hình xếp hạng lại để bảo đảm chất lượng RAG.
- Khả năng quan sát vận hành: Chỉ số hóa recall·độ trễ·độ mới của chỉ mục (Freshness) để giám sát thường xuyên bằng hệ thống observability, đồng thời chuẩn bị chiến lược sharding·mở rộng ngang cho sự tăng trưởng dữ liệu.
Trong tương lai, tìm kiếm vector được dự báo sẽ được hấp thụ thành chức năng cơ bản của RDB·search engine, trưởng thành từ “hệ thống đặc thù” thành “chức năng phổ biến”, và tầm quan trọng của nó sẽ càng tăng cùng sự lan rộng của embedding đa phương thức và tìm kiếm dạng agent.
Tài liệu tham khảo
- Dự án pgvector, https://github.com/pgvector/pgvector
- Malkov & Yashunin, "Efficient and robust approximate nearest neighbor search using HNSW", https://arxiv.org/abs/1603.09320
Tóm tắt một câu: Cơ sở dữ liệu vector tìm kiếm tương đồng tốc độ cao trên các vector nhiều chiều đã được nhúng bằng chỉ mục ANN, đóng vai trò kho tri thức theo ngữ nghĩa cho RAG·gợi ý·phát hiện bất thường, với cốt lõi là điều phối đánh đổi giữa độ chính xác·hiệu năng·chi phí.