infoteck.vn

Xây dựng Vector Database với Milvus và Qdrant cho bài toán tìm kiếm ngữ nghĩa

34 phút đọc #Trí tuệ Nhân tạo

Trong các hệ thống Tìm kiếm Ngữ nghĩa (Semantic Search), Gợi ý Đa phương thức (Multimodal Recommendation) và Trí tuệ Nhân tạo Tạo sinh năm 2026, tầng lưu trữ và truy hồi vector ở quy mô từ hàng chục triệu đến hàng tỷ điểm dữ liệu chính là trái tim quyết định tốc độ phản hồi cũng như độ chính xác của toàn bộ ứng dụng. Khi đội ngũ kỹ thuật thực hiện xây dựng Vector Database với Milvus và Qdrant mà không nắm vững cấu trúc đồ thị chỉ mục nội tại, hệ thống sẽ lập tức vấp phải ba bức tường vật lý trên môi trường Production: bộ nhớ RAM máy chủ phình đại tới hàng trăm Gigabyte chỉ vì lưu trữ thô vector Float32, kết quả tìm kiếm trả về rỗng (Zero Recall) khi kết hợp bộ lọc quyền truy cập theo phòng ban (Metadata Pre-Filtering), hoặc mô hình nhúng ngữ nghĩa hoàn toàn bỏ sót các mã sản phẩm SKU, số hợp đồng và mã số thuế chính xác.

Trong khi bài viết về xây dựng ứng dụng AI RAG với Python và LangChain đã trình bày quy trình cắt nhỏ văn bản (Chunking) và điều phối chuỗi truy vấn ở tầng ứng dụng, bài viết chuyên sâu này đi thẳng xuống tầng cơ sở dữ liệu lõi (Storage & Indexing Engine Internals). Chúng ta sẽ giải phẫu toán học các hàm khoảng cách (Cosine, Inner Product, L2) và thuật toán chỉ mục láng giềng gần đúng ANN (HNSW, IVF_PQ, DiskANN), đặt lên bàn cân kiến trúc phân tách của Milvus 2.5+ với nhân Rust của Qdrant 1.13+, thiết lập công thức định lượng RAM kèm kỹ thuật lượng tử hóa Scalar INT8 / Binary Quantization (32x), và triển khai mã nguồn Hybrid Search (Dense + Sparse BM25) hợp nhất bằng Reciprocal Rank Fusion (RRF).

Mục Lục Nội Dung

1. Giải phẫu Toán học Tìm kiếm Ngữ nghĩa (Semantic Search) và Chỉ mục ANN trong Vector Database

Khác với cơ sở dữ liệu quan hệ truyền thống so khớp chính xác chuỗi ký tự trên cây B-Tree hoặc chỉ mục đảo (Inverted Index trong Elasticsearch), Semantic Search ánh xạ mọi đoạn văn bản, hình ảnh hoặc âm thanh qua một mô hình học sâu (như BGE-M3, text-embedding-3-large hoặc NV-Embed-v2) thành một điểm tọa độ trong không gian nhiều chiều $mathbf{v} in mathbb{R}^d$ (với số chiều $d in {768, 1024, 1536, 3072}$). Hai văn bản có cùng ý nghĩa nghiệp vụ — dù không trùng bất kỳ từ khóa bề mặt nào — sẽ nằm gần nhau về mặt hình học trong không gian $mathbb{R}^d$.

1.1. Không gian Vector nhiều chiều (High-Dimensional Embeddings) và lựa chọn hàm khoảng cách: Cosine Similarity, Inner Product (IP) vs Euclidean ($L_2$)

Khi khởi tạo một Collection trong Milvus hoặc Qdrant, quyết định kỹ thuật đầu tiên và không thể thay đổi về sau là chọn Hàm đo khoảng cách (Distance Metric) giữa vector truy vấn $mathbf{A}$ và vector tài liệu $mathbf{B}$:

  1. Cosine Similarity (Độ tương đồng Cosine): Đo cô-sin của góc $theta$ giữa hai vector mà không phụ thuộc vào độ dài (biên độ) của chúng:
    $$text{Cosine}(mathbf{A}, mathbf{B}) = frac{mathbf{A} cdot mathbf{B}}{|mathbf{A}|_2 |mathbf{B}|2} = frac{sum{i=1}^{d} A_i Bi}{sqrt{sum{i=1}^{d} Ai^2} sqrt{sum{i=1}^{d} B_i^2}} in [-1, 1]$$
  2. Inner Product / Dot Product (IP — Tích vô hướng):
    $$text{IP}(mathbf{A}, mathbf{B}) = mathbf{A} cdot mathbf{B} = sum_{i=1}^{d} A_i B_i$$
  3. Euclidean Distance (L2 — Khoảng cách đường thẳng Hình học):
    $$d_{L_2}(mathbf{A}, mathbf{B}) = |mathbf{A} - mathbf{B}|2 = sqrt{sum{i=1}^{d} (A_i - B_i)^2}$$

