Vector Database là gì: 4 tiêu chí chọn CSDL cho hệ RAG

Vector Database là gì? Đó là cơ sở dữ liệu lưu vector embedding kèm metadata. Nó tìm đoạn văn giống nghĩa nhất thay vì tìm đúng từ khóa. Đây là kho lưu trữ đứng sau bước Embedding và Indexing của hệ RAG.

Chọn sai cơ sở dữ liệu này thì hệ RAG chậm ngay từ bước truy xuất. Bài này đối chiếu 4 lựa chọn quen thuộc: pgvector, Qdrant, Milvus và Pinecone. Bốn tiêu chí đối chiếu là RAM chỉ mục HNSW, lọc metadata, chi phí vận hành cụm và độ trễ p95.

Tiêu chí 1: Chỉ mục HNSW ngốn RAM tới đâu

HNSW là chỉ mục đồ thị nhiều lớp cho tìm kiếm gần đúng. Nó đổi một phần RAM lấy tốc độ truy vấn. Tài liệu pgvector ghi rõ: HNSW cho tốc độ và độ phủ tốt hơn IVFFlat. Đổi lại, nó dựng chỉ mục chậm hơn và tốn nhiều bộ nhớ hơn.

pgvector dùng Postgres 13 trở lên, bản mới nhất ghi trên trang dự án là v0.8.7. Chỉ mục HNSW mặc định dùng m bằng 16 và ef_construction bằng 64. Vector thường tối đa 2.000 chiều, halfvec tối đa 4.000 chiều. Khi dựng chỉ mục, đồ thị nên vừa trong maintenance_work_mem để dựng nhanh.

Qdrant nhắc một điểm khác: chỉ mục payload cũng tốn thêm bộ nhớ và dung lượng đĩa. Vì vậy, chỉ nên lập chỉ mục cho trường nào thực sự dùng để lọc. Trường nào lọc nhiều nhất thì lập chỉ mục cho trường đó trước.

Milvus và Pinecone không có số RAM chung để đối chiếu. Mức RAM phụ thuộc số vector, số chiều và cấu hình triển khai. Đội nào cần số thật thì nạp thử dữ liệu của mình rồi đo.

Tiêu chí 2: Lọc metadata kết hợp tìm vector

Tìm vector thuần túy chưa đủ cho hệ RAG thật. Đội vận hành thường cần lọc trước theo tài liệu, theo quyền truy cập hay theo ngày. Ví dụ: chỉ tìm trong tài liệu của một khách hàng, chỉ lấy bản mới nhất.

pgvector giải quyết việc này bằng SQL quen thuộc. Vector nằm chung bảng với metadata nên câu lệnh WHERE lọc metadata trước, rồi mới sắp xếp theo khoảng cách vector. Toán tử khoảng cách gồm L2, inner product, cosine và L1.

Qdrant tách hai loại chỉ mục. Chỉ mục vector tăng tốc tìm tương tự. Chỉ mục payload tăng tốc lọc. Hãng khuyên tạo chỉ mục payload trước khi nạp dữ liệu. Lý do: chỉ mục HNSW lọc được hưởng lợi từ các cạnh bổ sung chỉ khi nó được tạo sau chỉ mục payload.

Qdrant còn có chế độ strict. Chế độ này chặn truy vấn lọc trên trường chưa lập chỉ mục. Truy vấn lỗi ngay ở cổng API thay vì chạy chậm rồi làm chậm cả cụm.

Chú thích ảnh: Người đàn ông gõ máy tính xách tay, minh họa cho việc vận hành hệ RAG. Ảnh: MART PRODUCTION, Pexels, giấy phép Pexels (link gốc xem mục Nguồn, phần Ảnh).

Tiêu chí 3: Chi phí vận hành cụm

pgvector là extension mã nguồn mở cho Postgres. Đội nào đã có Postgres thì chỉ cần bật extension bằng lệnh CREATE EXTENSION vector. Không có cụm riêng để vận hành. Chi phí chính là máy chủ Postgres và công dựng chỉ mục HNSW.

