Sinh tăng cường truy xuất (RAG, Retrieval-Augmented Generation)

1. Tổng quan

A. Định nghĩa

Sinh tăng cường truy xuất (RAG) là kiến trúc trong đó, thay vì chỉ dùng tri thức được lưu trong tham số của mô hình ngôn ngữ lớn (LLM), hệ thống truy xuất các căn cứ liên quan từ tài liệu, cơ sở dữ liệu hoặc chỉ mục tìm kiếm bên ngoài ngay tại thời điểm đặt câu hỏi, rồi đưa chúng vào prompt sinh hoặc vào quá trình sinh.

Bản chất của RAG là sự kết hợp giữa bộ truy xuất (retriever) và bộ sinh (generator). Bộ truy xuất tìm các đoạn tài liệu gần với câu hỏi của người dùng về mặt ngữ nghĩa hoặc từ vựng, tạo ra các ứng viên tri thức bên ngoài. Bộ sinh nhận đồng thời các ứng viên đó và câu hỏi để soạn câu trả lời. Vì vậy, RAG không đơn thuần là kỹ thuật prompt gắn tài liệu dài vào LLM, mà là cách thiết kế việc lưu trữ tri thức, truy xuất, chọn căn cứ, sinh câu trả lời và đánh giá thành một hệ thống thông tin thống nhất.

Lewis et al. đã chính thức hóa RAG như phương pháp kết hợp bộ nhớ tham số của mô hình tiền huấn luyện với bộ nhớ phi tham số của chỉ mục bên ngoài (Lewis et al., 2020). Bài báo gốc kết hợp bộ sinh sequence-to-sequence tiền huấn luyện với dense vector index của Wikipedia để thực hiện hỏi đáp chuyên sâu về tri thức. RAG doanh nghiệp ngày nay đã mở rộng nguồn tri thức sang quy định nội bộ, tài liệu thiết kế, lịch sử tư vấn, bảng biểu, mã nguồn và cơ sở dữ liệu, nhưng cốt lõi “tìm căn cứ bên ngoài cần thiết và kết nối vào quá trình sinh” vẫn không đổi.

RAG không hoàn toàn giải phóng LLM khỏi vấn đề tính cập nhật của dữ liệu huấn luyện. Mô hình vẫn dựa vào tham số để hiểu câu hỏi và tóm tắt kết quả truy xuất, và thông tin không có hoặc bị lập chỉ mục sai trong chỉ mục tìm kiếm sẽ không được phản ánh vào câu trả lời. Do đó, trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer), cần trình bày RAG không phải là giải pháp vạn năng tự động loại bỏ ảo giác (hallucination), mà là một mẫu thiết kế kiểm soát tính cập nhật, nguồn gốc và quyền truy cập của tri thức tại thời điểm chạy (runtime).

B. Bối cảnh ra đời và sự cần thiết

Tri thức tham số của LLM bị cố định tại thời điểm huấn luyện và không tự biết tài liệu nội bộ không công khai của tổ chức hay quy định vừa sửa đổi. Để phản ánh nội dung mới bằng cách huấn luyện lại mô hình, cần làm sạch dữ liệu, chi phí huấn luyện, kiểm chứng an toàn, triển khai và rollback. Ngược lại, RAG có thể thay thế nguồn tri thức tương đối nhanh bằng cách cập nhật pipeline tài liệu và chỉ mục tìm kiếm.

Trong nghiệp vụ doanh nghiệp, căn cứ và khả năng truy vết quan trọng hơn sự trôi chảy của câu trả lời. Nếu tư vấn quy định nhân sự nói sai số ngày nghỉ phép, hoặc hệ thống bảo trì thiết bị làm việc dựa trên sổ tay đã bị hủy bỏ, sẽ phát sinh vấn đề về chi phí và an toàn. RAG có thể cung cấp kèm tiêu đề, phiên bản, ngày hiệu lực, trang hoặc đoạn của tài liệu được truy xuất, qua đó cho người rà soát và người dùng thấy căn cứ của câu trả lời.

Ngoài ra, RAG cho phép tách riêng kho tri thức theo từng nghiệp vụ mà không cần huấn luyện lại một mô hình đa năng bằng toàn bộ dữ liệu tổ chức. Nếu quản lý tài liệu của khách hàng A và khách hàng B bằng các chỉ mục tenant khác nhau và chỉ truy xuất tài liệu phù hợp với quyền của người dùng, có thể nâng cao mức cô lập dữ liệu và tính linh hoạt vận hành. Tuy nhiên, nếu chỉ lọc sau khi truy xuất thì văn bản đã bị lộ có thể lọt vào prompt, nên điều kiện phân quyền phải được áp dụng ngay từ bước truy xuất.

C. Mục tiêu và phạm vi áp dụng

Mục tiêu khi triển khai RAG có thể tóm tắt như sau.

Phản ánh tri thức mới nhất, đặc thù của tổ chức theo chu kỳ ngắn hơn so với huấn luyện lại mô hình.
Liên kết câu trả lời với tài liệu căn cứ để nâng cao khả năng kiểm chứng và khả năng kiểm toán.
Thực thi quyền truy cập, thời hạn lưu giữ và ranh giới tenant của nguồn tài liệu tại thời điểm truy vấn.
Đo lường tách biệt chất lượng truy xuất và chất lượng sinh để có thể cải tiến theo từng nguyên nhân.
Khi mô hình nhận biết thiếu căn cứ, cho phép nó chọn tạm hoãn, hỏi thêm hoặc chuyển cho chuyên gia thay vì phỏng đoán.

