Bỏ qua để đến nội dung
Search & RAG

1. Nhóm SET-BASED — bỏ qua thứ tự

1.1 Success@k (Hit Rate@k)

Phần tiêu đề “1.1 Success@k (Hit Rate@k)”
Success@k=1 ⁣[  R∩{d1,…,dk}≠∅  ]\text{Success@}k = \mathbb{1}\!\left[\;\mathcal{R} \cap \{d_1,\dots,d_k\} \neq \emptyset\;\right]

Nhị phân: có bắt được ít nhất một doc đúng hay không.

  • Ưu: metric duy nhất không cần giải thích với người ngoài — “8/10 câu hỏi hệ tìm được tài liệu đúng”.
  • Nhược: mù hoàn toàn với chất lượng bên trong top-k. Một hệ đặt doc đúng ở vị trí 1 và một hệ đặt ở vị trí 5 có cùng điểm.
  • Dùng khi: báo cáo cho stakeholder; hoặc golden set chỉ có 1 doc đúng/truy vấn.

1.2 Recall@k — trần của toàn pipeline

Phần tiêu đề “1.2 Recall@k — trần của toàn pipeline”
Recall@k=∣R∩{d1,…,dk}∣R\text{Recall@}k = \frac{\lvert \mathcal{R} \cap \{d_1,\dots,d_k\}\rvert}{R}

Tính chất quan trọng: đơn điệu không giảm theo kk, và Recall@∣D∣=1\text{Recall@}\lvert D\rvert = 1 luôn đúng. Nên báo cáo recall mà không kèm kk là vô nghĩa.

Vì sao đây là metric quan trọng nhất ở tầng retrieval: nó là chặn trên của mọi tầng phía sau. Reranker không thể xếp lại thứ chưa lấy về; LLM không thể trích dẫn đoạn không có trong prompt. Recall@kretrievek_{\text{retrieve}} là mức tối đa mà toàn bộ pipeline có thể đạt.

Cách dùng đúng — đo ở hai độ sâu:

ĐoTrả lời câu hỏi
recall@k_retrieve (50, 100)Tầng retrieval có đủ giỏi không?
recall@k_context (5, 8, 10)Sau khi cắt xuống context window, còn giữ được bao nhiêu?
nDCG@k_contextTrong phần giữ lại, thứ tự có tốt không?

Chẩn đoán:

  • recall@100 = 0.95, recall@5 = 0.55 → retrieval ổn, vấn đề là ranking → đầu tư vào reranker.
  • recall@100 = 0.60 → đừng chạm vào reranker. 40% truy vấn vô vọng ngay từ đầu. Vấn đề nằm ở index/chunking/embedding.

Đây là chẩn đoán rẻ nhất trong toàn bộ IR và bị bỏ qua nhiều nhất.

1.3 Precision@k — và cái bẫy mẫu số

Phần tiêu đề “1.3 Precision@k — và cái bẫy mẫu số”
Precision@k=∣R∩{d1,…,dk}∣k\text{Precision@}k = \frac{\lvert \mathcal{R} \cap \{d_1,\dots,d_k\}\rvert}{k}

Chú ý mẫu số là kk, không phải min⁡(k,∣π∣)\min(k, \lvert\pi\rvert). Nghĩa là hệ trả về thiếu kết quả vẫn bị phạt — đúng ý, vì trả về thiếu cũng là một dạng lỗi.

Cái bẫy nghiêm trọng: precision@k có trần phụ thuộc truy vấn.

Precision@k≤min⁡(k,R)k\text{Precision@}k \le \frac{\min(k, R)}{k}

Ví dụ với golden set này — truy vấn A1 có rel = {d023:2, d028:1}, tức R=2R = 2:

Precision@5≤2/5=0.40\text{Precision@}5 \le 2/5 = 0.40

kể cả khi hệ hoàn hảo. Nếu truy vấn khác có R=5R = 5, trần của nó là 1.0. Lấy trung bình hai con số này qua golden set là cộng táo với cam — điểm trung bình precision@5 bị chặn trên bởi một hằng số phụ thuộc golden set, không phụ thuộc hệ thống.

Ba cách xử lý:

(a) R-Precision — đặt cutoff bằng chính RR của truy vấn đó:

R-Prec=∣R∩{d1,…,dR}∣R\text{R-Prec} = \frac{\lvert \mathcal{R} \cap \{d_1,\dots,d_R\}\rvert}{R}

Tại k=Rk = R ta có precision = recall (điểm break-even), nên R-Precision là một số duy nhất cân bằng cả hai và so sánh được giữa các truy vấn. Trần luôn là 1.0.

(b) Báo cáo kèm trần. In precision@5 = 0.32 (max khả thi 0.41). Giữ nguyên ý nghĩa vận hành: “68% context window là rác”.

(c) Chuẩn hoá: Precision@k / min⁡(k,R)k\text{Precision@}k \,/\, \frac{\min(k,R)}{k} — về mặt toán thì gọn, nhưng mất tính giải thích được.

Cho RAG tôi nghiêng về (b): điều bạn thực sự quan tâm không phải precision như điểm thi, mà là tỷ lệ token vô ích đưa vào LLM — vốn là chi phí thật, tính bằng tiền và bằng hiệu ứng lost-in-the-middle.

1.4 F-measure

Phần tiêu đề “1.4 F-measure”
Fβ=(1+β2) P⋅Rβ2P+R,F1=2PRP+RF_\beta = \frac{(1+\beta^2)\, P \cdot R}{\beta^2 P + R}, \qquad F_1 = \frac{2PR}{P+R}

β>1\beta > 1 ưu tiên recall, β<1\beta < 1 ưu tiên precision.

Ít dùng trong IR hiện đại vì thừa hưởng nguyên cái trần của precision@k, và vì trong IR ta gần như luôn quan tâm ranking chứ không quan tâm tập kết quả. F1 phù hợp hơn với classification (ví dụ: tầng filter nhị phân “chunk này có liên quan không”).

Phần 2 — Metrics