Phân tích dữ liệu bằng AI tạo sinh | 4 loại và bài toán hoàn vốn 17.8 tháng

Chuyện dùng AI tạo sinh để phân tích dữ liệu, ngay cả khi đã sang năm 2026, vẫn chưa bước vào giai đoạn “đưa dữ liệu vào là có câu trả lời”. Số doanh nghiệp thực sự đưa được phân tích dữ liệu bằng AI tạo sinh vào công việc hằng ngày chỉ là một phần rất nhỏ, ngay cả trong nhóm đã dùng AI tạo sinh. Nhưng lý do không phải là “mô hình chưa đủ thông minh”. Thứ quyết định kết quả phân tích có dùng được hay không nằm ở phía dữ liệu, cụ thể là 3 điều kiện, chứ không nằm ở phía mô hình. Bài viết này chia phân tích dữ liệu bằng AI tạo sinh thành 4 loại, chỉ ra 3 điều kiện quyết định độ chính xác, và đi tới một cấu trúc phản trực giác qua ước tính riêng theo 3 kịch bản: càng mở rộng phạm vi chuẩn hóa thì hoàn vốn càng xa.

Chỉ riêng mảng phân tích dữ liệu là không tăng

Trong khảo sát do Teikoku Databank thực hiện từ ngày 17 đến ngày 31 tháng 3 năm 2026 (10,312 doanh nghiệp trả lời hợp lệ), tỷ lệ doanh nghiệp trả lời có sử dụng AI tạo sinh trong công việc là 34.5%. Đến đây thì đó là con số hay được trích dẫn. Vấn đề nằm ở phần chi tiết bên trong.

Khi hỏi các doanh nghiệp đó về mục đích sử dụng, dẫn đầu là “soạn thảo, tóm tắt và hiệu đính văn bản” với 45.1%, tiếp theo là “thu thập thông tin” 21.8% và “đưa ra ý tưởng” 11.0%. Còn “tổng hợp và phân tích dữ liệu” chỉ đạt 7.4%. Bằng một phần sáu mục đích dẫn đầu. Mức này gần như không khác biệt so với “hỗ trợ lập trình” ở 5.9%.

Có một cách đọc cần lưu ý ở đây. Con số 7.4% này không phải là “7.4% của toàn bộ doanh nghiệp”. Đó là tỷ trọng mục đích sử dụng trong nhóm doanh nghiệp đã trả lời có dùng AI tạo sinh cho công việc. Khi nhớ rằng mẫu số nằm ở phía 34.5%, tỷ lệ doanh nghiệp thực sự dùng AI tạo sinh để tổng hợp và phân tích dữ liệu so với toàn thể còn nhỏ hơn nữa.

Vì sao riêng mảng này không tăng? Không phải vì không có nhu cầu. Ngược lại, tại bộ phận kế hoạch kinh doanh và quản lý sản xuất, mong muốn “bỏ hẳn thời gian làm báo cáo tháng” hay “muốn nhìn xu hướng lỗi mỗi ngày” còn bức thiết hơn nhu cầu sinh văn bản. Mảng này không tăng không phải vì thiếu nhu cầu, mà vì đã thử rồi nhưng không thông.

Không thông ở đây nghĩa là kiểu thất bại của nó rất đặc thù. Với sinh văn bản, nếu đầu ra tệ thì đọc một cái là biết ngay. Phân tích dữ liệu thì khác. Con số trả về đúng hay sai, bạn không thể biết trừ khi có sẵn một phương tiện khác để kiểm chứng chính con số đó. Và phần lớn hiện trường muốn giao việc phân tích cho AI chính bởi vì họ không có phương tiện kiểm chứng đó. Đây là một nghịch lý mang tính cấu trúc.

Phân tích dữ liệu bằng AI tạo sinh chia thành 4 loại

Một cụm từ duy nhất là “phân tích dữ liệu bằng AI tạo sinh” đang chỉ tới 4 công việc có tính chất hoàn toàn khác nhau trong thực tế. Thứ phải chuẩn bị khác nhau, kiểu thất bại khác nhau, mức đầu tư cần thiết cũng khác nhau. Các cuộc thảo luận lệch pha nhau là vì đang trộn cả 4 loại này lại mà nói.

Bốn loại này không phải là các giai đoạn. Điểm quan trọng là chúng không có quan hệ kiểu đi tuần tự từ loại 1 rồi mới tới loại 4. Loại 4 cho ra kết quả dùng được dễ hơn loại 1, còn loại 3 thì tuyệt đối không khả thi nếu loại 2 chưa đứng vững. Hãy quyết định trước công ty mình đang cần loại nào, rồi tính ngược ra phần chuẩn bị cần thiết.

Loại 1. Phân tích dán dữ liệu – nhanh, nhưng không đọng lại

Đây là dạng dán bảng CSV hoặc Excel đang có sẵn vào AI tạo sinh rồi hỏi “cho tôi biết công đoạn nào nhiều lỗi nhất”. Gần như không cần chuẩn bị gì và có thể bắt đầu ngay hôm nay. Thực tế, câu “chúng tôi đã thử phân tích dữ liệu bằng AI tạo sinh” ở phần lớn doanh nghiệp đang chỉ tới đúng loại này.

Giá trị của loại này nằm ở khâu thăm dò. Để nhìn dữ liệu khi chưa có giả thuyết nào và bắt được nhận xét kiểu “riêng công đoạn này trông khác hẳn”, nó hoàn toàn dùng được. Đây là công cụ xuất sắc cho bước đoán hướng trước khi dựng bảng tổng hợp trên phần mềm bảng tính.

Vấn đề là kết quả không đọng lại. Không có ghi chép nào về việc ai đã dán tệp nào, phạm vi nào, vào lúc nào. Tháng sau bạn hỏi lại đúng câu đó, nhưng nếu điều kiện trích xuất của tệp đã dán lệch đi một ngày thì câu trả lời sẽ khác. Và không có cách nào phân định bên nào mới đúng. Chuyện một con số được phát biểu trong cuộc họp kèm câu “AI nói vậy” rồi sau đó không tái lập được, cuối cùng nhân viên phụ trách phải dựng lại bằng tay, không hề hiếm.

Vì vậy nên giới hạn vị trí của loại 1 ở đúng vai trò “nơi tạo ra giả thuyết”. Nhận xét thu được ở đây phải được hạ xuống dạng tái lập được, bằng loại 2 hoặc bằng hệ BI sẵn có. Nếu sự phân công đó chạy được thì loại 1 dư sức hoàn vốn, còn nếu không chạy được thì loại 1 chỉ là hoạt động làm tăng thêm giờ công.

Loại 2. Phân tích kết nối – đích ngắm thật, nhưng cần chuẩn bị nhiều nhất

Đây là dạng nối AI tạo sinh vào hệ thống quản lý sản xuất hoặc cơ sở dữ liệu chất lượng, để nó dịch câu hỏi bằng ngôn ngữ tự nhiên thành truy vấn dạng SQL và lấy ra câu trả lời. Khi nghe cụm “phân tích dữ liệu bằng AI tạo sinh”, phần lớn mọi người đang kỳ vọng chính điều này.

Nếu loại này chạy được thì hiệu quả rất lớn, và phần chuẩn bị cũng nặng nhất. Thứ cần thiết không phải là hiệu năng mô hình, mà là 3 điều kiện từ vựng, độ chi tiết (granularity) và ranh giới sẽ nói ở phần sau. Nếu kết nối khi chưa có 3 thứ này, AI sẽ thản nhiên, một cách nghe rất có lý, đếm nhầm một tổng thể khác.

