Retrieval-Augmented Generation(RAG)

Mô hình ngôn ngữ không biết quy trình nội bộ của công ty bạn, và cũng không biết bản quy tắc vừa sửa tuần trước. RAG là cách vá chỗ đó mà không cần huấn luyện lại gì cả: trước khi để mô hình mở miệng, hệ thống đi tìm vài đoạn tài liệu liên quan nhất, nhét vào prompt, rồi bảo nó chỉ được trả lời dựa trên đó.

Bản chất RAG là bắt mô hình làm bài mở sách, thay vì để nó nhớ mang máng rồi nói bừa.

Luồng chạy của một hệ RAG

1. Chuẩn bị — cắt tài liệu thành đoạn (chunk), tạo embedding, cất vào vector database kèm metadata.
2. Người dùng hỏi — câu hỏi cũng được chuyển thành embedding.
3. Truy xuất — tìm k đoạn gần nghĩa nhất, thường k từ 3 tới 8.
4. Sinh câu trả lời — nhét các đoạn đó cùng câu hỏi vào prompt, kèm ràng buộc "chỉ dùng thông tin ở trên".
5. Trả về kèm nguồn — hiện tên tài liệu, số điều, link để người dùng bấm vào kiểm.

Bước 5 dễ bị cắt lúc gần deadline vì "làm sau cũng được". Đừng cho cắt. Không có trích dẫn thì người dùng hết đường kiểm, và cả tính năng thành trò may rủi.

So sánh RAG và Fine-tuning

Phần lớn bài toán doanh nghiệp ở Việt Nam mình gặp là bài toán tra cứu tài liệu, tức là RAG. Fine-tuning chỉ đáng bàn khi RAG đã chạy tốt mà vẫn còn một vấn đề định dạng hoặc chi phí cụ thể.

Ví dụ thực tế

"Sản phẩm này có chi trả nội soi dạ dày không, thời gian chờ bao lâu." Tổng đài nghiệp vụ của một công ty bảo hiểm nhân thọ nghe câu đó chừng 147 lượt mỗi ngày, từ 213 tư vấn viên đang ngồi trước mặt khách. Đáp án nằm đâu đó trong 430 trang quy tắc và điều khoản của 12 sản phẩm sức khoẻ, cộng 63 công văn nội bộ rải rác qua ba năm.

Đây là bài toán RAG rất điển hình. Phần việc của BA trong dự án đó, không phần nào là kỹ thuật:

• Chốt nguồn sự thật. 430 trang kia nằm ở đâu, bản nào đang hiệu lực, ai là người duyệt. Hoá ra có ba bản khác nhau đang lưu hành trên ổ chung.
• Định nghĩa cách cắt đoạn. Cắt theo số ký tự thì một điều khoản bị đứt đôi, câu trả lời sẽ thiếu vế loại trừ. Chốt cắt theo điều, mỗi đoạn kèm tiêu đề điều làm ngữ cảnh.
• Metadata bắt buộc. Mã sản phẩm, ngày hiệu lực, ngày hết hiệu lực, phòng ban được xem. Thiếu ngày hiệu lực là chatbot vui vẻ trả lời bằng điều khoản đã bỏ từ 2023.
• Quy tắc từ chối. Điểm tương đồng của đoạn tốt nhất dưới ngưỡng đã chốt thì trả câu chuẩn "chưa tìm thấy căn cứ trong tài liệu, vui lòng liên hệ tổng đài nghiệp vụ", kèm nút chuyển máy.

Việc thứ năm nặng nhất: dựng bộ 150 câu hỏi mẫu kèm đáp án do phòng nghiệp vụ duyệt. Họ phải ngồi trả lời từng câu, mất gần hai tuần, và BA là người đi giục. Đổi lại, đó là thứ duy nhất dùng được để nghiệm thu và để chạy lại mỗi khi đổi tài liệu hay đổi mô hình.

Sau ba tháng chạy, lượt gọi lên tổng đài nghiệp vụ còn khoảng một nửa. Phần không giảm được là ca ngoại lệ và ca cần phán đoán. Cái không ai lường trước là chính tổng đài viên cũng bắt đầu tra bot trước khi trả lời tư vấn viên.

Chỗ hay vỡ

Tài liệu đầu vào bẩn. PDF scan không có lớp text, bảng biểu bị bẹp thành một dòng, file Word ai cũng sửa được và không có phiên bản. Dự án RAG mình đi qua, chậm tiến độ đều vì khâu này, chưa lần nào vì mô hình.

Phân quyền. Không phải ai cũng được đọc mọi tài liệu, mà vector database thường không có sẵn cơ chế phân quyền theo dòng như Postgres, nên phải lọc bằng metadata ngay ở bước truy xuất. Nói chuyện này với team từ sprint đầu, đừng để tới lúc bảo mật rà.