Xây dựng hệ thống RAG cho nhà máy: chi phí và cách làm 2026

Ban giám đốc yêu cầu đưa AI vào nhà máy, còn bộ phận IT thì muốn AI đọc được sổ tay bảo trì thiết bị và báo cáo sự cố của chính nhà máy mình. Lớp kết nối giữa tài liệu nội bộ và mô hình ngôn ngữ chính là xây dựng hệ thống RAG. Nhưng có một điều nên nói trước: nếu tài liệu cần tra cứu chỉ vài chục tệp thì không xây RAG sẽ nhanh hơn và rẻ hơn. Bài viết đi từ tiêu chí quyết định có nên xây, đến cấu trúc chi phí, cách thiết kế để hỏi bằng tiếng Việt vẫn tra được tài liệu kỹ thuật tiếng Nhật, và những cái bẫy thường gặp.

93% doanh nghiệp Việt Nam đã dùng hoặc cân nhắc AI, nhưng chỉ 13,8% triển khai toàn công ty

Trước khi bàn về kỹ thuật, hãy nhìn vào vị trí hiện tại của doanh nghiệp Việt Nam.

Theo khảo sát của Deloitte, 93% doanh nghiệp Việt Nam đã ứng dụng hoặc đang cân nhắc ứng dụng AI. Đây là tỷ lệ cao nhất Đông Nam Á. Nhưng cũng theo khảo sát này, chỉ 13,8% triển khai được ở quy mô toàn doanh nghiệp. Đây là số liệu về Việt Nam.

Hai con số này cách nhau 79,2 điểm phần trăm. Nói cách khác, trong nhóm đã ứng dụng hoặc đang cân nhắc, chỉ 13,8 chia 93, tức khoảng 15%, đi được tới mức toàn công ty. Phần còn lại dừng ở đâu đó giữa đường: một bản thử nghiệm chạy tốt trong phòng họp, một nhóm nhỏ dùng vài tháng, rồi lặng lẽ không ai mở lại nữa.

Dừng ở giai đoạn thử nghiệm đã trở thành trạng thái bình thường, chứ không phải ngoại lệ. Với AI trong sản xuất, điều này càng rõ. Và nguyên nhân thường không nằm ở mô hình AI. Mô hình nào cũng trả lời trôi chảy. Vấn đề là nó không biết gì về nhà máy của bạn: không biết máy số 3 là loại nào, không biết lỗi E042 năm ngoái đã xử lý ra sao, không biết quy trình thao tác chuẩn vừa được sửa đổi tháng trước. Một trợ lý biết mọi thứ trên internet nhưng không biết gì về nơi mình làm việc thì chỉ hữu ích trong buổi trình diễn.

Khoảng cách giữa 93% và 13,8% được lấp bằng một việc rất cụ thể: nối tài liệu của chính doanh nghiệp vào AI. Đó là toàn bộ nội dung của việc xây dựng hệ thống RAG.

Luật Trí tuệ nhân tạo của Việt Nam có hiệu lực từ tháng 3 năm 2026

Có một yếu tố nữa khiến năm 2026 khác các năm trước. Quốc hội Việt Nam đã thông qua Luật Trí tuệ nhân tạo vào tháng 12 năm 2025 và luật có hiệu lực từ tháng 3 năm 2026. Đây là đạo luật riêng về AI đầu tiên tại Đông Nam Á. Luật đưa ra cơ chế phân loại rủi ro, yêu cầu về trách nhiệm giải trình, và nghĩa vụ quản trị đối với các hệ thống AI có tác động lớn.

Điều này không có nghĩa là một công cụ tra cứu sổ tay nội bộ sẽ bị siết chặt. Nhưng nó có nghĩa là cách bạn thiết kế hệ thống ngay từ đầu sẽ quyết định việc sau này có giải trình được hay không: câu trả lời dựa trên tài liệu nào, ai được xem tài liệu đó, dữ liệu lưu ở đâu. Những nội dung này sẽ quay lại ở phần sau của bài viết.

Về các quy định cụ thể, nghĩa vụ áp dụng cho từng loại hình doanh nghiệp và thủ tục liên quan, hãy xác nhận bằng văn bản với cơ quan quản lý nhà nước có thẩm quyền hoặc chuyên gia tại địa phương. Bài viết này không đi vào chi tiết pháp lý.

Nếu bạn đang ở bước sớm hơn, tức là còn đang chọn nghiệp vụ nào nên đưa AI vào trước và xây dựng bộ máy nội bộ ra sao, hãy xem thêm bài Hướng dẫn triển khai AI tạo sinh và chi phí. Bài viết hiện tại đi sâu vào một lớp cụ thể trong đó: lớp nối dữ liệu của doanh nghiệp với mô hình ngôn ngữ.

Trước khi xây dựng hệ thống RAG, hãy kiểm tra xem có thể không cần xây hay không

Phần lớn bài viết về chủ đề này bắt đầu bằng cách thuyết phục bạn xây. Chúng tôi bắt đầu bằng điều ngược lại: nếu tránh được thì nên tránh.

Anthropic, đơn vị phát triển mô hình ngôn ngữ lớn, đưa ra một ngưỡng rõ ràng trong tài liệu kỹ thuật của họ. Đây là số liệu toàn cầu. Nếu kho tri thức của bạn nhỏ hơn 200.000 token, tương đương khoảng 500 trang tài liệu, thì không cần dựng hệ thống tìm kiếm. Chỉ cần đưa toàn bộ kho tri thức vào prompt của mô hình. Kết hợp với cơ chế bộ nhớ đệm cho prompt, cách này cho phản hồi nhanh hơn, chi phí thấp hơn và không phải xây dựng gì phức tạp.

Lấy 200.000 token chia cho 500 trang được khoảng 400 token một trang. Hãy hình dung bằng tài liệu thật: một cuốn hướng dẫn vận hành thiết bị khổ A4 dày 50 trang, phải có mười cuốn như vậy mới chạm ngưỡng này.

Nghĩa là nếu nhu cầu hiện tại chỉ là “tra được mười quy trình thao tác chuẩn” hoặc “có 30 tệp PDF quy định chất lượng cần hỏi đáp”, thì hợp lý hơn cả là thử phương án đưa thẳng tài liệu vào mô hình, trước khi bỏ tiền vào một dự án nặng.

Một lưu ý về cách quy đổi. Số token tiêu tốn thay đổi theo ngôn ngữ. Tiếng Nhật, tiếng Thái và tiếng Việt có dấu thường tốn nhiều token hơn tiếng Anh cho cùng một nội dung. Con số 500 trang nên được hiểu là ước lượng dựa trên tài liệu tiếng Anh, và với tài liệu tiếng Nhật hay tiếng Việt thì nên trừ hao. Muốn chắc chắn, hãy đưa tài liệu thật qua công cụ đếm token và đo trực tiếp.

Ba điều kiện khiến hệ thống RAG trở nên cần thiết

Vậy khi nào thì thực sự cần xây? Ba điều kiện dưới đây là đủ để quyết định. Chỉ cần rơi vào một điều kiện là việc dựng lớp tìm kiếm đã có giá trị.

1. Khối lượng tài liệu vượt ngưỡng. Đối tượng tra cứu lên tới hàng trăm tệp, hàng nghìn trang. Không thể đưa hết vào prompt, nên phải có cơ chế lấy ra đúng phần cần thiết.
2. Tài liệu được cập nhật thường xuyên. Quy trình thao tác chuẩn sửa hàng tháng, báo cáo sự cố tăng thêm hàng tuần. Khi đó cần một cơ chế mà chỉ thay tài liệu gốc là câu trả lời tự thay đổi theo.
3. Cần phân quyền xem theo người hỏi. Hồ sơ kiểm tra chỉ bộ phận chất lượng được xem, bảng đơn giá chỉ bộ phận mua hàng được xem. Việc giới hạn phạm vi tra cứu theo từng người chỉ có thể làm ở lớp tìm kiếm.

Điều kiện thứ ba hay bị bỏ qua nhưng trên thực tế lại nặng nhất. Nếu toàn bộ nhân viên đều được xem mọi tài liệu thì thiết kế rất đơn giản. Nhưng trong nhà máy có vốn đầu tư Nhật Bản, thực tế vẫn tồn tại những tài liệu mà chuyên gia người Nhật được xem còn nhân viên người Việt thì không, hoặc ngược lại, những tài liệu chỉ lưu hành trong nội bộ một xưởng. Có hay không nhu cầu phân quyền sẽ làm thay đổi đáng kể chi phí được nói tới ở phần sau.

