Chọn vector database cho RAG nội bộ 2026: pgvector, Qdrant, Milvus, Weaviate, Chroma — so giấy phép, phiên bản & dung lượng

Khi xây RAG nội bộ — cho AI đọc và trả lời trên tài liệu của chính doanh nghiệp — câu hỏi kỹ thuật đầu tiên là: lưu vector ở đâu? Vector database là nơi cất các "embedding" (biểu diễn số của tài liệu) để truy hồi khi người dùng đặt câu hỏi. Bài này so năm vector database mã nguồn mở theo dữ kiện kiểm chứng được (giấy phép, phiên bản, độ phổ biến), chỉ cách chọn mô hình embedding cho tiếng Việt, và ước lượng dung lượng index cần chuẩn bị. Mọi số liệu tra cứu ngày 20/07/2026.

Vì sao RAG nội bộ cần vector database?

RAG (Retrieval-Augmented Generation) cần một vector database để lưu và tìm nhanh các đoạn tài liệu gần nghĩa với câu hỏi. Quy trình: cắt tài liệu thành đoạn (chunk) → đưa qua mô hình embedding để biến mỗi đoạn thành một vector số → cất vào vector DB. Khi người dùng hỏi, câu hỏi cũng được embed rồi vector DB trả về các đoạn "gần" nhất để mô hình ngôn ngữ tổng hợp câu trả lời. Nếu bạn chưa nắm khái niệm này, đọc trước bài RAG: cho AI nội bộ học tài liệu của bạn và sơ đồ kiến trúc AI nội bộ.

Với doanh nghiệp muốn giữ dữ liệu tại chỗ, điểm mấu chốt là chọn vector DB mã nguồn mở, tự host được — để tài liệu nội bộ không phải gửi lên dịch vụ bên thứ ba. Cả năm lựa chọn trong bài đều thoả điều kiện đó; khác biệt nằm ở giấy phép, độ trưởng thành và cách vận hành.

So sánh 5 vector database mã nguồn mở

Cả năm vector database dưới đây đều mã nguồn mở và tự host được, nhưng khác nhau về giấy phép và độ phổ biến: Milvus dẫn đầu với 45.274 sao GitHub, còn pgvector là lựa chọn "nhẹ" nhất vì chỉ là phần mở rộng cắm thẳng vào PostgreSQL. Bảng dưới tổng hợp dữ kiện kiểm chứng ngày 20/07/2026 — dùng để loại nhanh theo tiêu chí giấy phép (thương mại được không) và hạ tầng sẵn có.

Đọc bảng cho đúng: cả năm giấy phép (PostgreSQL, Apache-2.0, BSD-3-Clause) đều là giấy phép permissive — cho phép dùng thương mại và tự host thoải mái. Số sao GitHub phản ánh độ phổ biến và cộng đồng, không phải chất lượng tuyệt đối, nhưng là chỉ dấu tốt về mức hỗ trợ và tài liệu bạn sẽ tìm được khi gặp sự cố.

Chọn mô hình embedding cho tiếng Việt

Với tài liệu tiếng Việt, hãy chọn mô hình embedding đa ngữ, và cân giữa hai thông số quyết định: số chiều vector (càng lớn càng tốn dung lượng) và độ dài context (đoạn dài nhất model xử lý một lần). Ví dụ BAAI/bge-m3 cho vector 1.024 chiều và nhận tới 8.192 token mỗi lần — gấp 16 lần loại 512 token — nên cắt chunk thoải mái hơn. Bảng dưới lấy trực tiếp từ file cấu hình chính thức (config.json) trên HuggingFace.

*bge-m3 dùng checkpoint FP32 2,27 GB → ước tính ~568 triệu tham số; ba mô hình còn lại lấy trực tiếp từ safetensors metadata HuggingFace. Context của họ mô hình RoBERTa (bge-m3, e5) khai báo max_position_embeddings lớn hơn 2 do offset — số dùng được là 8.192 / 512 như bảng.

