5.7 Dùng LLM làm reranker

Bạn đã có một LLM trong hệ thống. Ý nghĩ tự nhiên: đưa luôn 100 đoạn cho nó và bảo nó ranking. Ý nghĩ đó đúng hơn bạn tưởng ở một số bài toán, và tệ hơn bạn tưởng ở phần lớn bài toán còn lại. Mục này về việc phân biệt hai trường hợp đó.

Bốn cách hỏi, bốn mức chi phí

Cách	Prompt là gì	Số lần gọi LLM cho `N` ứng viên
Pointwise	“Đoạn này có liên quan tới câu hỏi không?” — từng đoạn một	`N` — song song hoá được hoàn toàn
Pairwise	“A hay B liên quan hơn?” — từng cặp	tới `N² − N` nếu so hết mọi cặp
Listwise	“Đây là 20 đoạn, xuất thứ tự”	~`N/10` với cửa sổ trượt
Setwise	“Trong nhóm này đoạn nào tốt nhất?” — dùng làm phép so trong một thuật toán sắp xếp	~`k·log N`

Bốn dòng này không phải bốn cách viết prompt khác nhau cho cùng một việc — chúng có độ phức tạp khác nhau hàng bậc, và chất lượng cũng khác.

Bảng đáng nhớ nhất của cả mục

Một bài báo đã đo cả bốn cách trong cùng một khung thực nghiệm (cùng model Flan-T5-large, cùng rerank top-100 của BM25, TREC DL 2019 — BM25 nền nDCG@10 = 0,506):

Cách	nDCG@10	Số lần gọi LLM	Token prompt / truy vấn	Latency
pointwise (query likelihood)	0,557	100	15.212	0,6 s
pointwise (yes/no)	0,654	100	16.112	0,6 s
listwise (sinh permutation)	0,561	245	119.121	54,2 s
listwise (theo likelihood)	0,669	245	94.201	10 s
pairwise (mọi cặp)	0,666	9.900	3.014.383	109,6 s
pairwise (heapsort)	0,657	230,3	104.953	16,1 s
setwise (heapsort)	0,670	125,4	40.461	8,0 s
setwise (bubblesort)	0,678	460,5	147.774	29,1 s

Đọc hai dòng in đậm cạnh nhau: pairwise-mọi-cặp tốn khoảng 75 lần số token của setwise-heapsort để cho nDCG@10 thấp hơn. Đó là lập luận mạnh nhất trong y văn chống lại việc triển khai pairwise một cách hồn nhiên.

Chi phí thật, cùng bài báo, GPT-3.5-turbo, mỗi truy vấn trên DL19:

Cách	nDCG@10	Giá / truy vấn
listwise (sinh permutation)	0,712	$0,045
pairwise (heapsort)	0,694	$0,171
setwise (bubblesort)	0,699	$0,084
setwise (heapsort)	0,693	$0,029

Kết luận của chính tác giả: listwise đạt hiệu quả cao nhất, nhưng setwise đạt tương đương (không khác biệt có ý nghĩa thống kê) với một nửa chi phí.

Và một phát hiện phản trực giác đáng ghim: với pointwise theo query-likelihood, LLM càng lớn càng tệ — Flan-T5-large 0,557 → xl 0,542 → xxl 0,506. Tác giả gọi đây là điều “đặc biệt không ngờ tới”. Đừng giả định “model to hơn thì reranker tốt hơn”.

Listwise và cửa sổ trượt: cơ chế, và cái giá đi kèm

Cách listwise phổ biến nhất (RankGPT) đưa các đoạn có số thứ tự vào prompt và yêu cầu model xuất một permutation, kiểu [3] > [7] > [1]. Vì N đoạn không vừa context, nó dùng cửa sổ trượt kích thước 20, bước 10, chạy từ dưới lên trên:

100 ứng viên:  [81…100] → xếp → [71…90] → xếp → … → [1…20] → xếp
                  ↑ bắt đầu từ đuôi                       ↑ kết thúc ở đầu

Cơ chế này hiệu quả — GPT-4 hơn model tốt nhất trước đó khoảng +2,7 nDCG trên TREC và +2,3 trên BEIR — nhưng nó sinh ra ba vấn đề mà bạn phải biết trước khi triển khai:

1. Rất phụ thuộc thứ tự đầu vào. Vì trượt từ dưới lên, một tài liệu vốn nằm gần đầu danh sách chỉ cần “không bị đánh xuống” là giữ được vị trí, còn tài liệu ở cuối phải thắng ở mọi cửa sổ nó đi qua mới lên được đỉnh. Đó là lý do cụ thể vì sao listwise kiểu này nhạy cảm với thứ tự của stage 1.

2. Thiên lệch vị trí bên trong prompt. Một nghiên cứu 2026 quét vị trí của tài liệu đúng qua các vị trí 1–20 và phát biểu rất gọn: các đoạn ở gần cuối input ít có khả năng được đưa lên đầu hơn. Đây là lost-in-the-middle (Tầng 8) xuất hiện lại ngay trong tầng ranking. Một nhóm khác đo được thiên lệch nội tại bằng cách đưa vào các tài liệu rỗng/không có nội dung rồi xem model vẫn xếp chúng thế nào — rồi hiệu chỉnh phần thiên lệch đó ra, thu được hơn 10 điểm nDCG cho model 0,6B.

3. Đầu ra sai định dạng — một chế độ hỏng vận hành thật. Kiểm 873 cửa sổ: GPT-3.5 trả về khoảng 33 phản hồi thiếu tài liệu, GPT-4 khoảng 41 phản hồi sai định dạng; một model chuyên dụng được huấn luyện cho việc này trả về 0. Cùng bài báo đó nhắc một điều nữa: đầu ra của các API đó không tất định, nên cùng một truy vấn có thể ra hai thứ tự khác nhau. Nếu bạn định đưa listwise LLM vào production, hãy chuẩn bị sẵn parser phòng thủ và một đường fallback (5.11).

Ba cách làm nó rẻ đi

Kỹ thuật	Ý tưởng	Kết quả được báo cáo
FIRST	Không decode cả permutation — chỉ đọc logit của token đầu tiên để suy ra thứ tự, huấn luyện thêm bằng loss RankNet	Giảm ~50% latency, và BEIR avg nDCG@10 54,3 so với cross-encoder 50,7 và RankZephyr 53,7
Permutation self-consistency	Xáo trộn thứ tự ứng viên trong prompt nhiều lần, rồi lấy thứ tự trung tâm gần nhất với mọi mẫu	Tăng 34–52% (Mistral), 7–18% (GPT-3.5), 8–16% (LLaMA-2 70B) — chính là cách triệt tiêu thiên lệch vị trí ở trên
Giải đấu (TourRank)	Thay cửa sổ trượt bằng các vòng đấu song song + hệ điểm	TREC DL19/DL20 nDCG@10: RankGPT 68,19/63,60 → TourRank-10 71,63/69,56, và không nhạy cảm với thứ tự ban đầu

Và hướng của 2026 nói rất nhiều về việc ngành này đang đi đâu: distill LLM reranker xuống thành cross-encoder, hoặc nén biểu diễn tài liệu để listwise chạy một lượt. Nói cách khác, câu trả lời của production cho chi phí LLM reranker ngày càng là: đừng chạy LLM lúc phục vụ.

Chỗ LLM reranker thắng đậm: truy vấn cần reasoning

Đây là phần quan trọng, và nó là ngoại lệ thật của khuyến nghị “dùng cross-encoder”.

Trên BRIGHT — benchmark gồm các truy vấn cần reasoning thật (không phải khớp ngữ nghĩa), nDCG@10 trung bình, cùng rerank top-100:

Model	Loại	BRIGHT nDCG@10
rankT5-3B	cross-encoder	16,60
MonoT5-3B	cross-encoder	16,8
RankZephyr-7B	listwise LLM, không reasoning	22,64
Rank1-7B	reranker reasoning	27,23
Rank-R1-14B	reranker reasoning (RL)	29,66
Rank-K-32B	reranker reasoning	32,61
ReasonRank-32B	reranker reasoning	38,03

Gấp hơn hai lần cross-encoder. Trên R2MED, khoảng cách còn rộng hơn: 22,58 → 42,85.