RAG là gì: ba bước tìm kiếm, ghép ngữ cảnh và sinh câu trả lời

RAG là viết tắt của Retrieval-Augmented Generation, có thể hiểu là “sinh câu trả lời có tăng cường bằng tìm kiếm”. Đây là cách phổ biến nhất để triển khai LLM cho doanh nghiệp, trong đó LLM là tên gọi tắt của mô hình ngôn ngữ lớn. Cơ chế chỉ gồm ba bước.

Bước một là tìm kiếm. Hệ thống nhận câu hỏi của người dùng và tìm trong kho tài liệu nội bộ những phần có khả năng liên quan. Trước đó, tài liệu đã được cắt thành các đoạn có độ dài vừa phải và được lưu dưới dạng vector nhúng, tức là biểu diễn bằng số của ý nghĩa. Câu hỏi cũng được chuyển thành vector theo cùng cách, rồi hệ thống lấy ra những đoạn gần nghĩa nhất.

Bước hai là ghép ngữ cảnh. Các đoạn vừa lấy ra được gửi kèm câu hỏi tới mô hình ngôn ngữ, theo dạng “hãy tham khảo các tài liệu sau và trả lời câu hỏi này”.

Bước ba là sinh câu trả lời. Mô hình soạn câu trả lời trong phạm vi tài liệu được đưa, kèm theo chỉ dẫn về việc đã dựa vào tài liệu nào, đoạn nào.

Điểm quan trọng nhất: theo cách này, mô hình không hề “thuộc” tài liệu nội bộ của bạn. Nó chỉ tra cứu tại chỗ mỗi lần được hỏi. Chính vì vậy, sửa tài liệu là sửa được câu trả lời. Thay bản quy trình thao tác chuẩn đã sửa đổi vào kho, hôm sau hệ thống trả lời theo quy trình mới.

Khác biệt với việc tinh chỉnh mô hình

Nghe tới “cho AI học dữ liệu nội bộ”, nhiều người nghĩ ngay tới tinh chỉnh mô hình. Ba phương án có thể so sánh như sau.

Với mục tiêu tra cứu tài liệu nội bộ, tinh chỉnh mô hình không phải lựa chọn hợp lý. Dùng nó để ghi nhớ dữ kiện thì chi phí cập nhật quá cao, và quan trọng hơn, mô hình sẽ không chỉ ra được đã dựa vào tài liệu nào. Trong nhà máy, việc nêu căn cứ là bắt buộc. Vì vậy cách phân vai thực tế là: tra cứu dữ kiện dùng RAG, thống nhất văn phong dùng câu lệnh hướng dẫn.

Việc nào trong nhà máy hợp với RAG và việc nào không

Một trong những nguyên nhân thất bại phổ biến là gán hệ thống vào nghiệp vụ vốn không hợp với nó. Một hệ thống tìm kiếm tài liệu nội bộ bằng AI không thay thế được mọi công cụ đang có trong nhà máy. Hãy vạch ranh giới ngay từ đầu.

Những việc hợp: khi câu trả lời nằm trong tài liệu

• Tra cứu sổ tay bảo trì thiết bị. Ví dụ, tìm bước xử lý ban đầu khi một mã máy chiết rót cụ thể báo lỗi E042, tra ngang qua nhiều cuốn hướng dẫn của nhiều nhà sản xuất khác nhau.
• Tra cứu chéo báo cáo sự cố và lỗi sản phẩm cũ. Cùng một dạng lỗi, các năm trước đã xử lý ra sao. Đây là cách khai thác lại kinh nghiệm vốn chỉ nằm trong đầu vài người.
• Hỏi đáp quy trình thao tác chuẩn và quy định nội bộ. Thời hạn xin nghỉ phép, thủ tục mang dụng cụ ra khỏi xưởng. Những câu mà đọc quy định là biết nhưng không ai chịu đọc.
• Xác nhận thông số linh kiện và bản vẽ. Vật liệu, dung sai, có được dùng linh kiện thay thế hay không. Đây là dạng tìm kiếm tài liệu kỹ thuật bằng AI mang lại hiệu quả rõ nhất, vì thông tin có sẵn trong tài liệu nhưng nằm rải rác.
• Soạn bản nháp trả lời câu hỏi kỹ thuật của khách hàng. Dựa trên dữ liệu thực tế của các lần trả lời trước và tài liệu kỹ thuật, tạo bản nháp để người phụ trách kiểm tra rồi mới gửi đi.

Nhóm nghiệp vụ này là phần lõi của quản lý tri thức nhà máy: tri thức tồn tại dưới dạng văn bản, nhưng nằm rải rác đến mức không ai tra nổi.

Những việc không hợp: khi câu trả lời là con số hoặc trạng thái hiện tại

• Tổng hợp sản lượng và tồn kho. “Tỷ lệ vận hành từng chuyền tháng trước”, “tồn kho linh kiện hiện tại” là con số trong cơ sở dữ liệu chứ không phải văn bản. Đây là phần việc của hệ thống quản lý sản xuất và công cụ báo cáo. Hỏi RAG những câu này là tự tạo ra câu trả lời sai. Về việc chọn công cụ lập kế hoạch và điều độ sản xuất, xem thêm bài so sánh các hệ thống lập kế hoạch sản xuất.
• Trạng thái thiết bị theo thời gian thực. “Máy số 3 đang chạy hay đang dừng” là việc của hệ thống giám sát. Về cách thu tín hiệu từ thiết bị và trực quan hóa, xem bài triển khai giám sát vận hành nhà máy bằng IoT.
• Bản thân việc ghi chép và phê duyệt. Nộp báo cáo ca, lưu phiếu kiểm tra là việc của luồng công việc. Nếu nhà máy vẫn dùng biểu mẫu giấy, thì đúng thứ tự là làm số hóa biểu mẫu và giảm giấy tờ trong nhà máy trước đã.

Nguyên tắc phân định chỉ có một. Nếu câu trả lời tồn tại dưới dạng câu chữ trong tài liệu thì dùng RAG; nếu câu trả lời là con số nằm trong hệ thống thì dùng công cụ báo cáo hoặc hệ thống nghiệp vụ. Không làm rõ điều này ngay từ đầu, kết cục sẽ là nhận xét quen thuộc: “AI gì mà hỏi tồn kho cũng không biết”.

Chi phí xây dựng hệ thống RAG nên được chia thành năm lớp

Đây là phần lõi của bài viết. Nhìn một bản báo giá gộp thì không thể quyết định được điều gì. Nhưng nếu tách thành năm lớp dưới đây, bạn sẽ thấy ngay lớp nào sẽ phình to trong trường hợp của mình.

Vì sao lớp 1 thường là lớp tốn kém nhất trong nhà máy

Các bài viết phổ thông về RAG thường bắt đầu từ lớp 2, tức cơ sở dữ liệu vector và vector nhúng. Thực tế nhà máy thì khác. Tài liệu cần tra cứu vốn dĩ chưa ở dạng có thể tìm kiếm được.

Sổ tay bảo trì là tập giấy đóng bìa do nhà sản xuất thiết bị bàn giao. Bản vẽ là PDF quét, bên trong là ảnh chứ không phải chữ. Báo cáo sự cố cũ bị nhét vào ô của tệp bảng tính, kèm ảnh dán chồng lên. Hồ sơ chất lượng là biểu mẫu viết tay đem đi quét. Rất nhiều nhà máy xuất phát từ đúng trạng thái này.

RAG tìm kiếm trên chữ, nên PDF ở dạng ảnh không nằm trong phạm vi tìm kiếm. Ở đây cần bước nhận dạng ký tự để chuyển ảnh thành văn bản. Việc bảo đảm độ chính xác khi đọc biểu mẫu viết tay có lẫn tiếng Nhật và tiếng Việt tự nó đã đủ lớn để thành một dự án riêng. Về bước tiền xử lý này, xem thêm bài tự động hóa khối văn phòng bằng AI-OCR.

Chuyển xong thành chữ vẫn chưa hết việc. Cùng một thiết bị nhưng có ba đời sổ tay khác nhau, không ai biết bản nào đang có hiệu lực. Lịch sử sửa đổi nằm lẫn trong nội dung, quy trình cũ và quy trình mới cùng nằm trong một tệp. Những việc này thuê ngoài cũng không xong, vì chỉ người của chính doanh nghiệp mới quyết định được tài liệu nào còn hiệu lực.