Thất bại điển hình của loại 2 không phải là “ra con số sai”. Mà là “ra con số đúng ở dạng không dùng được”. Điểm này là trọng tâm của bài viết nên sẽ có một chương riêng.

Nếu muốn bao gồm cả việc tìm kiếm và tóm tắt tài liệu, quy trình nội bộ, thì ngoài việc kết nối cơ sở dữ liệu bạn còn cần thiết kế một nền tảng tìm kiếm riêng. Lĩnh vực này trùng với các luận điểm được bàn trong bài thực hành xây dựng RAG. Kết nối tới dữ liệu số và tìm kiếm trên tài liệu là hai việc có phần chuẩn bị hoàn toàn khác nhau.

Loại 3. Phân tích tác tử – cái giá của tự chạy là các giả định giữa chừng

Đây là dạng AI tự dựng lấy trình tự và đi đến kết luận, xuyên qua nhiều nguồn như cơ sở dữ liệu sản lượng thực tế, hồ sơ kiểm tra chất lượng, hệ thống mua hàng và nhật ký vận hành thiết bị. Đây cũng là lĩnh vực mà số lượng đề xuất tăng vọt từ đầu năm 2026.

Về kỹ thuật thì đây là phần nối dài của loại 2, nhưng rủi ro trong thực tế thay đổi về chất. Tác tử chắc chắn sẽ phán đoán ở giữa đường. Những phán đoán kiểu “loại bỏ các dòng bị khuyết”, “đơn vị khác nhau nên quy đổi”, “số sê ri trùng thì lấy bản mới hơn”. Đây là những nội dung mà một chuyên viên phân tích sẽ ghi vào phần chú thích, nhưng chúng không xuất hiện trong đầu ra cuối cùng của tác tử.

Kết quả là thất bại của loại 3 mang hình dạng “kết luận thì có vẻ hợp lý, nhưng không ai giải thích nổi tổng thể nào đang chống đỡ cho kết luận đó”. Nếu loại 2 là “đáp án đúng ở dạng không dùng được”, thì loại 3 là “đáp án đúng không kiểm chứng được”.

Nếu muốn triển khai loại 3, ngoài việc loại 2 đã chạy ổn định, bạn còn phải thiết kế trước phần phân quyền (được chạm vào bảng nào, trong phạm vi nào) và phần kiểm toán (ghi lại đã chạy những truy vấn trung gian nào). Bỏ qua thứ tự này thì khi xảy ra sự cố sẽ không truy được nguyên nhân.

Loại 4. Sinh báo cáo – thực tế nhất, và cũng dễ bị chủ quan nhất

Số liệu tổng hợp đã có sẵn từ hệ BI hoặc bảng tính hiện hành. Chỉ giao cho AI phần việc chuyển những con số đó thành văn bản. Báo cáo chất lượng hằng tháng, báo cáo vận hành, bản tóm tắt cho họp ban lãnh đạo đều thuộc dạng này.

Trong khảo sát Teikoku Databank dẫn ở đầu bài, mục dẫn đầu là “soạn thảo, tóm tắt và hiệu đính văn bản” với 45.1%, và có thể cho rằng loại này chiếm phần khá lớn trong đó. Nói cách khác, các doanh nghiệp trên thực tế đã giao một phần của việc phân tích dữ liệu cho AI rồi. Chỉ là kèm điều kiện “không làm phần tổng hợp”.

Thất bại của loại 4 là ranh giới giữa sự thật và lời bình bị mờ đi. “Tỷ lệ lỗi là 0.35%” là sự thật, nhưng AI sẽ tự thêm từ đánh giá kiểu “đang có xu hướng cải thiện so với tháng trước” dù bạn không yêu cầu. Từ đánh giá đó không phải là kết quả tổng hợp, mà là sản phẩm sinh ra. Kết quả là một bản báo cáo mà con số thì đúng còn diễn giải thì bịa.

Biện pháp rất đơn giản: tách đoạn viết sự thật và đoạn viết đánh giá ngay trên mẫu biểu, và bắt buộc ghi tên người thật vào đoạn đánh giá. Cách vạch ranh giới “giao tới đâu cho máy, từ đâu con người tự cầm” này có cấu trúc giống hệt phần bàn về ranh giới của thao tác chuyển số trong bài tự động hóa công việc Excel bằng AI.

Quyết định độ chính xác là 3 điều kiện phía dữ liệu

Việc phân tích kết nối của loại 2 có suôn sẻ hay không, không được quyết định bởi bạn chọn mô hình nào. Thứ quyết định là dữ liệu ở đầu kết nối có thỏa mãn 3 điều kiện dưới đây hay không.

Từ vựng. NG_CD=07 chỉ cái gì, đã được viết thành tài liệu chưa?

Đây là điều kiện về việc tên cột, giá trị mã và từ viết tắt đã được định nghĩa ở dạng con người đọc được hay chưa.

Giả sử cột mã lỗi có tên NG_CD và giá trị là 07. Nhìn vào bảng dữ liệu, bạn không thể biết đó là “lỗi hàn thiếc”, “xước ngoại quan” hay “sai kích thước”. Ở nhiều nhà máy, bảng đối chiếu này nằm trong đầu một người kỳ cựu, hoặc nằm ở một sheet nào đó của tệp Excel làm cách đây 10 năm. AI tạo sinh, nếu không có bảng đối chiếu này, sẽ không biết 07 là gì.

Chỗ khó chịu là AI không nói “tôi không biết”. Nó suy đoán ý nghĩa từ tên cột và trả về một bảng tổng hợp nghe có vẻ đúng. Nó tự quyết định cột QTY là “số sản phẩm đạt” hay “số lượng đưa vào”, rồi tính tỷ lệ đạt. Dù suy đoán sai, đầu ra vẫn trông hoàn toàn bình thường.

Chuẩn hóa từ vựng, tóm lại, là viết ra những thứ sau. Với mỗi bảng, từng cột biểu diễn cái gì. Với các cột dùng giá trị mã, toàn bộ bảng đối chiếu giữa giá trị và ý nghĩa. Và bảng giải nghĩa các từ viết tắt chỉ nội bộ mới hiểu (WIP, ADJ, RTN, SCRAP và tương tự). Vùng dữ liệu nào không viết ra được 3 thứ này thì cách làm đúng là loại nó khỏi phạm vi phân tích kết nối.

Độ chi tiết. Một dòng biểu diễn cái gì, có định nghĩa được cả ngoại lệ không?

Điều kiện thứ hai là một dòng của bảng đang biểu diễn cái gì. Một dòng là một sản phẩm, một lô, một ca, hay một bản ghi kiểm tra. Những bảng trộn lẫn các mức này không hề hiếm trong thực tế.

Vấn đề lớn hơn nữa là định nghĩa ở phía ngoại lệ. Nếu 4 trường hợp sau chưa được định nghĩa, kết quả tổng hợp chắc chắn lệch.

• Trùng lặp: khi kết quả đo lại tạo thành 2 dòng, đếm cả hai hay chỉ đếm dòng mới hơn
• Hủy bỏ: việc hủy một lần nhập sai được ghi thành một dòng số lượng âm, hay được xử lý bằng cách xóa dòng gốc
• Đưa lại vào chuyền: khi cùng một số sê ri chạy lại lần nữa sau sửa chữa, số lượng đưa vào tính là 2 hay là 1
• Khuyết dữ liệu: trong khoảng thời gian thiết bị dừng thì bản thân dòng dữ liệu không xuất hiện, hay xuất hiện một dòng với giá trị 0

