Sau chunking, embedding, hybrid retrieval và reranking, một nguyên nhân quan trọng khiến RAG vẫn truy xuất kém nằm ngay ở query. Câu hỏi của người dùng được viết để giao tiếp tự nhiên, trong khi tài liệu trong index thường dùng thuật ngữ, cấu trúc và mức độ chi tiết khác.
Query transformation là nhóm kỹ thuật biến đổi truy vấn trước hoặc trong quá trình retrieval nhằm tăng khả năng tìm được tài liệu relevant. Các kỹ thuật phổ biến gồm query rewriting, query expansion, query decomposition, multi-query retrieval và HyDE.
Vì sao query gốc chưa chắc là query tốt để retrieval?
Người dùng thường đặt câu hỏi theo cách thuận tiện cho họ chứ không theo vocabulary của document collection. Ví dụ, người dùng có thể hỏi:
Trong tài liệu kỹ thuật, cùng vấn đề có thể được mô tả bằng các thuật ngữ như session timeout, idle timeout hoặc session expiration. Dense retrieval có thể xử lý một phần chênh lệch ngữ nghĩa này, nhưng không đảm bảo query embedding luôn nằm gần đúng chunk cần tìm.
Một query cũng có thể quá dài, chứa thông tin hội thoại không cần thiết, dùng đại từ không rõ tham chiếu hoặc gộp nhiều ý thành một câu. Những yếu tố này làm representation của query ít tập trung hơn.
Query transformation không thay thế retriever. Nó điều chỉnh đầu vào của retriever để query phản ánh rõ hơn information need, tức nhu cầu thông tin thực sự của người dùng.
Query rewriting: viết lại truy vấn để rõ và độc lập hơn
Query rewriting biến query ban đầu thành một phiên bản phù hợp hơn cho retrieval nhưng vẫn giữ nguyên ý định chính. Kỹ thuật này đặc biệt hữu ích trong conversational RAG, nơi câu hỏi hiện tại phụ thuộc vào các lượt hội thoại trước.
Ví dụ hội thoại:
User: Nó khác exact search ở điểm nào?
Query thứ hai đứng riêng lẻ chứa đại từ “nó”, vì vậy retriever không biết chắc đối tượng đang được hỏi là gì. Một query rewriter có thể chuyển thành:
Đây thường được gọi là standalone query rewriting: biến câu hỏi phụ thuộc vào conversation history thành câu hỏi có thể hiểu độc lập.
Một query rewriter tốt nên bảo toàn user intent. Nếu mô hình tự thêm giả định hoặc thay đổi đối tượng được hỏi, retrieval có thể chuyển sang đúng nghĩa về mặt ngôn ngữ nhưng sai về mặt thông tin.
Query expansion và multi-query retrieval
Query expansion bổ sung các term hoặc cách diễn đạt có liên quan nhằm tăng cơ hội matching với document. Đây là kỹ thuật lâu đời trong Information Retrieval và vẫn hữu ích trong RAG.
Ví dụ query:
Một phiên bản expanded có thể bổ sung các khái niệm liên quan như:
- vector search latency;
- Approximate Nearest Neighbor;
- ANN index;
- HNSW search parameters.
Query expansion đặc biệt hữu ích với lexical retrieval vì nó tăng lexical overlap. Với dense retrieval, một chiến lược liên quan là multi-query retrieval: tạo nhiều cách diễn đạt khác nhau của cùng information need rồi retrieval riêng từng query.
Ví dụ từ một câu hỏi:
Có thể sinh các query bổ sung như:
- “Cách cải thiện retrieval accuracy trong RAG”
- “Tối ưu dense retrieval và reranking cho RAG”
- “Các kỹ thuật tăng recall của retriever trong RAG”
Mỗi query tạo một candidate list riêng. Các danh sách sau đó có thể được union, deduplicate và fusion trước khi reranking.
Multi-query retrieval giúp tăng retrieval recall, nhưng cũng có thể làm candidate set lớn hơn và chứa nhiều false positive. Vì vậy nó thường hiệu quả hơn khi đi cùng reranker.
Query decomposition cho câu hỏi nhiều bước
Không phải query nào cũng nên được gửi nguyên vẹn vào một lần retrieval. Những câu hỏi cần nhiều fact hoặc nhiều bước suy luận có thể được tách thành các subquery. Kỹ thuật này gọi là query decomposition.
Giả sử người dùng hỏi:
Có thể tách thành:
- Dense retrieval hoạt động như thế nào?
- BM25 hoạt động như thế nào?
- Điểm mạnh và điểm yếu của dense retrieval so với BM25 là gì?
- Khi nào hybrid retrieval phù hợp?
Mỗi subquery có thể truy xuất một tập evidence riêng. Sau đó hệ thống tổng hợp evidence để tạo context cho câu trả lời cuối.
Decomposition đặc biệt hữu ích với multi-hop question answering, nơi câu trả lời cần thông tin từ nhiều tài liệu hoặc nhiều thực thể khác nhau.
Tuy nhiên, decomposition tạo thêm nhiều retrieval call và có thể gây error propagation. Nếu LLM chia câu hỏi sai ngay từ đầu, các bước retrieval phía sau có thể tìm đúng tài liệu cho những subquery không thực sự cần thiết.
HyDE: retrieval bằng hypothetical document
HyDE, viết tắt của Hypothetical Document Embeddings, sử dụng một cách tiếp cận khác query rewriting thông thường. Thay vì trực tiếp embedding câu hỏi, hệ thống trước tiên sinh ra một đoạn văn giả định giống tài liệu có thể trả lời query.
↓
LLM tạo hypothetical document
↓
Embedding hypothetical document
↓
Vector retrieval
↓
Real documents
Ví dụ query:
LLM có thể sinh một hypothetical passage mang dạng tài liệu:
Embedding của đoạn giả định này có thể gần với embedding của tài liệu thực hơn embedding của một câu hỏi ngắn. Về trực giác, HyDE giảm khoảng cách giữa hai dạng văn bản: question-like query và document-like passage.
Điểm quan trọng là hypothetical document không được xem là evidence để trả lời người dùng. Nó chỉ đóng vai trò trung gian để retrieval.
Triển khai multi-query retrieval đơn giản bằng Python
Ví dụ dưới đây giả lập nhiều retrieval result và hợp nhất chúng trước bước reranking. Trong hệ thống thực tế, mỗi query có thể được gửi đến BM25, vector database hoặc cả hai.
def merge_candidates(result_sets):
merged = {}
for results in result_sets:
for rank, doc_id in enumerate(results, start=1):
score = 1 / rank
merged[doc_id] = merged.get(doc_id, 0) + score
return sorted(
merged.items(),
key=lambda item: item[1],
reverse=True
)
query_1 = ["doc_2", "doc_5", "doc_1"]
query_2 = ["doc_5", "doc_3", "doc_2"]
query_3 = ["doc_2", "doc_4", "doc_5"]
candidates = merge_candidates([query_1, query_2, query_3])
for doc_id, score in candidates:
print(doc_id, round(score, 3))Document xuất hiện ở vị trí tốt trong nhiều query sẽ nhận điểm cao hơn. Đây chỉ là ví dụ minh họa; trong production có thể sử dụng Reciprocal Rank Fusion, weighted fusion hoặc đưa toàn bộ candidate sang cross-encoder reranker.
Một chi tiết quan trọng là phải deduplicate candidate. Nếu ba query khác nhau đều retrieval cùng một chunk, chunk đó không nên được đưa ba lần vào context chỉ vì nó xuất hiện trong ba result set.
Query transformation có thể làm retrieval tệ hơn khi nào?
Thêm một LLM vào trước retriever không mặc nhiên làm hệ thống tốt hơn. Query transformation có thể tạo query drift, tức truy vấn mới dần lệch khỏi information need ban đầu.
Ví dụ, query gốc hỏi về “Python multiprocessing” nhưng query expansion tự thêm “asyncio” vì cả hai liên quan đến concurrency. Kết quả retrieval có thể chuyển sang asynchronous programming dù người dùng không hỏi về chủ đề này.
Một vấn đề khác là mất các lexical constraint quan trọng. Với query:
Nếu query rewriter biến thành “GPU runtime failure during model execution”, semantic meaning vẫn tương đối đúng nhưng token 700 đã bị mất. Điều này có thể làm lexical retrieval bỏ qua tài liệu chính xác.
Trong các domain chứa identifier, version, error code, product code hoặc tên API, nên giữ nguyên các lexical anchor quan trọng khi rewrite query.
Nên chọn rewriting, multi-query, decomposition hay HyDE?
Không có một chiến lược query transformation phù hợp cho mọi query. Loại transformation nên được chọn dựa trên failure mode của retrieval.
| Vấn đề | Kỹ thuật phù hợp | Mục tiêu |
|---|---|---|
| Query phụ thuộc hội thoại | Query rewriting | Tạo standalone query |
| Vocabulary mismatch | Query expansion hoặc multi-query | Tăng recall |
| Câu hỏi chứa nhiều ý | Query decomposition | Tìm evidence cho từng phần |
| Query ngắn khó map sang document | HyDE | Tạo document-like representation |
Trong production, không nhất thiết phải áp dụng transformation cho mọi request. Một router có thể phân loại query đơn giản, query hội thoại, query multi-hop hoặc query cần exact matching rồi chọn retrieval strategy tương ứng.
Đánh giá query transformation đúng cách
Cách đánh giá tốt nhất không phải xem query đã viết lại “nghe hay hơn” hay chưa. Mục tiêu cuối cùng vẫn là retrieval relevant documents chính xác hơn.
Có thể so sánh pipeline trước và sau transformation bằng các retrieval metric như Recall@k, MRR hoặc nDCG. Nếu transformation làm Recall@20 tăng nhưng top results trở nên nhiễu, reranking metrics và chất lượng final answer cũng cần được kiểm tra.
Nên phân tích riêng theo query category. Conversational rewriting có thể cải thiện mạnh câu hỏi chứa đại từ nhưng gần như không có lợi cho exact error-code queries. Một aggregate metric duy nhất có thể che giấu những khác biệt này.
Ngoài accuracy, production system còn phải theo dõi latency và chi phí. Multi-query retrieval tạo nhiều search request hơn, decomposition tạo nhiều retrieval stage, còn HyDE cần thêm một LLM generation trước retrieval.
Kết luận
Query transformation trong RAG giải quyết khoảng cách giữa cách người dùng đặt câu hỏi và cách tri thức được biểu diễn trong document collection. Query rewriting phù hợp với conversational context, multi-query và expansion giúp tăng recall, decomposition xử lý câu hỏi nhiều bước, còn HyDE tạo một document-like representation để phục vụ dense retrieval.
Sau khi retrieval đã tìm được candidate tốt, vấn đề tiếp theo là quyết định những chunk nào thực sự nên được đưa vào context của LLM, sắp xếp chúng ra sao và làm thế nào tránh context dư thừa hoặc mâu thuẫn. Đây là bước context construction và context optimization trong một pipeline RAG hoàn chỉnh.
Nội dung gốc thuộc tác giả. Vui lòng không đăng lại toàn văn khi chưa được phép, trừ trường hợp pháp luật hoặc giấy phép áp dụng cho phép. Nội dung của bên thứ ba tuân theo quyền và giấy phép tương ứng.
Nguồn gốc: Query Transformation trong RAG: Rewrite, HyDE và Decomposition