Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang xây một trợ lý AI cho công ty bảo hiểm. Trợ lý này phải trả lời câu hỏi của khách hàng dựa trên 50.000 trang tài liệu hợp đồng. Khi khách hỏi "Tôi có được bồi thường nếu mổ nội soi không?", hệ thống phải tìm ra vài đoạn văn bản liên quan nhất trong 50.000 trang đó, chỉ trong vài chục mili-giây. Đây chính là bài toán mà vector database sinh ra để giải quyết.
Ở bài trước, bạn đã hiểu embeddings biến văn bản thành vector số nhiều chiều. Nhưng có embeddings thôi chưa đủ. Bạn cần một nơi để lưu trữ hàng triệu vector và truy vấn tìm vector gần nhất một cách cực nhanh. Nếu chọn sai công cụ ở đây, sản phẩm AI của bạn sẽ chậm, đắt, hoặc đơn giản là không scale được khi lượng dữ liệu tăng.
Với vai trò một AI Product Manager, bạn không cần tự code thuật toán tìm kiếm, nhưng bạn bắt buộc phải hiểu đủ sâu để ra quyết định: chọn Pinecone hay pgvector? Tự host hay dùng dịch vụ quản lý? Chi phí mỗi tháng sẽ là bao nhiêu khi có 10 triệu vector? Bài này trang bị cho bạn khung tư duy để trả lời những câu hỏi đó một cách tự tin, đặc biệt trong bối cảnh ngân sách và hạ tầng của các công ty Việt Nam.
Khái niệm cốt lõi
Vì sao cần database riêng cho vector
Câu hỏi đầu tiên nhiều người đặt ra: "Tôi đã có MySQL/PostgreSQL rồi, sao không lưu vector vào đó luôn?". Vấn đề nằm ở bản chất của bài toán.
Database truyền thống được thiết kế để tìm kiếm chính xác: tìm khách hàng có id = 12345, hoặc đơn hàng có status = 'pending'. Chúng dùng cấu trúc chỉ mục như B-tree hoạt động tuyệt vời với dữ liệu một chiều (số, chuỗi, ngày tháng).
Nhưng vector embedding thường có 768, 1.536 hoặc thậm chí 3.072 chiều. Bài toán không còn là "tìm giá trị bằng nhau" mà là "tìm vector gần nhất trong không gian nhiều chiều" — tức là tìm những đoạn văn bản có ý nghĩa tương đồng nhất. Đây gọi là similarity search (tìm kiếm theo độ tương đồng).
Nếu làm theo cách ngây thơ, để tìm vector gần nhất bạn phải so sánh vector truy vấn với từng vector trong database, tính khoảng cách cosine cho mỗi cái. Với 1 triệu vector 1.536 chiều, mỗi lần truy vấn cần khoảng 1,5 tỷ phép nhân. Cách này gọi là brute-force hay tìm kiếm chính xác (exact search) — đúng tuyệt đối nhưng chậm khủng khiếp khi dữ liệu lớn.
ANN — trái tim của vector database
Giải pháp là ANN (Approximate Nearest Neighbor) — tìm kiếm láng giềng gần đúng. Ý tưởng cốt lõi: thay vì tìm chính xác top-K vector gần nhất, ta chấp nhận gần đúng (ví dụ tìm được 95% trong số đúng) để đổi lấy tốc độ nhanh hơn hàng trăm lần.
Có vài thuật toán ANN phổ biến bạn nên biết tên:
- HNSW (Hierarchical Navigable Small World): xây dựng một đồ thị nhiều tầng, tìm kiếm bằng cách "nhảy" qua các nút gần nhau. Đây là thuật toán phổ biến nhất hiện nay, cân bằng tốt giữa tốc độ và độ chính xác (recall). Nhược điểm: tốn RAM.
- IVF (Inverted File Index): chia không gian vector thành các cụm (cluster), khi truy vấn chỉ tìm trong vài cụm gần nhất thay vì toàn bộ. Tiết kiệm bộ nhớ hơn HNSW.
- PQ (Product Quantization): nén vector lại để giảm dung lượng lưu trữ, thường kết hợp với IVF (gọi là IVF-PQ).
Phân loại các vector database
Thị trường vector database 2026 có thể chia thành ba nhóm:
Nhóm 1 — Dedicated managed (chuyên dụng, có dịch vụ quản lý): Pinecone, Weaviate Cloud, Qdrant Cloud. Bạn không phải lo vận hành server, chỉ gọi API. Đổi lại trả tiền theo dung lượng và lượng truy vấn.
Nhóm 2 — Open-source self-hosted (mã nguồn mở, tự vận hành): Qdrant, Milvus, Weaviate, Chroma. Bạn tự cài lên server của mình, kiểm soát hoàn toàn nhưng phải lo DevOps.
Nhóm 3 — Extension trên DB sẵn có: pgvector (cho PostgreSQL), Redis (với module RediSearch), Elasticsearch/OpenSearch. Tận dụng database bạn đã quen thuộc, không cần thêm hệ thống mới.
So sánh các lựa chọn chính
Hãy điểm qua những cái tên bạn sẽ gặp nhiều nhất:
- pgvector: extension cho PostgreSQL. Ưu điểm lớn nhất là dùng chung database với dữ liệu nghiệp vụ, dễ join, một hệ thống để quản lý. Hợp với startup, dự án dưới vài triệu vector. Nhược điểm: hiệu năng đuối khi vượt 5-10 triệu vector.
- Qdrant: viết bằng Rust, nhanh, hỗ trợ filtering mạnh (lọc theo metadata cùng lúc với similarity search), có cả bản open-source lẫn cloud. Rất được ưa chuộng 2025-2026 vì cân bằng tốt.
- Milvus: thiết kế cho quy mô tỷ vector, kiến trúc phân tán phức tạp. Mạnh nhưng vận hành nặng, hợp với enterprise lớn.
- Pinecone: dịch vụ managed thuần túy, dễ bắt đầu nhất, serverless. Đắt hơn khi scale, và dữ liệu nằm trên hạ tầng nước ngoài — điều cần cân nhắc với dữ liệu nhạy cảm tại Việt Nam.
- Chroma: nhẹ, dành cho prototype và phát triển cục bộ. Rất tốt để học và làm POC, không khuyến nghị cho production quy mô lớn.
Các tiêu chí đánh giá khi chọn
Khi đứng trước quyết định, hãy soi qua sáu trục:
- Quy mô dữ liệu: bao nhiêu vector? Vài chục nghìn hay vài chục triệu?
- Hiệu năng: yêu cầu độ trễ truy vấn bao nhiêu ms? QPS (query per second) cần đạt?
- Metadata filtering: có cần lọc kết hợp (ví dụ chỉ tìm trong tài liệu của khách hàng X, năm 2025)?
- Chi phí vận hành: tự host (tốn người DevOps) hay trả tiền managed?
- Chủ quyền dữ liệu: dữ liệu có được phép rời khỏi Việt Nam không? Đây là vấn đề pháp lý ngày càng quan trọng với Nghị định bảo vệ dữ liệu cá nhân.
- Độ trưởng thành của đội ngũ: team có người vận hành được Kubernetes, Milvus không?
Tình huống thực tế
Tình huống 1 — Startup fintech tại TP.HCM chọn pgvector
Một startup fintech với 8 kỹ sư đang xây tính năng "trợ lý tra cứu điều khoản vay". Họ có khoảng 200.000 đoạn văn bản từ các hợp đồng và quy định. Đội ngũ đã dùng PostgreSQL làm database chính cho toàn bộ nghiệp vụ.
Lúc đầu, một kỹ sư đề xuất dùng Pinecone vì "ai cũng dùng". Nhưng PM tính toán lại: với 200.000 vector, Pinecone tốn khoảng 70-100 USD/tháng, lại phải đồng bộ dữ liệu giữa hai hệ thống và dữ liệu hợp đồng khách hàng phải gửi ra server nước ngoài — rủi ro pháp lý.
Quyết định cuối cùng: dùng pgvector ngay trên PostgreSQL hiện có. Kết quả: chi phí tăng thêm gần như bằng 0 (chỉ tốn thêm RAM), truy vấn dưới 50ms với index HNSW, và quan trọng nhất là họ có thể join vector search với bảng khách hàng để lọc "chỉ tìm trong hợp đồng của user này" bằng một câu SQL duy nhất.
Bài học: Đừng chọn công cụ theo trào lưu. Với quy mô vài trăm nghìn vector và dữ liệu nhạy cảm, một extension trên database sẵn có thường là lựa chọn khôn ngoan nhất về cả chi phí lẫn pháp lý.
Tình huống 2 — Sàn thương mại điện tử chuyển từ pgvector sang Qdrant
Một sàn TMĐT Đông Nam Á xây tính năng "tìm sản phẩm bằng hình ảnh và mô tả tự nhiên". Ban đầu họ cũng dùng pgvector và mọi thứ ổn ở mức 1 triệu vector. Nhưng khi catalog tăng lên 18 triệu sản phẩm, mỗi sản phẩm có vector hình ảnh, hệ thống bắt đầu trục trặc: truy vấn lên tới 800ms vào giờ cao điểm, và việc lọc kết hợp (theo danh mục, theo khoảng giá, theo tình trạng còn hàng) cùng lúc với similarity search khiến PostgreSQL nghẽn.
Đội ngũ benchmark thử ba lựa chọn trên cùng tập dữ liệu thật: pgvector, Qdrant và Milvus. Kết quả: Milvus nhanh nhất ở quy mô này nhưng vận hành quá nặng cho team 15 người. Qdrant đạt độ trễ ~40ms ở recall 0.96, và đặc biệt filtering theo metadata cực mạnh nhờ kiến trúc lưu payload cùng vector. Họ chọn Qdrant self-hosted trên cụm server riêng.
Sau migration: độ trễ p95 giảm từ 800ms xuống 60ms, và việc lọc đa điều kiện không còn làm sập hệ thống. Chi phí: thêm 2 server và khoảng nửa người DevOps.
Bài học: Vector database không phải quyết định "một lần là xong". Khi quy mô vượt ngưỡng (thường quanh mốc 5-10 triệu vector), bạn cần benchmark trên dữ liệu thật của mình chứ không tin vào con số marketing. Và filtering mạnh thường quan trọng ngang với tốc độ thuần.
Tình huống 3 — Ngân hàng chọn Milvus self-hosted vì chủ quyền dữ liệu
Một ngân hàng lớn xây hệ thống tìm kiếm tài liệu nội bộ cho 12.000 nhân viên, với hơn 200 triệu vector từ văn bản pháp lý, quy trình, email lưu trữ. Quy định ngành ngân hàng buộc toàn bộ dữ liệu phải nằm trong data center của ngân hàng tại Việt Nam — loại bỏ hoàn toàn mọi dịch vụ cloud nước ngoài như Pinecone.
Với quy mô 200 triệu vector và yêu cầu phân tán, họ chọn Milvus triển khai trên Kubernetes nội bộ. Đội ngũ chấp nhận chi phí vận hành cao (một team 4 người chuyên trách hạ tầng AI) để đổi lấy khả năng mở rộng theo chiều ngang và kiểm soát tuyệt đối dữ liệu.
Bài học: Ở quy mô rất lớn và trong ngành bị quản lý chặt (ngân hàng, y tế, bảo hiểm), chủ quyền dữ liệu thường là yếu tố quyết định, vượt lên cả chi phí. Khi đó các giải pháp self-hosted mạnh như Milvus là lựa chọn bắt buộc, và bạn phải tính cả ngân sách con người để vận hành.
Hướng dẫn từng bước
Đây là quy trình chọn vector database cho một dự án mới:
Bước 1 — Ước lượng quy mô. Tính số lượng vector hiện tại và dự phóng 12-18 tháng tới. Nhân số document với số chunk trung bình. Ví dụ: 10.000 tài liệu × 30 chunk = 300.000 vector. Đây là con số neo cho mọi quyết định sau.
Bước 2 — Xác định yêu cầu phi chức năng. Viết ra rõ ràng: độ trễ tối đa chấp nhận được (ví dụ p95 < 100ms), QPS đỉnh, và mức recall tối thiểu. Đừng để mơ hồ.
Bước 3 — Kiểm tra ràng buộc dữ liệu và pháp lý. Dữ liệu có nhạy cảm không? Có buộc lưu tại Việt Nam không? Bước này có thể loại ngay nhóm dịch vụ cloud nước ngoài.
Bước 4 — Áp ma trận quyết định nhanh. Dùng quy tắc kinh nghiệm:
- Dưới 1 triệu vector + đã có PostgreSQL → pgvector.
- 1-10 triệu vector, cần filtering mạnh, team vừa → Qdrant.
- Trên 50 triệu vector, có team hạ tầng → Milvus.
- Cần lên production siêu nhanh, không ngại chi phí và dữ liệu không nhạy cảm → Pinecone.
- Chỉ làm prototype/học → Chroma.
Bước 6 — Tính tổng chi phí sở hữu (TCO). Cộng cả chi phí hạ tầng, license, và chi phí con người vận hành. Một giải pháp "miễn phí" open-source có thể đắt hơn nếu cần một kỹ sư full-time trông coi.
Bước 7 — Chọn index và tinh chỉnh. Sau khi chọn DB, cấu hình HNSW hoặc IVF với tham số phù hợp, đo lại recall và latency, lặp lại đến khi đạt mục tiêu ở Bước 2.
Lỗi thường gặp & mẹo
Lỗi 1 — Chọn theo độ "hot" thay vì theo nhu cầu. Nhiều team nhảy thẳng vào Pinecone hay Milvus trong khi pgvector dư sức đáp ứng. Kết quả là phức tạp hóa hệ thống không cần thiết. Mẹo: luôn bắt đầu từ lựa chọn đơn giản nhất đáp ứng được yêu cầu.
Lỗi 2 — Quên metadata filtering. Nhiều người chỉ benchmark tốc độ similarity search thuần, rồi vỡ mộng khi phát hiện filtering kết hợp làm chậm gấp 10 lần. Mẹo: luôn benchmark với điều kiện lọc giống production thật.
Lỗi 3 — Không hiểu trade-off recall và tốc độ. Đặt recall quá cao (0.99) khiến hệ thống chậm và đắt vô lý, trong khi với hầu hết ứng dụng RAG, recall 0.90-0.95 là đủ tốt. Mẹo: đo trải nghiệm người dùng thực tế ở các mức recall khác nhau, đừng tối ưu recall một cách mù quáng.
Lỗi 4 — Bỏ qua chi phí re-indexing. Khi đổi mô hình embedding, bạn phải tạo lại toàn bộ vector. Với 50 triệu vector, đây là cả một dự án tốn kém. Mẹo: ngay từ đầu, ghi lại model embedding nào đã dùng và lập kế hoạch cho việc nâng cấp.
Lỗi 5 — Đánh giá thấp chi phí RAM của HNSW. HNSW giữ index trong RAM. 10 triệu vector 1.536 chiều có thể cần 60-80GB RAM. Nhiều team sốc khi nhận hóa đơn server. Mẹo: ước lượng RAM trước, cân nhắc IVF-PQ nếu cần tiết kiệm.
Mẹo vàng: Tách biệt rõ ràng giữa lớp lưu trữ vector và lớp logic ứng dụng. Dùng một interface trừu tượng để sau này đổi vector database không phải viết lại toàn bộ — vì như tình huống 2 cho thấy, bạn rất có thể sẽ phải đổi khi scale.
Bài tập thực hành
Bài tập 1 — Lập ma trận quyết định. Cho ba kịch bản: (a) blog cá nhân có 5.000 bài viết muốn làm tìm kiếm ngữ nghĩa; (b) chuỗi bán lẻ 8 triệu sản phẩm cần tìm bằng hình ảnh; (c) bệnh viện với 100 triệu bản ghi bệnh án buộc lưu trong nước. Với mỗi kịch bản, đề xuất vector database phù hợp và viết 2-3 câu lý giải dựa trên sáu tiêu chí đã học.
Bài tập 2 — Ước lượng chi phí. Một dự án có 4 triệu vector 1.536 chiều, dùng HNSW. Hãy ước lượng dung lượng RAM cần thiết (gợi ý: mỗi vector float32 = 1.536 × 4 byte, cộng overhead đồ thị HNSW khoảng 1,5 lần). So sánh chi phí giữa tự host trên một server cloud và dùng dịch vụ managed.
Bài tập 3 — Thiết kế benchmark. Viết kế hoạch benchmark để so sánh pgvector và Qdrant cho một dự án 3 triệu vector cần filtering theo danh mục. Liệt kê: tập dữ liệu test, các mức recall đo, điều kiện filter, và metric thành công. Đây là kỹ năng PM thực chiến: biết thiết kế thí nghiệm để ra quyết định dựa trên số liệu.
Tóm tắt
Vector database tồn tại vì database truyền thống không xử lý hiệu quả bài toán tìm kiếm tương đồng trong không gian nhiều chiều. Trái tim của chúng là thuật toán ANN (HNSW, IVF, PQ), với sự đánh đổi cốt lõi giữa recall và tốc độ mà bạn — với vai trò PM — phải chủ động quyết định.
Thị trường chia làm ba nhóm: dịch vụ managed (Pinecone), open-source self-hosted (Qdrant, Milvus, Chroma), và extension trên DB sẵn có (pgvector). Không có lựa chọn "tốt nhất" tuyệt đối — chỉ có lựa chọn phù hợp nhất với quy mô, hiệu năng, filtering, chi phí, chủ quyền dữ liệu và năng lực đội ngũ của bạn.
Quy tắc thực dụng: bắt đầu đơn giản (pgvector cho dưới 1 triệu vector), chuyển sang Qdrant khi cần filtering mạnh ở quy mô triệu, và chỉ dùng Milvus khi thực sự ở quy mô hàng chục triệu vector trở lên với team hạ tầng đủ mạnh. Ba tình huống thực tế — từ startup fintech, sàn TMĐT đến ngân hàng — cho thấy quyết định luôn phụ thuộc bối cảnh, đặc biệt là yếu tố chủ quyền dữ liệu ngày càng quan trọng tại Việt Nam. Và đừng bao giờ chọn công cụ mà chưa benchmark trên dữ liệu thật của chính mình.