[!TIP]
Mẹo Tối ưu Hóa Tập lệnh SIMD (AVX-512 / ARM NEON) trên Production:
Hầu hết các mô hình Embedding hiện đại năm 2026 (BGE-M3, OpenAI text-embedding-3, Cohere Embed v3) đều xuất ra các vector đã được chuẩn hóa độ dài đơn vị (L2-Normalized: $|mathbf{A}|_2 = |mathbf{B}|_2 = 1.0$). Khi hai vector có độ dài bằng 1, mẫu số của công thức Cosine luôn bằng 1, nghĩa là Inner Product (IP) hoàn toàn tương đương về mặt toán học với Cosine Similarity nhưng tiết kiệm được hai phép tính căn bậc hai và tổng bình phương trên mỗi lần so khớp! Trong Qdrant 1.13+, khi bạn chọn Distance.COSINE, engine tự động chuẩn hóa vector một lần duy nhất lúc ghi (Upsert) và chuyển toàn bộ phép tìm kiếm bên dưới thành phép tính Dot Product siêu tốc.

1.2. Cơ chế hoạt động của đồ thị phân tầng HNSW so với IVF_PQ và DiskANN (Vamana Graph)

Nếu thực hiện tìm kiếm vét cạn (Flat / Brute-Force Exact k-NN) trên 50,000,000 vector có $d = 1024$ chiều, mỗi truy vấn đơn lẻ phải thực hiện $5 times 10^{10}$ phép tính dấu phẩy động, mất hàng giây đồng hồ. Để đưa độ trễ truy vấn xuống dưới 5 ms, các hệ quản trị Vector Database sử dụng thuật toán Approximate Nearest Neighbor (ANN) đánh đổi một phần rất nhỏ độ phủ (Recall@10 đạt 98% – 99.5%) để giảm độ phức tạp từ tuyến tính $O(N)$ xuống logarit $O(log N)$:

Thuật toán Chỉ mục ANN Nguyên lý Cấu trúc Dữ liệu Siêu tham số Điều khiển Cốt lõi Ưu điểm & Kịch bản Quy mô Chuẩn Production
HNSW (Hierarchical Navigable Small World — Malkov & Yashunin) Đồ thị láng giềng đa tầng kết hợp danh sách nhảy (Skip-List): tầng trên cùng thưa để nhảy bước dài, tầng 0 dày đặc để định vị chính xác. - M (16–64): Số cạnh nối tối đa mỗi nút.
- efConstruction (128–512): Độ rộng hàng đợi khi dựng đồ thị.
- ef / hnsw_ef (64–256): Độ rộng tìm kiếm lúc truy vấn.		 Chuẩn vàng mặc định cho quy mô 100K – 100M vectors: tốc độ truy vấn cực nhanh (1–5 ms), Recall@10 > 99%, hỗ trợ thêm/xóa vector động theo thời gian thực.
IVF_PQ (Inverted File + Product Quantization) Gom cụm không gian bằng k-Means (nlist tâm cụm Voronoi) và nén vector thành các mã từ điển con (m sub-vectors). - nlist (1024–65536): Số tâm cụm.
- nprobe (16–128): Số cụm quét khi tìm kiếm.
- m (16–64): Số phân đoạn mã hóa PQ.		 Tiết kiệm RAM mạnh khi chạy trên GPU (Milvus CAGRA / GPU_IVF_PQ), nhưng giảm Recall nếu không kết hợp bước tính lại điểm (Refinement).
DiskANN (Vamana Single-Layer Graph trên NVMe SSD) Giữ vector nén PQ trong RAM (~6% dung lượng) nhưng lưu đồ thị Vamana và vector gốc Float32 trực tiếp trên ổ cứng NVMe tốc độ cao. - MaxDegree (32–64)
- SearchListSize (100–200)
- PQCodeBudgetGB		 Giải pháp tối ưu chi phí cho quy mô 100M – 5B+ vectors khi không muốn thuê hàng Terabyte bộ nhớ DRAM đắt đỏ.

2. Đặt lên bàn cân Kiến trúc: Milvus 2.5+ (Cloud-Native Disaggregated) vs Qdrant 1.13+ (Rust Monolithic/Distributed)

Khi xây dựng Vector Database với Milvus và Qdrant, việc hiểu rõ triết lý thiết kế kiến trúc khác biệt giữa hai hệ quản trị hàng đầu này giúp kiến trúc sư lựa chọn đúng công cụ theo quy mô dữ liệu và năng lực vận hành của đội ngũ DevOps/SRE.

flowchart TB
    subgraph Milvus25["Kiến trúc Milvus 2.5+ (Cloud-Native Storage-Compute Disaggregation)"]
        MProxy["Stateless Access Proxy (gRPC / REST)"] --> MCoord["Coordinator Plane (Root / Query / Data / Index Coord)"]
        MProxy --> MQNode["QueryNode Workers (C++ Knowhere SIMD Engine - HNSW / DiskANN)"]
        MProxy --> MDNode["DataNode & IndexNode Workers (Streaming Ingestion & Compaction)"]
        MQNode --> MS3["Shared Storage Plane: MinIO / AWS S3 Object Storage + Woodpecker/Pulsar WAL + etcd"]
        MDNode --> MS3
    end

    subgraph Qdrant113["Kiến trúc Qdrant 1.13+ (Rust High-Performance Shard/Segment Engine)"]
        QAPI["Unified gRPC / REST Endpoint"] --> QRaft["Raft Consensus & Collection Shard Router"]
        QRaft --> QSeg1["Rust Segment 1: Filterable HNSW + Payload Index (is_tenant=True)"]
        QRaft --> QSeg2["Rust Segment 2: Scalar INT8 / Binary Quantization + Linux io_uring mmap"]
    end

