Triển khai RAG cho doanh nghiệp 2026 | Ranh giới dừng ở PoC và mốc thu hồi vốn

Chúng tôi thường xuyên nhận được đề nghị “muốn cho AI tạo sinh đọc quy định nội bộ, tài liệu thiết kế và lịch sử xử lý sự cố trong quá khứ”. Số doanh nghiệp cân nhắc triển khai RAG cho doanh nghiệp như một phương án cho nhu cầu đó đã tăng rõ rệt từ đầu năm 2026. Mặt khác, chúng tôi cũng nghe không ít câu chuyện rằng dự án đã đi được đến bước thử nghiệm nhưng không chạm tới vận hành thật rồi lặng lẽ biến mất. Bài viết này không bàn về cách xây dựng RAG, mà tập trung vào cách phán đoán xem doanh nghiệp mình có nên đầu tư hay không. Chúng tôi sắp xếp theo đúng thứ tự mà bạn cần nắm trước khi viết tờ trình duyệt ngân sách, gồm điều kiện phân tách giữa công ty dừng ở PoC và công ty tiến tới vận hành thật, khoảng chi phí thực tế, và mốc khối lượng công việc để việc thu hồi vốn trở nên khả thi.

RAG là gì | Thống nhất trước tiền đề về khai thác dữ liệu nội bộ bằng AI tạo sinh

RAG là viết tắt của Retrieval-Augmented Generation, nghĩa là sinh nội dung có tăng cường truy xuất. Đây là cơ chế trong đó, trước khi để AI tạo sinh trả lời, hệ thống tìm và lấy ra các đoạn liên quan từ tài liệu nội bộ, đưa chúng vào làm căn cứ rồi mới cho AI dựng câu trả lời.

Trong bối cảnh phán đoán đầu tư, điều duy nhất bạn cần nắm là cơ chế này có hai tầng gồm truy xuất và sinh nội dung. Với người dùng thì nó trông giống một công cụ chat tra cứu nội bộ, nhưng bên trong, bước “lấy ra những mảnh tài liệu gần nghĩa nhất” chạy trước, và câu trả lời chỉ được dựng trong phạm vi những đoạn văn đã lấy ra đó. Nếu tờ giấy được đưa cho AI không hề chứa câu trả lời thì dù dùng mô hình mạnh đến đâu, kết quả trả về cũng không thể đúng.

Từ cấu trúc này, ta suy ra ngay được RAG giỏi loại câu hỏi nào và yếu ở loại câu hỏi nào.

Nếu bắt đầu PoC mà chưa chia sẻ ranh giới này trong nội bộ, người dùng sẽ thử đúng ba loại câu hỏi mà RAG không giỏi, thấy hệ thống không trả lời được rồi kết luận “dùng không được”. Kết quả đáng tiếc là hệ thống chạy đúng như thiết kế nhưng điểm đánh giá lại đi xuống. Ngay trong cuộc họp đầu tiên của giai đoạn cân nhắc, hãy trình bày rõ các dạng câu hỏi mà hệ thống trả lời được, kèm ví dụ cụ thể.

Bài viết này không bàn tới các kỹ thuật nâng độ chính xác truy xuất hay các lý thuyết thiết kế phía xây dựng như chia đoạn văn bản và xếp hạng lại kết quả. Quy trình xây dựng cụ thể với đề tài là tra cứu tri thức trong nhà máy đã được giải thích chi tiết tại Chi phí và cách triển khai hệ thống RAG cho tra cứu tri thức đa ngôn ngữ tại nhà máy ở Thái Lan, nên khi bước vào giai đoạn bàn cách làm, xin mời tham khảo bài đó. Bài viết hiện tại đứng ở bước trước đó và chỉ xử lý những dữ kiện cần cho giai đoạn quyết định có làm hay không.

Ranh giới của doanh nghiệp triển khai RAG | Công ty dừng ở PoC khác ở chỗ nào

Từ đây mới là phần chính. Với doanh nghiệp đang cân nhắc triển khai RAG, mối quan tâm lớn nhất là khoản tiền bỏ ra có đi được tới vận hành thật hay không.

Hai dự báo của Gartner cho thấy cái bẫy nằm ở đâu

Trong thông cáo báo chí ngày 29 tháng 7 năm 2024, Gartner dự báo rằng ít nhất 30% dự án AI tạo sinh sẽ bị từ bỏ sau bước PoC, tức chứng minh khái niệm, trước cuối năm 2025. Nguyên nhân của việc từ bỏ được nêu ra là một trong các yếu tố sau, gồm chất lượng dữ liệu thấp, kiểm soát rủi ro không đầy đủ, chi phí phình to, và giá trị kinh doanh không rõ ràng.

Tiếp đó, trong thông cáo báo chí ngày 26 tháng 2 năm 2025, Gartner đưa ra một dự báo có trọng tâm hẹp hơn. Nội dung là đến năm 2026, các doanh nghiệp sẽ từ bỏ 60% những dự án AI không được chống đỡ bởi dữ liệu ở trạng thái sẵn sàng cho AI. Điều không được bỏ sót ở đây là dự báo này không nói rằng 60% toàn bộ dự án AI sẽ thất bại. Đối tượng bị giới hạn ở những dự án “không được chống đỡ bởi dữ liệu đã được chuẩn bị tới trạng thái dùng được cho AI”. Chính mệnh đề giới hạn đó mới là giá trị thực dụng của dự báo này.

Cũng trong thông cáo đó, một khảo sát thực hiện quý 3 năm 2024 với 248 người phụ trách quản trị dữ liệu cho thấy 63% tổ chức trả lời rằng họ không có thực hành quản trị dữ liệu phù hợp cho AI, hoặc không rõ mình có hay không. Nói cách khác, cứ 3 công ty thì 2 công ty không nắm được dữ liệu của chính mình có đang ở trạng thái dùng được cho AI hay không.

Số liệu đo thực tế của Canon IT Solutions cho thấy thủ phạm không phải LLM

Chỉ có dự báo thì khó hình dung, nên hãy nhìn vào dữ liệu công bố của một doanh nghiệp Nhật Bản đã thực sự triển khai RAG trong nội bộ. Canon IT Solutions đã công bố dưới dạng báo cáo kỹ thuật kết quả vận hành thử nghiệm RAG tại trung tâm hỗ trợ dành cho nhân viên. Cách làm là đưa thẳng nội dung các câu hỏi thực tế vào hệ thống rồi để người phụ trách chấm điểm xem có nhận được câu trả lời hữu ích hay không, và tổng cộng 228 trường hợp đã được đánh giá.

