RAG (retrieval-augmented generation, sinh văn bản có truy xuất tăng cường) là kỹ thuật cho mô hình ngôn ngữ tìm và đọc tài liệu liên quan trước, rồi mới viết câu trả lời dựa trên các đoạn tài liệu đó. Thay vì chỉ dựa vào trí nhớ nén trong tham số, mô hình được "mở sách" khi làm bài. Đây là nền của hầu hết chatbot trả lời từ tài liệu nội bộ doanh nghiệp, các công cụ tìm kiếm có AI, và tính năng hỏi đáp trên tệp bạn tải lên.
RAG giảm mạnh ảo giác về dữ kiện, cập nhật được thông tin mới mà không cần huấn luyện lại, và cho phép hiển thị nguồn để người dùng kiểm. Nhưng nó không biến AI thành cỗ máy chân lý: chất lượng câu trả lời bị giới hạn bởi chất lượng khâu tìm, khâu cắt tài liệu, và độ trung thành của mô hình với đoạn đã tìm. Hiểu các khâu này giúp bạn biết vì sao một câu trả lời "có trích nguồn" vẫn sai, và biết hỏi gì khi doanh nghiệp định triển khai một hệ thống như vậy.
Nguồn gốc ý tưởng và vì sao nó cần thiết
Thuật ngữ RAG được phổ biến bởi bài báo của Patrick Lewis và cộng sự tại Facebook AI Research, công bố năm 2020, đề xuất kết hợp một bộ truy xuất tài liệu với một mô hình sinh văn bản cho các tác vụ đòi hỏi nhiều tri thức. Ý tưởng ghép tìm kiếm với trả lời câu hỏi có từ trước đó trong ngành truy xuất thông tin, nhưng sự phổ biến của mô hình ngôn ngữ lớn từ năm 2023 khiến RAG thành kiến trúc mặc định khi doanh nghiệp muốn AI dùng tài liệu riêng.
Lý do rất thực tế. Mô hình nền có ba giới hạn mà RAG nhắm thẳng vào: kiến thức dừng ở thời điểm huấn luyện; không biết tài liệu nội bộ (quy trình, hợp đồng, sản phẩm của công ty bạn); và không chỉ ra được căn cứ cho câu trả lời. Huấn luyện lại hoặc tinh chỉnh mô hình trên tài liệu nội bộ vừa tốn kém, vừa không giải quyết được vấn đề căn cứ, vì kiến thức sau tinh chỉnh vẫn bị nén vào tham số.
Với RAG, tài liệu nằm ngoài mô hình và có thể cập nhật bất cứ lúc nào. Sửa một quy định nội bộ chỉ cần thay tệp trong kho; câu trả lời hôm sau sẽ dựa trên bản mới. Phân quyền cũng làm được ở khâu tìm: nhân viên phòng nào chỉ được tìm trong tài liệu phòng đó.
Một hệ thống RAG chạy qua những bước nào
Dưới giao diện chat đơn giản là một chuỗi xử lý. Mỗi bước là một chỗ có thể hỏng, nên đáng biết tên chúng:
- Nạp và làm sạch tài liệu: chuyển PDF, Word, trang web, bảng tính thành văn bản. Bảng biểu, chú thích, tài liệu quét không có lớp chữ là nơi hay mất thông tin ngay từ đầu.
- Cắt đoạn (chunking): chia tài liệu thành các đoạn vài trăm tới hơn một nghìn token. Cắt quá nhỏ thì mất ngữ cảnh; quá lớn thì loãng và tốn chỗ.
- Tạo véc-tơ nhúng (embedding): mỗi đoạn được một mô hình chuyên dụng chuyển thành véc-tơ số biểu diễn ý nghĩa; các đoạn có nghĩa gần nhau nằm gần nhau trong không gian véc-tơ. Véc-tơ được lưu vào cơ sở dữ liệu chuyên cho tìm kiếm tương tự.
- Truy xuất: câu hỏi của người dùng cũng được chuyển thành véc-tơ, hệ thống lấy ra các đoạn gần nhất. Nhiều hệ thống kết hợp thêm tìm kiếm theo từ khoá truyền thống để bắt tên riêng, mã số, số hiệu văn bản mà tìm theo nghĩa hay bỏ sót.
- Xếp hạng lại (re-ranking): một mô hình khác chấm lại mức liên quan của các đoạn ứng viên, giữ lại những đoạn tốt nhất.
- Sinh câu trả lời: các đoạn được chèn vào ngữ cảnh cùng câu hỏi và chỉ dẫn "chỉ trả lời dựa trên tài liệu, trích nguồn". Mô hình viết câu trả lời và gắn tham chiếu.
Khi một hệ thống RAG trả lời sai, câu hỏi chẩn đoán đầu tiên là: đoạn tài liệu đúng có được lấy ra không? Nếu không, lỗi nằm ở khâu tìm; nếu có mà vẫn sai, lỗi nằm ở khâu sinh.
Năm cách một câu trả lời "có nguồn" vẫn sai
Tìm trượt. Đoạn chứa câu trả lời không nằm trong số đoạn được lấy ra, thường vì câu hỏi dùng từ khác tài liệu ("nghỉ phép" so với "nghỉ hằng năm"), hoặc vì thông tin nằm rải ở nhiều đoạn. Mô hình khi đó trả lời từ đoạn gần nghĩa nhất hoặc từ trí nhớ của nó, nhưng vẫn gắn trích dẫn.
Cắt mất ngữ cảnh. Một đoạn được lấy ra chứa quy định nhưng phần ngoại lệ nằm ở đoạn kế bên, hoặc một bảng bị cắt ngang làm mất tiêu đề cột. Câu trả lời trích đúng câu nhưng hiểu sai phạm vi.
Tài liệu mâu thuẫn hoặc lỗi thời. Kho chứa cả bản quy trình cũ và mới. Bộ truy xuất không biết bản nào còn hiệu lực trừ khi tài liệu được gắn siêu dữ liệu ngày hiệu lực và hệ thống được thiết kế để ưu tiên bản mới.
Mô hình không trung thành với đoạn. Đoạn đúng đã có trong ngữ cảnh nhưng mô hình vẫn pha thêm kiến thức chung, khái quát quá mức, hoặc chọn nhầm đoạn khi các đoạn nói khác nhau. Đặc biệt hay xảy ra khi kiến thức phổ biến trái với quy định riêng của tổ chức.
Trích dẫn gắn sai câu. Câu trả lời tổng hợp từ ba đoạn nhưng số trích dẫn gắn lệch, khiến người kiểm mở nguồn thấy không khớp và nghĩ là bịa, hoặc ngược lại, thấy nguồn liên quan và không đọc kỹ câu.
RAG, tinh chỉnh hay ngữ cảnh dài: chọn thế nào
Ba cách đưa tri thức riêng vào AI thường bị nhầm lẫn. Bảng so sánh dưới giúp đặt đúng kỳ vọng trước khi chọn giải pháp:
| Tiêu chí | RAG | Tinh chỉnh (fine-tuning) | Dán thẳng vào ngữ cảnh dài |
|---|---|---|---|
| Phù hợp nhất cho | Kho tài liệu lớn, thay đổi thường xuyên, cần nguồn | Dạy phong cách, định dạng, thuật ngữ, hành vi | Vài tài liệu cụ thể cho một phiên làm việc |
| Cập nhật tri thức | Thay tài liệu là xong | Phải huấn luyện lại | Dán bản mới |
| Trích nguồn | Có, nếu thiết kế tốt | Không tự nhiên | Có thể yêu cầu trích nguyên văn |
| Phân quyền theo người dùng | Làm được ở khâu tìm | Khó | Do người dán quyết định |
| Điểm yếu chính | Phụ thuộc chất lượng tìm và cắt đoạn | Không giảm bịa dữ kiện đáng kể | Giới hạn độ dài, thông tin ở giữa dễ bị bỏ qua |
Hiểu lầm phổ biến là "tinh chỉnh mô hình trên tài liệu công ty để nó biết hết". Trong thực tế, tinh chỉnh thay đổi cách mô hình nói nhiều hơn là thêm dữ kiện đáng tin vào trí nhớ của nó. Phần lớn nhu cầu hỏi đáp tài liệu nội bộ phù hợp với RAG; tinh chỉnh dùng bổ sung khi cần giọng văn hay định dạng chuyên biệt.
Đánh giá một hệ thống RAG nội bộ: danh mục kiểm tra
Trước khi đưa chatbot tài liệu vào sử dụng rộng, nhóm triển khai nên đo được các điểm sau, thay vì dựa vào vài câu hỏi thử thấy "khá ổn":
- Bộ câu hỏi chuẩn: vài chục tới vài trăm câu hỏi thật của người dùng, kèm đáp án và vị trí tài liệu đúng, do người am hiểu nghiệp vụ soạn. Gồm cả câu mà tài liệu không có câu trả lời.
- Tỷ lệ tìm đúng: trong số câu hỏi, bao nhiêu phần trăm có đoạn đúng nằm trong các đoạn được lấy ra. Chỉ số này tách lỗi khâu tìm khỏi lỗi khâu sinh.
- Độ trung thành: mỗi nhận định trong câu trả lời có được đoạn nguồn ủng hộ không. Có thể chấm bằng người hoặc bằng mô hình hỗ trợ, kèm kiểm tra mẫu bằng người.
- Biết từ chối: với câu hỏi ngoài tài liệu, hệ thống có nói "không tìm thấy" hay vẫn trả lời từ kiến thức chung.
- Quản lý phiên bản tài liệu: có quy trình loại bỏ bản hết hiệu lực, gắn ngày hiệu lực, chỉ định người chịu trách nhiệm cho từng nhóm tài liệu.
- Phân quyền và nhật ký: kiểm thử rằng người không có quyền không lấy được nội dung tài liệu mật qua câu hỏi khéo léo, và có nhật ký truy vấn để rà soát.
Danh mục này cũng là bộ câu hỏi tốt khi làm việc với nhà cung cấp giải pháp: một nhà cung cấp nghiêm túc sẽ trình bày được cách họ đo từng mục, không chỉ trình diễn vài câu hỏi đẹp.
Ví dụ: chatbot quy chế nhân sự của một công ty sản xuất
Xét một tình huống giả định. Một công ty sản xuất ở Bắc Ninh với khoảng một nghìn lao động đưa sổ tay nhân sự, nội quy lao động, quy chế lương thưởng và các thông báo nội bộ vào một chatbot RAG để công nhân hỏi qua điện thoại. Tuần đầu, câu hỏi "ca đêm được phụ cấp bao nhiêu" nhận câu trả lời sai. Kiểm tra cho thấy kho có cả quy chế lương năm trước và bản sửa đổi năm nay; bộ truy xuất lấy bản cũ vì nó có câu chữ khớp câu hỏi hơn.
Lỗi thứ hai: câu hỏi "nghỉ việc riêng có lương những trường hợp nào" nhận câu trả lời thiếu một trường hợp. Nguyên nhân là danh sách trong nội quy dài, bị cắt thành hai đoạn, và chỉ đoạn đầu được lấy ra. Lỗi thứ ba: với câu hỏi về thủ tục bảo hiểm xã hội mà tài liệu nội bộ không đề cập, chatbot trả lời từ kiến thức chung của mô hình, trong đó có chi tiết đã lỗi thời.
Cách sửa không nằm ở việc đổi mô hình mạnh hơn. Nhóm triển khai gỡ bản quy chế cũ khỏi kho và gắn ngày hiệu lực cho mọi tài liệu; tăng kích thước đoạn và cho các đoạn gối lên nhau để danh sách không bị cắt; thêm chỉ dẫn bắt buộc trả lời "tài liệu nội bộ không đề cập, vui lòng hỏi phòng nhân sự" khi không tìm thấy căn cứ. Cả ba đều là việc quản trị tài liệu và thiết kế, không phải việc của AI.
Dùng công cụ có RAG như một người đọc tỉnh táo
Với người dùng cuối, nguyên tắc rút ra khá gọn. Khi công cụ hiển thị nguồn, nguồn đó là lời mời kiểm tra, không phải con dấu xác nhận. Hãy mở ít nhất nguồn gắn với nhận định quan trọng nhất và tìm câu tương ứng. Nếu câu trả lời nói nhiều hơn những gì đoạn nguồn nói, phần dư ra là phần mô hình tự thêm.
Khi hỏi chatbot tài liệu nội bộ, dùng thuật ngữ giống tài liệu nếu biết ("nghỉ hằng năm" thay vì "nghỉ phép"), và hỏi từng ý thay vì gộp. Nếu câu trả lời mơ hồ, hỏi thẳng: "Đoạn nào trong tài liệu nói điều này? Trích nguyên văn." Một hệ thống tốt sẽ trích được; một hệ thống đang đoán sẽ lộ ra.
Cuối cùng, nhớ rằng RAG chỉ tốt bằng kho tài liệu. Một tổ chức có quy trình viết mâu thuẫn, nhiều phiên bản trôi nổi, không ai chịu trách nhiệm cập nhật sẽ có chatbot trả lời mâu thuẫn tương ứng. Triển khai RAG thường buộc doanh nghiệp dọn kho tri thức của mình — và đó đôi khi là lợi ích lớn nhất của dự án.
Câu hỏi thường gặp
RAG có loại bỏ hoàn toàn ảo giác không?
Không. Nó giảm mạnh ảo giác về dữ kiện có trong kho, nhưng mô hình vẫn có thể thêm thông tin ngoài đoạn nguồn, hiểu sai đoạn bị cắt thiếu, hoặc trả lời từ trí nhớ khi khâu tìm trượt. Các đánh giá thực tế cho thấy độ trung thành phụ thuộc nhiều vào thiết kế chỉ dẫn và chất lượng tài liệu.
Tìm kiếm theo véc-tơ khác tìm theo từ khoá thế nào?
Tìm theo từ khoá khớp các từ xuất hiện trong văn bản, giỏi với tên riêng, mã số, thuật ngữ chính xác. Tìm theo véc-tơ so sánh ý nghĩa, tìm được đoạn diễn đạt khác từ nhưng cùng nội dung. Mỗi cách bỏ sót những gì cách kia bắt được, nên nhiều hệ thống dùng kết hợp cả hai.
Tài liệu tiếng Việt có gây khó cho RAG không?
Có một số khó khăn: mô hình nhúng đa ngôn ngữ có thể biểu diễn tiếng Việt kém hơn tiếng Anh, văn bản quét chất lượng thấp, bảng biểu phức tạp trong văn bản hành chính, và cách viết tắt nội bộ. Nên thử nghiệm mô hình nhúng trên chính bộ câu hỏi tiếng Việt của tổ chức trước khi chọn.
Có nên dùng RAG cho văn bản pháp luật không?
Có thể hỗ trợ tra cứu và đọc nhanh, với điều kiện kho được cập nhật tình trạng hiệu lực và văn bản sửa đổi, và người dùng luôn mở văn bản gốc trước khi áp dụng. Pháp luật có cấu trúc dẫn chiếu chéo phức tạp, nên rủi ro cắt mất ngữ cảnh cao hơn tài liệu thông thường.
Dữ liệu đưa vào hệ thống RAG có bị dùng để huấn luyện mô hình không?
Về kỹ thuật, RAG không cần huấn luyện mô hình trên tài liệu của bạn; tài liệu chỉ được đọc khi trả lời. Tuy nhiên đoạn tài liệu và câu hỏi được gửi tới mô hình, nên chính sách lưu trữ và huấn luyện của nhà cung cấp vẫn áp dụng. Cần đọc điều khoản, đặc biệt với tài liệu mật.
Một doanh nghiệp nhỏ có cần tự xây RAG không?
Thường là không cần từ đầu. Nhiều công cụ văn phòng và dịch vụ AI đã có tính năng hỏi đáp trên tệp hoặc trên kho tài liệu. Việc đáng đầu tư hơn là chuẩn hoá tài liệu, loại bản cũ, đặt tên rõ ràng, và soạn bộ câu hỏi chuẩn để thử bất kỳ công cụ nào định dùng.