Bài 2 — Intent, entity và thiết kế lớp Hiểu (Understanding)

Intent & entity: nền móng của việc "hiểu" người dùng

Mọi sản phẩm hội thoại đều bắt đầu từ một câu hỏi: người dùng đang muốn gì? Trả lời câu hỏi này là nhiệm vụ của lớp Understanding, và hai khái niệm cốt lõi là intent và entity.

Intent là gì

Intent (ý định) là mục tiêu đằng sau câu nói của người dùng. Ví dụ, tất cả các câu sau đều thuộc intent check_order_status:

• "Đơn của tôi tới đâu rồi?"
• "Kiểm tra giúp đơn hàng số 12345"
• "Bao giờ hàng tới vậy?"

Người dùng nói theo trăm cách khác nhau, nhưng ý định thì như nhau. Việc của PM là định nghĩa tập intent — danh sách những ý định mà bot cần nhận ra.

Entity là gì

Entity (thực thể) là những mẩu thông tin cụ thể cần trích ra để hoàn thành tác vụ. Trong "Kiểm tra đơn 12345 đặt ngày hôm qua":

• Entity order_id = 12345
• Entity date = hôm qua

Intent nói muốn làm gì, entity nói làm với dữ liệu nào. Một tác vụ thường chỉ chạy được khi đã đủ entity — gọi là slot filling (điền đủ ô thông tin).

Khung thiết kế tập intent

Đừng liệt kê intent theo cảm tính. Dùng khung 4 bước:

• Thu thập câu thật: lấy log chat/tổng đài, câu hỏi thật của khách — không tự bịa.
• Gom cụm: nhóm các câu cùng ý định lại. Nếu hai nhóm hay bị nhầm với nhau, cân nhắc gộp.
• Đặt tên rõ ràng: report_lost_card tốt hơn card_issue (quá rộng).
• Định nghĩa ranh giới: viết ra 3 câu THUỘC và 3 câu KHÔNG thuộc mỗi intent để training và QA nhất quán.

Nguyên tắc "độ phủ" và "độ tách bạch"

Tập intent tốt cần hai tính chất:

• Coverage (độ phủ): phủ được phần lớn nhu cầu thật. Nếu 30% câu hỏi rơi vào "không hiểu", tập intent của bạn có lỗ hổng.
• Separability (độ tách bạch): các intent không chồng lấn. Nếu change_address và update_profile cùng chứa "đổi địa chỉ", mô hình sẽ đoán lung tung.

Mẹo: dùng confusion matrix để xem intent nào hay bị nhận nhầm thành intent nào, rồi tách hoặc gộp cho phù hợp.

Confidence và fallback

Mô hình NLU trả về một confidence score (độ tự tin) cho mỗi intent. PM phải quyết định các ngưỡng:

• Trên ngưỡng cao (VD > 0.8): xử lý luôn.
• Vùng giữa (VD 0.5–0.8): hỏi lại để xác nhận — "Bạn muốn kiểm tra trạng thái đơn hàng, đúng không?"
• Dưới ngưỡng thấp: kích hoạt fallback — xin lỗi và gợi ý các việc bot làm được, hoặc chuyển người thật.

Ngưỡng này là đòn bẩy sản phẩm quan trọng: đặt cao thì an toàn nhưng hay hỏi lại (phiền); đặt thấp thì mượt nhưng dễ hiểu sai.

Ví dụ cụ thể: bot ngân hàng

Người dùng: "Thẻ tôi bị nuốt ở ATM tối qua, giờ làm sao?"

• Intent: card_stuck_atm (không phải report_lost_card — khác quy trình!).
• Entity: channel = ATM, time = tối qua.
• Confidence 0.62 → hỏi lại xác nhận trước khi hướng dẫn.

Nếu bạn gộp nhầm card_stuck_atm vào report_lost_card, bot sẽ khóa thẻ oan — một lỗi sản phẩm nghiêm trọng đến từ thiết kế intent sai.

Checklist chất lượng tập intent

• [ ] Mỗi intent có ≥ 15–20 câu mẫu đa dạng cách nói?
• [ ] Đã kiểm tra confusion matrix, không cặp nào nhầm > 15%?
• [ ] Đã định nghĩa entity bắt buộc cho mỗi intent cần slot filling?
• [ ] Đã có ngưỡng confidence và luồng hỏi-lại rõ ràng?
• [ ] Đã có intent fallback và cách xử lý "không hiểu"?

Sai lầm thường gặp

• Tạo quá nhiều intent nhỏ lẻ (100+) khiến mô hình rối và khó bảo trì. Bắt đầu gọn, mở rộng theo dữ liệu.
• Tự bịa câu mẫu thay vì dùng câu thật của khách — mô hình học lệch so với thực tế.
• Bỏ quên entity bắt buộc, khiến bot cứ trả lời nhưng thiếu thông tin để thực thi.
• Đặt một ngưỡng confidence cứng cho mọi intent — intent rủi ro cao (khóa thẻ) cần ngưỡng khắt khe hơn intent vô hại (chào hỏi).

Hiểu đúng là bước đầu tiên. Bài sau ta bàn tới việc điều phối cuộc hội thoại — quyết định bước tiếp theo sau khi đã hiểu.