Đặc biệt khuyết dữ liệu là chỗ hay xảy ra sự cố nhất. Việc dòng không tồn tại và việc giá trị bằng 0 mang ý nghĩa khác nhau. Khi bảo AI tạo sinh tính trung bình, các khoảng thời gian không có dòng sẽ rơi khỏi mẫu số. Bạn muốn ra tỷ lệ vận hành, nhưng kết quả là đúng phần thời gian máy dừng đã biến mất khỏi phép tổng hợp.

Về việc thiết kế hồ sơ ghi chép để giữ được độ chi tiết này, chúng tôi đã sắp xếp trong bài thiết kế 3 lớp cho hệ quản lý dữ liệu chất lượng. Lý tưởng là dọn xong trước khi đưa AI tạo sinh vào, nhưng phần lớn trường hợp bạn sẽ phải khởi động song song.

Ranh giới. Từ lúc nào đến lúc nào là dữ liệu cùng một ý nghĩa

Điều kiện thứ ba là ranh giới thời gian. Dữ liệu từ lúc nào đến lúc nào được ghi theo cùng một định nghĩa.

Dữ liệu chủ của nhà máy có thay đổi. Tháng 10 năm 2025 đổi tên công đoạn. Gộp hệ mã lỗi lại, dồn mã cũ 07 và 09 thành mã mới 12. Đổi quy tắc đánh mã hàng. Mở rộng chuyền nên đánh lại ID thiết bị. Những lần sửa đổi như vậy xảy ra thường xuyên.

Vấn đề là lịch sử sửa đổi không được lưu lại. Khi dữ liệu chủ bị ghi đè, bạn sẽ phải diễn giải dữ liệu quá khứ bằng dữ liệu chủ hiện tại. Nếu nhờ AI tạo sinh “phân tích xu hướng lỗi 3 năm qua”, cái trả về sẽ là kết quả cộng gộp giai đoạn dùng hệ mã cũ và giai đoạn dùng hệ mã mới dưới cùng một cái tên. Xu hướng trông như đã đổi, nhưng thứ đổi không phải là hiện trường mà chỉ là hệ mã.

Chuẩn hóa ranh giới nghĩa là phải có những thứ sau. Lịch sử ngày sửa đổi và nội dung sửa đổi của dữ liệu chủ. Bảng đối chiếu giữa mã cũ và mã mới. Và ghi thẳng vào phía truy vấn hoặc phía câu lệnh một tuyên bố dạng “phân tích này chỉ lấy dữ liệu từ mốc thời gian này trở đi”.

Ba điều kiện này, nếu thiếu một thì hai cái còn lại không bù được. Có từ vựng mà độ chi tiết chưa định nghĩa thì bạn đếm nhầm số lượng dưới một cái tên đúng. Có độ chi tiết mà không có ranh giới thì bạn trộn nhầm giai đoạn bằng một cách đếm đúng. Phải đủ cả 3 thì đầu ra của phân tích kết nối mới dùng được cho quyết định nghiệp vụ.

Benchmark cho thấy giới hạn trên cơ sở dữ liệu thật

Khi nói về 3 điều kiện, phản ứng hay gặp là “vậy mô hình thông minh hơn thì giải quyết được chứ”. Điểm này có thể trả lời phần nào bằng con số từ các benchmark công khai.

Một benchmark tiêu biểu đo độ chính xác của việc sinh SQL từ ngôn ngữ tự nhiên là BIRD. Đây là benchmark có cấu trúc gần với cơ sở dữ liệu thật, gồm 12,751 cặp câu hỏi và SQL, 95 cơ sở dữ liệu, tổng cộng 33.4GB, bao phủ hơn 37 lĩnh vực.

Trên bảng xếp hạng của BIRD, độ chính xác thực thi trên tập test cao nhất cũng chỉ đạt 81.95%. Trên tập dev là 77.64% (cấu hình AskData cộng GPT-4o). Trong khi đó, human performance với cùng bài toán được ghi nhận ở mức 92.96.

Cách đọc con số 81.95% này cần thận trọng. Đây là “giá trị cao nhất trên benchmark của việc chuyển ngôn ngữ tự nhiên thành SQL đối với cơ sở dữ liệu thật”, chứ không thể khái quát thành “độ chính xác phân tích của AI tạo sinh là khoảng 80%”. Các câu hỏi trong benchmark được giải trong điều kiện đã được cung cấp sẵn phần mô tả lược đồ của cơ sở dữ liệu và kiến thức bên ngoài. Nghĩa là đây là con số trong điều kiện mà từ vựng và độ chi tiết nói ở chương trước đã được chính benchmark cấp sẵn.

Hơn nữa, khi chuyển sang bối cảnh có đối thoại và thao tác thực tế thì con số rơi mạnh. BIRD có một biến thể đi kèm đối thoại và thao tác thực tế là BIRD-Interact, và thành tích ở đó cao nhất cũng chỉ 24.4%, tùy cấu hình chỉ dừng ở mức 17.78%. Càng tiến gần tới công việc mà một chuyên viên phân tích thật sự làm, tức là vừa hỏi lại, vừa nhìn kết quả trung gian, vừa siết dần điều kiện, thì thành tích càng giảm.

Điều cần rút ra ở đây không phải là “AI tạo sinh không dùng được”. Mà là ngay cả khi lược đồ và từ vựng đã được chuẩn hóa, vẫn sai gần 20%. Còn nếu chưa chuẩn hóa thì không có gì để bàn. Tiến bộ của mô hình không thay thế được 3 điều kiện.

Dạng thất bại “đáp án đúng nhưng không dùng được”

Thất bại thực sự xảy ra ở hiện trường lại mang một hình dạng khó chịu hơn cả chuyện “ra con số sai”.

Bản kiểm chứng do AIMultiple công bố năm 2026 so sánh 36 mô hình trên 759 câu hỏi. Trong bản kiểm chứng này, khi đo bằng strict execution match (kết quả thực thi phải khớp chặt), điểm cao nhất cũng chỉ dừng ở 0.551. Con số này trông thấp hơn bảng xếp hạng của BIRD, nhưng đó là do mức độ khắt khe của tiêu chí đánh giá khác nhau.

Chỉ dẫn quan trọng nhất về mặt thực tiễn mà bản kiểm chứng đó đưa ra là điều này. Có mô hình rơi tới 22.7 điểm chỉ vì khác biệt ở phép chiếu. Khác biệt ở phép chiếu nghĩa là có cột thừa, thứ tự cột khác, hoặc đơn vị tổng hợp khác. Bản thân con số cần tìm thì đúng, nhưng hình dạng bảng trả về lại khác kỳ vọng. Chỉ vậy thôi là bị tính “sai”.

Ở hiện trường, cái này không được xử lý như một câu trả lời sai. Nó bị xử lý theo cách còn tệ hơn. Con người nhận về, mắt dò lấy đúng những cột cần, sắp lại thứ tự, quy về cùng đơn vị, rồi mới dùng. Nghĩa là phát sinh thao tác thủ công. Cơ chế đáng lẽ được đưa vào để tự động hóa lại đẻ ra một khâu hậu xử lý mỗi lần. Tệ hơn nữa, chính người đang làm hậu xử lý lại nhận thức rằng “AI trả lời đúng mà”, nên chuyện này không bao giờ được báo cáo như một vấn đề.

