5.4 Trần không vượt được: recall@k của stage 1

Đây là mục quan trọng nhất của Phần 5. Nếu bạn chỉ đọc một mục, đọc mục này — vì nó là chỗ tiền bị đổ sai hướng nhiều nhất trong các hệ RAG thật.

Phát biểu

Reranker không thể xếp lại thứ nó chưa được đưa cho.

Gọi k là số ứng viên bạn đưa vào reranker. Mọi tài liệu liên quan không nằm trong k đó thì không tồn tại đối với reranker, với LLM, và với người dùng.

Hệ quả là một bất đẳng thức không có ngoại lệ:

$$\text{chất lượng cuối cùng} \;\le\; \text{recall@}k \text{ của stage 1}$$

Reranker giỏi tới đâu cũng chỉ đưa bạn tới cái trần đó, không bao giờ vượt. Nếu recall@100 = 0,70 thì 30% truy vấn đã thua từ trước khi reranker được gọi.

Đọc thêm

• [EN] Elastic — Semantic reranking, phần 1 — phát biểu thẳng từ một nhà cung cấp: những điểm mù về recall của stage 1 thì không phương pháp rerank nào sửa được
• [EN] Databricks — Reranking trong Mosaic AI Vector Search — recall@10 74% → 89%, và họ nói rõ điều kiện: rerank chỉ giúp nếu câu trả lời đúng đã nằm đâu đó trong top-50

Ba con số, ba quyết định khác nhau

Đo cùng một hệ thống, ba con số này nói ba chuyện hoàn toàn khác nhau:

Số đo	Ý nghĩa	Nếu nó thấp thì sửa ở đâu
recall@k của stage 1 (k = số đưa vào rerank)	trần. Tài liệu đúng có được lấy về không	Retrieval: tokenizer, hybrid, chunking, embedding
nDCG@5 trước rerank	thứ tự hiện tại tệ đến đâu	— (đây là mốc để so)
nDCG@5 sau rerank	reranker mua được bao nhiêu phần khoảng cách tới trần	Reranker: đổi model, đổi k, fine-tune

Khoảng cách recall@k − nDCG@5(trước) là toàn bộ dư địa mà reranker có thể ăn. Nếu khoảng cách đó nhỏ, reranker sẽ không cho bạn gì cả — dù nó là model tốt nhất thế giới.

Thứ tự chẩn đoán bắt buộc

Làm đúng thứ tự này, đừng đảo:

1. Đo recall@k của stage 1, với k đúng bằng số bạn định đưa vào reranker.
   │
   ├── recall@k thấp (< ~0,8)  ──► DỪNG. Không mua reranker.
   │                                 Tiền phải vào retrieval:
   │                                 tokenizer → hybrid → chunking → embedding
   │
   └── recall@k cao, nDCG@5 thấp ──► ĐÚNG bệnh. Reranker chữa được.
                                      Đây là hình dạng "lấy đúng, xếp sai".

Lỗi phổ biến: thấy chất lượng RAG kém → cắm reranker → không khá lên → kết luận “reranker không hiệu quả”. Sai chẩn đoán, không phải sai thuốc. Bệnh nằm ở stage 1 và reranker chưa bao giờ được nhìn thấy tài liệu đúng.

Số thật trên corpus của cẩm nang — và vì sao nó không đại diện

Baseline BM25 trên data/corpus.jsonl + data/goldenset.jsonl. Cột nDCG@5 có trong bảng baseline của Phụ lục — Lộ trình & baseline; cột recall@5 là số đo cùng lần chạy đó, nằm trong nhật ký làm việc không thuộc repo (xem cuối mục):

	nDCG@5	recall@5
Tổng	0.787	0.778
Lớp A — lexical/exact	0.971	0.917
Lớp B — paraphrase	0.456	0.667
Lớp C — multi-hop	0.834	0.778
Lớp D — phủ định	0.888	0.750

