Các lỗi phổ biến khi xây Sentiment Analysis

Các lỗi phổ biến khi xây sentiment analysis thường không nằm ở việc chọn Logistic Regression hay Transformer, mà xuất hiện sớm hơn ở dữ liệu, cách định nghĩa nhãn và quy trình đánh giá. Một mô hình có thể đạt metric khá tốt trên tập test nhưng vẫn xử lý sai hàng loạt câu thực tế nếu pipeline được thiết kế không đúng.

Đặc biệt với tiếng Việt, phủ định, tiếng lóng, câu nhiều ý và sự khác biệt giữa từng domain khiến bài toán phân tích cảm xúc khó hơn việc tìm các từ như “tốt” hoặc “tệ”. Dưới đây là những lỗi đáng chú ý nhất khi xây dựng hệ thống.

1. Thiết kế nhãn không rõ ràng

Một trong những lỗi đầu tiên là bắt đầu gán nhãn dữ liệu mà chưa xác định rõ positive, neutral và negative thực sự có nghĩa gì trong bài toán.

Ví dụ với câu:

“Camera đẹp nhưng pin khá yếu.”

Câu này nên là positive, negative hay neutral? Nếu người gán nhãn A chọn positive còn người B chọn negative thì mô hình sẽ học từ dữ liệu không nhất quán.

Trước khi annotation, nên xây label guideline với ví dụ cụ thể cho các trường hợp như sentiment hỗn hợp, câu không chứa quan điểm, câu mỉa mai và câu chỉ mô tả sự kiện.

Nếu ứng dụng cần biết cảm xúc theo từng thuộc tính, việc ép toàn bộ câu về một nhãn duy nhất có thể không phù hợp. Khi đó nên cân nhắc Aspect-Based Sentiment Analysis thay vì sentiment classification ở mức câu.

2. Làm sạch văn bản quá mức

Preprocessing không phải lúc nào càng nhiều càng tốt. Một pipeline xóa stopword máy móc có thể vô tình loại bỏ những token rất quan trọng với sentiment.

Câu gốc: “Sản phẩm không tốt.”
Sau khi xóa sai từ “không”: “Sản phẩm tốt.”

Chỉ một bước preprocessing sai đã đảo hoàn toàn polarity của câu. Những từ như không, chưa, chẳng, quá, rất thường mang thông tin quan trọng và không nên bị xóa chỉ vì chúng xuất hiện thường xuyên.

Tương tự, dấu câu hoặc cách viết kéo dài như “đẹpppp”, “tệ!!!” có thể chứa tín hiệu cảm xúc. Việc chuẩn hóa có thể hữu ích, nhưng nên dựa trên mục tiêu cụ thể thay vì áp dụng một danh sách rule chung cho mọi bài toán.

3. Chỉ học keyword thay vì ngữ cảnh

Một baseline dựa trên TF-IDF có thể học rằng “tốt” thường liên quan đến positive và “tệ” thường liên quan đến negative. Điều này hoạt động khá tốt với những câu đơn giản nhưng dễ thất bại khi cấu trúc câu thay đổi.

Câu	Sentiment	Điểm khó
“Máy rất tốt.”	Positive	Đơn giản.
“Máy không tốt.”	Negative	Phủ định.
“Không đến mức tệ.”	Phụ thuộc guideline	Phủ định của từ tiêu cực.
“Tốt quá, chờ có ba tiếng thôi.”	Có thể Negative	Mỉa mai.

Các mô hình Transformer có khả năng biểu diễn ngữ cảnh tốt hơn, nhưng chúng cũng không tự động giải quyết mọi trường hợp. Nếu dữ liệu huấn luyện gần như không có phủ định hoặc mỉa mai, mô hình vẫn khó học được các pattern này.

4. Bỏ qua mất cân bằng dữ liệu

Trong dữ liệu thực tế, số lượng mẫu giữa các lớp thường không cân bằng. Ví dụ, một sàn thương mại điện tử có thể chứa nhiều review positive hơn negative và neutral.

Giả sử tập test có 80% mẫu positive. Một mô hình luôn dự đoán positive đã có accuracy 80%, mặc dù hoàn toàn không phát hiện được khi khách hàng không hài lòng.

Vì vậy, không nên chỉ theo dõi accuracy. Cần kiểm tra precision, recall và F1-score theo từng lớp, đặc biệt với lớp quan trọng cho nghiệp vụ.

Ví dụ trong hệ thống giám sát phản hồi khách hàng, recall của lớp negative có thể quan trọng hơn accuracy tổng thể vì mục tiêu là hạn chế bỏ sót khiếu nại.

5. Train và test trên dữ liệu quá giống nhau

