Reranker mới: đừng vội kéo màn hype

Reranker mới: đừng vội kéo màn hype

Ettin Reranker đáng chú ý không vì tên mới, mà vì nó nhắc builder nhìn lại tầng rerank trong RAG: nơi nhiều hệ thống đẹp demo nhưng hụt production.

“Model mới ra rồi, mình thay luôn embedder nhé?” — câu này mình nghe nhiều đến mức chỉ cần mở Slack là thấy ánh đèn sân khấu bật lên đâu đó.

Nhưng với đợt ra mắt họ Ettin Reranker mới, phần đáng bàn không phải là “model nào đang đứng đầu bảng”. Điểm thú vị hơn nằm ở chỗ: nhiều team đang nâng cấp RAG sai tầng. Họ đổi embedding model, tăng context window, thêm agent, rồi vẫn than câu trả lời lạc quẻ. Trong khi nhân vật đứng sau cánh gà — reranker — mới là chỗ có thể cứu nhiều ca tìm sai tài liệu.

Bài này không phải màn tung hô một release. Mình muốn bóc nó theo góc builder: khi nào nên thêm reranker, khi nào không, và làm sao thử trong một buổi chiều mà không biến hệ thống thành đống đạo cụ lỉnh kỉnh.

Sơ đồ minh họa cho bài Reranker mới: đừng vội kéo màn hype

Sơ đồ tóm tắt ý chính của bài viết.

Thứ đang diễn ra: reranker trở lại đúng vai

Trong pipeline RAG, thường có hai bước:

  1. Retriever / embedder: biến query và tài liệu thành vector để tìm nhanh các đoạn có vẻ liên quan.
  2. Reranker: đọc lại query cùng từng ứng viên, rồi xếp hạng lại kỹ hơn.

Reranker là model chấm điểm cặp query–document. Khác với embedder chỉ so khoảng cách vector, reranker nhìn trực tiếp vào nội dung hai bên. Nói thẳng ra thì: embedder giống người soát vé nhanh ngoài cửa, reranker là người kiểm lại danh sách khách mời trước khi kéo màn.

Ettin Reranker đáng chú ý vì nó phát hành nhiều kích cỡ CrossEncoder dựa trên Ettin ModernBERT encoder, kèm dữ liệu và recipe huấn luyện bằng distillation — kỹ thuật cho model nhỏ học theo điểm số của model lớn hơn. Với builder, giá trị không chỉ là “có thêm model để gọi”, mà là có một recipe tương đối minh bạch để tự fine-tune nếu domain của bạn lệch khỏi dữ liệu chung.

Nhưng hiểu lầm phổ biến là: cứ thêm reranker thì RAG sẽ thông minh hơn. Không hẳn. Reranker thêm độ chính xác, nhưng cũng thêm latency, compute, và một điểm cần monitoring.

Mổ xẻ: tầng nào đang làm hỏng câu trả lời?

Trước khi thay model, mình sẽ hỏi một câu hơi khó chịu: RAG của bạn đang sai vì không lấy được tài liệu đúng, hay vì lấy được rồi nhưng xếp sai thứ tự?

Hai lỗi này nhìn ngoài giống nhau: chatbot trả lời sai. Nhưng cách sửa khác hẳn.

Ví dụ cụ thể: một team fintech ở Việt Nam có chatbot nội bộ hỏi chính sách hoàn tiền. Query là “khách hủy giao dịch sau 7 ngày thì xử lý sao?”. Retriever kéo về 20 đoạn, trong đó có:

Nếu đoạn đúng nằm đâu đó trong top 20 nhưng không vào top 3 đưa cho LLM, bạn có vấn đề về ranking — xếp hạng kết quả. Đây là đất diễn của reranker.

