Tự động phân loại email và ticket bằng AI: route đúng người trong vài giây

Mỗi sáng hộp thư hỗ trợ có vài chục đến vài trăm email/ticket mới, và ai đó phải đọc từng cái để quyết định: lỗi hay câu hỏi, gấp hay không, giao cho ai. Đây là việc lặp lại, tốn thời gian và chậm phản hồi khách — đúng kiểu việc mà LLM làm tốt. Bài này trình bày luồng AI triage hoàn chỉnh: lọc, phân loại theo schema, route, và đo lường để tin được hệ thống.

Luồng xử lý

1. Trigger: email mới (Gmail/Outlook) hoặc ticket mới (Jira Service Management, Zendesk, Freshdesk) qua webhook hoặc polling.
2. Rule lọc trước: spam, auto-reply, newsletter, thông báo hệ thống → bỏ qua bằng điều kiện đơn giản (không tốn token).
3. LLM phân loại: đọc tiêu đề + nội dung, trả JSON theo schema cố định.
4. Code route: gắn label, giao assignee, đặt SLA theo ưu tiên — hoàn toàn bằng logic xác định.
5. Độ tin cậy thấp: dưới ngưỡng → đưa vào hàng đợi “cần người xem”.
6. Ghi log: lưu đầu vào, đầu ra và quyết định cuối để đánh giá và cải thiện prompt.

Schema gợi ý

{
  "category": "bug | billing | how_to | feature_request | other",
  "priority": "P1 | P2 | P3",
  "product_area": "login | payment | report | api | other",
  "language": "vi | en",
  "summary": "1 câu tóm tắt vấn đề",
  "customer_sentiment": "negative | neutral | positive",
  "confidence": 0.0
}

Dùng structured outputs (JSON schema) để model luôn trả đúng định dạng. Bước code phía sau vẫn nên validate: giá trị ngoài danh sách cho phép → coi như độ tin cậy thấp.

Prompt phân loại

Bạn phân loại ticket hỗ trợ của phần mềm quản lý bán hàng.
Định nghĩa ưu tiên:
- P1: hệ thống không dùng được, mất dữ liệu, sai tiền, nhiều người bị ảnh hưởng.
- P2: một chức năng lỗi nhưng có cách làm tạm.
- P3: câu hỏi cách dùng, góp ý, yêu cầu tính năng.
Nếu không chắc, đặt confidence thấp thay vì đoán.

<vi_du>
... 10–20 ticket thật đã được gán nhãn ...
</vi_du>

Ticket cần phân loại:
<ticket>{{subject}}\n{{body}}</ticket>

Định nghĩa rõ từng mức ưu tiên và đưa ví dụ thật (few-shot) thường cải thiện độ chính xác nhiều hơn việc đổi sang model lớn hơn.

Đo lường trước khi tin

Với P1, bỏ sót tệ hơn nhiều so với báo nhầm. Có thể thêm rule bổ sung bằng từ khoá (“không đăng nhập được”, “mất dữ liệu”, “bị trừ tiền 2 lần”) để nâng ưu tiên bất kể AI phân loại thế nào.

Triển khai theo giai đoạn

1. Shadow mode (1–2 tuần): AI phân loại nhưng chỉ ghi log, người vẫn làm như cũ. So sánh để đo độ chính xác.
2. Gợi ý: AI gắn label “đề xuất”, người xác nhận bằng một click.
3. Tự động có ngưỡng: confidence cao → tự route; thấp → hàng đợi người xem.
4. Mở rộng: AI soạn sẵn câu trả lời nháp cho nhóm how-to, nhân viên chỉnh rồi gửi.

Cạm bẫy thường gặp

• Danh mục quá nhiều: 30 nhãn chi tiết sẽ nhầm lẫn; bắt đầu với 5–7 nhóm.
• Dữ liệu cá nhân: che bớt số thẻ, số điện thoại trước khi gửi lên model nếu chính sách yêu cầu.
• Prompt injection: nội dung email là dữ liệu không tin cậy — AI chỉ được phân loại, không được thực hiện hành động theo “hướng dẫn” trong email.

Áp dụng thế nào?

• Dev: Làm bằng n8n hoặc vài chục dòng code; giữ phần AI là một hàm thuần “text → JSON” để test dễ.
• Tech Lead: Xây bộ 100–200 ticket gán nhãn làm eval set; chạy lại mỗi khi đổi prompt hoặc model.
• PM / Support Lead: Thống nhất định nghĩa P1/P2/P3 bằng văn bản trước — AI không thể nhất quán hơn chính định nghĩa của team.