Nhưng nhìn dòng in đậm giữa bảng: RankZephyr — một listwise LLM mạnh nhưng không được huấn luyện cho reasoning — chỉ đạt 22,64, thấp hơn mọi reranker reasoning từ 14B trở lên. Bài học: prompt listwise chung chung không mua được khả năng reasoning. Cái mua được nó là huấn luyện trên reasoning trace (một model được distill từ hơn 600.000 trace) hoặc RL trên nhãn liên quan.

Reranker có nghe chỉ dẫn không? Phần lớn là không

Một hứa hẹn thường thấy của LLM reranker: bạn viết được chỉ dẫn tự nhiên — “ưu tiên tài liệu sau 2024”, “chỉ tính tài liệu về gói doanh nghiệp”. Có một benchmark đo đúng việc này (FollowIR, thước p-MRR, thang −100…+100: đổi chỉ dẫn mà giữ nguyên câu hỏi, xem thứ hạng có đổi đúng hướng không). Kết quả trung bình:

Model	p-MRR
MonoBERT	−3,5
BM25	−2,1
MonoT5-base	−1,8
MonoT5-3B	+2,5
BGE-base / BGE-large	−3,1 / −2,4
INSTRUCTOR-xl (quảng cáo là theo chỉ dẫn)	−2,8
API thương mại (một model rerank tiếng Anh)	−0,2
Mistral-7B-instruct dùng làm reranker	+10,1
FollowIR-7B (huấn luyện riêng cho việc này)	+12,2

Số âm nghĩa là thêm chỉ dẫn làm thứ hạng tệ đi. Chẩn đoán của tác giả: các model đó dùng chữ trong chỉ dẫn như thêm từ khoá chứ không hiểu nó là chỉ dẫn. Và câu tóm tắt của họ: nhìn chung chỉ các model trên 3B tham số hoặc các LM instruct-tuned chưa bị huấn luyện chuyên cho retrieval mới thật sự theo được chỉ dẫn.

→ Hệ quả thực dụng: nếu bạn cần “ưu tiên tài liệu mới hơn”, đừng viết nó vào prompt của reranker. Làm nó ở tầng lọc hoặc tầng xếp lại theo bậc (5.11), nơi hành vi là tất định.

Đọc thêm

[EN] Weller et al. — FollowIR: Evaluating and Teaching IR Models to Follow Instructions, NAACL 2025 — thước p-MRR và bảng cho thấy phần lớn reranker không theo chỉ dẫn
[EN] Weller et al. — Promptriever, 2024 — cách chữa ở phía retriever: huấn luyện với chỉ dẫn ở mức từng mẫu
[EN] Tang et al. — Found in the Middle: Permutation Self-Consistency, NAACL 2024 — xáo thứ tự nhiều lần rồi lấy thứ tự trung tâm, để triệt tiêu thiên lệch vị trí
[EN] LLM-based Listwise Reranking under the Effect of Positional Bias, ECIR 2026 — quét vị trí 1–20: đoạn ở cuối input khó được đưa lên đầu
[EN] Learning from Emptiness: De-biasing Listwise Rerankers, 2026 — đo thiên lệch nội tại bằng tài liệu rỗng, rồi hiệu chỉnh

Bảng chọn

Tình huống của bạn	Nên dùng
RAG hỏi–đáp thông thường trên tài liệu nội bộ	Cross-encoder chuyên dụng. Rẻ hơn, nhanh hơn, tất định hơn
Truy vấn cần reasoning nhiều bước (kỹ thuật, y sinh, code)	Reranker reasoning / listwise LLM — đây là chỗ nó thắng thật
Cần theo chỉ dẫn tự nhiên linh hoạt	LLM instruct, và đo bằng p-MRR trước khi tin
Không có GPU, không muốn tự host	API reranker chuyên dụng (5.8)
Cần chi phí và latency dự đoán được	Không dùng LLM reranker. Nó biến thiên theo độ dài đầu ra
Muốn chất lượng LLM ở giá cross-encoder	Distill LLM → cross-encoder (5.14)

→ Nên áp dụng vào AI Agent: dùng LLM reranker như một thầy để sinh nhãn hoặc như một mốc trần để biết mình còn thiếu bao nhiêu, còn ở đường phục vụ thì chạy cross-encoder. Nếu vẫn muốn LLM ở đường phục vụ: setwise-heapsort là điểm đánh đổi tốt nhất đã được đo, và phải có parser phòng thủ cùng đường fallback.

Phần 5 — Reranker