Triển khai RAG cho tài liệu nội bộ on-premise: hướng dẫn thực hành

"Cho AI đọc tài liệu nội bộ rồi trả lời câu hỏi của nhân viên" — nghe đơn giản, và demo lúc nào cũng đẹp. Nhưng khi đưa vào vận hành thật, phần lớn dự án vỡ ở những chỗ không ai nói tới trong demo: kho tài liệu bẩn, phân quyền lỏng, và một cảm giác "chắc là ổn" thay cho số liệu. Bài này là hướng dẫn thực hành triển khai RAG cho tài liệu nội bộ, chạy trên hạ tầng của chính tổ chức, viết cho người sắp bắt tay làm chứ không phải người đi nghe giới thiệu sản phẩm.

RAG là gì, nói cho gọn

RAG (Retrieval-Augmented Generation) không phải huấn luyện lại mô hình. Ý tưởng đơn giản hơn nhiều: khi có câu hỏi, hệ thống đi tìm những đoạn tài liệu liên quan nhất, nhét chúng vào ngữ cảnh, rồi để mô hình ngôn ngữ trả lời dựa trên đúng những đoạn đó, kèm trích dẫn nguồn.

Điểm mấu chốt là mô hình không cần biết trước nội dung tài liệu của bạn. Nó không được nhồi vào trọng số. Nó chỉ đọc những đoạn được đưa vào ngay tại lượt hỏi. Vì thế cập nhật tài liệu là hệ thống biết ngay, không phải huấn luyện lại; gỡ một tài liệu khỏi kho là nó biến mất khỏi mọi câu trả lời sau đó. Trả lời có nguồn để người dùng kiểm chứng, và đó là khác biệt lớn nhất so với một chatbot trả lời trơn tru mà không chỉ được nó lấy thông tin từ đâu.

Ranh giới cần vạch rõ ngay từ đầu: RAG khác fine-tune. Fine-tune dạy mô hình một văn phong, một định dạng đầu ra, một cách hành xử cố định; RAG cấp cho mô hình dữ kiện tươi tại thời điểm hỏi. Với tài liệu nội bộ thay đổi liên tục, RAG gần như luôn là hướng đúng.

Vì sao nên chạy on-premise

Tài liệu nội bộ là nơi tập trung thứ nhạy cảm nhất của tổ chức: hợp đồng, hồ sơ nhân sự, tài liệu nghiệp vụ, hồ sơ thầu chưa mở. Đẩy chúng qua một API đám mây nước ngoài đồng nghĩa dữ liệu rời khỏi tầm kiểm soát — vướng nghĩa vụ bảo vệ dữ liệu cá nhân và, với nhiều tổ chức, là điều không được phép. Chạy mô hình cục bộ giữ toàn bộ vòng xử lý trong nhà: đọc, cắt, mã hóa, truy hồi, sinh câu trả lời — không gói tin nào chứa nội dung văn bản đi ra Internet.

On-premise còn cho bạn ba thứ khó có ở dịch vụ thuê ngoài. Quyền kiểm soát vòng đời dữ liệu: bạn quyết định lưu gì, bao lâu, ai chạm vào. Khả năng giải trình: mọi câu hỏi và mọi nguồn được dùng đều nằm trong nhật ký của bạn, phục vụ kiểm toán nội bộ và các nghĩa vụ minh bạch cho hệ thống AI. Và sự ổn định: mô hình không đổi sau lưng bạn sau một bản cập nhật của nhà cung cấp, nên hành vi hôm nay giống hành vi tháng sau. Chúng tôi đã bàn kỹ nền tảng này ở bài AI on-premise đọc tài liệu nội bộ; bài này tập trung vào phần dựng RAG.

Kiến trúc: dữ liệu đi từ đầu tới cuối như thế nào

Hình dung một đường ống thẳng, chia hai nhánh. Nhánh nạp (offline, chạy khi có tài liệu mới): tài liệu thô → làm sạch và trích văn bản → cắt thành đoạn → tạo embedding → lưu vào kho vector kèm siêu dữ liệu. Nhánh hỏi (online, chạy mỗi lượt): câu hỏi → lọc quyền → truy hồi đoạn liên quan → xếp hạng lại → đưa vào ngữ cảnh cùng câu hỏi → mô hình ngôn ngữ cục bộ sinh câu trả lời có trích dẫn. Hai nhánh gặp nhau ở kho vector. Hiểu được sơ đồ này thì mỗi bước dưới đây vào đúng chỗ của nó.

1. Chuẩn bị dữ liệu — khâu quyết định, hay bị xem nhẹ nhất

Đây là chỗ phần lớn dự án thất bại, và gần như không demo nào nhắc tới. Nếu tài liệu của bạn là giấy tờ scan, ảnh chụp, PDF lộn xộn, thì trước khi nói tới RAG phải số hóa và làm sạch chúng thành dữ liệu đọc được. Rác vào thì rác ra — không mô hình nào cứu được một kho tài liệu không đọc nổi. Bảng biểu bị bẹp thành một dòng, tiêu đề dính vào chân trang, ký tự OCR sai dấu tiếng Việt: mỗi lỗi này về sau biến thành một câu trả lời sai mà bạn rất khó truy ngược.

Với giấy tờ cũ, đây là bài toán riêng: số hóa và rút trích thành dữ liệu có cấu trúc. Đó là việc Molly làm — và nói cho rõ, Molly không phải hệ thống RAG hay chatbot: nó là lớp số hóa, rút trích và tra cứu, nhắm vào hàng loạt văn bản cùng mẫu. Nhưng một kho dữ liệu sạch chính là nguyên liệu đầu vào mà bất kỳ hệ RAG nào cũng cần. Đừng gộp hai việc: RAG là kiến trúc hỏi đáp; số hóa theo mẫu là công đoạn đứng trước nó.

2. Chia nhỏ tài liệu (chunking)

Tài liệu dài phải cắt thành đoạn vừa đủ để tìm kiếm chính xác. Cắt quá to thì một đoạn mang nhiều chủ đề, truy hồi ra nhiễu; cắt quá nhỏ thì mất ngữ cảnh, mô hình đọc một mẩu treo lơ lửng. Cắt theo cấu trúc tự nhiên (mục, điều, khoản, tiêu đề) thường tốt hơn cắt theo số ký tự cứng, vì nó tôn trọng ranh giới ý nghĩa. Cho các đoạn gối nhau một chút để không cắt ngang câu quan trọng, và giữ lại phần tiêu đề mục ở mỗi đoạn để mô hình biết đoạn này thuộc về đâu.

3. Tạo embedding và lưu vào kho vector

Mỗi đoạn được chuyển thành vector số biểu diễn ngữ nghĩa, lưu vào một kho vector. Câu hỏi của người dùng cũng thành vector, rồi hệ thống tìm những đoạn gần nhất về ngữ nghĩa. Chất lượng mô hình embedding với tiếng Việt quyết định hệ thống có tìm đúng đoạn hay không — nếu bước này sai, mô hình ngôn ngữ giỏi đến mấy cũng chỉ đang viết văn trên tài liệu sai. Kho vector phải lưu kèm siêu dữ liệu của từng đoạn: thuộc tài liệu nào, phòng ban nào, mức mật nào, phiên bản nào. Bỏ qua phần siêu dữ liệu này là gieo mầm cho mọi sự cố rò rỉ chéo nói ở dưới.

4. Truy hồi và xếp hạng

Lấy các đoạn ứng viên rồi xếp hạng lại để chọn ra thứ thật sự liên quan. Kết hợp tìm kiếm ngữ nghĩa với tìm kiếm từ khóa (hybrid) thường cho kết quả tốt hơn dùng một mình — đặc biệt với tiếng Việt và các thuật ngữ chuyên ngành, số hiệu văn bản, mã hợp đồng, những thứ mà tìm kiếm ngữ nghĩa hay bỏ lỡ còn tìm từ khóa bắt chính xác. Một bước xếp hạng lại (re-rank) trên nhóm ứng viên giúp đẩy đoạn đúng lên đầu và cắt bớt số đoạn đưa vào ngữ cảnh, vừa tăng độ chính xác vừa giảm chi phí sinh.

5. Sinh câu trả lời có trích dẫn

Mô hình ngôn ngữ chạy cục bộ trả lời chỉ dựa trên các đoạn được truy hồi, kèm trích dẫn tài liệu nguồn. Các mô hình mở như Llama, Qwen, Gemma đều chạy được on-premise, kể cả trong môi trường ngắt mạng hoàn toàn. Yêu cầu trích dẫn không phải để đẹp: nó là cơ chế để người dùng kiểm chứng và phát hiện khi mô hình bịa. Chỉ dẫn cho mô hình một quy tắc cứng — nếu ngữ cảnh không đủ để trả lời thì nói "không tìm thấy trong tài liệu" thay vì đoán — giảm được phần lớn hiện tượng bịa đặt tự tin.

6. Phân quyền — chỗ ít ai nói nhưng dễ gây họa

