Tại sao sản phẩm giọng nói khác hẳn sản phẩm màn hình
Khi làm sản phẩm có màn hình (app, web), người dùng THẤY được lựa chọn: nút bấm, menu, danh sách. Với sản phẩm giọng nói, người dùng KHÔNG thấy gì cả — họ chỉ nói và chờ nghe. Điều này thay đổi mọi thứ:
- Không có "affordance" thị giác: người dùng phải đoán họ nói được gì. PM phải thiết kế câu gợi ý (prompt) và onboarding bằng lời.
- Lỗi rất đắt: một câu trả lời sai bằng giọng nói khó sửa hơn một dòng text hiển thị sai. Người dùng phải nghe lại, nói lại.
- Thời gian là tất cả: người ta chịu chờ 3 giây khi bấm nút, nhưng khó chịu khi im lặng 1,5 giây trong hội thoại nói.
Pipeline giọng nói cơ bản
Mọi trợ lý giọng nói đều đi qua chuỗi này:
Micro → Wake word → ASR → NLU → Dialog/Logic → TTS → Loa
- Wake word: từ đánh thức ("Hey Vina", "Ok trợ lý"). Chạy liên tục trên thiết bị.
- ASR (Automatic Speech Recognition): chuyển giọng nói thành văn bản. Đây là mắt xích quyết định chất lượng tiếng Việt.
- NLU (Natural Language Understanding): hiểu ý định (intent) và trích xuất thực thể (entity) từ văn bản.
- Dialog/Logic: quyết định phản hồi, gọi API, quản lý ngữ cảnh hội thoại.
- TTS (Text-to-Speech): đọc câu trả lời thành giọng nói.
Voice AI PM làm gì khác PM thường?
PM giọng nói phải quản lý những đánh đổi rất kỹ thuật mà PM thường ít chạm tới:
- Ngân sách độ trễ (latency budget): phân bổ mili-giây cho từng mắt xích.
- Chất lượng nhận dạng: đọc và cải thiện chỉ số WER (Word Error Rate) cho tiếng Việt.
- False wake: cân bằng giữa "gọi là dậy" và "đừng tự dậy".
- Quyền riêng tư: thiết bị luôn nghe — đây là rủi ro pháp lý và niềm tin lớn nhất.
Ví dụ cụ thể
Một startup Việt làm loa thông minh cho người cao tuổi. Người dùng nói: "Gọi cho con gái tôi." Nếu ASR nghe nhầm tên, hệ thống gọi nhầm người — hậu quả nghiêm trọng hơn nhiều so với một app hiển thị sai danh bạ. PM ở đây phải quyết định: khi độ tin cậy (confidence) thấp, hệ thống nên XÁC NHẬN lại ("Bạn muốn gọi cho Lan, đúng không?") thay vì làm ngay.
Khung tư duy: 4 câu hỏi khi bắt đầu một tính năng giọng nói
- Người dùng đang ở đâu? (lái xe, nấu ăn, phòng riêng) — quyết định mức tiếng ồn và nhu cầu rảnh tay.
- Chi phí của một lỗi là bao nhiêu? — quyết định ngưỡng xác nhận.
- Có cần always-listening không? — nếu không, dùng nút bấm-để-nói (push-to-talk) an toàn hơn về quyền riêng tư.
- Ngân sách độ trễ tối đa là bao nhiêu? — quyết định chọn mô hình on-device hay cloud.
Checklist khởi động dự án Voice
- [ ] Đã xác định ngữ cảnh sử dụng (rảnh tay, ồn ào, riêng tư?)
- [ ] Đã ước lượng chi phí của lỗi nhận dạng
- [ ] Đã chọn wake word hay push-to-talk
- [ ] Đã đặt mục tiêu độ trễ cảm nhận ("nghe xong nói xong bao lâu?")
- [ ] Đã có kế hoạch thu thập dữ liệu tiếng Việt thực tế
Sai lầm thường gặp
- Bê nguyên UX màn hình sang giọng nói: liệt kê 8 lựa chọn bằng lời — người dùng quên ngay sau lựa chọn thứ ba.
- Bỏ qua tính tích lũy của lỗi: chỉ tối ưu ASR mà quên NLU, dẫn tới trải nghiệm tổng thể vẫn tệ.
- Coi always-listening là mặc định: chưa cân nhắc rủi ro quyền riêng tư đã bật micro liên tục.