Một dự án AI thất bại vì dữ liệu thì hiếm khi được gọi tên đúng như vậy. Nó thường được kể lại thành “mô hình chưa đủ thông minh”.
Dữ liệu rời rạc là vấn đề lớn hơn dữ liệu thiếu
Doanh nghiệp nào cũng có dữ liệu, nhiều hơn họ tưởng. Vấn đề là nó nằm rải rác: một phần trong phần mềm kế toán, một phần trong hệ thống bán hàng, một phần trong hàng trăm file bảng tính trên máy cá nhân, và một phần nằm trong các nhóm tin nhắn nội bộ. Mỗi nơi gọi cùng một thứ bằng một tên khác và ghi ngày tháng theo một định dạng khác.
Hệ quả là không ai trả lời được những câu hỏi tưởng như đơn giản: doanh nghiệp hiện có bao nhiêu khách hàng đang hoạt động, một mã sản phẩm tồn kho bao nhiêu. Nếu con người còn chưa trả lời được bằng dữ liệu sẵn có, thì đưa cùng dữ liệu đó cho một mô hình cũng không tạo ra câu trả lời đúng, chỉ tạo ra câu trả lời trôi chảy.
Trùng lặp và mâu thuẫn
Cùng một khách hàng xuất hiện ba lần với ba cách viết tên, hai số điện thoại và một địa chỉ đã cũ. Cùng một sản phẩm có hai mã vì hai chi nhánh tự đặt. Đây là tình trạng phổ biến ở mọi doanh nghiệp hoạt động đủ lâu, và nó không tự khỏi.
Việc cần làm trước khi nghĩ đến mô hình là thống nhất vài thứ cơ bản: đâu là nguồn được coi là đúng cho mỗi loại thông tin, quy tắc nào xác định hai bản ghi là một, và ai chịu trách nhiệm gộp và sửa. Đây là công việc nghiệp vụ hơn là kỹ thuật, và không thể thuê ngoài hoàn toàn.
Quyền truy cập phải được quyết định trước
Khi dữ liệu từ nhiều bộ phận được gom về một chỗ để phục vụ AI, một ranh giới vốn tồn tại tự nhiên sẽ biến mất. Trước đây, nhân viên kinh doanh không xem được bảng lương chỉ vì hai hệ thống tách rời nhau. Sau khi gom dữ liệu, nếu không thiết lập lại phân quyền, một công cụ hỏi đáp nội bộ có thể trả lời những câu mà người hỏi không có quyền biết.
Nên xác định trước vài điều:
- Mỗi tập dữ liệu thuộc về bộ phận nào và ai có quyền cho phép sử dụng nó.
- Vai trò nào được truy cập tập nào, và quyền đó kiểm tra ở tầng dữ liệu chứ không chỉ ở giao diện.
- Có ghi lại nhật ký truy vấn không, và ai được xem nhật ký đó.
- Dữ liệu có rời khỏi hạ tầng doanh nghiệp không, đi tới đâu, lưu bao lâu ở bên nhận.
Dữ liệu nhạy cảm cần được nhận diện trước
Trong kho dữ liệu của doanh nghiệp nào cũng có những phần cần đối xử khác: thông tin cá nhân của khách hàng và nhân viên, thông tin thanh toán, điều khoản hợp đồng có ràng buộc bảo mật, và tài liệu nội bộ chưa công bố. Trước khi đưa dữ liệu vào bất kỳ hệ thống AI nào, nên rà soát để biết những phần đó nằm ở đâu, rồi quyết định: loại bỏ, che bớt định danh, hay giới hạn truy cập chặt.
Cũng cần lưu ý ràng buộc pháp lý và cam kết với khách hàng về việc dữ liệu của họ được xử lý ở đâu. Nên hỏi ý kiến pháp chế từ sớm, vì sửa thiết kế trên giấy rẻ hơn gỡ dữ liệu khỏi một hệ thống đã vận hành.
Vì sao chất lượng dữ liệu quyết định nhiều hơn việc chọn mô hình
Các mô hình mạnh nhất hiện nay đều đã sẵn sàng để dùng, và khoảng cách giữa chúng hẹp hơn nhiều so với khoảng cách giữa một kho dữ liệu sạch và một kho lộn xộn. Mô hình chỉ làm việc trên thứ được đưa cho nó; nếu tài liệu nội bộ có ba phiên bản quy trình và không bản nào ghi ngày hiệu lực, câu trả lời nhận về sẽ phản ánh đúng sự mâu thuẫn đó, chỉ khác là được diễn đạt bằng giọng văn chắc chắn khiến người đọc dễ tin.
Đây cũng là lý do đổi sang mô hình khác hiếm khi cứu được một dự án đang chệch hướng. Khi kết quả không đạt, câu hỏi đầu tiên nên là dữ liệu đầu vào có đúng, đủ và cập nhật hay không.
Nên làm gì tiếp theo
Không cần dọn toàn bộ dữ liệu trước khi bắt đầu — làm vậy thì sẽ không bao giờ bắt đầu được. Cách thực tế hơn là chọn đúng một bài toán cụ thể, xác định nó cần những tập dữ liệu nào, rồi dọn gọn trong phạm vi đó: thống nhất nguồn đúng, xử lý trùng lặp, phân quyền rõ, tách phần nhạy cảm. Khi bài toán đầu tiên chạy được, doanh nghiệp vừa có kết quả để đánh giá, vừa có sẵn bộ quy tắc dữ liệu cho những bài toán sau. Đó là cách dọn nhà theo từng phòng, thay vì đợi cả căn nhà sạch mới dám mời khách.