Vector Database - Trái tim của hệ thống AI hiện đại

1. Vector Database là gì và tại sao quan trọng?

Trong kỷ nguyên AI, dữ liệu không chỉ đơn thuần là các bảng, dòng và cột. Mỗi đoạn văn bản, hình ảnh, đoạn âm thanh đều mang trong mình một "ý nghĩa ngữ nghĩa" — thứ mà cơ sở dữ liệu truyền thống không thể nắm bắt được. Vector Database ra đời để giải quyết chính xác vấn đề này: lưu trữ và tìm kiếm dữ liệu dựa trên ý nghĩa, không phải từ khóa.

Thay vì so khớp chuỗi ký tự như SQL LIKE '%keyword%', Vector Database cho phép bạn hỏi: "Tìm những đoạn văn bản có ý nghĩa tương tự với câu hỏi của tôi" — và nó trả về kết quả chính xác đáng kinh ngạc, kể cả khi không có từ nào trùng khớp.

2. Embedding - Biến dữ liệu thành vector

Trái tim của mọi hệ thống Vector Database là embedding — quá trình biến đổi dữ liệu phi cấu trúc (văn bản, hình ảnh, âm thanh) thành các vector số học trong không gian nhiều chiều. Hai mẫu dữ liệu càng giống nhau về mặt ngữ nghĩa, vector của chúng càng gần nhau trong không gian này.

2.1. Embedding hoạt động như thế nào?

Hình 1: Quy trình embedding và tìm kiếm ngữ nghĩa

Mỗi embedding model sẽ biến đổi dữ liệu đầu vào thành một vector có số chiều cố định. Ví dụ:

• OpenAI text-embedding-3-large: 3072 chiều (có thể giảm xuống 256-1536)
• Cohere embed-v3: 1024 chiều
• BGE-M3 (BAAI): 1024 chiều — hỗ trợ đa ngôn ngữ, bao gồm tiếng Việt
• Sentence-BERT: 384-768 chiều
• CLIP (OpenAI): 512-768 chiều — hỗ trợ cả text và image

2.2. Các metric đo khoảng cách

Khi đã có vector, cần một phương pháp để đo "mức độ giống nhau" giữa chúng. Ba metric phổ biến nhất:

3. Các thuật toán tìm kiếm vector

Khi cơ sở dữ liệu có hàng triệu vector, việc so sánh từng cặp (brute-force) trở nên không khả thi. Đây là lúc các thuật toán Approximate Nearest Neighbor (ANN) phát huy sức mạnh — đánh đổi một chút độ chính xác để đạt được tốc độ tìm kiếm hàng nghìn lần nhanh hơn.

3.1. Brute Force (Exact KNN)

So sánh vector truy vấn với mọi vector trong database. Độ chính xác 100% nhưng độ phức tạp O(N×D) — không thể mở rộng khi N lớn.

# Brute force search - O(N*D) complexity
import numpy as np

def brute_force_search(query_vec, database_vecs, top_k=10):
    # Tính cosine similarity với MỌI vector
    similarities = np.dot(database_vecs, query_vec) / (
        np.linalg.norm(database_vecs, axis=1) * np.linalg.norm(query_vec)
    )
    # Sắp xếp và trả về top-k
    top_indices = np.argsort(similarities)[-top_k:][::-1]
    return top_indices, similarities[top_indices]

# Với 1 triệu vector 1536-D: ~2-5 giây mỗi truy vấn
# Với 100 triệu vector: ~200-500 giây = KHÔNG KHẢ THI

3.2. HNSW (Hierarchical Navigable Small World)

HNSW là thuật toán ANN phổ biến nhất hiện nay, được sử dụng mặc định bởi hầu hết Vector Database. Ý tưởng cốt lõi: xây dựng một đồ thị nhiều tầng, mỗi tầng cao hơn chứa ít node hơn nhưng kết nối xa hơn — giống như hệ thống giao thông có cả đường cao tốc (tầng cao) và đường nội thành (tầng thấp).

Hình 2: Cấu trúc đồ thị HNSW với 3 tầng — tìm kiếm bắt đầu từ tầng cao nhất và "zoom in" dần

