Retrieval trong RAG: Dense Search, Hybrid và Reranking

Sau khi tài liệu được chia thành các chunk, bước quyết định tiếp theo trong Retrieval-Augmented Generation (RAG) là tìm đúng những chunk liên quan đến truy vấn. Đây là nhiệm vụ của retrieval, một bài toán thuộc lĩnh vực Information Retrieval với mục tiêu tìm và xếp hạng tài liệu theo mức độ liên quan.

Một hệ thống RAG tốt không chỉ cần embedding mạnh. Chất lượng thực tế còn phụ thuộc vào cách tạo candidate, hàm similarity, lexical search, hybrid retrieval và đặc biệt là reranking trước khi đưa context vào Large Language Model (LLM).

Retrieval thực sự làm gì trong pipeline RAG?

Sau bước indexing, mỗi chunk tài liệu đã được lưu dưới dạng nội dung, metadata và thường kèm một vector embedding. Khi người dùng gửi query, hệ thống phải tìm một tập nhỏ chunk có khả năng chứa thông tin cần thiết.

Query → candidate retrieval → ranking hoặc reranking → top-k context → LLM → answer

Trong terminology của Information Retrieval, bước đầu tiên thường được gọi là candidate retrieval hoặc candidate generation. Mục tiêu của nó không nhất thiết là sắp xếp hoàn hảo mọi tài liệu, mà là nhanh chóng lấy ra một tập ứng viên có xác suất chứa tài liệu liên quan cao.

Sau đó, hệ thống có thể sử dụng một mô hình chính xác hơn để sắp xếp lại các ứng viên. Quá trình này gọi là reranking. Kết quả cuối cùng thường chỉ giữ một số chunk đứng đầu để đưa vào prompt.

Điểm quan trọng là retrieval và generation là hai bài toán khác nhau. Nếu thông tin cần thiết không xuất hiện trong tập chunk được truy xuất, LLM phía sau thường không thể tự khôi phục chính xác thông tin đó chỉ bằng khả năng sinh ngôn ngữ.

Dense retrieval: tìm kiếm bằng embedding

Dense retrieval biểu diễn query và document bằng các dense vector, tức vector số thực có nhiều chiều và phần lớn chiều mang giá trị khác 0. Trong RAG hiện đại, các vector này thường được tạo bởi một embedding model.

Với kiến trúc retrieval phổ biến, query và document được encode độc lập:

query → query encoder → vector q
chunk → document encoder → vector d

Sau đó hệ thống tính mức độ tương đồng giữa q và d.

Kiến trúc này thường được gọi là bi-encoder hoặc dual-encoder. Ưu điểm lớn nhất là embedding của document có thể được tính trước và lưu trong vector index. Khi query mới xuất hiện, hệ thống chỉ cần encode query rồi thực hiện nearest-neighbor search.

Hai phép đo thường gặp là cosine similarity và dot product. Với hai vector q và d, cosine similarity được tính theo:

cos(q, d) = (q · d) / (||q|| ||d||)

Nếu embedding đã được chuẩn hóa về độ dài 1, dot product và cosine similarity tạo ra cùng thứ tự xếp hạng. Tuy nhiên, không nên tự giả định điều này cho mọi embedding model; cách tính similarity nên tuân theo thiết kế và hướng dẫn của model được sử dụng.

Dense retrieval đặc biệt hữu ích khi query và document diễn đạt cùng một ý bằng từ ngữ khác nhau. Ví dụ, query “không đăng nhập được tài khoản” vẫn có thể gần về embedding với chunk chứa cụm “authentication failure” hoặc “login error”, dù lexical overlap thấp.

Sparse retrieval và BM25 vẫn quan trọng

Sparse retrieval dựa nhiều hơn vào các tín hiệu từ vựng. Document và query được biểu diễn trong không gian từ vựng rất lớn, nhưng mỗi vector chỉ có một số lượng nhỏ phần tử khác 0.

Một thuật toán phổ biến là BM25, thuộc họ probabilistic retrieval. BM25 đánh giá mức độ liên quan dựa trên sự xuất hiện của term trong document, mức độ hiếm của term trong toàn collection và độ dài document.

Về trực giác, một từ xuất hiện trong rất nhiều tài liệu thường cung cấp ít thông tin hơn một thuật ngữ hiếm. Đồng thời, việc một term xuất hiện nhiều lần trong cùng document có ích nhưng lợi ích không tăng tuyến tính vô hạn.

Sparse retrieval thường mạnh trong những truy vấn chứa token cần khớp chính xác, chẳng hạn:

• mã lỗi như ERR_CONNECTION_RESET;
• mã sản phẩm như RTX-4090;
• tên class, function hoặc API endpoint;
• mã hợp đồng, số hiệu hoặc thuật ngữ chuyên ngành hiếm.