2.1. Kiến trúc tách rời Lưu trữ & Tính toán (Storage-Compute Disaggregation) của Milvus 2.5+

Milvus 2.5+ được thiết kế từ đầu theo kiến trúc Cloud-Native Phân tách Lưu trữ và Tính toán dành riêng cho môi trường Kubernetes quy mô lớn:

  1. Bốn mặt phẳng độc lập: Tầng cổng truy cập phi trạng thái (Access Proxy), tầng điều phối (Coordinator Service dùng etcd), tầng nút tính toán (QueryNode phục vụ tìm kiếm, DataNode ghi luồng dữ liệu, IndexNode chuyên dựng chỉ mục nặng CPU viết bằng C++ Knowhere), và tầng lưu trữ bền vững dùng chung (MinIO / S3 Object Storage kết hợp nhật ký Woodpecker / Apache Pulsar WAL).
  2. Khả năng co giãn đàn hồi độc lập (Independent Elastic Scaling): Khi hệ thống bước vào giờ cao điểm truy vấn RAG từ người dùng nhưng không có tác vụ nạp tài liệu mới, bạn có thể nhân rộng riêng số lượng Pod QueryNode từ 2 lên 16 Pod mà không tốn thêm CPU cho DataNode hay IndexNode. Đặc biệt, Milvus 2.5+ tích hợp sẵn bộ tạo vector thưa BM25 nguyên bản (FunctionType.BM25) ngay trong engine mà không cần tính toán từ phía ứng dụng.

2.2. Kiến trúc Rust hiệu năng cao và cơ chế Filterable HNSW nguyên bản của Qdrant 1.13+

Ngược lại, Qdrant 1.13+ được viết hoàn toàn bằng ngôn ngữ Rust (không có Garbage Collector, không bị hiện tượng dừng hình GC Pause), đóng gói mọi thành phần vào một tệp thực thi duy nhất có thể chạy từ chế độ 1 container đơn giản cho đến cụm phân tán đa nút đồng thuận qua giao thức Raft:

  1. Giải quyết triệt để bài toán "Filtered ANN Search" bằng Filterable HNSW:
    Trong tìm kiếm doanh nghiệp, hầu như mọi truy vấn vector đều đi kèm điều kiện lọc siêu dữ liệu (ví dụ: WHERE tenant_id = 'org_88' AND department = 'legal').

    • Nếu lọc sau khi tìm kiếm (Post-Filtering: lấy Top-100 vector gần nhất rồi mới lọc theo tenant_id), khi khách hàng org_88 chỉ chiếm 0.5% dữ liệu, kết quả trả về sẽ hoàn toàn trống rỗng!
    • Nếu lọc trước khi tìm kiếm (Naive Pre-Filtering: xóa tất cả các nút không thuộc org_88 khỏi đồ thị HNSW), các cầu nối trên đồ thị HNSW bị đứt gãy (Disconnected Graph), khiến thuật toán tìm kiếm bị kẹt ở cực trị địa phương.
    • Đột phá của Qdrant: Khi bạn đánh chỉ mục cho trường payload (create_payload_index), Qdrant tự động xây dựng thêm các cạnh nối đồ thị con (Subgraph Extra Links) cho từng giá trị trường lọc ngay bên trong cấu trúc HNSW, kết hợp bộ lập kế hoạch truy vấn thông minh (Cardinality-Based Query Planner) và cơ chế đọc đĩa bất đồng bộ Linux io_uring.
Tiêu chí Đối chiếu Milvus 2.5+ (LF AI & Data Foundation) Qdrant 1.13+ (Rust Engine)
Ngôn ngữ Lõi & Kiến trúc Go (Điều phối) + C++ Knowhere (Tính toán), tách rời Storage/Compute. 100% Rust nguyên khối hoặc phân mảnh theo Shard/Raft.
Độ phức tạp Vận hành Cao hơn ở chế độ Distributed (cần quản lý etcd, MinIO/S3, Woodpecker/Pulsar). Rất gọn nhẹ: Không phụ thuộc dịch vụ ngoài; triển khai 1 Binary / StatefulSet duy nhất.
Cơ chế Lọc Payload kết hợp ANN Bitset Pre-Filtering + Iterative Filtering + Partition Key (is_partition_key=True). Filterable HNSW nguyên bản (nối cạnh đồ thị theo Payload) + is_tenant=True co-location.
Hỗ trợ Nén Lượng tử hóa (Quantization) SQ8, PQ, FP16, BF16, Binary, và chỉ mục đĩa DiskANN. Scalar (INT8), Product (PQ), và Binary Quantization (1-bit) kèm oversampling + rescore cực kỳ linh hoạt.
Kịch bản Lựa chọn Tối ưu Cụm dữ liệu khổng lồ 100M – 10B+ vectors trên Kubernetes cần tách biệt hoàn toàn tài nguyên đọc/ghi hoặc cần GPU Index (CAGRA). Hệ thống RAG, Agentic AI và Semantic Search quy mô 1M – 200M vectors đòi hỏi độ trễ p99 cực thấp, lọc Payload phức tạp và vận hành tinh gọn.

3. Quy hoạch Bộ nhớ RAM và Kỹ thuật Nén Vector (Scalar, Product & Binary Quantization)