Quy trình tìm kiếm HNSW:

1. Bắt đầu từ entry point ở tầng cao nhất (Layer 2)
2. Di chuyển tham lam (greedy) đến node gần query nhất ở tầng hiện tại
3. Khi không thể tiến gần hơn, "xuống" tầng dưới và tiếp tục
4. Ở tầng thấp nhất (Layer 0), mở rộng tìm kiếm với beam search

Tham số quan trọng của HNSW:

• M (max connections per node): Thường 16-64. M cao hơn → recall tốt hơn nhưng tốn RAM hơn
• efConstruction: Beam size khi build index. Giá trị 200-500 cho kết quả tốt
• efSearch: Beam size khi query. Tăng ef → recall cao hơn, latency tăng

3.3. IVF (Inverted File Index)

IVF chia không gian vector thành nhiều cluster bằng K-Means. Khi tìm kiếm, chỉ cần quét các cluster gần query nhất thay vì toàn bộ database.

# IVF Search Process (Pseudo-code)
# 1. Training phase: Chia N vectors thành K clusters
centroids = kmeans(all_vectors, n_clusters=1024)

# 2. Indexing: Gán mỗi vector vào cluster gần nhất
for vec in all_vectors:
    cluster_id = find_nearest_centroid(vec, centroids)
    inverted_lists[cluster_id].append(vec)

# 3. Search: Chỉ quét nProbe clusters gần nhất
def ivf_search(query, nprobe=16, top_k=10):
    nearest_clusters = find_nearest_centroids(query, centroids, n=nprobe)
    candidates = []
    for cluster_id in nearest_clusters:
        candidates.extend(inverted_lists[cluster_id])
    return brute_force_search(query, candidates, top_k)

# nProbe=16/1024 → chỉ quét 1.6% dữ liệu → nhanh ~60x

3.4. Product Quantization (PQ)

PQ nén vector bằng cách chia vector D-chiều thành M sub-vector nhỏ hơn, mỗi sub-vector được lượng tử hoá thành 1 byte (256 centroids). Kết quả: giảm bộ nhớ 32-64 lần với chỉ ~5% mất mát recall.

4. Kiến trúc bên trong Vector Database

Một Vector Database production-grade không chỉ là "index + search". Nó cần giải quyết hàng loạt vấn đề phức tạp: phân tán dữ liệu, nhất quán, sao lưu, lọc metadata, và cập nhật real-time.

Hình 3: Kiến trúc phân tán điển hình của một Vector Database (tham khảo Milvus)

4.1. Sharding và Replication

Dữ liệu được chia thành nhiều shard dựa trên hash hoặc range partitioning. Mỗi shard có thể có nhiều replica để đảm bảo tính sẵn sàng cao (HA). Khi query, hệ thống scatter request tới tất cả các shard liên quan, sau đó gather và merge kết quả.

4.2. Write-Ahead Log (WAL) và Consistency

Mỗi thao tác insert/update/delete đều được ghi vào WAL trước khi áp dụng vào index. Điều này đảm bảo:

• Durability: Dữ liệu không mất khi node crash
• Consistency: Có thể replay WAL để rebuild index
• Replication: WAL được replicate giữa các replica

4.3. Hybrid Search: Vector + Metadata Filtering

Trong thực tế, hiếm khi chỉ tìm kiếm thuần vector. Thường cần kết hợp: "Tìm tài liệu tương tự với câu hỏi này, nhưng chỉ trong danh mục 'Kỹ thuật' và được tạo sau 01/2025".

# Qdrant hybrid search example
from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, MatchValue, Range

client = QdrantClient(url="http://localhost:6333")

results = client.search(
    collection_name="documents",
    query_vector=embedding_model.encode("kiến trúc microservices"),
    query_filter=Filter(
        must=[
            FieldCondition(
                key="category",
                match=MatchValue(value="engineering")
            ),
            FieldCondition(
                key="created_at",
                range=Range(gte="2025-01-01T00:00:00Z")
            )
        ]
    ),
    limit=10,
    score_threshold=0.7  # Chỉ trả về kết quả có score >= 0.7
)