Bài học: chiều vector nhỏ = truy hồi nhanh và nhẹ đĩa, chiều lớn = giữ được nhiều sắc thái ngữ nghĩa. Với đa số bài toán hỏi-đáp tài liệu tiếng Việt, một mô hình 768–1.024 chiều đa ngữ là điểm cân bằng tốt; loại 384 chiều (MiniLM) hợp khi cần siêu nhẹ, chấp nhận đánh đổi độ chính xác.

Dung lượng: index vector chiếm bao nhiêu?

Dung lượng thô của một index vector bằng số chiều × số byte mỗi số × số vector. Ở độ chính xác FP32 (4 byte/số), một triệu vector 1.024 chiều chiếm ~4,1 GB; lượng tử hoá scalar xuống int8 (1 byte) kéo còn ~1,0 GB. Đây là con số cần biết trước khi cấp phát RAM/ổ đĩa cho vector DB, vì nhiều engine giữ index trong bộ nhớ để truy hồi nhanh.

*Chỉ là dung lượng vector thô. Chưa cộng cấu trúc index (ví dụ đồ thị HNSW), payload/metadata và bản sao dự phòng — hoá đơn thực tế cao hơn. Lượng tử hoá int8 giảm mạnh dung lượng nhưng đánh đổi một phần độ chính xác truy hồi.

Điểm thực dụng: với kho tài liệu vừa (dưới vài triệu đoạn), dung lượng vector hiếm khi là nút thắt — vài GB là chuyện nhỏ. Nút thắt thường là độ trễ truy hồi và chất lượng chunk. Nhưng khi số vector lên hàng chục–trăm triệu, chọn chiều vector và lượng tử hoá bắt đầu quyết định chi phí RAM thật.

Chọn thế nào cho doanh nghiệp Việt

Với đa số doanh nghiệp Việt bắt đầu RAG nội bộ, lựa chọn hợp lý là đi từ đơn giản đến chuyên dụng, chứ không nhảy thẳng vào hệ phân tán phức tạp. Đây là khung chúng tôi khuyến nghị:

• Đã có PostgreSQL → dùng pgvector. Bạn thêm khả năng vector vào chính database đang vận hành, không phải dựng và bảo trì một hệ mới — điểm vào nhanh và rẻ nhất để có RAG chạy thật.
• Cần chuyên dụng, quy mô lớn → Qdrant hoặc Milvus. Khi số vector lớn, cần lọc metadata phức tạp hoặc độ trễ thấp ổn định, hai engine chuyên dụng phổ biến nhất này cho nhiều lựa chọn index và mở rộng hơn.
• Prototype nhanh → Chroma. Nhẹ, dễ nhúng, hợp giai đoạn thử nghiệm trước khi cam kết hạ tầng.
• Chọn embedding trước, DB sau. Cố định mô hình embedding (và do đó số chiều vector) trước, vì đổi mô hình embedding buộc phải tạo lại toàn bộ index. Với tiếng Việt, một mô hình đa ngữ 768–1.024 chiều là mặc định an toàn.

Không có vector database "tốt nhất" tuyệt đối cho RAG nội bộ — hãy bắt đầu bằng pgvector nếu đã có PostgreSQL, và chỉ chuyển sang Qdrant hay Milvus khi số lượng vector và yêu cầu độ trễ thực sự vượt ngưỡng.

Câu hỏi thường gặp

Lưu ý: Bài viết tổng hợp từ nguồn công khai tại 20/07/2026. Số phiên bản và số sao GitHub là ảnh chụp tại thời điểm tra cứu và sẽ thay đổi; dung lượng là kết quả tính toán từ số chiều vector (thô, chưa gồm cấu trúc index/metadata); thông số mô hình lấy từ file cấu hình chính thức. Thông tin tham khảo, không phải tư vấn kỹ thuật, đầu tư hay pháp lý.