Khi thiết kế hạ tầng máy chủ (đặc biệt khi kết hợp với các thông số nhân hệ điều hành đã phân tích trong bài giám sát tài nguyên hệ thống và tối ưu bộ nhớ RAM/Swap trên Linux), việc tính toán chính xác dung lượng RAM trước khi nạp dữ liệu là bước bắt buộc để tránh sự cố tràn bộ nhớ.

3.1. Công thức tính dung lượng RAM cho chỉ mục HNSW (Float32) ở quy mô hàng chục triệu Vector

Một vector chuẩn Float32 chiếm 4 bytes cho mỗi chiều dữ liệu. Ngoài bản thân vector, đồ thị HNSW cần lưu trữ danh sách các cạnh nối hai chiều (tối đa $2 times M$ liên kết ở tầng 0, mỗi định danh điểm chiếm 4–8 bytes). Công thức định lượng dung lượng RAM thực tế cho $N$ vectors có số chiều $d$ và tham số đồ thị $M$ là:

$$text{RAM}_{text{HNSW (Float32)}} approx N times left( d times 4text{ bytes} + M times 2 times 8text{ bytes} right) times 1.20text{ (Hệ số đệm quản lý Segment & Metadata)}$$

Ví dụ thực tế: Với $N = 10,000,000$ (10 triệu) vectors có số chiều $d = 1024$ (mô hình BGE-M3 hoặc Llama-3 embedding) và $M = 32$:

  • Bộ nhớ chứa Vector thô: $10^7 times 1024 times 4text{ bytes} approx 40.96text{ GB}$.
  • Bộ nhớ chứa cạnh đồ thị HNSW: $10^7 times 32 times 16text{ bytes} approx 5.12text{ GB}$.
  • Nhân hệ số đệm 1.20: Tổng cộng tốn khoảng 55.3 GB RAM vật lý!

3.2. Giảm 4x–32x RAM với Scalar Quantization (INT8), Product Quantization (PQ) và Binary Quantization kết hợp Rescoring

Làm thế nào để phục vụ cùng 10 triệu vectors đó chỉ với 2 GB – 14 GB RAM mà vẫn giữ nguyên 99% độ chính xác Recall@10? Câu trả lời nằm ở kiến trúc Nén Lượng tử hóa trong RAM kết hợp Chấm điểm lại từ Đĩa NVMe (In-RAM Quantized Search + On-Disk Oversampled Rescoring):

  1. Scalar Quantization (SQ8 / INT8 — Giảm 4x dung lượng vector): Ánh xạ từng số thực Float32 (4 bytes) sang số nguyên có dấu INT8 (1 byte, từ -128 đến 127) dựa trên phân vị quantile = 0.99 để loại bỏ giá trị ngoại lai. Dung lượng bộ nhớ vector giảm ngay 75%, trong khi độ chính xác Recall@10 chỉ chênh lệch dưới 0.5%!
  2. Binary Quantization (BQ / 1-bit — Giảm 32x dung lượng vector): Với các vector số chiều cao ($d ge 1024$), dấu của từng chiều ($text{bit}_i = 1$ nếu $x_i > 0$, ngược lại $0$) mang phần lớn thông tin hướng hình học. Binary Quantization nén mỗi chiều từ 32 bits xuống đúng 1 bit (1024 chiều chỉ còn đúng 128 bytes!). Hơn nữa, khoảng cách giữa hai vector nhị phân được tính bằng phép toán cổng logic XOR kết hợp lệnh phần cứng đếm bit POPCNT của CPU, tăng tốc độ quét đồ thị lên gấp 10–20 lần.
  3. Cơ chế Oversampling + Rescoring từ đĩa mmap: Để bù đắp hoàn toàn sai số lượng tử hóa, khi người dùng yêu cầu lấy limit = 10 kết quả tốt nhất, Vector DB sẽ dùng chỉ mục INT8 hoặc Binary nằm trong RAM để tìm nhanh oversampling * limit = 3.0 * 10 = 30 ứng viên tiềm năng nhất, sau đó chỉ đọc đúng 30 vector gốc Float32 từ đĩa NVMe (qua mmap / io_uring) lên để tính lại khoảng cách chính xác rồi trả về Top-10 cuối cùng!

# file: vector_ram_quantization_calculator.py
# Runtime: Python 3.13+ | Công cụ tính toán dung lượng RAM & Quantization cho HNSW
from __future__ import annotations

from dataclasses import dataclass

@dataclass(slots=True, frozen=True)
class HNSWMemoryEstimate:
    mode: str
    vector_ram_gb: float
    graph_ram_gb: float
    total_ram_with_overhead_gb: float

