7.21 Bảng quyết định

Mục tra cứu. Đọc sau khi đã đi qua Phần 7 ít nhất một lần — các dòng dưới đây là kết luận, và lý do của chúng nằm ở các mục được dẫn link.

A. Thứ tự chẩn đoán khi hệ chậm hoặc kém

Làm theo thứ tự. Mỗi bước rẻ hơn bước sau, và mỗi bước loại trừ một lớp nguyên nhân. Nhảy cóc là cách tốt nhất để tối ưu sai chỗ.

#	Câu hỏi	Cách kiểm	Nếu “có” thì đọc
1	Chất lượng có tệ cả khi không dùng ANN không?	Chạy lại với `exact: true`	5.4 — bệnh nằm ở embedding/chunking, không nằm ở Qdrant
2	Chất lượng chỉ tệ khi có filter?	Đo bộ bốn số (a)(b)(c)(d)	7.8 — filterable HNSW
3	Có payload index cho mọi trường lọc không, và tạo trước khi nạp dữ liệu?	`GET /collections/{name}`	7.9
4	Có nhiều điểm chưa được index không?	`points_count` − `indexed_vectors_count`	7.6 — optimizer không đuổi kịp
5	Collection có xanh không?	Trạng thái collection	7.2, 7.6
6	Dữ liệu nóng có vừa RAM không?	So với công thức `n × dim × 4 × 1,5`	7.18, 7.10
7	Quantization có đang ăn mất recall không?	So với `quantization: {ignore: true}`	7.10
8	Kết quả có “nhấp nháy” giữa các lần gọi không?	Gọi lại nhiều lần cùng truy vấn	7.16 — read affinity
9	Fusion có nằm trong prefetch trên cụm nhiều shard không?	Đọc lại request	7.12 — fusion theo từng shard

Bước 1 và bước 2 giải quyết phần lớn các trường hợp, và cả hai đều làm được trong một buổi.

B. Tình huống → cấu hình

Tình huống của bạn	Cấu hình xuất phát
Dưới ~1 triệu vector, một node, RAM dư	Mặc định hết. Chỉ tạo payload index cho trường lọc. Đừng tối ưu sớm
RAM chật, chất lượng phải giữ	`datatype: float16` trước. Nếu chưa đủ: vector gốc `cold` + bản nén `pinned` + inline storage (7.10)
Dữ liệu lớn hơn RAM nhiều lần	`memory: cold` cho vector và HNSW, `m: 64` / `ef_construct: 512`, bật inline storage, đo IOPS đĩa bằng `fio` trước
Ghi liên tục, truy vấn phải ổn định	`prevent_unoptimized` + `wait=false` (7.6)
Cần latency thấp cho từng truy vấn	`default_segment_number` = số nhân CPU (7.6)
Cần throughput cao, nhiều truy vấn song song	Ít segment lớn (`default_segment_number: 2`, `max_segment_size` lớn)
Nhiều khách hàng nhỏ	Một collection + payload partitioning + `is_tenant: true` (7.17)
Như trên, và mọi truy vấn đều lọc theo tenant	Thêm `m: 0` + `payload_m: 16` — tiết kiệm RAM rất nhiều
Nhiều khách nhỏ + vài khách rất lớn	Tiered multitenancy (v1.16+)
Dữ liệu có vòng đời, xoá theo tháng	`sharding_method: "custom"`, mỗi tháng một shard key (7.15)
Hệ quan trọng, không được mất dữ liệu	`replication_factor ≥ 2`, snapshot mọi node lên S3, đã diễn tập phục hồi
Xây index quá lâu	GPU indexing (v1.13+), hoặc giảm `max_segment_size`

C. Chọn cách fusion cho hybrid

Bạn có	Chọn
Golden set, tách được train/val	RRF có trọng số, chỉnh trên train
Không có golden set, tin vào điểm số của hai nhánh	DBSF
Không có gì cả	RRF thuần — mặc định an toàn
Điểm số hay có ngoại lai	RRF (DBSF nhạy với ngoại lai)
Cụm nhiều shard	Đảm bảo `fusion` là truy vấn chính, không nằm trong prefetch

Chi tiết: 7.12.

D. Núm nào đổi được lúc chạy, núm nào không

Bảng này tiết kiệm cho bạn nhiều lần nạp lại dữ liệu:

Đổi lúc chạy được	Phải dựng lại index	Phải tạo collection mới
`hnsw_ef` (`ef` khi truy vấn)	`m`	Số chiều vector
`oversampling`, `rescore`	`ef_construct`	Khoảng cách (Cosine/Dot/…)
`consistency`, `ordering`, `wait`	`payload_m`	`shard_number` (bản tự host)
`optimizers_config`, memory tier	Payload index tạo sau khi nạp dữ liệu	`sharding_method`
`quantization_config`
`replication_factor`
Thêm/xoá named vector (v1.18+)

Cột giữa có một lối tắt: tăng ef_construct lên 1 để buộc Qdrant dựng lại HNSW (7.7).

E. Mười lỗi hay gặp nhất

Xếp theo tần suất, không theo mức nghiêm trọng:

Tạo payload index sau khi nạp dữ liệu. Cạnh phụ trong HNSW không tồn tại và cả cơ chế filterable HNSW im lặng không hoạt động → 7.8
Đo recall khi không filter, rồi chạy production luôn có filter. → 7.8
Bật quantization mà vẫn giữ vector gốc trong RAM, rồi ngạc nhiên vì RAM tăng. → 7.10
Hiểu indexing_threshold là số điểm thay vì kilobyte (1 KB ≈ 1 vector 256 chiều). → 7.4
Mỗi khách hàng một collection. → 7.17
replication_factor: 1 trên production, tưởng đã có HA. → 7.15
Phục hồi snapshot mà quên priority: "snapshot", nhận về collection rỗng và tưởng snapshot hỏng. → 7.19
Lọc trên mảng object mà không dùng nested. Kết quả lỏng hơn bạn nghĩ, và không có lỗi nào. → 7.13
fusion nằm trong prefetch trên cụm nhiều shard. Chạy đúng lúc dev một shard, đổi hành vi khi lên production. → 7.12
Không đặt api_key. → 7.20

F. Nếu bạn chỉ có một ngày

Thứ tự làm, để có một hệ Qdrant lành mạnh trong một ngày:

Sáng
  1. Liệt kê mọi trường sẽ xuất hiện trong filter  →  tạo payload index cho tất cả
  2. Tạo collection: chốt số chiều, khoảng cách, shard_number (nghĩ kỹ, không sửa được)
  3. Nạp 10% dữ liệu thật.  Đo RAM và đĩa.  Ngoại suy.

Chiều
  4. Đo bộ bốn số (a)(b)(c)(d) của 7.8 trên golden set của bạn
  5. Nếu (c) ≫ (d): sửa theo 7.8 trước khi làm bất cứ thứ gì khác
  6. Đặt api_key + read_only_api_key.  Bind vào network riêng.

Cuối ngày
  7. Bật replication_factor ≥ 2
  8. Dựng cảnh báo trên (points_count − indexed_vectors_count)
  9. Tạo snapshot, thử phục hồi vào một cụm trống với priority: "snapshot"

Bước 4 và 5 là hai bước mà bỏ qua sẽ khiến mọi việc còn lại thành vô nghĩa: bạn sẽ có một hệ thống vận hành tốt, được giám sát cẩn thận, và trả về kết quả sai.

Phần 7 — Qdrant