Kết quả khá thẳng thắn. Số câu được đánh giá “Good” chỉ dừng ở khoảng một phần ba tổng số. Điều đáng chú ý nằm ở bước tiếp theo, khi cơ cấu nguyên nhân của các đánh giá “Bad” được công bố.

Chúng tôi cho rằng bảng này là con số đầu tiên mà mọi doanh nghiệp đang cân nhắc triển khai RAG nên xem. Trong số nguyên nhân của các câu trả lời tệ, phần bắt nguồn từ chính AI tạo sinh chỉ chiếm 12%. 88% còn lại bắt nguồn từ việc tài liệu gốc thiếu hoặc chưa được chỉnh trang, và từ việc không tìm ra được tài liệu cần thiết. Nghĩa là vùng mà tư duy “cứ đổi sang một LLM thông minh hơn thì sẽ tốt lên” không với tới được lại lớn hơn hẳn.

Việc ở phần trước chúng tôi mô tả RAG là cơ chế hai tầng gồm truy xuất và sinh nội dung phát huy tác dụng ngay tại đây. Bức tranh là tầng một, tức truy xuất, cùng với trạng thái tài liệu nằm ngay trước nó, đang nắm giữ thành bại của toàn bộ hệ thống, trong khi tầng hai, tức sinh nội dung, gần như không phải vấn đề. Đây là kết quả vận hành thử của một công ty nên không nhất thiết áp dụng nguyên vẹn cho doanh nghiệp bạn, nhưng nếu phân bố ở doanh nghiệp bạn xấp xỉ như vậy thì một bản đề xuất lấy hiệu năng mô hình và số lượng tham số làm trung tâm chỉ đang nhắm vào hơn một phần mười nguyên nhân. Ghi nhớ điều này như một góc nhìn khi tiếp nhận đề xuất thì không thừa.

Ranh giới 1 | Quyết định “chỉnh trang dữ liệu sau” là đã thua ngay từ thời điểm đó

Yếu tố lớn nhất phân tách công ty dừng ở PoC với công ty tiến tới vận hành thật là thái độ đối với chất lượng dữ liệu. Trong bài viết hệ thống hóa các nguyên nhân thất bại khi triển khai RAG, AQUA LLC chỉ ra rằng khâu chuẩn bị dữ liệu chiếm từ 40% đến 60% khối lượng công việc của toàn dự án, vậy mà nhiều tổ chức lại đánh giá thấp phần này.

Cụ thể thì những trạng thái sau đây sẽ trở thành vấn đề. Cùng một quy định nhưng cả bản cũ lẫn bản mới đều còn nằm trên máy chủ, và công cụ truy xuất nhặt đúng bản cũ. File PDF chỉ được quét ảnh nên không chứa thông tin ký tự, thậm chí không trở thành đối tượng tìm kiếm được. Tài liệu chỉ có bảng biểu mà không có câu chữ giải thích, nên nhìn vào mảnh trích xuất ra thì không hiểu đó là bảng gì. Tài liệu viết bằng các từ viết tắt mà chỉ người phụ trách mới hiểu, khiến từ vựng không khớp với câu hỏi của người dùng. Trong thư mục dùng chung mà không ai cập nhật, quy trình đã bị bãi bỏ từ 3 năm trước vẫn còn nằm nguyên ở đó.

Đây không phải những vấn đề mà kỹ thuật RAG giải quyết được. Hơn nữa chúng không lộ ra ở giai đoạn PoC. Lý do là trong PoC, phạm vi tài liệu được thu hẹp còn vài chục bản, và riêng vài chục bản đó được con người chỉnh trang trước khi nạp vào, nên độ chính xác trông rất đẹp. Vậy mà ngay khoảnh khắc nạp vài nghìn bản vào bản chạy thật, toàn bộ những vấn đề trên bùng lên cùng lúc và độ chính xác sụp đổ. Đây chính là lộ trình điển hình của việc PoC thành công còn bản thật thất bại.

Đối sách rất đơn giản. Khi chọn tài liệu cho PoC, hãy cố ý trộn lẫn “tài liệu đã chỉnh trang” với “tài liệu nạp vào nguyên trạng”. Nếu đo được ngay trong PoC rằng nhóm tài liệu nguyên trạng kéo lùi kết quả tới mức nào, bạn sẽ có dữ liệu để ước lượng khối lượng công việc chỉnh trang dữ liệu cho bản chạy thật. Nếu gặp nhà cung cấp đưa ra báo giá bản thật mà không đo phần này, báo giá đó chắc chắn sẽ phình ra về sau.

Ranh giới 2 | Phình phạm vi bắt đầu từ cụm từ “triển khai toàn công ty”

Ranh giới thứ hai là sự mở rộng không giới hạn của phạm vi đối tượng. Ban đầu lẽ ra chỉ giới hạn ở FAQ của bộ phận hệ thống thông tin, rồi giữa chừng quy định nhân sự được thêm vào, kế đến là sổ tay chất lượng, rồi bộ phận kinh doanh đề nghị đưa cả các bản đề xuất cũ vào, và cuối cùng thành “toàn bộ tài liệu nội bộ”.

Khi phạm vi mở rộng, ba chuyện xảy ra đồng thời. Trước hết, càng nhiều chủng loại tài liệu thì khối lượng công việc chỉnh trang càng tăng nhanh hơn mức tuyến tính. Tiếp theo, vì quyền xem khác nhau theo từng bộ phận nên phải hiện thực hóa cả phần quản lý phân quyền. Và cuối cùng, tiêu chí đánh giá trở nên mơ hồ. Khi đối tượng lên tới 10 nghiệp vụ, bạn không đo được nghiệp vụ nào cải thiện bao nhiêu, và trở nên không giải thích được hiệu quả. Dự án không giải thích được hiệu quả thì không có ngân sách cho năm tiếp theo.

Trong các lý do từ bỏ mà Gartner nêu, “chi phí phình to” và “giá trị kinh doanh không rõ ràng” trong phần lớn trường hợp xuất hiện như hệ quả của việc phình phạm vi. Cách chắc chắn nhất để ghìm chi phí là ngay từ đầu không nhắm tới triển khai toàn công ty, mà làm PoC trên một hoặc hai nghiệp vụ, xác nhận hiệu quả rồi mới mở rộng.

