5.15 Bảng quyết định và checklist triển khai

Mục tra cứu. Mười bốn mục trước gói lại thành các bảng dưới đây.

Bảng 1 — Tôi có nên làm reranking không?

Bắt đầu từ số đo, không từ ý kiến:

Bạn đo được	Chẩn đoán	Việc cần làm
`recall@100` của stage 1 < 0,7	Stage 1 bỏ sót	Không mua reranker. Sửa tokenizer → hybrid → chunking → embedding (5.4)
`recall@100` cao, `nDCG@5` thấp	“Lấy đúng, xếp sai”	Đúng bệnh. Làm ngay
`recall@10` ≈ `recall@100`	Stage 1 đã xếp tốt	Rerank với `k` nhỏ (10–25), hoặc bỏ qua
Cả hai đã cao và sát nhau	Gần trần	Reranker cho rất ít. Đầu tư tầng khác
Chưa đo gì cả	—	Đo trước. Một dòng log `recall@k` rẻ hơn mọi thứ trong Phần 5

Bảng 2 — Chọn họ nào

Tình huống	Lựa chọn	Vì sao
RAG hỏi–đáp nội bộ, mặc định	Cross-encoder	Rẻ nhất trong ba họ, tất định, không đổi index (5.2)
`recall@k` của stage 1 là chỗ nghẽn, quy mô lớn, kiểm soát được hạ tầng	Late interaction làm stage 1	Nó chữa bệnh recall, không phải bệnh ranking (5.6)
Truy vấn cần reasoning nhiều bước (kỹ thuật, y sinh, code)	Reranker reasoning / LLM	Chỗ duy nhất LLM thắng đậm — gấp hơn hai lần cross-encoder trên BRIGHT (5.7)
Cần chi phí và latency dự đoán được	Không dùng LLM reranker	Chi phí biến thiên theo độ dài đầu ra
Dung lượng lưu trữ là ràng buộc cứng	Bi-encoder + cross-encoder	Đừng chạm vào đa vector
Muốn chất lượng LLM ở giá cross-encoder	Distill LLM → cross-encoder	Đo được: ngang thầy ở ~1% chi phí (5.14)
Đang chạy tốt với bi-encoder + cross-encoder	Đừng đổi	Mỗi hạ tầng thêm vào là một thứ phải vận hành

So sánh trực diện “late interaction” với “hybrid + rerank” — cùng một harness, kèm dung lượng index và latency — ở 5.6.

Bảng 3 — Chọn model (cho hệ tiếng Việt)

Bốn cửa, theo thứ tự. Chỉ nhìn benchmark sau khi qua cả bốn (5.8):

1. GIẤY PHÉP cho phép dùng thương mại?     → không thì gạch tên, dù điểm cao
2. MAX SEQ lớn hơn chunk của tôi?          → không thì đuôi bị cắt IM LẶNG
3. TIẾNG VIỆT được nêu tên tường minh?     → "100+ ngôn ngữ" không phải bằng chứng
4. PHỤC VỤ được trên hạ tầng của tôi?      → TEI/vLLM có ràng buộc kiến trúc thật

Nhu cầu	Ứng viên đáng thử đầu tiên
Tiếng Việt, tự host, chunk dài	`AITeamVN/Vietnamese_Reranker` (max seq 2304, Apache-2.0)
Tiếng Việt, cần nhanh, chunk ngắn	`itdainb/PhoRanker` (0,1B, max seq 256 — kiểm chunk của bạn trước)
Đa ngữ, phục vụ được trên TEI	`BAAI/bge-reranker-v2-m3` (dùng `max_length` = 1024, không phải 8192)
Đa ngữ, có nhãn `vi` tường minh	`mixedbread-ai/mxbai-rerank-base-v2` (Apache-2.0)
Không muốn vận hành GPU	API thương mại nêu tên tiếng Việt trong tài liệu
Cần mốc trần để biết mình còn thiếu bao nhiêu	Một LLM reranker mạnh, chạy offline trên golden set

Bảng 4 — Chọn `k`