Ước lượng lớp 1 bằng bội số của đơn giá giờ công

Vì mặt bằng giá dịch vụ tại Việt Nam thay đổi theo khu vực và theo nhà cung cấp, cách ước lượng an toàn hơn là quy về giờ công. Gọi đơn giá giờ công nội bộ của doanh nghiệp là W. Khi đó chi phí lớp 1 được biểu diễn bằng bội số của W, và bạn chỉ cần thay W bằng con số thật của mình.

Giả định một nhà máy có 300 tài liệu cần đưa vào, trung bình 40 trang mỗi tài liệu, tổng cộng 12.000 trang.

Chi phí lớp 1 trong kịch bản này là 765 nhân W. Quy sang thời gian: 765 giờ chia 8 giờ mỗi ngày bằng khoảng 96 ngày công. Nếu bố trí hai người chuyên trách, mỗi người mất 48 ngày làm việc, tức khoảng hai tháng theo lịch 22 ngày làm việc mỗi tháng.

Con số này nhạy cảm nhất với dòng thứ hai. Giả sử 80% số trang đã ở dạng văn bản số và chỉ 2.400 trang cần hiệu đính, dòng đó giảm từ 600 giờ xuống 120 giờ, tổng còn 285 giờ, tức khoảng 37% so với kịch bản đầu. Nói cách khác, mức độ số hóa sẵn có của tài liệu quyết định gần như toàn bộ chi phí lớp 1. Đây cũng là lý do nên đo trước tỷ lệ này rồi mới lập ngân sách.

Xin nhấn mạnh: các định mức trong bảng là giả định để minh họa cách tính, không phải số liệu khảo sát. Hãy thay bằng kết quả đo thử trên 10 tài liệu thật của nhà máy mình trước khi đưa vào tờ trình.

Mặt bằng giá tại thị trường Nhật Bản, dùng để đọc cấu trúc chi phí

Không có số liệu công bố về mặt bằng giá xây dựng hệ thống RAG tại Việt Nam mà chúng tôi có thể trích dẫn. Vì vậy, phần dưới đây dùng số liệu của Nhật Bản, và mục đích không phải để bạn áp giá, mà để đọc ra tỷ lệ giữa các hạng mục. Đây là giá tại thị trường Nhật Bản, không phải mặt bằng giá tại Việt Nam.

Nguồn này còn công bố chi tiết theo từng khoản. Điểm đáng chú ý là cộng ba khoản được nêu tên lại vẫn không chạm tới tổng giá.

Kiểm lại phép cộng. Ở bước thử nghiệm, cận dưới là 300.000 cộng 100.000 cộng 200.000 bằng 600.000 yên; cận trên là 500.000 cộng 100.000 cộng 500.000 bằng 1,1 triệu yên. Ở bước chính thức, cận dưới là 1 triệu cộng 600.000 cộng 500.000 bằng 2,1 triệu yên; cận trên là 1,5 triệu cộng 600.000 cộng 2 triệu bằng 4,1 triệu yên. Đối chiếu với tổng giá 1 đến 3 triệu yên và 3 đến 10 triệu yên, phần chênh lệch là 400.000 đến 1,9 triệu yên ở bước thử nghiệm, và 0,9 đến 5,9 triệu yên ở bước chính thức.

Phần chênh lệch đó là gì? Là khảo sát yêu cầu, quản lý dự án, và lớp 4, tức kết nối hệ thống hiện có cùng thiết kế phân quyền truy cập. Ở bước xây dựng chính thức, nếu lấy cận trên thì riêng phần này đã chiếm hơn một nửa tổng giá, cụ thể 5,9 trên 10. Hãy ghi nhớ cấu trúc đó: cơ sở dữ liệu vector 600.000 yên, còn phân quyền và kết nối thì hơn thế nhiều lần.

Mặt bằng giá toàn cầu

Số liệu toàn cầu về chi phí phát triển RAG được công bố như sau, tính bằng đô la Mỹ. Nguồn không nêu tỷ giá nên chúng tôi không quy đổi.

Chia thử ở cả hai đầu dải. RAG chạy chính thức gấp khoảng 2,7 đến 3,2 lần RAG đơn giản: cận dưới 40.000 chia 15.000 bằng khoảng 2,7 lần, cận trên 80.000 chia 25.000 bằng 3,2 lần. RAG doanh nghiệp triển khai tại chỗ lại gấp khoảng 1,9 đến 2,0 lần RAG chạy chính thức: cận dưới 80.000 chia 40.000 bằng 2,0 lần, cận trên 150.000 chia 80.000 bằng khoảng 1,9 lần.

Nguồn này cũng nêu rõ rằng yếu tố đội chi phí lớn nhất không phải mô hình ngôn ngữ, mà là lớp kiểm soát truy cập, việc kết nối với hệ thống hiện có, và yêu cầu tuân thủ. Kết luận này trùng với cấu trúc đọc được từ số liệu của Nhật Bản. Trước khi lo phí gọi mô hình, hãy dành ngân sách cho phân quyền.

Tờ trình ghi lớp 1 đến 4 là vốn đầu tư, lớp 5 là chi phí vận hành hằng năm

Việc chia lớp phát huy tác dụng đúng ở đây, khi bạn viết tờ trình xin ngân sách.

• Vốn đầu tư ban đầu bằng lớp 1 cộng lớp 2 cộng lớp 3 cộng lớp 4. Gồm số hóa tài liệu, hạ tầng tìm kiếm, giao diện, kết nối và phân quyền.
• Chi phí vận hành hằng năm chỉ gồm lớp 5. Gồm phí sử dụng mô hình, công sức cập nhật tài liệu và cải thiện độ chính xác.

Trộn hai định nghĩa này là tờ trình hỏng. Lỗi hay gặp nhất: đưa 12 tháng phí vận hành năm đầu vào vốn đầu tư, rồi khi tính hiệu quả lại trừ tiếp phí vận hành lần nữa. Cùng một khoản bị tính hai lần.

Thử áp vào một ví dụ đã công bố tại Nhật Bản. Đây là số liệu của Nhật Bản, giá tại thị trường Nhật Bản. Một doanh nghiệp 300 nhân viên làm hệ thống hỏi đáp cho bộ phận công nghệ thông tin: PoC 1 triệu yên trong 2 tuần, xây dựng chính thức 6 triệu yên trong 3 tháng, vận hành khoảng 200.000 yên mỗi tháng. Theo định nghĩa trên:

• Vốn đầu tư, tức lớp 1 đến 4, bằng 1 triệu cộng 6 triệu, bằng 7 triệu yên
• Chi phí vận hành hằng năm, tức lớp 5, bằng 200.000 nhân 12 tháng, bằng 2,4 triệu yên
• Tổng chi phí sở hữu trong 3 năm bằng 7 triệu cộng 2,4 triệu nhân 3, bằng 14,2 triệu yên
• Tổng chi phí sở hữu trong 5 năm bằng 7 triệu cộng 2,4 triệu nhân 5, bằng 19 triệu yên

Công thức thời gian hoàn vốn là vốn đầu tư chia cho hiệu số giữa giá trị tiết kiệm hằng năm và chi phí vận hành hằng năm. Với ví dụ này là 7 triệu chia cho hiệu số giữa giá trị tiết kiệm và 2,4 triệu. Điều đáng lưu ý: khi giá trị tiết kiệm hằng năm tụt xuống dưới 2,4 triệu yên thì công thức không còn ý nghĩa. Chưa nói tới hoàn vốn, chỉ riêng chi phí vận hành đã lỗ.

Giả sử đặt giá trị tiết kiệm hằng năm là 4,8 triệu yên, ta có 7 chia cho hiệu của 4,8 và 2,4, bằng khoảng 2,9 năm. Nhưng xin nói rõ, 4,8 triệu yên không phải số liệu có nguồn, nó chỉ được đặt vào để minh họa hình dạng công thức.