Ranh giới 3 | Không đưa hệ thống vào chạy thật khi chưa chốt bộ máy vận hành

Điểm thứ ba là bộ máy sau khi hệ thống chạy. RAG không phải cơ chế làm xong là hết việc. Tài liệu được cập nhật thì phải nạp lại, phải có công việc thu thập những câu hỏi hệ thống không trả lời được để bổ sung tài liệu, và phải có công việc nhìn đánh giá của người dùng để điều chỉnh cấu hình truy xuất.

Theo phần hệ thống hóa của AQUA LLC đã nhắc ở trên, chi phí vận hành hằng năm cần được dự trù ở mức khoảng 15% đến 25% chi phí phát triển ban đầu. Quan trọng hơn con số tiền là việc chốt trước khi chạy xem ai sẽ làm công việc này. Nếu dựng theo kiểu người kiêm nhiệm ở bộ phận hệ thống thông tin sẽ làm “khi nào rảnh”, thì sau 3 tháng việc cập nhật sẽ dừng lại. Một hệ thống RAG đã ngừng cập nhật sẽ biến thành cơ chế nguy hiểm hơn cả trước khi triển khai, vì nó trả lời thông tin cũ với giọng điệu đầy tự tin.

Lời giải thực tế khi chốt người vận hành là giao trách nhiệm cập nhật cho chính bộ phận sở hữu tài liệu, còn bộ phận hệ thống thông tin chỉ đảm nhận việc duy trì cơ chế. Nếu quy ước rằng khi quy định nhân sự thay đổi thì phòng nhân sự nạp lại, thì về mặt cấu trúc, tình trạng chậm cập nhật sẽ khó xảy ra hơn nhiều.

Tự xác định doanh nghiệp mình đang ở phía nào

Chúng tôi chuyển ba ranh giới trên thành dạng có thể tự kiểm tra trước khi viết tờ trình. Hãy đọc theo cách này, nếu đúng với cột bên trái thì có triển vọng đi tới vận hành thật, còn nếu đúng với cột bên phải thì khả năng cao sẽ dừng lại ở PoC.

Nếu trong 6 hạng mục mà có từ 3 hạng mục trở lên rơi vào cột phải, thì trước khi lấy báo giá RAG, bắt đầu bằng việc xử lý dứt điểm những hạng mục đó sẽ về đích nhanh hơn. Đặc biệt 3 dòng đầu là bài tập của chính doanh nghiệp bạn, chọn nhà cung cấp nào cũng không giải quyết được.

Mức chi phí triển khai RAG năm 2026 | Khoảng giá và ba yếu tố làm báo giá dịch chuyển

Để phán đoán đầu tư, bạn cần nắm không chỉ tổng số tiền mà cả “cái gì làm số tiền dịch chuyển”. Chỉ khi hiểu được các yếu tố dịch chuyển thì việc so sánh báo giá giữa các nhà cung cấp mới có ý nghĩa.

Khoảng giá theo quy mô

Mức giá chia theo giai đoạn, dựa trên số liệu GXO công bố, là PoC từ 1,000,000 đến 3,000,000 yên trong 2 đến 6 tuần, xây dựng bản chạy thật từ 3,000,000 đến 10,000,000 yên trong 2 đến 4 tháng, và vận hành hằng tháng từ 100,000 đến 500,000 yên. Cách nhìn phân rã chi tiết hơn theo từng tầng của cơ cấu giai đoạn đã được xử lý tại Chi phí và cách triển khai hệ thống RAG, nên ở đây chúng tôi đặt một lát cắt khác gắn trực tiếp với phán đoán đầu tư, là mức giá theo quy mô do Root Team công bố. Khi quyết định doanh nghiệp mình nhắm tới giai đoạn nào, cách phân loại này hẳn sẽ dễ dùng hơn.

Đặt hai bộ số liệu cạnh nhau, khoảng giá của PoC và của xây dựng bản thật về cơ bản trùng nhau, trong khi phí vận hành hằng tháng lệch hẳn khoảng, với GXO là 100,000 đến 500,000 yên còn Root Team là 200,000 đến 800,000 yên. Đây là khác biệt về định nghĩa xem cái gì được tính vào vận hành, nên khi lấy báo giá, hãy xác nhận “trong phí bảo trì có những công việc nào” trước cả khi nhìn số tiền. Xin lưu ý cả hai đều là mức tham chiếu do chính các công ty phát triển công bố, không phải khảo sát thị trường của bên thứ ba độc lập. Bản thân việc báo giá của doanh nghiệp bạn nằm ngoài khoảng này không phải vấn đề, điều quan trọng là bạn có giải thích được lý do nằm ngoài hay không.

Điểm cần lưu ý là bản thật đầy đủ trên thực tế không có trần. Cách viết từ 15,000,000 yên trở lên hàm ý rằng con số có thể tăng không giới hạn tùy theo số lượng hệ thống cần tích hợp và độ phức tạp của quản lý phân quyền. Chính Root Team cũng hệ thống hóa rằng để ghìm chi phí thì đừng nhắm tới triển khai toàn công ty ngay từ đầu, mà hãy xác nhận hiệu quả bằng một PoC nhỏ rồi mới mở rộng phạm vi.

Phần lớn chi phí không nằm ở mô hình mà nằm ở dữ liệu và giao diện

Quan trọng hơn khoảng giá là cấu trúc của bảng phân tích chi phí. GXO đã công bố ví dụ phân tích theo từng hạng mục chi phí cho một PoC quy mô nhỏ nhắm vào việc tra cứu FAQ của bộ phận hệ thống thông tin. Phần phân tích số tiền cụ thể và cách nó tích lũy qua từng giai đoạn xây dựng bản thật và vận hành xin nhường lại cho Chi phí và cách triển khai hệ thống RAG, còn ở đây chúng tôi chỉ rút ra tỷ trọng cấu thành vì nó gắn trực tiếp với phán đoán đầu tư.

Điểm mấu chốt của bảng phân tích này là phí sử dụng API của LLM chỉ chiếm 2% tổng chi phí. Dư luận thường tập trung vào việc dùng mô hình nào, nhưng ít nhất với cơ cấu chi phí này thì lựa chọn mô hình gần như không ảnh hưởng tới số tiền. Hạng mục lớn nhất là chỉnh trang dữ liệu, và nếu cộng thêm đánh giá độ chính xác thì trong ví dụ phân tích này, 58% tổng chi phí được dùng cho việc chỉnh trang dữ liệu và đo xem nó hiệu quả tới đâu. Đây là cấu trúc nhất quán với ranh giới 1 ở phần trước.

