Trong nhiều dự án Machine Learning, nhóm phát triển thường tập trung vào chọn mô hình, tinh chỉnh tham số hoặc dùng kiến trúc mới. Nhưng trước khi mô hình có thể học tốt, nó cần một thứ rất cơ bản: nhãn dữ liệu rõ ràng và nhất quán. Nếu nhãn bị mơ hồ, mỗi người gán một kiểu, mô hình sẽ học từ tín hiệu nhiễu và kết quả đánh giá cũng khó tin cậy. Bài viết này chia sẻ một số kinh nghiệm thực tế khi thiết kế nhãn dữ liệu cho dự án AI, đặc biệt phù hợp với các bài toán phân loại văn bản, nhận diện ý định người dùng, kiểm duyệt nội dung, phân loại ticket hỗ trợ hoặc gán nhãn ảnh. 1. Đừng bắt đầu bằng danh sách nhãn quá dài Một lỗi phổ biến là tạo ngay một bộ nhãn rất chi tiết vì nghĩ rằng càng chi tiết càng tốt. Ví dụ với hệ thống phân loại ticket chăm sóc khách hàng, nhóm có thể tạo hàng chục nhãn như: lỗi đăng nhập, quên mật khẩu, đổi email, xác thực hai lớp, tài khoản bị khóa, tài khoản nghi ngờ bị hack... Vấn đề là dữ liệu thực tế thường không phân bố đều. Một số nhãn có rất ít mẫu, một số nhãn lại chồng lấn. Người gán nhãn cũng dễ nhầm giữa các nhóm gần nhau. Cách làm thực tế hơn: - Bắt đầu với số lượng nhãn vừa phải. - Gộp các nhãn dễ nhầm nếu chúng không cần được xử lý khác nhau ở bước sau. - Chỉ tách nhãn khi có đủ dữ liệu và có lý do nghiệp vụ rõ ràng. Một câu hỏi hữu ích: “Nếu mô hình dự đoán ra hai nhãn này, hệ thống sẽ xử lý khác nhau không?” Nếu câu trả lời là không, có thể chưa cần tách chúng. 2. Viết định nghĩa nhãn như viết tài liệu sản phẩm Tên nhãn ngắn gọn là chưa đủ. Ví dụ nhãn “khiếu nại” nghe có vẻ rõ, nhưng người dùng nói “dịch vụ hôm nay quá tệ” có phải khiếu nại không? Hay chỉ khi họ yêu cầu hoàn tiền mới tính là khiếu nại? Mỗi nhãn nên có: - Mô tả ngắn: nhãn này dùng cho trường hợp nào. - Tiêu chí bao gồm: ví dụ cụ thể nên gán vào nhãn. - Tiêu chí loại trừ: ví dụ dễ nhầm nhưng không thuộc nhãn. - Mức ưu tiên khi một mẫu có thể thuộc nhiều nhãn. Ví dụ: Nhãn: Yêu cầu hoàn tiền - Bao gồm: người dùng yêu cầu trả lại tiền, hủy giao dịch và nhận tiền về. - Không bao gồm: người dùng chỉ phàn nàn chất lượng nhưng chưa yêu cầu hoàn tiền. - Nếu vừa phàn nàn vừa yêu cầu hoàn tiền, ưu tiên nhãn Yêu cầu hoàn tiền. Tài liệu nhãn càng rõ, dữ liệu càng nhất quán. Đây là khoản đầu tư nhỏ nhưng tiết kiệm rất nhiều thời gian sửa lỗi về sau. 3. Gán nhãn thử trước khi gán nhãn hàng loạt Không nên đưa ngay toàn bộ dữ liệu cho đội gán nhãn. Hãy lấy một tập nhỏ, ví dụ vài trăm mẫu, để gán thử. Sau đó kiểm tra: - Có nhãn nào bị dùng quá ít không? - Có nhãn nào thường xuyên bị nhầm với nhãn khác không? - Có nhiều mẫu không thể quyết định nhãn không? - Người gán nhãn có hiểu cùng một quy tắc theo cùng một cách không? Giai đoạn gán thử giúp phát hiện vấn đề trong thiết kế nhãn trước khi chi phí tăng cao. Nếu phải sửa định nghĩa nhãn sau khi đã gán hàng chục nghìn mẫu, bạn có thể phải làm lại một phần đáng kể dữ liệu. 4. Đo mức độ đồng thuận giữa người gán nhãn Nếu có nhiều người cùng gán nhãn, nên kiểm tra một phần dữ liệu trùng nhau để xem họ có đồng ý với nhau không. Không nhất thiết phải dùng chỉ số phức tạp ngay từ đầu; chỉ cần xem tỷ lệ trùng nhãn và phân tích các trường hợp bất đồng cũng đã rất hữu ích. Các mẫu bị bất đồng thường rơi vào ba nhóm: - Dữ liệu thật sự mơ hồ. - Hướng dẫn nhãn chưa rõ. - Một hoặc nhiều người gán nhãn hiểu sai quy tắc. Thay vì chỉ “lấy theo đa số”, hãy xem các mẫu bất đồng là tín hiệu để cải thiện tài liệu nhãn. 5. Chừa chỗ cho nhãn “khác” nhưng đừng lạm dụng Nhãn “khác” hoặc “không xác định” rất cần thiết trong dữ liệu thực tế. Không phải mẫu nào cũng vừa vặn với bộ nhãn hiện có. Tuy nhiên, nếu nhãn “khác” chiếm tỷ lệ quá lớn, đó có thể là dấu hiệu bộ nhãn chưa phản ánh đúng bài toán. Nên định kỳ xem lại các mẫu thuộc nhóm “khác” để phát hiện cụm vấn đề mới. Có thể sau một thời gian, bạn cần tách thêm nhãn mới hoặc điều chỉnh lại phạm vi nhãn cũ. 6. Nghĩ trước về cách mô hình sẽ được sử dụng Thiết kế nhãn không chỉ là việc kỹ thuật. Nó gắn trực tiếp với sản phẩm. Một mô hình phân loại email có thể cần nhãn rất khác nhau tùy mục đích: - Nếu chỉ để ưu tiên xử lý, nhãn có thể là: khẩn cấp, bình thường, thấp. - Nếu để chuyển đến đúng phòng ban, nhãn có thể là: kỹ thuật, thanh toán, pháp lý, kinh doanh. - Nếu để tự động trả lời, nhãn cần bám vào ý định cụ thể của người dùng. Vì vậy, trước khi gán nhãn, hãy xác định rõ: dự đoán của mô hình sẽ kích hoạt hành động gì? Câu trả lời này quyết định bộ nhãn nên được thiết kế như thế nào. 7. Lưu lại phiên bản của bộ nhãn Khi dự án phát triển, định nghĩa nhãn thường thay đổi. Một nhãn có thể được tách ra, gộp lại hoặc đổi tiêu chí. Nếu không lưu phiên bản, bạn sẽ khó biết dữ liệu cũ được gán theo quy tắc nào. Tối thiểu nên lưu: - Danh sách nhãn tại từng thời điểm. - Mô tả và ví dụ cho mỗi nhãn. - Ngày thay đổi. - Lý do thay đổi. - Cách xử lý dữ liệu đã gán trước đó. Việc này đặc biệt quan trọng khi so sánh các lần huấn luyện mô hình. Nếu dữ liệu hoặc định nghĩa nhãn đã thay đổi, kết quả tăng giảm có thể không đến từ mô hình. Kết luận Một mô hình tốt không thể bù hoàn toàn cho dữ liệu nhãn kém. Thiết kế nhãn rõ ràng giúp mô hình học đúng mục tiêu, giúp đánh giá đáng tin hơn và giúp nhóm phát triển tránh nhiều vòng sửa sai tốn kém. Nếu bạn đang bắt đầu một dự án AI có gán nhãn dữ liệu, hãy làm theo thứ tự đơn giản: xác định mục đích sử dụng, tạo bộ nhãn nhỏ, viết định nghĩa rõ, gán thử, phân tích bất đồng, rồi mới mở rộng. Đây là cách làm không hào nhoáng, nhưng rất hiệu quả trong thực tế.