Với tờ trình của bạn, hãy điền ô đó bằng số đo thực tế của chính mình, và cách gọn nhất là quy về giờ công. Ví dụ minh họa: nếu 50 người mỗi ngày mất 15 phút để đi tìm tài liệu, một năm 240 ngày làm việc, thì tổng thời gian là 50 nhân 15 nhân 240 bằng 180.000 phút, tức 3.000 giờ, tức 3.000 nhân W mỗi năm. Nếu hệ thống cắt được một nửa thời gian đó, giá trị tiết kiệm là 1.500 nhân W. Con số 15 phút ở đây là giả định; hãy đo thật bằng cách nhờ 10 người ghi lại nhật ký tra cứu trong một tuần. Giá trị tiết kiệm không dựa trên đo đạc sẽ bị bác ngay ở vòng thẩm định.

Một lưu ý cuối về lớp 5. Mức 100.000 đến 500.000 yên mỗi tháng ở thị trường Nhật Bản có bao gồm công sức nội bộ cho việc cập nhật tài liệu và cải thiện độ chính xác hay không thì nguồn không nói rõ. An toàn nhất là mặc định lớp 5 có cả chi phí nhân sự nội bộ, và dự trù riêng thời gian của người phụ trách.

“AI trả lời sai” phần lớn là lỗi ở khâu tìm kiếm, không phải ở mô hình

Sau khi thử nghiệm xong, nhận xét phổ biến nhất là “không thông minh như mong đợi”. Nhưng khi bóc tách nguyên nhân, phần lớn nằm ở khâu tìm kiếm chứ không phải khâu sinh câu trả lời. Mô hình chỉ trả lời được trong phạm vi tài liệu được đưa cho, nên nếu tài liệu đúng không được lấy ra thì mô hình mạnh đến mấy cũng trả lời sai.

Ba tầng cải thiện: Contextual Retrieval, kết hợp BM25 và xếp hạng lại

Về việc cải thiện khâu tìm kiếm, Anthropic có công bố số đo thực tế. Đây là số liệu toàn cầu. Trong tất cả các trường hợp, mốc so sánh là RAG kiểu cũ chỉ dùng vector nhúng, và chỉ số được đo là tỷ lệ tìm kiếm thất bại khi lấy ra 20 đoạn đứng đầu.

Kiểm lại phép tính. Từ 5,7% xuống 3,7% là giảm 1 trừ 3,7 chia 5,7, khoảng 35%. Xuống 2,9% là giảm khoảng 49%. Xuống 1,9% là giảm khoảng 67%.

Đây là chỗ rất hay bị đọc sai. Ý nghĩa là tỷ lệ tìm kiếm thất bại giảm 67%, chứ không phải độ chính xác của câu trả lời tăng 67%. Nói cách khác, tỷ lệ thất bại đi từ 5,7% xuống 1,9%, tức giảm 3,8 điểm phần trăm. Khi thấy đề xuất của nhà cung cấp ghi “độ chính xác tăng 67%”, hãy hỏi lại họ đã lấy gì làm mốc và đo cái gì.

Diễn giải ba phương pháp bằng ngôn ngữ thực tế:

• Contextual Embeddings là gắn thêm vào mỗi đoạn một câu mô tả ngắn cho biết đoạn đó thuộc tài liệu nào, nằm trong ngữ cảnh nào, rồi mới đưa đi nhúng. Đoạn văn “điều chỉnh áp suất về 0,3 MPa” đứng một mình thì không biết là của thiết bị nào; nhưng nếu được gắn thêm “mục điều chỉnh áp suất trong quy trình kiểm tra hằng ngày của máy chiết rót B” thì tra được.
• Kết hợp BM25 là ghép tìm kiếm theo ý nghĩa với tìm kiếm theo khớp từ khóa kiểu truyền thống. Cách này phát huy tác dụng với mã thiết bị, mã hàng, những chuỗi ký tự không thể tra theo nghĩa nhưng khớp chính xác theo mặt chữ. Trong tài liệu nhà máy, đây là yếu tố quan trọng.
• Xếp hạng lại là lấy ra dư một lượng ứng viên, rồi dùng một mô hình khác sắp xếp lại theo mức độ liên quan tới câu hỏi.

Những lỗi thường gặp khi cắt đoạn tài liệu

Các sự cố hay xảy ra với tài liệu nhà máy:

• Bảng bị cắt ngang. Bảng thông số bị chia đúng chỗ ranh giới đoạn, dòng tiêu đề và dòng số liệu rơi vào hai đoạn khác nhau. Kết quả là hệ thống lấy ra một dãy số mà không biết chúng thuộc chỉ tiêu nào.
• Ghi chú của bản vẽ tách khỏi hình. Dòng lưu ý kiểu “đổi vật liệu phải có phê duyệt của bộ phận chất lượng” bị lưu tách rời khỏi bản vẽ mà nó thuộc về.
• Lịch sử sửa đổi lẫn vào nội dung. Mô tả của quy trình cũ bị lấy ra như thể đang có hiệu lực. Nguyên nhân là ở bước tiền xử lý đã không loại bỏ bản cũ.
• Mất cấu trúc tiêu đề. Tiêu đề mục “4.2 Xử lý khi có bất thường” bị tách khỏi nội dung, không còn biết là xử lý cho chương nào.

Cách khắc phục là bỏ kiểu cắt máy móc theo số ký tự, chuyển sang cắt theo cấu trúc tiêu đề và theo đơn vị bảng. Với bảng, hoặc giữ nguyên cả bảng trong một đoạn, hoặc lặp lại dòng tiêu đề cho từng dòng dữ liệu.

Thiết kế để hệ thống biết nói “không tìm thấy”

Để hệ thống được tin dùng ở hiện trường, hãy chốt ba điều sau ngay từ đầu.

1. Luôn trả kèm liên kết tới tài liệu gốc. Bên dưới câu trả lời phải hiện tên tài liệu và số trang, bấm vào mở được bản gốc. Khả năng để con người kiểm chứng chính là thứ quyết định hệ thống có được dùng hay không.
2. Khi không tìm thấy tài liệu phù hợp, phải trả lời rằng không tìm thấy nội dung tương ứng, tuyệt đối không suy đoán. Điều này được cài đặt qua câu lệnh hướng dẫn và qua ngưỡng điểm tìm kiếm. Một hệ thống trả lời nghe có vẻ đúng nhưng sai chỉ cần lộ ra một lần ở hiện trường là mất lòng tin.
3. Điều chỉnh mức độ khẳng định theo tính chất công việc. Với các thao tác liên quan tới an toàn, câu trả lời phải kèm câu cố định nhắc người dùng kiểm tra bản gốc trước khi thao tác.

Thiết kế tìm kiếm cho nhà máy đa ngôn ngữ: tài liệu tiếng Nhật, câu hỏi tiếng Việt

Đây là phần đặc thù của nhà máy tại Việt Nam mà hầu như không bài viết nào về RAG đề cập. Tài liệu kỹ thuật viết bằng tiếng Nhật hoặc tiếng Anh, còn người đặt câu hỏi là công nhân và kỹ thuật viên nói tiếng Việt. Xử lý độ lệch ngôn ngữ này ở lớp nào là một quyết định thiết kế, không phải chuyện nhỏ.

So sánh ba phương án dịch

Lời giải thực tế không phải chọn một trong ba, mà là phối hợp. Nền tảng là dùng đồng thời phương án 2 và phương án 3: vừa dịch câu hỏi sang tiếng Nhật để tìm, vừa đối chiếu trực tiếp bằng vector nhúng đa ngôn ngữ, rồi gộp hai tập ứng viên và xếp hạng lại. Trên nền đó, chỉ áp dụng phương án 1 cho nhóm tài liệu mà hiểu sai là dẫn tới tai nạn, ví dụ tài liệu huấn luyện an toàn và quy trình xử lý khẩn cấp; nhóm này cần có bản tiếng Việt chính thức. Dịch toàn bộ tài liệu và quản lý song song hai bản thì cả chi phí ban đầu lẫn công sức cập nhật đều tăng theo khối lượng, nên bắt buộc phải khoanh vùng.

Bốn đặc điểm của tiếng Việt làm hỏng tìm kiếm nếu không xử lý

Đây là phần mà các mẫu thiết kế nhập từ nước ngoài thường bỏ qua.

