Bóc tách Qdrant 1.18 — gì đáng giữ, gì nên bỏ qua

TurboQuant nén gấp đôi mà recall gần nguyên — nhưng phần đáng upgrade nhất trong Qdrant 1.18 lại nằm ở tầng ops mà ít ai kéo xuống đọc.

Nén vector gấp đôi mà recall gần như nguyên vẹn — câu đó chiếm mọi tiêu đề về Qdrant 1.18. Nhưng mình đọc hết release notes và nhận ra: phần khiến team ops thở phào lại nằm ở những dòng ít ai kéo xuống tới.

Headline nói gì — và đang giấu gì

Qdrant 1.18 giới thiệu TurboQuant — phương pháp quantization (nén vector để giảm bộ nhớ) mới, dựa trên nghiên cứu của Google Research. Cơ chế: áp dụng Hadamard rotation (phép xoay phân bổ đều giá trị) lên vector trước khi nén, kết hợp length renormalization (chuẩn hóa lại độ dài) mượn từ RaBitQ và per-coordinate calibration (hiệu chuẩn từng chiều) để bám sát dữ liệu thực tế. Hỗ trợ cả cosine, dot product, và L2, cùng SIMD acceleration (tăng tốc phần cứng) cho throughput cao.

Benchmark chính thức trên 4 dataset: TurboQuant 4-bit (TQ4) đạt recall từ 0.9169 đến 0.9261, so với scalar quantization (SQ) ở mức 0.9014–0.9339. Nén gấp đôi, recall lệch không đáng kể.

Nhưng dừng lại một nhịp. Chính Qdrant cũng ghi rõ: "Results vary by dataset and embedding model — TurboQuant may slightly outperform or underperform scalar quantization." Đây không phải lời khiêm tốn — đây là disclaimer quan trọng nhất trong cả bản release.

Dưới lớp nén — cơ chế và ranh giới

Nếu bạn đang dùng scalar quantization và nó chạy ổn, TurboQuant không phải lý do để upgrade gấp. Nó tỏa sáng ở đúng một kịch bản: bạn cần nén mạnh hơn SQ (gấp đôi tỷ lệ) mà không chấp nhận mất recall kiểu binary quantization (BQ).

Bảng so sánh TQ1 vs BQ1 minh họa điều này rõ nhất: trên dataset arxiv-titles, BQ1 rơi recall xuống 0.4683 trong khi TQ1 giữ được 0.6763. Trên dbpedia-openai3, BQ1 đạt 0.6921, TQ1 lên 0.7924. Hiểu nôm na: nếu binary quantization là xếp sách vào kho bằng cách chỉ giữ tên tác giả, TurboQuant giữ thêm cả mục lục — vẫn nén mạnh, nhưng khi tra cứu thì chính xác hơn hẳn.

Cái bẫy ở đây: đọc benchmark xong, nhiều team sẽ muốn bật TurboQuant ngay cho toàn bộ collection. Giả sử team bạn đang chạy RAG pipeline với 2 triệu vectors từ một model tiếng Việt fine-tuned riêng. Distribution của model đó có thể khác hoàn toàn so với 4 dataset benchmark kia — và recall có thể lệch theo hướng bất lợi mà bạn chỉ phát hiện khi user phàn nàn kết quả tìm kiếm tệ đi. Quy tắc vẫn là: benchmark trên dữ liệu của chính mình trước khi đổi quantization method trên production.

Ba tính năng yên ắng nhưng cứu infra lúc nửa đêm

Plot twist: phần đáng chú ý nhất trong 1.18 không liên quan gì đến nén vector.

Memory Monitoring — Trước đây, muốn biết collection nào đang ngốn RAM phải cross-reference giữa top, Prometheus gauges, và "kinh nghiệm" cá nhân. Giờ Qdrant cung cấp API endpoint và tab Memory trên Web UI, tách rõ disk / RAM / page cache (bộ nhớ đệm hệ điều hành) theo từng component: vectors, payload, indexes.

Kịch bản thực tế: giả sử team bạn chạy 5 collection trên cùng một cluster. Response time tăng vọt lúc 2 giờ sáng, Slack bắt đầu nổ. Trước thì mở Grafana, đoán mò, restart từng collection một. Giờ mở tab Memory, thấy ngay payload index của collection product-embeddings chiếm 80% page cache — xử lý đúng chỗ trong 10 phút, không cần restart cả cụm rồi ngồi cầu nguyện.

Named Vectors — thêm/xóa mà không cần tạo lại collection. Tính năng này nghe nhỏ nhưng ảnh hưởng rất lớn với workflow thực tế. Trước đây, muốn đổi embedding model (ví dụ từ text-embedding-ada-002 sang text-embedding-3-large), bạn phải tạo collection mới, re-ingest toàn bộ data, rồi switch traffic — kiểu dọn nhà big-bang. Giờ bạn thêm named vector mới, populate dần ở background, test recall, rồi xóa vector cũ khi sẵn sàng. Giống như thư viện cho phép gắn thêm hệ thống phân loại mới mà không cần đóng cửa dỡ hết kệ.

Strict Mode Guardrails — Hai guardrail (rào chắn bảo vệ) mới:

• max_resident_memory_percent: chặn write operation khi RAM vượt ngưỡng cho phép
• search_max_batchsize: giới hạn số query trong một batch search request

Với team nhỏ chạy shared cluster, hai dòng config này có thể là thứ duy nhất đứng giữa bạn và một incident lúc peak traffic. Đặc biệt max_resident_memory_percent — OOM kill trên production là loại sự cố mà bạn chỉ cần gặp một lần để nhớ đời.

Phần nên lướt qua — và bước tiếp theo

Audit logging — query API cho audit logs và request tracing ID. Quan trọng nếu bạn đang làm compliance (SOC 2, ISO 27001). Nếu team dưới 10 người và chưa cần audit trail, đây chưa phải ưu tiên.

Per-collection API metrics — một community contribution cho phép tách REST/gRPC metrics theo collection qua parameter ?per_collection=true. Hữu ích cho multi-tenant setup, nhưng nếu bạn chỉ có 1–2 collection thì giá trị gần bằng không. Điều đáng ghi nhận hơn là tín hiệu: cộng đồng open-source đang đóng góp vào đúng phần ops tooling mà Qdrant cần.

Còn TurboQuant? Đáng thử — nhưng thử trên staging với dữ liệu thật, không phải trên production bằng niềm tin từ benchmark của người khác. Bước cụ thể: clone một collection hiện tại, bật TQ4, chạy query set chuẩn của team, so recall và latency với SQ. Một buổi chiều là đủ nếu bạn đã có evaluation pipeline.

Điều mình mang về sau khi bóc hết bản release này: Qdrant 1.18 không phải bản "nén vector thần kỳ" như headline gợi ý — nó là bản mà Qdrant bắt đầu nghiêm túc với ops tooling. Và với những ai đang vận hành vector database trên production, đó mới là thứ quyết định bạn ngủ yên hay mất ngủ.

---

Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng