Triển khai RAG cho doanh nghiệp: kiến trúc MONA đang chạy thật

Triển khai RAG cho doanh nghiệp là dựng một luồng để chatbot tìm đúng mẩu tài liệu nội bộ trước, rồi mới dùng AI soạn câu trả lời có nguồn. Sau hơn 14.000 dự án, tụi em chỉ đưa bot vào vận hành khi người quản trị nhìn được kiến trúc 5 bước, nguồn của 70 chunk cắt từ 10 file và code đã qua 2 lần duyệt. Phần định nghĩa đã có ở bài RAG là gì. Nguồn phải nhìn được.

RAG bắt bot tìm tài liệu trước rồi mới cho trả lời

Khách hỏi chính sách đổi lịch, bot thường có 2 đường: đoán theo kiến thức chung hoặc tìm đúng văn bản doanh nghiệp đã duyệt. RAG chọn đường thứ 2. Nó tìm mẩu liên quan trong kho, đưa mẩu đó cùng câu hỏi cho mô hình, rồi yêu cầu trả lời trong phạm vi nguồn vừa tìm. Tìm rồi mới nói.

Mỗi câu hỏi đi qua 5 lượt xử lý nối nhau và 2 lượt đối chiếu giữa mẩu tìm được với câu trả lời, nhờ vậy đội biết lỗi nằm ở kho hay ở chỉ dẫn sinh câu. Nếu bot lấy nhầm mẩu, sửa kho; nếu lấy đúng mẩu mà diễn đạt sai, sửa chỉ dẫn. Tách lỗi ra sửa.

Tụi em đặt luồng đó trong mô hình phát triển phần mềm AI-Native, nơi code và nguồn đều phải có người kiểm.

Tại MONA, chatbot trực web mona.media và tổng đài 1900 636 648 chạy theo kiến trúc RAG. Một kho con của hệ thống nạp 10 file thành 70 chunk, mỗi chunk gắn nguồn để câu trả lời quay về đúng tài liệu. Đây là dấu vết kỹ thuật tụi em dùng thật, không phải sơ đồ để trình bày.

Tài liệu đã duyệt thì đưa vào kho, dữ liệu sống cứ để hệ thống gốc

Kho RAG tốt bắt đầu bằng việc chọn nguồn. Tài liệu nội bộ, bảng giá đã công bố, chính sách đổi trả và hướng dẫn nghiệp vụ ổn định là đầu vào hợp lý. Số dư, tồn kho hoặc trạng thái đơn thay đổi từng giây phải đọc từ hệ thống gốc qua API, đừng chép thành file rồi mong RAG luôn đúng. Chọn nguồn trước.

Tụi em thường khóa 3 trường metadata tối thiểu cho mỗi mẩu: nguồn, phần tài liệu và phiên bản. Nhờ đó bot trích được chỗ nó dựa vào, còn người quản trị tìm được file phải sửa. Đội đang làm chatbot AI cho doanh nghiệp đừng đổ nguyên ổ tài liệu lẫn lộn vào kho rồi hy vọng mô hình tự phân biệt bản cũ với bản mới.

Trước khi nạp, đội chạy 3 lượt kiểm phiên bản và 2 lượt đối chiếu với hệ thống gốc cho phần dữ liệu còn sống.

Nhìn tận tay: 5 bước từ câu khách hỏi đến câu trả lời có nguồn

Luồng dưới đây là bộ xương của một chatbot RAG. Anh chị dùng nó để hỏi đối tác đang triển khai: mỗi bước chạy ở đâu, lưu bằng chứng gì, khi sai thì người vận hành mở chỗ nào. Có đúng 5 bước. Thiếu bước thì hỏi tiếp.

1. Nhận câu hỏi: giữ nguyên câu khách nhập cùng ngữ cảnh được phép dùng.
2. Biến câu hỏi thành truy vấn: chuẩn hóa ý tìm, không tự thêm một kết luận chưa có.
3. Tìm các chunk liên quan: lấy mẩu nội dung cùng metadata nguồn từ kho.
4. Sinh câu trả lời: đưa câu hỏi và mẩu tìm được cho mô hình, bắt nó bám đúng nguồn.
5. Trả lời kèm nguồn: hiển thị câu trả lời, tài liệu tham chiếu và log 5 bước để người kiểm lại.

Ở bước 3, lấy nhiều chưa chắc tốt; mẩu thừa làm câu trả lời nhiễu. Ở bước 4, chỉ dẫn phải ghi rõ: không có mẩu đủ căn cứ thì nói chưa tìm thấy và chuyển người phụ trách. Chính đường lui này giữ chatbot khỏi đoán bừa.

Đội chạy 5 lần theo đúng luồng và lặp 2 lần bằng câu ngoài kho, vì bot biết dừng mới được tính là qua nghiệm thu.

