3.13 Top-k: không tính điểm cho thứ không thể vào top

Một truy vấn hai từ trên corpus lớn có thể khớp hàng triệu tài liệu. Nhưng bạn chỉ cần 10. Toàn bộ nghệ thuật tối ưu truy vấn lexical nằm ở chỗ: làm sao không tính điểm cho 999.990 tài liệu còn lại.

Nền: heap kích thước k

Cách cơ bản, đã đủ tốt cho phần lớn hệ thống:

heap = min-heap kích thước k
với mỗi doc khớp:
    tính điểm
    nếu điểm > đỉnh nhỏ nhất của heap:  thay vào

Bộ nhớ O(k) thay vì O(số kết quả khớp). Không cần sắp toàn bộ — và đây là lý do bạn không nên hỏi tổng số kết quả nếu không thật cần (xem cuối mục).

WAND: bỏ qua cả khối tài liệu

Ý tưởng: với mỗi term, tính trước điểm đóng góp tối đa mà nó có thể mang lại (ub(t) — upper bound, suy ra từ idf và tf lớn nhất của term đó).

Gọi θ = điểm của kết quả thứ k hiện có trong heap. Khi đi qua postings:

nếu  Σ ub(t) của các term mà doc này có thể chứa  <  θ
     → doc này KHÔNG THỂ vào top-k  → nhảy qua, không tính điểm

Ví dụ số cho thấy sức mạnh của nó:

term	`ub(t)`
`quên` (hiếm)	4,1
`mật` (phổ biến)	0,8
`khẩu` (phổ biến)	0,8

Nếu heap đã có θ = 2,0, thì mọi tài liệu không chứa quên có điểm tối đa 0,8 + 0,8 = 1,6 < 2,0 — không cần tính điểm cho bất kỳ tài liệu nào trong số đó. Postings của mật và khẩu (dài nhất) gần như bị nhảy qua hoàn toàn.

Block-Max WAND đi thêm một bước: lưu điểm tối đa theo từng khối 128 doc id, nên cắt được ở mức khối chứ không chỉ mức term. Đây là thuật toán Lucene 8+ dùng mặc định.

Hệ quả thực tế cần biết

Điều bạn làm	Chuyện gì xảy ra bên dưới
Hỏi tổng số kết quả (`track_total_hits: true`)	Tắt hết khả năng nhảy — buộc tính điểm mọi tài liệu khớp. Đây là một trong những cách tốn tiền nhất và vô hình nhất
`k = 10` vs `k = 1000`	`θ` với k nhỏ tăng nhanh hơn → cắt được nhiều hơn. `k` lớn đắt hơn phi tuyến
Thêm một term rất phổ biến vào truy vấn	Gần như miễn phí — `ub` thấp, bị nhảy qua. Đây là lý do thứ hai để không bỏ stopword
Sắp xếp theo field (ngày, giá) thay vì theo điểm	Mất luôn cơ chế cắt theo điểm. Cần index sắp trước (index sorting)
`terminate_after`, `timeout`	Dừng sớm — nhưng kết quả không còn xác định. Chỉ dùng làm van an toàn, đừng dùng làm cách tối ưu

`k` là một tham số chất lượng, không chỉ là tham số hiệu năng

Trong pipeline hai tầng (retrieval → rerank), k của tầng một đặt trần recall cho cả hệ thống: reranker không thể cứu tài liệu chưa bao giờ được lấy về. Toán kinh tế của việc chọn k — cân giữa trần recall và chi phí cross-encoder — ở Tầng 3.

Nên hai câu hỏi phải hỏi cùng lúc:

k nhỏ nhất là bao nhiêu để recall@k đủ cao trên golden set? (Phần 2)
k lớn nhất là bao nhiêu để p95 vẫn trong ngân sách? (Tầng 10)

Nếu hai khoảng không giao nhau, vấn đề không nằm ở k — nó nằm ở chất lượng retrieval hoặc ở chunking.

Phần 3 — Nền tảng kỹ thuật