RAG phù hợp với các nghiệp vụ trong đó việc khai thác tri thức bên ngoài là quan trọng như hỏi đáp quy định, hỗ trợ kỹ thuật, tìm kiếm nội bộ, quản lý tri thức, hỗ trợ rà soát thiết kế và tư vấn khách hàng. Ngược lại, những nghiệp vụ không thể bảo đảm an toàn chỉ bằng truy xuất như tính toán số liệu chính xác, thay đổi giao dịch phức tạp, phán đoán giá thời gian thực thì phải được thiết kế cùng với gọi công cụ, dịch vụ kiểm chứng và sự phê duyệt của con người.

2. Kiến trúc tham chiếu và nguyên lý hoạt động

A. Cấu trúc tổng thể

flowchart LR
  U[Người dùng·Hệ thống nghiệp vụ] --> Q[Phân tích·Chuẩn hóa truy vấn]
  Q --> F[Bộ lọc tenant·Quyền·Chính sách]
  F --> R[Bộ truy xuất lai]
  R --> RR[Xếp hạng lại·Chọn căn cứ]
  RR --> C[Bộ dựng ngữ cảnh]
  C --> G[Bộ sinh LLM]
  G --> V[Kiểm chứng trích dẫn·Tính xác thực·Chính sách]
  V --> A[Câu trả lời·Căn cứ·Tạm hoãn]
  D[Tài liệu·DB·API·Sự kiện] --> I[Thu thập·Làm sạch·Chia đoạn]
  I --> E[Embedding·Siêu dữ liệu]
  E --> X[(Chỉ mục vector·Từ khóa)]
  X --> R
  A --> O[Quan sát chất lượng·Bảo mật·Chi phí]

Luồng trực tuyến phân tích câu hỏi, áp dụng điều kiện quyền và tenant, truy xuất các tài liệu ứng viên, xếp hạng lại rồi chuyển cho LLM. Sau khi sinh, hệ thống kiểm chứng sự tồn tại của trích dẫn, mối liên kết giữa căn cứ và khẳng định, việc lộ từ cấm và thông tin cá nhân, cũng như việc tuân thủ định dạng trả lời. Nếu kiểm chứng thất bại, câu trả lời không được cho qua nguyên trạng mà được rẽ nhánh sang sinh lại, tạm hoãn hoặc chuyển cho con người.

Luồng ngoại tuyến đảm nhiệm việc thu thập và lập chỉ mục tài liệu nguồn. Khi tài liệu được thêm, sửa hoặc xóa, bộ phân tích cú pháp (parser) trích xuất nội dung và cấu trúc, chia thành các đơn vị ngữ nghĩa rồi tạo embedding và siêu dữ liệu. Phải liên kết phiên bản văn bản gốc với phiên bản chỉ mục thì mới có thể tái hiện “câu trả lời hiện tại dựa trên tài liệu tại thời điểm nào”.

Chỉ mục tìm kiếm không nhất thiết là một kho lưu trữ duy nhất. Tìm kiếm từ khóa mạnh với các thuật ngữ chính xác như tên sản phẩm, số điều khoản, mã lỗi, còn tìm kiếm vector mạnh trong việc tìm các tài liệu tương tự về ngữ nghĩa nhưng diễn đạt khác. Trong thực tế, cấu trúc lai hợp nhất hai kết quả rồi xếp hạng lại thường được sử dụng, và tùy quy mô dữ liệu cũng như đặc thù lĩnh vực mà kết hợp DB quan hệ, công cụ tìm kiếm, vector DB và graph DB.

B. Trình tự xử lý truy vấn

sequenceDiagram
  participant U as Người dùng
  participant API as RAG API
  participant P as Dịch vụ chính sách·Quyền
  participant S as Dịch vụ truy xuất
  participant RR as Bộ xếp hạng lại
  participant L as LLM
  participant V as Bộ kiểm chứng
  U->>API: Câu hỏi·Phiên·Tenant
  API->>P: Xác nhận tài liệu·Trường·Công cụ được phép
  P-->>API: Bộ lọc truy xuất·Chính sách
  API->>S: Truy vấn chuẩn hóa + Bộ lọc quyền
  S-->>API: Ứng viên từ khóa·Vector
  API->>RR: Hợp nhất·Chấm điểm ứng viên
  RR-->>API: Chunk căn cứ và nguồn
  API->>L: Câu hỏi + Chỉ dẫn + Căn cứ
  L-->>API: Câu trả lời nháp·Trích dẫn
  API->>V: Kiểm chứng khẳng định·Trích dẫn·An toàn
  V-->>API: Thông qua·Sinh lại·Tạm hoãn
  API-->>U: Câu trả lời·Nguồn·Độ bất định

Bước đầu tiên là chuẩn hóa truy vấn, bao gồm sửa lỗi chính tả, mở rộng từ viết tắt, kết hợp ngữ cảnh hội thoại và làm rõ ngày tháng cũng như phạm vi tổ chức. Ví dụ, “Cho tôi biết quy định nghỉ phép” không có quốc gia áp dụng, hình thức tuyển dụng và ngày chuẩn, nên thay vì truy xuất ngay cần hỏi thêm hoặc nêu rõ phạm vi mặc định. Nếu tùy tiện mở rộng truy vấn, có thể truy xuất tài liệu khác với ý định ban đầu, nên cần lưu lại cả truy vấn gốc lẫn truy vấn đã biến đổi ở dạng có thể kiểm toán.

Dịch vụ chính sách trả về phạm vi có thể truy xuất theo người dùng, vai trò, phòng ban, tenant, phân loại tài liệu và thời hạn hiệu lực. Bộ lọc này được áp đặt vào điều kiện của API truy xuất hoặc phân vùng chỉ mục, không chỉ dựa vào câu lệnh if tùy chọn trong mã ứng dụng. Để khi quyền thay đổi, bộ đệm embedding và bộ đệm câu trả lời không tái sử dụng kết quả của người dùng trước, cần phản ánh phiên bản quyền hoặc phiên bản chính sách vào khóa bộ đệm.

Sau khi truy xuất ứng viên, cần dọn dẹp các tài liệu trùng lặp, phiên bản cũ và tài liệu mâu thuẫn. Nếu các kết quả hàng đầu đều là các chunk lặp lại của cùng một tài liệu, góc nhìn của câu trả lời có thể bị thu hẹp, còn nếu các bản sửa đổi khác nhau cùng xuất hiện, mô hình có thể nhầm lẫn giữa tính mới nhất và việc bãi bỏ. Ở bước xếp hạng lại, ngoài mức độ liên quan còn xem xét đồng thời ngày hiệu lực, độ tin cậy của nguồn, quyền đối với tài liệu, mức trùng lặp và các điều kiện chi tiết trong câu hỏi của người dùng.

C. Liên kết giữa sinh và kiểm chứng

Bộ dựng ngữ cảnh phân tách rõ ràng câu hỏi, chỉ dẫn hệ thống, căn cứ truy xuất, định dạng trả lời và các hành vi bị cấm. Ngay cả khi trong tài liệu truy xuất có câu như “hãy bỏ qua các chỉ dẫn trước đó”, đó vẫn là dữ liệu chứ không phải chỉ dẫn hệ thống. Cần áp dụng ký hiệu phân tách và chính sách prompt để không nâng nội dung tài liệu lên thành mệnh lệnh đáng tin cậy.

Bộ sinh không được suy đoán các sự thật nằm ngoài căn cứ. Có thể đưa vào mẫu câu trả lời các quy tắc như “nếu không có trong tài liệu căn cứ thì trả lời là không thể xác nhận”, “ghi nguồn cho từng khẳng định”, “không che giấu mâu thuẫn giữa các tài liệu”. Tuy nhiên, chỉ prompt thì không thể bảo đảm điều đó, nên cần bộ kiểm chứng riêng và bộ dữ liệu kiểm thử.

Bộ kiểm chứng phân rã câu trả lời theo đơn vị câu hoặc khẳng định và kiểm tra xem mỗi khẳng định có căn cứ cần thiết hay không. Ngay cả khi có gắn trích dẫn, tài liệu được trích dẫn có thể không thực sự hỗ trợ khẳng định, nên phải phân biệt sự tồn tại của trích dẫn với tính entailment (hàm ý suy ra) của trích dẫn. Với nghiệp vụ quan trọng, không chỉ dùng phán định dựa trên mô hình mà kết hợp cả quy tắc, liên kết văn bản gốc, so sánh trường có cấu trúc và API kiểm chứng chuyên ngành.

3. Chuẩn bị dữ liệu và thiết kế truy xuất

A. Thu thập, làm sạch và dòng dõi tài liệu

Chất lượng RAG phụ thuộc vào chất lượng dữ liệu nguồn nhiều hơn là vào LLM. Nếu đầu trang, chân trang của PDF bị lặp lại trong nội dung hoặc thứ tự cột của bảng bị xáo trộn, embedding sẽ khó biểu diễn tốt ý nghĩa của tài liệu. Với tài liệu cần OCR, phải kiểm tra tỷ lệ nhận dạng, việc bảo toàn bảng và chú thích, việc thiếu trang quét, và không đánh dấu tài liệu phân tích thất bại là đã lập chỉ mục xong.

Pipeline thu thập lưu các siêu dữ liệu như URI gốc, chủ sở hữu, loại tài liệu, ngôn ngữ, ngày tạo, ngày sửa đổi, ngày bắt đầu/kết thúc hiệu lực, cấp độ bảo mật, trạng thái xóa, hash và phiên bản parser. Thông tin này không chỉ dùng cho bộ lọc truy xuất mà còn cho nguồn của câu trả lời và phân tích hồi quy. Cần định kỳ phát hiện các chunk mồ côi vẫn còn trong chỉ mục vector dù tài liệu đã bị xóa.

Dòng dõi tài liệu (lineage) là chuỗi liên kết từ bản gốc đến văn bản đã phân tích, chunk, embedding, kết quả truy xuất và câu trả lời. Khi cùng một tài liệu được thu thập lại, có thể dùng hash để phát hiện thay đổi và chỉ embedding lại các chunk có nội dung thay đổi nhằm giảm chi phí. Khi thay đổi parser hoặc mô hình embedding, cần tách phiên bản chỉ mục, so sánh kết quả của phiên bản cũ và mới rồi mới chuyển đổi.

B. Chia đoạn (chunking) và siêu dữ liệu

Chunking không phải là vấn đề cắt tài liệu theo độ dài cố định mà là vấn đề thiết kế đơn vị truy xuất. Chunk quá nhỏ sẽ mất ngữ cảnh và điều kiện, chunk quá lớn khiến kết quả truy xuất chứa nhiều nội dung không cần thiết và làm phân tán sự chú ý của bộ sinh. Cần thử nghiệm độ dài token mục tiêu và độ chồng lấn (overlap) trong khi vẫn bảo toàn tiêu đề, điều khoản, quan hệ giữa các hàng của bảng, khối mã và ranh giới đoạn văn.

Với tài liệu quy định, gắn cấu trúc phân cấp chương-mục-điều-khoản vào từng chunk; với tài liệu quy trình, gom điều kiện tiên quyết và điều kiện ngoại lệ vào cùng một chunk hoặc các chunk được liên kết. Nếu chỉ tách riêng từng hàng của bảng thì ý nghĩa của tiêu đề cột sẽ mất, nên cần lặp lại tiêu đề bảng, đơn vị và tên cột để bảo toàn dưới dạng văn bản có cấu trúc. Lưu trang và vị trí trong tài liệu nguồn giúp hiển thị trích dẫn chính xác cho người dùng.

Siêu dữ liệu quyết định chất lượng và tính bảo mật của kết quả truy xuất. Cần thiết kế các trường như tenant_id, acl, document_type, effective_from, effective_to, language, source_system, version, page, và quản lý các giá trị có thể lọc bằng mã chuẩn. Nếu chỉ lưu siêu dữ liệu dưới dạng văn bản tự do, tên phòng ban có thể được ghi khác nhau dẫn đến bỏ sót bộ lọc quyền và bộ lọc thời gian.

C. Embedding và lập chỉ mục

Embedding chuyển văn bản thành vector trong không gian ngữ nghĩa. Hệ thống so sánh độ tương đồng cosine hoặc tích vô hướng giữa vector câu hỏi và vector tài liệu để tìm ứng viên, nhưng độ tương đồng không đồng nghĩa với tính đúng đắn. Những biểu thức cần khớp ký tự như mã sản phẩm và số điều khoản có thể bị bỏ sót nếu chỉ dùng tìm kiếm vector, nên cần kết hợp với tìm kiếm từ khóa như BM25.

Khi thay đổi mô hình embedding, ý nghĩa của không gian vector thay đổi nên không so sánh trực tiếp với các vector cũ. Cần chọn mô hình phù hợp với ngôn ngữ, thuật ngữ chuyên ngành, độ dài tài liệu và loại truy vấn, rồi so sánh hiệu năng truy xuất bằng bộ dữ liệu câu hỏi đại diện - tài liệu đáp án. Khi gửi thông tin cá nhân hoặc văn bản gốc mật tới API embedding, cần xem xét vị trí xử lý, chính sách lưu giữ, mã hóa và điều khoản hợp đồng.

Chỉ mục cần tính đến tính nhất quán giữa ghi và đọc. Phải quyết định có cam kết với người dùng rằng tài liệu mới được đăng ký tại nguồn sẽ có thể truy xuất ngay hay chỉ công khai sau khi hoàn tất embedding và kiểm duyệt. Nếu lập chỉ mục tăng dần bị lỗi, có thể xảy ra tình trạng chỉ một phần chunk bị lộ ra, nên cần nạp vào chỉ mục tạm rồi chuyển alias một cách nguyên tử, hoặc thực thi trạng thái theo đơn vị tài liệu bằng bộ lọc.

D. Truy xuất và xếp hạng lại

Truy xuất bậc 1 thu thập ứng viên trên diện rộng, còn xếp hạng lại bậc 2 đánh giá mức liên quan chi tiết giữa câu hỏi và ứng viên. Nếu ở bậc 1 chỉ lấy 5 kết quả hàng đầu thì căn cứ cần thiết có thể bị bỏ sót, còn nếu đưa nguyên 100 kết quả vào LLM thì chi phí và nhiễu sẽ tăng. Số ứng viên và số ngữ cảnh cuối cùng được thử nghiệm theo từng loại câu hỏi, đồng thời ghi lại điểm truy xuất, điểm xếp hạng lại và lý do lựa chọn.

Nếu truy vấn là “Ngoại lệ của quy định bảo mật thông tin sửa đổi năm 2025 là gì?”, cần phản ánh không chỉ độ tương đồng ngữ nghĩa mà cả các tín hiệu cấu trúc như năm, loại tài liệu và từ “ngoại lệ”. Áp dụng bộ lọc thời gian và phiên bản trước rồi mới truy xuất thì mới giảm được việc quy định đã bãi bỏ xuất hiện ở vị trí cao. Nếu truy xuất được các tài liệu mâu thuẫn nhau, thay vì tùy tiện ẩn tài liệu mới nhất, cần hiển thị sự mâu thuẫn và đưa ngày chuẩn cùng trạng thái sửa đổi vào câu trả lời.

Truy xuất thất bại cũng được xem là một kết quả bình thường. Nếu không có tài liệu liên quan mà vẫn dùng tài liệu gần nhất để trả lời, kết quả sẽ là một câu trả lời sai nhưng nghe có vẻ hợp lý. Cần tổng hợp độ tương đồng tối thiểu, điểm xếp hạng lại, độ tin cậy của nguồn và việc đáp ứng siêu dữ liệu bắt buộc để tạo trạng thái “thiếu căn cứ”, rồi hướng dẫn người dùng thu hẹp phạm vi và hỏi lại.

4. Các loại RAG và so sánh

A. RAG cơ bản, RAG nâng cao và RAG dạng agent

RAG cơ bản là luồng tuyến tính câu hỏi - truy xuất - sinh. Cấu trúc đơn giản, dễ dự đoán độ trễ và chi phí nên phù hợp với giai đoạn thí điểm ban đầu. Tuy nhiên, khó xử lý câu hỏi phức hợp bằng một truy vấn duy nhất và không thể tự sửa các kết quả truy xuất sai.

RAG nâng cao bổ sung việc viết lại truy vấn, tìm kiếm lai, xếp hạng lại, nén tài liệu, quản lý ngữ cảnh hội thoại và kiểm chứng câu trả lời. Có thể cải thiện chất lượng truy xuất, nhưng càng nhiều thành phần thì độ trễ, điểm lỗi và số tổ hợp cần đánh giá càng tăng. Trước khi thêm chức năng, cần xác lập đường cơ sở (baseline) về việc giảm được loại lỗi nào.

