RAG (retrieval augmented generation, tạm dịch là sinh câu trả lời có tra cứu) là cách cho mô hình ngôn ngữ trả lời dựa trên tài liệu riêng của bạn: mỗi khi có câu hỏi, hệ thống tìm vài đoạn tài liệu liên quan nhất, đưa chúng vào câu lệnh cùng câu hỏi, và yêu cầu mô hình chỉ trả lời dựa trên những đoạn đó. Mô hình không được huấn luyện lại; nó chỉ được đưa đúng trang cần đọc vào đúng lúc.
Bài này dành cho lập trình viên được giao làm trợ lý trả lời theo tài liệu hướng dẫn sản phẩm, quy định nội bộ hay kho câu hỏi thường gặp. Bạn sẽ biết khi nào cần RAG và khi nào không, năm bước dựng một hệ RAG tối thiểu, cách chia đoạn và tìm kiếm cho tiếng Việt, cách ghép câu lệnh để có trích nguồn, và những lỗi làm trợ lý trả lời sai dù tài liệu đúng.
Khi nào cần RAG, khi nào chưa
Nhiều nhóm dựng RAG khi chưa cần, hoặc dùng RAG cho việc mà một cách khác làm tốt hơn. Bảng dưới giúp bạn chọn.
| Tình huống | Cách hợp lý | Lý do |
|---|---|---|
| Tài liệu ngắn, vài chục trang, ít thay đổi | Đưa thẳng toàn bộ vào câu lệnh hệ thống, dùng lưu đệm nếu có | Đơn giản, không có bước tìm kiếm nào có thể tìm sai |
| Tài liệu dài hàng trăm, hàng nghìn trang, cập nhật thường xuyên | RAG | Không nhét vừa câu lệnh, hoặc nhét được nhưng quá tốn mỗi lần gọi |
| Câu hỏi về số liệu sống: tồn kho, trạng thái đơn, số dư | Gọi công cụ truy vấn cơ sở dữ liệu | Dữ liệu đổi từng phút, cần chính xác tuyệt đối |
| Muốn mô hình viết theo giọng hay định dạng riêng | Câu lệnh hệ thống kèm ví dụ | Đây là chuyện cách viết, không phải chuyện kiến thức |
| Tài liệu có nhiều mức quyền xem khác nhau | RAG có lọc theo quyền ở bước tìm | Phải chặn từ bước tìm, không trông vào câu lệnh |
Hàng đầu tiên đáng nhấn mạnh: cửa sổ ngữ cảnh của mô hình hiện nay đủ lớn để chứa nhiều tài liệu cỡ vừa. Nếu bộ hướng dẫn sản phẩm của bạn chỉ khoảng ba mươi trang, thử đưa thẳng vào câu lệnh trước. Bạn sẽ có bản chạy trong một buổi chiều, và có mốc để so khi sau này tài liệu lớn lên buộc phải chuyển sang RAG.
Năm bước dựng một hệ RAG tối thiểu
Mỗi bước dưới đây đều có nhiều lựa chọn công nghệ; ở đây chỉ nêu việc cần làm, phần chọn thư viện bạn tra tài liệu hiện hành.
- Thu và làm sạch tài liệu. Gom về một chỗ, chuyển sang văn bản thuần hoặc Markdown, bỏ đầu trang, chân trang, mục lục lặp lại. Ghi lại nguồn, ngày cập nhật và mức quyền xem của từng tài liệu.
- Chia đoạn. Cắt tài liệu thành các đoạn vừa đủ một ý, gắn kèm tiêu đề mục và nguồn. Chi tiết ở phần sau.
- Tạo véc-tơ nhúng và lưu. Gọi một mô hình nhúng (embedding) để biến mỗi đoạn thành một dãy số biểu diễn nghĩa, lưu cùng văn bản gốc vào nơi tìm được theo độ gần. Có thể là cơ sở dữ liệu véc-tơ chuyên dụng, hoặc tiện ích véc-tơ của cơ sở dữ liệu bạn đang dùng, ví dụ pgvector cho PostgreSQL.
- Tìm khi có câu hỏi. Nhúng câu hỏi bằng đúng mô hình nhúng đã dùng cho tài liệu, lấy vài đoạn gần nhất, lọc theo quyền của người hỏi.
- Ghép câu lệnh và trả lời. Đưa các đoạn tìm được vào câu lệnh trong khối có ranh giới rõ, kèm mã nguồn từng đoạn, yêu cầu mô hình chỉ dựa vào đó và ghi nguồn đã dùng.
Bước ba có một bẫy hay gặp: đổi mô hình nhúng là phải nhúng lại toàn bộ tài liệu, vì véc-tơ của hai mô hình khác nhau không so được với nhau. Ghi tên mô hình nhúng cùng mỗi bản ghi để không trộn lẫn.
Chia đoạn: bước quyết định chất lượng nhiều nhất
Chia theo cấu trúc trước, theo độ dài sau. Tài liệu có tiêu đề mục thì cắt theo mục; mục quá dài mới cắt tiếp theo đoạn văn. Cắt máy móc mỗi năm trăm ký tự sẽ chẻ đôi một danh sách bước, nửa đầu một đoạn, nửa sau đoạn khác, và câu trả lời sẽ thiếu bước.
Mỗi đoạn tự hiểu được. Gắn tiêu đề tài liệu và tiêu đề mục vào đầu mỗi đoạn. Đoạn “Bấm Lưu để hoàn tất” đứng một mình không cho biết đang lưu cái gì; có tiêu đề “Hướng dẫn tạo phiếu nhập kho” đi kèm thì có.
Độ dài vừa phải. Đoạn quá ngắn thiếu bối cảnh, đoạn quá dài làm loãng nghĩa khi so độ gần và tốn token khi ghép. Thử vài cỡ trên bộ câu hỏi thật rồi chọn theo kết quả, đừng chép con số từ bài hướng dẫn nào.
Chồng lấn nhỏ giữa hai đoạn liền nhau. Để lặp lại một hai câu cuối của đoạn trước ở đầu đoạn sau giúp không mất ý nằm đúng chỗ cắt.
Giữ siêu dữ liệu. Mỗi đoạn mang theo mã tài liệu, tiêu đề, ngày cập nhật, mức quyền xem. Đây là thứ để lọc khi tìm, để trích nguồn khi trả lời, và để xoá đúng đoạn khi tài liệu gốc bị gỡ.
Tìm kiếm cho tiếng Việt: véc-tơ, từ khoá hay cả hai
Tìm theo véc-tơ giỏi bắt nghĩa gần: câu hỏi “làm sao huỷ phiếu đã lưu” vẫn tìm được đoạn viết “xoá phiếu nhập kho đã tạo”. Nhưng nó kém với những thứ cần khớp chính xác: mã lỗi, tên nút, mã sản phẩm, số hiệu văn bản. Tìm theo từ khoá thì ngược lại, khớp chính xác rất tốt nhưng bỏ sót khi người hỏi dùng từ khác tài liệu.
Vì vậy nhiều hệ thực tế kết hợp cả hai: chạy song song tìm véc-tơ và tìm từ khoá, rồi gộp kết quả. Với tiếng Việt, tìm từ khoá cần chú ý chuyện dấu: người dùng gõ không dấu, gõ thiếu dấu, gõ kiểu Telex lỗi. Lưu thêm một bản không dấu của văn bản để tìm, và chuẩn hoá Unicode trước khi lưu lẫn trước khi tìm. Bài về xử lý tiếng Việt trong cùng danh mục bàn kỹ chuyện này.
Bước cuối nên có là xếp hạng lại: lấy khoảng hai mươi đoạn ứng viên, dùng một mô hình xếp hạng hoặc chính mô hình ngôn ngữ chấm mức liên quan, giữ lại vài đoạn tốt nhất. Bước này thêm độ trễ và chi phí, nên chỉ thêm khi bộ kiểm cho thấy tìm kiếm thô đang lấy sai đoạn nhiều.
Ghép câu lệnh để có trích nguồn và biết nói “không có”
Câu lệnh hệ thống cho trợ lý RAG cần ba chỉ dẫn rõ. Một: chỉ trả lời dựa trên các đoạn tài liệu được cung cấp trong khối tai_lieu. Hai: sau mỗi ý, ghi mã nguồn của đoạn đã dùng trong ngoặc vuông. Ba: nếu các đoạn không đủ để trả lời, nói rõ chưa tìm thấy thông tin trong tài liệu và gợi ý người dùng hỏi bộ phận phụ trách, không suy đoán từ kiến thức chung.
Phần trích nguồn có hai tác dụng. Với người dùng, họ bấm được vào nguồn để tự kiểm. Với bạn, máy chủ có thể kiểm tự động rằng mã nguồn mô hình ghi thật sự nằm trong danh sách đoạn đã đưa vào; mã lạ là dấu hiệu mô hình bịa. Giao diện hiển thị nguồn bằng tên tài liệu và tên mục, lấy từ siêu dữ liệu, chứ không hiện mã thô.
Chỉ dẫn thứ ba là chỗ nhiều hệ thất bại. Mô hình có xu hướng muốn giúp, nên khi không tìm thấy, nó trả lời theo hiểu biết chung, nghe rất hợp lý nhưng có thể trái quy định riêng của công ty bạn. Thêm vào bộ kiểm những câu hỏi mà tài liệu cố tình không có câu trả lời, và theo dõi tỉ lệ trợ lý nói “không có” đúng chỗ.
Những lỗi làm trợ lý RAG trả lời sai dù tài liệu đúng
Khi trợ lý trả lời sai, phản xạ đầu tiên là đổi mô hình mạnh hơn. Thường lỗi nằm ở chỗ khác:
- Tìm sai đoạn. In ra các đoạn đã tìm được cho mỗi câu hỏi trong bộ kiểm. Nếu đoạn đúng không có trong đó, mô hình nào cũng không trả lời đúng được; sửa ở bước chia đoạn và tìm kiếm.
- Tài liệu cũ và mới cùng tồn tại. Quy định năm trước và năm nay đều nằm trong kho, trợ lý trộn hai bản. Khi cập nhật tài liệu phải xoá đoạn cũ, hoặc ưu tiên theo ngày cập nhật.
- Rò tài liệu theo quyền. Nhân viên thời vụ hỏi và nhận câu trả lời trích từ tài liệu chỉ dành cho quản lý. Lọc quyền phải nằm ở bước tìm, trước khi đoạn nào được đưa vào câu lệnh.
- Dữ liệu nhạy cảm trong kho. Tài liệu nội bộ thường lẫn danh sách nhân sự, số tài khoản, thông tin khách. Rà và che trước khi nhúng, vì mọi thứ trong kho đều có thể bị trích ra trong câu trả lời.
- Câu hỏi nhiều lượt. Người dùng hỏi “còn cái kia thì sao”, câu này đứng riêng không tìm được gì. Viết lại câu hỏi thành câu đầy đủ dựa trên lịch sử trước khi tìm.
Một thói quen tốt: tách đánh giá thành hai phần, chất lượng tìm (đoạn đúng có được tìm thấy không) và chất lượng trả lời (có đoạn đúng rồi thì trả lời có đúng không). Biết lỗi nằm ở phần nào giúp bạn sửa đúng chỗ thay vì đổi mọi thứ cùng lúc.
Giữ kho tài liệu luôn mới: cập nhật, xoá và ghi vết
Hệ RAG dựng xong mới là nửa đường. Tài liệu hướng dẫn đổi khi sản phẩm ra bản mới, quy định nội bộ sửa theo quý, câu hỏi thường gặp thêm mục mỗi tuần. Nếu việc cập nhật kho phụ thuộc vào một người nhớ chạy lại đoạn mã, chỉ sau vài tháng trợ lý sẽ trả lời theo tài liệu cũ mà không ai hay.
Cách làm bền là gắn việc cập nhật vào chính nơi tài liệu được sửa. Mỗi tài liệu có mã định danh ổn định và dấu thời gian sửa cuối. Một tác vụ chạy định kỳ so dấu thời gian, tài liệu nào đổi thì xoá toàn bộ đoạn cũ theo mã tài liệu rồi chia đoạn, nhúng lại; tài liệu nào bị gỡ thì xoá đoạn tương ứng. Nhờ có siêu dữ liệu ở bước chia đoạn, việc xoá đúng chỗ chỉ là một câu truy vấn theo mã tài liệu.
Ghi vết cũng quan trọng không kém: mỗi câu trả lời lưu kèm danh sách mã đoạn đã dùng và phiên bản tài liệu tại thời điểm đó. Khi người dùng khiếu nại một câu trả lời, bạn mở lại đúng những đoạn mô hình đã đọc, biết ngay lỗi do tài liệu sai, do tìm nhầm, hay do mô hình hiểu sai. Thiếu dữ liệu này, mọi buổi gỡ lỗi đều bắt đầu bằng phỏng đoán.
Câu hỏi thường gặp
RAG có thay được việc huấn luyện lại mô hình không?
Với mục tiêu cho mô hình biết kiến thức riêng, RAG thường là lựa chọn đầu tiên vì rẻ, cập nhật được ngay và có trích nguồn. Tinh chỉnh mô hình hợp hơn với việc dạy cách viết, định dạng hay kỹ năng chuyên biệt, và không đảm bảo mô hình nhớ đúng từng chi tiết.
Có bắt buộc dùng cơ sở dữ liệu véc-tơ chuyên dụng không?
Không. Với vài nghìn đến vài chục nghìn đoạn, tiện ích véc-tơ của cơ sở dữ liệu quen thuộc thường đủ và đỡ thêm một hệ thống phải vận hành. Cơ sở dữ liệu chuyên dụng đáng cân nhắc khi quy mô lớn hoặc cần tính năng tìm kiếm phức tạp.
Mô hình nhúng có hiểu tiếng Việt không?
Nhiều mô hình nhúng đa ngôn ngữ xử lý tiếng Việt khá tốt, nhưng chất lượng chênh nhau. Cách chắc nhất là chuẩn bị vài chục cặp câu hỏi và đoạn đúng bằng tiếng Việt, thử hai ba mô hình nhúng, đếm tỉ lệ tìm trúng rồi chọn.
Nên lấy bao nhiêu đoạn đưa vào câu lệnh?
Không có số chung. Ít quá dễ thiếu thông tin, nhiều quá làm loãng và tốn token. Bắt đầu với vài đoạn, chạy bộ kiểm, tăng giảm và xem tỉ lệ trả lời đúng thay đổi thế nào.
Tài liệu dạng bảng và PDF scan thì xử lý ra sao?
Bảng nên chuyển thành văn bản có cấu trúc, mỗi dòng kèm tên cột, để đoạn tách ra vẫn hiểu được. PDF scan cần nhận dạng chữ trước, và phải đọc lại kết quả vì lỗi nhận dạng dấu tiếng Việt khá phổ biến.
Làm sao biết trợ lý RAG đang tốt lên hay xấu đi?
Giữ một bộ câu hỏi kiểm cố định có đáp án và nguồn đúng, chạy lại mỗi khi đổi cách chia đoạn, mô hình nhúng, câu lệnh hay mô hình trả lời. Ghi tỉ lệ đúng theo thời gian, kèm số câu trả lời “không có” đúng chỗ.