Đây là điểm nguy hiểm nhất. Nếu hệ RAG truy hồi trên toàn bộ kho tài liệu mà không xét quyền của người hỏi, bạn vừa tạo ra một cỗ máy rò rỉ dữ liệu chéo hợp pháp hóa: nhân viên hỏi một câu vô hại và nhận về nội dung từ tài liệu họ không được phép đọc. Cơ chế gây lỗi rất dễ hình dung: đội triển khai nạp cả thư mục chia sẻ cho nhanh, rồi định lọc quyền ở bước hiển thị. Nhưng câu trả lời đã được sinh ra từ ngữ cảnh chứa đoạn đó rồi — lọc ở đầu ra là lọc muộn.

Nguyên tắc: quyền truy cập phải được áp ở bước truy hồi, không phải lọc ở bước hiển thị. Người dùng nào chỉ được thấy tài liệu nào — hệ thống phải biết trước khi tìm, và truy vấn vào kho vector luôn kèm điều kiện quyền của người hỏi. Quyền nên kế thừa từ hệ thống quản lý tài liệu gốc, không dựng một bảng phân quyền song song sẽ lệch sau vài tháng. Và khi nhân viên chuyển bộ phận hay nghỉ việc, quyền phải đổi ngay trên cả kho vector chứ không chỉ trên thư mục gốc.

7. Đánh giá — đừng tin cảm giác

Xây một bộ câu hỏi thật của tổ chức kèm đáp án đúng, rồi đo: tỉ lệ trả lời đúng, tỉ lệ bịa (hallucination), trích dẫn có đúng nguồn không, tốc độ phản hồi. Câu trả lời nghe hay nhưng không chỉ được nguồn thì tính là sai. Không đo thì bạn không biết hệ thống đang tốt lên hay tệ đi sau mỗi lần chỉnh — mà RAG có rất nhiều nút để chỉnh: kích thước đoạn, mô hình embedding, số đoạn truy hồi, cách xếp hạng, câu chỉ dẫn cho mô hình. Bộ câu hỏi chuẩn biến việc dò dẫm cảm tính thành việc so số trước và sau.

On-premise và ngắt mạng: những điều cần lường trước

Chạy trong nhà không tự động là chạy ngắt mạng hoàn toàn. Nếu tổ chức thật sự cần air-gapped, hãy lường trước ba việc: tải sẵn mọi trọng số mô hình (ngôn ngữ, embedding, xếp hạng lại) vào trong vành đai mạng, vì sẽ không có lượt tải về nào lúc chạy; dựng quy trình cập nhật mô hình và thư viện qua kênh chuyển tệp có kiểm soát chứ không qua pip install thẳng ra Internet; và chấp nhận rằng mọi thứ vá lỗi, theo dõi, sao lưu đều phải tự vận hành. Đổi lại, bạn có một hệ thống mà không dữ kiện nào rời khỏi phòng máy — đúng thứ nhiều hồ sơ mật theo ngành đòi hỏi.

Phần cứng cần bao nhiêu là đủ

Kỳ vọng sai ở bước này làm hỏng cả dự án, nên nói thẳng. Bộ nhớ GPU cần cho trọng số xấp xỉ bằng số tham số nhân số byte mỗi tham số: 16 bit là 2 byte, lượng tử hóa 8 bit là 1 byte, 4 bit là nửa byte. Ngoài trọng số còn cần chỗ cho bộ nhớ đệm ngữ cảnh, tăng theo độ dài văn bản đưa vào và số người dùng đồng thời. Ba nhóm quy mô: một GPU cỡ vừa với mô hình vài tỉ tham số lượng tử hóa đủ cho giai đoạn thử nghiệm một phòng ban; một máy chủ GPU bộ nhớ lớn chạy mô hình cỡ trung phục vụ hàng chục người đồng thời là điểm cân bằng của phần lớn doanh nghiệp; cụm nhiều GPU chỉ cần khi lên tới nhiều nghìn người dùng, và chi phí nhảy bậc rõ rệt ở ngưỡng đó. Đừng quên phần embedding và kho vector cũng cần tài nguyên riêng, thường trên CPU và RAM, tách khỏi GPU sinh câu trả lời.

Giới hạn cần nói rõ với ban lãnh đạo: một mô hình mở chạy trên một máy chủ trong phòng máy của bạn sẽ không mạnh bằng mô hình lớn nhất trên đám mây. Nó không cần mạnh bằng. Với tác vụ tìm và tóm tắt một đoạn đã được truy hồi sẵn, khoảng cách năng lực thu hẹp rất nhiều so với tác vụ suy luận mở.

Quản trị: phân quyền, nhật ký, vòng đời

