Một đồng nghiệp thả câu hỏi vào group chat ngay trước giờ ăn trưa: "Chính sách refund cho annual plan cuối cùng mình chốt thế nào rồi?" Có người nhớ một meeting note. Có người khác nhớ bản nháp help center. Product spec có một phiên bản, support macro có một phiên bản khác, và quyết định mới nhất có thể đang nằm trong một doc có tiêu đề không ai nhớ chính xác. Đây là khoảnh khắc rất bình thường nơi AI assistant có thể trả lời nghe rất hay, nhưng vẫn sai nếu nó chỉ dựa vào trí nhớ chung.
Retrieval-Augmented Generation, thường gọi tắt là RAG, là một cách xử lý thực tế cho vấn đề đó. Thay vì bắt language model chỉ dựa vào những gì nó đã học trong quá trình training, một hệ thống RAG trước tiên đi tìm thông tin liên quan trong tài liệu, ticket, wiki, code snippet hoặc knowledge base của chính bạn. Sau đó nó đưa các phần tìm được cho model và yêu cầu model viết câu trả lời dựa trên những phần đó.
Cách hiểu đơn giản là: tìm trước, trả lời sau. Model vẫn là phần viết và suy luận, nhưng nguyên liệu đến từ bước retrieval ngay trước khi câu trả lời được tạo ra. Điều này quan trọng vì nhiều câu hỏi trong công việc phụ thuộc vào thông tin thay đổi thường xuyên: policy, hành vi sản phẩm, release note, pricing rule, quy trình onboarding, lịch sử khách hàng, hoặc quyết định nội bộ. Một model được train từ nhiều tháng trước không thể tự biết chắc chuyện gì vừa đổi hôm qua.
RAG thường bắt đầu bằng việc chuẩn bị knowledge base. Tài liệu dài được chia thành các phần nhỏ hơn, gọi là chunk, vì hệ thống search thường làm việc tốt hơn với những mảnh tập trung thay vì cả file dài. Một chunk có thể là vài đoạn trong policy document, một section của engineering runbook, hoặc một phần gọn trong product spec. Chunking nghe có vẻ cơ học, nhưng đây là một trong những quyết định chất lượng đầu tiên của RAG. Chunk quá lớn sẽ mang theo nhiều nhiễu. Chunk quá nhỏ lại mất context cần thiết để hiểu đúng.
Sau khi chunking, mỗi chunk được chuyển thành embedding. Embedding là một danh sách số đại diện cho ý nghĩa của đoạn text theo cách máy tính có thể so sánh. Có thể hình dung nó như việc đặt từng đoạn văn lên một bản đồ lớn về ý nghĩa. Các chunk nói về refund nằm gần những chunk khác liên quan đến refund. Các chunk nói về xóa tài khoản nằm ở vùng khác. Con người không đọc trực tiếp các con số đó, nhưng hệ thống có thể hỏi: "những đoạn text nào gần nhất về mặt ý nghĩa với câu hỏi này?"
Các embedding đó được lưu trong vector database hoặc vector index. Khi người dùng đặt câu hỏi, hệ thống cũng chuyển câu hỏi thành embedding, so sánh với embedding của các chunk đã lưu, rồi lấy ra những kết quả gần nhất. Bước này thường được gọi là vector search hoặc semantic search. Nó khác keyword search thuần túy vì có thể tìm theo nghĩa liên quan, ngay cả khi từ khóa không trùng hoàn toàn. Một câu hỏi về "hủy gói annual" vẫn có thể tìm được chunk có tiêu đề "refund rule cho yearly billing" nếu embedding model nhận ra hai cách nói này gần nhau.
Khi hệ thống đã lấy được một nhóm chunk có vẻ liên quan, nó xây prompt cho language model. Prompt thường gồm câu hỏi của người dùng, context đã retrieval, và các chỉ dẫn như "chỉ trả lời từ các nguồn này" hoặc "hãy nói rõ khi nguồn không đủ thông tin." Đây là bước grounding. Mục tiêu không phải biến model thành một cỗ máy luôn đúng. Mục tiêu là thu hẹp nguyên liệu làm việc để câu trả lời bám vào evidence mà hệ thống có thể kiểm tra.
Citation là một phần hữu ích của grounding. Nếu model nói annual plan được refund trong vòng mười bốn ngày, giao diện nên chỉ ra document hoặc chunk nào hỗ trợ câu đó. Citation làm hai việc cùng lúc. Nó giúp người đọc tự kiểm chứng câu trả lời, và nó giúp debug hệ thống dễ hơn. Khi câu trả lời sai, mình có thể hỏi cụ thể: retrieval đã lấy sai nguồn, nguồn đó đã cũ, hay model đã không bám vào nguồn được đưa vào?
Thói quen debug này rất quan trọng vì RAG có nhiều failure mode. Có lúc retrieval bỏ lỡ chunk đúng vì câu hỏi được diễn đạt lạ, tài liệu bị chunk chưa tốt, hoặc embedding model không bắt được ngôn ngữ chuyên môn của domain. Có lúc retrieval lấy đúng chủ đề nhưng policy đã cũ. Có lúc hai chunk mâu thuẫn nhau, và model lại làm câu trả lời nghe mượt thay vì nói nguồn đang không thống nhất. Có lúc model viết một câu rất tự tin, nghe như có căn cứ, nhưng thêm một chi tiết không hề nằm trong context. RAG giảm việc đoán không có cơ sở; nó không loại bỏ nhu cầu kiểm chứng.
Vì vậy một hệ thống RAG tốt cần evaluation, không chỉ cần một demo đẹp. Team thường tạo một bộ câu hỏi thật, kèm source document mong đợi và câu trả lời chấp nhận được. Với mỗi câu hỏi, họ kiểm tra retrieval có tìm đúng chunk không, câu trả lời có dùng chunk đó chính xác không, citation có trỏ đúng chỗ không, và hệ thống có chịu từ chối khi knowledge base không đủ evidence không. Cách này tách hai vấn đề dễ bị trộn lẫn: chất lượng search và chất lượng answer.
Các metric hữu ích nhất đôi khi rất đời thường. Với retrieval, hãy hỏi nguồn đúng có xuất hiện trong vài kết quả đầu không. Với answer quality, hãy hỏi câu trả lời có trung thành với nguồn được lấy ra không, có đủ để người dùng làm việc tiếp không, và có thành thật khi chưa chắc không. Khi đưa vào production, hãy theo dõi những câu hỏi fail lặp lại. Chúng thường chỉ ra tài liệu bị thiếu, ownership chưa rõ, nội dung đã cũ, hoặc chiến lược chunking nhìn ổn trong notebook nhưng gãy khi gặp công việc thật.
RAG cũng phụ thuộc vào sức khỏe khá nhàm chán của knowledge base. Nếu tài liệu gốc đã cũ, trùng lặp, hoặc được viết theo năm kiểu khác nhau, retrieval sẽ trung thành mang sự lộn xộn đó lên trước mặt model. Lớp AI không thể tự sửa một hệ thống knowledge không ai maintain. Với nhiều team, phần khó nhất của RAG không phải embedding hay vector search. Đó là quyết định tài liệu nào đáng tin, ai cập nhật chúng, nội dung cũ được retire thế nào, và hệ thống xử lý thông tin nhạy cảm ra sao.
Có một cách bình tĩnh để nhìn RAG: nó không phải đường tắt để khỏi cần hiểu. Nó là cách nối language model với kệ evidence hiện tại trước khi model trả lời. Model vẫn cần boundary. Tài liệu vẫn cần được chăm sóc. Output vẫn cần kiểm tra đúng mức. Nhưng khi các mảnh đó có mặt, RAG có thể biến AI assistant từ một người trả lời chung chung nhưng tự tin thành một người đọc hữu ích hơn với chính tài liệu mà team đang dùng hằng ngày.
Lần tới khi một câu trả lời AI nghe có vẻ đúng, câu hỏi hữu ích không chỉ là câu chữ có rõ không. Câu hỏi là câu trả lời đó đến từ đâu. Chunk nào đã được retrieval? Nguồn có còn mới không? Citation có thật sự chống đỡ claim không? Nếu bạn từng build hoặc dùng một hệ thống RAG nhỏ, hãy thử so sánh nơi nó giúp nhiều nhất và nơi nó fail âm thầm. Thường chính phần so sánh đó mới là nơi mình học được nhiều nhất.