5. So sánh các Vector Database phổ biến

Thị trường Vector Database đang rất sôi động với nhiều lựa chọn, từ open-source đến fully managed. Dưới đây là phân tích chi tiết các giải pháp hàng đầu:

6. Tích hợp Vector Database vào pipeline RAG

Vector Database là thành phần không thể thiếu trong kiến trúc Retrieval-Augmented Generation (RAG). Nó đóng vai trò "bộ nhớ dài hạn" cho LLM, cung cấp context chính xác để giảm hallucination và cập nhật kiến thức real-time.

Hình 4: Pipeline RAG hoàn chỉnh — từ ingestion đến generation

6.1. Chunking Strategy - Nghệ thuật chia nhỏ tài liệu

Chunking là bước quan trọng nhất và thường bị đánh giá thấp. Chunk quá lớn → nhiễu, mất focus. Chunk quá nhỏ → mất context. Các chiến lược phổ biến:

• Fixed-size chunking: Chia theo số token cố định (512-1024), có overlap 10-20%. Đơn giản, hiệu quả cho đa số trường hợp
• Semantic chunking: Sử dụng embedding để phát hiện "ranh giới ngữ nghĩa" — chia tại điểm embedding thay đổi đột ngột
• Recursive character splitting: Chia theo cấu trúc document (heading → paragraph → sentence). Ưu tiên giữ nguyên đơn vị ngữ nghĩa tự nhiên
• Parent-child chunking: Lưu chunk nhỏ để search, nhưng retrieve chunk lớn hơn (parent) để giữ context

# Semantic Chunking with LangChain
from langchain_experimental.text_splitter import SemanticChunker
from langchain_openai import OpenAIEmbeddings

embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# Chia tại điểm embedding thay đổi > ngưỡng
chunker = SemanticChunker(
    embeddings,
    breakpoint_threshold_type="percentile",
    breakpoint_threshold_amount=90  # Chia tại top 10% điểm thay đổi
)

chunks = chunker.create_documents([document_text])
# Mỗi chunk là một đơn vị ngữ nghĩa hoàn chỉnh

6.2. Reranking - Tinh chỉnh kết quả

Sau khi Vector DB trả về top-K kết quả (thường K=20-50), một cross-encoder reranker sẽ đánh giá lại chính xác hơn mức độ liên quan giữa query và mỗi document, rồi chọn top-N tốt nhất (N=3-5) đưa vào LLM.

# Reranking with Cohere
import cohere

co = cohere.Client("your-api-key")

# Bước 1: Vector search trả về top-20
vector_results = vector_db.search(query_embedding, limit=20)

# Bước 2: Rerank để chọn top-5 chính xác nhất
reranked = co.rerank(
    model="rerank-v3.5",
    query="kiến trúc microservices cho hệ thống thanh toán",
    documents=[r.text for r in vector_results],
    top_n=5
)

# Reranker thường cải thiện recall@5 thêm 10-15%

7. Tối ưu hiệu năng và chi phí

7.1. Quantization - Nén vector để tiết kiệm RAM

Với dataset lớn, chi phí RAM có thể trở thành bottleneck. Quantization giúp giảm đáng kể:

7.2. Disk-based Index

Thay vì giữ toàn bộ index trong RAM, một số hệ thống hỗ trợ disk-based indexing:

• Milvus DiskANN: Graph-based index trên SSD. Chỉ cần ~10% RAM so với HNSW thuần, latency tăng 2-3x
• Qdrant memmap: Memory-mapped files, OS quản lý page cache. Hiệu quả khi working set < RAM
• pgvector: Tự nhiên disk-based vì dựa trên PostgreSQL storage engine

8. Các kỹ thuật nâng cao

8.1. Multi-vector Representation

Thay vì biểu diễn mỗi document bằng 1 vector duy nhất, kỹ thuật ColBERT (Contextualized Late Interaction) tạo một vector cho mỗi token. Khi search, tính MaxSim giữa mỗi query token với tất cả document tokens, rồi sum lại. Kết quả: recall vượt trội, đặc biệt với query phức tạp.

