Câu hỏi phỏng vấn AI Series 11: Làm thế nào để tối ưu hóa RAG?
Việc tối ưu hóa RAG không phải là điều chỉnh một khâu duy nhất, mà là một quá trình tối ưu toàn bộ chuỗi. Dưới đây, tôi sẽ đưa ra các chiến lược tối ưu hệ thống từ bốn chiều: phía chỉ mục dữ liệu, phía truy xuất, phía sinh, phía đánh giá, kèm theo kinh nghiệm thực tế có thể đề cập trong phỏng vấn.
1. Tối ưu phía chỉ mục dữ liệu (nâng cao chất lượng "kho tri thức")
Đây là nơi dễ bị bỏ qua nhất nhưng lại mang lại hiệu quả nhanh nhất.
| Điểm tối ưu | Hiện tượng vấn đề | Cách làm cụ thể | Chỉ số hiệu quả |
|---|---|---|---|
| Phân tích tài liệu | Bảng, sơ đồ trong PDF bị bỏ qua, hoặc ký tự bị lỗi, thứ tự sai. | Dùng thư viện phân tích tốt hơn (ví dụ: unstructured, chế độ giữ bố cục của pypdf); đối với bảng, dùng pandas để trích xuất rồi chuyển thành Markdown. |
Tỷ lệ thu hồi +5~15% |
| Kích thước phân đoạn văn bản | Chunk quá nhỏ mất ngữ cảnh (ví dụ: "doanh thu năm nay tăng" không rõ "năm nay"); chunk quá lớn gây nhiễu khi truy xuất. | Thử nghiệm các kích thước chunk khác nhau (256/512/768 token), overlap đặt 10~20%; đối với tài liệu dài, cắt theo ranh giới ngữ nghĩa (đoạn/tiêu đề) thay vì độ dài cố định. | Tỷ lệ trúng / Độ trung thực |
| Gắn metadata | Truy xuất được đoạn liên quan nhưng không truy được nguồn hoặc thời gian, hoặc cần lọc theo lĩnh vực. | Gắn metadata cho mỗi chunk: source (tên file/URL), timestamp, page_num, doc_type. Khi truy xuất dùng bộ lọc (ví dụ: doc_type == 'legal'). |
Độ chính xác khi lọc |
| Chọn mô hình embedding | Embedding đa dụng hoạt động kém trong lĩnh vực chuyên ngành (y tế, mã nguồn, luật). | Dùng mô hình đã được tinh chỉnh trong lĩnh vực (BGE‑large‑zh, GTE‑Qwen2‑7B‑instruct); hoặc tinh chỉnh mô hình embedding riêng (dùng triplet loss). | MRR@10 truy xuất +10~20% |
2. Tối ưu phía truy xuất (làm cho "tra sách" chính xác hơn)
Truy xuất quyết định chất lượng "tài liệu tham khảo" được đưa vào LLM.
| Điểm tối ưu | Hiện tượng vấn đề | Cách làm cụ thể | Hiệu quả |
|---|---|---|---|
| Truy xuất hỗn hợp | Truy xuất vector không khớp được thuật ngữ chính xác (ví dụ: mã sản phẩm ABC-123), truy xuất từ khóa không hiểu được từ đồng nghĩa. |
Sử dụng đồng thời truy xuất vector (ngữ nghĩa) và BM25 (từ khóa), kết hợp bằng trọng số (ví dụ: 0.7vector + 0.3BM25) hoặc rerank. | Tỷ lệ thu hồi +10~25% |
| Sắp xếp lại (Rerank) | Kết quả đầu ra của truy xuất vector không nhất thiết là liên quan nhất, kết quả thứ 10 mới là tốt nhất. | Dùng mô hình cross‑encoder (ví dụ: BGE‑reranker-v2, Cohere Rerank) để chấm điểm lại tập ứng viên (ví dụ: 20 kết quả đầu), lấy top‑K. |
Tỷ lệ trúng được cải thiện đáng kể (đặc biệt top‑1) |
| Viết lại truy vấn | Câu hỏi người dùng mơ hồ hoặc trong hội thoại nhiều lượt không rõ tham chiếu ("Giá của nó là bao nhiêu?"). | Dùng LLM để viết lại câu hỏi gốc thành dạng phù hợp hơn cho truy xuất (ví dụ: "Giá của iPhone 15 là bao nhiêu?"); hoặc dùng lịch sử hội thoại để bổ sung. | Tỷ lệ thu hồi +5~15% |
| HyDE | Câu hỏi người dùng quá ngắn hoặc quá trừu tượng (ví dụ: "Nói về quang hợp"), truy xuất trực tiếp kém hiệu quả. | Đầu tiên cho LLM tạo ra một câu trả lời giả định, sau đó dùng câu trả lời này để truy xuất tài liệu. | Phù hợp với miền mở, nhưng không phù hợp với câu hỏi thực tế chính xác |
| Điều chỉnh số lượng truy xuất Top‑K | K quá nhỏ có thể bỏ sót thông tin quan trọng; K quá lớn tăng tiêu thụ token và nhiễu. | Thử nghiệm K=3/5/10, quan sát sự cân bằng giữa tỷ lệ thu hồi và độ chính xác của câu trả lời. | Trade‑off giữa hiệu quả và hiệu suất |
3. Tối ưu phía sinh (giúp LLM tận dụng tốt tài liệu tham khảo)
Dù truy xuất có chính xác đến đâu, nếu prompt không tốt hoặc mô hình yếu thì cũng vô ích.
| Điểm tối ưu | Hiện tượng vấn đề | Cách làm cụ thể | Hiệu quả |
|---|---|---|---|
| Kỹ thuật prompt | LLM bỏ qua nội dung truy xuất hoặc bịa đặt. | Hướng dẫn rõ ràng: "Chỉ dựa trên tài liệu tham khảo được cung cấp dưới đây để trả lời câu hỏi. Nếu tài liệu không đủ hoặc không liên quan, hãy trả lời 'Không có đủ thông tin'." Thêm few‑shot examples cho thấy cách trích dẫn nguồn. | Độ trung thực +20~40% |
| Nén ngữ cảnh | Nội dung truy xuất quá dài (vượt quá cửa sổ ngữ cảnh của mô hình) hoặc phần lớn là nhiễu. | Sử dụng LLMLingua hoặc Selective Context để nén, giữ lại các câu liên quan nhất rồi mới đưa vào LLM. |
Giảm nguy cơ mất thông tin |
| Nâng cấp mô hình LLM | Mô hình nhỏ (7B) không thực hiện được suy luận phức tạp hoặc không nhớ được ngữ cảnh dài. | Chuyển sang mô hình mạnh hơn (GPT‑4o, Claude 3.5 Sonnet, Qwen2.5‑72B). | Độ chính xác suy luận tăng đáng kể |
| Phát trực tiếp và trích dẫn | Người dùng không thể xác minh độ tin cậy của câu trả lời. | Khi sinh, yêu cầu LLM xuất ra [citation:1], tương ứng với số thứ tự của tài liệu truy xuất. Phía back‑end đính kèm liên kết gốc. |
Độ tin cậy của người dùng + khả năng gỡ lỗi |
| Hiệu chỉnh từ chối trả lời | Mô hình bịa khi không nên trả lời, hoặc nói không biết khi đáng lẽ phải trả lời. | Đặt một ngưỡng tương tự: nếu độ tương tự cosine giữa chunk top‑1 truy xuất được và câu hỏi dưới 0,7, yêu cầu LLM "tài liệu không liên quan". | Giảm tỷ lệ ảo giác |
4. Phía đánh giá và lặp (biết nên điều chỉnh hướng nào)
Không có đo lường thì không thể tối ưu.
| Điểm tối ưu | Cách làm | Chỉ số |
|---|---|---|
| Xây dựng tập đánh giá | Chuẩn bị 100~300 câu hỏi người dùng thực tế + câu trả lời chuẩn + ID tài liệu truy xuất đúng. | Bao phủ các mức độ khó khăn và ý định khác nhau. |
| Đánh giá tự động | Sử dụng RAGAS (Faithfulness, Answer Relevance, Context Recall) hoặc TruLens. | Ba chỉ số cốt lõi: Độ trung thực, Mức độ liên quan của câu trả lời, Tỷ lệ thu hồi ngữ cảnh. |
| Đánh giá thủ công | Hàng tuần kiểm tra 20 bad case, phân tích loại lỗi (thất bại truy xuất / lỗi sinh / thiếu kho tri thức). | Sắp xếp thứ tự ưu tiên cải thiện. |
| Kiểm thử A/B | Trong môi trường sản xuất, phân nhóm thử nghiệm các chiến lược truy xuất khác nhau (ví dụ: BM25 so với truy xuất hỗn hợp). | Chỉ số trực tuyến: Mức độ hài lòng của người dùng, Tỷ lệ không có câu trả lời. |
5. Kinh nghiệm thực tế có thể nói trong phỏng vấn (điểm cộng)
“Trong dự án RAG tôi phụ trách, ban đầu tỷ lệ trúng baseline chỉ 67%. Tôi đã làm ba việc:
1. Chuyển phân đoạn từ cố định 1024 sang cắt ngữ nghĩa động (theo tiêu đề + đoạn), tỷ lệ trúng lên 74%;
2. Thêm truy xuất hỗn hợp (vector + BM25) và một mô hình rerank nhỏ, tỷ lệ trúng lên 83%;
3. Tối ưu prompt và bắt buộc trả về[Không tìm thấy thông tin liên quan], tỷ lệ ảo giác từ 22% giảm xuống dưới 5%.Ngoài ra, chúng tôi đã xây dựng một pipeline đánh giá liên tục, trước mỗi lần thay đổi đều chạy điểm RAGAS trên 200 câu hỏi để đảm bảo không bị suy giảm.”
Tổng kết cuối cùng: Một lộ trình tối ưu RAG hoàn chỉnh
Lớp dữ liệu ─→ Làm sạch tài liệu, tối ưu phân đoạn, tăng cường metadata, embedding theo lĩnh vực
Lớp truy xuất ─→ Truy xuất hỗn hợp, rerank, viết lại truy vấn, HyDE, tối ưu Top-K
Lớp sinh ─→ Tăng cường prompt, hướng dẫn yêu cầu, nén, trích dẫn, ngưỡng từ chối
Lớp đánh giá ─→ Tập đánh giá, RAGAS, phân tích thủ công, thử nghiệm A/B
评论
暂无已展示的评论。
发表评论（匿名）