Trả lời nhanh: RAG (Retrieval-Augmented Generation), tức sinh văn bản tăng cường truy xuất, là kỹ thuật cho mô hình AI tìm các đoạn liên quan trong kho tài liệu của bạn trước, rồi mới viết câu trả lời dựa trên các đoạn đó. Nhờ vậy câu trả lời bám dữ liệu thật, cập nhật được và có thể trích nguồn.
Điểm chính
- RAG không dạy lại mô hình. Nó “mở sách” cho mô hình tra cứu đúng lúc cần, nên đổi tài liệu là đổi được kiến thức.
- Tên RAG ra đời từ bài báo của Patrick Lewis và cộng sự (Facebook AI Research, nay là Meta AI), nộp ngày 22/05/2020, trình bày tại NeurIPS 2020.
- Pipeline RAG có hai nửa: chuẩn bị dữ liệu (ingest, chunking, embedding, vector database) và trả lời (retrieval, rerank, generation).
- Phần lớn lỗi của RAG nằm ở khâu truy xuất và chất lượng tài liệu, không phải ở mô hình ngôn ngữ.
- Kho tài liệu có dữ liệu cá nhân phải tuân thủ Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15, hiệu lực từ 01/01/2026.
Mục lục
- RAG là gì?
- Vì sao mô hình ngôn ngữ lớn cần RAG?
- RAG ra đời từ đâu?
- RAG hoạt động như thế nào?
- Có những kiểu RAG nào?
- RAG và fine-tuning khác nhau thế nào? Khi nào chỉ cần prompt dài?
- Đánh giá chất lượng hệ thống RAG bằng cách nào?
- Triển khai RAG cho doanh nghiệp Việt Nam cần chuẩn bị gì?
- Những lỗi thường gặp khi làm RAG
- Chi phí triển khai RAG gồm những gì?
- Câu hỏi thường gặp
RAG là gì?
RAG là viết tắt của Retrieval-Augmented Generation (cũng hay viết retrieval augmented generation), dịch sát là “sinh văn bản được tăng cường bằng truy xuất”. Trước khi mô hình ngôn ngữ viết (generation), hệ thống đi tìm (retrieval) thông tin liên quan trong một kho dữ liệu, rồi đưa thông tin đó vào câu lệnh để bổ sung (augmented) cho mô hình.
Hãy hình dung mô hình thông thường như thí sinh thi “đóng sách”, nhớ sai vẫn trả lời tự tin. RAG biến bài thi thành “mở sách”: lật đúng trang tài liệu rồi mới viết.
Kiến thức nằm ở kho bên ngoài chứ không trong trọng số mô hình, nên muốn AI biết quy định mới chỉ cần cập nhật kho. Vì vậy RAG trong AI doanh nghiệp là kiến trúc phổ biến nhất để dùng mô hình trên dữ liệu nội bộ.
Ví dụ: chatbot nội bộ tra quy chế công ty
Ví dụ minh hoạ: một công ty có quy chế lao động, chính sách công tác phí và sổ tay nhân sự, tổng cộng vài trăm trang PDF. Hỏi một chatbot công cộng thì nó không biết quy chế riêng, sẽ trả lời theo luật chung hoặc tự đoán. Với RAG:
- Nhân viên hỏi: “Đi công tác Đà Nẵng thì được thanh toán khách sạn tối đa bao nhiêu?”
- Hệ thống tìm trong kho, lấy ra đoạn quy định định mức lưu trú theo khu vực và đoạn về chứng từ cần nộp.
- Hai đoạn được ghép vào câu lệnh, kèm chỉ dẫn: “Chỉ trả lời dựa trên các đoạn dưới đây; nếu không có thông tin, hãy nói không tìm thấy.”
- Mô hình trả lời và ghi rõ trích từ điều nào của quy chế để nhân viên tự kiểm tra.
Khi công ty sửa định mức, chỉ cần thay file quy chế. Lần hỏi sau, câu trả lời đã theo bản mới.
Vì sao mô hình ngôn ngữ lớn cần RAG?
Một mô hình ngôn ngữ lớn có bốn giới hạn mà RAG được sinh ra để khắc phục:
- Kiến thức bị “đóng băng” ở thời điểm cắt dữ liệu huấn luyện.
- Không biết dữ liệu riêng như hợp đồng, quy trình, hồ sơ khách hàng.
- Ảo giác (hallucination): thiếu thông tin vẫn trả lời trôi chảy nhưng sai.
- Không trích được nguồn, nên khó kiểm chứng.
Hiểu RAG là gì theo cách đơn giản nhất: tách “kiến thức” khỏi “khả năng diễn đạt”. Mô hình lo đọc hiểu và viết, kho tài liệu lo sự thật.
RAG ra đời từ đâu?
Tên RAG xuất hiện trong bài báo “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks” của Patrick Lewis và 11 đồng tác giả thuộc Facebook AI Research (nay là Meta AI), University College London và Đại học New York. Bài nộp lên arXiv ngày 22/05/2020 và trình bày tại hội nghị NeurIPS 2020. Những điểm chính:
- Hai loại bộ nhớ: kiến thức trong trọng số của mô hình sinh BART-large (khoảng 400 triệu tham số) và một chỉ mục vectơ của Wikipedia.
- Kho tra cứu: Wikipedia bản tháng 12/2018, cắt thành khoảng 21 triệu đoạn 100 từ, tìm bằng bộ truy xuất DPR (Dense Passage Retriever).
- Kết quả: tốt nhất thời điểm đó trên ba bộ dữ liệu hỏi đáp mở.
- Đổi kiến thức không cần huấn luyện lại: thay chỉ mục Wikipedia 2016 bằng 2018, câu trả lời thay đổi theo.
Ngày 28/09/2020, Meta AI giới thiệu RAG trên blog và đưa mã vào thư viện mã nguồn mở Hugging Face Transformers. Các mốc đáng chú ý sau đó:
- 07/2023: nghiên cứu “Lost in the Middle” của Nelson F. Liu và cộng sự cho thấy mô hình dùng thông tin ở đầu và cuối ngữ cảnh tốt hơn hẳn thông tin nằm ở giữa.
- 09/2023: khung Ragas đề xuất bộ chỉ số tự động đánh giá RAG mà không cần nhãn do người viết.
- 04/2024: nhóm nghiên cứu của Microsoft công bố GraphRAG.
- 01/2025: bài khảo sát về Agentic RAG hệ thống hoá việc đưa tác tử AI vào điều phối truy xuất.
RAG hoạt động như thế nào?
Bước 1. Ingest: thu thập và làm sạch
Đọc file PDF, Word, Excel, wiki nội bộ, ticket. Bản scan phải qua OCR. Sau đó bỏ header, footer, số trang lặp lại; chuyển bảng về dạng đọc được; gắn metadata như tên văn bản, phòng ban, ngày hiệu lực, cấp độ bảo mật để lọc chính xác khi truy xuất.
Bước 2. Chunking: cắt tài liệu thành đoạn
Tài liệu được cắt thành đoạn (chunk) theo độ dài cố định có chồng lấn, theo cấu trúc (chương, điều, khoản) hoặc theo ngữ nghĩa. Đoạn quá ngắn mất ngữ cảnh (“mức này áp dụng cho…” mà không rõ “mức này” là gì); đoạn quá dài làm loãng nội dung và tốn token. Mẹo hiệu quả là gắn tên văn bản và tiêu đề mục vào đầu mỗi đoạn. Tháng 09/2024, Anthropic công bố kỹ thuật “contextual retrieval”: dùng mô hình viết một câu ngữ cảnh ngắn cho từng đoạn trước khi đánh chỉ mục. Theo thử nghiệm của họ, tỷ lệ truy xuất trượt trong top 20 đoạn giảm 35%, giảm 49% khi kết hợp tìm kiếm từ khoá BM25 và 67% khi thêm rerank.
Bước 3. Embedding là gì?
Embedding biến một đoạn văn thành một vectơ, tức dãy vài trăm đến vài nghìn con số, sao cho đoạn có nghĩa gần nhau thì vectơ nằm gần nhau. Nhờ đó máy hiểu “nghỉ phép năm” và “ngày phép hằng năm” là một. Với tiếng Việt, cần mô hình embedding đa ngôn ngữ hoặc huấn luyện cho tiếng Việt; ví dụ BGE-M3 (công bố 02/2024) hỗ trợ hơn 100 ngôn ngữ và văn bản tới 8.192 token. Hãy thử trên câu hỏi thật thay vì chỉ xem bảng xếp hạng. Câu hỏi và tài liệu phải dùng cùng một mô hình embedding; đổi mô hình là phải tính lại vectơ cho cả kho.
Bước 4. Vector database: nơi lưu và tìm vectơ
Vector database (cơ sở dữ liệu vectơ) lưu vectơ, nội dung gốc và metadata, cho phép tìm nhanh các vectơ gần nhất bằng chỉ mục lân cận gần đúng (ANN), đánh đổi chút độ chính xác lấy tốc độ. Có ba nhóm lựa chọn: hệ chuyên dụng (ví dụ Milvus, Qdrant, Weaviate, Pinecone), tiện ích vectơ trên cơ sở dữ liệu quen thuộc (pgvector cho PostgreSQL, tính năng vectơ của Elasticsearch, OpenSearch) và thư viện chạy trong bộ nhớ như FAISS. Với kho nhỏ và vừa, dùng luôn cơ sở dữ liệu đang có thường dễ vận hành và phân quyền hơn.
Bước 5 và 6. Embedding câu hỏi và truy xuất
Câu hỏi được đổi thành vectơ bằng đúng mô hình ở bước 3, rồi hệ thống lấy k đoạn gần nhất (top-k). Trước khi tìm phải lọc theo quyền của người hỏi và theo metadata. Nhiều hệ thống còn viết lại câu hỏi: “còn miền Nam thì sao?” thành “định mức công tác phí khu vực miền Nam”, hoặc mở rộng từ viết tắt.
Bước 7. Rerank: chấm điểm lại
Tìm bằng vectơ nhanh nhưng thô. Rerank dùng mô hình chấm điểm chính xác hơn (thường là cross-encoder, đọc câu hỏi và từng đoạn cùng lúc), ví dụ lấy 50 đoạn ứng viên rồi giữ 5 đoạn tốt nhất. Tốn thêm thời gian nhưng thường cải thiện rõ chất lượng.
Bước 8. Generation: sinh câu trả lời
Các đoạn tốt nhất được ghép vào câu lệnh cùng chỉ dẫn: chỉ dựa trên đoạn được cung cấp, nói “không tìm thấy” nếu thiếu, trích nguồn theo số đoạn. Cách viết chỉ dẫn thuộc kỹ năng viết prompt và ảnh hưởng lớn tới việc mô hình có “bịa thêm” hay không.
Có những kiểu RAG nào?
| Biến thể | Cách làm | Hợp với | Đánh đổi |
|---|---|---|---|
| Naive RAG (cơ bản) | Cắt đoạn, embedding, lấy top-k, đưa thẳng vào prompt | Bản thử nghiệm, kho nhỏ | Dễ lấy sai đoạn, chất lượng không ổn định |
| Advanced RAG (nâng cao) | Thêm bước trước truy xuất (viết lại câu hỏi, chunking theo cấu trúc) và sau truy xuất (rerank, nén ngữ cảnh) | Hầu hết hệ thống chạy thật | Nhiều thành phần, phải đo đạc và tinh chỉnh |
| Hybrid search (tìm kiếm lai) | Chạy song song tìm từ khoá (BM25) và tìm vectơ, gộp kết quả (ví dụ Reciprocal Rank Fusion) | Câu hỏi có mã số, tên riêng, số hiệu văn bản | Duy trì hai chỉ mục, chỉnh trọng số gộp |
| GraphRAG | Trích thực thể và quan hệ thành đồ thị tri thức, tóm tắt theo cụm, trả lời trên đồ thị | Câu hỏi bao quát toàn kho, dữ liệu nhiều quan hệ | Đánh chỉ mục tốn kém vì gọi mô hình trên toàn bộ tài liệu; khó cập nhật |
| Agentic RAG | Tác tử AI tự quyết định có tìm không, tìm ở đâu, tìm thêm vòng nữa, gọi công cụ khác | Câu hỏi nhiều bước, nhiều nguồn | Chậm hơn, chi phí khó đoán, khó kiểm thử |
Bài báo GraphRAG tháng 04/2024 chỉ ra RAG thông thường giỏi tìm chi tiết cụ thể nhưng kém với câu hỏi kiểu “chủ đề chính của cả bộ dữ liệu là gì”; trên bộ dữ liệu khoảng một triệu token, GraphRAG cho câu trả lời đầy đủ và đa dạng hơn đáng kể với loại câu hỏi này. Agentic RAG là điểm giao giữa RAG và tác tử AI tự chủ: thay vì “tìm một lần rồi trả lời”, tác tử lập kế hoạch, tìm nhiều vòng và tự kiểm tra, đổi lại cần giám sát chặt hơn.
Lời khuyên: bắt đầu từ advanced RAG có hybrid search và rerank; chỉ chuyển sang GraphRAG hay agentic RAG khi đo được nhu cầu thật.
RAG và fine-tuning khác nhau thế nào? Khi nào chỉ cần prompt dài?
Có ba cách đưa kiến thức riêng vào mô hình: RAG (tra cứu lúc trả lời), fine-tuning (huấn luyện thêm, thay đổi trọng số) và prompt dài (đưa nguyên tài liệu vào câu lệnh mỗi lần hỏi).
| Tiêu chí | RAG | Fine-tuning | Prompt dài |
|---|---|---|---|
| Giải quyết tốt nhất | Thiếu kiến thức, kiến thức hay thay đổi | Cách trả lời: giọng văn, định dạng, thuật ngữ | Kho nhỏ, cần đọc toàn bộ cùng lúc |
| Cập nhật kiến thức | Thay tài liệu là xong | Phải huấn luyện lại | Thay tài liệu trong prompt |
| Trích nguồn | Có, theo từng đoạn | Khó, kiến thức “tan” vào trọng số | Có thể, khó chỉ đúng vị trí khi tài liệu dài |
| Phân quyền theo người dùng | Làm ở bước truy xuất | Gần như không thể | Phải tự lọc trước khi đưa vào |
| Chi phí chính | Xây pipeline, lưu vectơ, token ngữ cảnh | Chuẩn bị dữ liệu, huấn luyện, đánh giá lại mỗi phiên bản | Token đầu vào rất lớn mỗi câu hỏi |
| Rủi ro chính | Lấy sai hoặc thiếu đoạn | Ảo giác vẫn còn, có thể làm lộ dữ liệu huấn luyện | Thông tin ở giữa bị bỏ qua, độ trễ cao |
Hướng dẫn tháng 09/2024 của Anthropic gợi ý: nếu kho kiến thức nhỏ hơn khoảng 200.000 token (họ ước tính khoảng 500 trang), có thể đưa toàn bộ vào prompt thay vì dựng RAG. Con số này ước cho tiếng Anh; số token của văn bản tiếng Việt tuỳ bộ tách token của từng mô hình, nên hãy đo trên tài liệu thật. Trong thực tế, ba cách thường kết hợp: fine-tuning cho thuật ngữ và định dạng, RAG cho sự thật cập nhật.
Đánh giá chất lượng hệ thống RAG bằng cách nào?
Đánh giá riêng từng tầng, vì câu trả lời sai có thể do lấy sai đoạn hoặc do mô hình đọc sai đoạn đúng. Trước tiên, xây bộ câu hỏi chuẩn (golden set) từ câu hỏi thật của người dùng, gồm câu dễ, câu khó, câu cần ghép nhiều đoạn và câu kho không có thông tin; người am hiểu nghiệp vụ duyệt đáp án. Mỗi lần đổi chunking, embedding hay prompt, chạy lại toàn bộ.
| Tầng | Chỉ số | Đo điều gì |
|---|---|---|
| Truy xuất | Recall@k, Precision@k (độ chính xác truy xuất), MRR, nDCG | Đoạn chứa đáp án có nằm trong top-k không, có được xếp hạng cao không |
| Sinh câu trả lời | Faithfulness (độ trung thành) | Mọi khẳng định có được đoạn ngữ cảnh hỗ trợ không |
| Sinh câu trả lời | Answer relevance, độ đúng trích dẫn | Trả lời đúng trọng tâm; nguồn trích có thật sự chứa thông tin |
| Vận hành | Tỷ lệ từ chối đúng, độ trễ, chi phí mỗi câu hỏi | Có nói “không tìm thấy” thay vì bịa; tốc độ; token tiêu thụ |
Các khung như Ragas dùng chính mô hình ngôn ngữ để chấm faithfulness và độ liên quan. Vẫn nên định kỳ cho người kiểm tra mẫu, vì mô hình chấm cũng có thể sai.
Triển khai RAG cho doanh nghiệp Việt Nam cần chuẩn bị gì?
Chuẩn bị tài liệu tiếng Việt
- Chuẩn hoá mã hoá: chuyển tài liệu font TCVN3, VNI sang Unicode. Chữ có dấu có thể lưu dạng dựng sẵn (NFC) hoặc tổ hợp (NFD), trông giống nhau nhưng máy coi là khác; hãy chuẩn hoá về một dạng, thường là NFC.
- Viết tắt và không dấu: văn bản nội bộ dày đặc viết tắt (BHXH, HĐLĐ, CBNV), người dùng hay gõ không dấu. Lập bảng viết tắt để mở rộng câu hỏi và đưa câu không dấu vào bộ kiểm thử.
- Hiệu lực văn bản: gắn ngày hiệu lực, loại bản hết hiệu lực khỏi chỉ mục, nếu không bot sẽ trích quy định cũ.
- Cấu trúc “Điều, khoản, điểm”: cắt đoạn theo đúng cấu trúc và giữ số điều trong từng đoạn để trích được “Điều 12 khoản 2”.
OCR tài liệu scan
Hồ sơ giấy, quyết định có con dấu, hợp đồng scan phải qua nhận dạng ký tự quang học (OCR) trước khi vào RAG. Chất lượng OCR là trần chất lượng của cả hệ thống: sai một chữ số trong định mức là bot trả lời sai con số. Hãy kiểm tra công cụ OCR với tiếng Việt có dấu, giữ cấu trúc hàng cột của bảng, cho người kiểm tra lại trang có độ tin cậy thấp và lưu đường dẫn tới bản gốc. Kho hồ sơ lớn nên được coi là một dự án số hoá tài liệu riêng.
Phân quyền truy cập
Nếu mọi tài liệu nằm chung một kho không phân quyền, một câu hỏi khéo có thể khiến bot trích bảng lương hay hồ sơ kỷ luật. Danh sách 10 rủi ro bảo mật cho ứng dụng mô hình ngôn ngữ lớn năm 2025 của OWASP có riêng mục LLM08:2025 “Vector and Embedding Weaknesses”, gồm truy cập trái phép, rò rỉ chéo giữa các nhóm người dùng, tấn công đảo ngược embedding để khôi phục nội dung gốc và đầu độc dữ liệu. Nguyên tắc:
- Gắn quyền (phòng ban, vai trò, cấp độ mật) vào metadata từng đoạn, đồng bộ với hệ thống quản lý danh tính.
- Lọc theo quyền trước khi truy xuất, không lọc câu trả lời sau khi đã sinh.
- Coi vectơ là dữ liệu nhạy cảm; ghi log truy vấn và đoạn được truy xuất.
- Đề phòng chèn lệnh gián tiếp qua tài liệu nạp vào; OWASP lưu ý RAG không loại bỏ hoàn toàn rủi ro chèn lệnh (prompt injection).
Bảo vệ dữ liệu cá nhân theo Luật 91/2025/QH15
Luật Bảo vệ dữ liệu cá nhân số 91/2025/QH15 được thông qua ngày 26/06/2025, hiệu lực từ 01/01/2026; Nghị định 356/2025/NĐ-CP ngày 31/12/2025 hướng dẫn thi hành và thay thế Nghị định 13/2023/NĐ-CP. Kho RAG rất dễ chứa dữ liệu cá nhân: hồ sơ nhân sự, hợp đồng có số căn cước, email khách hàng. Các điểm liên quan:
- Điều 30: xử lý dữ liệu cá nhân bằng dữ liệu lớn, trí tuệ nhân tạo, điện toán đám mây phải đúng mục đích, trong phạm vi cần thiết, có biện pháp bảo mật, xác thực, phân quyền truy cập; xử lý bằng AI phải phân loại theo mức độ rủi ro.
- Điều 20: dùng nền tảng ở ngoài lãnh thổ Việt Nam để xử lý dữ liệu cá nhân là chuyển dữ liệu xuyên biên giới; phải lập hồ sơ đánh giá tác động gửi cơ quan chuyên trách trong 60 ngày kể từ ngày đầu tiên chuyển, trừ trường hợp luật miễn. Điều này liên quan khi bạn gọi API mô hình hoặc dùng vector database đặt ở nước ngoài.
- Dữ liệu nhạy cảm: Điều 4 Nghị định 356/2025/NĐ-CP liệt kê các loại như tình trạng sức khoẻ, thông tin tài chính, dữ liệu sinh trắc học; cần phân quyền hạn chế truy cập chặt hơn.
- Khử nhận dạng và xoá: nếu chatbot không cần tên, số căn cước, hãy che hoặc xoá trước khi nạp. Khi phải xoá dữ liệu của một người, cần xoá cả ở tài liệu gốc, đoạn đã cắt, vectơ và log, nên thiết kế truy vết vectơ về tài liệu nguồn ngay từ đầu.
Ngoài ra, Luật Trí tuệ nhân tạo số 134/2025/QH15 (thông qua 10/12/2025, hiệu lực 01/03/2026) yêu cầu hệ thống AI tương tác trực tiếp với con người phải giúp người dùng nhận biết họ đang giao tiếp với AI, điều cần thể hiện rõ trên giao diện chatbot RAG phục vụ khách hàng.
Phần pháp lý trên chỉ tóm tắt các điểm liên quan đến RAG, không thay thế tư vấn pháp lý. Trước khi đưa dữ liệu khách hàng hoặc nhân sự vào hệ thống AI, hãy để bộ phận pháp chế rà soát.
Lộ trình triển khai gợi ý
- Chọn một bài toán hẹp, đo được, ví dụ hỏi đáp quy chế nhân sự.
- Làm sạch tài liệu, OCR bản scan, gắn metadata và quyền.
- Xây bộ câu hỏi chuẩn cùng người làm nghiệp vụ.
- Dựng bản thử nghiệm advanced RAG (hybrid search, rerank, trích nguồn) và đo chỉ số.
- Rà soát bảo mật, pháp lý; chạy thử với nhóm nhỏ rồi mới mở rộng.
Nếu đích đến là trợ lý hỏi đáp, xem thêm cách thiết kế và vận hành chatbot AI cho doanh nghiệp, nơi RAG thường là lõi tri thức.
Những lỗi thường gặp khi làm RAG
- Đổ mọi tài liệu vào một kho: bản cũ lẫn bản mới, nháp lẫn chính thức.
- Chunking máy móc: cắt ngang bảng hoặc điều khoản.
- Chỉ dùng tìm vectơ: trượt câu hỏi có số hiệu, mã sản phẩm; cần hybrid search.
- Không rerank, lấy quá nhiều đoạn: ngữ cảnh nhiễu, tốn token.
- Không cho mô hình nói “không biết”: dẫn tới bịa câu trả lời.
- Không đánh giá có hệ thống: thử vài câu bằng mắt rồi đưa vào dùng.
- Phân quyền ở giao diện thay vì ở tầng truy xuất.
- Quên đồng bộ chỉ mục khi tài liệu gốc thay đổi.
- Dùng RAG cho câu hỏi tổng hợp số liệu: việc này nên truy vấn cơ sở dữ liệu có cấu trúc, không đọc đoạn văn.
Chi phí triển khai RAG gồm những gì?
Không có con số chung, vì chi phí phụ thuộc quy mô kho, số câu hỏi, mô hình và cách triển khai (dùng API hay tự vận hành). Bảng dưới liệt kê các yếu tố để bạn tự lập dự toán.
| Hạng mục | Phát sinh khi nào | Phụ thuộc vào |
|---|---|---|
| Chuẩn bị dữ liệu, OCR | Ban đầu và khi thêm tài liệu | Số trang, tỷ lệ bản scan, bảng biểu, công kiểm tra thủ công |
| Embedding tài liệu | Khi nạp, cập nhật hoặc đổi mô hình | Tổng số token của kho; API hay tự chạy |
| Lưu trữ vector database | Hằng tháng | Số đoạn, số chiều vectơ, yêu cầu sao lưu |
| Gọi mô hình sinh câu trả lời | Mỗi câu hỏi | Số câu hỏi, số đoạn trong ngữ cảnh, độ dài trả lời, giá mỗi token |
| Rerank, viết lại câu hỏi | Mỗi câu hỏi | Số đoạn ứng viên, mô hình rerank |
| Hạ tầng tự vận hành | Hằng tháng hoặc đầu tư một lần | Máy chủ, GPU nếu tự chạy mô hình, đội vận hành |
| Đánh giá, bảo mật, tuân thủ | Liên tục và định kỳ | Kích thước bộ câu hỏi chuẩn, công người duyệt, mức nhạy cảm dữ liệu |
Cách giảm chi phí: rerank để đưa ít đoạn hơn vào ngữ cảnh, dùng mô hình nhỏ cho câu hỏi đơn giản, chỉ embedding lại phần tài liệu thay đổi. Khoản hay bị đánh giá thấp nhất là công chuẩn bị dữ liệu và công người kiểm tra.
Câu hỏi thường gặp
RAG có loại bỏ hoàn toàn ảo giác của AI không?
Không. RAG giảm mạnh ảo giác khi lấy đúng tài liệu, nhưng mô hình vẫn có thể hiểu sai hoặc thêm thông tin ngoài ngữ cảnh. Cần yêu cầu trích nguồn, cho phép trả lời “không tìm thấy” và đo faithfulness thường xuyên.
Làm RAG có bắt buộc dùng vector database không?
Không. Kho nhỏ có thể dùng thư viện tìm kiếm trong bộ nhớ hoặc tiện ích vectơ trên PostgreSQL, Elasticsearch sẵn có; một số hệ thống chỉ dùng tìm từ khoá. Hệ chuyên dụng phát huy khi kho lớn, nhiều người dùng đồng thời.
RAG khác gì công cụ tìm kiếm nội bộ?
Công cụ tìm kiếm trả về danh sách tài liệu để bạn tự đọc. RAG đọc các đoạn tìm được và viết câu trả lời trực tiếp kèm nguồn, nên chất lượng phụ thuộc trước hết vào khâu tìm kiếm bên dưới.
Dữ liệu đưa vào RAG có bị dùng để huấn luyện mô hình không?
RAG không huấn luyện mô hình; tài liệu chỉ được gửi kèm câu hỏi. Nhà cung cấp API có lưu hay dùng dữ liệu không là do điều khoản dịch vụ, hãy đọc kỹ và lưu ý quy định chuyển dữ liệu xuyên biên giới.
RAG có dùng tốt với tài liệu tiếng Việt không?
Có, nếu chọn mô hình embedding hỗ trợ tiếng Việt tốt, chuẩn hoá Unicode, xử lý viết tắt và câu không dấu, OCR bản scan đúng dấu và kiểm thử bằng câu hỏi thật.
Doanh nghiệp nhỏ có cần RAG không?
Nếu tài liệu ít, ổn định và không cần phân quyền, đưa thẳng vào prompt của mô hình có ngữ cảnh dài có thể đủ. RAG thật sự cần khi tài liệu nhiều, hay thay đổi và nhiều nhóm người dùng có quyền khác nhau.