Nhìn lớp B: nDCG@5 = 0.456 trong khi recall@5 = 0.667. Khoảng cách 0,21 — có dư địa, nhưng không lớn. Và lớp B là lớp mà Tầng 0 — vocabulary mismatch đã chỉ ra: BM25 trả về top-1 là “Bảo trì định kỳ” cho câu hỏi “dùng miễn phí trước khi quyết định mua”, nDCG = 0.00. Tài liệu đúng (d003 — Gói Dùng Thử) không có từ nào chung với câu hỏi. Reranker không cứu được truy vấn đó nếu d003 không được lấy về.

Bây giờ đến phần trung thực, và nó là một bài học về phương pháp:

Corpus này chỉ có 50 tài liệu. Nếu bạn rerank k = 50, reranker nhìn thấy toàn bộ corpus — recall@50 = 1,0 theo định nghĩa, và trần biến mất.

Nghĩa là mọi con số “reranker cải thiện X%” đo trên một corpus 50 doc đều phóng đại so với production, nơi k = 100 trên 10 triệu tài liệu và trần rất thật. Đây chính xác là bẫy được mô tả ở Phần 2 — 7. Bảy lỗi phương pháp.

Module 4 của cẩm nang (Reranking) chưa được đo. Phần 5 vì vậy không đưa ra con số “cải thiện bao nhiêu” nào của riêng cẩm nang; mọi con số định lượng trong Phần 5 đều là số dẫn từ nguồn ngoài kèm link, hoặc toán học tay có nói rõ giả định.

Chọn k bằng bao nhiêu

k là chỗ hai đường cong gặp nhau:

recall@k                                    chi phí rerank
   │        ╭──────────── bão hoà              │            ╱ tuyến tính
   │      ╭─╯                                  │        ╱
   │    ╭─╯                                    │    ╱
   │  ╭─╯                                      │╱
   └──┴──┴──┴──┴──► k                          └──────────────► k
     10 25 50 100 200                            10 25 50 100 200

Recall bão hoà, chi phí tuyến tính. Nên tồn tại một k mà sau đó bạn trả tiền để mua gần như không gì. Cách tìm nó:

1. Đo recall@k của stage 1 tại k = 10, 25, 50, 100, 200 trên golden set của bạn.
2. Tìm chỗ đường cong bẹt lại — thường recall@k tăng dưới 1 điểm phần trăm mỗi khi k gấp đôi.
3. Chọn k ở đó. Đo lại latency p95 để chắc nó nằm trong budget (5.9).

Lưu ý một chuyện phản trực giác: k quá lớn có thể làm chất lượng tệ hơn, không chỉ đắt hơn — reranker có thêm cơ hội để một tài liệu nhiễu ăn điểm cao ngẫu nhiên. Bằng chứng và cơ chế ở 5.13.

Đọc thêm

• [EN] Retrieve & Re-Rank — Sentence-Transformers — mốc thực dụng cho k (~100) và code để đo lại
• [EN] Jacob et al. — Drowning in Documents, ReNeuIR @ SIGIR 2025 — bằng chứng k lớn hơn có thể tệ hơn: chi tiết ở 5.13
• [EN] Vespa — Phased ranking — cách một search engine production chọn số ứng viên cho từng tầng, và vì sao first-phase phải tương quan đủ với phase sau

Bảng ra quyết định

Bạn đo được	Chẩn đoán	Việc cần làm
recall@100 < 0,7	stage 1 bỏ sót nhiều	Không mua reranker. Sửa tokenizer, thêm hybrid, xem lại chunking
recall@100 ≈ 0,95, nDCG@5 ≈ 0,5	lấy đúng, xếp sai	Đúng bệnh của reranker. Làm ngay
recall@100 ≈ nDCG@5, cả hai cao	đã gần trần	Reranker cho rất ít. Đầu tư vào tầng khác
recall@10 ≈ recall@100	stage 1 đã xếp tốt	Giảm k xuống 10–25, tiết kiệm mà không mất gì
recall@k cao nhưng RAG vẫn bịa	lỗi ở tầng generation	Tầng 8 — Context assembly, không phải reranker

→ Nên áp dụng vào AI Agent: trước khi viết dòng code reranker đầu tiên, thêm một dòng log recall@k vào pipeline đánh giá. Một con số đó quyết định bạn có nên làm tiếp hay không, và nó rẻ hơn mọi thứ khác trong Phần 5.