def estimate_hnsw_memory(
    num_vectors: int,
    dim: int = 1024,
    m_links: int = 32,
    overhead_factor: float = 1.20,
) -> list[HNSWMemoryEstimate]:
    """
    Tính toán dung lượng RAM cần thiết cho chỉ mục HNSW ở 3 chế độ:
    1. Float32 (4 bytes/dim) trong RAM hoàn toàn
    2. Scalar Quantization INT8 (1 byte/dim) trong RAM, Float32 gốc lưu trên đĩa mmap
    3. Binary Quantization 1-bit (0.125 byte/dim) trong RAM, Float32 gốc lưu trên đĩa mmap
    """
    gib = 1024**3
    graph_bytes = num_vectors * m_links * 2 * 8  # Danh sách kề 2 chiều ở tầng 0

    modes = [
        ("Full Float32 in RAM", 4.0),
        ("Scalar Quantization (INT8 in RAM + Disk Rescore)", 1.0),
        ("Binary Quantization (1-bit in RAM + Disk Rescore)", 0.125),
    ]

    estimates: list[HNSWMemoryEstimate] = []
    for label, bytes_per_dim in modes:
        vec_bytes = num_vectors * dim * bytes_per_dim
        total_bytes = (vec_bytes + graph_bytes) * overhead_factor
        estimates.append(
            HNSWMemoryEstimate(
                mode=label,
                vector_ram_gb=round(vec_bytes / gib, 2),
                graph_ram_gb=round(graph_bytes / gib, 2),
                total_ram_with_overhead_gb=round(total_bytes / gib, 2),
            )
        )
    return estimates

if __name__ == "__main__":
    for item in estimate_hnsw_memory(num_vectors=10_000_000, dim=1024, m_links=32):
        print(
            f"{item.mode:<50} | Vec: {item.vector_ram_gb:>6.2f} GiB "
            f"| Graph: {item.graph_ram_gb:>5.2f} GiB | Total RAM: {item.total_ram_with_overhead_gb:>6.2f} GiB"
        )

4. Triển khai Cụm Production và Hybrid Search (Dense + Sparse BM25) với Reciprocal Rank Fusion (RRF)

Khi tích hợp Vector Database với mô hình ngôn ngữ lớn đã qua fine-tuning mô hình mã nguồn mở Llama 3 hoặc hệ thống tích hợp LLM vào sản phẩm với LangChain và LlamaIndex, chỉ sử dụng một vector ngữ nghĩa đặc (Dense Vector) là không đủ cho môi trường doanh nghiệp.

sequenceDiagram
    autonumber
    participant SearchAPI as RAG / Search Service (Python 3.13+)
    participant EmbedSvc as BGE-M3 / Embedding & BM25 Tokenizer
    participant VectorDB as Qdrant 1.13+ / Milvus 2.5+ Engine
    participant DiskStore as NVMe mmap Storage (Original Float32)

    SearchAPI->>EmbedSvc: Truy vấn: "Điều khoản phạt chậm thanh toán hợp đồng HD-2026-9981"
    EmbedSvc-->>SearchAPI: Trả về Dense Vector (1024d) + Sparse Lexical Vector (BM25/SPLADE)
    SearchAPI->>VectorDB: Gửi yêu cầu Hybrid Search (Filter: tenant_id="org_fin", Top-K=10)
    par Nhánh 1: Tìm kiếm Ngữ nghĩa (Dense HNSW + INT8 Quantization)
        VectorDB->>VectorDB: Duyệt Filterable HNSW trong RAM lấy 30 ứng viên (Oversampling 3x)
        VectorDB->>DiskStore: Đọc 30 vector Float32 gốc qua io_uring để Rescore chính xác
    and Nhánh 2: Tìm kiếm Từ khóa Chính xác (Sparse Inverted Index BM25)
        VectorDB->>VectorDB: Khớp chính xác mã "HD-2026-9981" lấy Top-30 ứng viên từ khóa
    end
    VectorDB->>VectorDB: Hợp nhất 2 danh sách bằng công thức Reciprocal Rank Fusion (RRF, k=60)
    VectorDB-->>SearchAPI: Trả về Top-10 tài liệu chuẩn xác nhất (Latency p99 < 8ms)

4.1. Tại sao Dense Semantic Search đơn thuần thất bại trước mã SKU, số hợp đồng và từ khóa chính xác?

Các mô hình Dense Embedding nén toàn bộ đoạn văn 500 từ vào một vector 1024 số thực duy nhất. Quá trình nén ngữ nghĩa này giữ lại rất tốt khái niệm tổng quát ("chậm thanh toán" $approx$ "quá hạn trả nợ"), nhưng lại làm mờ đi các chuỗi ký tự định danh hiếm gặp như mã linh kiện SKU-AX9902-VN, mã lỗ hổng CVE-2026-4102, số quyết định pháp quy hay tên riêng.

Để đạt độ chính xác tuyệt đối trên cả hai mặt trận, kiến trúc Hybrid Search lưu trữ song song hai biểu diễn cho mỗi tài liệu ngay trong cùng một bản ghi của Vector Database:

  1. Dense Vector (1024d Float32/INT8): Bắt trọn ngữ nghĩa ngữ cảnh và từ đồng nghĩa đa ngôn ngữ.
  2. Sparse Vector (BM25 hoặc SPLADE): Vector thưa có chiều bằng kích thước từ điển nhưng chỉ có vài chục phần tử khác 0 tương ứng với trọng số tần suất từ khóa chính xác (TF-IDF / BM25).
  3. Hợp nhất thứ hạng bằng Reciprocal Rank Fusion (RRF — Cormack et al.): Thay vì cộng trực tiếp điểm Cosine (0.82) với điểm BM25 (14.7) vốn có thang đo hoàn toàn khác nhau, thuật toán RRF tính điểm hợp nhất dựa trên vị trí xếp hạng ($text{rank}_m(d) in {1, 2, dots}$) của tài liệu $d$ trong từng nhánh tìm kiếm $m in {text{dense}, text{sparse}}$ với hằng số làm mượt $k = 60$:

$$text{RRFScore}(d) = frac{1}{60 + text{rank}{text{dense}}(d)} + frac{1}{60 + text{rank}_{text{sparse}}(d)}$$

4.2. Triển khai Hybrid Search + Payload Filtering thực chiến trên Qdrant 1.13+ và Milvus 2.5+ bằng Python 3.13+

Trước tiên, dưới đây là cấu hình triển khai container chuẩn Production cho Qdrant v1.13.0 (đã mở khóa giới hạn bộ nhớ memlock và cấu hình thư mục lưu trữ bền vững):

# file: docker-compose-vector-db.yaml
# Triển khai cụm Qdrant v1.13.0 chuẩn Production trên Linux 6.12 LTS
services:
  qdrant-node:
    image: qdrant/qdrant:v1.13.0
    container_name: infoteck-qdrant-prod
    restart: unless-stopped
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    ports:
      - "6333:6333" # HTTP REST & Web UI
      - "6334:6334" # High-Performance gRPC Port
    environment:
      QDRANT__SERVICE__GRPC_PORT: "6334"
      QDRANT__STORAGE__PERFORMANCE__MAX_SEARCH_THREADS: "8"
      QDRANT__STORAGE__OPTIMIZERS__MEMMAP_THRESHOLD_KB: "20000"
      QDRANT__TELEMETRY_DISABLED: "true"
    volumes:
      - /data/nvme0/qdrant_storage:/qdrant/storage:z
      - /data/nvme0/qdrant_snapshots:/qdrant/snapshots:z

Đoạn mã Python 3.13+ dưới đây triển khai trọn vẹn kiến trúc Multi-Tenant Hybrid Search (Prefetch + Fusion.RRF) kết hợp ScalarQuantization (INT8) và Oversampling Rescore trên Qdrant 1.13+:

# file: qdrant_hybrid_rrf_production.py
# Runtime: Python 3.13+ | Dependencies: qdrant-client>=1.13.0
from __future__ import annotations

from qdrant_client import QdrantClient, models

COLLECTION_NAME = "enterprise_knowledge_v1"

def initialize_qdrant_hybrid_collection(client: QdrantClient) -> None:
    if client.collection_exists(COLLECTION_NAME):
        return

    client.create_collection(
        collection_name=COLLECTION_NAME,
        # 1. Cấu hình Named Dense Vector (1024 chiều, lưu gốc trên đĩa mmap để tiết kiệm RAM)
        vectors_config={
            "dense_bge_m3": models.VectorParams(
                size=1024,
                distance=models.Distance.COSINE,
                on_disk=True,
                hnsw_config=models.HnswConfigDiff(
                    m=32,
                    ef_construct=200,
                    on_disk=False,  # Giữ đồ thị điều hướng HNSW trong RAM để nhảy bước cực nhanh
                ),
            )
        },
        # 2. Cấu hình Sparse Lexical Vector cho tìm kiếm từ khóa chính xác BM25/SPLADE
        sparse_vectors_config={
            "sparse_bm25": models.SparseVectorParams(
                index=models.SparseIndexParams(on_disk=False)
            )
        },
        # 3. Kích hoạt Scalar Quantization INT8 giữ trong RAM (Giảm 4x RAM, Recall > 99%)
        quantization_config=models.ScalarQuantization(
            scalar=models.ScalarQuantizationConfig(
                type=models.ScalarType.INT8,
                quantile=0.99,
                always_ram=True,
            )
        ),
    )

    # 4. Tạo chỉ mục Payload đa khách hàng (is_tenant=True giúp gom cụm vật lý theo tenant_id)
    client.create_payload_index(
        collection_name=COLLECTION_NAME,
        field_name="tenant_id",
        field_schema=models.KeywordIndexParams(
            type=models.KeywordIndexType.KEYWORD,
            is_tenant=True,
        ),
    )

def search_hybrid_rrf_qdrant(
    client: QdrantClient,
    tenant_id: str,
    query_dense: list[float],
    query_sparse_indices: list[int],
    query_sparse_values: list[float],
    top_k: int = 10,
) -> list[models.ScoredPoint]:
    """
    Thực thi truy vấn Hybrid Search qua Unified Query API (query_points):
    - Áp dụng bộ lọc bảo mật đa khách hàng (tenant_id) cho cả 2 nhánh Prefetch.
    - Nhánh Dense dùng INT8 Quantization kèm oversampling=3.0 và rescore=True từ đĩa.
    - Hợp nhất kết quả bằng Reciprocal Rank Fusion (Fusion.RRF).
    """
    tenant_filter = models.Filter(
        must=[
            models.FieldCondition(
                key="tenant_id",
                match=models.MatchValue(value=tenant_id),
            )
        ]
    )

    response = client.query_points(
        collection_name=COLLECTION_NAME,
        prefetch=[
            models.Prefetch(
                query=query_dense,
                using="dense_bge_m3",
                filter=tenant_filter,
                limit=top_k * 3,
                params=models.SearchParams(
                    hnsw_ef=128,
                    quantization=models.QuantizationSearchParams(
                        ignore=False,
                        rescore=True,
                        oversampling=3.0,
                    ),
                ),
            ),
            models.Prefetch(
                query=models.SparseVector(
                    indices=query_sparse_indices,
                    values=query_sparse_values,
                ),
                using="sparse_bm25",
                filter=tenant_filter,
                limit=top_k * 3,
            ),
        ],
        query=models.FusionQuery(fusion=models.Fusion.RRF),
        limit=top_k,
        with_payload=True,
    )
    return response.points

