Wavi Books · AI, LLM & AI Agent

RAG là gì trong AI? Cách xây chatbot trả lời theo dữ liệu riêng

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

Tìm hiểu RAG là gì, kiến trúc retrieval, embedding, vector database và cách xây chatbot trả lời theo dữ liệu doanh nghiệp.

## RAG là gì trong AI

Retrieval-Augmented Generation (RAG) là kiến trúc kết hợp truy xuất tài liệu với mô hình ngôn ngữ lớn. Thay vì chỉ dựa vào kiến thức đã học, hệ thống tìm các đoạn dữ liệu liên quan rồi đưa chúng vào ngữ cảnh để mô hình tạo câu trả lời có căn cứ.

RAG phù hợp với chatbot nội bộ, trợ lý tra cứu quy trình, hỏi đáp tài liệu kỹ thuật và chăm sóc khách hàng. Giá trị chính không nằm ở việc nối một vector database vào LLM, mà ở chất lượng tài liệu, chiến lược chia đoạn, truy xuất và đánh giá câu trả lời.

## Những khái niệm cốt lõi cần nắm

- Nguồn dữ liệu được làm sạch và gắn metadata.

- Embedding biểu diễn đoạn văn thành vector.

- Retriever tìm ngữ cảnh liên quan theo truy vấn.

- LLM tổng hợp câu trả lời và dẫn nguồn.

## Lộ trình thực hành từng bước

- Bước 1: Chọn một tập tài liệu nhỏ có câu hỏi kiểm thử rõ ràng.

- Bước 2: Thiết kế chunking, metadata và phép đo retrieval.

- Bước 3: Thêm prompt, trích dẫn nguồn, guardrail và theo dõi lỗi.

## Những sai lầm thường gặp

- Đưa toàn bộ tài liệu vào một chunk quá dài.

- Chỉ đánh giá câu chữ mà không kiểm tra nguồn.

- Dùng RAG cho dữ liệu cần cập nhật giao dịch theo thời gian thực.

## Góc nhìn dành cho người học và developer Việt Nam

Tại doanh nghiệp Việt Nam, nên bắt đầu với tài liệu tiếng Việt đã chuẩn hóa dấu, tiêu đề và quyền truy cập. Bộ câu hỏi đánh giá phải lấy từ tình huống thật của nhân viên hoặc khách hàng.

## Nên học tiếp như thế nào?

Sau khi nắm phần cốt lõi, bạn nên tự xây một dự án nhỏ, ghi lại giả định, tiêu chí đánh giá và giới hạn của giải pháp. Các sách liên quan được Wavi Books gợi ý trong bài giúp bạn đào sâu kiến thức theo lộ trình có hệ thống thay vì chỉ ghép các hướng dẫn rời rạc.

## Kiến trúc RAG từ câu hỏi đến câu trả lời

Một hệ thống RAG hoàn chỉnh có hai pipeline khác nhau. Pipeline indexing đọc tài liệu, làm sạch, chia đoạn, tạo embedding và lưu vector cùng metadata. Pipeline truy vấn nhận câu hỏi, có thể viết lại truy vấn, tìm đoạn liên quan, xếp hạng lại rồi mới tạo prompt cho LLM. Tách hai pipeline giúp đội kỹ thuật cập nhật dữ liệu mà không phải thay đổi toàn bộ ứng dụng.

Chất lượng cuối cùng là tích của nhiều mắt xích. Tài liệu sai khiến retrieval sai; retrieval sai khiến LLM không có đủ bằng chứng; prompt thiếu quy tắc khiến mô hình trả lời vượt quá nguồn. Vì vậy không nên chỉ đánh giá câu trả lời trôi chảy. Cần đo riêng khả năng tìm đúng tài liệu và khả năng tổng hợp đúng từ tài liệu đã tìm.

### Chunking không chỉ là cắt theo số ký tự

