7.9 Payload index

7.8 đã cho thấy payload index không chỉ là “index để lọc nhanh hơn” — nó là điều kiện tiên quyết để cả cơ chế filterable HNSW hoạt động. Mục này là bảng tra đầy đủ.

Một câu để mang theo:

Không có payload index thì filter vẫn chạy, chỉ là chạy sai chỗ đắt và làm hỏng recall. Đây là loại lỗi không báo lỗi.

Tám loại index

Loại	Dùng cho	Điều kiện lọc hỗ trợ
keyword	chuỗi định danh: tenant_id, phong_ban, ngon_ngu	match (value / any / except), prefix
integer	số nguyên	match, range
float	số thực	range
bool	true/false	match
datetime	mốc thời gian (RFC 3339)	range
uuid	UUID	match
geo	toạ độ	geo_bounding_box, geo_radius, geo_polygon
text	full-text	match: {text / text_any / phrase}

Phân biệt quan trọng: keyword là so khớp cả giá trị, text là so khớp token bên trong giá trị. keyword cho "Thanh toán thất bại" chỉ khớp khi truy vấn đúng nguyên chuỗi đó; text khớp khi truy vấn chứa “thanh toán”.

Ba tham số có mặt ở gần như mọi loại

Tham số	Mặc định	Ý nghĩa
memory	pinned	Tầng bộ nhớ của index này (pinned / cached / cold)
enable_hnsw	true	Có tạo cạnh phụ trong đồ thị HNSW cho trường này không
is_tenant / is_principal	false	Tối ưu bố cục đĩa (xem dưới)

enable_hnsw đáng chú ý: đây chính là công tắc của cơ chế ở 7.8. Mặc định bật. Bạn tắt nó cho những trường mà bạn chỉ dùng để lọc trong scroll/count chứ không bao giờ dùng trong truy vấn vector — để khỏi tốn cạnh phụ vô ích.

memory: pinned mặc định nghĩa là trường đã index luôn nằm trong RAM, kể cả khi payload storage của bạn là cold. Đây là điều tốt (filter nhanh) nhưng cũng có nghĩa: mỗi payload index bạn tạo là RAM bị chiếm. Đừng index “cho chắc”.

Đọc thêm

• [EN] Indexing — Qdrant docs — nguồn của bảng tám loại index, các tham số memory / enable_hnsw / is_tenant / is_principal, và toàn bộ tham số tokenizer

is_tenant và is_principal — sắp lại dữ liệu trên đĩa

Hai cờ này không làm filter đúng hơn. Chúng thay đổi bố cục vật lý: Qdrant gom các điểm cùng giá trị lại gần nhau trên đĩa, để một truy vấn lọc theo trường đó đọc ít trang đĩa hơn.

Cờ	Đặt trên loại	Dùng khi
is_tenant: true	keyword, uuid	Trường phân tách khách hàng / không gian dữ liệu — mỗi truy vấn luôn kèm nó
is_principal: true	integer, float, datetime	Trường là trục lọc chính, điển hình là dấu thời gian

Ví dụ dễ hình dung: nếu 100% truy vấn của bạn có tenant_id = X, thì việc các điểm của X nằm rải rác khắp file là lãng phí thuần tuý. is_tenant: true gom chúng lại. is_principal cũng vậy nhưng cho dữ liệu chuỗi thời gian: truy vấn “30 ngày gần nhất” chỉ cần chạm phần cuối file.

Chi tiết cách dùng cho hệ nhiều khách hàng: 7.17.

Đọc thêm

• [EN] Multitenancy — Qdrant docs — vì sao is_tenant tồn tại và nó thay đổi bố cục đĩa thế nào

Full-text index và tiếng Việt

Đây là chỗ tài liệu tiếng Anh không giúp được bạn, nên nói kỹ.

Tham số của index text:

Tham số	Mặc định	Ghi chú cho tiếng Việt
tokenizer	word	word tách theo khoảng trắng và dấu câu — không tách từ ghép tiếng Việt
lowercase	true	Giữ nguyên
ascii_folding	false	Cân nhắc kỹ — xem dưới
min_token_len / max_token_len	—	Đặt min_token_len thấp, tiếng Việt nhiều từ 1 âm tiết
stemmer	tắt	Snowball không có tiếng Việt. Bỏ qua
stopwords	tắt	Không có danh sách tiếng Việt dựng sẵn
phrase_matching	false	Bật nếu cần khớp cụm chính xác

Ba điều rút ra, khớp với 3.10 và 3.15:

1. Không có tách từ tiếng Việt. tokenizer: word coi “ngân hàng” là hai token độc lập. Với nhiều truy vấn thì vẫn dùng được, nhưng đừng kỳ vọng nó hiểu từ ghép.
2. ascii_folding là con dao hai lưỡi. Bật thì “thanh toán” khớp với “thanh toan” — tốt cho người gõ không dấu. Nhưng nó cũng làm “má” ≡ “ma” ≡ “mà”, tức là bạn vứt bỏ thanh điệu. Với corpus có nhiều mã định danh và thuật ngữ, đây thường là đánh đổi có lợi; với văn bản đời thường thì cần đo.
3. Nếu chất lượng lexical tiếng Việt là quan trọng, đừng dựa vào full-text index. Dùng nhánh sparse (7.3) với tokenizer tiếng Việt ở phía ngoài, rồi đưa sparse vector vào Qdrant. Full-text index của Qdrant hợp làm bộ lọc, không hợp làm bộ ranking chính cho tiếng Việt.

Chưa có số đo. Cẩm nang chưa đo full-text index của Qdrant trên data/corpus.jsonl. Ba nhận định trên suy ra từ tài liệu tham số của Qdrant cộng với các kết quả tokenizer tiếng Việt đã đo ở 3.15, không phải số đo trực tiếp trên Qdrant.

Đọc thêm

• [EN] Full-Text Search — Qdrant docs — hành vi thật của match: text / text_any / phrase, và giới hạn của nó so với một search engine đầy đủ
• [VI] 3.15 — BM25 tiếng Việt: tham số và chunk size — mục trong chính cẩm nang này, chứa các số đo tokenizer tiếng Việt mà phần “Full-text index và tiếng Việt” ở trên dựa vào

Thứ tự thao tác đúng

Đây là phần bạn nên chép ra dán lên tường:

1. Tạo collection
2. TẠO TẤT CẢ PAYLOAD INDEX          ← trước, không phải sau
3. Nạp dữ liệu
4. Đợi optimizer xây xong HNSW
5. Đo (a)(b)(c)(d) như ở 7.8

Làm sai thứ tự — nạp dữ liệu rồi mới tạo index — thì filter vẫn hoạt động về mặt kết quả, nhưng cạnh phụ trong HNSW không tồn tại và bạn mất phần lớn lợi ích. Cách chữa: buộc dựng lại HNSW bằng cách tăng ef_construct lên 1.

Đọc thêm

• [EN] A Complete Guide to Filtering in Vector Search — Qdrant — đọc lại cùng 7.8 để thấy vì sao thứ tự tạo index quan trọng đến vậy

Ba lỗi hay gặp

1. Index mọi trường “cho chắc”. Mỗi index tốn RAM (memory: pinned mặc định) và tốn cạnh phụ trong HNSW. Chỉ index trường thật sự xuất hiện trong filter.
2. Dùng keyword cho trường muốn tìm theo token. keyword khớp cả chuỗi. Nếu bạn muốn “tìm tài liệu có chứa chữ hoàn tiền” thì đó là text.
3. Quên datetime và dùng chuỗi. Lưu ngày dưới dạng keyword thì không lọc khoảng được. Dùng datetime với RFC 3339, và cân nhắc is_principal: true nếu ngày là trục lọc chính.