Hãy hình dung bằng một ví dụ ở nhà máy để thấy nó hiện ra dưới dạng nào. Giả sử bạn hỏi “cho tôi 5 công đoạn có giá trị thiệt hại do lỗi lớn nhất tháng trước”. Cái trả về là một bảng 5 dòng với 2 cột mã công đoạn và giá trị thiệt hại, sắp giảm dần theo giá trị. Con số thì đúng. Nhưng bảng này không đem ra họp được. Vì chỉ có mã công đoạn mà không có tên công đoạn. Người dự họp không thuộc mã công đoạn. Bạn hỏi tiếp “thêm cả tên công đoạn vào”, lần này nhận về 5 cột gồm tên công đoạn, mã công đoạn, giá trị thiệt hại, số vụ lỗi và kỳ dữ liệu, còn thứ tự dòng đã đổi thành thứ tự theo mã công đoạn. Con số vẫn đúng. Nhưng vì thứ tự cột khác với tài liệu tháng trước nên không xếp cạnh nhau để so sánh được.

Vòng đi vòng lại này xảy ra mỗi tháng. Mỗi lần thường chỉ mất khoảng 10 đến 15 phút nên không ai báo cáo như một vấn đề. Tuy vậy, nếu bạn đưa AI vào với mục tiêu cắt giảm giờ công làm báo cáo, thì vòng lặp này đang bị trừ vào phần thời gian tiết kiệm được. Lý do phần ước tính ở nửa sau bài viết đặt thời gian tiết kiệm của kịch bản A ở mức khiêm tốn là 12 giờ chính là vì đã tính cả vòng lặp này vào.

Lệch đơn vị tổng hợp cũng xảy ra theo đúng hình dạng đó. Khi bạn hỏi “tỷ lệ lỗi”, việc AI lấy số vụ lỗi chia cho số lượng đưa vào, hay lấy giá trị thiệt hại chia cho giá trị sản xuất, hay đưa ra tỷ lệ lô lỗi theo đơn vị lô kiểm tra, sẽ không được xác định nếu bạn không chỉ định. Cả 3 đều được gọi là “tỷ lệ lỗi” và cả 3 đều được tính đúng. Và các con số đương nhiên không khớp nhau. Việc chuẩn hóa từ vựng ở chương trước cũng chính là công việc để xóa đi sự mơ hồ này.

Cùng bản kiểm chứng đó còn chỉ ra rằng 31.1% các truy vấn gold của BIRD (những câu SQL được coi là đáp án đúng) có vấn đề. Bài báo tại CIDR 2026 phân tích các lỗi chú giải của benchmark cũng bàn về đúng vấn đề này. Nghĩa là bản thân định nghĩa của “đáp án đúng” cũng đang lung lay. Đây vừa là một luận điểm học thuật, vừa là một gợi ý cho thực tiễn. Chừng nào chưa định nghĩa “đáp án đúng” trong nội bộ, bạn không đo được tính đúng đắn.

Ba biện pháp dập tắt bằng thiết kế

Để giảm “đáp án đúng ở dạng không dùng được”, đừng đổi mô hình, hãy đặt ràng buộc ở phía đầu ra. Ba thứ sau có hiệu quả trong thực tế.

Thứ nhất, cố định trước hình dạng đầu ra. Hãy quyết định trước khi hỏi rằng sẽ xuất những cột nào, theo thứ tự nào, ở đơn vị tổng hợp nào. Với những câu hỏi hay dùng thì làm thành mẫu, và chỉ thị cho AI là “điền vào đúng hình dạng này”. Chỉ để nó xuất tự do khi đang thăm dò.

Thứ hai, luôn đặt một lớp kiểm tra chéo. Hãy chuẩn bị một truy vấn cố định để đối chiếu với giá trị đã biết. Ví dụ chọn một con số đã chốt qua hệ thống khác (như biểu mẫu chốt sổ hằng tháng), chẳng hạn “tổng số lượng đưa vào của tháng trước”, rồi bắt AI xuất cùng con số đó từ tổng thể mà nó đã dùng và xem có khớp không. Không khớp thì vứt bỏ kết quả phân tích đó. Có hay không có một đường kiểm tra chéo này làm thay đổi hoàn toàn mức an toàn của vận hành.

Thứ ba, thứ bắt AI xuất ra không phải là “con số” mà là “con số cộng với định nghĩa phạm vi đã tạo ra con số đó”. Hãy bắt buộc ghi kèm ở cuối đầu ra: kỳ dữ liệu, công đoạn đối tượng, điều kiện của các dòng đã loại bỏ, và phiên bản dữ liệu chủ đã dùng. Có phần này thì người nhìn con số mới tự phán đoán được tính hợp lý của tổng thể. Không có thì người duy nhất phán đoán được là chính người đã tạo ra con số.

Cả 3 thứ này đều không liên quan đến việc chọn mô hình. Dùng mô hình nào cũng cần và dùng mô hình nào cũng hiệu quả. Nói ngược lại, so sánh mô hình mà chưa đặt 3 thứ này thì việc so sánh vô nghĩa.

Bốn điểm vỡ thêm tại cơ sở ở Việt Nam

Những gì nói ở trên là điểm chung với cả các nhà máy tại Nhật Bản. Khi bạn có cơ sở sản xuất tại Việt Nam, sẽ có thêm 4 yếu tố chồng lên.

Trộn lẫn ngôn ngữ là yếu tố thứ nhất. Không hiếm những bảng dữ liệu mà tên cột bằng tiếng Anh, phần giải thích giá trị phân loại bằng tiếng Nhật, còn ô nhập tự do thực tế lại được điền bằng tiếng Việt. Cùng một hiện tượng “lỗi ngoại quan” được ghi theo 3 kiểu tiếng Nhật, tiếng Anh và tiếng Việt. Còn phải kể tới việc tiếng Việt nhập không dấu hoặc sai dấu tạo ra thêm biến thể của cùng một chuỗi. AI tạo sinh sẽ đếm tất cả như những thứ khác nhau. Trước khi dựng đơn vị tổng hợp, bạn cần một bảng đối chiếu chuẩn hóa.

Lịch ca và kỳ nghỉ dài là yếu tố thứ hai. Tết Nguyên đán là chỗ dễ vỡ nhất, vì nó rơi vào ngày dương lịch khác nhau mỗi năm và thường kéo dài qua ranh giới tháng, khiến số ngày làm việc của tháng 1 và tháng 2 dao động mạnh giữa các năm. Nghỉ lễ Giỗ Tổ Hùng Vương cũng trượt theo âm lịch. Thêm vào đó, tại cơ sở chạy 3 ca 24 giờ, thời điểm chuyển ngày và thời điểm chuyển ca không trùng nhau. Khi tính “tỷ lệ lỗi tháng này”, việc ca cuối cùng của cuối tháng được tính sang tháng sau hay tính vào tháng này là quy tắc riêng của từng cơ sở. Nếu quy tắc đó chưa nằm trong dữ liệu chủ, AI sẽ cắt theo ngày lịch. Biểu mẫu sản lượng thực tế lại được cắt theo lịch ca, nên hai bên chắc chắn vênh nhau. Và theo kinh nghiệm, độ vênh thường chỉ ở mức nhỏ nên nhìn bằng mắt thì không phát hiện được. So sánh cùng kỳ giữa các năm cũng cần một lịch làm việc theo nhà máy, chứ không phải số ngày trong tháng.

Dữ liệu chủ cập nhật bằng tay là yếu tố thứ ba. Rất hay gặp trường hợp dữ liệu chủ mã hàng, dữ liệu chủ công đoạn và dữ liệu chủ mã lỗi được quản lý trên Excel của một nhân viên phụ trách, và bị ghi đè mỗi lần cập nhật. Ở trạng thái này thì “ranh giới” ở chương trước về nguyên tắc là không dựng được. Trước khi đưa AI tạo sinh vào, ít nhất bạn phải đổi cách vận hành sang việc ghi bổ sung ngày sửa đổi và nội dung sửa đổi vào một sheet riêng. Đặc biệt với doanh nghiệp có nhiều nhà máy tại miền Bắc và miền Nam, mỗi cơ sở lại sửa dữ liệu chủ theo cách riêng mà không nơi nào giữ lại lịch sử, thì việc gộp số liệu giữa các cơ sở sẽ không có căn cứ. Hãy quyết định trước nơi nắm bản chính của dữ liệu chủ và cách phát tán sửa đổi tới các cơ sở.