Qdrant là dịch vụ chuyên biệt cho tìm vector. Đội tự vận hành có thể chạy cụm Qdrant riêng. Đội không muốn vận hành cụm có thể dùng bản quản lý trên đám mây. Lựa chọn này đổi tiền dịch vụ lấy thời gian vận hành.

Milvus là cơ sở dữ liệu vector mã nguồn mở, chạy theo cụm riêng. Đội tự lo triển khai, mở rộng và giám sát. Pinecone là dịch vụ quản lý: đội không tự vận hành cụm mà trả phí theo mức dùng. Hướng chọn vì vậy phụ thuộc đội có người vận hành cụm hay không, nhiều hơn phụ thuộc tính năng.

Tiêu chí 4: Độ trễ p95 đo thế nào mới đúng

Độ trễ p95 là độ trễ mà 95 phần trăm truy vấn đạt được. Con số này mới phản ánh trải nghiệm thật, vì trung bình che mất đuôi chậm. Bài này không đưa ra con số p95 chung cho 4 hệ trên. Lý do: p95 phụ thuộc số vector, số chiều, bộ lọc và phần cứng đo.

Cách đo đúng gồm 3 bước. Nạp đúng dữ liệu thật của đội, gồm cả metadata dùng để lọc. Chạy đúng mẫu truy vấn thật, gồm cả truy vấn lọc hẹp và lọc rộng. Đo p95 riêng cho từng loại truy vấn thay vì gộp chung.

Một lưu ý từ tài liệu pgvector: ef_search càng cao thì độ phủ càng tốt nhưng truy vấn càng chậm. Giá trị mặc định là 40. Tăng con số này là cách đổi tốc độ lấy độ chính xác. Đội nào đo p95 thì nên ghi rõ ef_search dùng lúc đo.

Bảng đối chiếu: pgvector, Qdrant, Milvus và Pinecone

Tiêu chí	pgvector	Qdrant	Milvus	Pinecone
Kiểu triển khai	Extension của Postgres	Dịch vụ vector chuyên biệt, tự chạy hoặc dùng bản quản lý	Mã nguồn mở, tự vận hành cụm	Dịch vụ quản lý, trả phí theo mức dùng
Chỉ mục HNSW và RAM	HNSW tốn RAM hơn IVFFlat, đồ thị nên vừa maintenance_work_mem	Chỉ mục vector cộng chỉ mục payload, cả hai đều tốn thêm RAM và đĩa	Mức RAM phụ thuộc cấu hình triển khai, cần đo thử	Mức RAM do nhà cung cấp lo, đội không tự đo
Lọc metadata	SQL WHERE chung bảng với vector	Chỉ mục payload theo từng trường, có chế độ strict chặn lọc chưa lập chỉ mục	Lọc metadata kết hợp tìm vector theo cấu hình cụm	Lọc metadata theo API của dịch vụ quản lý
Độ trễ p95	Không có số chung, đo trên workload thật với ef_search ghi rõ	Không có số chung, đo trên workload thật sau khi lập chỉ mục payload	Không có số chung, đo trên workload thật	Không có số chung, đo trên workload thật

Rủi ro và giới hạn khi chọn vector database

Chọn theo quảng cáo mà không đo workload là rủi ro lớn nhất. Số đo p95 của hãng khác với p95 trên dữ liệu của bạn. Lọc metadata trên trường chưa lập chỉ mục làm truy vấn chậm hẳn. Dịch vụ quản lý tiện nhưng đổi nhà cung cấp tốn công chuyển dữ liệu. Đội nào chưa có người vận hành cụm thì nên bắt đầu từ pgvector trên Postgres sẵn có.

Đọc thêm trên 3a.com.vn:

• Lỗi trích dẫn sai nguồn trong RAG tài liệu nội bộ
• LangChain là gì và 4 thành phần cốt lõi
• Cách đọc bảng benchmark AI không bị đánh lừa

— Quang Minh, từ phòng đo kiểm 3A.