Thứ nhất, người dùng hay gõ không dấu. Trong thực tế nhà máy, nhân viên gõ trên máy tính chung hoặc trên điện thoại thường bỏ dấu thanh và dấu phụ: gõ “may nen khi” thay vì “máy nén khí”, “bao tri” thay vì “bảo trì”, “kiem tra dinh ky” thay vì “kiểm tra định kỳ”. Với nhánh tìm kiếm theo từ khóa, chuỗi không dấu không khớp với chuỗi có dấu trong chỉ mục, và kết quả trả về sẽ trống. Cách xử lý là chuẩn hóa hai chiều: tạo thêm một trường chỉ mục đã bỏ dấu, đồng thời bỏ dấu ở câu truy vấn, rồi đối chiếu trên trường đó. Lưu ý là bỏ dấu sẽ tạo ra nhập nhằng, vì “ma” có thể là mà, má, mã hay mạ, nên chỉ nên dùng cách này cho nhánh từ khóa, còn nhánh tìm theo nghĩa vẫn giữ nguyên bản có dấu.

Thứ hai, dấu cách trong tiếng Việt ngăn cách âm tiết chứ không ngăn cách từ. Nhiều người cho rằng tiếng Việt không có vấn đề tách từ vì đã có dấu cách, nhưng thực tế “máy nén khí” là một từ gồm ba âm tiết. Nếu bộ tách từ mặc định cắt theo dấu cách, cụm này thành ba đơn vị riêng biệt là máy, nén và khí, và câu hỏi về máy nén khí có thể kéo về mọi tài liệu có chữ máy. Cách xử lý là dùng thêm n-gram hai đến ba âm tiết cho nhánh từ khóa, hoặc nạp một từ điển từ ghép chuyên ngành của chính nhà máy.

Thứ ba, từ viết tắt không thống nhất. Cùng bộ phận kiểm tra chất lượng, tài liệu chỗ này ghi QC, chỗ khác ghi KCS. Bán thành phẩm có nơi viết đầy đủ, có nơi viết BTP. Hàng lỗi thì lúc ghi NG, lúc ghi hàng không đạt. Cách xử lý là lập bảng từ đồng nghĩa và mở rộng truy vấn theo bảng đó, chứ không trông chờ mô hình tự đoán.

Thứ tư, thuật ngữ kỹ thuật lẫn lộn tiếng Anh và tiếng Việt. Trên hiện trường, người ta nói conveyor lẫn với băng tải, mold lẫn với khuôn, maintenance lẫn với bảo trì. Tài liệu gốc dùng một cách, người hỏi dùng cách khác. Bảng từ đồng nghĩa nói ở trên phải bao gồm cả các cặp song ngữ này, và nên xây theo hai chiều.

Ba trong bốn điểm trên đều được giải quyết bằng cùng một tài sản: một bảng thuật ngữ và từ đồng nghĩa của riêng nhà máy. Đó là lý do bảng này được đưa vào bảng giờ công ở phần chi phí.

Xin nói thêm một điểm để tránh nhầm lẫn nếu công ty bạn có nhà máy chị em tại Thái Lan: tiếng Thái không dùng dấu cách giữa các từ, nên còn cần thêm bước tách từ ở mức khác. Đó là vấn đề của tiếng Thái, không áp dụng cho tiếng Việt.

Không cho dịch mã thiết bị, mã hàng và tên riêng

Đây là chỗ dễ vỡ nhất khi làm đa ngôn ngữ. Nếu để máy dịch chạy tự do, mã thiết bị và từ viết tắt nội bộ cũng bị dịch. Mà mã đã bị dịch thì chuỗi ký tự đó không còn khớp với bất kỳ mục nào trong chỉ mục.

Cách xử lý là lập danh sách những từ không được dịch: mã thiết bị, mã linh kiện, số bản vẽ, tên hệ thống nội bộ, tên viết tắt của bộ phận, tên tiêu chuẩn. Bảng thuật ngữ này chỉ doanh nghiệp mới lập được, nhưng lập một lần là dùng lại được cho cả khâu dịch, khâu tìm kiếm và khâu sinh câu trả lời. Trong toàn bộ dự án, đây là một trong những đầu việc có hiệu quả trên chi phí dễ thấy nhất.

Trả lời bằng ngôn ngữ của người hỏi, dẫn nguồn bằng ngôn ngữ gốc

Mô hình vận hành mà chúng tôi khuyến nghị:

• Phần trả lời viết bằng ngôn ngữ của câu hỏi. Hỏi tiếng Việt thì trả lời tiếng Việt.
• Tài liệu căn cứ giữ nguyên ngôn ngữ gốc và hiển thị dưới dạng liên kết. Nếu là sổ tay bảo trì tiếng Nhật thì hiện liên kết tới đúng tệp PDF tiếng Nhật đó.
• Phần trích dẫn đoạn liên quan thì đặt bản gốc và bản dịch cạnh nhau. Chỉ đưa bản dịch thì khi ra hiện trường không đối chiếu được với bản gốc.

Cách này giúp người thao tác nắm được nội dung bằng tiếng mẹ đẻ, còn khi nghi ngờ thì mở bản gốc ra kiểm tra. Người quản lý Nhật Bản nhìn cùng màn hình cũng biết câu trả lời dựa trên tài liệu nào, đoạn nào. Khi vận hành như một chatbot đa ngôn ngữ, chính thiết kế giữ liên kết bản gốc này là biện pháp thực tế để cắt con đường dẫn từ một câu dịch sai tới một tai nạn lao động.

Luật Trí tuệ nhân tạo và dữ liệu: những điểm cần xác nhận trước khi triển khai

Quay lại chủ đề mở đầu bài viết, ở góc độ những gì cần chuẩn bị.

Điều cần chuẩn bị khi luật đã có hiệu lực

Như đã nêu, Luật Trí tuệ nhân tạo được Quốc hội thông qua tháng 12 năm 2025 và có hiệu lực từ tháng 3 năm 2026, với cơ chế phân loại rủi ro, yêu cầu trách nhiệm giải trình và nghĩa vụ quản trị đối với hệ thống AI có tác động lớn. Đây là nội dung liên quan tới Việt Nam.

Điều cần nắm khi xây dựng hệ thống RAG là xác định xem cách dùng của mình rơi vào nhóm rủi ro nào. Một công cụ hỗ trợ tra cứu sổ tay nội bộ thì mức tác động có thể xem là hạn chế. Nhưng nếu câu trả lời của nó được dùng để đánh giá nhân sự, để quyết định tuyển dụng, hoặc được dùng như chỉ dẫn thao tác liên quan trực tiếp tới an toàn, thì cách nhìn nhận có thể khác. Về số hiệu văn bản, thủ tục cụ thể, ngưỡng áp dụng và các ưu đãi nếu có, hãy xác nhận bằng văn bản với cơ quan quản lý nhà nước có thẩm quyền hoặc chuyên gia tại địa phương. Bài viết này không suy đoán chi tiết pháp lý.

Yêu cầu về trách nhiệm giải trình có một hệ quả kỹ thuật rất cụ thể: hệ thống nên lưu được nhật ký cho biết câu trả lời nào dựa trên tài liệu nào, do mô hình nào sinh ra, vào thời điểm nào. Thiết kế “luôn trả kèm liên kết tài liệu gốc” nói ở phần trước, vì thế, không chỉ để lấy lòng tin của hiện trường mà còn hợp lý ở góc độ giải trình. Hai yêu cầu này gặp nhau ở cùng một chỗ, nên đừng coi việc lưu vết là gánh nặng phát sinh thêm.

Không trộn tài liệu nhân sự, sức khỏe và tiền lương vào kho tri thức

Về mặt thực hành, hãy mặc định loại các nhóm tài liệu sau khỏi phạm vi của hệ thống:

• Hồ sơ đánh giá nhân sự, điều chuyển, kỷ luật
• Kết quả khám sức khỏe và hồ sơ y tế
• Bảng lương, thưởng, chi tiết giờ làm của từng cá nhân
• Hồ sơ ứng tuyển và biên bản phỏng vấn

Những tài liệu này tra cứu được thì có vẻ tiện, nhưng một khi đã nằm trong chỉ mục thì bất kỳ sai sót nào ở khâu phân quyền cũng lập tức trở thành sự cố lộ dữ liệu cá nhân. Quyết định nguy hiểm nhất là “cứ đưa hết vào cho tiện”. Nếu bắt buộc phải đưa vào, hãy tách hẳn thành một chỉ mục riêng và xây như một hệ thống độc lập, giới hạn chặt danh sách người được truy cập. Về nghĩa vụ đối với dữ liệu cá nhân theo quy định hiện hành tại Việt Nam, hãy xác nhận bằng văn bản với cơ quan quản lý nhà nước có thẩm quyền hoặc chuyên gia tại địa phương.