Ngược lại, nếu đoạn đúng không xuất hiện trong top 50, reranker không cứu được. Lúc đó bạn cần xem lại parsing tài liệu, chunking, metadata, hoặc embedder. Đây là nơi các tool như liteparse-server đáng để để mắt: không phải vì “OCR tự host” nghe oách, mà vì nhiều pipeline RAG chết từ khâu bóc text khỏi PDF, bảng biểu, ảnh scan. Text bẩn thì retriever tìm sai; reranker chỉ đang chấm lại một dàn ứng viên đã thiếu vai chính.

Một ví dụ khác: team SaaS 8 người làm search cho tài liệu kỹ thuật. Họ có file PDF hướng dẫn cài đặt, changelog, và ticket support cũ. Nếu parser làm mất heading “Breaking changes”, chunk bị cắt ngang giữa câu, hoặc bảng version bị flatten thành một mớ chữ, embedding sẽ nhầm. Thêm reranker lúc này giống thuê người kiểm kịch bản sau khi đạo cụ đã thất lạc.

Điều đáng giữ: framework 3 câu trước khi thêm reranker

Mình sẽ không bắt bạn “dùng hay không dùng”. Với builder, quyết định nên đi qua ba câu sau.

1. Candidate pool có đủ tốt chưa?

Hãy log top-k trước rerank. Với mỗi query thật, kiểm tra thủ công xem tài liệu đúng có xuất hiện trong top 20 hoặc top 50 không.

Ingestion là quá trình đưa dữ liệu vào hệ thống tìm kiếm: parse, chia đoạn, gắn metadata, index. Đây là hậu trường nhiều bụi nhất, nhưng bỏ qua nó thì model tốt cũng diễn hụt.

2. Latency budget còn bao nhiêu?

Reranker đọc nhiều cặp query–document nên thường đắt hơn embedder. Nếu app của bạn là internal knowledge base, thêm vài trăm mili giây có thể chấp nhận. Nếu là autocomplete realtime, có khi không.

Giả sử team bạn có search nội bộ cho nhân sự, mỗi query lấy top 30 đoạn rồi rerank xuống top 5. Đây là ví dụ minh họa, không phải benchmark: nếu latency tăng nhưng người dùng ít phải hỏi lại, tradeoff có thể đáng. Nhưng nếu API khách hàng đang cần phản hồi cực nhanh, bạn phải đo kỹ.

3. Domain của bạn có “ngôn ngữ riêng” không?

Nếu tài liệu toàn thuật ngữ pháp lý, y tế, tài chính, hoặc codebase nội bộ, reranker chung có thể chưa đủ. Điểm hay của release kiểu Ettin là recipe huấn luyện mở hơn: bạn có thể nghĩ tới fine-tune CrossEncoder trên dữ liệu click, pair đánh giá thủ công, hoặc score từ model mạnh hơn.

CrossEncoder là kiến trúc đưa query và document vào cùng model để chấm điểm; đổi lại chính xác hơn kiểu so vector nhanh, nhưng tốn compute hơn. Pointwise MSE trong recipe distillation nghĩa là model học dự đoán điểm số từng cặp sao cho gần với teacher model.

Điều nên bỏ qua: ba màn dễ làm team tốn công

Có ba kiểu hào hứng mình thấy hơi nguy hiểm.

Một là đổi model theo tiếng ồn. Hôm nay reranker A, mai embedder B, mốt agent C. Nếu không có eval set riêng, bạn chỉ đang chỉnh ánh đèn cho sân khấu mà chưa biết khán giả có nghe rõ không.

Hai là dùng benchmark thay cho bài test nội bộ. Benchmark hữu ích để lọc ứng viên, nhưng production query thường xấu hơn: gõ tắt, sai chính tả, pha tiếng Việt–Anh, hỏi kiểu “cái vụ hôm bữa xử lý sao?”. Nếu hệ thống phục vụ người Việt, hãy có test set tiếng Việt thật, tài liệu thật, câu hỏi thật.