Đoạn quá ngắn làm mất ngữ cảnh, đoạn quá dài làm nhiễu embedding và chiếm cửa sổ context. Với tài liệu kỹ thuật, nên ưu tiên ranh giới tự nhiên như tiêu đề, mục, hàm, bảng hoặc quy trình. Metadata nên lưu loại tài liệu, phiên bản, phòng ban, ngày hiệu lực và quyền truy cập. Khi truy vấn, metadata filter thường làm tăng độ chính xác mạnh hơn việc đổi vector database.

Một điểm khởi đầu thực tế là 300–700 token mỗi đoạn, overlap nhỏ và giữ tiêu đề cha trong nội dung. Đây không phải con số cố định; hãy tạo tập 30–50 câu hỏi thật rồi so sánh nhiều chiến lược chunking bằng recall@k và tỷ lệ câu hỏi có đủ bằng chứng trong top-k.

### Luồng RAG tối giản bằng Python

```python question = normalize(user_question) query_vector = embed(question) candidates = vector_store.search( query_vector, top_k=20, filters={"status": "active", "language": "vi"} ) contexts = rerank(question, candidates)[:5] answer = llm.generate( system="Chỉ trả lời từ nguồn được cung cấp; thiếu dữ liệu phải nói rõ.", context=contexts, question=question ) return answer, collect_citations(contexts) ```

Đoạn mã cho thấy vector search chỉ là bước tạo ứng viên. Với dữ liệu có nhiều đoạn gần giống nhau, reranker giúp sắp xếp lại dựa trên quan hệ trực tiếp giữa câu hỏi và tài liệu. Trong production còn cần timeout, cache, kiểm soát token, lọc dữ liệu nhạy cảm và log phiên bản tài liệu đã dùng.

## Đánh giá RAG như một hệ thống kỹ thuật

Bộ đánh giá nên có câu hỏi, câu trả lời kỳ vọng, tài liệu chuẩn và nhãn về mức độ khó. Retrieval có thể đo hit rate, recall@k, mean reciprocal rank. Generation cần kiểm tra tính đúng, mức bám nguồn, độ đầy đủ và khả năng từ chối khi không có dữ liệu. Ngoài đánh giá tự động bằng LLM, nên lấy mẫu thủ công vì mô hình chấm cũng có thể thiên lệch.

Trong vận hành, hãy theo dõi latency từng bước, tỷ lệ không tìm thấy tài liệu, số token, chi phí mỗi câu hỏi, nguồn được trích dẫn nhiều nhất và phản hồi của người dùng. Nếu chỉ nhìn tổng latency và thumbs-up, đội kỹ thuật khó biết lỗi nằm ở embedding, index, reranker hay prompt.

## Case study: trợ lý tra cứu quy trình nội bộ

Giả sử doanh nghiệp có 2.000 tài liệu quy trình. Phiên bản đầu nên giới hạn ở một phòng ban, chọn tài liệu còn hiệu lực, tạo 50 câu hỏi từ ticket hỗ trợ thật và yêu cầu câu trả lời luôn có đường dẫn nguồn. Sau khi baseline ổn định mới mở rộng sang phòng ban khác. Quyền truy cập phải được lọc trước khi context đi vào LLM; không được trông chờ prompt ngăn mô hình tiết lộ dữ liệu.

### Checklist đưa RAG vào production

- Có tập đánh giá cố định và tập câu hỏi mới được bổ sung hằng tuần.

- Quản lý phiên bản tài liệu, embedding model và cấu hình chunking.

- Có trích dẫn nguồn, cơ chế từ chối và đường dẫn phản hồi.

- Kiểm thử truy vấn tiếng Việt không dấu, viết tắt và thuật ngữ pha tiếng Anh.

- Phân quyền ở retrieval, ẩn dữ liệu nhạy cảm và lưu audit log.

- Đo retrieval, generation, latency và chi phí thành các lớp riêng.

## Bài tập thực hành

Hãy chọn 10 trang tài liệu, viết 20 câu hỏi gồm câu có đáp án, không có đáp án và câu mơ hồ. Xây baseline với keyword search, sau đó thêm embedding và reranker. Ghi lại trường hợp mỗi phương pháp thắng hoặc thua. Bài tập này giúp hiểu RAG sâu hơn nhiều so với việc chỉ chạy một notebook mẫu.