Nơi lưu trữ dữ liệu phải trả lời cho bốn loại, không phải một

Trong nhà máy có vốn đầu tư nước ngoài, chính sách công nghệ thông tin của công ty mẹ thường quy định dữ liệu phải nằm ở một vùng lưu trữ nhất định, trong khi phía Việt Nam lại có yêu cầu riêng. Với hệ thống RAG, có bốn loại dữ liệu và mỗi loại có thể nằm ở một nơi khác nhau: tài liệu gốc, văn bản đã trích xuất, vector nhúng, và nhật ký câu hỏi cùng câu trả lời. Đừng chỉ hỏi vùng đặt máy chủ của mô hình rồi coi như xong. Cấu hình mà cơ sở dữ liệu vector và nhật ký nằm ở vùng khác với tài liệu gốc là chuyện rất bình thường. Hãy yêu cầu nhà cung cấp trả lời riêng cho từng loại trong bốn loại trên, bằng văn bản.

Số liệu tham chiếu từ Thái Lan: đây là số liệu của Thái Lan, không áp dụng cho Việt Nam

Để có điểm so sánh trong khu vực, có thể tham khảo tình hình Thái Lan. Xin nhấn mạnh trước: đây là số liệu của Thái Lan, không áp dụng cho Việt Nam.

Theo khảo sát Thailand Digital Outlook 2026 với 834 doanh nghiệp trên toàn Thái Lan, mức độ trưởng thành số trung bình của doanh nghiệp đạt 2,12 trên thang 4 điểm, lần đầu tiên chạm mức trung bình. So với 1,56 của năm 2025, mức tăng là 0,56 điểm, tương đương khoảng 36%. Tuy vậy, 2,12 trên thang 4 điểm chỉ tương ứng khoảng 53% mức tối đa. Lĩnh vực yếu được nêu là phát triển sản phẩm và dịch vụ số cùng hoạt động nghiên cứu phát triển.

Cũng tại Thái Lan, tỷ lệ doanh nghiệp thực sự đưa AI vào nghiệp vụ mới khoảng 18%, tức hơn 80% còn lại chưa đưa vào. Và khoảng 65% tổ chức trong ngành sản xuất nêu lo ngại về chất lượng dữ liệu như một rào cản lớn khi ứng dụng AI. Tất cả các con số trong đoạn này là của Thái Lan.

Con số 65% đáng chú ý ở chỗ nó mô tả đúng cái mà bài viết này gọi là lớp 1: dữ liệu chưa sẵn sàng thì mọi thứ phía sau đều đắt lên. Nhận thức đó đã phổ biến trong ngành sản xuất khu vực, không riêng một nước.

Về khung pháp lý, Thái Lan tính đến năm 2026 vẫn chưa có đạo luật riêng về AI có hiệu lực; cơ quan quản lý đang hợp nhất các dự thảo trước đây thành một khung duy nhất theo hướng tiếp cận dựa trên rủi ro, dự kiến gồm phân loại rủi ro bị cấm và rủi ro cao, bắt buộc đánh giá tác động, và siết chặt hơn với quyết định tự động. Nền tảng pháp lý hiện tại của họ là luật bảo vệ dữ liệu cá nhân. Đây là điểm khác biệt rõ với Việt Nam, nơi luật riêng về AI đã có hiệu lực từ tháng 3 năm 2026. Nếu công ty bạn dùng chung một thiết kế hệ thống cho cả hai nước, đừng giả định rằng yêu cầu tuân thủ ở hai nơi giống nhau.

Sáu kiểu thất bại khi xây dựng hệ thống RAG trong nhà máy

Tổng hợp lại nội dung phía trên dưới dạng sáu kiểu thất bại.

1. Đổ hết tài liệu vào mà không dọn dẹp. Bản cũ và bản hiện hành lẫn lộn, hệ thống trả về quy trình cũ và mất lòng tin ngay tuần đầu. Cách phòng: đưa việc kiểm kê tài liệu và xác định phiên bản vào bảng giờ công của lớp 1, coi đó là công việc chính thức chứ không phải việc phụ.
2. Để thiết kế phân quyền lại sau cùng. Bản thử nghiệm làm theo kiểu ai cũng xem được mọi tài liệu, tới bản chính thức mới thêm phân quyền thì phải làm lại từ đầu. Như cấu trúc chi phí đã chỉ ra, phân quyền là một trong những lớp nặng nhất. Hãy đưa vào thiết kế ngay từ đầu.
3. Thử nghiệm không có tiêu chí đánh giá. Nếu chấm bằng cảm nhận sau khi dùng thử, mỗi người một ý và cuộc họp không đi tới kết luận nào. Giải pháp là bộ câu hỏi đánh giá nói ở phần sau.
4. Không chỉ định người chịu trách nhiệm cập nhật tài liệu. Sáu tháng sau khi chạy, tài liệu cũ đi, không ai sửa, chất lượng câu trả lời tụt dần. Hãy ghi rõ công sức cập nhật vào lớp 5 và chốt bộ phận phụ trách trước khi vận hành.
5. Dừng dự án chỉ vì “AI trả lời sai một lần”. Không có hệ thống RAG nào đạt 100% câu đúng. Điều quan trọng là khi sai thì có bóc tách được lỗi nằm ở khâu tìm kiếm hay khâu sinh câu trả lời, và có sửa được cách cắt đoạn hay cách tìm kiếm hay không. Hãy chốt trước quy trình ghi nhận câu trả lời sai và đưa vào vòng cải thiện, thay vì dừng toàn bộ.
6. Ranh giới tự làm và thuê ngoài không rõ. Giao trọn gói cho bên ngoài không xong, mà tự làm hết cũng không xong. Phần tiếp theo vạch ranh giới đó.

Ranh giới tự làm và thuê ngoài, cùng tám câu hỏi dành cho nhà cung cấp

Những việc chỉ doanh nghiệp mới làm được

• Chọn tài liệu và chốt phiên bản hiệu lực. Chỉ người ở hiện trường mới biết bản nào đang dùng.
• Soạn bộ dữ liệu đánh giá. Bảng đối chiếu giữa câu hỏi thật của hiện trường và vị trí câu trả lời đúng trong tài liệu. Không có kiến thức nội bộ thì không soạn nổi.
• Quyết định chính sách phân quyền. Ai được xem tới đâu là quyết định của ban lãnh đạo và bộ phận nhân sự.
• Xây bảng thuật ngữ. Danh sách mã và từ viết tắt không được dịch, cùng bảng từ đồng nghĩa song ngữ.

Những việc nên thuê ngoài

• Dựng hạ tầng tìm kiếm, gồm cơ sở dữ liệu vector, vector nhúng và thiết kế chỉ mục
• Cài đặt cơ chế phân quyền, với chính sách do doanh nghiệp quyết còn phần triển khai do bên ngoài làm
• Kết nối với hệ thống hiện có, gồm hệ thống quản lý sản xuất, hệ thống quản lý tài liệu và hệ thống xác thực người dùng
• Thiết kế cách cắt đoạn và tinh chỉnh phương pháp tìm kiếm
• Thực hiện công đoạn số hóa, bao gồm nhận dạng ký tự

Tám câu hỏi nên đặt cho nhà cung cấp

1. Độ chính xác được đo bằng cách nào? Bộ đánh giá gồm bao nhiêu câu, dùng chỉ số gì? Có tách riêng tỷ lệ tìm kiếm thất bại và mức độ đúng của câu trả lời khi báo cáo không?
2. Mốc so sánh là gì? Khi nói “độ chính xác tăng”, hãy nêu rõ so với cái gì.
3. Phân quyền truy cập được cài đặt theo cơ chế nào? Lọc ngay ở bước tìm kiếm hay lấy về rồi loại bỏ? Khi có điều chuyển nhân sự thì hệ thống cập nhật ra sao?
4. Sau khi sửa tài liệu, mất bao lâu và qua những bước nào thì câu trả lời phản ánh nội dung mới? Tự động hay thủ công, và ai là người thực hiện?
5. Độ chính xác khi tìm kiếm bằng tiếng Việt có được đánh giá tách riêng với tiếng Nhật không? Đã xử lý trường hợp nhập không dấu và từ ghép nhiều âm tiết chưa?
6. Dữ liệu được lưu ở đâu? Trả lời riêng cho từng loại trong bốn loại: tài liệu gốc, văn bản trích xuất, vector nhúng, nhật ký hỏi đáp.
7. Khi không tìm thấy căn cứ thì hệ thống hành xử thế nào? Đã có cơ chế chặn việc suy đoán chưa?
8. Nếu kết thúc hợp đồng, chúng tôi giữ lại được những gì? Có mang đi được bộ tài liệu đã chỉnh lý, văn bản đã trích xuất, bộ dữ liệu đánh giá và bảng thuật ngữ không? Ở định dạng không phụ thuộc vào sản phẩm của một hãng cụ thể chứ?