RAG dạng agent để mô hình gọi công cụ truy xuất nhiều lần, đánh giá kết quả truy xuất và phân rã truy vấn khi cần. Có lợi cho các cuộc điều tra phức hợp nhưng có thể phát sinh bùng nổ gọi công cụ, vòng lặp vô hạn, mở rộng phạm vi quyền và thất bại trong dự đoán chi phí. Cần nêu rõ danh sách công cụ và kiểm tra tham số, ngân sách số lần gọi và thời gian, cùng ranh giới phê duyệt.

Phân loại	RAG cơ bản	RAG nâng cao	RAG dạng agent
Luồng	Sinh sau 1 lần truy xuất	Tiền xử lý·Xếp hạng lại·Kiểm chứng	Lập kế hoạch·Truy xuất lặp·Gọi công cụ
Ưu điểm	Đơn giản·Chi phí vận hành thấp	Cải thiện chất lượng·Khả năng kiểm soát	Xử lý câu hỏi phức hợp
Rủi ro	Dễ tổn thương khi truy xuất thất bại	Độ trễ·Độ phức tạp cấu hình	Bùng nổ chi phí·Quyền·Vòng lặp
Nghiệp vụ phù hợp	FAQ·Tìm kiếm nội bộ	Quy định·Hỗ trợ kỹ thuật	Điều tra·Phân tích nhiều bước

B. RAG so với fine-tuning, prompt và ngữ cảnh dài

Fine-tuning hiệu quả trong việc dạy mô hình phong cách hành vi hoặc cách diễn đạt chuyên ngành. Nhưng rất khó quản lý nếu dùng để lưu trữ sự thật từ tài liệu mới nhất và cung cấp nguồn theo thời gian thực. RAG đặt tri thức trong chỉ mục và cập nhật nó, trong khi fine-tuning phản ánh mẫu hình và tri thức vào trọng số mô hình, nên hai phương pháp có thể là quan hệ kết hợp hơn là thay thế.

Kỹ thuật prompt (prompt engineering) là cách truyền đạt cho mô hình vai trò, định dạng đầu ra, ví dụ và ràng buộc. Đưa tài liệu căn cứ vào prompt cũng là một bước của RAG, nhưng cách con người mỗi lần tự dán tài liệu mà không có thu thập, phân quyền, truy xuất và dòng dõi tài liệu thì không phải là RAG vận hành. Dù cửa sổ ngữ cảnh dài có lớn lên, đầu vào càng dài thì chi phí và độ trễ càng tăng, và mô hình có thể bỏ sót tài liệu ở giữa hoặc trộn lẫn thông tin mâu thuẫn.

Tiêu chí lựa chọn theo nghiệp vụ là tốc độ thay đổi của tri thức, kiểm soát truy cập tài liệu, nhu cầu về căn cứ cho câu trả lời, số lượng và chất lượng dữ liệu huấn luyện, và chi phí suy luận. Quy định nội bộ thay đổi thường xuyên thì lợi ích của RAG lớn, còn nếu vấn đề là định dạng đầu ra và giọng văn luôn phải giống nhau thì fine-tuning hoặc prompt có thể phù hợp hơn. Khi mô hình không hiểu tốt thuật ngữ chuyên ngành, cần kết hợp embedding chuyên ngành, viết lại truy vấn và một lượng nhỏ học có giám sát với RAG.

Hạng mục đánh giá	RAG	Fine-tuning	Ngữ cảnh dài
Cập nhật tri thức mới	Cập nhật chỉ mục	Cần huấn luyện lại	Cần nhập mỗi lần
Cung cấp nguồn	Dễ cấu trúc hóa	Cần thiết kế riêng	Phụ thuộc tài liệu đầu vào
Quyền truy cập dữ liệu	Lọc khi truy xuất	Cần kiểm soát bên ngoài mô hình	Cần cấu hình prompt
Học hành vi·Văn phong	Hạn chế	Điểm mạnh	Có thể qua ví dụ
Gánh nặng vận hành	Pipeline·Chỉ mục	Huấn luyện·Triển khai	Chi phí token·Độ trễ

5. Tình huống áp dụng và quy trình vận hành

A. Tình huống hỏi đáp quy định nội bộ

Giả định một doanh nghiệp có quy định nhân sự, nội quy lao động, thỏa ước tập thể và các quy định phụ theo khu vực. Khi người dùng hỏi “Tiêu chí chi trả thưởng hiệu suất trong thời gian nghỉ nuôi con là gì?”, hệ thống phải xác nhận quốc gia, pháp nhân, hình thức tuyển dụng và ngày chuẩn của người dùng, rồi truy xuất phiên bản mới nhất của quy định được phép. Nếu trộn lẫn kiến thức pháp luật chung hoặc quy định của pháp nhân khác, câu trả lời dù trôi chảy cũng không có giá trị trong nghiệp vụ.

Mỗi chunk tài liệu được gắn tên quy định, số điều khoản, ngày thi hành, ngày bãi bỏ, pháp nhân áp dụng và cấp độ bảo mật. Nếu kết quả truy xuất trả về đồng thời quy định năm 2024 và quy định sửa đổi năm 2026, hệ thống so sánh ngày sửa đổi và thời hạn hiệu lực, và nếu mâu thuẫn thì yêu cầu người phụ trách nhân sự xác nhận. Câu trả lời không chỉ gồm kết luận mà còn có điều kiện áp dụng, điều khoản liên quan, ngày chuẩn, ngoại lệ và kênh liên hệ.

