Một mô hình ngôn ngữ lớn không biết gì về công ty bạn. Hỏi nó quy trình duyệt chi của phòng kế toán, nó sẽ trả lời trôi chảy, tự tin, và hoàn toàn bịa. Nó không nói dối — nó chỉ đang làm đúng việc nó được huấn luyện để làm là sinh ra chuỗi chữ hợp lý tiếp theo.
RAG (Retrieval-Augmented Generation) là cách xử lý chuyện đó: trước khi trả lời, hệ thống đi tìm trong kho tài liệu của bạn những đoạn liên quan tới câu hỏi, rồi đưa chúng vào cùng câu hỏi cho model. Model trả lời dựa trên tài liệu thật thay vì dựa trên trí nhớ mờ từ lúc huấn luyện.
Ý tưởng đơn giản. Chỗ khó nằm ở một chi tiết mà nhiều đội bỏ qua: chất lượng câu trả lời phụ thuộc gần như hoàn toàn vào bước tìm kiếm, không phải bước sinh câu trả lời.
Vì sao bước tìm kiếm quyết định tất cả
Hãy hình dung một thư ký rất giỏi diễn đạt nhưng chưa từng đọc hồ sơ công ty. Bạn hỏi một câu, một người khác chạy vào kho lấy ra ba trang tài liệu đưa cho thư ký, và thư ký đọc lướt rồi trả lời bạn.
Nếu người chạy vào kho lấy nhầm hồ sơ, thư ký sẽ trả lời sai — dù diễn đạt vẫn rất trôi chảy. Đổi sang một thư ký giỏi hơn không giải quyết được gì.
Đó chính xác là quan hệ giữa retrieval và generation. Đổi từ model rẻ sang model đắt nhất thị trường cải thiện cách diễn đạt và khả năng suy luận trên tài liệu đã cho, nhưng nếu tài liệu đưa vào là sai thì câu trả lời vẫn sai.
Vì vậy khi một hệ thống RAG cho kết quả kém, câu hỏi đầu tiên không phải "dùng model nào" mà là "với câu hỏi này, hệ thống đã lấy ra những đoạn nào". Ghi lại các đoạn được lấy ra cho mỗi truy vấn là việc rẻ tiền nhất và có ích nhất mà một dự án RAG có thể làm ngay từ đầu.
Chia nhỏ tài liệu — chỗ hỏng phổ biến nhất
Tài liệu phải được cắt thành từng đoạn trước khi đánh chỉ mục, vì không thể nhét cả cuốn sổ tay hai trăm trang vào một câu hỏi.
Cách làm mặc định trong hầu hết thư viện là cắt theo số ký tự — ví dụ mỗi đoạn 1.000 ký tự, chồng lấn 200 ký tự. Cách này chạy được, và cũng là chỗ sinh ra phần lớn vấn đề.
Cắt theo số ký tự không quan tâm tới cấu trúc. Nó cắt ngang một bảng, tách tiêu đề mục khỏi nội dung của mục đó, hoặc chia một quy trình sáu bước thành hai đoạn mà đoạn sau bắt đầu bằng "bước 4" không có ngữ cảnh nào.
Cách tốt hơn là cắt theo cấu trúc tài liệu: mỗi mục là một đoạn, giữ nguyên bảng, và gắn kèm đường dẫn tiêu đề vào đầu mỗi đoạn. Một đoạn bắt đầu bằng "Sổ tay nhân sự > Chế độ nghỉ phép > Nghỉ không lương" mang nhiều thông tin hơn hẳn cùng đoạn đó không có dòng dẫn.
Với tài liệu tiếng Việt còn một chi tiết nữa: nhiều thư viện đếm token theo cách tối ưu cho tiếng Anh, và tiếng Việt có dấu thường tốn nhiều token hơn cho cùng một lượng nội dung. Đoạn 1.000 ký tự tiếng Việt không tương đương 1.000 ký tự tiếng Anh về chi phí.
Tìm bằng vector là chưa đủ
Cách tìm kiếm phổ biến trong RAG là semantic search — tìm theo nghĩa. Mỗi đoạn tài liệu được chuyển thành một vector, câu hỏi cũng vậy, và hệ thống lấy những đoạn có vector gần nhất.
Cách này mạnh ở chỗ nó hiểu được câu hỏi diễn đạt khác với tài liệu. Hỏi "nghỉ đẻ được bao lâu" vẫn tìm ra mục viết "chế độ thai sản".
Nhưng nó yếu đúng ở chỗ tìm kiếm truyền thống mạnh: từ khoá chính xác. Mã sản phẩm MX-2200, số hiệu văn bản 13/2023/NĐ-CP, tên riêng ít gặp — semantic search hay bỏ sót những thứ này, vì với model thì MX-2200 và MX-2100 gần như giống hệt nhau.
Cách xử lý thông thường là hybrid search: chạy song song tìm theo vector và tìm theo từ khoá, rồi gộp kết quả lại. Thêm phần từ khoá vào một hệ thống chỉ có vector thường cải thiện rõ rệt, và đây là một trong những thay đổi đáng làm sớm.
Sau bước gộp, nếu cần chính xác hơn nữa thì thêm reranker — một model nhỏ đọc từng cặp câu hỏi và đoạn tài liệu rồi chấm điểm mức độ liên quan. Reranker chậm hơn nhiều so với so sánh vector, nên nó chỉ chạy trên vài chục đoạn đã lọc ra chứ không chạy trên toàn kho.
Đánh giá: thứ dễ bỏ qua nhất
Một dự án RAG không có cách đo thì không bao giờ kết thúc. Luôn có thể sửa thêm prompt, luôn có thể thử model khác, và không ai chứng minh được lần sửa vừa rồi làm mọi thứ tốt lên hay tệ đi.
Thứ cần có là một tập câu hỏi thật kèm câu trả lời đúng — lấy từ chính công việc hàng ngày, không phải nghĩ ra. Ba mươi tới năm mươi câu đã đủ để bắt đầu. Với mỗi câu, ghi rõ đoạn tài liệu nào chứa câu trả lời.
Có tập đó rồi thì đo được hai thứ tách biệt, và đây là điểm quan trọng:
Retrieval có lấy đúng đoạn không — đo bằng tỉ lệ câu hỏi mà đoạn chứa câu trả lời nằm trong nhóm được lấy ra. Chỉ số này không phụ thuộc vào model sinh câu trả lời.
Câu trả lời có đúng không — đo trên những câu mà retrieval đã lấy đúng.
Tách hai chỉ số ra là cách duy nhất để biết nên sửa chỗ nào. Nếu retrieval chỉ đúng 60% thì mọi công sức chỉnh prompt đều lãng phí; vấn đề nằm ở chỗ khác.
Khi nào RAG không phải câu trả lời
Không phải bài toán nào cũng hợp.
Nếu câu hỏi cần tổng hợp toàn bộ dữ liệu — "tháng này doanh thu bao nhiêu" — thì đó là việc của một câu query vào database, không phải của RAG. RAG lấy ra vài đoạn liên quan; nó không đếm được trên toàn bộ kho.
Nếu tài liệu thay đổi liên tục trong ngày, chi phí đánh chỉ mục lại có thể vượt lợi ích.
Và nếu câu trả lời phải chính xác tuyệt đối, không sai lệch — số liệu tài chính công bố, điều khoản hợp đồng — thì nên để hệ thống dẫn người dùng tới đúng tài liệu gốc thay vì tóm tắt lại. Một đường link tới đúng điều khoản có giá trị hơn một bản tóm tắt trôi chảy mà không ai dám tin.
Tóm lại
Phần khó của RAG không nằm ở chỗ chọn model. Nó nằm ở việc chia tài liệu sao cho mỗi đoạn tự nó có nghĩa, tìm kiếm kết hợp cả nghĩa lẫn từ khoá, và có một tập đánh giá đủ tốt để biết mỗi thay đổi làm hệ thống tốt lên hay tệ đi.
Ba việc đó nghe kém hấp dẫn hơn nhiều so với việc so sánh các model mới nhất. Nhưng chúng mới là thứ quyết định hệ thống có dùng được không.
Nice Solutions triển khai LLM và RAG vào vận hành doanh nghiệp, và phát triển 9G Platform — nền tảng quản lý tập trung hơn 39 AI model trên cloud lẫn on-premise. Xem thêm giải pháp AI cho doanh nghiệp.