Khi nhận được báo giá, trước tiên hãy đối chiếu với tỷ lệ này. Bản báo giá có hạng mục chỉnh trang dữ liệu nhỏ bất thường, hoặc ghi rằng “phần dữ liệu xin quý khách tự chuẩn bị”, thì dù tổng số tiền trông rẻ, phần chênh lệch đó sẽ phát sinh về sau dưới dạng chi phí nhân sự của chính doanh nghiệp bạn.

Ba yếu tố làm báo giá dịch chuyển

Cùng là “xây dựng bản thật 5,000,000 yên”, nhưng nếu tiền đề khác nhau thì ý nghĩa hoàn toàn khác. Khi lấy báo giá so sánh, hãy cố định ba điểm sau từ phía bên đặt hàng và bắt các nhà cung cấp báo giá trên cùng một điều kiện. Không thống nhất chỗ này thì bản thân việc so sánh số tiền không còn ý nghĩa.

• Số lượng và định dạng tài liệu đối tượng. Giữa một báo giá lấy tiền đề 100 bản và một báo giá lấy tiền đề 1,000 bản, khối lượng công việc chỉnh trang dữ liệu chênh nhau tới cả bậc số. Hãy nhất định truyền đạt cả tỷ lệ PDF quét ảnh.
• Có cần quản lý phân quyền hay không. Chức năng kiểm soát việc ai được tìm kiếm tài liệu nào thường không xuất hiện như một hạng mục chi phí trong ví dụ phân tích PoC, mà theo thông lệ chỉ nổi lên ở bản chạy thật. Nếu xử lý tài liệu chứa thông tin nhân sự hoặc điều kiện giao dịch thì không thể lược bỏ. Chỉ riêng việc có hay không hạng mục này đã tạo ra chênh lệch từ vài trăm nghìn đến hàng triệu yên.
• Cách tích hợp vào hệ thống hiện có. Việc làm mới một màn hình chuyên dụng hay đưa lên cổng thông tin nội bộ và ứng dụng chat nghiệp vụ sẵn có sẽ làm chi phí phát triển giao diện dịch chuyển rất mạnh. Đây là hạng mục còn nhiều dư địa thương lượng nhất trong ba yếu tố.

Mốc khối lượng công việc để việc thu hồi vốn trở nên khả thi

Chúng tôi không khuyến khích chép nguyên bản tính toán của nhà cung cấp vào tờ trình. Lý do là các tiền đề của khoản tiết kiệm, gồm “mỗi lượt rút ngắn được bao nhiêu phút”, “mỗi tháng có bao nhiêu lượt” và “đơn giá thời gian đó là bao nhiêu”, khác nhau rất lớn giữa các doanh nghiệp. Ngay cả trong các ví dụ tính toán được công bố, năm đầu tiên cũng được ước lượng theo cách phân bổ với giả định bản thật chạy từ tháng thứ 6, chứ không áp thẳng khoản tiết kiệm hằng năm ở trạng thái ổn định vào năm đầu.

Về mặt thực hành, hãy nắm trước ba con số sau của chính doanh nghiệp mình rồi mới tính lại. Đó là số lượt mỗi tháng của nghiệp vụ đối tượng, thời gian xử lý trung bình hiện tại cho mỗi lượt, và đơn giá theo giờ của người xử lý. Có ba con số này thì dù đặt tỷ lệ cắt giảm là bao nhiêu phần trăm, bạn vẫn đưa ra được thời gian thu hồi vốn dưới dạng một khoảng.

Giả sử một lượt hỏi đáp mất 20 phút và do nhân sự có đơn giá 3,000 yên mỗi giờ xử lý. Nếu RAG rút ngắn thời gian xử lý được 30%, thì khoản tiết kiệm cho mỗi lượt là phần tương ứng 30% của 20 phút, tức 6 phút, nghĩa là 300 yên. Lấy mốc 300 yên này làm trục, bạn tính ngược ra được khối lượng công việc cần thiết. Về phía đầu tư, chúng tôi đặt mức nặng nhất trong các khoảng giá theo quy mô nêu trên, tức bản thật đầy đủ với triển khai toàn công ty và tích hợp nhiều hệ thống. Đầu tư ban đầu lấy khoảng giữa của khoảng từ 5,000,000 đến 15,000,000 yên, tức 10,000,000 yên, còn chi phí vận hành hằng năm lấy mức thiên về cận dưới của khoảng bảo trì vận hành 200,000 đến 800,000 yên mỗi tháng, là 400,000 yên mỗi tháng, tức 4,800,000 yên cho 12 tháng. Số tiền đầu tư cho trường hợp bắt đầu nhỏ theo từng bước đã được sắp xếp thành 3 giai đoạn gồm PoC, xây dựng bản thật và vận hành tại Chi phí và cách triển khai hệ thống RAG, nên hãy theo cùng quy trình đó để đặt lại cho quy mô của doanh nghiệp bạn.

Với cách đặt này, chi phí vận hành hằng năm 4,800,000 yên tương ứng 48% của khoản đầu tư ban đầu 10,000,000 yên, vượt xa mốc tham chiếu 15% đến 25% mà AQUA LLC nêu ở trên. Nghĩa là khi lấy tiền đề triển khai toàn công ty thì dù chọn cận dưới của khoảng phí vận hành, tỷ lệ vẫn ra như vậy. Chi phí vận hành thực tế sẽ lên xuống theo số lượng tài liệu đối tượng và tần suất cập nhật. Khi tự tính toán, hãy đưa ra 2 phương án với giả định phí vận hành cao và thấp khác nhau, phán đoán sẽ ít bị dao động hơn.

Điều bảng trên cho thấy là một thực tế, rằng nếu đầu tư ở quy mô triển khai toàn công ty, thì với nghiệp vụ có số lượt hỏi đáp không đạt tới 1,330 lượt mỗi tháng, riêng việc cắt giảm thời gian thậm chí không bù nổi chi phí vận hành hằng năm. Nếu hạ quy mô nhắm tới thì số lượt cần thiết cũng giảm theo tỷ lệ, nên hãy đặt lại theo khoảng mà doanh nghiệp bạn thực tế có thể chọn rồi mới đọc. Đây không phải kết luận bi quan, mà là tiêu chí ràng buộc đồng thời cả cách chọn nghiệp vụ đối tượng lẫn cách quyết định quy mô đầu tư. Khi số lượt không đủ, có 3 nước đi. Thứ nhất là chọn lại đối tượng sang nghiệp vụ có số lượt lớn. Thứ hai là đánh giá hiệu quả không chỉ bằng việc rút ngắn thời gian mà kết hợp cả những hiệu quả khác như xóa bỏ tình trạng phụ thuộc cá nhân và rút ngắn thời gian làm quen việc của nhân sự mới. Một ví dụ tính toán với tiền đề khác, lấy đề tài là hỗ trợ hỏi đáp nội bộ và cho thấy chỉ riêng việc cắt giảm thời gian xử lý bước một thì khó cân đối thu chi, đã được tổng hợp tại Tự động hóa hỏi đáp nội bộ 2026 và bốn kiểu lệch phiên bản khiến câu trả lời cũ đi. Bài đó đặt thời gian mỗi lượt và đơn giá khác với bài này, nên hãy đọc đối chiếu như 2 mô hình khác nhau. Thứ ba là đưa lên hệ thống hiện có để nén chính chi phí ban đầu và chi phí vận hành xuống.

Những điểm bổ sung mà doanh nghiệp triển khai RAG tại Thái Lan và ASEAN phải bước qua

Tới đây là những nội dung chung cả với Nhật Bản. Khi triển khai tại các cơ sở ASEAN, trong đó có Thái Lan, sẽ có thêm 4 dữ kiện phán đoán. Sắp xếp chúng trước khi viết tờ trình sẽ giảm số vòng đi lại để lấy phê duyệt. Những vấn đề chung cho toàn bộ AI tạo sinh chứ không riêng RAG, như trình độ sử dụng của nhân viên bản địa và mức độ nhất quán với hướng dẫn của công ty mẹ, đã được sắp xếp tại Thất bại khi triển khai AI tạo sinh 2026 và ranh giới tại các cơ sở Thái Lan. Ở đây chúng tôi chỉ giới hạn vào những phán đoán đặc thù của RAG.

Lệch phiên bản của tài liệu đa ngôn ngữ. Tại các nhà máy Nhật Bản ở Thái Lan, việc cùng một nội dung tồn tại bằng tiếng Nhật, tiếng Anh và tiếng Thái mà 3 ngôn ngữ không đồng bộ với nhau là chuyện hết sức bình thường. Chẳng hạn chỉ bản tiếng Nhật là mới nhất còn bản tiếng Thái đã 2 năm tuổi. Vì RAG có xu hướng ưu tiên nhặt tài liệu cùng ngôn ngữ với câu hỏi, nên khi nhân viên người Thái hỏi bằng tiếng Thái, bản cũ có thể được trả về làm căn cứ. Các phán đoán thiết kế như lấy bản ngôn ngữ nào làm bản chuẩn và chèn khâu dịch ở giai đoạn nào chỉ có thể thay đổi ở giai đoạn đầu triển khai. Về cách đưa khâu dịch vào có 3 phương án gồm dịch toàn văn, dịch câu truy vấn và nhúng vector đa ngôn ngữ, mỗi phương án có chi phí ban đầu và gánh nặng cập nhật khác nhau. Phần so sánh này đã được tổng hợp thành bảng tại Chi phí và cách triển khai hệ thống RAG nêu trên, xin hãy đọc qua trước khi làm định nghĩa yêu cầu.

Cửa vào mà nhân viên bản địa thực sự sử dụng. Đội ngũ tổ trưởng tại hiện trường sản xuất nhiều khi không có thói quen mở cổng thông tin nội bộ bằng trình duyệt. Dù bạn có làm hẳn một ứng dụng web chuyên dụng, nếu họ không đi tới được đó thì nó cũng không được dùng. Thứ chắc chắn được mở tại hiện trường là ứng dụng chat dùng hằng ngày, hoặc thiết bị đầu cuối được đặt sẵn tại hiện trường. Chỉ cần dồn cửa vào về phía đó thôi thì tỷ lệ sử dụng đã thay đổi. Ở phần trước chúng tôi có nói chi phí phát triển giao diện là một yếu tố dịch chuyển, và nếu đưa được lên ứng dụng chat sẵn có thì đây là một trong số ít phán đoán mà vừa ghìm được chi phí vừa nâng được tỷ lệ sử dụng, tức chi phí và hiệu quả cùng hướng về một phía.

Nơi đặt dữ liệu và quy định nội bộ. Tại Thái Lan, Luật Bảo vệ dữ liệu cá nhân PDPA đã có hiệu lực, nên khi xử lý tài liệu chứa thông tin cá nhân, bạn cần sắp xếp căn cứ pháp lý cho việc xử lý và cách xử lý việc chuyển dữ liệu ra ngoài lãnh thổ. Thêm vào đó, nếu quy chế quản lý thông tin do công ty mẹ tại Nhật ban hành cũng áp dụng cho các cơ sở nước ngoài, thì không lấy trước cách diễn giải xem theo quy chế đó dữ liệu được phép gửi tới API bên ngoài tới đâu, dự án sẽ bị chặn ngay trước thời điểm vận hành. Một cái bẫy đặc thù của RAG là đối tượng cần kiểm tra không chỉ có bản gốc tài liệu. Bạn cần xác nhận nơi lưu trữ cho cả 4 loại, gồm bản gốc, văn bản được trích xuất từ bản gốc, dữ liệu đã số hóa thành vector để phục vụ truy xuất, và nhật ký sử dụng, và phần sắp xếp này được viết chi tiết tại Chi phí và cách triển khai hệ thống RAG nêu trên. Lựa chọn ở tầng nền tảng, gồm dùng API bên ngoài, đặt mô hình trong môi trường của chính mình, hay dùng kết hợp cả hai, ảnh hưởng lớn tới cả chi phí lẫn độ chính xác, nên đáng để sắp xếp riêng khỏi phần thiết kế RAG. Các trục phán đoán đã được tổng hợp tại Triển khai LLM được quyết định bởi cách sở hữu nền tảng, gồm API, tự vận hành và mô hình lai.

Phân chia vai trò giữa công ty mẹ và cơ sở địa phương. Nếu để công ty mẹ dẫn dắt, kết quả sẽ là một cấu hình lấy tài liệu của công ty mẹ và tiếng Nhật làm tiền đề, không khớp với thực tế công việc tại địa phương. Ngược lại, nếu cơ sở địa phương tự làm một mình, thì sự bất nhất với quy chế quản lý thông tin của công ty mẹ sẽ thành vấn đề về sau và phải làm lại sau khi đã chạy. Về mặt thực hành, dạng phân chia dễ vận hành là nền tảng và quy tắc do công ty mẹ, còn tài liệu đối tượng và vận hành do cơ sở địa phương. Việc chọn tài liệu nào làm đối tượng, ai cập nhật, lấy ngôn ngữ nào làm bản chuẩn thì chỉ cơ sở địa phương mới phán đoán được. Ngược lại, dùng mô hình nào, đặt dữ liệu ở đâu, được đưa ra bên ngoài tới mức nào là các hạng mục thuộc quyền kiểm soát của công ty mẹ. Hãy văn bản hóa ranh giới này trước khi viết tờ trình.

Vạch một ranh giới trước khi mở rộng sang AI tự động hóa nghiệp vụ

Phần lớn doanh nghiệp đã đưa RAG vào đều cân nhắc bước tiếp theo là mở rộng sang AI tự động hóa nghiệp vụ. Ý tưởng là không chỉ tra cứu và trả lời, mà cho hệ thống thực thi luôn cả phần xử lý. Về mặt định hướng thì điều đó tự nhiên, nhưng cần vạch một ranh giới ở giữa.

Trước hết hãy thống nhất về mặt ngôn từ sự khác nhau giữa hai thứ. RAG là cơ chế tra cứu tài liệu nội bộ để trả lời, và vai trò của nó về bản chất chỉ giới hạn ở việc đọc rồi trả lời, chứ không ghi vào hay thực thi. Ngược lại, AI tự động hóa nghiệp vụ thực thi luôn phần xử lý thực tế dựa trên nội dung nó đã phán đoán. Trong nội bộ, cả hai thường bị gộp chung thành “triển khai AI”, nhưng khác biệt này mới thực sự lộ ra sau khi hệ thống chạy.

Khác biệt lộ ra khi có sự cố. Với RAG, dù câu trả lời sai được trả về thì người dùng vẫn còn dư địa để đọc và tự phán đoán. Nếu thêm chức năng thực thi vào đây, phán đoán sai sẽ biến thẳng thành hành động. Nghĩa là phạm vi ảnh hưởng của sai sót thay đổi về mặt chất.

Do đó, thứ tự mở rộng phải là trước hết dùng RAG để đo độ đúng của câu trả lời trong một khoảng thời gian nhất định, xác nhận bằng dữ liệu thực xem loại câu hỏi nào đang đạt độ chính xác đủ tốt, rồi mới thêm chức năng thực thi giới hạn trong phạm vi đó. Việc tiến sang tự động hóa mà không đo độ chính xác chính là thứ tương ứng với “kiểm soát rủi ro không đầy đủ” mà Gartner nói tới.

Tiền đề để giữ được thứ tự này là thiết kế luôn trả về câu trả lời đã dựa trên chỗ nào của tài liệu nào. Bạn không thể đặt chức năng tự động thực thi lên trên một cơ chế không truy được căn cứ. Ví dụ thiết kế cụ thể với đề tài là tài liệu hướng dẫn thiết bị được xử lý tại AI tra cứu tài liệu hướng dẫn 2026 và thiết kế trả về nguồn trích dẫn để ngăn sự cố, và thứ tự ưu tiên nêu ở đó, rằng nguồn trích dẫn quan trọng hơn độ chính xác, cũng là điều kiện cần khi tiến sang tự động hóa nghiệp vụ.

Nhìn vào đâu trong đề xuất khi chọn nhà cung cấp

Cuối cùng, chúng tôi sắp xếp các điểm cần nhìn khi chọn nơi đặt hàng. Đừng đánh giá bằng độ dày của bản đề xuất hay số lượng dự án đã làm, mà bằng cách họ trả lời 5 điểm sau.

Trong 5 điểm này, điểm tạo ra khác biệt lớn nhất là điểm thứ hai. Nhà cung cấp nói được câu “hãy cùng nhau xây bộ câu hỏi để đánh giá” là nhà cung cấp hiểu rằng độ chính xác là một chỉ số đo được. Ngược lại, nếu họ chỉ giải thích được bằng tính từ, thì khi hệ thống chạy rồi mà bị đánh giá là “dùng kém hơn mong đợi”, sẽ không có manh mối nào để cải thiện. Điều này ăn khớp với hạng mục “cách đánh giá” trong bảng tự xác định ở phần trước. Nếu bên đặt hàng phó mặc cho nhà cung cấp khi bản thân chưa chốt cách đánh giá, thì cả hai bên đều không phán đoán được thành bại trong khi chi phí cứ chồng lên.

Xin lưu ý những gì nêu ở đây là cách phân biệt tại thời điểm nhận được bản đề xuất. Danh sách câu hỏi thiên về kỹ thuật để đặt ra trong buổi gặp trực tiếp đã được tổng hợp thành 8 mục tại Chi phí và cách triển khai hệ thống RAG nêu trên, xin dùng khi so sánh sau khi đã thu hẹp còn 2 hoặc 3 ứng viên.

TOMAS TECH có thể hỗ trợ những gì

TOMAS TECH đặt trụ sở tại Bangkok, Thái Lan, chuyên triển khai hệ thống quản lý sản xuất PEGASUS và hỗ trợ ứng dụng AI cho các cơ sở của doanh nghiệp sản xuất Nhật Bản tại Thái Lan và ASEAN. Về RAG, chúng tôi nhận được đề nghị tư vấn ngay từ giai đoạn trước khi quyết định có làm hay không, trong phạm vi sau.

