RAG là gì, và khi nào nên dùng RAG thay vì gửi cả tài liệu vào prompt?

Người phỏng vấn muốn biết bạn hiểu RAG như một quy trình có các bước, chứ không chỉ như một cái tên thời thượng, và bạn có biết cân nhắc đánh đổi hay không.

RAG, viết tắt của retrieval-augmented generation, gồm ba bước. Một là tách tài liệu thành các đoạn nhỏ, làm một lần từ trước. Hai là khi có câu hỏi, tìm vài đoạn liên quan nhất, bằng đếm từ khóa hoặc bằng cách so nghĩa. Ba là ghép các đoạn đó vào prompt rồi mới gọi mô hình, kèm yêu cầu chỉ trả lời dựa trên các đoạn đó.

Nên dùng RAG khi:

1. Tài liệu đủ dài để gửi cả tài liệu là tốn. Mọi thứ trong prompt được gửi lại ở mỗi lần gọi, nên chi phí và độ trễ tăng theo độ dài tài liệu, còn RAG chỉ gửi vài đoạn.
2. Tài liệu thay đổi thường xuyên. Sửa tài liệu và cập nhật chỉ mục, không phải viết lại prompt.
3. Bạn cần biết câu trả lời dựa vào đâu. Mỗi đoạn có tên, nên có thể bắt mô hình trích nguồn và kiểm tra lại.

Không nên dùng RAG khi tài liệu chỉ vài trang. Gửi cả tài liệu đơn giản hơn và bớt một chỗ có thể sai.

Ý quan trọng để nêu: RAG thêm một chỗ để lỗi xảy ra là bước tìm kiếm. Nếu bước đó không đưa đúng đoạn, mô hình có thể trả lời thiếu hoặc đoán, trong khi câu trả lời vẫn nghe rất trôi chảy. Vì vậy khi RAG trả lời sai, việc đầu tiên là xem các đoạn nào đã được gửi đi, chứ không phải sửa prompt ngay.

Điểm cộng: kể một ví dụ cụ thể, như khách hỏi "tiền về bao lâu" trong khi tài liệu viết "thời hạn hoàn tiền". Tìm theo từ khóa bỏ sót câu này vì hai cách nói không có chữ nào chung, và đó là lý do người ta chuyển sang tìm theo nghĩa bằng embedding.