Bản thân nguồn dữ liệu là yếu tố thứ tư. Nếu sản lượng thực tế từ thiết bị được nhập tay mỗi ngày một lần thông qua báo cáo giấy, thì việc theo dõi theo ngày là bất khả thi. Đây là vấn đề về tần suất dữ liệu xuất hiện, nằm trước cả AI tạo sinh. Về quy mô đầu tư khi lấy sản lượng tự động từ phía thiết bị, chúng tôi đã bàn trong bài phân rã chi phí IoT nhà máy thành 5 lớp.

Để tham chiếu mức độ trưởng thành số của thị trường ASEAN lân cận, có thể nhìn số liệu Thái Lan. Trong Thailand Digital Outlook 2026 của ETDA (Cơ quan Phát triển Giao dịch Điện tử Thái Lan), điểm trưởng thành số của doanh nghiệp Thái Lan được báo cáo ở mức 2.12 trên thang 4 điểm. Con số này tăng so với 1.56 của năm trước, với 834 doanh nghiệp được khảo sát. Xin lưu ý 2.12 là điểm trưởng thành số, không phải tỷ lệ triển khai AI. Có cải thiện, nhưng chỉ vừa vượt qua một nửa của thang 4 điểm. Đây là số liệu của thị trường Thái Lan và không đại diện cho Việt Nam, nên chỉ nên dùng như một mốc tham chiếu khu vực.

Về bản thân việc triển khai AI, khảo sát ETDA Thái Lan năm 2024 (580 doanh nghiệp Thái Lan) đưa ra con số 18% đã triển khai và 73% đang cân nhắc. Trong khảo sát đó, rào cản triển khai được nêu ra là lo ngại về chất lượng dữ liệu. Nội dung chỉ dẫn này trùng khớp với câu chuyện 3 điều kiện đã trình bày từ đầu bài.

Ước tính chi phí và hoàn vốn theo 3 kịch bản

Từ đây là phần tiền bạc. Toàn bộ các con số dưới đây là phần tự dựng của bài viết này, không phải mặt bằng giá thị trường. Hãy đọc và thay bằng điều kiện của chính công ty bạn.

Mô hình được dựng trên một nhà máy Nhật Bản tại Thái Lan, nơi TOMAS TECH có kinh nghiệm triển khai trực tiếp, và giữ nguyên đơn vị THB nên các con số truy được về nguồn. Cơ cấu chi phí tại nhà máy ở Việt Nam khác về mức tuyệt đối, nhưng quan hệ giữa 3 kịch bản thì giữ nguyên. Hãy thay đơn giá giờ công và mức thiệt hại mỗi vụ lỗi bằng số của chính cơ sở bạn, còn cấu trúc thì đọc nguyên.

Các giả định như sau.

• Nhà máy Nhật Bản tại Thái Lan, quy mô 300 nhân sự, sản lượng năm 1,200,000 sản phẩm
• Việc làm báo cáo lỗi và vận hành hằng tháng tiêu tốn 2 nhân sự quản lý sản xuất, mỗi người 20 giờ một tháng, tổng cộng 40 giờ một tháng
• Lương tháng của nhân viên 25,000 THB, làm việc 160 giờ một tháng. Đơn giá giờ là 25,000 chia 160 bằng 156.25, làm tròn xuống thành 156 THB
• Thiệt hại cho mỗi vụ lỗi được đặt ở 180 THB, gồm chi phí vật tư, giờ công sửa chữa và điều chỉnh giao hàng
• Tỷ lệ lỗi hiện tại là 0.35%

Xin nói trước về đơn giá giờ 156 THB. Đây là cận dưới, không phải căn cứ hoàn vốn. Nó chỉ là con số quy đổi ra tiền lương của thời gian đang bị dùng để làm báo cáo. Trên thực tế còn có phần tổn thất cơ hội, tức là lẽ ra thời gian đó có thể dùng cho một cải tiến khác, và phần đó nhiều khả năng còn lớn hơn. Nhưng tổn thất cơ hội cho ra biên độ ước tính rộng, nên bài viết này cố ý chỉ dùng cận dưới. Hãy đọc theo hướng: nếu có kịch bản nào đứng vững chỉ với quy đổi tiền lương, thì kịch bản đó là chắc chắn.

Với giả định đó, chúng ta so sánh 3 kịch bản khác nhau về phạm vi chuẩn hóa.

Chỉ nhìn bảng thì chưa hiểu vì sao lại ra như vậy. Dưới đây là phần phân rã phép tính theo từng kịch bản, ở dạng bấm máy tính là theo được.

Kịch bản A. Dán dữ liệu toàn công ty

Cấu hình phát tài khoản AI tạo sinh cho toàn bộ các phòng ban, chỉ chuẩn bị bảng từ vựng và mẫu câu lệnh. Không kết nối cơ sở dữ liệu. Mỗi người tự dán tệp CSV của mình để dùng.

Chi phí ban đầu 60,000 THB là giờ công cho việc lập bảng từ vựng, soạn mẫu câu lệnh và tổ chức buổi phổ biến nội bộ. Vận hành năm 30,000 THB là phí bản quyền và duy trì bảng từ vựng.

Lợi ích được tính như sau. Trong 40 giờ một tháng đang bỏ ra để làm báo cáo, phần cắt giảm được nhờ phân tích dán dữ liệu đặt ở 12 giờ. Vì khâu chuẩn bị số liệu tổng hợp rốt cuộc vẫn làm tay, phần cắt giảm được chỉ là khâu diễn giải thành văn và chỉnh trang hình thức.

12 giờ một tháng nhân 12 tháng bằng 144 giờ. 144 giờ nhân 156 THB bằng 22,464 THB.

Đó là lợi ích năm. Nó thấp hơn chi phí vận hành năm 30,000 THB. Lợi ích ròng là 22,464 trừ 30,000 bằng -7,536 THB. Chưa nói tới việc thu hồi 60,000 THB ban đầu, đây là cấu trúc mà mỗi năm lỗ lại chồng thêm.

Điều không nên hiểu nhầm là bài viết không nói kịch bản A vô giá trị. Với mục đích sinh văn bản và tóm tắt, nó dư sức hoàn vốn. Ý nghĩa của ước tính này là khi đo giới hạn trong đúng mục đích “phân tích dữ liệu” thì nó lỗ. Một phần bối cảnh khiến tổng hợp và phân tích dữ liệu chỉ dừng ở 7.4% trong số liệu Teikoku Databank ở đầu bài nằm ở đây.

Kịch bản B. Kết nối toàn bộ dữ liệu

Cấu hình chuẩn hóa 3 điều kiện từ vựng, độ chi tiết và ranh giới cho toàn bộ hệ thống quản lý sản xuất, cơ sở dữ liệu chất lượng và nhật ký vận hành thiết bị, rồi kết nối từ AI tạo sinh. Đây là tư duy gần với cái thường được gọi là nền tảng dữ liệu toàn công ty.

Chi phí ban đầu 450,000 THB gồm dọn dữ liệu chủ cho toàn bộ công đoạn, lập bảng đối chiếu mã, định nghĩa độ chi tiết, chuẩn hóa lịch sử sửa đổi dữ liệu chủ, cùng việc xây kết nối và lớp kiểm tra chéo. Vận hành năm 120,000 THB gồm bản quyền, vận hành nền tảng và công việc phản ánh các lần sửa dữ liệu chủ.