Luồng 5 bước cũng là một bản spec rất rõ cho đội kỹ thuật. Bài cách viết spec cho AI chỉ cách thêm dữ liệu vào, đầu ra, ca lỗi và tiêu chí nghiệm thu để luồng này được code rồi chấm bằng cùng một đáp án.

Cắt 10 file thành 70 chunk để bot tìm đúng mẩu nhỏ

Nếu ném nguyên một file dài vào mô hình, phần đúng dễ bị chìm giữa nhiều đoạn không liên quan. Chunk là mẩu tài liệu nhỏ đủ mang một ý trọn, kèm thông tin nó đến từ file nào. Kho con của chatbot MONA lấy 10 file và tách thành 70 chunk, tức trung bình 7 mẩu trên mỗi file trong đúng bộ đó. Mẩu nhỏ dễ tìm.

Con số 7 là phép chia của kho con này, không phải công thức áp cho mọi tài liệu. Hợp đồng có điều khoản dài cần giữ phần liên quan cạnh nhau; bảng giá cần giữ tên gói cùng mức giá; câu hỏi thường gặp có thể tách theo từng cặp hỏi đáp. Tụi em chọn ranh giới theo nghĩa, không chặt đều theo số ký tự.

Mỗi chunk giữ ít nhất 3 dấu vết: file nguồn, mục nguồn, phiên bản hoặc ngày hiệu lực. Khi bot trả sai, đội mở log xem nó đã kéo chunk nào trong 70 mẩu. Nếu nguồn đúng mà câu chữ sai, sửa chỉ dẫn; nếu nguồn sai, sửa cách cắt hoặc tìm. Quy trình chẩn đoán tách đôi như vậy tiết kiệm nhiều vòng đoán.

Khi nghiệm thu, đội thử tìm 5 lần bằng các cách hỏi khác nhau, rồi chạy 2 lần với câu không có trong kho để kiểm đường lui.

Bot vẫn trả sai nếu 4 chỗ trong kho làm ẩu

RAG giữ bot bám nguồn khi cả chuỗi làm đúng. Bốn lỗi thường gặp là cắt mẩu mất nghĩa, để nhiều phiên bản cùng sống, không lưu metadata và ép bot phải trả lời dù không tìm thấy căn cứ. Chỉ cần 1 lỗi, câu trả lời vẫn trôi khỏi tài liệu thật. Kho sạch trước.

Tụi em kiểm riêng 2 tỷ lệ ở bản thử: câu hỏi có nguồn thì bot kéo đúng mẩu hay không, câu hỏi ngoài kho thì bot có chịu dừng hay không. Brief không cho sẵn một ngưỡng chung, nên mỗi doanh nghiệp phải chốt bộ câu hỏi nghiệm thu từ dữ liệu thật. Đừng nhận con số đẹp từ đối tác nếu không xem danh sách câu hỏi phía sau.

Tụi em lưu cả 2 nhóm câu hỏi để lần cập nhật kho sau chạy lại đúng bộ cũ, tránh sửa một chỗ rồi làm hỏng chỗ khác.

Mỗi thay đổi kho phải qua 4 lần kiểm theo 4 lỗi trong bảng và ít nhất 2 lần chạy lại bộ câu hỏi cũ.

MONA đang chạy RAG trên web và tổng đài ra sao

Khách vào khung chat mona.media hoặc gọi tổng đài 1900 636 648 đều cần câu trả lời bám thông tin MONA đã duyệt. Kiến trúc RAG lấy câu hỏi, tìm chunk trong kho, sinh câu trả lời và giữ nguồn trong log. Một kho con 10 file thành 70 chunk là phần tụi em đã mở ra trong brief này. Đang chạy thật.

AI gánh việc tìm và diễn đạt. Dev senior duyệt code qua 2 cửa trước máy chủ; người phụ trách nội dung quyết tài liệu nào được đưa vào kho và lúc nào bản cũ hết hiệu lực. Vai trò tách rõ giúp bot không tự biến thành nơi ban hành chính sách.

Mỗi câu hỏi đi qua 5 lượt xử lý, còn code cùng nguồn giữ 2 lượt duyệt tách vai trước lúc bản mới được đưa lên chạy.

Kiến trúc này cũng nối với dịch vụ viết AI agent theo yêu cầu. RAG lo phần nhớ đúng tài liệu, agent lo phần gọi công cụ trong ranh giới được cấp. Anh chị cần bot chỉ trả lời thì dừng ở RAG; cần bot cập nhật đơn hoặc tạo yêu cầu thì thêm cửa quyền, xác nhận và log.

3 bài toán đừng dùng RAG

