Mở đầu — vì sao bài này quan trọng
Nếu bạn từng phải ngồi đọc từng email khách hàng để quyết định "cái này gửi cho phòng kinh doanh hay phòng kỹ thuật", từng đọc hàng trăm review trên Shopee để biết khách đang khen hay chê, hay từng phân loại đơn hàng theo mức độ khẩn cấp — thì bạn đã làm công việc mà máy tính gọi là classification (phân loại). Đây là bài toán "đầu vào là một đoạn text, đầu ra là một trong vài nhãn định sẵn".
Điều thú vị là classification chính là ứng dụng doanh nghiệp dễ triển khai nhất, ROI cao nhất của prompt engineering. Lý do rất đơn giản: đầu ra bị giới hạn trong một tập nhãn nhỏ (positive/negative/neutral, P0/P1/P2, spam/không spam...), nên bạn dễ đo độ chính xác, dễ tự động hóa, và dễ nối vào hệ thống có sẵn. Trong khi một bài viết marketing "hay hay dở" khó chấm điểm khách quan, thì "email này thuộc nhóm sales hay support" là câu hỏi có đáp án đúng — bạn kiểm chứng được.
Ở các bài trước, bạn đã học zero-shot, few-shot, và structured output như những kỹ thuật riêng lẻ. Bài này sẽ hợp nhất tất cả lại thành một khuôn mẫu chuyên dụng cho classification — thứ mà bạn có thể copy về, thay đổi vài dòng, và dùng ngay cho công ty mình. Chúng ta không bàn lý thuyết chung chung nữa, mà đi thẳng vào các pattern (khuôn mẫu lặp lại) đã được kiểm chứng trong thực tế.
Khái niệm cốt lõi
Classification prompt là gì
Về bản chất, bạn đang biến LLM thành một hàm phân loại: đưa vào một đoạn văn bản, nhận về đúng một nhãn (hoặc một tập nhãn). Khác với việc "hỏi AI cho ý kiến", classification đòi hỏi đầu ra cực kỳ có kỷ luật: chỉ được chọn trong danh sách nhãn cho trước, không giải thích lan man, không tự sáng tạo nhãn mới.
Một classification prompt tốt luôn có 5 thành phần:
- Vai trò và nhiệm vụ: nói rõ AI là bộ phân loại cho việc gì.
- Danh sách nhãn (taxonomy) kèm định nghĩa từng nhãn.
- Quy tắc ranh giới: khi mập mờ thì xử lý ra sao, có nhãn "khác/không xác định" không.
- Định dạng đầu ra: thường là JSON hoặc chỉ một từ nhãn.
- Văn bản cần phân loại.
Ba pattern nền tảng bạn phải nắm
Pattern 1 — Single-label (chọn một nhãn duy nhất). Đây là dạng phổ biến nhất: một email chỉ thuộc một phòng ban, một review chỉ có một sắc thái chủ đạo. Yêu cầu quan trọng nhất là các nhãn phải loại trừ lẫn nhau (mutually exclusive) — nếu hai nhãn chồng lấn, AI sẽ phân vân và kết quả thiếu ổn định.
Pattern 2 — Multi-label (chọn nhiều nhãn). Một ticket support có thể vừa là "lỗi thanh toán" vừa là "khẩn cấp". Ở đây đầu ra là một mảng nhãn. Bạn cần nói rõ với AI rằng được phép chọn nhiều nhãn, và nêu rõ khi nào thì gán nhiều nhãn.
Pattern 3 — Hierarchical / phân cấp. Trước tiên phân loại nhóm lớn (ví dụ: "kỹ thuật"), rồi mới phân loại nhóm con ("lỗi đăng nhập", "lỗi hiển thị"). Với taxonomy lớn (hàng chục nhãn), phân cấp giúp AI chính xác hơn nhiều so với đưa cả rừng nhãn cùng lúc.
Nguyên tắc thiết kế taxonomy
Đây là phần quyết định 80% chất lượng, mà nhiều người bỏ qua. Một taxonomy tốt phải: rõ ràng (mỗi nhãn có định nghĩa một câu), loại trừ lẫn nhau (không chồng lấn), bao phủ đủ (có nhãn "Khác" để hứng trường hợp lạ), và đủ nhỏ (5–8 nhãn ở mỗi tầng là lý tưởng; nếu quá 15 nhãn hãy chuyển sang phân cấp).
Đừng chỉ đặt tên nhãn, hãy định nghĩa nhãn. "Billing" mơ hồ; "Billing — mọi câu hỏi về hóa đơn, thanh toán, hoàn tiền, nâng/hạ gói" thì rõ ràng. Định nghĩa tốt còn quý hơn cả ví dụ.
Zero-shot hay few-shot cho classification
Với taxonomy đơn giản và nhãn dễ hiểu (positive/negative), zero-shot thường đã đủ tốt. Nhưng khi ranh giới tinh tế — ví dụ phân biệt "phàn nàn nhưng vẫn muốn mua" với "phàn nàn đòi hủy" — hãy dùng few-shot, đưa 2–3 ví dụ cho mỗi nhãn khó, đặc biệt là các ví dụ ở ranh giới. Ví dụ ở vùng biên dạy AI nhiều hơn ví dụ điển hình.
Tình huống thực tế
Ví dụ 1 — Tiki phân luồng email khách hàng (email triage)
Một đội chăm sóc khách hàng giả định của một sàn thương mại điện tử lớn tại Việt Nam nhận khoảng 4.000 email/ngày. Trước đây, 3 nhân viên trực tổng đài phải đọc lướt và bấm chuyển từng email vào một trong bốn hộp thư: Sales, Support kỹ thuật, Billing (thanh toán/hoàn tiền), và Khác. Mỗi email mất trung bình 25 giây để phân loại thủ công.
Họ triển khai prompt phân loại như sau:
Bạn là hệ thống phân luồng email cho bộ phận CSKH.
Phân loại email vào ĐÚNG MỘT nhóm:
- SALES: hỏi mua hàng, tư vấn sản phẩm, hỏi giá, khuyến mãi, đặt số lượng lớn.
- SUPPORT: lỗi kỹ thuật, không đăng nhập được, app lỗi, giao hàng trễ, đổi/trả hàng.
- BILLING: hóa đơn, thanh toán thất bại, đòi hoàn tiền, sai số tiền, xuất VAT.
- OTHER: không thuộc ba nhóm trên hoặc không rõ ý định.
Quy tắc: nếu email đề cập nhiều vấn đề, chọn nhóm theo VẤN ĐỀ CHÍNH mà khách muốn giải quyết.
Chỉ trả về JSON: {"label": "...", "confidence": "high|medium|low"}Email: """{{noi_dung_email}}"""
Kết quả sau 2 tuần: độ chính xác đạt ~93% so với nhãn do con người kiểm tra lại. Điểm hay nằm ở trường confidence: những email AI gán low (khoảng 6%) được tự động đẩy cho người xử lý, còn lại chạy tự động. Thời gian phân loại trung bình giảm từ 25 giây xuống gần như tức thời, và 3 nhân viên trực chuyển sang xử lý các ca low confidence thay vì đọc toàn bộ.
Bài học: trường confidence biến một hệ thống "tự động hoàn toàn" (rủi ro cao) thành human-in-the-loop thông minh — máy làm phần chắc chắn, người làm phần khó. Đây là pattern nên áp dụng cho gần như mọi classification chạy production.
Ví dụ 2 — Chuỗi F&B phân tích sentiment review
Một chuỗi trà sữa giả định có 40 chi nhánh ở TP.HCM nhận hàng nghìn đánh giá mỗi tháng trên ShopeeFood và GrabFood. Ban đầu họ dùng prompt đơn giản "review này tích cực hay tiêu cực", nhưng gặp vấn đề: review kiểu "Trà ngon mà giao lâu quá, shipper thái độ" bị AI gán lung tung — lúc positive, lúc negative.
Vấn đề là họ trộn hai chiều vào một nhãn. Họ chuyển sang multi-label theo khía cạnh (aspect-based):
Phân loại review theo TỪNG khía cạnh. Với mỗi khía cạnh, gán: positive / negative / neutral / not_mentioned.
Khía cạnh: đồ_uống, giá, giao_hàng, thái_độ_nhân_viên.
Trả về JSON đúng cấu trúc:
{"do_uong":"...","gia":"...","giao_hang":"...","thai_do":"..."}Review: """Trà ngon mà giao lâu quá, shipper thái độ"""
Đầu ra: {"do_uong":"positive","gia":"neutral"→"not_mentioned","giao_hang":"negative","thai_do":"negative"}. Giờ đây quản lý chuỗi nhìn dashboard thấy rõ: đồ uống được khen, nhưng giao hàng và thái độ shipper là điểm đen — vấn đề nằm ở khâu logistics chứ không phải chất lượng sản phẩm. Họ đàm phán lại với đối tác giao vận thay vì sửa công thức pha chế.
Bài học: khi một đối tượng có nhiều mặt, đừng ép về một nhãn sentiment duy nhất. Aspect-based classification (phân loại theo khía cạnh) cho insight hành động được, thay vì một con số "80% tích cực" chung chung mà không biết sửa gì.
Ví dụ 3 — Startup SaaS phân loại độ ưu tiên ticket (P0–P3)
Một startup SaaS B2B ở Singapore phục vụ khách doanh nghiệp trong khu vực Đông Nam Á cần tự động gán độ ưu tiên cho ticket support để đảm bảo SLA. Họ định nghĩa taxonomy theo tác động kinh doanh, không theo cảm xúc của khách:
Gán mức ưu tiên cho ticket dựa trên TÁC ĐỘNG, không dựa vào giọng điệu khách.
- P0: hệ thống sập, nhiều khách hàng không dùng được, mất/rò rỉ dữ liệu, thanh toán toàn hệ thống lỗi.
- P1: một chức năng chính hỏng với khách trả phí, chưa có cách khắc phục tạm.
- P2: lỗi nhỏ, có cách khắc phục tạm (workaround), ảnh hưởng hạn chế.
- P3: câu hỏi, đề xuất tính năng, vấn đề thẩm mỹ.
Nếu ticket vừa có yếu tố P0 vừa có yếu tố nhẹ, LẤY MỨC CAO NHẤT.
Ví dụ:
- "Cả team 50 người không login được từ sáng nay" -> P0
- "Nút export báo cáo bị lệch chữ" -> P3
- "Tính năng gửi hóa đơn không chạy nhưng em copy tay tạm được" -> P2
Trả về: {"priority":"P0|P1|P2|P3","ly_do":"<một câu>"}
Ticket: """{{noi_dung}}"""
Điểm mấu chốt: họ dặn AI bỏ qua giọng điệu. Vì khách hàng hay viết "GẤP GẤP!!!" cho cả những lỗi nhỏ, còn lỗi P0 thật đôi khi được báo rất bình tĩnh. Vài ví dụ few-shot ở ranh giới (đặc biệt ca P2 "có workaround") giúp AI tách bạch mức độ khẩn cấp thực sự khỏi cảm xúc. Trường ly_do giúp trưởng nhóm audit lại nhanh khi nghi ngờ.
Bài học: định nghĩa nhãn phải theo tiêu chí khách quan, đo được (số người ảnh hưởng, có workaround hay không), không theo yếu tố dễ đánh lừa như giọng điệu. Và luôn có quy tắc "khi trùng lấy mức cao nhất" cho thang bậc ưu tiên.
Hướng dẫn từng bước
Đây là quy trình xây một classifier bằng prompt, áp dụng cho mọi bài toán:
Bước 1 — Định nghĩa taxonomy trước khi viết prompt. Ngồi liệt kê các nhãn, viết định nghĩa một câu cho mỗi nhãn, và luôn thêm nhãn "Khác/OTHER". Kiểm tra hai điều: các nhãn có loại trừ lẫn nhau không, và có bao phủ hết trường hợp không.
Bước 2 — Chọn pattern. Một nhãn hay nhiều nhãn? Nếu taxonomy trên 15 nhãn, chia phân cấp. Nếu đối tượng có nhiều khía cạnh, dùng aspect-based.
Bước 3 — Viết prompt theo khung 5 thành phần. Vai trò → danh sách nhãn có định nghĩa → quy tắc ranh giới → định dạng đầu ra → chỗ chèn văn bản. Bắt buộc yêu cầu đầu ra JSON và "chỉ chọn trong danh sách, không tạo nhãn mới".
Bước 4 — Thêm few-shot cho nhãn khó. Nếu zero-shot chưa ổn, chọn 2–3 ví dụ ở ranh giới cho mỗi nhãn hay bị nhầm. Nhớ cân bằng: đừng chỉ đưa toàn ví dụ của một nhãn.
Bước 5 — Thêm confidence và lý do. Yêu cầu AI trả confidence và một câu ly_do. Định tuyến các ca low cho con người.
Bước 6 — Kiểm thử trên tập vàng. Chuẩn bị 30–50 mẫu đã có nhãn chuẩn do người gán, chạy prompt, so sánh. Xem AI sai ở đâu — thường là do định nghĩa nhãn chưa rõ, không phải do "AI kém". Sửa định nghĩa, thêm ví dụ ranh giới, chạy lại.
Bước 7 — Đưa vào vận hành với vòng lặp. Ghi lại các ca người sửa nhãn, định kỳ đưa những ca đó thành ví dụ few-shot mới. Classifier của bạn sẽ tốt dần theo thời gian.
Lỗi thường gặp & mẹo
Nhãn chồng lấn. Đây là lỗi số một. Nếu "Complaint" và "Billing Issue" cùng match một email đòi hoàn tiền, AI sẽ dao động. Cách sửa: định nghĩa lại cho loại trừ, hoặc chuyển sang multi-label có chủ đích.
Để AI giải thích dài dòng. Nếu không ép định dạng, AI hay trả "Email này có vẻ thuộc nhóm Support vì...". Rất khó parse tự động. Luôn ép JSON và nói rõ "không thêm văn bản ngoài JSON".
AI tự chế nhãn mới. Khi văn bản mập mờ, AI có thể trả nhãn ngoài danh sách. Chống bằng câu lệnh cứng: "Chỉ được chọn trong danh sách sau; nếu không chắc, chọn OTHER" — và luôn có sẵn nhãn OTHER.
Quên nhãn "Khác". Không có nhãn hứng, AI sẽ nhét đại vào nhãn gần nhất, làm bẩn dữ liệu. Luôn có OTHER/UNKNOWN.
Thang ưu tiên không có quy tắc trùng. Ticket vừa P0 vừa P3 mà không có quy tắc "lấy mức cao nhất" thì kết quả bất nhất.
Mẹo — dùng nhãn viết HOA, không dấu. Nhãn như SALES, P0 ổn định và dễ so khớp trong code hơn "Bán hàng". Giữ nhãn ngắn, cố định.
Mẹo — với nhiều nhãn phức tạp, đánh số nhãn. Cho AI chọn theo số (1, 2, 3...) đôi khi ổn định hơn chọn theo chữ, vì giảm khả năng AI "diễn giải lại" tên nhãn.
Mẹo — nhiệt độ thấp. Classification cần tính ổn định, hãy đặt temperature thấp (0–0.2) để cùng một đầu vào luôn cho cùng một nhãn.
Bài tập thực hành
- Thiết kế taxonomy. Chọn một luồng công việc ở công ty bạn (email đến, comment fanpage, đơn hàng, CV ứng viên...). Viết 4–6 nhãn, mỗi nhãn một câu định nghĩa, và một nhãn OTHER. Tự kiểm tra: có nhãn nào chồng lấn không?
- Viết prompt single-label. Dùng khung 5 thành phần viết một classification prompt hoàn chỉnh cho taxonomy ở bài 1, ép đầu ra JSON kèm
confidence.
- Nâng cấp lên multi-label / aspect-based. Lấy 10 review sản phẩm thật (Shopee/Tiki tùy bạn), viết prompt phân loại theo ít nhất 3 khía cạnh. Chạy thử và xem có khía cạnh nào AI hay nhầm.
- Tạo tập vàng và đo. Tự gán nhãn cho 20 mẫu, chạy prompt, đếm số đúng. Với mỗi ca sai, viết một câu: sai vì định nghĩa nhãn hay vì thiếu ví dụ? Sửa prompt và chạy lại, ghi lại độ chính xác trước/sau.
- Thêm ví dụ ranh giới. Tìm 2 mẫu ở vùng biên hay bị nhầm, thêm vào prompt dưới dạng few-shot, và kiểm chứng độ chính xác có cải thiện không.
Tóm tắt
Classification là ứng dụng doanh nghiệp dễ triển khai và đo lường nhất của prompt engineering, vì đầu ra bị giới hạn trong một tập nhãn định sẵn. Chất lượng của một classifier phụ thuộc trước hết vào taxonomy — các nhãn phải rõ ràng, loại trừ lẫn nhau, bao phủ đủ (có OTHER), và đủ nhỏ. Ba pattern nền tảng là single-label, multi-label và hierarchical; với đối tượng nhiều mặt hãy dùng aspect-based để có insight hành động được.
Một prompt phân loại tốt luôn theo khung 5 thành phần, ép đầu ra JSON, cấm tạo nhãn mới, và kèm confidence để định tuyến ca khó cho con người. Ba tình huống — email triage của sàn TMĐT, sentiment theo khía cạnh của chuỗi F&B, và ưu tiên ticket P0–P3 của startup SaaS — cho thấy cùng một bộ nguyên tắc: định nghĩa nhãn theo tiêu chí khách quan, dùng ví dụ ranh giới để dạy AI vùng biên, và luôn giữ con người trong vòng lặp ở những ca không chắc chắn. Nắm được các pattern này, bạn có thể tự động hóa một trong những công việc tốn thời gian nhất của mọi phòng ban.