Câu thứ tám đặc biệt quan trọng. Trong toàn bộ dự án, tài sản có giá trị nhất không phải hạ tầng tìm kiếm mà là bộ tài liệu đã được chỉnh lý và bộ dữ liệu đánh giá. Hãy kiểm tra xem hợp đồng có bảo đảm rằng hai thứ đó ở lại với doanh nghiệp hay không.

Bốn bước triển khai hệ thống RAG

Bước 1: thu hẹp còn một nghiệp vụ duy nhất

Gom yêu cầu của nhiều bộ phận cùng lúc thì loại tài liệu và cấu hình phân quyền đều phức tạp lên ngay lập tức. Bắt đầu bằng một nghiệp vụ. Tiêu chí chọn: tài liệu đã số hóa với tỷ lệ cao, tần suất câu hỏi lớn, và phân quyền đơn giản. Trong thực tế, hai ứng viên hay được chọn là tra cứu sổ tay bảo trì thiết bị và hỏi đáp quy định nội bộ.

Bước 2: soạn 30 câu hỏi đánh giá trước khi bắt đầu

Trước khi khởi động thử nghiệm, hãy thu thập 30 câu hỏi thật từ hiện trường, và với mỗi câu, ghi rõ tên tài liệu cùng vị trí chứa câu trả lời đúng. Đây là khâu chuẩn bị quan trọng nhất của cả dự án.

Trong 30 câu, hãy trộn đủ các loại sau:

• Câu chỉ cần xem một chỗ là trả lời được
• Câu phải đối chiếu nhiều tài liệu mới trả lời được
• Câu mà tài liệu không có câu trả lời, và đáp án đúng là hệ thống nói không tìm thấy nội dung tương ứng
• Câu có chứa mã thiết bị hoặc từ viết tắt
• Câu viết bằng tiếng Việt, gồm cả một số câu cố tình gõ không dấu

Không có bộ dữ liệu này thì không thể kết luận thử nghiệm là thành công hay thất bại. Ngược lại, chỉ cần có nó là bạn so sánh được đề xuất của nhiều nhà cung cấp trên cùng một thước đo, và sau khi vận hành vẫn đo được hiệu quả của từng lần cải tiến. Việc này tốn thời gian của người ở hiện trường, nhưng không thuê ngoài được.

Bước 3: chạy thử nghiệm và chấm điểm

Giới hạn phạm vi tài liệu và giới hạn nhóm người dùng, rồi chấm bằng đúng 30 câu ở bước 2. Tiêu chí không phải là “dùng thấy tiện”, mà là trả lời đúng bao nhiêu câu, lấy nhầm tài liệu ở bao nhiêu câu, và nói không tìm thấy một cách chính xác ở bao nhiêu câu. Với các câu sai, hãy ghi rõ là do khâu tìm kiếm không lấy được tài liệu đúng, hay lấy được rồi mà vẫn trả lời sai. Trường hợp đầu thì sửa khâu tìm kiếm, trường hợp sau thì xem lại câu lệnh hướng dẫn và cách cắt đoạn.

Về thời gian, mặt bằng tại Nhật Bản là 2 đến 6 tuần. Đây là số liệu của Nhật Bản, dùng để tham chiếu.

Bước 4: xây dựng chính thức và bắt đầu vận hành

Ở bản chính thức, phần việc chính là lớp 4, tức kết nối hệ thống hiện có và thiết kế phân quyền truy cập. Song song, hãy chốt bộ máy vận hành thuộc lớp 5: ai cập nhật tài liệu, ai tiếp nhận báo cáo về câu trả lời sai, và bao lâu chạy lại bộ câu hỏi đánh giá một lần. Không chốt ba điều này mà đã cho chạy thì sáu tháng sau hệ thống sẽ không còn ai dùng.

Về thời gian, mặt bằng tại Nhật Bản là 2 đến 4 tháng. Đây là số liệu của Nhật Bản, dùng để tham chiếu.

Ở đúng bước này, khoảng cách giữa 93% và 13,8% nêu ở đầu bài mới lộ ra. Bản thử nghiệm chỉ chạm tới lớp 1 tới lớp 3, tức chỉnh lý một ít tài liệu rồi gắn một màn hình hỏi đáp. Rào cản của việc mở rộng ra toàn công ty nằm ở lớp 4. Ở đó, bạn phải rà soát quyền xem của từng bộ phận và xây cơ chế bám theo các đợt điều chuyển nhân sự. Đây là công việc của tổ chức nhiều hơn là của kỹ thuật, và nó không tự xong bằng cách đổi sang một mô hình AI mạnh hơn. Bước vào giai đoạn mở rộng với ngân sách và cách nghĩ của giai đoạn thử nghiệm thì gần như chắc chắn dừng lại ở lớp này.

Câu hỏi thường gặp về xây dựng hệ thống RAG

RAG là gì?

RAG, viết tắt của Retrieval-Augmented Generation, là cơ chế tìm phần liên quan trong tài liệu của doanh nghiệp theo câu hỏi, rồi đưa phần đó cho mô hình ngôn ngữ để soạn câu trả lời. Mô hình không ghi nhớ tài liệu nội bộ mà tra cứu lại mỗi lần, nên cập nhật tài liệu là cập nhật được câu trả lời. Khả năng chỉ ra tài liệu làm căn cứ cũng là đặc tính quan trọng khi dùng trong nội bộ.

Chi phí xây dựng hệ thống RAG khoảng bao nhiêu?

Không có số liệu công bố về mặt bằng giá tại Việt Nam mà chúng tôi có thể trích dẫn, nên hãy dùng hai tham chiếu sau để đọc cấu trúc chi phí. Tại thị trường Nhật Bản, PoC khoảng 1 đến 3 triệu yên, xây dựng chính thức 3 đến 10 triệu yên, vận hành 100.000 đến 500.000 yên mỗi tháng; đây là giá tại thị trường Nhật Bản. Theo số liệu toàn cầu, RAG đơn giản 15.000 đến 25.000 đô la Mỹ, RAG chạy chính thức 40.000 đến 80.000 đô la Mỹ, RAG doanh nghiệp triển khai tại chỗ từ 80.000 đến 150.000 đô la Mỹ trở lên. Riêng phần công sức nội bộ, cách ước lượng an toàn là quy về giờ công và nhân với đơn giá giờ công W của chính doanh nghiệp. Với nhà máy, nếu tài liệu còn ở dạng giấy hoặc ảnh quét thì lớp 1 sẽ đội lên đáng kể. Trong tờ trình, hãy ghi lớp 1 đến 4 là vốn đầu tư và lớp 5 là chi phí vận hành hằng năm.

Nên chọn RAG hay tinh chỉnh mô hình?

Nếu mục tiêu là tra cứu tài liệu nội bộ thì chọn RAG trước. Tinh chỉnh mô hình đòi hỏi huấn luyện lại mỗi lần tài liệu thay đổi và không chỉ ra được tài liệu làm căn cứ. Ngược lại, khi cần cố định văn phong hoặc định dạng đầu ra thì tinh chỉnh có chỗ dùng. Cách phân vai thực tế là: tra cứu dữ kiện dùng RAG, thống nhất cách diễn đạt dùng câu lệnh hướng dẫn hoặc tinh chỉnh.

Tài liệu chỉ có bản giấy thì có làm được không?

Làm được, nhưng phải số hóa trước. Bản giấy và PDF dạng ảnh không tìm kiếm được theo chữ, nên cần bước nhận dạng ký tự. Công đoạn này thuộc lớp 1 và trong nhà máy thường là phần chiếm chi phí lớn nhất. Với biểu mẫu viết tay hoặc có lẫn tiếng Nhật và tiếng Việt, hãy bắt đầu bằng việc kiểm tra độ chính xác đọc trên một mẫu nhỏ. Cách làm thực tế là khoanh vùng và số hóa theo thứ tự ưu tiên, bắt đầu từ những tài liệu được tra cứu nhiều nhất.

