5.13 Khi nào reranker làm tệ hơn

Phần lớn tài liệu về reranking dừng ở “nó cải thiện chất lượng”. Mục này về nửa còn lại, và nửa còn lại có bằng chứng đo được. Đọc mục này trước khi triển khai, không phải sau khi có sự cố.

Bằng chứng trung tâm: `k` càng lớn không càng tốt

Một nghiên cứu đã đo đúng câu hỏi này — tăng k (số ứng viên đưa vào rerank) rồi xem recall@10 cuối cùng đi đâu — trên cả tập học thuật (BRIGHT, BIRCO, BEIR scifact) và tập doanh nghiệp thật (FinanceBench, ManufacturingQA, DocumentationQA), với bốn reranker đang được dùng nhiều trong production.

Ba con số của họ, đọc theo thứ tự:

Kết quả	Học thuật	Doanh nghiệp
Reranker cải thiện recall@10 so với retrieval ở ít nhất một giá trị `k`	85,0%	88,9%
Nhưng: tăng `k` lên dẫn tới recall@10 tệ hơn cả retrieval một mình	53,3%	44,4%
Cross-encoder pointwise bền khi tăng `k`	chỉ 23,3%	chỉ 22,2%

Đọc dòng thứ hai lần nữa: trong khoảng một nửa số trường hợp, đưa nhiều ứng viên hơn vào reranker làm kết quả tệ hơn là không rerank gì cả.

Và cơ chế hỏng có tên: phantom hits — reranker chấm điểm cao cho tài liệu không có liên hệ nào với truy vấn, không lexical, không ngữ nghĩa. Ví dụ cụ thể trong bài báo: một truy vấn về acetylation của protein, và một tài liệu về máy rửa bát được reranker xếp hạng 3, trong khi retriever xếp nó hạng 4615.

Đây không phải “reranker hiểu sai một chút”. Đây là reranker tự tin đề bạt rác, và càng nhiều ứng viên thì càng nhiều cơ hội cho một mẩu rác ăn điểm cao ngẫu nhiên.

Một chi tiết nữa của cùng bài báo, và nó ngược với trực giác: reranker listwise bằng LLM lại cải thiện đều khi k tăng. Tác giả cho rằng vì nó không bị fine-tune chuyên cho xếp hạng nên không mắc kiểu quên thảm khốc mà các cross-encoder đã fine-tune mắc phải. Họ cũng nói thẳng cách đó “latency cao và không thực tế” — nó là bằng chứng tồn tại, không phải khuyến nghị.

Và đây là lời giải thích từ phía huấn luyện

Hai kết quả sau đến từ hai nơi khác nhau và khớp nhau đến mức đáng chú ý. Hướng dẫn huấn luyện reranker của HuggingFace ghi một cảnh báo:

Nếu bạn chỉ dùng hard negative, model có thể tệ đi một cách bất ngờ ở các trường hợp dễ. Cụ thể: rerank top-200 của stage 1 có thể cho top-10 tệ hơn là rerank top-100.

Đó chính xác là hiện tượng ở phần trên, nhìn từ phía nguyên nhân. Reranker được huấn luyện toàn bằng ứng viên khó nên nó chưa từng học cách nói “cái này chả liên quan gì” một cách đáng tin — và khi bạn đưa cho nó những ứng viên rất xa từ đuôi danh sách top-200, nó không có cơ sở nào để loại chúng.

→ Hệ quả hành động: k không phải một tham số hiệu năng. Nó là một siêu tham số chất lượng phải được điều chỉnh bằng số đo, y như k1/b của BM25 (3.14 — tinh chỉnh k1,b chỉ được +2,4%). Đo recall@10 cuối cùng tại k = 25, 50, 100, 200 và chọn theo số, đừng chọn k = 100 vì đọc thấy ở đâu đó.

Lợi ích giảm dần khi stage 1 đã tốt

Một số đo trên BEIR (nhóm tập Q&A, nDCG@10, rerank top-100) cho thấy hình dạng rất rõ:

Retriever stage 1	Chỉ retrieval	+ reranker	Mức tăng
retriever yếu hơn	0,6100	0,7529	+0,143
retriever trung bình	0,6083	0,7486	+0,140
retriever mạnh	0,7173	0,7694	+0,052

Cùng một reranker, cùng dữ liệu. Stage 1 càng tốt, reranker mua được càng ít — đúng như 5.4 nói bằng lý thuyết.

Và ở đầu mút của xu hướng đó, nó đổi dấu. Một benchmark do nhà cung cấp thực hiện (số của nhà cung cấp, có xung đột lợi ích — đọc như một tín hiệu, không như một hằng số) báo cáo: với một retriever dense mạnh làm nền (nDCG@10 = 81,58%), reranker chuyên dụng đưa lên 83,02%, nhưng hai LLM đa dụng dùng làm reranker kéo xuống 80,63% và 79,49% — tức thấp hơn cả việc không rerank. Và càng tăng số ứng viên từ 10 lên 200 thì càng tụt.

→ Đây là lý do 5.12 đòi bạn báo nDCG@5 trước rerank. Không có mốc đó thì bạn không thể biết mình đang cải thiện hay đang phá.

Khoảng cách tổng quát hoá: benchmark nói dối theo thời gian

Một nghiên cứu 2025 đánh giá 22 phương pháp / 40 biến thể trên các benchmark chuẩn, rồi đánh giá lại trên một tập truy vấn mới, chưa từng tồn tại lúc các model được huấn luyện:

Phát hiện	Số
Mức tụt khi chuyển sang truy vấn mới, mọi nhóm phương pháp	5–15%
Listwise tụt ít nhất	~8%
Pointwise	~12%
Pairwise tụt nhiều nhất	~15%

Câu kết luận của họ đáng ghim: các tuyên bố về “khả năng tổng quát hoá” dựa trên benchmark chuẩn có thể đang bị nói quá. Cùng nghiên cứu ghi nhận các thất bại thảm khốc ngoài miền — một model listwise tụt xuống 9,72 trên tập truy vấn mới, trong khi các model khác giữ khoảng 60.

Cộng thêm phần này: các reranker công khai thường được huấn luyện trên đúng loại dữ liệu mà các benchmark phổ biến lấy mẫu từ đó (5.5). Nhà cung cấp benchmark mới nhất thậm chí phải giữ kín một nửa tập dữ liệu để phát hiện overfit — họ gọi hiện tượng này là “khoảng cách tổng quát hoá”.

Một minh hoạ nhỏ và rất sạch, ngay trên dữ liệu tiếng Việt: trên cùng tập mMARCO-vi dev, ViRanker thắng ở NDCG@3 (0,6815 so với 0,6625) nhưng PhoRanker thắng ở NDCG@10 (0,7422 so với 0,7302). “Reranker nào tốt hơn” đổi chiều theo cutoff bạn chọn. Nếu chỉ đọc một con số, bạn sẽ chọn sai một nửa số lần.

Bảng các chế độ hỏng

Chế độ hỏng	Biểu hiện	Cách phát hiện	Cách chữa
`k` quá lớn	recall@10 cuối tệ hơn không rerank	Quét `k` = 25/50/100/200, đo recall@10	Giảm `k`. Xem phần đầu mục
Phantom hits	Tài liệu vô liên quan nằm trong top-3	Đọc tay top-3 của 20 truy vấn	Giảm `k`; thêm sàn điểm stage 1; xem xét đổi model
Hỏng lớp lexical	Truy vấn chứa mã định danh (`E2003`) tệ hơn sau rerank	Đo tách theo lớp truy vấn	Bỏ qua rerank cho các truy vấn đó (5.11)
Cắt chuỗi im lặng	Điểm thấp cho tài liệu chứa đúng câu trả lời ở cuối	So `max_seq` của model với độ dài chunk thật, tính bằng tokenizer của chính model	Chunk nhỏ hơn, hoặc cửa sổ + max-pool (5.9)
Sai ngôn ngữ	Chất lượng “cứ tệ” mà không rõ vì sao	Kiểm model có nêu tên tiếng Việt tường minh	Đổi model. Cảnh giác với endpoint mặc định của search engine (5.8)
Trôi phân phối điểm sau nâng cấp	Hệ thống trả rỗng / “không tìm thấy” hàng loạt	Test tự động so phân phối điểm với mốc lúc hiệu chỉnh	Bỏ ngưỡng cứng (5.3)
Degrade âm thầm	Chất lượng tụt về stage 1, không ai biết	Metric riêng cho tỷ lệ degrade	Alert khi tỷ lệ degrade > 1% (5.11)
Đầu ra LLM sai định dạng	Thứ tự bị bỏ qua, hoặc mất tài liệu	Log tỷ lệ parse lỗi	Parser phòng thủ + fallback. Với listwise ở `k = 100`, khoảng 5% phản hồi bị lỗi định dạng
Prompt injection	Tài liệu chứa chỉ dẫn tự đẩy mình lên đầu	Đo với tài liệu tấn công có chủ đích	Rủi ro thật của LLM reranker; cross-encoder không nhận chỉ dẫn nên không mắc
Vượt giới hạn cứng của API	Lỗi runtime ở tải cao	Đọc tài liệu giới hạn	Ví dụ: một API báo lỗi nếu nhận quá 10.000 tài liệu một lượt

Dòng thứ ba xứng đáng được nói rõ, vì nó áp đúng vào corpus của cẩm nang: lớp A (lexical/exact) đã đạt nDCG 0,971 với BM25 thuần (baseline đã đo). Một reranker chung chung ở đó chỉ có thể làm hỏng — nó ưu tiên đoạn văn xuôi “đọc thấy hợp” hơn đoạn chứa đúng mã lỗi. Nếu bạn chỉ báo một con số tổng, mức sụt đó bị lớp B che đi hoàn toàn.

Một quyết định “không dùng” có số đo, từ production

Đáng đọc vì nó là ví dụ về việc đo rồi từ chối: một đội vận hành reranker bằng LLM trong sản phẩm thật đã thử chuyển sang listwise và báo cáo kết quả là +40% latency, +15% chi phí, và không có lợi ích chất lượng nào. Họ giữ nguyên cách cũ.

Đó là hình dạng của một quyết định kỹ thuật tốt: không phải “listwise tốt hơn theo paper”, mà “trên hệ của tôi, với dữ liệu của tôi, nó không mua được gì”.

→ Nên áp dụng vào AI Agent: thêm ba thứ vào hệ thống cùng lúc với reranker, không phải sau: (1) một bảng đo tách theo lớp truy vấn, (2) một metric tỷ lệ degrade, (3) một test tự động fail khi phân phối điểm dịch quá xa mốc hiệu chỉnh. Cả ba đều rẻ, và cả ba đều là thứ bạn sẽ ước mình đã có vào lần sự cố đầu tiên.

Phần 5 — Reranker