Ràng buộc của bạn	`k` gợi ý	Ghi chú
Search hiển thị trực tiếp (không có LLM sau đó)	10–25	Từng chục ms là thật ở đây
RAG có LLM sinh câu trả lời sau đó	25–100	Vài chục ms rerank không đáng kể so với LLM
Rerank trên CPU	≤ 30	Khuyến nghị của nhà cung cấp: `n` inference mỗi truy vấn ở độ sâu `n`
Agent gọi retrieval nhiều lần một lượt	nhỏ hơn bạn nghĩ	Chi phí nhân với số lần gọi (Tầng 9)
Chưa đo	đo `k` = 25/50/100/200	`k` là siêu tham số chất lượng, không chỉ hiệu năng (5.13)

⚠️ k lớn hơn không luôn tốt hơn. Trong khoảng một nửa các trường hợp đã đo, tăng k làm recall@10 cuối cùng tệ hơn cả không rerank (5.13).

Bảng 5 — Các quyết định thiết kế còn lại

Quyết định	Mặc định nên chọn	Khi nào đổi
Cắt kết quả sau rerank	Top-n tuyệt đối	Chỉ chuyển sang ngưỡng khi thật cần abstention (5.3)
Đặt reranker ở đâu	Tầng ứng dụng (2 lần gọi)	Để thấy điểm thô và tắt được bằng biến môi trường (5.11)
Khi reranker chết	Degrade về thứ tự stage 1	`Fail` chỉ khi trả lời sai đắt hơn không trả lời
Timeout	Cứng, nhỏ hơn budget tổng	Kèm circuit breaker
Tín hiệu nghiệp vụ (mới, phổ biến, giá)	Lọc cứng trước rerank	Đừng cộng thẳng vào điểm reranker
Chạy GPU	fp16	Không dùng ONNX làm mặc định trên GPU nữa; không bao giờ fp16 trên CPU (5.9)
API hay tự host	API trước, đo một tháng	Tự host khi lưu lượng cao đều, hoặc khi dữ liệu không được ra ngoài (5.10)
Top-5 trùng lặp	Chặn ≤ 1–2 đoạn cùng một tài liệu gốc	MMR nếu cần đa dạng thật (lớp C)

Checklist triển khai

Cắt dán được. Mỗi dòng dẫn về mục giải thích nó.

Trước khi viết code

Đo recall@k của stage 1 tại k bạn định dùng — 5.4
Đo nDCG@5 trước rerank làm mốc — 5.12
Có golden set riêng, chia theo lớp truy vấn — 5.12
Đo độ dài chunk thật bằng tokenizer của chính model reranker — 5.9
Đọc LICENSE của model, không chỉ đọc bảng benchmark — 5.8

Khi chọn model

Chạy 2–3 ứng viên trên golden set của bạn, tách theo lớp — 5.12
Xem danh sách truy vấn bị tệ hơn, đọc tay từng cái — 5.13
Kiểm riêng lớp lexical/mã định danh có bị hỏng không — 5.13
Xác nhận model nêu tên tiếng Việt tường minh — 5.8
Quét k = 25/50/100/200 và chọn theo số — 5.13

Khi triển khai

Timeout cứng + circuit breaker + đường degrade — 5.11
Metric riêng cho tỷ lệ degrade, có alert — 5.11
Khoá cache gồm cả model_id + version và doc_content_hash — 5.11
Ghim ngưỡng (nếu có) cạnh tên model trong cùng dòng config — 5.3
Lưu lại phân phối điểm hôm bật, làm mốc phát hiện trôi — 5.13
Đo p95 của riêng tầng rerank, ở k thật, trên hạ tầng thật — 5.9
Bật cho một phần lưu lượng, so bằng interleaving hoặc A/B — 5.12
Có parser phòng thủ nếu dùng LLM reranker — 5.7

Sau một tháng

So chi phí rerank với tổng hoá đơn — nếu nó là 3% thì đừng tối ưu nó — 5.10
Kiểm lại tỷ lệ degrade — nó có âm thầm là 100% không? — 5.11
Đo lại recall@k (corpus đã thay đổi) — 5.4
Tính lại k với dữ liệu lưu lượng thật — 5.13

Ba câu để mang đi

1. Reranker không tìm được thứ nó chưa được đưa cho. Đo recall@k trước, luôn luôn.

2. Điểm reranker là để so, không phải để đọc. Mọi ngưỡng cứng là một sự cố đang chờ.

3. k là núm điều chỉnh vừa chất lượng vừa chi phí. Và k lớn không phải luôn tốt hơn.

Phần 5 — Reranker