Phân quyền ở bước truy hồi mới là nền; trên nó cần một lớp quản trị vận hành. Ghi nhật ký mỗi câu hỏi và các nguồn đã dùng để dựng lại được sự việc khi có nghi vấn lộ thông tin. Gắn vòng đời tài liệu vào kho vector: văn bản hết hiệu lực, bản cũ bị thay, tài liệu bị thu hồi đều phải được gỡ hoặc đánh dấu để không lọt vào câu trả lời. Có người chịu trách nhiệm rõ ràng cho việc theo dõi chất lượng và xử lý khi hệ thống trả lời sai — không có vai trò này thì hệ thống xuống cấp âm thầm. Ở góc nhìn AI chủ quyền cho doanh nghiệp Việt, quản trị được đặt vào bối cảnh lựa chọn hạ tầng và tuân thủ rộng hơn.

Tự xây hay mua sẵn

Không có câu trả lời đúng cho mọi tổ chức, nhưng có cách hỏi đúng. Tự xây cho bạn quyền kiểm soát tối đa và không phụ thuộc nhà cung cấp, đổi lại bạn phải nuôi một đội hiểu cả mô hình, truy hồi lẫn phân quyền, và phải tự chịu mọi lần hệ thống trả lời sai. Mua một giải pháp đóng gói rút ngắn thời gian tới giá trị và đẩy phần vận hành khó cho nhà cung cấp, đổi lại là chi phí định kỳ và mức độ tùy biến giới hạn. Phần lớn tổ chức nên bắt đầu bằng một thử nghiệm nhỏ để hiểu bài toán của chính mình trước khi cam kết một trong hai hướng — nhiều đội phát hiện thứ họ cần chỉ là một ô tìm kiếm tử tế, và điều đó đáng biết sớm.

Danh sách kiểm khi triển khai

• Bài toán: Xác nhận đây thật sự là hỏi đáp ngôn ngữ tự nhiên cần tổng hợp nhiều tài liệu, không phải tìm từ khóa hay rút trích theo mẫu.
• Dữ liệu: Số hóa và làm sạch tài liệu, kiểm tra chất lượng văn bản trích ra trước khi nạp.
• Bộ câu hỏi chuẩn: Soạn khoảng vài chục câu hỏi thật kèm đáp án đúng, trước khi dựng hệ thống.
• Phân quyền: Áp quyền ở bước truy hồi, kế thừa từ hệ thống gốc, thử vượt quyền bằng tài khoản quyền thấp.
• Trích dẫn: Mọi câu trả lời phải chỉ được nguồn; câu không có nguồn tính là sai.
• Nhật ký: Ghi lại câu hỏi và nguồn đã dùng cho từng lượt.
• Đo lường: Chạy bộ câu hỏi chuẩn trước và sau mỗi lần chỉnh, so số chứ không so cảm giác.
• Người vận hành: Có người chịu trách nhiệm theo dõi GPU, cập nhật mô hình và xử lý câu trả lời sai.

Không phải bài toán nào cũng cần RAG

Đây là điều ít nhà cung cấp nói. Hãy hỏi thật: bạn cần hỏi đáp bằng ngôn ngữ tự nhiên, hay chỉ cần tìm đúng tài liệu / lấy đúng vài trường dữ liệu?

• Cần tìm văn bản theo từ khóa → tìm kiếm toàn văn đơn giản hơn, nhanh hơn, và không bịa.
• Cần lấy ra các trường có cấu trúc (số hợp đồng, ngày, tên) từ hàng loạt giấy tờ cùng mẫu → rút trích dữ liệu chính xác và kiểm chứng được hơn nhiều.
• Chỉ khi câu hỏi mở, cần tổng hợp từ nhiều tài liệu, RAG mới thật sự đáng công.

Chọn đúng công cụ cho bài toán tiết kiệm hơn nhiều so với dựng một hệ RAG rồi phát hiện thứ mình cần chỉ là một ô tìm kiếm tử tế.

Kết

RAG on-premise là bài toán kỹ thuật giải được, nhưng phần khó không nằm ở mô hình — nó nằm ở dữ liệu sạch, phân quyền đúng ở bước truy hồi, và đo lường thật bằng bộ câu hỏi chuẩn. Tổ chức nào làm nghiêm ba thứ đó sẽ có một trợ lý tra cứu dùng được; ai bỏ qua sẽ có một demo đẹp và một rủi ro rò rỉ.

Nếu muốn đánh giá bài toán tài liệu nội bộ của tổ chức và chọn đúng hướng đi, hãy đặt lịch tư vấn.