Ba là nhồi reranker vào mọi request. Có request chỉ cần keyword search hoặc metadata filter. Ví dụ: “invoice tháng 9 của công ty A” có thể lọc bằng metadata trước, không cần model đọc văn vẻ. Reranker nên là lớp chấm lại khi semantic search có nhiều ứng viên gần nhau.

Câu chuyện hóm hỉnh đây: có team từng demo RAG bằng bộ handbook sạch đẹp, mọi thứ trả lời mượt. Đến khi đưa PDF scan hợp đồng thật vào, parser nuốt mất số điều khoản, heading bay lung tung. Cả nhóm ngồi debug LLM hai ngày, cuối cùng lỗi nằm ở file input. Hóa ra diễn viên bị mắng vì lời thoại sai, trong khi kịch bản in thiếu trang.

Thử trong một buổi chiều: teardown pipeline của bạn

Nếu muốn kiểm tra reranker có đáng thêm không, làm gọn như sau.

Bước 1: Lấy 30 query thật

Chọn từ log, ticket support, hoặc câu hỏi nội bộ. Đừng tự viết toàn câu đẹp. Mỗi query gắn một hoặc vài đoạn tài liệu đúng nếu có.

Bước 2: Chạy retriever hiện tại và lưu top-k

Ví dụ pseudo-code:

queries = load_queries("eval_queries.jsonl")

for q in queries:
    candidates = retriever.search(q["text"], top_k=30)
    save_jsonl("retrieval_top30.jsonl", {
        "query": q["text"],
        "expected_doc_ids": q["expected_doc_ids"],
        "candidates": candidates,
    })

Nếu tài liệu đúng không vào top 30 ở nhiều query, khoan thêm reranker. Quay lại parse, chunk, metadata.

Bước 3: Cắm thử một reranker open-source

Bạn có thể thử các reranker trong hệ Sentence Transformers, gồm Ettin Reranker, hoặc các lựa chọn open-source khác như BGE reranker, Jina reranker, mixedbread reranker nếu phù hợp license và hạ tầng. Điểm cần so không chỉ là score, mà là top 5 sau rerank có chứa đoạn đúng không.

from sentence_transformers import CrossEncoder

reranker = CrossEncoder("cross-encoder/your-reranker-model")

for item in load_jsonl("retrieval_top30.jsonl"):
    pairs = [(item["query"], c["text"]) for c in item["candidates"]]
    scores = reranker.predict(pairs)
    ranked = sorted(zip(scores, item["candidates"]), reverse=True)
    print(item["query"], [c["doc_id"] for _, c in ranked[:5]])

Bước 4: Đo thứ bạn thật sự quan tâm

Với RAG hỏi đáp, hãy nhìn:

Bước 5: Quyết định triển khai có điều kiện

Đừng bật cho toàn bộ traffic ngay. Có thể chỉ rerank khi:

Góc nhìn cân bằng: release là tín hiệu, không phải mệnh lệnh

Ettin Reranker là một tín hiệu tốt: tầng rerank đang được chăm chút hơn, recipe huấn luyện mở hơn, và builder có thêm lựa chọn ngoài việc đổ hết niềm tin vào embedder hoặc LLM dài ngữ cảnh.

Nhưng quyết định đúng không phải “có model mới thì thay”. Quyết định đúng là: xác định lỗi nằm ở retrieval, ranking, parsing hay generation, rồi mới chọn công cụ. Cursor Composer 2.5 nhắc mình rằng model coding ngày càng được train để làm việc dài hơi hơn; liteparse-server nhắc rằng document pipeline vẫn là điểm nghẽn rất đời; còn Ettin Reranker nhắc rằng một lớp xếp hạng tốt có thể làm RAG bớt trả lời trật nhịp.

Nếu là mình, mình sẽ không kéo reranker lên làm nhân vật chính ngay. Mình sẽ cho nó đứng đúng chỗ: sau retriever, trước LLM, có eval riêng, có latency budget, có rollback. Hậu trường gọn thì màn diễn mới đỡ vấp dây.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo