Trong bài viết này
Từ được đánh dấu có giải thích. Di chuột hoặc chạm để xem, hay mở từ điển AI.
“Giao chậm nhưng bạn hỗ trợ rất nhiệt tình; ứng dụng cứ báo lỗi lúc thanh toán.” Phản hồi giả định này vừa có vấn đề giao hàng, lỗi kỹ thuật, vừa có lời khen. Ép nó vào một nhãn cảm xúc duy nhất sẽ làm mất thông tin mà đội vận hành cần xử lý.
Trước khi chọn mô hình, hãy quyết định nhãn dùng để thống kê, phân công hay kích hoạt một hành động. Mục đích ấy quyết định cách chia bài toán.
Tách chủ đề khỏi cảm xúc
Một thiết kế đầu ra minh họa là:
{
"topics": ["delivery", "payment_error"],
"support_sentiment": "positive",
"needs_review": false
}topics là danh sách vì một phản hồi có thể chứa nhiều vấn đề. Cảm xúc với nhân viên hỗ trợ được giữ riêng, không dùng để phủ nhận lỗi thanh toán. Nếu sản phẩm chỉ cho phép một nhãn chính, phải viết quy tắc ưu tiên và chấp nhận phần thông tin bị mất.
Mỗi nhãn cần mô tả, ví dụ nhận vào và ví dụ loại ra. “Thanh toán” quá rộng nếu đội nghiệp vụ cần phân biệt không mở được màn hình, giao dịch bị từ chối và không biết dùng phương thức nào. Tuy nhiên, chia quá chi tiết khi người gán nhãn chưa phân biệt được cũng làm dữ liệu thiếu ổn định.
Tạo hướng dẫn cho trường hợp mơ hồ
“Không mua nữa” có thể thể hiện bất mãn nhưng chưa cho biết nguyên nhân. Đừng tự gán giao hàng chỉ vì người dùng trước đó thường phàn nàn giao hàng. Nhãn unknown hoặc trạng thái cần xem lại là một phần hợp lệ của hợp đồng.
Cho hai người độc lập gán một mẫu phản hồi đã được phép sử dụng, rồi xem bất đồng. Nếu họ khác nhau vì thiếu quy tắc, sửa hướng dẫn trước khi sửa prompt. Mô hình khó học một ranh giới mà chính nhóm vận hành chưa thống nhất.
Với tiếng Việt, thêm viết tắt, không dấu, câu châm biếm và phản hồi có nhiều ý. Giữ nguyên nội dung cần thiết cho việc hiểu nghĩa nhưng loại bỏ thông tin nhận dạng không liên quan khỏi tập thử.
Đọc chất lượng theo từng nhãn
Tài liệu đánh giá của scikit-learn trình bày precision, recall, F-score và các cách tổng hợp cho bài toán phân loại. Precision hỏi các trường hợp được gán nhãn có bao nhiêu trường hợp đúng; recall hỏi trong các trường hợp thực sự thuộc nhãn, hệ thống tìm được bao nhiêu.
Giả sử trong một tập giả định, lỗi thanh toán hiếm hơn lời khen. Chỉ báo cáo tỷ lệ đúng toàn bộ có thể che việc bỏ sót gần hết lỗi thanh toán. Xem từng nhãn và ma trận nhầm lẫn để biết vấn đề bị chuyển sang đâu.
Với nhiều nhãn, cần quy định thế nào là đúng một phần. Bắt đúng giao hàng nhưng bỏ lỗi thanh toán không nên được tính ngang với bắt đủ cả hai. Ngưỡng chấp nhận phụ thuộc hậu quả vận hành, không chỉ mong muốn tăng một điểm tổng hợp.
Chạy các mô hình trên cùng bộ thử, đọc cả điểm tổng lẫn kiểu lỗi, rồi cân nhắc tốc độ và chi phí. Một chênh lệch nhỏ chưa chứng minh mô hình nào luôn tốt hơn.
↔ Vuốt ngang để xem toàn bộ sơ đồ.
01 / Cùng bộ thử
Dùng cùng các trường hợp và quy tắc chấm đã xác định trước cho cả hai mô hình.
02 / Đọc điểm số
Trong ví dụ giả định, A đúng 18/20, B đúng 17/20. Chênh lệch một trường hợp chưa đủ kết luận chung.
03 / Xem kiểu lỗi
Mở các trường hợp thất bại: sai tên người và vượt độ dài có mức ảnh hưởng khác nhau.
04 / Đánh giá nhiều chiều
Đo thêm tốc độ, chi phí và độ ổn định trên dữ liệu phù hợp với công việc thực tế.
A đúng 18/20 và B đúng 17/20 là số liệu giả định để giải thích cách đọc kết quả, không phải benchmark của mô hình có thật.
Tách phân loại khỏi quyết định xử lý
Nhãn “có yêu cầu hoàn tiền” không đồng nghĩa “đủ điều kiện hoàn tiền”. Phân loại chỉ nhận diện nội dung; bước nghiệp vụ cần dữ liệu đơn hàng, quy chế và quyền thực hiện riêng.
Có thể dùng mô hình để gợi ý hàng đợi cho nhân viên trước khi tự động phân công. Giai đoạn này cho phép quan sát các lỗi gây chuyển nhầm mà không làm người dùng mất đường hỗ trợ. Khi tự động hóa, giữ đường đổi nhãn và phản hồi để cải thiện bộ kiểm tra.
Lỗi thường gặp là thêm nhãn mới sau mỗi phản hồi khó. Bộ nhãn sẽ phình to nhưng không còn nhất quán. Chỉ thêm khi nhãn phục vụ một quyết định khác biệt và có đủ hướng dẫn để người khác dùng đúng.
Bài tập: phản hồi có hai vấn đề
Soạn bộ phản hồi giả định gồm lời khen, lỗi thanh toán, giao hàng chậm, câu mơ hồ và phản hồi chứa nhiều chủ đề. Viết đáp án cùng lý do cho từng nhãn trước khi chạy mô hình.
Tiêu chí đạt: phản hồi đầu bài giữ được cả hai vấn đề, câu thiếu nguyên nhân không bị đoán, và báo cáo cho thấy lỗi theo từng nhãn. Cuối cùng chọn một lỗi chuyển nhầm có hậu quả lớn, rồi bổ sung ví dụ kiểm tra đúng ranh giới ấy thay vì chỉ tăng số lượng dữ liệu dễ.