Tương tự, nếu kiến trúc của bạn vận hành trên Milvus 2.5+, bạn có thể khai thác tính năng Built-in BM25 Function (tự động chuyển văn bản thô thành SPARSE_FLOAT_VECTOR bên trong Milvus) kết hợp khóa phân vùng đa khách hàng partition_key_field="tenant_id" và bộ xếp hạng RRFRanker(k=60):

# file: milvus25_native_bm25_hybrid_search.py
# Runtime: Python 3.13+ | Dependencies: pymilvus>=2.5.0
from __future__ import annotations

from pymilvus import (
    AnnSearchRequest,
    DataType,
    Function,
    FunctionType,
    MilvusClient,
    RRFRanker,
)

def setup_and_query_milvus_hybrid(
    uri: str,
    tenant_id: str,
    query_text: str,
    query_dense_vec: list[float],
) -> list[dict]:
    client = MilvusClient(uri=uri)
    collection_name = "milvus_enterprise_hybrid_v25"

    if not client.has_collection(collection_name):
        schema = MilvusClient.create_schema(auto_id=False, enable_dynamic_field=True)
        schema.add_field(field_name="doc_id", datatype=DataType.VARCHAR, is_primary=True, max_length=64)
        schema.add_field(
            field_name="tenant_id",
            datatype=DataType.VARCHAR,
            max_length=64,
            is_partition_key=True,  # Tự động phân vùng vật lý theo Tenant (Multi-Tenancy)
        )
        schema.add_field(
            field_name="raw_text",
            datatype=DataType.VARCHAR,
            max_length=8192,
            enable_analyzer=True,
        )
        schema.add_field(field_name="dense_vec", datatype=DataType.FLOAT_VECTOR, dim=1024)
        schema.add_field(field_name="sparse_bm25_vec", datatype=DataType.SPARSE_FLOAT_VECTOR)

        # Đăng ký hàm BM25 nội tại của Milvus 2.5+: tự động sinh sparse_bm25_vec từ raw_text
        bm25_fn = Function(
            name="text_bm25_emb",
            input_field_names=["raw_text"],
            output_field_names=["sparse_bm25_vec"],
            function_type=FunctionType.BM25,
        )
        schema.add_function(bm25_fn)

        index_params = client.prepare_index_params()
        index_params.add_index(
            field_name="dense_vec",
            index_type="HNSW",
            metric_type="IP",
            params={"M": 32, "efConstruction": 200},
        )
        index_params.add_index(
            field_name="sparse_bm25_vec",
            index_type="SPARSE_INVERTED_INDEX",
            metric_type="BM25",
        )
        client.create_collection(collection_name=collection_name, schema=schema, index_params=index_params)

    # Thực thi Hybrid Search kết hợp Dense IP + Native BM25 với RRFRanker(k=60)
    expr_filter = f'tenant_id == "{tenant_id}"'
    dense_req = AnnSearchRequest(
        data=[query_dense_vec],
        anns_field="dense_vec",
        param={"metric_type": "IP", "params": {"ef": 128}},
        limit=30,
        expr=expr_filter,
    )
    sparse_req = AnnSearchRequest(
        data=[query_text],
        anns_field="sparse_bm25_vec",
        param={"metric_type": "BM25"},
        limit=30,
        expr=expr_filter,
    )

    results = client.hybrid_search(
        collection_name=collection_name,
        reqs=[dense_req, sparse_req],
        ranker=RRFRanker(k=60),
        limit=10,
        output_fields=["doc_id", "raw_text", "tenant_id"],
    )
    return results[0]

5. Vận hành Đa khách hàng (Multi-Tenancy), Sao lưu Snapshot và Giám sát Prometheus trên Production

5.1. Thiết kế Multi-Tenancy bằng Payload Partitioning (is_tenant=True / Partition Key) thay vì tạo hàng nghìn Collection

Một phản mẫu kiến trúc phổ biến khiến các cụm Qdrant hoặc Milvus bị treo cứng trên Production là tạo một Collection vật lý riêng biệt cho mỗi khách hàng (1 Tenant = 1 Collection) khi hệ thống có hàng nghìn tổ chức đăng ký. Mỗi Collection trong Vector Database đều duy trì các phân đoạn (Segments), luồng nén nền (Background Compaction/Indexing Threads) và bảng siêu dữ liệu riêng; khi số lượng Collection vượt quá 1,000, chi phí quản lý lịch trình của hệ điều hành sẽ làm tê liệt CPU ngay cả khi không có truy vấn nào.

