Trả lời ngắn: RAG là cách tìm phần nguồn liên quan rồi đưa vào context trước khi model tạo output. RAG có thể giúp câu trả lời bám vào tài liệu được chọn, nhưng không tự làm nguồn đúng, mới hoặc đủ. Nếu knowledge base lộn xộn, retrieval chọn sai hoặc context thiếu, output vẫn có thể sai và phải chuyển fallback.

Đọc xong, bạn sẽ hiểu:

  • RAG gồm knowledge base, retrieval, context và generation ở đâu.
  • Vì sao owner, version, metadata và freshness quan trọng.
  • Chunking, query và reranking ảnh hưởng kết quả tìm nguồn thế nào.
  • Cách lập một bảng test RAG 15 phút bằng dữ liệu giả.

Lưu ý giáo dục: Ví dụ dùng policy giả, mã đơn giả và nguồn minh họa. Không đưa dữ liệu khách hàng, API key, tiền thật hoặc quyền production vào bài tập.

1. RAG là đường ống bằng chứng, không phải nút “biết thêm”

a. Bốn thành phần cơ bản

RAG viết tắt của retrieval-augmented generation: retrieval tìm phần nguồn liên quan, đưa phần đó vào context, rồi generation tạo output. Knowledge base là tập nguồn được quản lý cho một mục đích, chẳng hạn policy, runbook hoặc tài liệu sản phẩm. RAG không biến mọi file trong kho thành sự thật.

Retrieval là bước tìm nguồn; context là phần được đưa vào lần chạy; generation là việc tạo câu trả lời hoặc bản nháp từ input/context. Tách bốn thành phần giúp debug: nếu nguồn đúng nhưng retrieval sai, không nên chỉ sửa câu prompt.

b. Ví dụ policy hoàn tiền

Người dùng hỏi: “Đơn A100 lỗi vận chuyển có được xem xét hoàn tiền không?”. Knowledge base có policy-v2026-01, nhưng cũng có bản policy-v2024. RAG tốt phải xác định query, tìm đúng điều khoản, đưa version phù hợp vào context và gắn citation. Nếu lấy bản cũ, câu trả lời nghe hợp lý vẫn có thể sai.

Hình 1 — RAG nối nguồn, retrieval, context và generation; citation chỉ ra căn cứ của output.

c. Citation không phải bằng chứng tuyệt đối

Citation là dấu chỉ nguồn được dùng cho output. Citation giúp reviewer mở lại tài liệu, nhưng không tự chứng minh retrieval đã chọn đúng đoạn hoặc policy còn hiệu lực. Cần kiểm cả nội dung, version, quyền truy cập và điều kiện áp dụng.

2. Knowledge architecture bắt đầu từ nguồn

a. Owner, version và metadata

Một tài liệu nên có metadata: thông tin mô tả nguồn như owner, version, ngày hiệu lực, phạm vi áp dụng, loại tài liệu và quyền đọc. Không có metadata, retrieval khó phân biệt “bản mới” với “bản được tải lên sau”. Người sở hữu nguồn cũng cần biết ai duyệt thay đổi và ai xử lý khi hai tài liệu mâu thuẫn.

Freshness là mức còn hiệu lực hoặc cập nhật của nguồn. Với policy đổi theo thời gian, ngày hiệu lực quan trọng hơn tên file. Với runbook, một bước cũ có thể làm người dùng thao tác sai dù văn bản được tìm thấy chính xác.

b. Tài liệu được phép dùng

Knowledge base không nên là bãi chứa mọi thứ. Hãy phân loại tài liệu công khai, nội bộ, nhạy cảm và bị cấm gửi tới model. RAG cần đi cùng access control; một đoạn được tìm thấy không có nghĩa người dùng hiện tại được xem đoạn đó.

Hình 2 — Nguồn tốt cần owner, version, freshness và quyền dùng trước khi được retrieval.

c. Nguồn mâu thuẫn

Khi policy-v2026-01 và policy-v2024 khác nhau, hệ thống phải có quy tắc ưu tiên hoặc chuyển NEED_REVIEW. Đừng để model tự chọn theo văn bản nghe thuyết phục hơn. Một architecture có owner và ngày hiệu lực giúp quyết định này có thể kiểm lại.

3. Retrieval chọn đúng phần nào?

a. Chunking và query

Chunking là chia tài liệu thành phần nhỏ để tìm. Chunk quá dài có thể chứa nhiều chủ đề; chunk quá ngắn có thể tách mất điều kiện và ngoại lệ. Query cần giữ entity quan trọng như mã policy, loại sự cố và thời gian. Một câu hỏi “hoàn tiền?” quá rộng sẽ tìm nhiều đoạn khó phân biệt.

Reranking là xếp hạng lại kết quả theo độ phù hợp sau bước tìm ban đầu. Keyword search, vector search hoặc hybrid search đều có thể hữu ích tùy dữ liệu; không có lựa chọn duy nhất đúng cho mọi kho. Microsoft mô tả việc đánh giá RAG cần nhìn vào grounding data và test query, không chỉ câu prompt. Microsoft RAG evaluation

Hình 3 — Query, chunking và reranking cùng ảnh hưởng phần nguồn đi vào context.

b. Ba lỗi retrieval thường gặp

Một là tìm đúng từ nhưng sai tài liệu: “hoàn tiền” xuất hiện trong policy khác sản phẩm. Hai là tìm đoạn đúng nhưng thiếu câu ngoại lệ ở chunk kế bên. Ba là ưu tiên tài liệu mới tải lên nhưng chưa có owner hoặc chưa đến ngày hiệu lực. Mỗi lỗi cần test riêng; tăng top-k không tự giải quyết quyền, freshness hay chunk boundary.