Lợi ích gồm 2 thành phần.

Thứ nhất là cắt giảm giờ công. Trong 40 giờ một tháng, đặt phần cắt giảm được ở 28 giờ. Vì khâu tổng hợp cũng lấy được bằng phân tích kết nối nên con số lớn hơn hẳn kịch bản A.

28 giờ một tháng nhân 12 tháng bằng 336 giờ. 336 giờ nhân 156 THB bằng 52,416 THB.

Thứ hai là giảm lỗi. Nhờ dữ liệu trở nên nhìn thấy được, đặt giả định tỷ lệ lỗi giảm từ 0.35% xuống 0.30%. Chênh lệch là 0.05 điểm.

1,200,000 sản phẩm nhân 0.0005 bằng 600 sản phẩm. 600 sản phẩm nhân 180 THB bằng 108,000 THB.

Cộng lại, 52,416 cộng 108,000 bằng 160,416 THB là lợi ích năm. Trừ đi chi phí vận hành năm 120,000 THB, ta có 160,416 trừ 120,000 bằng 40,416 THB là lợi ích ròng mỗi năm.

Số năm thu hồi chi phí ban đầu là 450,000 chia 40,416, khoảng 11.1 năm. Đây không phải con số duyệt được với tư cách một khoản đầu tư thiết bị.

Kịch bản C. Kết nối giới hạn 1 chủ đề

Cấu hình thu hẹp đối tượng vào 3 công đoạn có giá trị thiệt hại do lỗi lớn nhất, chỉ chuẩn hóa từ vựng, độ chi tiết và ranh giới cho 3 công đoạn đó rồi kết nối. Các công đoạn còn lại trước mắt vẫn giữ nguyên ở loại 1 là phân tích dán dữ liệu.

Chi phí ban đầu 180,000 THB gồm dọn dữ liệu chủ và kết nối cho 3 công đoạn, cùng việc xây một đường kiểm tra chéo. Vận hành năm 60,000 THB gồm bản quyền và duy trì dữ liệu chủ cho 3 công đoạn.

Phần cắt giảm giờ công nhỏ hơn kịch bản B. Vì đối tượng chỉ có 3 công đoạn, đặt phần cắt giảm được trong việc làm báo cáo ở 16 giờ.

16 giờ một tháng nhân 12 tháng bằng 192 giờ. 192 giờ nhân 156 THB bằng 29,952 THB.

So với 52,416 THB của kịch bản B, mức cắt giảm chưa tới 60%. Đến đây thì kịch bản B trông có vẻ trội hơn.

Phần giảm lỗi tạo ra sự đảo chiều. Vì đối tượng đã thu về 3 công đoạn nên có thể theo dõi theo ngày. Do ngày nào cũng nhìn, đặt giả định thời gian từ lúc bất thường xuất hiện tới lúc bắt tay khắc phục rút ngắn trung bình 2 tuần. Kết quả là giả định tỷ lệ lỗi giảm từ 0.35% xuống 0.28%. Chênh lệch là 0.07 điểm.

1,200,000 sản phẩm nhân 0.0007 bằng 840 sản phẩm. 840 sản phẩm nhân 180 THB bằng 151,200 THB.

Cộng lại, 29,952 cộng 151,200 bằng 181,152 THB. Trừ chi phí vận hành năm 60,000 THB, ta có 181,152 trừ 60,000 bằng 121,152 THB là lợi ích ròng mỗi năm.

Số năm thu hồi là 180,000 chia 121,152, xấp xỉ 1.49 năm. Quy ra tháng là 17.8 tháng.

Càng mở rộng phạm vi chuẩn hóa thì hoàn vốn càng xa

Xếp 3 kịch bản cạnh nhau, ta thấy một kết quả đi ngược trực giác.

Kịch bản B có thời gian cắt giảm lớn nhất mà mất 11.1 năm để hoàn vốn, còn kịch bản C dù thời gian cắt giảm chưa tới 60% của B lại hoàn vốn trong 17.8 tháng.

Thứ tạo ra khác biệt không phải là giờ công. Giá trị cắt giảm giờ công của B là 52,416 THB, của C là 29,952 THB, đúng là B cao hơn. Thứ gây ra đảo chiều là giá trị giảm lỗi, với B là 108,000 THB còn C là 151,200 THB.

Vì sao kịch bản C thu hẹp đối tượng lại có phần giảm lỗi lớn hơn? Lý do là việc khắc phục có nhanh lên hay không chỉ đúng khi đối tượng được thu hẹp.

Dù dữ liệu của toàn bộ công đoạn trở nên nhìn thấy được, số chỉ số mà con người thực sự nhìn mỗi ngày cũng không tăng lên. Một bảng điều khiển cập nhật 20 chỉ số theo ngày, trong thực tế, sẽ trở thành thứ được ngó qua gộp một lần mỗi tuần. Ngược lại, việc mỗi sáng chỉ nhìn tỷ lệ lỗi của 3 công đoạn thì duy trì được. Duy trì được nên phát hiện bất thường sớm hơn. Phát hiện sớm nên khắc phục sớm. Khắc phục sớm bao nhiêu thì lỗi giảm bấy nhiêu. Chuỗi liên hoàn này chỉ xảy ra khi đối tượng cần nhìn đã được thu hẹp.

Nói cách khác, nhân tố chính của lợi ích không phải là “dữ liệu nhìn thấy được” mà là “hành vi thay đổi“. Và việc hành vi có thay đổi hay không thì tương quan nghịch với độ rộng của phạm vi chuẩn hóa.

Còn một điểm nữa, kịch bản B mang một gánh nặng mang tính cấu trúc. Trong 120,000 THB vận hành năm, một phần đáng kể là công việc phản ánh các lần sửa dữ liệu chủ. Càng chuẩn hóa nhiều công đoạn thì mỗi lần sửa dữ liệu chủ lại càng nhiều chỗ phải chỉnh. Nghĩa là kịch bản B có cấu trúc mà lợi ích thì chạm trần trong khi chi phí vận hành cứ tăng tỷ lệ thuận với phạm vi đối tượng. Chính sự bất đối xứng này tạo ra con số 11.1 năm.

Do đó, quyết định đầu tư vào phân tích dữ liệu bằng AI tạo sinh không phải là quyết định “chuẩn hóa tới đâu” mà là quyết định “quyết định không chuẩn hóa chỗ nào“. Dự án nào không chỉ ra được một cách tường minh phạm vi sẽ không chuẩn hóa thì sẽ đi theo lộ trình của kịch bản B.

Về bản thân cách đo hiệu quả như trong ước tính này, tức là thiết kế xem cái gì được tính vào lợi ích và cái gì không, chúng tôi đã sắp xếp khung tư duy trong bài đo lường hiệu quả triển khai AI. Bài đó hữu ích khi bạn thay các giả định của ước tính bằng điều kiện của công ty mình.

Bảng phán đoán nên bắt đầu từ loại nào

Dưới đây là toàn bộ nội dung tới đây, gói lại thành hình dạng của một quyết định thực tế. Việc phán đoán chỉ rẽ nhánh bằng 2 câu hỏi.

Câu hỏi thứ nhất. Bạn đã thu về được 1 chỉ số đáng theo dõi theo ngày chưa? “Thu về được” nghĩa là đã xác định luôn cả việc ai sẽ làm gì khi chỉ số đó xấu đi. Những chỉ số chỉ để nhìn cho biết thì không tính.