8.2. Sparse-Dense Hybrid

Kết hợp tìm kiếm sparse (BM25/TF-IDF — khớp từ khóa chính xác) với dense (vector — hiểu ngữ nghĩa) để có kết quả tốt nhất cho cả hai trường hợp:

# Weaviate hybrid search
result = client.query.get(
    "Document", ["content", "title"]
).with_hybrid(
    query="cách tối ưu hiệu năng database",
    alpha=0.7,  # 70% dense (semantic), 30% sparse (keyword)
    fusion_type="RELATIVE_SCORE"  # Chuẩn hoá score trước khi kết hợp
).with_limit(10).do()

8.3. Multi-modal Vector Search

Với model embedding đa phương thức như CLIP, ImageBind, hay Jina CLIP v2, bạn có thể tìm kiếm xuyên modality — dùng text để tìm ảnh, dùng ảnh để tìm text, hoặc thậm chí dùng audio để tìm video.

Hình 5: Multi-modal search — mọi dữ liệu cùng sống trong một không gian vector thống nhất

9. Triển khai thực tế: Từ prototype đến production

9.1. Prototype nhanh với ChromaDB

# Cài đặt: pip install chromadb sentence-transformers
import chromadb

client = chromadb.Client()
collection = client.create_collection(
    name="my_docs",
    metadata={"hnsw:space": "cosine"}
)

# Thêm documents — ChromaDB tự embed
collection.add(
    documents=[
        "Vector database lưu trữ embedding cho tìm kiếm ngữ nghĩa",
        "Redis là in-memory data store hỗ trợ nhiều cấu trúc dữ liệu",
        "Kafka là distributed event streaming platform",
    ],
    ids=["doc1", "doc2", "doc3"],
    metadatas=[
        {"category": "database"},
        {"category": "database"},
        {"category": "streaming"},
    ]
)

# Tìm kiếm
results = collection.query(
    query_texts=["cơ sở dữ liệu cho AI"],
    n_results=2,
    where={"category": "database"}
)
print(results["documents"])
# → [['Vector database lưu trữ embedding...', 'Redis là in-memory...']]

9.2. Production với Qdrant

# docker-compose.yml cho Qdrant production
version: "3.8"
services:
  qdrant:
    image: qdrant/qdrant:v1.12.1
    ports:
      - "6333:6333"   # REST API
      - "6334:6334"   # gRPC
    volumes:
      - qdrant_data:/qdrant/storage
    environment:
      QDRANT__SERVICE__GRPC_PORT: 6334
      QDRANT__STORAGE__OPTIMIZERS__MEMMAP_THRESHOLD_KB: 20000
      QDRANT__STORAGE__ON_DISK_PAYLOAD: true
    deploy:
      resources:
        limits:
          memory: 8G
        reservations:
          memory: 4G

volumes:
  qdrant_data:

9.3. Checklist triển khai production

10. Kết luận

Vector Database không chỉ là một trend công nghệ — nó đang trở thành infrastructure layer thiết yếu cho mọi ứng dụng AI, từ chatbot đến recommendation system, từ semantic search đến multimodal AI.

Điểm mấu chốt cần nhớ:

• Embedding quality quyết định tất cả — Vector DB chỉ tốt bằng embedding model bạn chọn
• Bắt đầu đơn giản — ChromaDB cho prototype, pgvector nếu đã có PostgreSQL, Qdrant/Weaviate cho production
• Chunking là nghệ thuật — Không có one-size-fits-all, phải thử nghiệm với dữ liệu thực
• Reranking không thể thiếu — Luôn kết hợp reranker để cải thiện precision
• Monitor continuously — Recall có thể drift theo thời gian khi dữ liệu thay đổi

Khi kết hợp Vector Database với các kỹ thuật như RAG, GraphRAG, và Agentic AI, bạn sẽ có nền tảng vững chắc để xây dựng những hệ thống AI thực sự thông minh — hiểu ngữ cảnh, truy xuất kiến thức chính xác, và đưa ra câu trả lời đáng tin cậy.