Câu trả lời ngắn gọn là: dữ liệu của doanh nghiệp được coi là đủ tốt để triển khai AI khi nó đầy đủ, chính xác, nhất quán, kịp thời, đại diện cho thực tế cần dự đoán và được thu thập, sử dụng hợp pháp — và khi doanh nghiệp đo được các tiêu chí này bằng số liệu cụ thể, chứ không chỉ cảm thấy dữ liệu của chúng ta chắc là ổn. Bài viết này hướng dẫn cách đánh giá dữ liệu cho AI một cách có hệ thống: vì sao dữ liệu quyết định thành bại của dự án AI, sáu chiều chất lượng dữ liệu cần kiểm tra, quy trình kiểm tra từng bước, cách đánh giá dữ liệu phi cấu trúc như văn bản, hình ảnh và ghi âm, bảng chấm điểm mức độ sẵn sàng dữ liệu, lộ trình cải thiện dữ liệu trước khi triển khai AI, và cách nhận biết khi nào nên bắt đầu — hay khi nào phải dừng lại làm dữ liệu trước.
Đây là câu hỏi mà hầu hết doanh nghiệp đều trả lời quá nhanh. Khi được hỏi dữ liệu của anh/chị có tốt không, câu trả lời thường là cũng được, có đủ cả — nhưng khi đội kỹ thuật bắt tay vào làm, họ phát hiện mã khách hàng trùng nhau ở ba hệ thống khác nhau, doanh số tháng trước vẫn chưa được nhập, file Excel lưu trữ hợp đồng nằm rải rác trên máy tính của từng nhân viên, và không ai biết dữ liệu huấn luyện cho mô hình lấy từ đâu. Dự án AI sau đó không thất bại vì thuật toán kém, mà vì dữ liệu đầu vào không đủ tốt để thuật toán học được điều gì đúng đắn. Đánh giá dữ liệu trước khi triển khai AI không phải là một bước thủ tục: đó là cách rẻ nhất để biết một dự án AI có khả năng thành công hay không, trước khi doanh nghiệp bỏ ra nhiều tháng và nhiều chi phí cho nó.
Vì sao dữ liệu quyết định thành bại của dự án AI?
Nguyên tắc garbage in, garbage out (đầu vào rác thì đầu ra cũng là rác) là nguyên tắc cơ bản nhất trong trí tuệ nhân tạo: chất lượng của mô hình AI không bao giờ vượt quá chất lượng của dữ liệu mà nó học từ đó. Một mô hình học máy không hiểu nghiệp vụ như con người; nó chỉ tìm ra các mẫu thống kê trong dữ liệu được đưa cho nó. Nếu dữ liệu chứa lỗi, thiên lệch hoặc thiếu sót, mô hình sẽ học chính những lỗi, thiên lệch và thiếu sót đó — rồi lặp lại chúng một cách có hệ thống, nhanh hơn và ở quy mô lớn hơn con người rất nhiều. Một nhân viên nhập sai giá vài lần thì chỉ sai vài đơn hàng; một mô hình học từ dữ liệu giá sai sẽ định giá sai hàng nghìn đơn hàng mỗi ngày.
Cơ chế này diễn ra theo một chuỗi rất thực tế. Ở bước thu thập, dữ liệu thiếu trường quan trọng khiến mô hình không nhìn thấy yếu tố quyết định — ví dụ mô hình dự báo nhu cầu hàng tồn kho nhưng dữ liệu không ghi chương trình khuyến mãi, nên nó không bao giờ học được rằng khuyến mãi làm nhu cầu tăng vọt. Ở bước huấn luyện, dữ liệu không đại diện khiến mô hình giỏi với nhóm khách hàng chiếm đa số trong dữ liệu nhưng kém hẳn với nhóm thiểu số — ví dụ dữ liệu phản hồi khách hàng chủ yếu đến từ khách hàng trẻ ở thành phố, nên chatbot trả lời tốt cho nhóm này nhưng lúng túng với khách hàng lớn tuổi ở tỉnh. Ở bước vận hành, dữ liệu lỗi thời khiến mô hình ngày càng sai: hành vi khách hàng đã thay đổi sau một năm, nhưng mô hình vẫn dự đoán theo dữ liệu cũ. Ba mắt xích này giải thích vì sao nhiều dự án AI cho kết quả thử nghiệm tốt trên dữ liệu mẫu nhưng thất bại khi đưa vào vận hành thực tế.
Có một sự khác biệt quan trọng giữa dữ liệu dùng cho báo cáo và dữ liệu dùng cho AI. Báo cáo tổng hợp thường chịu được một tỷ lệ lỗi nhỏ: sai vài dòng trong mười nghìn dòng không làm thay đổi bức tranh tổng thể. AI thì nhạy cảm hơn nhiều, vì mô hình học từ từng dòng dữ liệu. Một trường dữ liệu bị lệch hệ thống — ví dụ tất cả giao dịch của một chi nhánh đều ghi sai mã sản phẩm trong ba tháng — có thể khiến mô hình kết luận sai về toàn bộ nhóm sản phẩm đó. Tương tự, dữ liệu dùng cho AI cần chi tiết ở cấp độ từng giao dịch, từng khách hàng, từng thời điểm; dữ liệu tổng hợp theo tháng có thể đủ để làm báo cáo quản trị, nhưng không đủ để huấn luyện mô hình dự báo theo ngày. Vì vậy, việc chúng ta đã có báo cáo đầy đủ không đồng nghĩa với chúng ta đã có dữ liệu đủ tốt cho AI.
Chi phí của việc bỏ qua đánh giá dữ liệu cũng cần được nhìn thẳng. Khi dự án AI thất bại giữa chừng vì dữ liệu, doanh nghiệp mất không chỉ chi phí phát triển mô hình mà còn mất thời gian của đội ngũ nghiệp vụ, mất cơ hội kinh doanh trong thời gian chờ đợi, và mất niềm tin nội bộ vào AI — khiến lần triển khai sau khó được phê duyệt hơn. Ngược lại, một đợt đánh giá dữ liệu nghiêm túc thường chỉ tốn vài tuần làm việc tập trung, và kết quả của nó có giá trị ngay cả khi doanh nghiệp quyết định chưa triển khai AI: doanh nghiệp sẽ biết dữ liệu của mình đang ở đâu, thiếu gì, và cần sửa gì trước — những thông tin này hữu ích cho cả báo cáo quản trị và vận hành hàng ngày, không chỉ cho AI. Nói cách khác, đánh giá dữ liệu là khoản đầu tư có lãi ngay cả trong trường hợp xấu nhất là dự án AI bị hoãn lại.
Cuối cùng, cần phân biệt rõ hai việc thường bị nhầm lẫn: có nhiều dữ liệu và có dữ liệu tốt. Một doanh nghiệp có thể lưu trữ hàng triệu dòng dữ liệu giao dịch trong mười năm nhưng vẫn không đủ dữ liệu tốt cho AI, nếu các dòng đó thiếu trường quan trọng, trùng lặp, sai định dạng hoặc không gắn được với nhau. Ngược lại, một doanh nghiệp chỉ có vài nghìn bản ghi, nhưng các bản ghi đó đầy đủ, chính xác và được gắn nhãn đúng, hoàn toàn có thể triển khai một ứng dụng AI nhỏ có giá trị. Số lượng dữ liệu quan trọng, nhưng chỉ sau khi chất lượng đã đạt mức tối thiểu. Bài viết này vì thế tập trung vào chất lượng trước, số lượng sau — và chỉ ra cách đo cả hai.
Đánh giá dữ liệu cho AI là gì?
Đánh giá dữ liệu cho AI là quá trình kiểm tra một cách có hệ thống xem dữ liệu mà doanh nghiệp đang có có đủ tốt để huấn luyện và vận hành Một hệ thống AI cụ thể hay không — và nếu chưa đủ tốt, thì thiếu ở đâu và cần sửa gì. Quá trình này trả lời bốn câu hỏi: dữ liệu có tồn tại không, dữ liệu có dùng được không, dữ liệu có đúng không, và dữ liệu có được phép dùng không. Một đợt đánh giá thường được thực hiện trước khi bắt đầu một dự án AI, hoặc khi một dự án AI đang gặp trục trặc và đội ngũ nghi ngờ nguyên nhân nằm ở dữ liệu.
Đánh giá dữ liệu khác với kiểm toán AI, dù hai việc này hay bị nhầm lẫn. Đánh giá dữ liệu tập trung vào dữ liệu đầu vào: dữ liệu có đủ tốt không, có thiếu gì không, có sai ở đâu không. Kiểm toán AI tập trung vào toàn bộ hệ thống AI: mô hình có chính xác không, có thiên vị không, có tuân thủ quy định không, và có được vận hành đúng cách không. Nói một cách đơn giản, đánh giá dữ liệu là bước đi trước — nó diễn ra trước khi xây mô hình; kiểm toán AI là bước kiểm tra sau — nó diễn ra khi hệ thống đã được xây dựng và vận hành. Một doanh nghiệp có thể đánh giá dữ liệu mà chưa cần có hệ thống AI nào; nhưng một hệ thống AI không thể được kiểm toán một cách đầy đủ nếu dữ liệu của nó chưa từng được đánh giá.
Đánh giá dữ liệu cũng khác với đánh giá mức độ sẵn sàng AI tổng thể — một khái niệm rộng hơn, bao gồm cả con người, quy trình, hạ tầng công nghệ và chiến lược kinh doanh, bên cạnh dữ liệu. Đánh giá dữ liệu chỉ là một phần của bức tranh sẵn sàng tổng thể, nhưng là phần nền tảng nhất: một doanh nghiệp có thể có đội ngũ giỏi và chiến lược rõ ràng, nhưng nếu dữ liệu không đủ tốt, dự án AI vẫn sẽ thất bại. Vì vậy, trong thực tế, nhiều doanh nghiệp bắt đầu hành trình AI bằng một đợt đánh giá dữ liệu — vì kết quả của nó cho biết doanh nghiệp đang đứng ở đâu và cần bao lâu để sẵn sàng, trước khi cam kết nguồn lực cho một dự án lớn hơn.
Về vai trò, đánh giá dữ liệu thường do một nhóm nhỏ thực hiện: người phụ trách nghiệp vụ của bài toán AI (ví dụ trưởng phòng bán hàng, trưởng phòng vận hành), người phụ trách dữ liệu hoặc công nghệ thông tin (người biết dữ liệu đang ở đâu và lấy ra như thế nào), và nếu có thể, một chuyên gia dữ liệu hoặc đối tác bên ngoài có kinh nghiệm đánh giá dữ liệu cho AI. Doanh nghiệp không cần một đội ngũ lớn: với một bài toán cụ thể và dữ liệu đã xác định, một nhóm 2–3 người làm việc tập trung trong 2–4 tuần thường đủ để hoàn thành một đợt đánh giá có chất lượng. Thời gian và chi phí tăng lên khi dữ liệu nằm rải rác ở nhiều hệ thống, hoặc khi bài toán AI chưa được xác định rõ ràng — vì khi đó nhóm đánh giá phải dành thời gian để làm rõ bài toán trước khi kiểm tra dữ liệu.
Sáu chiều đánh giá dữ liệu cho AI
Chất lượng dữ liệu không phải là một khái niệm duy nhất, mà là tổng hợp của sáu chiều khác nhau. Mỗi chiều kiểm tra một khía cạnh riêng, và một tập dữ liệu có thể tốt ở chiều này nhưng kém ở chiều khác — ví dụ dữ liệu rất đầy đủ nhưng không nhất quán, hoặc rất chính xác nhưng đã lỗi thời. Sáu chiều quan trọng nhất — dựa trên các khung quản trị dữ liệu như DAMA-DMBOK (tài liệu quản trị dữ liệu của hiệp hội DAMA International) và kinh nghiệm triển khai AI trong doanh nghiệp — là: đầy đủ, chính xác, nhất quán, kịp thời, đại diện và hợp pháp. Dưới đây là ý nghĩa của từng chiều, cách kiểm tra, và những lỗi điển hình mà doanh nghiệp thường gặp.
1. Đầy đủ (Completeness): dữ liệu có thiếu không?
Chiều đầy đủ hỏi một câu đơn giản: dữ liệu cần có đã có đủ chưa, hay đang thiếu ở đâu? Thiếu dữ liệu có hai dạng. Thiếu theo trường: một trường quan trọng bị bỏ trống trong nhiều bản ghi — ví dụ trường lý do khách hàng rời đi bị trống trong 60% hồ sơ, hay trường ngày giao hàng thực tế bị trống trong một nửa đơn hàng. Thiếu theo bản ghi: toàn bộ bản ghi của một nhóm đối tượng bị vắng mặt — ví dụ dữ liệu bán hàng chỉ lưu giao dịch tại cửa hàng mà không lưu giao dịch online, hay dữ liệu khách hàng chỉ có khách hàng đã mua mà không có khách hàng đã hỏi rồi bỏ đi. Cả hai dạng thiếu đều khiến mô hình AI học sai: thiếu theo trường khiến mô hình không nhìn thấy yếu tố quan trọng, thiếu theo bản ghi khiến mô hình tưởng rằng nhóm bị thiếu không tồn tại.
Cách kiểm tra chiều đầy đủ là đo tỷ lệ thiếu theo từng trường và từng nhóm bản ghi. Với mỗi trường quan trọng của bài toán AI, tính tỷ lệ bản ghi bị trống hoặc bị ghi giá trị giữ chỗ — ví dụ N/A, 0000-00-00, không rõ — và so sánh với ngưỡng chấp nhận được của bài toán đó. Một trường bị thiếu 5% thường vẫn dùng được; một trường bị thiếu 40% thì gần như không dùng được, trừ khi doanh nghiệp có cách bổ sung đáng tin cậy. Song song, kiểm tra xem có nhóm bản ghi nào bị thiếu một cách có hệ thống không: dữ liệu của chi nhánh nào, của giai đoạn nào, của nhóm khách hàng nào đang vắng mặt. Thiếu ngẫu nhiên thì ít nguy hiểm hơn thiếu có hệ thống — vì thiếu có hệ thống đồng nghĩa với việc mô hình sẽ không bao giờ học được về nhóm bị thiếu đó.
Một lỗi điển hình là nhầm lẫn giữa dữ liệu thiếu thật và dữ liệu được ghi bằng giá trị giữ chỗ. Nhiều hệ thống cho phép nhân viên nhập 0, 999, hay một ngày giả khi không biết giá trị thật — và những giá trị giữ chỗ này sau đó bị mô hình hiểu nhầm là giá trị thật. Ví dụ một trường số điện thoại khách hàng bị nhập bằng dãy số 0 trong 15% bản ghi; nếu không phát hiện, mô hình có thể kết luận rằng nhóm khách hàng này có một đặc điểm chung kỳ lạ. Cách phòng tránh là thống kê tần suất của các giá trị bất thường trong từng trường — những giá trị xuất hiện với tần suất cao một cách đáng ngờ thường là giá trị giữ chỗ, không phải dữ liệu thật. Việc sửa chiều đầy đủ thường bắt đầu bằng việc xác định vì sao nó thiếu: do quy trình nhập liệu không bắt buộc trường đó, do hệ thống cũ không lưu trường đó, hay do dữ liệu đó thực sự không tồn tại trong thực tế. Mỗi nguyên nhân có cách sửa khác nhau, và có những nguyên nhân không sửa được — khi đó doanh nghiệp cần điều chỉnh bài toán AI cho phù hợp với dữ liệu đang có, thay vì cố dùng dữ liệu thiếu để làm một bài toán đòi hỏi dữ liệu đầy đủ.
2. Chính xác (Accuracy): dữ liệu có đúng với thực tế không?
Chiều chính xác hỏi: dữ liệu đang lưu có phản ánh đúng thực tế hay không? Một tập dữ liệu có thể rất đầy đủ nhưng vẫn sai: tên khách hàng gõ sai chính tả, số lượng tồn kho ghi sai vì chưa cập nhật sau khi xuất hàng, giá bán ghi theo bảng giá cũ, ngày tháng nhập theo định dạng khác nhau nên bị hệ thống hiểu sai. Những lỗi này đặc biệt nguy hiểm vì chúng âm thầm: dữ liệu trông vẫn đầy đủ, hệ thống vẫn chạy bình thường, nhưng mô hình AI học được những quan hệ không có thật trong thực tế.
Cách kiểm tra chiều chính xác là đối chiếu dữ liệu với một nguồn đáng tin cậy độc lập, theo ba cách. Thứ nhất là đối chiếu với nguồn gốc: lấy mẫu dữ liệu và kiểm tra trực tiếp với chứng từ gốc — ví dụ đối chiếu đơn hàng trong hệ thống với hợp đồng giấy, đối chiếu tồn kho trong hệ thống với kiểm kê thực tế tại kho. Thứ hai là kiểm tra tính hợp lý: đặt ra các quy tắc nghiệp vụ và kiểm tra xem có bản ghi nào vi phạm không — ví dụ ngày giao hàng không thể trước ngày đặt hàng, tuổi khách hàng không thể là 200, số tiền đơn hàng không thể âm. Thứ ba là đối chiếu chéo giữa các hệ thống: cùng một khách hàng, cùng một đơn hàng, khi tra ở hai hệ thống khác nhau thì thông tin có khớp nhau không. Mỗi cách phát hiện một loại lỗi khác nhau, và cả ba đều cần thiết.
Có ba nguồn gốc phổ biến của dữ liệu không chính xác. Thứ nhất là giá trị giữ chỗ bị hiểu nhầm thành giá trị thật: một trường ngày sinh bị nhập 01/01/1900 khi không biết ngày sinh thật, một trường giá trị bị nhập 0 đồng khi chưa có giá, một trường số lượng bị nhập 999 khi chưa đếm — và mô hình sau đó học rằng có một nhóm khách hàng sinh năm 1900 hay một nhóm sản phẩm có giá bằng không. Thứ hai là lỗi do chuyển đổi đơn vị hoặc định dạng: cân nặng ghi lúc bằng kg lúc bằng gam, ngày tháng ghi lúc theo định dạng ngày/tháng/năm lúc theo tháng/ngày/năm, tiền tệ ghi lúc có dấu phân cách hàng nghìn lúc không có. Thứ ba là dữ liệu bị ghi đè hoặc cập nhật một phần: một bản ghi được sửa ở hệ thống này nhưng không được sửa ở hệ thống kia, hoặc một trường được cập nhật mà trường liên quan không được cập nhật theo. Việc sửa chiều chính xác thường đòi hỏi xác minh với nguồn gốc — không có cách nào tự động sửa một cách đáng tin cậy nếu không biết giá trị đúng là gì. Vì vậy, khi tỷ lệ sai vượt quá ngưỡng chấp nhận được của bài toán, doanh nghiệp thường phải quay lại nguồn gốc để làm sạch, hoặc thu thập lại dữ liệu cho phần bị sai.
3. Nhất quán (Consistency): cùng một sự thật có được ghi giống nhau ở mọi nơi không?
Chiều nhất quán hỏi: cùng một sự thật có được ghi giống nhau ở mọi nơi không? Đây là vấn đề phổ biến nhất ở doanh nghiệp có nhiều hệ thống: cùng một khách hàng được ghi là Công ty TNHH ABC ở hệ thống kế toán, CTy ABC ở hệ thống bán hàng, và ABC Co., Ltd ở hệ thống kho; cùng một sản phẩm có mã khác nhau ở hai hệ thống; cùng một nhân viên có ngày vào làm khác nhau ở hai bảng lương. Khi dữ liệu không nhất quán, mô hình AI không biết đâu là sự thật — và thường kết luận rằng có ba khách hàng khác nhau thay vì một khách hàng duy nhất, hay có hai sản phẩm khác nhau thay vì một.
Nhất quán có ba cấp độ. Nhất quán trong một bảng: cùng một giá trị, ví dụ giới tính, có được ghi theo một chuẩn duy nhất không, hay lúc ghi Nam/Nữ, lúc ghi M/F, lúc ghi 1/0. Nhất quán giữa các bảng trong một hệ thống: một khách hàng có mã duy nhất dùng chung ở mọi bảng không, hay mỗi bảng dùng một mã riêng. Nhất quán giữa các hệ thống: khi cùng một thông tin xuất hiện ở hệ thống kế toán, hệ thống bán hàng và hệ thống kho, các hệ thống có đồng ý với nhau không. Mỗi cấp độ cần một cách kiểm tra riêng, nhưng tất cả đều chung một nguyên tắc: chọn một chuẩn duy nhất cho mỗi loại giá trị, và kiểm tra xem có bản ghi nào không tuân theo chuẩn đó không.
Nguyên nhân của dữ liệu không nhất quán thường nằm ở lịch sử: doanh nghiệp dùng nhiều hệ thống được mua ở những thời điểm khác nhau, mỗi hệ thống có quy ước riêng; nhân viên nhập liệu tự do, không theo một danh mục chuẩn; và dữ liệu được nhập lại thủ công giữa các hệ thống, nên mỗi lần nhập lại là một lần có thể sai khác. Cách sửa là xây dựng danh mục chuẩn — ví dụ một bảng mã khách hàng duy nhất, một bảng mã sản phẩm duy nhất, một quy ước ghi ngày tháng, giới tính, địa chỉ — và đối chiếu, hợp nhất các giá trị cũ về chuẩn đó. Đây là công việc tốn thời gian, vì nó đòi hỏi người hiểu nghiệp vụ xác nhận xem hai giá trị khác nhau có thực sự chỉ cùng một sự thật hay không. Nhưng một khi đã có danh mục chuẩn và quy trình kiểm soát, dữ liệu mới nhập vào sẽ tự động tuân theo chuẩn, và vấn đề nhất quán sẽ không tái diễn.
4. Kịp thời (Timeliness): dữ liệu có còn mới và đúng thời điểm không?
Chiều kịp thời hỏi: dữ liệu có còn mới và đúng thời điểm không? Dữ liệu có hai khía cạnh thời gian: độ trễ — khoảng thời gian từ khi sự kiện xảy ra đến khi dữ liệu được ghi nhận — và độ mới — dữ liệu đang dùng có phản ánh trạng thái hiện tại hay đã lỗi thời. Một mô hình dự báo nhu cầu dùng dữ liệu bán hàng cập nhật đến hôm qua thì có giá trị; dùng dữ liệu cập nhật đến ba tháng trước thì dự báo của nó có thể đã sai hoàn toàn, vì thị trường, giá cả và hành vi khách hàng đều đã thay đổi.
Cách kiểm tra chiều kịp thời là đo độ trễ và độ mới của từng nguồn dữ liệu. Với mỗi bảng dữ liệu quan trọng, ghi lại thời điểm cập nhật gần nhất và tần suất cập nhật: dữ liệu được cập nhật theo thời gian thực, theo ngày, theo tuần, hay theo tháng? Sau đó so sánh với yêu cầu của bài toán AI: một hệ thống gợi ý sản phẩm cần dữ liệu hành vi trong vài ngày gần nhất; một mô hình dự báo nhu cầu theo tháng có thể chấp nhận dữ liệu cập nhật theo tuần. Nếu độ trễ của dữ liệu lớn hơn yêu cầu của bài toán, mô hình sẽ luôn chậm một nhịp so với thực tế — dự báo được nhu cầu của tháng trước, gợi ý được sản phẩm mà khách hàng đã mua rồi.
Một lỗi điển hình là dùng dữ liệu huấn luyện đã quá cũ mà không kiểm tra. Hành vi khách hàng, giá cả, danh mục sản phẩm và kênh bán hàng đều thay đổi theo thời gian; một mô hình huấn luyện bằng dữ liệu hai năm trước có thể không còn phù hợp với thị trường hiện tại. Hiện tượng này được gọi là model drift — mô hình suy giảm dần theo thời gian vì dữ liệu thực tế đã trôi khỏi dữ liệu huấn luyện. Cách phòng tránh là ghi lại khoảng thời gian mà dữ liệu huấn luyện bao phủ, kiểm tra xem dữ liệu đó còn phản ánh thực tế hiện tại không, và thiết lập quy trình cập nhật dữ liệu định kỳ sau khi mô hình đi vào vận hành — chứ không phải huấn luyện một lần rồi dùng mãi.
5. Đại diện (Representativeness): dữ liệu có phản ánh đúng đối tượng mà AI sẽ phục vụ không?
Chiều đại diện hỏi: dữ liệu có phản ánh đúng đối tượng mà AI sẽ phục vụ không? Một tập dữ liệu có thể đầy đủ và chính xác nhưng vẫn không đại diện: dữ liệu phản hồi khách hàng chủ yếu đến từ những khách hàng hài lòng vì chỉ họ mới chịu viết phản hồi; dữ liệu bán hàng chủ yếu từ cửa hàng lớn ở thành phố vì cửa hàng nhỏ ở tỉnh chưa nhập dữ liệu đầy đủ; dữ liệu lịch sử chỉ bao phủ mùa cao điểm mà không có mùa thấp điểm. Khi đó mô hình học được một bức tranh méo mó về thực tế — và sẽ hoạt động kém với chính những nhóm đối tượng bị thiếu trong dữ liệu.
Cách kiểm tra chiều đại diện là so sánh tỷ lệ các nhóm trong dữ liệu với tỷ lệ các nhóm trong thực tế mà AI sẽ phục vụ. Với mỗi đặc điểm quan trọng — độ tuổi, khu vực, loại khách hàng, loại sản phẩm, kênh bán hàng, thời gian — tính tỷ lệ trong dữ liệu huấn luyện và so sánh với tỷ lệ thực tế của toàn bộ đối tượng. Nếu một nhóm chiếm 30% khách hàng thực tế nhưng chỉ chiếm 5% dữ liệu, mô hình sẽ học kém về nhóm đó. Nếu một nhóm hoàn toàn vắng mặt trong dữ liệu, mô hình sẽ không biết gì về nhóm đó — và doanh nghiệp cần quyết định: thu thập thêm dữ liệu cho nhóm đó, hay giới hạn phạm vi áp dụng của AI, không để AI phục vụ nhóm mà nó chưa từng thấy.
Chiều đại diện liên quan trực tiếp đến thiên vị (bias) của AI — một chủ đề mà nhiều doanh nghiệp chỉ quan tâm khi đã gặp sự cố. Thiên vị thường không xuất phát từ thuật toán, mà từ dữ liệu: dữ liệu lịch sử phản ánh quyết định của con người trong quá khứ, và nếu những quyết định đó đã thiên vị một nhóm nào đó — ví dụ nhóm khách hàng ở một khu vực luôn bị từ chối tín dụng vì lý do không liên quan đến khả năng trả nợ — thì mô hình học từ dữ liệu đó sẽ lặp lại sự thiên vị đó một cách tự động và có hệ thống. Vì vậy, kiểm tra tính đại diện không chỉ là vấn đề kỹ thuật, mà còn là vấn đề trách nhiệm: doanh nghiệp cần biết dữ liệu của mình đại diện cho ai, và ai đang bị bỏ quên, trước khi để AI ra quyết định thay cho con người. Lưu ý: thiên vị trong dữ liệu thường không phải do ai đó cố tình tạo ra — nó là kết quả của quy trình thu thập dữ liệu trong quá khứ, và việc phát hiện ra nó chính là giá trị của một đợt đánh giá dữ liệu nghiêm túc.
6. Hợp pháp (Legality): dữ liệu có được phép dùng cho AI không?
Chiều hợp pháp hỏi: dữ liệu có được phép dùng cho AI không? Đây là chiều thường bị bỏ qua nhất, vì nhiều doanh nghiệp cho rằng dữ liệu của mình thì mình được dùng tùy ý. Thực tế, dữ liệu cá nhân của khách hàng và nhân viên được thu thập cho một mục đích cụ thể — ví dụ để giao hàng, để chăm sóc khách hàng — không tự động đồng nghĩa với việc doanh nghiệp được dùng dữ liệu đó để huấn luyện mô hình AI, đặc biệt khi mô hình được triển khai bởi bên thứ ba hoặc khi dữ liệu chứa thông tin nhạy cảm như sức khỏe, tài chính, vị trí, hay quan điểm cá nhân. Việc dùng dữ liệu sai mục đích có thể vi phạm quy định về bảo vệ dữ liệu cá nhân và gây ra hậu quả pháp lý nghiêm trọng, ngay cả khi mô hình AI hoạt động tốt về mặt kỹ thuật.
Cách kiểm tra chiều hợp pháp là rà soát ba yếu tố. Thứ nhất là nguồn gốc và quyền sử dụng: dữ liệu được thu thập từ đâu, với sự đồng ý nào, và thỏa thuận thu thập đó có cho phép dùng cho AI không. Thứ hai là dữ liệu nhạy cảm: dữ liệu có chứa thông tin nhạy cảm theo quy định pháp luật không, và nếu có, doanh nghiệp đã có biện pháp bảo vệ phù hợp chưa — ví dụ ẩn danh hóa, mã hóa, hay giới hạn quyền truy cập. Thứ ba là quyền của chủ thể dữ liệu: khách hàng có quyền yêu cầu xóa dữ liệu của mình không, và nếu họ yêu cầu, doanh nghiệp có thể xóa dữ liệu đó khỏi cả mô hình đã huấn luyện không — một câu hỏi khó về mặt kỹ thuật mà nhiều doanh nghiệp chưa từng nghĩ tới.
Lưu ý quan trọng: một tập dữ liệu có thể đạt điểm cao ở cả năm chiều trên nhưng vẫn không dùng được cho AI, nếu chiều hợp pháp không đạt. Vì vậy, trong đợt đánh giá dữ liệu, chiều hợp pháp cần được kiểm tra song song với các chiều kỹ thuật, không phải để cuối cùng. Nếu phát hiện vấn đề pháp lý, doanh nghiệp cần tham khảo ý kiến pháp lý trước khi tiếp tục — và trong nhiều trường hợp, giải pháp là thu thập lại sự đồng ý, ẩn danh hóa dữ liệu, hoặc giới hạn phạm vi sử dụng dữ liệu cho những mục đích đã được đồng ý. Việc tuân thủ pháp luật không chỉ tránh rủi ro pháp lý, mà còn xây dựng niềm tin với khách hàng — và niềm tin là điều kiện để doanh nghiệp thu thập được dữ liệu tốt hơn trong tương lai. Các doanh nghiệp nên tham khảo thêm về cam kết hợp đồng và đạo đức sử dụng dữ liệu khi làm việc với đối tác triển khai AI, để đảm bảo dữ liệu của mình được sử dụng đúng mục đích và đúng thỏa thuận.
Cách kiểm tra chất lượng dữ liệu từng bước
Sáu chiều trên cho biết cần kiểm tra những gì; phần này cho biết kiểm tra như thế nào, theo từng bước cụ thể. Quy trình gồm bảy bước, đi từ việc xác định bài toán AI cần dữ liệu gì, đến việc lập danh mục dữ liệu, lấy mẫu kiểm tra, đo tỷ lệ thiếu và sai, kiểm tra tính đại diện và thiên vị, kiểm tra nguồn gốc và quyền sử dụng, rồi tổng hợp kết quả để ra quyết định đi hay dừng. Bảy bước này có thể hoàn thành trong 2–4 tuần làm việc tập trung, tùy thuộc vào số lượng nguồn dữ liệu và mức độ phức tạp của bài toán AI.
Bước 1: Xác định bài toán AI và dữ liệu mà bài toán cần
Định nghĩa: Xác định rõ bài toán AI cụ thể mà doanh nghiệp muốn giải quyết, và từ đó liệt kê dữ liệu mà bài toán đó cần. Đây là bước quan trọng nhất, vì không có bài toán rõ ràng thì không thể biết dữ liệu nào là cần thiết và dữ liệu nào là không liên quan. Một bài toán AI tốt có ba yếu tố: mục tiêu kinh doanh cụ thể (ví dụ giảm 20% thời gian xử lý đơn hàng), dữ liệu đầu vào xác định được (ví dụ lịch sử đơn hàng, thông tin khách hàng), và kết quả đầu ra đo được (ví dụ thời gian xử lý trung bình giảm từ 30 phút xuống 24 phút).
Ví dụ, nếu bài toán là dự báo nhu cầu từng mặt hàng theo tuần để đặt hàng đúng số lượng, dữ liệu cần thiết là lịch sử bán hàng theo ngày, lịch khuyến mãi, lịch nghỉ lễ, và dữ liệu thời tiết nếu có ảnh hưởng. Nếu bài toán là phân loại email khách hàng vào đúng bộ phận xử lý, dữ liệu cần thiết là lịch sử email đã được gắn nhãn đúng bộ phận. Nếu bài toán là gợi ý sản phẩm phù hợp cho từng khách hàng trên website, dữ liệu cần thiết là lịch sử mua hàng, lịch sử xem sản phẩm, và thông tin khách hàng. Mỗi bài toán cần một tập dữ liệu khác nhau — và việc xác định đúng tập dữ liệu cần thiết ngay từ đầu sẽ tránh lãng phí thời gian kiểm tra những dữ liệu không liên quan. Một sai lầm phổ biến là bắt đầu kiểm tra dữ liệu mà chưa xác định bài toán: nhóm đánh giá kiểm tra tất cả dữ liệu trong doanh nghiệp, mất nhiều tuần, nhưng cuối cùng không trả lời được câu hỏi dữ liệu có đủ tốt cho bài toán nào — vì bài toán chưa từng được xác định.
Bước 2: Lập danh mục dữ liệu (data inventory)
Định nghĩa: Lập danh sách tất cả các nguồn dữ liệu liên quan đến bài toán AI: dữ liệu đang ở đâu, ở dạng nào, do ai quản lý, và được cập nhật như thế nào. Đây là bước thường bị bỏ qua, nhưng lại là bước giúp nhóm đánh giá không bỏ sót nguồn dữ liệu quan trọng — ví dụ một bảng dữ liệu khách hàng nằm trên máy tính của một nhân viên đã nghỉ việc, hay một file Excel chứa lịch sử khuyến mãi mà không ai nhớ tới.
Với mỗi nguồn dữ liệu, ghi lại sáu thông tin: tên và vị trí của nguồn dữ liệu, người phụ trách (ai biết rõ nhất về dữ liệu này), định dạng và cấu trúc (bảng trong cơ sở dữ liệu, file Excel, file PDF, giấy tờ), khoảng thời gian mà dữ liệu bao phủ (từ tháng nào đến tháng nào), tần suất cập nhật (theo thời gian thực, theo ngày, theo tuần), và mức độ tin cậy theo cảm nhận của người dùng — dữ liệu này có thường xuyên bị sai không, có ai phàn nàn về nó không. Thông tin cuối cùng nghe có vẻ chủ quan, nhưng lại rất hữu ích: người dùng hàng ngày thường biết dữ liệu nào đáng tin và dữ liệu nào hay sai, dù họ không diễn đạt được bằng số liệu. Sau khi lập danh mục, nhóm đánh giá sẽ biết mình có bao nhiêu nguồn dữ liệu cần kiểm tra, và nguồn nào quan trọng nhất — từ đó lập kế hoạch kiểm tra theo thứ tự ưu tiên, thay vì kiểm tra một cách ngẫu nhiên.
Bước 3: Lấy mẫu kiểm tra và phân tích mô tả
Định nghĩa: Lấy một mẫu dữ liệu đủ lớn từ mỗi nguồn dữ liệu quan trọng, và phân tích mẫu đó để hiểu dữ liệu trông như thế nào trước khi đo chi tiết. Phân tích mô tả bao gồm: số lượng bản ghi, khoảng giá trị của từng trường, các giá trị thường gặp nhất, và các giá trị bất thường nổi bật. Bước này giống như việc bác sĩ khám tổng quát trước khi chỉ định xét nghiệm chi tiết: nó cho biết dữ liệu đang ở trạng thái nào, và cần tập trung kiểm tra sâu vào đâu.
Cách lấy mẫu quan trọng không kém việc phân tích mẫu. Mẫu cần được lấy ngẫu nhiên từ toàn bộ dữ liệu, không phải chỉ lấy 100 dòng đầu tiên — vì 100 dòng đầu tiên có thể là dữ liệu của một chi nhánh, một tháng, hay một nhóm khách hàng cụ thể, không đại diện cho toàn bộ. Mẫu nên bao phủ nhiều thời gian, nhiều nhóm và nhiều nguồn khác nhau. Sau khi lấy mẫu, phân tích mô tả sẽ cho thấy những vấn đề rõ ràng ngay lập tức: một trường có quá nhiều giá trị trống, một trường có giá trị lớn nhất bất thường, một trường có quá nhiều giá trị trùng lặp. Những phát hiện này giúp nhóm đánh giá điều chỉnh kế hoạch kiểm tra chi tiết ở các bước sau — tập trung vào những trường có vấn đề, thay vì kiểm tra đều tất cả các trường với cùng một mức độ.
Bước 4: Đo tỷ lệ thiếu, sai và trùng lặp
Định nghĩa: Đo lường bằng số liệu cụ thể ba tỷ lệ quan trọng nhất của chất lượng dữ liệu: tỷ lệ thiếu (bao nhiêu phần trăm bản ghi bị trống ở từng trường quan trọng), tỷ lệ sai (bao nhiêu phần trăm bản ghi vi phạm quy tắc nghiệp vụ hoặc không khớp với nguồn gốc), và tỷ lệ trùng lặp (bao nhiêu phần trăm bản ghi là bản sao của một bản ghi khác). Ba tỷ lệ này là những con số cốt lõi mà mọi quyết định về dữ liệu sau này đều dựa vào.
Với tỷ lệ thiếu, đo theo từng trường quan trọng: trường nào thiếu dưới 5% thì thường vẫn dùng được; thiếu từ 5% đến 20% thì cần đánh giá xem có thể bổ sung không; thiếu trên 20% thì gần như không dùng được cho mô hình AI, trừ khi trường đó không thực sự quan trọng. Với tỷ lệ sai, đo bằng cách áp dụng các quy tắc nghiệp vụ lên toàn bộ dữ liệu: ví dụ kiểm tra có bao nhiêu đơn hàng có ngày giao trước ngày đặt, bao nhiêu khách hàng có tuổi ngoài khoảng hợp lý, bao nhiêu sản phẩm có giá bằng không. Với tỷ lệ trùng lặp, đo bằng cách so sánh các trường định danh — ví dụ cùng một số điện thoại, cùng một email, cùng một mã số thuế xuất hiện ở bao nhiêu bản ghi khác nhau — và xác định xem đó là trùng lặp thật (cùng một khách hàng bị ghi hai lần) hay chỉ là trùng hợp (hai khách hàng khác nhau có cùng tên).
Kết quả của bước này nên được ghi lại thành một bảng số liệu rõ ràng, vì nó là bằng chứng quan trọng nhất khi trình bày với ban lãnh đạo: dữ liệu của chúng ta thiếu bao nhiêu phần trăm, sai bao nhiêu phần trăm, trùng bao nhiêu phần trăm — chứ không phải cảm giác chung chung rằng dữ liệu có vẻ ổn hay có vẻ kém. Bảng số liệu này cũng là cơ sở để chấm điểm mức độ sẵn sàng dữ liệu ở phần sau, và để ước tính thời gian, chi phí cần thiết để làm sạch dữ liệu trước khi triển khai AI. Một lưu ý: tỷ lệ trùng lặp cao không phải lúc nào cũng xấu — có những hệ thống cố tình lưu nhiều bản ghi cho cùng một sự kiện (ví dụ lịch sử thay đổi trạng thái đơn hàng) — nhưng khi đó cần phân biệt rõ đâu là lịch sử, đâu là trùng lặp thật, và mô hình AI cần dùng phiên bản nào của dữ liệu.
Bước 5: Kiểm tra tính đại diện và thiên vị trong dữ liệu
Định nghĩa: So sánh tỷ lệ các nhóm trong dữ liệu với tỷ lệ các nhóm trong thực tế mà AI sẽ phục vụ, để phát hiện nhóm nào bị thiếu hoặc bị thừa. Bước này trả lời câu hỏi: dữ liệu của chúng ta có phản ánh đúng đối tượng mà AI sẽ phục vụ không, hay nó chỉ phản ánh một phần của đối tượng đó. Ví dụ, nếu dữ liệu phản hồi khách hàng chủ yếu đến từ khách hàng trẻ ở thành phố, mô hình chatbot học từ dữ liệu đó sẽ trả lời tốt cho nhóm trẻ ở thành phố nhưng kém với khách hàng lớn tuổi ở tỉnh — và doanh nghiệp sẽ không biết điều đó cho đến khi khách hàng lớn tuổi phàn nàn.
Cách kiểm tra là lập bảng so sánh tỷ lệ: với mỗi đặc điểm quan trọng — độ tuổi, khu vực, loại khách hàng, kênh bán hàng, thời gian — tính tỷ lệ trong dữ liệu huấn luyện và tỷ lệ thực tế của toàn bộ đối tượng. Chênh lệch lớn giữa hai tỷ lệ là dấu hiệu của vấn đề đại diện. Ngoài ra, cần kiểm tra thiên vị trong nhãn dữ liệu: nếu dữ liệu huấn luyện là các quyết định của con người trong quá khứ (ví dụ quyết định phê duyệt tín dụng, quyết định tuyển dụng), hãy kiểm tra xem các quyết định đó có thiên vị một nhóm nào không — vì mô hình học từ những quyết định đó sẽ lặp lại sự thiên vị đó. Nếu phát hiện thiên vị, doanh nghiệp có ba lựa chọn: thu thập thêm dữ liệu cho nhóm bị thiếu, điều chỉnh dữ liệu để cân bằng các nhóm, hoặc giới hạn phạm vi áp dụng của AI, không để AI ra quyết định với nhóm mà dữ liệu chưa đại diện được. Lựa chọn nào cũng cần được ghi lại và thảo luận với ban lãnh đạo, vì nó ảnh hưởng đến cả phạm vi và trách nhiệm của dự án AI.
Bước 6: Kiểm tra nguồn gốc, quyền sử dụng và tính bảo mật
Định nghĩa: Kiểm tra xem dữ liệu đến từ đâu, được thu thập với sự đồng ý nào, có chứa thông tin nhạy cảm không, và có được bảo vệ đúng cách không. Bước này trả lời câu hỏi pháp lý quan trọng nhất: dữ liệu này có được phép dùng cho AI không. Một tập dữ liệu có thể đạt điểm cao ở tất cả các chiều kỹ thuật nhưng vẫn không dùng được, nếu nó được thu thập mà không có sự đồng ý phù hợp, hoặc nếu nó chứa dữ liệu nhạy cảm mà doanh nghiệp chưa có biện pháp bảo vệ.
Cách kiểm tra là rà soát ba yếu tố. Thứ nhất, nguồn gốc: dữ liệu được thu thập khi nào, bằng cách nào, và với sự đồng ý nào — ví dụ khách hàng có đồng ý cho doanh nghiệp dùng dữ liệu của họ để cải thiện dịch vụ không, và sự đồng ý đó có bao gồm việc dùng dữ liệu để huấn luyện AI không. Thứ hai, dữ liệu nhạy cảm: dữ liệu có chứa thông tin nhạy cảm theo quy định pháp luật không — ví dụ thông tin sức khỏe, tài chính, vị trí, hay dữ liệu sinh trắc học — và nếu có, doanh nghiệp đã áp dụng biện pháp bảo vệ nào: ẩn danh hóa, mã hóa, hay giới hạn quyền truy cập. Thứ ba, bảo mật: dữ liệu đang được lưu trữ ở đâu, ai có quyền truy cập, và có nhật ký truy cập không. Nếu phát hiện vấn đề ở bước này, doanh nghiệp cần tham khảo ý kiến pháp lý trước khi tiếp tục — vì khác với các vấn đề kỹ thuật có thể sửa bằng cách làm sạch dữ liệu, vấn đề pháp lý có thể khiến toàn bộ dự án AI phải dừng lại hoặc thay đổi phạm vi.
Bước 7: Tổng hợp kết quả và ra quyết định đi hay dừng
Định nghĩa: Tổng hợp tất cả kết quả kiểm tra từ sáu bước trên thành một báo cáo đánh giá dữ liệu, và dựa trên báo cáo đó để ra quyết định: bắt đầu triển khai AI ngay, bắt đầu với phạm vi thu hẹp, hay dừng lại làm dữ liệu trước. Báo cáo nên bao gồm: bảng số liệu chất lượng dữ liệu (tỷ lệ thiếu, sai, trùng lặp theo từng trường quan trọng), điểm số theo sáu chiều chất lượng, danh sách các vấn đề phát hiện được xếp theo mức độ nghiêm trọng, và đề xuất cụ thể cho từng vấn đề — sửa trong bao lâu, tốn bao nhiêu chi phí, và ai chịu trách nhiệm.
Quyết định đi hay dừng nên dựa trên ba tiêu chí. Thứ nhất, dữ liệu có đủ tốt cho bài toán đã xác định không — hay bài toán cần được thu hẹp lại cho phù hợp với dữ liệu đang có. Thứ hai, chi phí và thời gian để sửa dữ liệu có chấp nhận được không — nếu cần sáu tháng để làm sạch dữ liệu cho một PoC dự kiến chạy trong hai tháng, có lẽ nên chọn một bài toán khác có dữ liệu tốt hơn. Thứ ba, rủi ro pháp lý có được giải quyết không — nếu chiều hợp pháp chưa đạt, không nên bắt đầu triển khai cho đến khi vấn đề pháp lý được giải quyết, vì hậu quả pháp lý có thể lớn hơn nhiều so với giá trị của dự án AI. Một báo cáo đánh giá dữ liệu tốt không chỉ nói dữ liệu có tốt hay không — nó nói rõ dữ liệu tốt ở đâu, kém ở đâu, cần sửa gì, và sửa trong bao lâu, để ban lãnh đạo có thể ra quyết định dựa trên số liệu, không phải cảm tính.
Dữ liệu phi cấu trúc đánh giá ra sao?
Phần lớn dữ liệu của doanh nghiệp không nằm trong bảng mà nằm trong văn bản, hình ảnh và ghi âm — và các loại dữ liệu này không thể đánh giá bằng cùng một cách như dữ liệu có cấu trúc. Mỗi loại dữ liệu phi cấu trúc có những chiều chất lượng riêng, nhưng nguyên tắc chung vẫn giống nhau: kiểm tra xem dữ liệu có đủ, có đúng, có đại diện và có được phép dùng không. Dưới đây là cách đánh giá ba loại dữ liệu phi cấu trúc phổ biến nhất trong doanh nghiệp: văn bản, hình ảnh, và ghi âm.
Văn bản: email, tin nhắn, hợp đồng, phản hồi khách hàng
Định nghĩa: Dữ liệu văn bản là các đoạn chữ mà doanh nghiệp thu thập được trong quá trình làm việc: email khách hàng, tin nhắn chat, hợp đồng, biên bản họp, phản hồi và đánh giá của khách hàng. Với chatbot và các ứng dụng AI ngôn ngữ, dữ liệu văn bản chính là nguyên liệu huấn luyện quan trọng nhất — và chất lượng của nó quyết định trực tiếp chất lượng câu trả lời của AI.
Đánh giá dữ liệu văn bản gồm bốn khía cạnh. Thứ nhất là số lượng và độ bao phủ: có đủ đoạn văn bản cho mỗi chủ đề, mỗi ý định của khách hàng không, hay chỉ có vài ví dụ cho mỗi chủ đề. Thứ hai là chất lượng ngôn ngữ: văn bản có đúng chính tả và ngữ pháp không, hay chứa nhiều từ viết tắt, từ lóng, lỗi gõ phím — ví dụ ko, dc, ạ — mà mô hình sẽ phải học cách xử lý. Thứ ba là tính nhất quán của nhãn: nếu văn bản đã được gắn nhãn (ví dụ email đã được phân loại vào đúng bộ phận), nhãn đó có đúng không, và hai người gắn nhãn cùng một email có cho ra cùng một kết quả không. Thứ tư là tính cập nhật: ngôn ngữ khách hàng có thay đổi theo thời gian không — ví dụ khách hàng dùng từ mới để hỏi về sản phẩm mới, và dữ liệu huấn luyện chưa có những từ đó.
Một lỗi điển hình là dùng dữ liệu văn bản đã được làm sạch quá mức để huấn luyện, rồi ngạc nhiên khi mô hình hoạt động kém với văn bản thật của khách hàng — vì văn bản thật có lỗi chính tả, có từ viết tắt, có câu không đầy đủ. Cách đánh giá đúng là kiểm tra dữ liệu văn bản ở trạng thái gần với thực tế nhất có thể: lấy mẫu email và tin nhắn thật, đếm tỷ lệ lỗi chính tả, tỷ lệ từ viết tắt, tỷ lệ câu không đầy đủ — và xác định xem mô hình cần được huấn luyện để xử lý những đặc điểm này, hay dữ liệu cần được làm sạch trước. Ngoài ra, cần kiểm tra xem văn bản có chứa thông tin nhạy cảm không — ví dụ số điện thoại, địa chỉ, số tài khoản trong nội dung email — và nếu có, cần ẩn danh hóa trước khi dùng để huấn luyện AI.
Hình ảnh: ảnh sản phẩm, ảnh hiện trường, giấy tờ scan
Định nghĩa: Dữ liệu hình ảnh là các bức ảnh mà doanh nghiệp thu thập được: ảnh sản phẩm, ảnh hiện trường sản xuất, ảnh giấy tờ đã scan, ảnh chụp từ camera. Với các ứng dụng AI thị giác máy tính — ví dụ kiểm tra chất lượng sản phẩm bằng hình ảnh, đọc thông tin từ giấy tờ scan — dữ liệu hình ảnh là nguyên liệu huấn luyện chính.
Đánh giá dữ liệu hình ảnh gồm bốn khía cạnh. Thứ nhất là độ phân giải và độ rõ: ảnh có đủ rõ để nhìn thấy chi tiết cần thiết không, hay bị mờ, thiếu sáng, chụp lệch góc. Thứ hai là tính đa dạng: ảnh có bao phủ đủ các trường hợp mà AI sẽ gặp trong thực tế không — ví dụ ảnh sản phẩm chụp dưới nhiều góc độ, nhiều điều kiện ánh sáng, nhiều nền khác nhau — hay chỉ có ảnh chụp trong điều kiện lý tưởng. Thứ ba là nhãn: nếu ảnh đã được gắn nhãn (ví dụ ảnh sản phẩm lỗi đã được đánh dấu vùng lỗi), nhãn đó có chính xác không, và có nhất quán giữa những người gắn nhãn không. Thứ tư là tính đại diện: ảnh có phản ánh đúng điều kiện thực tế mà AI sẽ hoạt động không — ví dụ ảnh huấn luyện chụp trong nhà xưởng sáng sủa, nhưng AI sẽ phải hoạt động trong nhà kho thiếu sáng. Một lỗi điển hình là huấn luyện mô hình bằng ảnh chụp đẹp trong phòng thí nghiệm, rồi thất vọng khi mô hình hoạt động kém với ảnh chụp vội vàng bằng điện thoại tại hiện trường.
Ghi âm và âm thanh: cuộc gọi khách hàng, ghi âm họp
Định nghĩa: Dữ liệu ghi âm là các bản ghi âm cuộc gọi khách hàng, ghi âm họp, ghi âm đào tạo — những dữ liệu mà doanh nghiệp thu thập được trong quá trình làm việc hàng ngày. Với các ứng dụng AI như tóm tắt cuộc gọi, phân tích cảm xúc qua giọng nói, hay chuyển giọng nói thành văn bản, dữ liệu ghi âm là nguyên liệu huấn luyện quan trọng.
Đánh giá dữ liệu ghi âm gồm bốn khía cạnh. Thứ nhất là chất lượng âm thanh: ghi âm có rõ không, có nhiễu nền không, có nhiều người nói cùng lúc không, và giọng nói có đủ lớn để nghe rõ không. Thứ hai là tính đại diện của giọng nói: ghi âm có bao phủ đủ các giọng vùng miền, độ tuổi, và tốc độ nói của khách hàng thực tế không — hay chỉ có giọng của một nhóm nhỏ nhân viên. Thứ ba là bản ghi chép kèm theo: nếu ghi âm đã được chuyển thành văn bản, bản ghi chép đó có chính xác không, và có được kiểm tra lại không — vì mô hình học từ bản ghi chép sai sẽ học sai. Thứ tư là quyền sử dụng và bảo mật: khách hàng có biết cuộc gọi của họ được ghi âm không, và họ có đồng ý cho doanh nghiệp dùng bản ghi âm đó để huấn luyện AI không. Đây là khía cạnh pháp lý đặc biệt quan trọng với dữ liệu ghi âm, vì giọng nói là dữ liệu sinh trắc học ở nhiều quy định — và việc dùng ghi âm mà không có sự đồng ý rõ ràng có thể vi phạm pháp luật.
Bảng chấm điểm mức độ sẵn sàng dữ liệu
Sau khi kiểm tra xong sáu chiều chất lượng dữ liệu, doanh nghiệp cần một cách tổng hợp kết quả thành một điểm số duy nhất — để biết dữ liệu của mình đang ở mức nào, và cần bao nhiêu thời gian để đạt mức sẵn sàng. Bảng dưới đây là một thang chấm điểm từ 0 đến 4 cho mỗi chiều, dựa trên các chỉ số đo được ở các bước trên. Điểm số không phải là một con số tuyệt đối: nó là công cụ để doanh nghiệp so sánh các chiều với nhau, xác định chiều nào yếu nhất, và ưu tiên sửa chiều đó trước.
Cách dùng bảng rất đơn giản: với mỗi chiều, xác định mức điểm phù hợp nhất với dữ liệu hiện tại của doanh nghiệp, dựa trên các mô tả trong bảng. Sau đó tính điểm trung bình của sáu chiều để ra điểm tổng thể, và đối chiếu với bốn mức sẵn sàng ở phần sau của bảng. Một lưu ý quan trọng: điểm trung bình có thể che giấu một chiều rất yếu — ví dụ năm chiều đạt 4 điểm nhưng chiều hợp pháp chỉ đạt 0 điểm thì dữ liệu vẫn không dùng được. Vì vậy, ngoài điểm trung bình, doanh nghiệp cần xem điểm thấp nhất: nếu bất kỳ chiều nào dưới 1,5 điểm, dữ liệu chưa sẵn sàng, bất kể điểm trung bình là bao nhiêu.
| Chiều | 0 điểm — Chưa có | 1 điểm — Rất yếu | 2 điểm — Yếu | 3 điểm — Khá | 4 điểm — Tốt |
|---|---|---|---|---|---|
| Đầy đủ | Dữ liệu cần thiết không tồn tại | Thiếu trên 40% ở trường quan trọng | Thiếu 20–40% ở trường quan trọng | Thiếu 5–20%, đã có kế hoạch bổ sung | Thiếu dưới 5% ở mọi trường quan trọng |
| Chính xác | Chưa từng kiểm tra với nguồn gốc | Sai trên 20% bản ghi được kiểm tra | Sai 10–20% bản ghi được kiểm tra | Sai 5–10%, đã biết nguyên nhân | Sai dưới 5%, có quy trình kiểm soát |
| Nhất quán | Không có chuẩn chung, mỗi hệ thống một quy ước | Cùng một sự thật ghi khác nhau ở nhiều nơi | Đã có chuẩn nhưng chưa áp dụng đầy đủ | Nhất quán trong từng hệ thống, còn lệch giữa các hệ thống | Nhất quán ở mọi hệ thống, có danh mục chuẩn |
| Kịp thời | Dữ liệu đã lỗi thời hơn 1 năm | Cập nhật theo tháng, chậm hơn yêu cầu | Cập nhật theo tuần, còn chậm so với yêu cầu | Cập nhật theo ngày, đáp ứng yêu cầu | Cập nhật theo thời gian thực hoặc gần thời gian thực |
| Đại diện | Dữ liệu chỉ phản ánh một nhóm nhỏ | Một số nhóm quan trọng vắng mặt | Có đủ nhóm nhưng tỷ lệ lệch nhiều | Tỷ lệ các nhóm gần với thực tế | Tỷ lệ các nhóm khớp với thực tế, đã kiểm tra thiên vị |
| Hợp pháp | Chưa rõ nguồn gốc và quyền sử dụng | Có rủi ro pháp lý chưa được giải quyết | Đã xác định được vấn đề, đang xử lý | Quyền sử dụng đã được xác nhận, còn thiếu vài thủ tục | Quyền sử dụng đầy đủ, có quy trình bảo mật |
Điểm trung bình của sáu chiều được hiểu theo bốn mức. Mức dưới 1,5 điểm nghĩa là dữ liệu chưa sẵn sàng: doanh nghiệp cần dừng lại làm dữ liệu trước, vì triển khai AI lúc này gần như chắc chắn sẽ thất bại hoặc cho kết quả không đáng tin cậy. Mức từ 1,5 đến dưới 2,5 điểm nghĩa là dữ liệu ở mức yếu: có thể bắt đầu với một PoC nhỏ trên phạm vi thu hẹp, nhưng cần song song cải thiện dữ liệu, và không nên kỳ vọng kết quả cao. Mức từ 2,5 đến dưới 3,5 điểm nghĩa là dữ liệu ở mức khá: có thể triển khai AI cho bài toán đã xác định, với kế hoạch giám sát và cải thiện dữ liệu liên tục sau khi vận hành. Mức từ 3,5 điểm trở lên nghĩa là dữ liệu đã sẵn sàng: doanh nghiệp có thể triển khai AI với độ tin cậy cao, và nên tập trung nguồn lực vào việc xây dựng mô hình và tích hợp hệ thống, thay vì tiếp tục làm sạch dữ liệu.
Một lưu ý cuối cùng về bảng chấm điểm: điểm số chỉ có ý nghĩa khi được chấm dựa trên số liệu đo được, không phải cảm nhận. Nếu doanh nghiệp chấm 4 điểm cho chiều đầy đủ chỉ vì cảm thấy dữ liệu có vẻ đầy đủ, mà chưa từng đo tỷ lệ thiếu, thì điểm số đó không có giá trị. Vì vậy, bảng chấm điểm nên được dùng sau khi đã hoàn thành bảy bước kiểm tra ở trên — khi doanh nghiệp đã có số liệu cụ thể về tỷ lệ thiếu, sai, trùng lặp và tính đại diện. Khi đó, điểm số sẽ là một công cụ ra quyết định đáng tin cậy, giúp ban lãnh đạo biết mình đang ở đâu và cần bao lâu để sẵn sàng.
Lộ trình cải thiện dữ liệu trước khi triển khai AI
Sau khi đã có điểm số mức độ sẵn sàng dữ liệu, doanh nghiệp cần một lộ trình cải thiện cụ thể — không phải làm tất cả mọi thứ cùng lúc, mà làm theo thứ tự: dọn dẹp nhanh những lỗi rõ ràng nhất, chuẩn hóa và bổ sung từ gốc, rồi xây dựng quản trị dữ liệu lâu dài để dữ liệu không xấu trở lại. Ba giai đoạn dưới đây tương ứng với ba mức độ đầu tư khác nhau, và có thể triển khai nối tiếp nhau trong 3–6 tháng.
Giai đoạn 1: Dọn dẹp nhanh (2–4 tuần) — sửa những lỗi rõ ràng nhất
Định nghĩa: Giai đoạn dọn dẹp nhanh tập trung vào việc sửa những lỗi rõ ràng nhất và dễ sửa nhất trong dữ liệu: xóa bản ghi trùng lặp, chuẩn hóa định dạng ngày tháng và đơn vị, thay thế các giá trị giữ chỗ bằng giá trị thật hoặc đánh dấu là thiếu, và bổ sung các trường bị thiếu mà có thể suy ra được từ dữ liệu khác. Giai đoạn này không đòi hỏi thay đổi quy trình hay hệ thống — chỉ cần làm sạch dữ liệu hiện có bằng các công cụ và quy tắc đã xác định.
Ví dụ cụ thể: nếu trường ngày sinh có nhiều bản ghi mang giá trị 01/01/1900, hãy đánh dấu các bản ghi đó là thiếu ngày sinh thay vì để nguyên giá trị giả. Nếu trường giá trị có nhiều bản ghi mang giá trị 0 đồng trong khi sản phẩm không thể có giá bằng không, hãy kiểm tra lại với nguồn gốc hoặc đánh dấu là thiếu. Nếu trường số lượng có nhiều bản ghi mang giá trị 999, hãy xác minh xem đó có phải là số lượng thật không — vì 999 thường là giá trị giữ chỗ khi người nhập không biết số lượng thật. Một nguyên tắc quan trọng trong giai đoạn này: mọi thao tác làm sạch phải được ghi lại và có thể lặp lại — tức là doanh nghiệp cần biết chính xác đã sửa gì, sửa như thế nào, và có thể chạy lại quy trình làm sạch đó trên dữ liệu mới trong tương lai. Nếu làm sạch bằng cách sửa tay từng bản ghi mà không ghi lại quy tắc, dữ liệu sẽ lại bẩn ngay khi có dữ liệu mới nhập vào.
Giai đoạn 2: Chuẩn hóa và bổ sung (1–3 tháng) — sửa từ gốc và lấp khoảng trống
Định nghĩa: Giai đoạn chuẩn hóa và bổ sung tập trung vào việc sửa dữ liệu từ gốc: xây dựng danh mục chuẩn cho các giá trị hay bị ghi khác nhau (ví dụ mã khách hàng, mã sản phẩm, tên địa phương), hợp nhất các bản ghi trùng lặp về một bản ghi duy nhất, và bổ sung dữ liệu còn thiếu bằng cách thu thập thêm hoặc suy ra từ các nguồn khác. Khác với giai đoạn 1 chỉ sửa bề mặt, giai đoạn 2 thay đổi cách dữ liệu được tạo ra và lưu trữ — nên cần sự tham gia của cả đội nghiệp vụ và đội công nghệ.
Ví dụ, nếu cùng một khách hàng có ba mã khác nhau ở ba hệ thống, giai đoạn 2 sẽ chọn một mã duy nhất làm mã chuẩn, đối chiếu và hợp nhất tất cả các bản ghi về mã đó, và thiết lập quy trình để dữ liệu mới nhập vào luôn dùng mã chuẩn. Nếu một trường quan trọng bị thiếu ở 30% bản ghi, giai đoạn 2 sẽ xác định vì sao nó thiếu — do quy trình nhập liệu không bắt buộc, do hệ thống không lưu, hay do dữ liệu đó không tồn tại — và sửa từ gốc: bắt buộc nhập trường đó trong quy trình mới, bổ sung dữ liệu từ nguồn khác nếu có, hoặc chấp nhận rằng trường đó không thể bổ sung được và điều chỉnh bài toán AI cho phù hợp. Giai đoạn này thường mất 1–3 tháng, vì nó đòi hỏi người hiểu nghiệp vụ xác nhận từng quyết định hợp nhất và bổ sung — máy móc không thể tự quyết định xem hai khách hàng có tên gần giống nhau có phải là cùng một người hay không.
Giai đoạn 3: Quản trị dữ liệu lâu dài (từ 3 tháng trở đi) — để dữ liệu không xấu trở lại
Định nghĩa: Giai đoạn quản trị dữ liệu lâu dài tập trung vào việc xây dựng cơ chế để dữ liệu không xấu trở lại sau khi đã làm sạch: chỉ định người phụ trách dữ liệu cho từng nguồn dữ liệu, đặt ra quy tắc nhập liệu và kiểm tra chất lượng định kỳ, và thiết lập quy trình giám sát để phát hiện sớm khi dữ liệu bắt đầu xấu đi. Quản trị dữ liệu (data governance) nghe có vẻ là một khái niệm lớn, nhưng trong thực tế nó bắt đầu từ những việc rất đơn giản: ai chịu trách nhiệm về dữ liệu nào, dữ liệu mới được nhập theo chuẩn nào, và ai kiểm tra dữ liệu đó mỗi tháng.
Ví dụ, doanh nghiệp chỉ định một người phụ trách dữ liệu khách hàng: người đó chịu trách nhiệm kiểm tra hàng tháng xem có bao nhiêu bản ghi mới bị thiếu trường quan trọng, có bao nhiêu bản ghi trùng lặp mới xuất hiện, và có bao nhiêu giá trị không tuân theo danh mục chuẩn. Khi phát hiện vấn đề, người phụ trách báo cáo và phối hợp sửa — trước khi vấn đề lan rộng. Đồng thời, doanh nghiệp đặt ra quy tắc: dữ liệu mới nhập vào hệ thống phải tuân theo danh mục chuẩn, nếu không hệ thống sẽ báo lỗi và không cho lưu. Ba việc này — người phụ trách, quy tắc nhập liệu, kiểm tra định kỳ — là nền tảng của quản trị dữ liệu, và chúng đảm bảo rằng công sức làm sạch dữ liệu ở hai giai đoạn trước không bị lãng phí khi dữ liệu mới tiếp tục được nhập vào mỗi ngày.
| Giai đoạn | Thời gian | Việc chính | Kết quả |
|---|---|---|---|
| 1. Dọn dẹp nhanh | 2–4 tuần | Xóa trùng lặp, chuẩn hóa định dạng, thay giá trị giữ chỗ | Dữ liệu sạch ở mức bề mặt, sẵn sàng kiểm tra sâu |
| 2. Chuẩn hóa và bổ sung | 1–3 tháng | Xây danh mục chuẩn, hợp nhất bản ghi, bổ sung dữ liệu thiếu | Dữ liệu nhất quán và đầy đủ hơn, sửa từ gốc |
| 3. Quản trị lâu dài | Từ 3 tháng trở đi | Chỉ định người phụ trách, quy tắc nhập liệu, kiểm tra định kỳ | Dữ liệu duy trì chất lượng, không xấu trở lại |
Khi nào dữ liệu đủ tốt để bắt đầu?
Định nghĩa: Dữ liệu được coi là đủ tốt để bắt đầu triển khai AI khi nó đáp ứng được các tiêu chí tối thiểu của bài toán cụ thể — không phải khi nó hoàn hảo. Hoàn hảo là một tiêu chuẩn không thực tế: không có tập dữ liệu nào trong thực tế đạt 100% đầy đủ, chính xác và nhất quán. Câu hỏi đúng không phải là dữ liệu có hoàn hảo không, mà là dữ liệu có đủ tốt cho bài toán này, với phạm vi này, và với mức rủi ro mà doanh nghiệp chấp nhận được không.
Năm dấu hiệu cho thấy dữ liệu đã đủ tốt để bắt đầu. Thứ nhất, các trường bắt buộc đã có và tỷ lệ thiếu, sai đã được đo — doanh nghiệp biết chính xác dữ liệu của mình thiếu bao nhiêu phần trăm, sai bao nhiêu phần trăm, chứ không phải đoán. Thứ hai, không còn lỗi có hệ thống chưa được giải thích — những lỗi còn lại là lỗi ngẫu nhiên, không phải lỗi ảnh hưởng đến toàn bộ một nhóm hay một giai đoạn. Thứ ba, dữ liệu đại diện cho phạm vi triển khai — tức là dữ liệu bao phủ đúng nhóm đối tượng mà AI sẽ phục vụ trong giai đoạn đầu, dù chưa bao phủ toàn bộ doanh nghiệp. Thứ tư, quyền sử dụng dữ liệu đã được xác nhận — doanh nghiệp biết mình được phép dùng dữ liệu này cho AI, và đã có biện pháp bảo vệ dữ liệu nhạy cảm. Thứ năm, có kế hoạch giám sát sau triển khai — doanh nghiệp biết sẽ theo dõi chất lượng dữ liệu như thế nào sau khi AI đi vào vận hành, và sẽ làm gì khi dữ liệu bắt đầu xấu đi.
Ngược lại, có năm dấu hiệu cho thấy doanh nghiệp phải dừng lại làm dữ liệu trước. Thứ nhất, dữ liệu cho bài toán không tồn tại — ví dụ bài toán cần lịch sử giao dịch 2 năm nhưng doanh nghiệp chỉ lưu 3 tháng. Thứ hai, tỷ lệ sai cao và có hệ thống ở trường bắt buộc — ví dụ 30% đơn hàng có giá sai vì bảng giá chưa được cập nhật. Thứ ba, dữ liệu không đại diện cho đối tượng sẽ áp dụng — ví dụ dữ liệu huấn luyện chỉ có khách hàng thành phố trong khi AI sẽ phục vụ cả khách hàng tỉnh. Thứ tư, vấn đề pháp lý chưa được giải quyết — ví dụ chưa rõ có được dùng dữ liệu khách hàng để huấn luyện AI không. Thứ năm, không ai trong doanh nghiệp hiểu dữ liệu đó — không ai biết dữ liệu đến từ đâu, được thu thập như thế nào, và có đáng tin không. Khi gặp bất kỳ dấu hiệu nào trong năm dấu hiệu này, quyết định đúng là dừng lại, làm dữ liệu trước, rồi mới quay lại với AI — vì triển khai AI trên dữ liệu như vậy không chỉ lãng phí, mà còn có thể gây hại: mô hình đưa ra quyết định sai một cách có hệ thống, và doanh nghiệp mất niềm tin vào AI.
Một cách thực tế để quyết định là bắt đầu với phạm vi thu hẹp (pilot có kiểm soát): chọn một nhóm nhỏ khách hàng, một chi nhánh, hay một loại sản phẩm để triển khai AI trước, đo kết quả trong 1–2 tháng, rồi mới quyết định mở rộng. Pilot có kiểm soát giúp doanh nghiệp kiểm chứng dữ liệu trong thực tế — vì có những vấn đề về dữ liệu chỉ lộ ra khi AI vận hành thật, không lộ ra khi kiểm tra trên mẫu. Nếu pilot đạt kết quả tốt, doanh nghiệp mở rộng dần. Nếu pilot cho thấy dữ liệu còn vấn đề, doanh nghiệp quay lại làm dữ liệu — với chi phí và rủi ro thấp hơn nhiều so với việc triển khai toàn bộ ngay từ đầu.
Các sai lầm thường gặp khi đánh giá dữ liệu cho AI
Sai lầm 1: Đánh giá dữ liệu bằng cảm nhận thay vì bằng số liệu. Nhóm đánh giá hỏi người phụ trách dữ liệu có tốt không, nhận được câu trả lời có vẻ ổn, và ghi nhận dữ liệu tốt mà không đo tỷ lệ thiếu, sai hay trùng lặp. Cách làm đúng là luôn đo bằng số liệu: tỷ lệ thiếu là bao nhiêu phần trăm, tỷ lệ sai là bao nhiêu phần trăm, tỷ lệ trùng lặp là bao nhiêu phần trăm. Cảm nhận của con người về dữ liệu thường lạc quan hơn thực tế — vì người ta chỉ nhớ những lần dữ liệu đúng, không nhớ những lần dữ liệu sai.
Sai lầm 2: Kiểm tra dữ liệu mà không xác định bài toán AI. Nhóm đánh giá kiểm tra tất cả dữ liệu trong doanh nghiệp một cách chung chung, mất nhiều tuần, nhưng cuối cùng không trả lời được dữ liệu có đủ tốt cho bài toán nào. Cách làm đúng là xác định bài toán AI trước, rồi chỉ kiểm tra dữ liệu mà bài toán đó cần. Một tập dữ liệu có thể không đủ tốt cho bài toán dự báo nhu cầu nhưng lại đủ tốt cho bài toán phân loại email — và không có cách nào biết được nếu bài toán chưa được xác định.
Sai lầm 3: Nhầm lẫn giữa nhiều dữ liệu và đủ dữ liệu. Doanh nghiệp tự hào vì có hàng triệu dòng dữ liệu, và kết luận rằng dữ liệu đã đủ tốt. Nhưng số lượng không thay thế được chất lượng: hàng triệu dòng dữ liệu thiếu trường quan trọng vẫn là dữ liệu không đủ tốt. Cách làm đúng là kiểm tra chất lượng trước, số lượng sau — và chỉ khi chất lượng đã đạt mức tối thiểu mới tính đến việc có đủ số lượng không.
Sai lầm 4: Chỉ kiểm tra dữ liệu có cấu trúc mà bỏ qua dữ liệu phi cấu trúc. Nhiều bài toán AI dùng dữ liệu phi cấu trúc — email, hợp đồng, ghi âm, hình ảnh — nhưng nhóm đánh giá chỉ kiểm tra dữ liệu trong bảng. Cách làm đúng là xác định bài toán cần loại dữ liệu nào, và kiểm tra đúng loại dữ liệu đó — với các tiêu chí phù hợp với từng loại, như đã trình bày ở phần dữ liệu phi cấu trúc.
Sai lầm 5: Đánh giá một lần rồi không bao giờ đánh giá lại. Doanh nghiệp đánh giá dữ liệu trước khi triển khai AI, thấy dữ liệu đủ tốt, rồi không bao giờ kiểm tra lại — trong khi dữ liệu thay đổi mỗi ngày: dữ liệu mới được nhập vào, hệ thống mới được thêm vào, quy trình thay đổi. Cách làm đúng là thiết lập quy trình giám sát chất lượng dữ liệu định kỳ sau khi AI đi vào vận hành, và đánh giá lại mỗi khi có thay đổi lớn về dữ liệu hay bài toán.
Sai lầm 6: Bỏ qua chiều hợp pháp vì cho rằng dữ liệu của mình thì mình được dùng tùy ý. Doanh nghiệp kiểm tra kỹ năm chiều kỹ thuật nhưng không kiểm tra quyền sử dụng dữ liệu, và phát hiện ra vấn đề pháp lý khi dự án đã triển khai được một nửa. Cách làm đúng là kiểm tra chiều hợp pháp song song với các chiều kỹ thuật, ngay từ đầu — và tham khảo ý kiến pháp lý khi có nghi ngờ, thay vì đợi đến khi có sự cố.
Sai lầm 7: Làm sạch dữ liệu bằng cách sửa tay mà không ghi lại quy tắc. Nhóm đánh giá sửa từng bản ghi sai bằng tay, dữ liệu trông sạch hơn, nhưng không ai biết đã sửa gì và sửa như thế nào — nên khi dữ liệu mới nhập vào, lỗi cũ lại xuất hiện. Cách làm đúng là mọi thao tác làm sạch đều phải được ghi lại thành quy tắc và có thể lặp lại tự động — để dữ liệu mới cũng được làm sạch theo cùng một cách, và để người khác có thể kiểm tra lại những gì đã sửa.
Ví dụ thực tế: đánh giá dữ liệu theo từng loại bài toán AI
Để thấy rõ cách áp dụng sáu chiều và bảy bước kiểm tra vào thực tế, dưới đây là ba ví dụ đánh giá dữ liệu theo từng loại bài toán AI phổ biến trong doanh nghiệp: chatbot chăm sóc khách hàng, dự báo nhu cầu và tồn kho, và phân loại tài liệu. Mỗi ví dụ cho thấy dữ liệu quan trọng nhất là gì, chiều chất lượng nào cần chú ý nhất, và lỗi nào thường gặp nhất với loại bài toán đó.
Chatbot chăm sóc khách hàng: dữ liệu là lịch sử hội thoại
Với bài toán chatbot chăm sóc khách hàng, dữ liệu quan trọng nhất là lịch sử hội thoại giữa khách hàng và nhân viên — hàng nghìn đoạn chat, email và cuộc gọi đã được xử lý trong quá khứ. Bốn chiều cần chú ý nhất là: nhãn phân loại — mỗi hội thoại đã được gắn nhãn đúng chủ đề và đúng ý định của khách hàng chưa; tính đại diện của chủ đề — dữ liệu có bao phủ đủ các chủ đề mà khách hàng sẽ hỏi không, hay chỉ có những chủ đề phổ biến; chất lượng câu trả lời mẫu — câu trả lời của nhân viên trong lịch sử có đúng và nhất quán không, vì chatbot sẽ học cách trả lời từ chính những câu trả lời đó; và quyền sử dụng — khách hàng có đồng ý cho doanh nghiệp dùng lịch sử hội thoại của họ để huấn luyện chatbot không. Lỗi thường gặp nhất với bài toán này là dữ liệu hội thoại chỉ bao phủ các câu hỏi đơn giản, vì những câu hỏi phức tạp thường được xử lý qua điện thoại và không được lưu lại — khiến chatbot trả lời tốt những câu dễ nhưng lúng túng với những câu khó, đúng vào lúc khách hàng cần giúp đỡ nhất.
Dự báo nhu cầu và tồn kho: dữ liệu là lịch sử bán hàng
Với bài toán dự báo nhu cầu và tồn kho, dữ liệu quan trọng nhất là lịch sử bán hàng theo ngày — số lượng bán ra của từng mặt hàng, tại từng cửa hàng, trong từng ngày. Bốn chiều cần chú ý nhất là: tính đầy đủ theo thời gian — lịch sử bán hàng có bao phủ đủ dài không, có bị thiếu những giai đoạn nào không (ví dụ thiếu dữ liệu của tháng Tết vì hệ thống cũ không lưu); yếu tố khuyến mãi và sự kiện — dữ liệu có ghi lại chương trình khuyến mãi, ngày lễ, và sự kiện đặc biệt không, vì những yếu tố này ảnh hưởng lớn đến nhu cầu; tính nhất quán giữa các nguồn — số liệu bán hàng ở hệ thống bán hàng có khớp với số liệu ở hệ thống kế toán và hệ thống kho không; và độ dài lịch sử — dữ liệu có đủ dài để mô hình học được tính mùa vụ không (ví dụ ít nhất 1–2 năm để học được mẫu theo mùa). Lỗi thường gặp nhất với bài toán này là dữ liệu lịch sử trông có vẻ đủ — vài năm dữ liệu bán hàng — nhưng lại thiếu thông tin về khuyến mãi và sự kiện, khiến mô hình không hiểu vì sao nhu cầu tăng vọt trong một số tuần, và dự báo sai mỗi khi có chương trình khuyến mãi mới.
Phân loại và trích xuất từ tài liệu: dữ liệu là hợp đồng và chứng từ
Với bài toán phân loại và trích xuất thông tin từ tài liệu, dữ liệu quan trọng nhất là tập hợp các tài liệu mẫu — hợp đồng, chứng từ, hóa đơn, đơn đặt hàng — cùng với đáp án đúng cho mỗi tài liệu. Bốn chiều cần chú ý nhất là: chất lượng scan và OCR — tài liệu scan có đủ rõ để máy đọc được chữ không, hay bị mờ, nghiêng, thiếu trang; sự đa dạng của mẫu tài liệu — dữ liệu có bao phủ đủ các loại mẫu tài liệu mà doanh nghiệp dùng không, hay chỉ có một mẫu duy nhất; nhãn và đáp án đúng — mỗi tài liệu mẫu có đáp án đúng đã được kiểm tra không, và hai người gắn nhãn cùng một tài liệu có cho ra cùng một đáp án không; và tính nhạy cảm — tài liệu có chứa thông tin nhạy cảm như giá cả, điều khoản bảo mật, hay thông tin cá nhân không, và nếu có, doanh nghiệp đã có biện pháp bảo vệ khi dùng tài liệu đó để huấn luyện AI chưa. Lỗi thường gặp nhất với bài toán này là dữ liệu huấn luyện chỉ gồm những tài liệu đẹp, rõ ràng, đúng mẫu — trong khi tài liệu thực tế mà AI phải xử lý thường là bản scan mờ, bị gấp góc, hay dùng một mẫu cũ mà hệ thống chưa từng thấy.
Checklist đánh giá dữ liệu cho AI
Để giúp doanh nghiệp tự đánh giá dữ liệu của mình một cách nhanh chóng, dưới đây là một checklist tổng hợp từ tất cả các nội dung đã trình bày trong bài viết. Mỗi mục trong checklist tương ứng với một câu hỏi cụ thể mà nhóm đánh giá cần trả lời bằng có hoặc không, dựa trên số liệu đo được — không phải cảm nhận. Doanh nghiệp có thể in checklist này ra và dùng trong buổi làm việc đánh giá dữ liệu đầu tiên của mình.
| # | Câu hỏi kiểm tra | Có / Không / Chưa rõ |
|---|---|---|
| 1 | Bài toán AI đã được xác định rõ ràng, với mục tiêu kinh doanh và chỉ số đo cụ thể chưa? | |
| 2 | Đã lập danh mục đầy đủ các nguồn dữ liệu mà bài toán cần chưa? | |
| 3 | Tỷ lệ thiếu ở các trường quan trọng đã được đo bằng số liệu chưa? | |
| 4 | Tỷ lệ sai đã được đo bằng cách đối chiếu với nguồn gốc hoặc quy tắc nghiệp vụ chưa? | |
| 5 | Tỷ lệ trùng lặp đã được đo và các bản ghi trùng đã được xác định chưa? | |
| 6 | Cùng một sự thật có được ghi giống nhau ở mọi hệ thống không? | |
| 7 | Dữ liệu có được cập nhật đủ nhanh so với yêu cầu của bài toán không? | |
| 8 | Dữ liệu có đại diện cho đúng đối tượng mà AI sẽ phục vụ không? | |
| 9 | Đã kiểm tra thiên vị trong dữ liệu và trong nhãn dữ liệu chưa? | |
| 10 | Nguồn gốc và quyền sử dụng dữ liệu cho AI đã được xác nhận chưa? | |
| 11 | Dữ liệu nhạy cảm đã được xác định và có biện pháp bảo vệ chưa? | |
| 12 | Dữ liệu phi cấu trúc (nếu có) đã được đánh giá theo tiêu chí riêng chưa? | |
| 13 | Điểm số mức độ sẵn sàng dữ liệu đã được chấm theo bảng 0–4 chưa? | |
| 14 | Đã có kế hoạch giám sát chất lượng dữ liệu sau khi AI đi vào vận hành chưa? |
Cách dùng checklist rất đơn giản: với mỗi mục, trả lời có, không, hay chưa rõ — dựa trên số liệu đo được, không phải cảm nhận. Nếu một mục trả lời chưa rõ, đó là dấu hiệu cho thấy nhóm đánh giá cần đo thêm trước khi kết luận. Nếu nhiều mục trả lời không, dữ liệu chưa sẵn sàng và doanh nghiệp cần làm theo lộ trình cải thiện ở phần trước. Checklist này không phải là bài kiểm tra đậu hay rớt — nó là công cụ để doanh nghiệp biết mình đang ở đâu và cần làm gì tiếp theo, một cách cụ thể và có thứ tự ưu tiên.
Doanh nghiệp có thể dùng checklist này trong buổi làm việc đánh giá dữ liệu đầu tiên: mỗi người phụ trách một vài mục, đo số liệu, rồi cùng nhau chấm điểm và ra quyết định. Khi đã hoàn thành checklist, doanh nghiệp sẽ có một bức tranh rõ ràng về dữ liệu của mình — và đó là nền tảng để mọi quyết định về AI sau này đều dựa trên số liệu, không phải cảm tính.
Câu hỏi thường gặp (FAQs)
Dữ liệu của doanh nghiệp cần bao nhiêu bản ghi mới đủ để triển khai AI?
Không có một con số chung cho mọi bài toán. Một bài toán phân loại đơn giản có thể bắt đầu với vài trăm bản ghi đã được gắn nhãn đúng, trong khi một mô hình dự báo phức tạp có thể cần hàng chục nghìn bản ghi theo thời gian. Điều quan trọng hơn số lượng là chất lượng: vài nghìn bản ghi đầy đủ, chính xác và đại diện có giá trị hơn hàng triệu bản ghi thiếu trường quan trọng. Doanh nghiệp nên xác định bài toán cụ thể trước, rồi tính xem bài toán đó cần bao nhiêu dữ liệu — và kiểm tra xem dữ liệu hiện có có đạt số lượng đó không, sau khi đã làm sạch.
Đánh giá dữ liệu mất bao lâu và tốn bao nhiêu chi phí?
Một đợt đánh giá dữ liệu cho một bài toán AI cụ thể thường mất 2–4 tuần làm việc tập trung của một nhóm 2–3 người, bao gồm cả người phụ trách nghiệp vụ và người phụ trách dữ liệu. Thời gian tăng lên khi dữ liệu nằm rải rác ở nhiều hệ thống, hoặc khi bài toán AI chưa được xác định rõ ràng. Chi phí chủ yếu là thời gian của đội ngũ nội bộ — không cần mua thêm công cụ đắt tiền, vì phần lớn công việc kiểm tra có thể làm bằng các công cụ phân tích dữ liệu có sẵn hoặc bảng tính. So với chi phí của một dự án AI thất bại giữa chừng vì dữ liệu, chi phí đánh giá dữ liệu là rất nhỏ.
Khi nào dữ liệu được coi là đủ tốt để bắt đầu triển khai AI?
Dữ liệu được coi là đủ tốt khi nó đáp ứng được năm dấu hiệu đã trình bày trong bài viết: các trường bắt buộc đã có và tỷ lệ thiếu, sai đã được đo; không còn lỗi có hệ thống chưa được giải thích; dữ liệu đại diện cho phạm vi triển khai; quyền sử dụng dữ liệu đã được xác nhận; và có kế hoạch giám sát sau triển khai. Ngoài ra, điểm trung bình theo bảng chấm điểm nên đạt từ 2,5 trở lên, và không có chiều nào dưới 1,5 điểm. Nếu chưa đạt, doanh nghiệp nên làm theo lộ trình cải thiện dữ liệu trước khi triển khai, hoặc bắt đầu với một phạm vi thu hẹp để kiểm chứng trong thực tế.
Doanh nghiệp nhỏ không có chuyên gia dữ liệu có tự đánh giá được không?
Có, với sự hỗ trợ phù hợp. Doanh nghiệp nhỏ có thể tự thực hiện các bước cơ bản: xác định bài toán, lập danh mục dữ liệu, lấy mẫu kiểm tra, và đo tỷ lệ thiếu, sai, trùng lặp bằng bảng tính hoặc công cụ phân tích dữ liệu đơn giản. Những bước cần chuyên môn sâu hơn — ví dụ kiểm tra thiên vị, hay đánh giá dữ liệu phi cấu trúc — có thể nhờ đối tác bên ngoài hỗ trợ trong một đợt đánh giá ngắn. Điều quan trọng là bắt đầu bằng những bước đơn giản và đo bằng số liệu, thay vì đợi đến khi có đủ chuyên gia mới bắt đầu đánh giá.
Dữ liệu phi cấu trúc như email và ghi âm có đánh giá được không?
Có, nhưng bằng các tiêu chí riêng như đã trình bày trong bài viết: với văn bản, kiểm tra số lượng, độ bao phủ chủ đề, chất lượng ngôn ngữ, tính nhất quán của nhãn và tính cập nhật; với hình ảnh, kiểm tra độ phân giải, tính đa dạng, nhãn và tính đại diện; với ghi âm, kiểm tra chất lượng âm thanh, tính đại diện của giọng nói, bản ghi chép kèm theo và quyền sử dụng. Dữ liệu phi cấu trúc thường khó đánh giá hơn dữ liệu có cấu trúc vì không có các con số rõ ràng như tỷ lệ thiếu theo trường — nhưng vẫn có thể lấy mẫu, đếm và chấm điểm một cách có hệ thống.
Có cần đánh giá lại dữ liệu sau khi AI đã đi vào vận hành không?
Có, và đây là điều nhiều doanh nghiệp bỏ qua. Dữ liệu thay đổi mỗi ngày: dữ liệu mới được nhập vào, hệ thống mới được thêm vào, quy trình thay đổi, hành vi khách hàng thay đổi theo mùa và theo thị trường. Nếu không giám sát, chất lượng dữ liệu sẽ suy giảm dần và mô hình AI cũng suy giảm theo — hiện tượng model drift. Doanh nghiệp nên thiết lập quy trình kiểm tra chất lượng dữ liệu định kỳ (ví dụ hàng tháng hoặc hàng quý) sau khi AI đi vào vận hành, và đánh giá lại toàn diện mỗi khi có thay đổi lớn về dữ liệu hay bài toán.
Nếu dữ liệu chưa đủ tốt, có nên dừng hẳn dự án AI không?
Không nhất thiết phải dừng hẳn — mà nên điều chỉnh. Có ba lựa chọn thay vì dừng hẳn: thu hẹp phạm vi bài toán cho phù hợp với dữ liệu đang có (ví dụ triển khai AI cho một nhóm khách hàng hay một chi nhánh thay vì toàn bộ); làm dữ liệu trước theo lộ trình cải thiện, rồi quay lại với AI sau 1–3 tháng; hoặc bắt đầu với một PoC nhỏ trên phạm vi thu hẹp để kiểm chứng dữ liệu trong thực tế. Chỉ nên dừng hẳn khi dữ liệu cho bài toán không tồn tại, hoặc khi vấn đề pháp lý không thể giải quyết được — vì trong hai trường hợp đó, tiếp tục triển khai không chỉ lãng phí mà còn có thể gây hại.
Làm thế nào để biết dữ liệu của doanh nghiệp có đang bị thiên vị không?
Kiểm tra tính đại diện: so sánh tỷ lệ các nhóm trong dữ liệu với tỷ lệ các nhóm trong thực tế mà AI sẽ phục vụ. Nếu một nhóm chiếm 30% khách hàng thực tế nhưng chỉ chiếm 5% dữ liệu, đó là dấu hiệu của thiên vị về đại diện. Ngoài ra, kiểm tra nhãn dữ liệu: nếu dữ liệu huấn luyện là các quyết định của con người trong quá khứ, hãy kiểm tra xem các quyết định đó có thiên vị một nhóm nào không — ví dụ nhóm khách hàng ở một khu vực luôn bị từ chối dù đủ điều kiện. Nếu phát hiện thiên vị, doanh nghiệp có thể thu thập thêm dữ liệu cho nhóm bị thiếu, điều chỉnh dữ liệu để cân bằng các nhóm, hoặc giới hạn phạm vi áp dụng của AI cho đến khi vấn đề được giải quyết.