Một lỗi nguy hiểm khác là data leakage: thông tin từ tập test vô tình xuất hiện trong tập train. Điều này làm metric cao một cách giả tạo.

Ví dụ, dữ liệu có thể chứa nhiều review trùng lặp hoặc gần như giống nhau:

Train: “Shop giao hàng nhanh, sản phẩm rất tốt.”
Test: “Shop giao hàng nhanh. Sản phẩm rất tốt!”

Nếu hai mẫu này nằm ở hai tập khác nhau, mô hình có thể đang ghi nhớ pattern thay vì tổng quát hóa. Trước khi chia dữ liệu, nên kiểm tra duplicate và near-duplicate.

Với dữ liệu theo người dùng, cửa hàng hoặc thời gian, đôi khi nên chia train/test theo nhóm hoặc theo thời gian thay vì random split để mô phỏng điều kiện triển khai thực tế tốt hơn.

6. Huấn luyện trên một domain rồi áp dụng cho domain khác

Domain shift xảy ra khi dữ liệu khi triển khai khác đáng kể so với dữ liệu mà mô hình đã học. Đây là nguyên nhân phổ biến khiến một mô hình nhìn tốt trong notebook nhưng hoạt động kém ngoài thực tế.

Một classifier huấn luyện trên review sản phẩm có thể quen với các câu như “giao hàng nhanh”, “đóng gói đẹp”, “hàng bị lỗi”. Khi chuyển sang bình luận mạng xã hội, mô hình gặp slang, câu cực ngắn và cách diễn đạt hoàn toàn khác.

Insight từ bài trước: sentiment không phải một thuộc tính tách biệt khỏi domain. Một mô hình đạt kết quả tốt trên review thương mại điện tử chưa chắc phù hợp với mạng xã hội hoặc ticket chăm sóc khách hàng. Khi thay đổi nguồn dữ liệu, hãy coi đó là một bài toán đánh giá mới.

Giải pháp thực tế là tạo một tập test lấy trực tiếp từ domain triển khai. Nếu performance giảm nhiều, có thể cần bổ sung dữ liệu đúng domain và fine-tune lại mô hình.

7. Nhầm sentiment với mục tiêu nghiệp vụ

Một output negative không phải lúc nào cũng đồng nghĩa với tình huống nghiêm trọng. Đây là lỗi dễ gặp khi sentiment được dùng trong hệ thống tự động.

“Tôi không thích màu giao diện mới.”
Sentiment: Negative
Urgency: Thấp

“Tài khoản xuất hiện giao dịch tôi không thực hiện.”
Sentiment: Có thể Neutral hoặc Negative
Urgency: Cao

Nếu mục tiêu là ưu tiên ticket, nên xây thêm mô hình urgency classification hoặc issue classification thay vì dùng sentiment như tín hiệu duy nhất.

Tương tự, nếu doanh nghiệp muốn biết khách hàng phàn nàn về pin, giao hàng hay giá, sentiment classification toàn câu sẽ không đủ. Mục tiêu nghiệp vụ phải quyết định kiến trúc NLP, không phải ngược lại.

Một checklist ngắn trước khi triển khai

• Nhãn sentiment có guideline rõ ràng.
• Không xóa từ phủ định và tín hiệu cảm xúc quan trọng.
• Đã kiểm tra duplicate và data leakage.
• Theo dõi F1, precision và recall theo từng lớp.
• Có test set đúng domain triển khai.
• Đã kiểm tra riêng các câu phủ định, mixed sentiment và slang.
• Sentiment thực sự phù hợp với mục tiêu nghiệp vụ.

Một baseline đơn giản nhưng được đánh giá đúng thường có giá trị hơn một mô hình phức tạp với dữ liệu và test set thiếu kiểm soát. Khi cải thiện hệ thống, nên bắt đầu từ việc đọc các mẫu dự đoán sai và phân nhóm lỗi thay vì chỉ đổi kiến trúc mô hình.

Kết luận

Các lỗi phổ biến khi xây sentiment analysis chủ yếu đến từ việc định nghĩa bài toán chưa rõ, preprocessing quá mạnh, dữ liệu mất cân bằng, leakage và domain shift. Những vấn đề này có thể ảnh hưởng đến hệ thống nhiều hơn việc chuyển từ một classifier cơ bản sang một mô hình lớn hơn.

Một pipeline tốt cần được đánh giá bằng dữ liệu gần với môi trường triển khai, kết hợp metric phù hợp và phân tích lỗi định tính. Sentiment analysis chỉ thực sự hữu ích khi output của mô hình gắn đúng với quyết định mà hệ thống hoặc người dùng cần đưa ra.