Câu hỏi thứ hai. Hôm nay bạn có viết ra được từ vựng, độ chi tiết và ranh giới của chỉ số đó không? Cụ thể là ý nghĩa của các cột cấu thành chỉ số đó, bảng đối chiếu giá trị mã, một dòng biểu diễn cái gì, cách xử lý ngoại lệ, và từ mốc nào trở đi dữ liệu có cùng định nghĩa. Câu hỏi là bạn có thể biến chúng thành tài liệu ngay trong hôm nay hay không.

Hai câu trả lời này quyết định loại nào nên bắt tay.

Trong bảng này, số doanh nghiệp rơi vào ô “nên bắt tay vào loại 2” trên thực tế không nhiều. Phần lớn thuộc dòng thứ hai hoặc dòng thứ tư. Và đó không phải là thất bại, mà là việc nắm đúng vị trí hiện tại của mình. Nếu đặt hàng loại 2 khi chưa viết ra được 3 điều kiện, bạn sẽ bước vào lộ trình của kịch bản B.

Về cách tiến hành cho trường hợp rơi vào dòng thứ hai, xin bổ sung thêm. Việc chuẩn hóa 3 điều kiện, nếu làm trên phạm vi toàn công ty, sẽ thành đúng kịch bản B của bài viết này. Để tránh, hãy giới hạn đơn vị chuẩn hóa ở đúng “những bảng mà 1 chỉ số đã thu hẹp tham chiếu tới”. Về mặt thực hành, hãy liệt kê ra đúng những cột được dùng trực tiếp để tính chỉ số đối tượng, và chỉ lập ý nghĩa cùng bảng đối chiếu mã cho những cột đó. Các cột khác trong cùng bảng thì không đụng vào. Việc bạn có chấp nhận được sự dứt khoát này hay không chính là thứ phân định giữa 17.8 tháng và 11.1 năm.

Ngoài ra, hãy lưu lại sản phẩm của việc chuẩn hóa dưới dạng tài liệu. Nếu chỉ nhúng vào bên trong câu lệnh của AI tạo sinh, chúng sẽ biến mất khi bạn đổi mô hình hoặc chuyển sang công cụ khác. Ba thứ gồm bảng từ vựng, định nghĩa độ chi tiết và tuyên bố ranh giới là tài sản độc lập với công cụ. Công cụ thì vài năm sẽ thay, nhưng 3 thứ này thì không thay. Thực thể của khoản đầu tư nằm ở đây chứ không nằm ở công cụ.

Loại 3, tức phân tích tác tử, không xuất hiện ở bất cứ đâu trong bảng này. Vì nó là đối tượng chỉ nên xem xét sau khi loại 2 đã chạy ổn định, lớp kiểm tra chéo đã hoạt động, và thiết kế phân quyền cùng kiểm toán đã xong. Nếu bạn đang ở giai đoạn nhận đề xuất, hãy đặt điều kiện là phải có thành tích của loại 2 trước.

Ngoài ra, phân tích bằng AI tạo sinh và các mô hình thống kê hay học máy kiểu dự báo nhu cầu là hai câu chuyện khác nhau. Chuyện đi đoán giá trị tương lai được bàn trong bài về AI dự báo nhu cầu, ở đó cả điều kiện dữ liệu cần thiết lẫn phương pháp đánh giá đều khác bài này. Lẫn lộn hai thứ sẽ làm hỏng khâu định nghĩa yêu cầu.

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

Để AI tạo sinh phân tích dữ liệu thì cần dữ liệu như thế nào?

Cần định nghĩa chứ không cần khối lượng. Cụ thể là 3 thứ: phần mô tả từng cột của bảng đối tượng biểu diễn cái gì, bảng đối chiếu giá trị và ý nghĩa cho các cột dùng giá trị mã, và định nghĩa về việc một dòng biểu diễn cái gì cùng cách xử lý ngoại lệ (trùng lặp, hủy bỏ, đưa lại vào chuyền, khuyết dữ liệu). Ngoài ra hãy chốt ranh giới về việc từ mốc nào trở đi dữ liệu được ghi theo cùng một định nghĩa. Phạm vi nào không viết ra được 4 thứ này thì dù có bao nhiêu dữ liệu cũng không trở thành đối tượng của phân tích kết nối. Ngược lại, nếu đủ 4 thứ này thì chỉ 3 công đoạn cũng đã làm được. Thứ tự bắt tay không phải là tăng dữ liệu, mà là viết ra định nghĩa của dữ liệu đang có.

Phân tích dữ liệu bằng AI tạo sinh có thay thế được Excel không?

Nó không thay thế được khâu tổng hợp, nhưng phần trước và sau khâu tổng hợp thì có. Phần trước là thăm dò. Việc đoán hướng xem nên nhìn theo lát cắt nào sẽ nhanh hơn so với dựng lại bảng tổng hợp trên phần mềm bảng tính. Phần sau là diễn giải thành văn. Việc đưa những con số đã tổng hợp vào hình dạng báo cáo hoàn toàn có thể giao đi nếu bạn cố định mẫu. Ngược lại, bản thân việc tổng hợp để ra con số chốt thì đòi hỏi tính tái lập và tính kiểm chứng được, nên để nguyên trong hệ thống sẵn có là an toàn. Kịch bản C của bài viết này cũng không dựa trên tiền đề vứt bỏ nền tảng tổng hợp, mà được dựng theo hướng đặt phần truy vấn và phần diễn giải thành văn lên trên nền tảng đó.

Có thể giao việc tự động tạo báo cáo tới đâu?

Tới phần mô tả sự thật. Hãy tách riêng phần đánh giá và phán đoán. “Tỷ lệ lỗi là 0.35%” là thao tác chép lại kết quả tổng hợp nên giao được. “Đang có xu hướng cải thiện so với tháng trước” là một sản phẩm sinh ra. Dù diễn biến số liệu giống nhau, việc có gọi đó là cải thiện hay không là vấn đề của giá trị mục tiêu và bối cảnh, mà AI thì không biết những thứ đó. Biện pháp thực tế là tách mẫu biểu thành đoạn sự thật và đoạn đánh giá, rồi vận hành theo cách ghi tên người điền vào đoạn đánh giá. Thêm một điểm nữa, hãy bắt buộc ghi kèm ở cuối đầu ra kỳ dữ liệu, công đoạn đối tượng, điều kiện loại trừ và phiên bản dữ liệu chủ đã dùng. Báo cáo thiếu phần này thì người đọc không kiểm chứng được tổng thể.

Công cụ BI và AI tạo sinh, nên đưa cái nào vào trước?

Điểm quan trọng không phải là thứ tự, mà là cả hai đều đòi hỏi cùng một sự chuẩn bị. Cả BI lẫn AI tạo sinh đều không cho ra con số đúng nếu từ vựng, độ chi tiết và ranh giới chưa được định nghĩa. BI thì dù định nghĩa sai vẫn tái hiện đúng cái sai đó mỗi lần, nên rồi sẽ có người nhận ra. AI tạo sinh thì có khoảng trống để diễn giải khác nhau ở mỗi lần hỏi, nên cái sai không tái hiện và việc phát hiện bị chậm lại. Dựa trên khác biệt này, cách phân công thực tế là đặt mục đích ra con số chốt ở BI hoặc biểu mẫu sẵn có, còn AI tạo sinh đặt ở khâu thăm dò và diễn giải thành văn. Trước khi quyết định mua cái nào, hãy bắt tay vào việc viết ra 3 điều kiện. Công việc này cần thiết dù bạn chọn bên nào.

Dữ liệu ở nhà máy Việt Nam trộn lẫn tiếng Việt thì có phân tích được không?

