Tám tháng trước mình chọn vector database cho một pipeline RAG dựa trên benchmark một triệu vector. Đến tháng 6, index production vượt 40 triệu. Recall tụt, p99 latency từ 80ms leo lên gần 400ms, mình mất một tuần đinh ninh là bug filter trước khi chấp nhận sự thật: cái benchmark mình từng tin chưa bao giờ test ở quy mô gần với thực tế, và mình cũng chẳng nghĩ tới việc hỏi lại.

Mình không phải trường hợp duy nhất. Ngày 1/9/2026, Qdrant đăng một bài blog tên “Enough with the Bad Benchmarks” (Đủ rồi mấy cái benchmark dỏm), lần đầu tiên mình thấy một vendor vector database nói thẳng: hầu hết benchmark vector search công khai đều là dữ liệu giả lập, quy mô quá nhỏ, hoặc chạy trên dịch vụ đóng kín không ai kiểm chứng độc lập được. Câu trả lời của họ là Qdrant-FineWeb-10B — 10,07 tỷ document, 24,47 TB dữ liệu vector, 28,66 TB text gốc và metadata, dựng từ một phần corpus FineWeb của Hugging Face, embed bằng model gte-multilingual-base.

Vì sao ground truth mới là thứ quan trọng

Phần khiến mình chú ý không phải số lượng document. Ai cũng tạo được 10 tỷ vector ngẫu nhiên. Phần tốn kém và đáng tin thật sự là ground truth: Qdrant tính chính xác top-1.000 nearest neighbor cho 100.000 query dạng dense, sparse và có filter, bằng cách so sánh brute-force với toàn bộ 10 tỷ vector — hơn một triệu tỷ phép tính khoảng cách, chạy trên hạ tầng GPU. Đây mới là con số đáng giá, vì index approximate nearest neighbor (HNSW, IVF, hay bất kỳ thứ gì database bạn dùng bên dưới) chỉ tốt bằng cái nó dùng để đo recall. Nếu “ground truth” của bạn cũng chỉ là gần đúng, số liệu recall của bạn chỉ là tiểu thuyết khoác áo blouse phòng thí nghiệm.

Họ cũng mở mã nguồn công cụ làm việc này, tên Supernova, chia làm bốn phần: nova-embed để tạo embedding, nova-bf để tính ground truth brute-force trên GPU, nova-load để đẩy dữ liệu vào database đích, và nova-dist để phân tán toàn bộ pipeline qua cluster bằng SkyPilot. Ai từng thử tự xây eval harness cho một cuộc migration vector database đều biết phần lớn công việc này là hạ tầng nhàm chán mà chẳng ai muốn viết lại lần hai. Có sẵn nó dưới dạng tool phát hành, không chỉ là một bài paper, đó mới là phần thực sự hữu ích.

Mình đã làm gì với nó

Mình kéo một lát nhỏ — không phải toàn bộ 10 tỷ, laptop và sự kiên nhẫn của mình đều có giới hạn — để kiểm tra lại đúng pattern query có filter, cái gần nhất với thứ từng cắn mình ở production: lấy top-k nearest neighbor với filter metadata (tenant ID cộng khoảng ngày) áp dụng ngay tại thời điểm query, không phải filter sau.

from qdrant_client import QdrantClient
from qdrant_client.models import Filter, FieldCondition, Range

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

# Pattern ANN query có filter, giống hệt hot path production của mình
result = client.query_points(
    collection_name="fineweb_slice",
    query=query_vector,
    query_filter=Filter(
        must=[
            FieldCondition(key="tenant_id", match={"value": "t_4471"}),
            FieldCondition(key="crawl_date", range=Range(gte=1735689600)),
        ]
    ),
    limit=20,
    with_payload=False,
)

Ở 1 triệu vector, pattern này trả về trong vài mili giây, recall so với ground truth brute-force nằm thoải mái trên 98%. Ở 50 triệu vector với cùng độ chọn lọc filter, recall trên index HNSW của mình tụt xuống khoảng 89% trước khi mình chỉnh tăng ef_search — và việc chỉnh đó khiến latency query tăng thêm khoảng 35% để mua lại recall. Chẳng có gì trong chuyện này lộ ra nếu điểm dữ liệu benchmark duy nhất của bạn là “chạy ngon ở 1 triệu vector,” mà đó chính xác là quy mô hầu hết benchmark công khai, và cả phần lớn test tiền-launch của tụi mình, thực sự dùng.

Phần khó chịu: điều này thay đổi cách tụi mình test thế nào

Phiên bản thành thật của câu chuyện này là tụi mình không bỏ qua benchmark. Tụi mình benchmark cẩn thận, ở quy mô nghe hợp lý cho một sản phẩm mới sáu tháng tuổi, và benchmark đó nói đúng sự thật ở quy mô đó. Nó chỉ không nói cho tụi mình biết về quy mô sẽ chạm tới tám tháng sau, vì không benchmark rẻ tiền nào mô phỏng nổi 40 triệu vector trên một cái laptop, và chẳng ai duyệt ngân sách GPU-hour cho “thử brute-force ground truth ở quy mô production” trong một buổi họp sprint planning.

Câu trích của Qdrant trong bài release chốt đúng cái chuẩn thật sự: “Kỹ sư trong các đội search hàng đầu thế giới đòi hỏi khả năng tái lập, recall trên 95%, độ sâu retrieval lớn, throughput cao, và p99 latency dưới 100ms.” Mỗi tiêu chí đó đều phụ thuộc vào quy mô. Recall ở 1 triệu chẳng nói được gì đáng tin về recall ở 100 triệu, vì mật độ neighbor và sai số approximation của index đều thay đổi phi tuyến theo kích thước corpus — sai số của HNSW tệ đi theo cách không phải hàm số gọn gàng của kích thước, và tuning mặc định của mỗi database gần như chắc chắn được validate ở quy mô nào đó mà vendor tự benchmark nội bộ, mà với hầu hết benchmark marketing công khai thì đó không phải hàng tỷ.

Cái mình đang đổi ở team: với bất kỳ vector index nào dự kiến tăng quá 10 lần kích thước lúc launch trong vòng một năm, giờ tụi mình duyệt ngân sách để re-benchmark ở quy mô thật trước khi launch, không đợi tới lúc alert p99 bắt đầu kêu. Nghĩa là chọn một tập con thực tế từ FineWeb-10B hoặc Coyo-Vector-Embeddings (bộ 15,4 triệu vector đa phương thức của họ dùng Qwen3-VL-Embedding-2B, gần với thứ tụi mình cần cho pipeline nặng hình ảnh) có kích thước khớp mục tiêu tăng trưởng năm đầu, không phải kích thước ngày launch.

Kết luận không có cái nơ đẹp

Một benchmark trả lời đúng câu hỏi bạn hỏi nó, ở đúng quy mô bạn hỏi. Cái của tụi mình trả lời hoàn hảo câu “cái này có chạy được ở 1 triệu vector không.” Nó chưa bao giờ được hỏi “có chạy được ở 40 triệu không,” và một benchmark chưa từng bị hỏi câu đó sẽ không bao giờ tự nguyện trả lời. Nếu bạn đang chọn hạ tầng vector lúc này, cứ kéo Qdrant-FineWeb-10B (phát hành 1/9/2026) về xem, hoặc ít nhất đọc qua khỏi con số tiêu đề — phương pháp ground truth mới là phần đáng học theo cho eval pipeline của riêng bạn, bất kể cuối cùng dùng Qdrant hay không.