Bỏ qua để đến nội dung
Search & RAG

Tầng 6 — Query understanding

Người dùng không viết truy vấn tốt. Các kỹ thuật sửa việc đó, kèm đánh giá thẳng thắn về ROI:

Kỹ thuậtCách làmROI thực tế
Normalisationbỏ dấu / chuẩn hoá teencode / sửa lỗi chính tảcao, rẻ — với tiếng Việt đây là món đầu tiên
RewritingLLM viết lại truy vấn rõ hơn, thêm ngữ cảnh hội thoạicao trong chat — “còn cái kia thì sao?” vô nghĩa nếu không rewrite
Decompositiontách truy vấn nhiều phần thành nhiều truy vấn concao cho lớp C (multi-hop)
Multi-query + RRFsinh 3–5 biến thể, tìm cả, fusevừa — nhân chi phí retrieval lên 3–5×
HyDELLM sinh ra một câu trả lời giả, embed nó thay vì embed câu hỏithay đổi lớn về lý thuyết, lợi ích thực tế thất thường — phải đo
Entity/filter extractiontách ngày, mã, tên riêng thành filter có cấu trúcrất cao và bị bỏ quên
Routingphân loại truy vấn rồi chọn đường (SQL? vector? lexical? từ chối?)cao ở hệ trưởng thành
Keyword extractiontrích term đắt từ câu hỏi hội thoại làm truy vấn BM25cao trong chat RAG có hybrid — chi tiết ở Tầng 6b

Vì sao HyDE hoạt động (về lý thuyết): câu hỏi và câu trả lời có hình dạng ngôn ngữ khác nhau — embedding của câu hỏi nằm gần các câu hỏi khác hơn là gần câu trả lời. Sinh một câu trả lời giả rồi embed nó sẽ đưa truy vấn vào “vùng câu trả lời”. Nhưng nó thêm một lượt LLM vào đường latency, và nếu câu trả lời giả bịa sai hướng thì nó làm hại. Đo trước khi tin.

Cảnh báo chung cho cả tầng này: mọi kỹ thuật ở đây đều thêm một lượt gọi LLM vào p50 latency. Với baseline BM25 0.03 ms, thêm 400 ms rewriting là nhân latency lên hơn 10.000 lần. Nó phải đổi lại được cái gì đo được.

Phần 4 — Lý thuyết