• Cắt nghiệp vụ đối tượng và tính toán thu hồi vốn. Chúng tôi cùng bạn xác nhận nghiệp vụ nào có số lượt và hiệu quả cắt giảm tương xứng với khoản đầu tư, bằng cách điền 3 con số nêu trong bài này bằng dữ liệu thực.
• Khảo sát hiện trạng tài liệu và ước lượng khối lượng công việc chỉnh trang. Chúng tôi đưa ra khối lượng công việc sau khi thực sự xem tỷ lệ PDF quét ảnh, độ lệch giữa các bản ngôn ngữ và tình trạng quản lý phiên bản.
• Thiết kế và đánh giá PoC. Chúng tôi đề xuất cách xây bộ câu hỏi dùng để đánh giá và cách đo có trộn lẫn tài liệu đã chỉnh trang với tài liệu để nguyên trạng.
• Phương châm kết nối với hệ thống hiện có. Nếu bạn đã có hệ thống nắm dữ liệu quản lý sản xuất hoặc dữ liệu thiết bị, chúng tôi sắp xếp cách phân vai giữa hệ thống đó với việc tra cứu tài liệu.
• Sắp xếp phân chia vai trò giữa công ty mẹ và cơ sở địa phương. Chúng tôi văn bản hóa các luận điểm cần cho tờ trình, bao gồm cả tính nhất quán với quy chế quản lý thông tin.

Khác biệt so với các nhà cung cấp trong nước Nhật Bản là chúng tôi có cơ sở tại chỗ và thiết kế trên tiền đề thực tế công việc của hiện trường sản xuất tại Thái Lan. Việc có thể sắp xếp yêu cầu trong khi nhìn cả quy chế của công ty mẹ lẫn thực tế công việc tại địa phương cũng phát huy tác dụng trong các dự án xuyên biên giới.

Câu hỏi thường gặp

RAG là gì và phù hợp với loại câu hỏi nào

RAG là viết tắt của Retrieval-Augmented Generation, tức sinh nội dung có tăng cường truy xuất, là cơ chế trong đó trước khi để AI tạo sinh trả lời, hệ thống tìm và lấy ra các đoạn liên quan từ tài liệu nội bộ, đưa vào làm căn cứ rồi mới cho AI dựng câu trả lời. Loại câu hỏi phù hợp là những câu mà đáp án đã được viết thành văn ở đâu đó trong tài liệu nội bộ, ví dụ diễn giải quy định, xác nhận quy trình, hay tìm lại vụ việc tương tự trong quá khứ. Ngược lại, RAG không giỏi với những câu mà đáp án tồn tại dưới dạng con số trong hệ thống lõi, những câu cần tổng hợp hoặc so sánh xuyên nhiều tài liệu, và tri thức ngầm vốn chưa từng được văn bản hóa. Nếu không chia sẻ ranh giới này trong nội bộ trước khi vào PoC, người dùng sẽ chỉ thử những câu hỏi mà hệ thống không giỏi và điểm đánh giá sẽ đi xuống.

Chi phí triển khai RAG khoảng bao nhiêu

Trong hướng dẫn giá của GXO chia theo giai đoạn tại thời điểm năm 2026, mức của PoC là từ 1,000,000 đến 3,000,000 yên và xây dựng bản thật là từ 3,000,000 đến 10,000,000 yên. Phí vận hành hằng tháng dao động tùy nguồn công bố, với GXO là 100,000 đến 500,000 yên còn Root Team là 200,000 đến 800,000 yên. Theo quy mô thì PoC quy mô nhỏ chuyên vào 1 đến 2 nghiệp vụ là 500,000 đến 2,000,000 yên, bản thật gọn nhẹ cho 1 đến 2 phòng ban có kèm quản lý phân quyền là 3,000,000 đến 5,000,000 yên, và bản thật đầy đủ triển khai toàn công ty có tích hợp nhiều hệ thống là từ 5,000,000 đến 15,000,000 yên trở lên. Trong ví dụ phân tích chi phí PoC được công bố, phí sử dụng API của LLM chỉ chiếm vỏn vẹn 2% tổng chi phí, còn hạng mục lớn nhất là chỉnh trang dữ liệu với 40%. Biết trước cấu trúc rằng phần lớn chi phí không nằm ở mô hình mà nằm ở dữ liệu và giao diện sẽ giúp bạn dễ phán đoán mức hợp lý của báo giá hơn. Phần phân tích số tiền theo từng giai đoạn được tổng hợp trong bài liên quan về chi phí và cách triển khai hệ thống RAG.

Cần xác nhận những gì để không dừng lại ở PoC

Có 3 điểm. Điểm thứ nhất là trạng thái tài liệu đối tượng, hãy nắm trước xem người phụ trách có trả lời ngay được bản nào là mới nhất hay không, và có bao nhiêu file PDF chỉ được quét ảnh. Điểm thứ hai là phạm vi, hãy thu hẹp còn 1 hoặc 2 nghiệp vụ và chốt trước điều kiện thế nào thì mở rộng. Điểm thứ ba là người phụ trách vận hành, hãy chốt trước khi chạy xem bộ phận nào cập nhật cái gì vào lúc nào. Nếu tiến vào PoC khi 3 điểm này còn mơ hồ, bạn sẽ đi đúng lộ trình lãng phí chi phí nhất, là PoC cho kết quả tốt nhưng bản chạy thật thì sụp đổ.

Khi dùng AI tạo sinh với dữ liệu nội bộ thì có lo rò rỉ thông tin không

Điều đó tùy cấu hình. Với cấu hình gửi dữ liệu ra dịch vụ LLM bên ngoài, bạn cần xác nhận trên cả hai mặt hợp đồng và thiết lập về phạm vi dữ liệu được gửi đi, việc bên cung cấp có được dùng dữ liệu để huấn luyện hay không, và nơi lưu trữ. Với cấu hình đặt mô hình trong môi trường của chính mình thì không phát sinh việc gửi ra ngoài, nhưng chi phí ban đầu và gánh nặng vận hành sẽ tăng lên. Nếu vận hành tại Thái Lan, xét từ góc độ Luật Bảo vệ dữ liệu cá nhân PDPA, bạn cũng cần sắp xếp cách xử lý tài liệu chứa thông tin cá nhân và việc chuyển dữ liệu ra ngoài lãnh thổ. Ngoài ra, một luận điểm đặc thù của RAG là phải hiện thực hóa quản lý phân quyền sao cho tài liệu mà người dùng không có quyền xem sẽ không được trả về trong kết quả tra cứu. Chức năng này thường không xuất hiện như một hạng mục chi phí trong ví dụ phân tích PoC mà theo thông lệ chỉ nổi lên ở bản chạy thật, nên khi so sánh báo giá hãy nhất định thống nhất việc có hay không chức năng đó.

Kết luận