Hỏi bằng tiếng Việt có tra được sổ tay tiếng Nhật không?

Được, nhưng phải thiết kế. Có ba phương án: dịch tài liệu và giữ hai bản, dịch câu hỏi rồi mới tìm, và dùng vector nhúng đa ngôn ngữ để đối chiếu trực tiếp. Thực tế nên dùng đồng thời hai phương án sau, và chỉ làm bản tiếng Việt chính thức cho nhóm tài liệu liên quan trực tiếp tới an toàn. Ngoài ra cần xử lý riêng cho tiếng Việt: chuẩn hóa trường hợp gõ không dấu, xử lý từ ghép nhiều âm tiết, thống nhất từ viết tắt, và lập bảng từ đồng nghĩa cho các cặp thuật ngữ Anh – Việt. Đừng quên bảng thuật ngữ không được dịch để mã thiết bị và mã hàng không bị dịch mất.

Luật Trí tuệ nhân tạo có ảnh hưởng tới hệ thống tra cứu nội bộ không?

Luật có hiệu lực từ tháng 3 năm 2026 và đưa ra cơ chế phân loại rủi ro cùng yêu cầu về trách nhiệm giải trình. Về mặt thiết kế, điều nên làm ngay là bảo đảm hệ thống lưu được vết: câu trả lời dựa trên tài liệu nào, do mô hình nào sinh ra, vào lúc nào, và ai được phép xem tài liệu đó. Còn việc nghiệp vụ cụ thể của bạn thuộc nhóm rủi ro nào và phát sinh nghĩa vụ gì, hãy xác nhận bằng văn bản với cơ quan quản lý nhà nước có thẩm quyền hoặc chuyên gia tại địa phương.

Xây dựng hệ thống RAG mất bao lâu?

Theo mặt bằng tại Nhật Bản, PoC mất 2 đến 6 tuần và xây dựng chính thức mất 2 đến 4 tháng; đây là số liệu của Nhật Bản. Trong ví dụ một doanh nghiệp 300 nhân viên làm hệ thống hỏi đáp cho bộ phận công nghệ thông tin, thử nghiệm mất 2 tuần và xây dựng chính thức mất 3 tháng. Cần lưu ý đây là khoảng thời gian với giả định tài liệu đã ở dạng số. Nếu phải số hóa từ bản giấy hoặc ảnh quét, hãy cộng thêm thời gian cho công đoạn đó; theo bảng giờ công ở phần trên, riêng lớp 1 đã có thể chiếm khoảng hai tháng với hai người chuyên trách.

Tổng kết: xây dựng hệ thống RAG theo năm lớp

Tóm lại theo đúng năm lớp chi phí.

• Lớp 1, số hóa và tiền xử lý tài liệu. Trong nhà máy đây thường là lớp nặng nhất. Việc chỉnh lý bản giấy, PDF quét, bản vẽ, tệp bảng tính và chốt phiên bản hiệu lực thì chỉ doanh nghiệp làm được. Trước khi bắt tay, hãy kiểm tra xem khối lượng có dưới 200.000 token, tức khoảng 500 trang, hay không; nếu dưới thì cân nhắc phương án đưa thẳng vào prompt thay vì xây hệ thống. Đây là ngưỡng theo số liệu toàn cầu.
• Lớp 2, hạ tầng tìm kiếm. Theo chi tiết giá tại thị trường Nhật Bản, cơ sở dữ liệu vector ở bản chính thức khoảng 600.000 yên. Đây là lớp tương đối nhẹ.
• Lớp 3, ứng dụng và giao diện. Càng nhúng vào công cụ mà nhân viên đang dùng hằng ngày thì càng dễ hình thành thói quen sử dụng.
• Lớp 4, kết nối hệ thống và phân quyền truy cập. Phần chênh lệch trong bảng giá của Nhật Bản, và yếu tố đội chi phí mà nguồn toàn cầu chỉ ra, đều tập trung ở đây. Đây cũng chính là chỗ mà việc mở rộng toàn công ty bị chặn lại.
• Lớp 5, vận hành. Phí sử dụng mô hình, cập nhật tài liệu, công sức cải thiện độ chính xác. Trong tờ trình, tách khỏi vốn đầu tư và ghi thành chi phí vận hành hằng năm.

Về độ chính xác, trọng tâm cải thiện nằm ở khâu tìm kiếm. Chồng lần lượt Contextual Embeddings, kết hợp BM25 và xếp hạng lại thì tỷ lệ tìm kiếm thất bại đi từ 5,7% xuống 1,9%, tức giảm 67% so với mốc là RAG chỉ dùng vector nhúng. Đây là số liệu toàn cầu, và xin nhắc lại rằng đó là mức giảm của tỷ lệ thất bại, không phải mức tăng của độ chính xác.

Về đa ngôn ngữ, trong nhà máy tại Việt Nam thì ngôn ngữ của tài liệu và ngôn ngữ của người vận hành không trùng nhau. Chọn lớp để đặt việc dịch trong ba phương án, xử lý chuyện gõ không dấu và từ ghép nhiều âm tiết, thống nhất từ viết tắt, không cho dịch mã thiết bị. Trả lời bằng ngôn ngữ của người hỏi, dẫn nguồn bằng ngôn ngữ gốc. Thiết kế tới mức đó thì hệ thống mới thực sự được dùng ngoài hiện trường.

Và quay lại con số mở đầu. 93% doanh nghiệp Việt Nam đã dùng hoặc đang cân nhắc AI, nhưng chỉ 13,8% triển khai được toàn công ty. Khoảng cách ấy không được lấp bằng một mô hình mạnh hơn, mà bằng ba việc rất đời thường: chỉnh lý tài liệu của chính mình, soạn bộ câu hỏi đánh giá của chính mình, và thiết kế phân quyền của chính mình. Ba việc đó không thuê ngoài trọn gói được, nhưng cũng chính chúng là thứ ở lại với doanh nghiệp sau khi dự án kết thúc. Về mặt pháp lý, Luật Trí tuệ nhân tạo đã có hiệu lực từ tháng 3 năm 2026 và chi tiết áp dụng cần được xác nhận bằng văn bản với cơ quan quản lý nhà nước có thẩm quyền hoặc chuyên gia tại địa phương.

Nếu bạn đang cân nhắc xây dựng hệ thống RAG và mới ở giai đoạn muốn phân loại xem nên bắt đầu từ nhóm tài liệu nào, chúng tôi vẫn có thể cùng bạn làm rõ. Có thể bắt đầu đơn giản bằng việc xác định khối lượng tài liệu hiện có thuộc quy mô cần xây hệ thống hay chỉ cần đưa thẳng vào prompt là đủ. Chúng tôi cũng nhận trao đổi về thiết kế tìm kiếm đa ngôn ngữ và phạm vi kết nối với hệ thống quản lý sản xuất đang dùng. Vui lòng liên hệ tại đây.

Nguồn tham khảo

• Anthropic, Introducing Contextual Retrieval, https://www.anthropic.com/news/contextual-retrieval
• GXO, Phân tích chi phí xây dựng RAG, ngày 14 tháng 4 năm 2026, https://gxo.co.jp/column/rag-implementation-cost-breakdown-2026
• AITIP, Quy trình và mặt bằng chi phí xây dựng RAG, https://aitip.jp/rag-construction/
• ScalaCode, RAG Development Cost, https://www.scalacode.com/blog/rag-development-cost/
• Vietnam Briefing, Vietnam’s AI Law: Regulatory Milestone and Business Implications, https://www.vietnam-briefing.com/news/vietnams-ai-law-regulatory-milestone-business-implications.html/
• Bangkok Post, AI adoption helps Thai firms become digitally mature, https://www.bangkokpost.com/business/general/3283789/ai-adoption-helps-thai-firms-become-digitally-mature
• Bangkok Post, Data quality concerns a barrier to adoption of AI, https://www.bangkokpost.com/business/general/3051260/data-quality-concerns-a-barrier-to-adoption-of-ai
• DataGuidance, Thailand: ETDA announces AI 2026 strategy to promote trust, https://www.dataguidance.com/news/thailand-etda-announces-ai-2026-strategy-promote-trust