Chiến lược nâng cao chất lượng RAG: Từ chunking đến reranking

Retrieval Quyết Định Giới Hạn Trên Của Chất Lượng RAG

Năm 2026, rất hiếm trường hợp RAG "đột nhiên thông minh hơn sau khi đổi từ GPT-4 sang Claude Opus 4.7". Phần lớn vấn đề nằm ở giai đoạn Retrieval không lấy được thông tin cần thiết hoặc lấy phải nhiễu khiến LLM bị lạc hướng. Nhìn lại 18 tháng hỗ trợ dự án RAG tại KGA, chỉ riêng cải thiện Retrieval đã làm điểm trải nghiệm người dùng tăng 30–60%, trong khi thay đổi mô hình LLM chỉ tăng trung bình 8%.

Bài viết này tổng kết các phương pháp hay nhất về RAG Retrieval năm 2026 theo 5 lớp: (1) Hybrid Search, (2) Reranker, (3) Viết lại truy vấn, (4) Chiến lược chunking, (5) Chỉ số đánh giá.

Lớp 1: Hybrid Search (BM25 + Dense)

Tìm kiếm dense đơn thuần thường thất bại với mã sản phẩm ("ZX-450B"), từ viết tắt ("TLS1.3"), tên người và điều kiện số cụ thể. Ngược lại, BM25 yếu với diễn đạt theo ngữ nghĩa. Kết hợp 2 loại này bằng Reciprocal Rank Fusion (RRF) đã trở thành tiêu chuẩn ngành.

RRF rất đơn giản: chuyển đổi rank của mỗi kết quả tìm kiếm thành `1 / (k + rank)` rồi cộng tổng (k=60 là mặc định). Vì không cần quan tâm đến sự chênh lệch thang điểm, nó hoạt động hiệu quả với mọi tổ hợp mô hình khác nhau.

```python from collections import defaultdict

def rrf_fusion(ranked_lists: list[list[str]], k: int = 60) -> list[tuple[str, float]]: scores = defaultdict(float) for results in ranked_lists: for rank, doc_id in enumerate(results, start=1): scores[doc_id] += 1.0 / (k + rank) return sorted(scores.items(), key=lambda x: -x[1])

bm25_top = bm25_index.search(query, k=50) dense_top = vector_db.search(query_embed, k=50) fused = rrf_fusion([bm25_top, dense_top])[:20] ```

Trong dự án tìm kiếm pháp lý của KGA: BM25 đơn lẻ nDCG@10=0,52, Dense đơn lẻ 0,61, RRF hybrid tăng lên 0,73. Đơn giản mà mạnh.

Lớp 2: Reranker (Cohere Rerank-3, Voyage Rerank-2)

Sau khi lấy top 50–200 bằng hybrid search, thiết kế hai giai đoạn chấm điểm chính xác bằng cross-encoder reranker đã trở thành chuẩn de facto năm 2026. Tìm kiếm dense có kiến trúc bi-encoder vector hóa query và document độc lập, mất đi tương tác giữa query-document. Reranker đưa cả hai vào Transformer cùng lúc để cho ra độ liên quan thực sự.

• Cohere Rerank-3 (ra mắt 09/2025): Hỗ trợ 100 ngôn ngữ, context 128k, 2 USD/1k queries
• Voyage Rerank-2: Context 32k, dẫn đầu MTEB Reranking, 0,5 USD/1k queries
• Jina Reranker v2: Tùy chọn thiên OSS, hiệu suất tiếng Nhật kém Cohere một bậc
• BGE-Reranker-v2-m3: OSS giấy phép MIT, lựa chọn đầu tiên cho self-host

```python import cohere

co = cohere.Client() results = co.rerank( model="rerank-3", query="データ保護法における越境移転の要件", documents=[d.text for d in top50], top_n=10, ) reranked = [top50[r.index] for r in results.results] ```

Hiệu quả của reranker rất ấn tượng, trung bình tại KGA nDCG@10 tăng từ 0,65 lên khoảng 0,82. Tuy nhiên latency tăng thêm 200–400ms cho top 50, nên cần thiết kế async hóa hoặc trả lời nhanh chỉ bằng giai đoạn đầu trong search UX.

Lớp 3: Viết Lại Truy Vấn (HyDE, Query2Doc, Multi-Query)

Truy vấn của người dùng thường ngắn và mơ hồ ("hủy hợp đồng", "tỷ lệ sử dụng bộ nhớ"). Kỹ thuật mở rộng bằng LLM trước khi tìm kiếm đã được tích hợp vào thiết kế Retrieval năm 2026.

• HyDE (Hypothetical Document Embeddings): Cho LLM viết document giả định trả lời câu hỏi và dùng embedding của document đó làm khóa tìm kiếm
• Query2Doc: Kết hợp query và pseudo-document lấy embedding (biến thể HyDE, ổn định hơn trong nhiều trường hợp)
• Multi-Query: Cho LLM tạo 3–5 diễn đạt khác nhau cùng ý, tìm kiếm song song rồi fuse bằng RRF

```python def hyde_search(query: str, vector_db, llm): hypothetical = llm.generate( f"次の質問に対する架空の回答を 3 文で書いてください: {query}" ) combined = query + " " + hypothetical # Query2Doc 化 embed = embedding_model.encode(combined) return vector_db.search(embed, k=50) ```