Quy tắc thiết kế Multi-Tenancy chuẩn năm 2026:

  • Gộp toàn bộ các khách hàng thông thường vào một Collection dùng chung, phân tách nghiêm ngặt ở tầng dữ liệu bằng khóa tenant_id được cấu hình is_tenant=True (trong Qdrant 1.13+) hoặc is_partition_key=True (trong Milvus 2.5+). Engine sẽ tự động sắp xếp các vector của cùng một tenant_id nằm liền kề nhau trên cùng các khối bộ nhớ/đĩa (Co-located Storage Blocks), mang lại tốc độ đọc tuần tự nhanh như một Collection riêng nhưng chỉ tốn tài nguyên quản trị của một Collection duy nhất.
  • Chỉ tách Collection hoặc cụm vật lý riêng biệt (Dedicated Tier) cho các khách hàng Enterprise VIP có quy mô trên 50 triệu vectors hoặc có yêu cầu pháp lý bắt buộc cô lập phần cứng.

5.2. Tối ưu hóa HNSW Segment Compaction, WAL Tuning và Giám sát P99 Recall/Latency

Để bảo vệ an toàn dữ liệu và theo dõi sức khỏe cụm Vector Database theo thời gian thực, hãy thiết lập quy trình chụp ảnh nhanh (Snapshot Backup) định kỳ đẩy lên S3/MinIO và giám sát điểm cuối /metrics chuẩn Prometheus:

#!/usr/bin/env bash
# file: qdrant_snapshot_and_health_check.sh
set -euo pipefail

QDRANT_URL="http://localhost:6333"
COLLECTION="enterprise_knowledge_v1"

echo "=== [1/3] Kiểm tra trạng thái Optimizer & Số lượng Segments của Collection ==="
curl -sS "${QDRANT_URL}/collections/${COLLECTION}" | jq '{
  status: .result.status,
  optimizer_status: .result.optimizer_status,
  points_count: .result.points_count,
  segments_count: .result.segments_count
}'

echo "=== [2/3] Tạo bản sao lưu nhất quán (Point-in-Time Snapshot) ==="
SNAPSHOT_NAME=$(curl -sS -X POST "${QDRANT_URL}/collections/${COLLECTION}/snapshots?wait=true" | jq -r '.result.name')
echo "Đã khởi tạo thành công Snapshot: ${SNAPSHOT_NAME}"

echo "=== [3/3] Kiểm tra chỉ số độ trễ tìm kiếm gRPC và số bộ sưu tập từ Prometheus /metrics ==="
curl -sS "${QDRANT_URL}/metrics" | grep -E "^(qdrant_collections_total|qdrant_grpc_responses_duration_seconds)" | head -n 15

6. Bảng Khuyến Nghị Lựa Chọn Kiến Trúc & Tài Liệu Tham Khảo Chuẩn Kỹ Thuật

6.1. Checklist nghiệm thu cụm Vector Database trước khi golive

  1. Chuẩn hóa Vector & Metric: Đảm bảo vector đầu vào đã chuẩn hóa $L_2 = 1.0$ và cấu hình Cosine / IP đồng nhất giữa bước nạp (Ingestion) và bước tìm kiếm (Query).
  2. Định cỡ RAM & Quantization: Kích hoạt ScalarQuantization (INT8, always_ram=True) hoặc BinaryQuantization kèm oversampling >= 2.5 và rescore=True khi tập dữ liệu vượt quá 2 triệu vectors.
  3. Bắt buộc đánh chỉ mục Payload trước khi nạp dữ liệu lớn: Luôn gọi create_payload_index (is_tenant=True) cho các trường lọc cố định ngay sau khi tạo Collection để Qdrant dựng sẵn cạnh nối Filterable HNSW.
  4. Cấu hình hệ điều hành Linux: Tăng giới hạn vm.max_map_count = 1048576 và khóa vm.swappiness = 1 để bảo vệ các trang đồ thị HNSW không bị đẩy ra vùng nhớ Swap.

6.2. Quy trình kiểm thử độ phủ Recall@10 thực nghiệm trước khi chọn siêu tham số ef

Trước khi cố định giá trị hnsw_ef trên Production, hãy lấy mẫu ngẫu nhiên 1,000 câu truy vấn thực tế, chạy tìm kiếm chính xác (exact=True) làm nhãn chuẩn (Ground Truth), sau đó đo tỷ lệ giao thoa Recall@10 với các mức hnsw_ef từ 64, 128 đến 256 để chọn điểm cân bằng tối ưu giữa SLA độ trễ p99 < 10ms và độ chính xác Recall@10 >= 98.5%.

6.3. Tài liệu tham khảo & Nguồn chuẩn kỹ thuật (Primary Technical References)

  1. Malkov & Yashunin — Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs (IEEE TPAMI / arXiv:1603.09320)
  2. Milvus Official Documentation — Milvus 2.5 Architecture, Knowhere SIMD Engine & Multi-Vector Hybrid Search Guide
  3. Qdrant Official Documentation — Filterable HNSW Indexing, Payload Indexes & Unified Query API
  4. Qdrant Official Documentation — Vector Quantization (Scalar INT8, Product PQ, and Binary Quantization)
  5. Cormack, Clarke & Buettcher — Reciprocal Rank Fusion Outperforms Condorcet and Individual Rank Learning Methods (ACM SIGIR Official Paper)
  6. Subramanya et al. — DiskANN: Fast Accurate Billion-point Nearest Neighbor Search on a Single Node (NeurIPS Official Paper)
  7. Jegou, Douze & Schmid — Product Quantization for Nearest Neighbor Search (IEEE TPAMI Specification)
Từ khóa: #AI #Milvus #Qdrant #Vector DB

Bài Viết Cùng Chuyên Mục