Với doanh nghiệp cân nhắc triển khai RAG, phán đoán không được quyết định bởi công nghệ tốt hay dở, mà bởi mức độ sẵn sàng của dữ liệu và của bộ máy vận hành. Gartner dự báo ít nhất 30% dự án AI tạo sinh sẽ bị từ bỏ sau bước PoC trước cuối năm 2025, và dự báo thêm rằng đến năm 2026, 60% những dự án AI không được chống đỡ bởi dữ liệu ở trạng thái sẵn sàng cho AI sẽ bị bỏ dở. Mệnh đề giới hạn đó rất quan trọng, vì Gartner không hề nói rằng các dự án đã chỉnh trang dữ liệu cũng thất bại với cùng xác suất.

Trong 228 trường hợp đo thực tế mà Canon IT Solutions công bố, phần nguyên nhân của các câu trả lời tệ bắt nguồn từ chính AI tạo sinh chỉ dừng ở 12%, còn tài liệu thiếu sót hoặc không đầy đủ chiếm 46% và độ chính xác truy xuất thấp chiếm 42%. Thứ cần nhìn khi phán đoán đầu tư không phải là dùng mô hình nào, mà là tài liệu của chính doanh nghiệp bạn đã được chỉnh trang tới đâu.

Về chi phí, mức của các hướng dẫn giá là PoC từ 1,000,000 đến 3,000,000 yên và xây dựng bản thật từ 3,000,000 đến 10,000,000 yên, còn vận hành hằng tháng dao động từ 100,000 đến 800,000 yên tùy nguồn công bố. Tuy nhiên, quan trọng hơn tổng số tiền là bảng phân tích, và trong ví dụ phân tích chi phí PoC được công bố thì 58% chi phí được dùng cho chỉnh trang dữ liệu và đánh giá độ chính xác, còn phí API của LLM chỉ chiếm 2%. Và việc thu hồi vốn có khả thi hay không được quyết định bởi khối lượng công việc. Với tiền đề mỗi lượt 20 phút, đơn giá 3,000 yên mỗi giờ và tỷ lệ cắt giảm 30%, nếu đặt quy mô triển khai toàn công ty với đầu tư ban đầu 10,000,000 yên và chi phí vận hành hằng năm 4,800,000 yên, thì nếu không vượt khoảng 1,330 lượt mỗi tháng, bạn thậm chí không bù nổi chi phí vận hành hằng năm, và để thu hồi cả khoản đầu tư ban đầu trong 3 năm thì cần khoảng 2,260 lượt mỗi tháng. Thay các con số trong bản tính này bằng số liệu của chính doanh nghiệp bạn chính là công việc đầu tiên trước khi viết tờ trình.

Tại các cơ sở ở Thái Lan và ASEAN, có thêm 4 dữ kiện phán đoán, gồm lệch phiên bản của tài liệu đa ngôn ngữ, cửa vào mà nhân viên bản địa thực sự sử dụng, nơi đặt dữ liệu cùng quy định nội bộ, và phân chia vai trò giữa công ty mẹ với cơ sở địa phương. Tất cả đều là những phán đoán thiết kế chỉ quyết định được ở giai đoạn đầu triển khai, nên hãy sắp xếp chúng trước khi làm định nghĩa yêu cầu.

Về cách bắt đầu, hãy thu hẹp còn một nghiệp vụ có số lượt lớn, làm PoC với tài liệu đã chỉnh trang trộn lẫn tài liệu để nguyên trạng, và nắm bằng con số cả tỷ lệ trả lời đúng lẫn mức hợp lý của nguồn trích dẫn. Chỉ cần thiết kế ban đầu này đúng, thì những phán đoán sau đó sẽ do chính dữ liệu chỉ đường cho bạn.

Nên bắt đầu từ nghiệp vụ nào, tài liệu đang có đã ở trạng thái dùng được cho RAG hay chưa, và xét từ số lượt thì việc thu hồi vốn có khả thi không, những câu trả lời này thay đổi theo khối lượng cùng trạng thái tài liệu và cấu hình hệ thống hiện có. Thông qua việc triển khai hệ thống quản lý sản xuất và hỗ trợ ứng dụng AI tại các nhà máy và cơ sở của doanh nghiệp Nhật Bản ở Thái Lan, TOMAS TECH nhận được nhiều đề nghị tư vấn ngay từ khâu sắp xếp các tiền đề như vậy. Ngay cả khi bạn còn đang ở giai đoạn cân nhắc và chưa chốt định hướng trong nội bộ cũng không sao, xin hãy chia sẻ với chúng tôi các vấn đề hiện tại và nghiệp vụ mà bạn muốn đưa vào phạm vi qua trang liên hệ. Chúng tôi sẽ đồng hành cùng bạn từ những điểm rất cụ thể như cách chọn nghiệp vụ đối tượng và nên đo cái gì trong PoC.

Nguồn tham khảo

• GXO – Mức chi phí và bảng phân tích chi phí triển khai RAG, khoảng giá cho PoC, xây dựng bản thật, vận hành hằng tháng và ví dụ phân tích chi phí PoC giả định doanh nghiệp quy mô 300 nhân viên
• Root Team – Mức chi phí phát triển RAG và các điểm cần lưu ý khi thuê ngoài, chi phí theo quy mô từ PoC nhỏ tới bản thật đầy đủ cùng chi phí bảo trì vận hành
• Gartner – Dự báo ít nhất 30% dự án AI tạo sinh sẽ bị từ bỏ sau PoC trước cuối năm 2025, ngày 29 tháng 7 năm 2024
• Gartner – Dự báo 60% dự án AI không được chống đỡ bởi dữ liệu sẵn sàng cho AI sẽ bị bỏ dở trước năm 2026, cùng con số 63% trong khảo sát 248 người, ngày 26 tháng 2 năm 2025
• Canon IT Solutions – Kết quả đánh giá 228 trường hợp trong vận hành thử RAG nội bộ, cơ cấu nguyên nhân bị đánh giá Bad gồm tài liệu thiếu sót 46%, độ chính xác truy xuất thấp 42% và AI tạo sinh 12%
• AQUA LLC – Hệ thống hóa nguyên nhân thất bại khi triển khai RAG, chuẩn bị dữ liệu chiếm 40 đến 60% khối lượng công việc và chi phí vận hành hằng năm bằng 15 đến 25% chi phí phát triển ban đầu