Không đánh giá thành công chỉ bằng tỷ lệ trả lời đúng. Cần kiểm chứng cả việc tài liệu của pháp nhân mà người dùng không có quyền không bị truy xuất, câu trả lời trích dẫn chính xác điều khoản nguồn, hệ thống tạm hoãn khi không chắc chắn, và tài liệu mới được truy xuất ngay sau khi sửa đổi. Nhật ký tư vấn nhân sự lưu câu hỏi và câu trả lời nhưng phải che (masking) để số định danh cá nhân hoặc thông tin nhân sự nhạy cảm không bị lưu trữ một cách không cần thiết.

B. Tình huống hỗ trợ kỹ thuật sản xuất

Tại hiện trường sản xuất, biện pháp xử lý khác nhau tùy theo model thiết bị, phiên bản firmware, mã cảnh báo và công đoạn. Trả về sổ tay chung cho câu hỏi “xử lý cảnh báo E-204” có thể nguy hiểm. Hệ thống phải xác nhận định danh thiết bị và phiên bản hiện tại, rồi truy xuất biện pháp cho điều kiện tương ứng từ sổ tay bảo trì và quy trình làm việc an toàn đã được phê duyệt.

Tài liệu quy trình làm việc được lập chỉ mục tách biệt các bước, việc ngắt nguồn trước, dụng cụ cần thiết, cảnh báo nguy hiểm và điều kiện trở lại bình thường. Nếu chunk được truy xuất không có cảnh báo an toàn, bộ sinh không tự ý bổ sung quy trình mà yêu cầu sự phê duyệt của kỹ thuật viên bảo trì chuyên môn. Việc sinh câu trả lời được tách khỏi việc điều khiển thiết bị thực tế, và lệnh điều khiển phải qua phê duyệt riêng, khóa liên động (interlock) và xác nhận kép.

Khi mạng tại hiện trường không ổn định, có thể dùng sổ tay được lưu trong bộ đệm, nhưng phải hiển thị bộ đệm đó có phải là tài liệu an toàn mới nhất hay không. Nếu phiên bản tài liệu của câu trả lời ngoại tuyến và trực tuyến khác nhau, cần ghi rõ thời điểm chuẩn và trạng thái đồng bộ để người dùng không nhầm lẫn. Tình huống này cho thấy RAG vượt ra ngoài một tiện ích tìm kiếm và gắn liền với an toàn, quản lý thay đổi và trách nhiệm.

C. Quy trình triển khai

Xác định phạm vi nghiệp vụ và cấp độ rủi ro: Tách nghiệp vụ chỉ cung cấp câu trả lời khỏi nghiệp vụ dẫn tới ra quyết định hoặc điều khiển thực tế.
Lập danh mục nguồn tài liệu: Khảo sát chủ sở hữu, tính cập nhật, cấp độ bảo mật, chu kỳ cập nhật, định dạng tài liệu và thủ tục hủy bỏ.
Xây dựng bộ câu hỏi đại diện: Tạo gold set gồm tài liệu đáp án, điều kiện bắt buộc, tài liệu bị cấm và các câu hỏi dự kiến phải tạm hoãn.
Thiết lập tiêu chí phân tích·chia đoạn: Bảo toàn cấu trúc bảng, mã, điều khoản, trang và đặt quy tắc xử lý lại cho tài liệu thất bại.
Kết nối mô hình phân quyền: Áp đặt ACL chỉ mục, bộ lọc tenant, thời hạn hiệu lực tài liệu và lan truyền xóa vào đường truy xuất.
Đo đường cơ sở truy xuất: So sánh recall@k, MRR, nDCG của phương thức từ khóa, vector và lai.
Thiết kế hợp đồng sinh·trích dẫn: Định nghĩa định dạng câu trả lời, trường nguồn, cách biểu đạt độ bất định, vùng cấm và điều kiện tạm hoãn.
Kiểm thử an toàn·bảo mật: Kiểm thử prompt injection trong tài liệu, vượt quyền, thu hồi thông tin cá nhân, tài liệu mâu thuẫn và truy vấn tài liệu đã xóa.
Vận hành bóng (shadow) và công khai hạn chế: So sánh truy xuất và câu trả lời mà không ảnh hưởng đến người dùng thực, công khai từng bước bắt đầu từ nghiệp vụ rủi ro thấp.
Tự động hóa vận hành: Quản lý độ tươi của chỉ mục, lỗi, chi phí, độ trễ, phản hồi và lan truyền xóa tài liệu bằng dashboard và cảnh báo.

6. Chuyên sâu — Đánh giá, cập nhật và RAG bảo mật

A. Đánh giá tách biệt truy xuất và sinh

Trong đánh giá RAG, nếu chỉ nhìn vào một chỉ số “câu trả lời đúng” thì không thể biết nguyên nhân. Cần xem xét tách biệt: truy xuất có lấy được tài liệu cần thiết không (retrieval recall), có đặt nó ở thứ hạng cao không (MRR·nDCG), ngữ cảnh được chọn có đủ cho câu hỏi không (context precision·recall), câu trả lời cuối cùng có trung thành với căn cứ không (faithfulness), và có trả lời đúng câu hỏi không (answer relevance).

Ví dụ, nếu tài liệu đáp án có trong chỉ mục nhưng không nằm trong top 10 thì đó là vấn đề truy xuất. Nếu tài liệu đáp án có trong ngữ cảnh nhưng câu trả lời nói nội dung khác thì đó là vấn đề sinh, prompt hoặc kiểm chứng. Nếu bản thân tài liệu đáp án sai hoặc đã cũ thì đó là vấn đề quản lý tri thức. Phải liên kết chỉ số theo từng tầng với các mẫu lỗi thì hoạt động cải tiến mới hướng đúng vào thành phần cần sửa.