Đây cũng là lý do dense retrieval không hoàn toàn thay thế lexical retrieval. Embedding có khả năng khái quát ngữ nghĩa tốt, nhưng một representation mang tính semantic có thể không luôn bảo toàn hoàn hảo mọi chuỗi ký tự đặc biệt mà người dùng muốn tìm chính xác.

Hybrid search kết hợp lexical và semantic retrieval

Hybrid search kết hợp ít nhất hai nguồn tín hiệu retrieval, thường là sparse retrieval và dense retrieval. Một nhánh tìm document dựa trên lexical matching, nhánh còn lại tìm theo semantic similarity.

Query
├── BM25 → lexical candidates
└── Dense retriever → semantic candidates
        ↓
Fusion → candidate list chung

Vấn đề là score của hai retriever thường không cùng thang đo. Một cosine similarity không có ý nghĩa số học trực tiếp tương đương với BM25 score. Vì vậy, cộng trực tiếp hai score mà không normalization hoặc calibration có thể tạo ranking khó kiểm soát.

Một phương pháp fusion đơn giản là Reciprocal Rank Fusion (RRF). Thay vì dựa vào raw score, RRF sử dụng vị trí của document trong từng ranking:

RRF(d) = Σ 1 / (k + rank_i(d))

Trong đó rank_i(d) là vị trí document d trong ranking thứ i, còn k là hằng số làm giảm tác động quá mạnh của các vị trí đầu. Ý tưởng chính là document xuất hiện ở thứ hạng tốt trong nhiều retriever sẽ nhận điểm tổng hợp cao.

Ví dụ Python dưới đây minh họa cách hợp nhất kết quả từ BM25 và dense retrieval bằng RRF:

def rrf(rankings, k=60):
    scores = {}

    for ranking in rankings:
        for rank, doc_id in enumerate(ranking, start=1):
            scores[doc_id] = scores.get(doc_id, 0) + 1 / (k + rank)

    return sorted(
        scores.items(),
        key=lambda item: item[1],
        reverse=True
    )


bm25_results = ["doc_3", "doc_1", "doc_5"]
dense_results = ["doc_1", "doc_4", "doc_3"]

print(rrf([bm25_results, dense_results]))

Trong ví dụ này, doc_1 và doc_3 nhận điểm từ cả hai ranking nên có lợi thế so với tài liệu chỉ xuất hiện ở một nhánh. RRF không yêu cầu score của BM25 và dense retriever phải được chuẩn hóa về cùng một scale.

Reranking: từ candidate retrieval đến ranking chính xác hơn

Dense retrieval cần xử lý một lượng document lớn nên thường ưu tiên tốc độ. Một bi-encoder encode query và document riêng biệt, nhờ đó vector document có thể được index trước. Đổi lại, query và document không tương tác trực tiếp trong quá trình encoding.

Reranker giải quyết một phần hạn chế này bằng cách nhận trực tiếp cặp query-document và dự đoán relevance score. Một kiến trúc phổ biến là cross-encoder.

Bi-encoder:
encode(query) + encode(document) → similarity

Cross-encoder:
model(query, document) → relevance score

Cross-encoder cho phép token của query tương tác với token của document trong cùng forward pass. Điều này thường giúp mô hình đánh giá quan hệ giữa hai đoạn chi tiết hơn so với việc chỉ so sánh hai embedding độc lập.

Đổi lại, cross-encoder đắt hơn về tính toán. Nếu collection có hàng triệu chunk, chạy cross-encoder cho mọi chunk trong mỗi query là không thực tế trong hầu hết hệ thống.

Vì vậy, kiến trúc phổ biến là hai giai đoạn:

1. Retriever lấy một tập candidate tương đối lớn với chi phí thấp.
2. Reranker chấm điểm lại tập candidate nhỏ này và chọn các chunk tốt nhất.

Ví dụ, retriever có thể lấy top-50 ứng viên, reranker sắp xếp lại rồi chỉ giữ một số chunk đầu. Các giá trị cụ thể nên được chọn bằng đánh giá thực nghiệm thay vì coi là quy tắc cố định.

Phân biệt thuật ngữ: retrieval lấy candidate từ collection lớn; ranking xác định thứ tự theo relevance; reranking là xếp hạng lại một tập candidate đã được retrieval trước đó. Ba khái niệm liên quan nhưng không hoàn toàn đồng nghĩa.

Approximate Nearest Neighbor và vector index

Khi collection có số lượng vector lớn, so sánh query với toàn bộ vector bằng exact search có thể trở nên tốn kém. Nhiều vector database vì vậy sử dụng các kỹ thuật Approximate Nearest Neighbor (ANN).

ANN đánh đổi một phần độ chính xác của nearest-neighbor search để giảm latency và chi phí truy vấn. Một cấu trúc index thường gặp là HNSW, viết tắt của Hierarchical Navigable Small World.