RAG không phải đáp án cho mọi dữ liệu doanh nghiệp. Với 3 nhóm dưới đây, đội chạy 3 lượt đối chiếu nguồn và giữ 2 lượt duyệt của người có trách nhiệm, vì một câu trả lời trôi theo dữ liệu cũ sẽ kéo quyết định thật đi sai. Biết lúc dừng.

1. Dữ liệu đổi từng giây: tồn kho, số dư, trạng thái đơn phải đọc từ API của hệ thống gốc tại lúc hỏi; RAG chỉ giữ hướng dẫn cách hiểu trường dữ liệu.
2. Bài toán tính toán: thuế, lãi, định mức và công thức phải chạy bằng code đã kiểm thử; RAG tìm công thức hoặc chính sách, không tự làm máy tính.
3. Quyết định pháp lý: bot được trích nguồn và tóm tắt, người có thẩm quyền giữ quyết định cuối cùng cùng dấu vết phê duyệt.

Một luồng thực tế có thể ghép 2 cách: RAG tìm chính sách đổi hàng, code kiểm ngày mua và trạng thái đơn từ dữ liệu sống. Tụi em khuyên đội đang làm chuyển đổi AI doanh nghiệp vẽ ranh giới này trước khi mua thêm mô hình hoặc tăng kho tài liệu.

RAG chỉ là phần kỹ thuật, cả dự án vẫn phải chạy đủ 4 trụ

RAG là một kiến trúc kỹ thuật bên trong sản phẩm; 4 trụ mới là cách quản cả dự án. SDD ghi 5 bước cùng ca nghiệm thu, AI-DLC cho AI hỗ trợ từ phân tích đến vận hành, Kanban giữ từng thay đổi đi liên tục, Agentic SDLC cho MVP nhỏ chạy nhanh trong ranh giới. Kiến trúc cần quy trình.

Trong mô hình phát triển phần mềm AI-Native, người vẫn ra đề, kiểm soát và chịu trách nhiệm. Bot tìm trong 70 chunk là tay chân; người duyệt nguồn, quyền và câu nào phải chuyển chuyên viên. Đội đang tắc vì thay đổi kho chờ hết một đợt 2 tuần có thể xem cách Kanban cho việc chảy liên tục.

Ngày 19/08/2026, tụi em phát hành whitepaper 14 trang về 4 trụ sau 1 buổi chiều làm theo đúng mô hình. AI dựng phần lặp, người bắt 3 lỗi bố cục. Cùng nguyên tắc đó giữ dự án RAG nhanh mà vẫn có người chịu trách nhiệm cho câu trả lời.

Câu hỏi thường gặp về triển khai RAG cho doanh nghiệp

RAG có làm chatbot hết bịa không?

RAG giảm đường đoán bằng cách bắt bot tìm nguồn trước. Sau hơn 14.000 dự án, tụi em vẫn giữ 2 lần duyệt cho nguồn và code, vì chỉ gắn nhãn RAG chưa đủ để giao trách nhiệm cho máy.

Triển khai RAG cho doanh nghiệp cần bao nhiêu tài liệu?

Không có số file chung. Kho con MONA dùng 10 file thành 70 chunk, nhưng con số cần theo ý nghĩa tài liệu. Hãy chọn một nhóm chính sách đã duyệt và bộ câu hỏi thật trước, rồi đo khả năng tìm đúng.

RAG khác chatbot học lại mô hình ở đâu?

RAG giữ kiến thức trong kho tài liệu được thay riêng, còn mô hình sinh câu trả lời không phải huấn luyện lại mỗi lần đổi chính sách. Khi bản giá mới có hiệu lực, đội thay nguồn và lập chỉ mục lại phần liên quan.

Ai chịu trách nhiệm cập nhật kho RAG?

Người sở hữu nghiệp vụ duyệt nội dung; đội kỹ thuật xử lý chunk, metadata và tìm kiếm. Tối thiểu 2 vai này phải rõ. Dev không tự ban hành chính sách, người nội dung không tự cấp quyền hệ thống.

Bắt đầu bằng 1 kho nhỏ có nguồn và 5 bước nhìn thấy được

Triển khai RAG cho doanh nghiệp nên bắt đầu từ một tập tài liệu đã duyệt, không phải toàn bộ ổ lưu trữ. Chạy 5 lần theo luồng, lặp 3 lần với câu ngoài kho và giữ đủ dấu vết nguồn cho mỗi chunk. Bot biết dừng khi thiếu căn cứ đáng giá hơn một bot trả lời mọi câu. Kho nhỏ, nguồn rõ.

Anh chị muốn dựng bộ AI agent hoặc chatbot RAG từ tài liệu nội bộ, gọi 1900 636 648. Tụi em sẽ bắt đầu bằng nguồn, cách cắt chunk và bộ câu hỏi nghiệm thu; đúng 5 bước rồi mới tính tới giao diện hay số lượng mô hình.