Bộ đánh giá tự động hữu ích cho kiểm thử hồi quy quy mô lớn nhưng không phải là trọng tài tuyệt đối. Cần xem xét thiên lệch ngôn ngữ và lĩnh vực của mô hình đánh giá, lỗi chỉ nhìn vào trích dẫn mà bỏ qua việc nội dung có được hỗ trợ hay không, và tính chưa đầy đủ của câu trả lời chuẩn. Với nghiệp vụ rủi ro cao, chuyên gia lĩnh vực rà soát mẫu, và sự không nhất quán giữa chỉ số tự động và đánh giá của con người cũng được quản lý như một chỉ số riêng.

B. Cập nhật và tri thức mâu thuẫn

Khi tài liệu thay đổi, chỉ lập chỉ mục phiên bản mới là chưa đủ. Phải phản ánh trạng thái bãi bỏ để phiên bản cũ không bị truy xuất, vô hiệu hóa bộ đệm và các câu trả lời đã tính trước, và bảo đảm ngữ cảnh của các cuộc hội thoại đang diễn ra không làm nhiễm bẩn chính sách mới. Nếu ngày hiệu lực của tài liệu nằm ở tương lai thì cần công khai theo lịch, đồng thời xem xét cả múi giờ của thời điểm áp dụng và đồng bộ đồng hồ.

Khi các tài liệu chính thức khác nhau mâu thuẫn, không giao cho mô hình tự chọn một. Cần so sánh chủ sở hữu tài liệu, ngày sửa đổi, phạm vi áp dụng, quy định cấp trên và trạng thái phê duyệt, rồi chọn theo quy tắc ưu tiên hoặc hiển thị sự mâu thuẫn cho người dùng. Câu trả lời phải được phép ở dạng như “Tài liệu A quy định X, tài liệu B quy định Y, do đó cần xác nhận ngày chuẩn”.

C. Bảo mật, thông tin cá nhân và prompt injection

Tài liệu truy xuất là dữ liệu chứ không phải chỉ dẫn đáng tin cậy. Trong trang web bên ngoài, email hay tài liệu người dùng tải lên có thể chứa câu chỉ thị LLM xuất bí mật hoặc gọi công cụ. Cần tách ranh giới giữa chỉ dẫn hệ thống và dữ liệu, và kiểm soát việc gọi công cụ bằng danh sách cho phép, lược đồ tham số, đặc quyền tối thiểu và luồng phê duyệt.

Bộ lọc ACL ở bước truy xuất và bộ lọc đầu ra ở bước sinh không thể thay thế cho nhau. Ngay từ đầu không được truy xuất tài liệu không có quyền, đồng thời phải kiểm tra xem mô hình có suy luận và tái cấu trúc nội dung của tài liệu khác hay không. Bộ đệm câu trả lời sử dụng khóa bao gồm người dùng, tenant, quyền và phiên bản tài liệu, còn việc lưu giữ, mã hóa và quyền truy cập của nhật ký truy xuất và kho embedding phải phù hợp với phân loại dữ liệu.

Hồ sơ quản lý rủi ro AI tạo sinh của NIST là khung tham chiếu xử lý các rủi ro như nguồn gốc, kiểm chứng và dòng dõi dữ liệu của AI tạo sinh (NIST AI 600-1). Khi triển khai RAG, nếu lập tài liệu về dữ liệu nguồn, đường truy xuất, kết quả sinh và trách nhiệm rà soát của con người theo các góc nhìn Govern·Map·Measure·Manage của khung này, có thể liên kết việc hiện thực kỹ thuật với quản trị.

7. Các điểm cần cân nhắc và hàm ý

A. Đánh đổi giữa tính chính xác, tính cập nhật và tính đầy đủ

Đưa vào nhiều tài liệu liên quan không phải lúc nào cũng làm câu trả lời chính xác hơn. Ngữ cảnh càng dài thì nhiễu càng tăng, các phiên bản mâu thuẫn bị trộn lẫn, chi phí và độ trễ tăng lên. Ngược lại, nếu chọn quá ít tài liệu thì các điều kiện ngoại lệ và định nghĩa bị thiếu. Cần thử nghiệm tập căn cứ tối thiểu cần thiết và ngữ cảnh tối đa theo từng loại câu hỏi, rồi đánh giá kết quả cùng với tác động tới người dùng.

Tính cập nhật được quyết định bởi khoảng chênh thời gian giữa chu kỳ thu thập và phê duyệt công khai. Thu thập tự động nhanh nhưng có thể công khai ngay tài liệu độc hại hoặc sai, còn kiểm duyệt thủ công nâng cao độ tin cậy nhưng chậm hơn. Cần có chính sách theo cấp độ, chẳng hạn quy định và tài liệu an toàn rủi ro cao chỉ cho phép truy xuất phiên bản đã phê duyệt, còn tri thức thông thường thì lập chỉ mục tự động rồi kiểm duyệt theo mẫu.

B. Hiệu năng, chi phí và tính sẵn sàng

Độ trễ của RAG trực tuyến là tổng của embedding truy vấn, truy xuất bậc 1, xếp hạng lại, sinh bằng LLM và kiểm chứng. Nếu vô điều kiện gọi xếp hạng lại và kiểm chứng nhiều lần, chất lượng có thể được cải thiện phần nào nhưng trải nghiệm người dùng và chi phí có thể xấu đi. Cần chia thành luồng nhẹ và luồng chuyên sâu theo mức rủi ro và độ phức tạp của câu hỏi, và truyền deadline tổng thể xuống từng bước.

Không chỉ nhìn vào chi phí tìm kiếm vector và embedding mà phải tính TCO bao gồm chi phí phân tích tài liệu, lưu trữ, lập chỉ mục lại, token đầu vào và đầu ra của LLM, bộ đệm và khả năng quan sát (observability). Thay vì mỗi lần đưa vào toàn bộ tài liệu dài, cần áp dụng nén chunk và loại bỏ trùng lặp, và chỉ lưu đệm an toàn các truy vấn công khai thường gặp khi phiên bản căn cứ không thay đổi.

Nếu khi chỉ mục tìm kiếm gặp sự cố mà dịch vụ vẫn vô điều kiện sinh câu trả lời không có căn cứ thì rất nguy hiểm. Cần hiển thị rõ trạng thái không thể truy xuất và chuyển sang FAQ tĩnh đã được phê duyệt hoặc kênh chuyên gia. Cô lập riêng sự cố mô hình, sự cố embedding và sự cố hệ thống nguồn, đồng thời diễn tập quy trình khôi phục chỉ mục, lập chỉ mục lại và rollback phiên bản.

C. Bảo mật, thông tin cá nhân và trách nhiệm giải trình

RAG không học tài liệu vào trọng số mô hình, nhưng không vì thế mà rủi ro thông tin cá nhân biến mất. Kết quả truy xuất, prompt, nhật ký, dữ liệu đánh giá và bộ đệm đều có thể sao chép thông tin cá nhân. Cần xác định mục đích thu thập và thời hạn lưu giữ, đồng thời áp dụng thu thập tối thiểu, phi định danh hóa, kiểm soát truy cập, mã hóa và lan truyền xóa phù hợp với vòng đời dữ liệu.

Khi câu trả lời ảnh hưởng đến ra quyết định, cần làm rõ chủ thể chịu trách nhiệm cuối cùng và điểm rà soát của con người. Chỉ ghi dòng chữ “AI chỉ mang tính tham khảo” là không đủ, mà phải đưa vào quy trình vận hành việc ngừng cung cấp tự động trong điều kiện nào và người phụ trách vai trò nào sẽ phê duyệt. Phản hồi của người dùng và kết quả khiếu nại không chỉ phục vụ cải tiến mô hình mà còn là tư liệu kiểm toán để tìm ra khiếm khuyết của nguồn tài liệu và chính sách.

D. Khả năng quan sát, quản lý thay đổi và quản trị đánh giá

Các chỉ số vận hành bắt buộc gồm độ trễ câu trả lời, truy xuất thất bại, độ tươi của chỉ mục, tỷ lệ trúng top-k, thiếu trích dẫn, căn cứ không trung thành, tỷ lệ tạm hoãn, tỷ lệ hỏi lại của người dùng, chi phí token và lỗi phân quyền. Không chỉ lưu giá trị trung bình mà cần phân rã theo loại tài liệu, tenant, loại câu hỏi và phiên bản mô hình. Tuy nhiên, phải duy trì quyền truy cập phù hợp với mức độ nhạy cảm của câu hỏi và câu trả lời gốc.

Khi thay đổi mô hình embedding, quy tắc chia đoạn, mô hình xếp hạng lại, prompt, LLM hay bộ lọc chính sách, tất cả đều là đối tượng phát hành (release) ảnh hưởng đến kết quả RAG. Chỉ chuyển đổi từng bước sau khi đã qua hồi quy gold set, kiểm thử bảo mật, kiểm thử tải về chi phí và độ trễ, và so sánh phiên bản chỉ mục. Không chỉ lưu câu trả lời mà phải lưu lại phiên bản tài liệu đã sử dụng, điểm truy xuất, phiên bản mô hình và prompt, kết quả kiểm chứng ở dạng có thể tái hiện.

E. Đánh giá triển khai dưới góc nhìn Kỹ sư chuyên nghiệp

Điểm khởi đầu của việc triển khai RAG không phải là “hãy gắn LLM vào”, mà là phân tích nghiệp vụ về việc thông tin nằm ở đâu, thay đổi thường xuyên đến mức nào, ai được đọc và cái giá của câu trả lời sai là bao nhiêu. Nếu quyền sở hữu tài liệu và trách nhiệm cập nhật không rõ ràng thì ngay cả thuật toán truy xuất tốt cũng không thể tạo ra câu trả lời đáng tin cậy. Trước hết cần chỉnh đốn dữ liệu nguồn và trách nhiệm nghiệp vụ, rồi xây dựng đường cơ sở từ các trường hợp sử dụng có rủi ro thấp và đo lường được.

Kiến trúc phải tách biệt truy xuất, sinh và kiểm chứng, và kết nối lỗi của từng tầng với việc tạm hoãn và các đường thay thế. Thành quả cốt lõi của RAG không phải là độ dài câu trả lời hay kích thước mô hình, mà là năng lực chuyển căn cứ cần thiết tới đúng người dùng vào đúng lúc và dừng lại một cách an toàn khi căn cứ không đủ. Cụ thể hóa nguyên tắc này thành SLO, biện pháp kiểm soát bảo mật, bộ đánh giá và runbook vận hành chính là vai trò của Kỹ sư chuyên nghiệp.

Tài liệu tham khảo

Tóm tắt một câu: RAG là kỹ thuật truy xuất tri thức bên ngoài và kết nối vào quá trình sinh của LLM, nhưng chỉ đáng tin cậy khi được thiết kế như một kiến trúc thông tin vận hành bao gồm cả chất lượng truy xuất, phân quyền, dòng dõi tài liệu, kiểm chứng và chính sách tạm hoãn.