4. Test RAG và điểm dừng

a. Bốn case tối thiểu

Tạo một query bình thường, một query thiếu nguồn, một query có nguồn mâu thuẫn và một đoạn tài liệu chứa chỉ dẫn chen vào. Chấm: retrieval có lấy đoạn cần không, context có đủ điều kiện không, output có citation không và hệ thống có dừng đúng không. Evaluation là dùng test case và rubric để chấm output; không thay thế review nguồn.

b. Fallback khi không đủ căn cứ

Nếu không tìm được nguồn phù hợp, trả NEED_REVIEW hoặc hỏi thêm dữ liệu. Nếu nguồn mâu thuẫn, hiển thị conflict và chuyển owner. Nếu người dùng không có quyền, không tiết lộ đoạn tìm thấy. Đừng để model “điền phần còn thiếu” bằng kiến thức chung khi nhiệm vụ yêu cầu policy nội bộ.

Google Cloud mô tả RAG như một pattern kết hợp model với dữ liệu doanh nghiệp và pipeline truy hồi; architecture cụ thể vẫn cần kiểm quyền, dữ liệu và evaluation theo use case. Google Cloud RAG

5. Practice Bridge 15 phút

a. Cách làm

Dùng Google Sheets hoặc notes cục bộ. Chọn policy giả v2026-01 và đơn A100; không cần API key, không gọi vector database thật. Điền bảy hàng: source, query, retrieved, context, output, citation và fallback. Mục tiêu là tìm một lỗ hổng, không phải xây hệ thống hoàn chỉnh.

Mẫu đối chiếu

Lớp Câu hỏi Mẫu dữ liệu giả Trạng thái Bước tiếp theo
Source Nguồn nào? policy-v2026-01, owner Support Có owner Ghi ngày hiệu lực
Query Người dùng hỏi gì? A100 + lỗi vận chuyển Đủ entity Thêm case thiếu mã
Retrieved Tìm đoạn nào? Điều khoản 7 ngày Chưa kiểm Mở lại chunk kế bên
Context Đưa gì vào run? policy + trạng thái A100 Có mẫu Kiểm quyền
Output Trả gì? answer + citation + status Đã định Viết rubric
Citation Căn cứ nào? policy-v2026-01 §2 Có mẫu Kiểm freshness
Fallback Khi mâu thuẫn? NEED_REVIEW, hỏi owner Đã định Ghi runbook

b. Kết quả mong đợi

Bạn phải chỉ ra ít nhất một ô “Chưa kiểm” và một query xấu. Không dùng dữ liệu thật, tiền thật hoặc quyền trả lời khách hàng. Bảng này là artifact giáo dục để chuẩn bị cho Agent và Tool-use Architecture Review #4.

Hình 4 — Bảng review biến pipeline RAG thành các câu hỏi về nguồn, test và điểm dừng.

6. Tổng kết: RAG cần kiến trúc nguồn và đường lui

a. Năm ý chính

  • RAG tìm nguồn liên quan, đưa vào context rồi mới generation; không phải nút biến kho tài liệu thành sự thật.
  • Knowledge architecture cần owner, version, metadata, freshness và access control.
  • Chunking, query và reranking quyết định phần nào được retrieval; tăng top-k không sửa mọi lỗi.
  • Citation giúp kiểm căn cứ; evaluation phải test cả đúng, thiếu, mâu thuẫn và injection.
  • Thiếu nguồn hoặc quyền thì fallback là dừng/chuyển owner, không tự điền phần còn thiếu.

b. Câu hỏi tự kiểm tra

  • RAG khác generation thuần ở bước nào?
  • Vì sao citation không tự chứng minh câu trả lời đúng?
  • Chunk quá dài hoặc quá ngắn tạo rủi ro gì?
  • Khi nguồn mâu thuẫn, fallback nên làm gì?

c. Gợi ý đáp án

Xem gợi ý câu 1

RAG thêm retrieval và context nguồn trước generation. Xem lại mục 1.

Xem gợi ý câu 2

Citation chỉ chỉ ra nguồn; vẫn phải kiểm nội dung, version và điều kiện áp dụng. Xem lại mục 1.

Xem gợi ý câu 3

Chunk dài trộn nhiều chủ đề; chunk ngắn có thể tách ngoại lệ khỏi điều kiện. Xem lại mục 3.

Xem gợi ý câu 4

Hiển thị conflict và chuyển owner/NEED_REVIEW thay vì tự chọn hoặc bịa. Xem lại mục 4.

d. Thuật ngữ cần nhớ

Thuật ngữ Giải thích ngắn
RAG Retrieval đưa nguồn vào context trước generation.
Knowledge base Tập nguồn được quản lý cho một mục đích.
Retrieval Tìm phần nguồn liên quan.
Metadata Mô tả nguồn như owner, version, date.
Chunking Chia tài liệu thành phần nhỏ để tìm.
Reranking Xếp hạng lại kết quả theo độ phù hợp.
Citation Dấu chỉ nguồn được dùng cho output.
Fallback Đường an toàn khi nguồn/output không đạt.

e. Nguồn tham khảo

Bài trước là Prompt và Context Engineering Review #2. Bài tiếp theo đi vào quyền tool, workflow và human approval.

Lưu ý giáo dục: RAG không thay thế source governance, security review, evaluation hoặc human approval. Giữ prototype ở dữ liệu giả và read-only cho tới khi các gate có bằng chứng.