Multi-Query có hiệu quả chi phí tốt nhất; trong RAG FAQ nội bộ của KGA, Recall@20 cải thiện 12% so với tìm kiếm đơn query. Chi phí chỉ tăng thêm 1 lần gọi LLM/query, nhưng nếu dùng Claude Haiku / GPT-4.1-mini thì dưới 0,1 yên.

Lớp 4: Chiến Lược Chunking

Vận hành RAG chỉ bằng "chia 1000 ký tự" đã lạc hậu tính đến năm 2026. Phương thức chunking trực tiếp quyết định chất lượng Retrieval.

• Fixed-size: Chia N ký tự theo cách cổ điển. Overlap 10–20%
• Recursive Character Splitting: Chia đệ quy theo thứ tự đoạn → câu → từ. Mặc định của `RecursiveCharacterTextSplitter` trong LangChain
• Semantic Chunking: Embedding các câu liên tiếp và chia tại điểm cosine similarity thay đổi đột ngột. Tạo chunk ngưng tụ về mặt ngữ nghĩa
• Late Chunking (Jina 2024/2025): Đưa toàn bộ văn bản dài vào embedding model trước, lấy embedding theo token rồi bình quân để tạo chunk. Chunk giữ lại ngữ cảnh xung quanh nên không mất đại từ và coreference
• Hierarchical / Parent-Child: Tìm kiếm bằng chunk nhỏ, truyền chunk cha vào quá trình tạo. Cân bằng giữa độ chính xác và lượng ngữ cảnh

Ví dụ triển khai Late Chunking:

```python from transformers import AutoModel, AutoTokenizer import torch

model = AutoModel.from_pretrained("jinaai/jina-embeddings-v3", trust_remote_code=True) tokenizer = AutoTokenizer.from_pretrained("jinaai/jina-embeddings-v3")

def late_chunking(long_text: str, chunk_boundaries: list[tuple[int, int]]): inputs = tokenizer(long_text, return_tensors="pt", truncation=True, max_length=8192) with torch.no_grad(): token_embeds = model(**inputs).last_hidden_state[0] chunk_embeds = [] for start, end in chunk_boundaries: chunk_embeds.append(token_embeds[start:end].mean(dim=0)) return torch.stack(chunk_embeds) ```

Khi áp dụng Late Chunking vào RAG hợp đồng tại KGA, Recall@10 cải thiện từ 71% lên 88% với các tài liệu có nhiều tham chiếu chéo như "được định nghĩa tại Điều 3".

Lớp 5: Chỉ Số Đánh Giá và Đánh Giá Offline

Retrieval không thể đánh giá bằng "có chạy được". Cần chỉ số định lượng và regression test.

• Recall@k: Tỷ lệ document đúng nằm trong top k. Chỉ số quan trọng nhất quyết định giới hạn trên của RAG
• nDCG@10 (Normalized Discounted Cumulative Gain): Tính cả chất lượng thứ hạng. Chuẩn de facto cho tìm kiếm thương mại
• MRR (Mean Reciprocal Rank): Trung bình nghịch đảo rank đến document đúng đầu tiên. Gần với trải nghiệm người dùng
• Hit Rate@k: Nhị phân đơn giản "có document đúng trong top k không"

Bộ đánh giá cần tối thiểu 100 query, lý tưởng 500 query. Lưu cặp query và document ID đúng dưới dạng CSV và chạy regression test trong CI.

```python import numpy as np

def ndcg_at_k(ranked_ids: list[str], relevance: dict[str, int], k: int = 10) -> float: gains = [relevance.get(doc_id, 0) for doc_id in ranked_ids[:k]] dcg = sum((2 g - 1) / np.log2(idx + 2) for idx, g in enumerate(gains)) ideal_gains = sorted(relevance.values(), reverse=True)[:k] idcg = sum((2 g - 1) / np.log2(idx + 2) for idx, g in enumerate(ideal_gains)) return dcg / idcg if idcg > 0 else 0.0 ```

Các framework như `RetrieverEvaluator` của LlamaIndex, RAGAS và Trulens đã chuẩn hóa việc tính toán này; thay vì tự xây, trước hết hãy dùng RAGAS — đây là thực hành chuẩn năm 2026.

Cấu Hình Tham Chiếu Cho Production

Cấu hình RAG production chuẩn KGA đề xuất năm 2026 như sau.

• Ingest: Tài liệu → Late Chunking (Jina v3) → lưu parent/child
• Index: Lưu cả dense và sparse trong pgvector hoặc Qdrant
• Query: Multi-Query (LLM tạo 3 biến thể)
• First-stage: Hybrid BM25 + Dense → fuse bằng RRF lấy top 100
• Second-stage: Cohere Rerank-3 nén xuống top 10
• Generation: Truyền top 10 vào Claude Opus 4.7 để tạo câu trả lời cuối
• Eval: Chạy regression test 500 query mỗi tuần trong CI, block khi nDCG@10 / MRR / Recall@20 xuống dưới ngưỡng

Nếu xây cấu hình này nghiêm túc, trải nghiệm "RAG thông minh hơn mà không cần thay LLM" sẽ xuất hiện trong thực tế. Retrieval mới là trung tâm của RAG, và năm 2026, đây là lớp ưu tiên đầu tư đầu tiên trong dự án.