Phân tích được, nhưng phải lập bảng đối chiếu chuẩn hóa trước. Thứ gây vấn đề trong thực tế không phải là mô hình có đọc được tiếng Việt hay không. Mà là cùng một hiện tượng đang được ghi theo 3 kiểu tiếng Nhật, tiếng Anh và tiếng Việt, rồi bị tổng hợp như những thứ khác nhau. Riêng tiếng Việt còn có thêm biến thể do nhập không dấu hoặc sai dấu, làm số lượng cách viết của cùng một nội dung tăng thêm. Hãy lập bảng đối chiếu quy các cách viết khác nhau về một giá trị chuẩn duy nhất, cho 3 nhóm là phân loại lỗi, lý do dừng máy và tên công đoạn. Hãy tránh lấy thẳng ô nhập tự do làm đối tượng tổng hợp, và thêm một cột giá trị phân loại dạng chọn từ danh sách. Đó mới là đường tắt thật sự. Ngoài ra hãy giữ lịch ca và lịch nghỉ lễ dưới dạng dữ liệu chủ. Tết Nguyên đán rơi vào ngày dương lịch khác nhau mỗi năm và kéo dài qua ranh giới tháng, nên nếu thay thế bằng ngày lịch thông thường thì kỳ tổng hợp sẽ lệch khỏi biểu mẫu sản lượng thực tế.

Tóm tắt

Dưới đây là các luận điểm của bài viết, sắp xếp lại.

• Ngay cả trong nhóm doanh nghiệp đang dùng AI tạo sinh cho công việc, mục đích “tổng hợp và phân tích dữ liệu” chỉ dừng ở 7.4% (Teikoku Databank, tháng 3 năm 2026, 10,312 doanh nghiệp trả lời hợp lệ). Bằng một phần sáu mục dẫn đầu là “soạn thảo, tóm tắt và hiệu đính văn bản” 45.1%. Con số 7.4% này không phải tỷ lệ trên toàn bộ doanh nghiệp mà là tỷ trọng mục đích trong nhóm doanh nghiệp đang sử dụng
• Lý do mảng này không tăng không phải thiếu nhu cầu, mà là đã thử rồi nhưng không thông. Thất bại của phân tích dữ liệu, khác với sinh văn bản, không thể nhìn bằng mắt mà biết
• “Phân tích dữ liệu bằng AI tạo sinh” chia thành 4 loại: phân tích dán dữ liệu, phân tích kết nối, phân tích tác tử và sinh báo cáo. Thứ phải chuẩn bị và kiểu thất bại đều khác nhau, nên trộn lại mà bàn thì không ăn khớp
• Quyết định độ chính xác là 3 điều kiện phía dữ liệu chứ không phải mô hình. Từ vựng (NG_CD=07 là gì đã được viết thành tài liệu chưa), độ chi tiết (một dòng biểu diễn cái gì, xử lý trùng lặp, hủy bỏ, đưa lại vào chuyền, khuyết dữ liệu ra sao), ranh giới (từ lúc nào đến lúc nào là cùng một định nghĩa, lịch sử sửa dữ liệu chủ có được lưu không)
• Việc chuyển ngôn ngữ tự nhiên thành SQL trên cơ sở dữ liệu thật, ngay cả giá trị cao nhất trên benchmark cũng chỉ đạt test 81.95% (BIRD), chưa chạm tới human performance 92.96. Ở BIRD-Interact là bối cảnh có đối thoại và thao tác thực tế, cao nhất chỉ 24.4%, tùy cấu hình chỉ ở mức 17.78%
• Thứ xảy ra ở hiện trường là thất bại “ra con số đúng ở dạng không dùng được” nhiều hơn là “ra con số sai”. Có mô hình rơi 22.7 điểm chỉ vì khác biệt ở phép chiếu (cột thừa, khác thứ tự cột, khác đơn vị tổng hợp) (AIMultiple, năm 2026, 36 mô hình nhân 759 câu hỏi)
• Biện pháp là cố định trước hình dạng đầu ra, đặt một lớp kiểm tra chéo, và bắt xuất kèm con số cùng định nghĩa phạm vi đã tạo ra con số đó. Cả 3 đều hiệu quả không phụ thuộc việc chọn mô hình
• Tại cơ sở ở Việt Nam có thêm 4 yếu tố chồng lên: trộn lẫn ngôn ngữ, lịch ca và kỳ nghỉ dài như Tết Nguyên đán làm vỡ kỳ tổng hợp, dữ liệu chủ cập nhật bằng tay không lưu lịch sử sửa đổi giữa các cơ sở, và tần suất của nguồn dữ liệu. Như một mốc tham chiếu khu vực, Thailand Digital Outlook 2026 của ETDA báo cáo mức trưởng thành số của doanh nghiệp Thái Lan là 2.12 trên thang 4 điểm (năm trước 1.56, 834 doanh nghiệp). Đây là điểm trưởng thành số chứ không phải tỷ lệ triển khai AI, và là số liệu Thái Lan chứ không phải Việt Nam
• Trong ước tính 3 kịch bản, kịch bản B kết nối toàn bộ dữ liệu hoàn vốn 11.1 năm, còn kịch bản C thu về 1 chủ đề hoàn vốn 17.8 tháng. Thứ tạo ra khác biệt không phải giá trị cắt giảm giờ công, mà là lượng lỗi giảm đi nhờ khắc phục nhanh hơn. Phần này chỉ lớn khi đối tượng được thu hẹp. Toàn bộ số tiền là phần tự dựng của bài viết này, không phải mặt bằng thị trường
• Do đó quyết định đầu tư không phải là “chuẩn hóa tới đâu” mà là “quyết định không chuẩn hóa chỗ nào”. Dự án nào không chỉ ra được phạm vi sẽ không chuẩn hóa thì sẽ đi theo lộ trình hoàn vốn xa

Việc phân tích dữ liệu bằng AI tạo sinh không thông không phải vì hiệu năng mô hình còn thiếu. Mà vì ý nghĩa của dữ liệu bạn đưa cho nó chưa từng được viết thành tài liệu, ngay cả trong nội bộ. Và việc viết thành tài liệu đó, nếu làm gộp toàn công ty, sẽ đẩy hoàn vốn ra xa. Nếu thu về đúng 1 chỉ số, con số 17.8 tháng bắt đầu hiện ra.

TOMAS TECH xây dựng nền tảng quản lý sản xuất và dữ liệu chất lượng cho các nhà máy Nhật Bản tại ASEAN, bao gồm cả các cơ sở tại Việt Nam. Chúng tôi có thể hỗ trợ ngay từ giai đoạn trước khi bàn tới kết nối, tức là cùng bạn kiểm kê xem có thu về được 1 chỉ số đáng theo dõi theo ngày hay không, và hôm nay có viết ra được từ vựng, độ chi tiết và ranh giới của chỉ số đó hay không. Giai đoạn chưa chọn sản phẩm, hay giai đoạn còn chưa rõ dữ liệu nào dùng được, đều không sao. Nếu bạn muốn xác nhận dữ liệu của công ty mình có chịu được phân tích kết nối hay không, hãy trao đổi với chúng tôi qua trang liên hệ.

Nguồn tham khảo

• Teikoku Databank – Khảo sát xu hướng doanh nghiệp về AI tạo sinh, tháng 3 năm 2026 (生成AIに関する企業の動向調査)
• Trang chính thức của benchmark BIRD
• AIMultiple – Text-to-SQL Comparison of LLM Accuracy in 2026
• CIDR 2026 – Text-to-SQL Benchmarks are Broken, An In-Depth Analysis of Annotation Errors
• Bangkok Post – AI adoption helps Thai firms become digitally mature
• Bangkok Post – Data quality concerns a barrier to adoption of AI