Điều cần phân biệt là ANN không phải embedding model và cũng không phải reranker. Nó là cơ chế tìm kiếm hiệu quả trong không gian vector sau khi embedding đã được tạo.

Pipeline đầy đủ có thể được hình dung như sau:

Embedding model tạo vector
↓
Vector index / ANN tìm candidate gần nhất
↓
Reranker đánh giá relevance chi tiết hơn
↓
LLM sử dụng các chunk được chọn làm context

Nếu retrieval kém, chưa chắc embedding model là nguyên nhân. Vấn đề có thể nằm ở chunking, ANN parameters, metadata filter, query formulation, số candidate được lấy hoặc giai đoạn reranking.

Đánh giá retrieval bằng Recall@k, MRR và nDCG

Không nên đánh giá retrieval chỉ bằng cảm giác khi thử vài câu hỏi. Một evaluation set nên chứa query và thông tin về document hoặc chunk nào được xem là relevant.

Recall@k đo tỷ lệ tài liệu relevant được tìm thấy trong top-k kết quả. Trong RAG, metric này đặc biệt quan trọng khi mục tiêu đầu tiên là bảo đảm chunk chứa câu trả lời không bị bỏ sót ở candidate stage.

Nếu một query có một relevant chunk duy nhất, Recall@5 về trực giác trả lời câu hỏi: “Chunk đúng có xuất hiện trong năm kết quả đầu hay không?”. Khi một query có nhiều relevant documents, recall được tính trên toàn bộ tập relevant documents chứ không chỉ một document.

Mean Reciprocal Rank (MRR) tập trung vào vị trí của relevant result đầu tiên. Reciprocal Rank của một query là:

RR = 1 / rank của relevant result đầu tiên

MRR là trung bình Reciprocal Rank trên tập query. Metric này phù hợp khi việc đưa relevant result đầu tiên lên vị trí cao là yếu tố quan trọng.

Normalized Discounted Cumulative Gain (nDCG) hữu ích hơn khi relevance có nhiều mức, chẳng hạn highly relevant, partially relevant và irrelevant. nDCG không chỉ xét document nào relevant mà còn đánh giá chất lượng thứ tự của toàn bộ ranking, với document ở vị trí cao có trọng số lớn hơn.

Các metric này đo những khía cạnh khác nhau. Vì vậy một hệ thống RAG thực tế thường cần kết hợp retrieval metrics với evaluation của câu trả lời cuối cùng thay vì tối ưu một metric duy nhất.

Thiết kế retrieval pipeline chuyên sâu hơn

Một retrieval pipeline đáng tin cậy nên được tối ưu theo từng tầng thay vì gom mọi vấn đề vào embedding. Có thể bắt đầu bằng một dense retriever đơn giản, sau đó quan sát các failure case để xác định bước nào thực sự cần cải thiện.

Nếu hệ thống bỏ sót query chứa mã sản phẩm hoặc thuật ngữ hiếm, hybrid search với BM25 có thể hợp lý. Nếu relevant chunk đã nằm trong candidate set nhưng thứ hạng thấp, reranking thường đáng xem xét hơn thay đổi embedding model ngay lập tức.

Nếu các chunk được truy xuất có nội dung đúng chủ đề nhưng không chứa đủ thông tin để trả lời, vấn đề có thể nằm ở chunking hoặc cách tạo context. Nếu candidate set chứa quá nhiều document từ sai nguồn, metadata filtering có thể hiệu quả hơn việc thay đổi vector similarity.

Một pipeline RAG hoàn chỉnh vì vậy thường là sự kết hợp của nhiều thành phần:

• chunking để xác định đơn vị retrieval;
• embedding để biểu diễn semantic information;
• sparse hoặc dense retrieval để tạo candidate;
• hybrid fusion nếu cần kết hợp nhiều tín hiệu;
• reranking để cải thiện thứ tự candidate;
• retrieval evaluation để đo chất lượng trước khi đánh giá generation.

Việc tách rõ từng tầng giúp debugging có cơ sở hơn. Khi một câu trả lời sai, có thể kiểm tra relevant document có tồn tại trong index, có được retrieval hay không, có bị reranker đẩy xuống dưới hay bị loại khỏi context trước khi kết luận rằng LLM là nguyên nhân.

Kết luận

Retrieval trong RAG không đơn giản là tìm vector có cosine similarity cao nhất. Một hệ thống mạnh thường cần hiểu rõ vai trò của dense retrieval, lexical retrieval, hybrid search, ANN và reranking.

Sau khi chunking đã được thiết kế hợp lý, bước tiếp theo nên là xây dựng tập evaluation cho retrieval và phân tích failure case theo từng tầng. Đây là nền tảng để tối ưu RAG một cách có hệ thống thay vì thay đổi embedding model hoặc prompt theo cảm tính.