Voicebot tổng đài AI: kiến trúc và lưu ý khi triển khai
admin
Ứng dụng AI cho chăm sóc khách hàng đang đặt ra một bài toán rất thực tế: làm sao để tổng đài hiểu người gọi thay vì bắt họ bấm phím. Chúng tôi đã đi qua vài dự án tương tự, và điều dễ thấy nhất là người gọi gần như hết kiên nhẫn với những menu dài. Bài viết này chia sẻ góc nhìn kỹ thuật phía sau một voicebot, để bạn nắm hệ thống vận hành ra sao trước khi quyết định triển khai.
Vì sao voicebot đang trở thành lớp giao tiếp mới trong tổng đài
Trước đây, tổng đài tự động chủ yếu dựa vào IVR (Interactive Voice Response). Đó là kiểu “nhấn 1 để gặp kinh doanh, nhấn 2 để nghe thông tin tài khoản”. Hệ thống này cứng nhắc đến mức khách thường phải nghe qua ba, bốn tầng menu mới tới đúng chỗ cần, và không ít người bỏ máy giữa chừng.
Voicebot AI đổi cách tiếp cận đó. Người gọi có thể nói tự nhiên, chẳng hạn “tôi muốn hỏi về đơn hàng đặt từ tuần trước”, và hệ thống hiểu ý định để trả lời hoặc chuyển đúng bộ phận. Khách không phải học cách điều khiển máy, và chính điều đó làm trải nghiệm thay đổi rõ rệt.
Điều này không có nghĩa voicebot thay thế hoàn toàn nhân viên tổng đài. Theo kinh nghiệm của đội ngũ, voicebot xử lý tốt nhất những câu hỏi có đáp án rõ ràng: tra cứu trạng thái đơn, giờ làm việc, đổi lịch hẹn. Khi gặp khiếu nại phức tạp hoặc khách đòi gặp người thật, việc chuyển tiếp (handover) mượt mà mới quyết định trải nghiệm. Nếu chuyển tiếp vụng về, khách phải kể lại từ đầu và bực bội ngay.
Nguyên tắc này áp dụng cho mọi giao diện hội thoại. Khi học lập trình Android bằng Kotlin, bạn sẽ thấy ứng dụng cần phản hồi đúng hành vi người dùng ra sao. Voicebot cũng vậy: phản hồi đúng ngữ cảnh mới tạo cảm giác đáng tin.
Kiến trúc kỹ thuật cơ bản của một voicebot tổng đài AI
Một voicebot thường gồm nhiều lớp nối tiếp nhau. Lớp đầu tiên là telephony: hệ thống kết nối mạng điện thoại qua SIP trunk, PSTN hoặc VoIP, rồi stream âm thanh vào pipeline xử lý. Nếu lớp này chập chờn, mọi thứ phía sau đều hỏng theo. Vì vậy chúng tôi thường kiểm tra độ trễ và chất lượng đường truyền ngay từ đầu.
Tiếp theo là ASR (Automatic Speech Recognition), chuyển giọng nói thành văn bản. Chất lượng ASR quyết định phần lớn độ chính xác của toàn hệ thống. Với tiếng Việt, cần thử nghiệm kỹ với giọng miền Bắc, miền Trung, miền Nam và các giọng địa phương, cũng như điều kiện âm thanh kém như tiếng xe cộ hay sóng yếu. Một mô hình đạt điểm cao trên dữ liệu sạch có thể vấp rất nhiều khi đưa ra thực tế.
Lớp NLU (Natural Language Understanding) xác định ý định (intent) từ văn bản. Hai câu “tôi muốn hủy đơn hàng” và “cho tôi hủy đơn đi” về bản chất là cùng một intent, dù cách nói khác nhau. Để NLU làm tốt việc này, dữ liệu huấn luyện phải phủ đủ các cách diễn đạt của người dùng thật, không chỉ những câu kịch bản đẹp đẽ.
Dialog management là lớp điều phối cuộc trò chuyện. Nó theo dõi ngữ cảnh: khách đang nói về đơn hàng nào, đã cung cấp mã nào, còn thiếu thông tin gì. Đây cũng là nơi đặt logic quyết định khi nào chuyển sang nhân viên. Thường chúng tôi thiết lập vài điều kiện rõ ràng, ví dụ sau hai lần bot không hiểu, hoặc khi khách nói những cụm như “gặp người thật”.
Cuối cùng là TTS (Text-to-Speech), biến câu trả lời thành giọng nói. Giọng đọc nên tự nhiên, tốc độ vừa phải và ngắt nghỉ đúng chỗ, nhất là khi đọc số điện thoại, mã đơn hay ngày tháng.
| Lớp kiến trúc | Chức năng và điểm cần chú ý |
|---|---|
| ASR | Nhận dạng giọng nói, cần test kỹ với tiếng Việt địa phương và âm thanh kém |
| NLU | Hiểu ý định, cần dữ liệu huấn luyện đa dạng cách nói |
| Dialog management | Giữ ngữ cảnh và quyết định logic chuyển tiếp sang nhân viên |
| TTS | Giọng đọc tự nhiên, ngắt nghỉ đúng khi đọc số và mã |
Dữ liệu, bảo mật và kiểm thử trước khi go-live
Cuộc gọi tổng đài thường được ghi âm, nên bảo mật phải được làm rõ ngay từ đầu. Cần trả lời được vài câu hỏi cụ thể: bản ghi lưu ở đâu, ai có quyền nghe, lưu trong bao lâu, và có dùng để cải thiện mô hình hay không. Khách hàng cũng nên được thông báo rõ ngay đầu cuộc gọi rằng cuộc trò chuyện đang được ghi và xử lý bởi AI.
Kiểm thử là bước dễ bị bỏ qua nhất. Chúng tôi thường chia thành ba nhóm kịch bản. Nhóm thứ nhất là happy path, tức các tình huống lý tưởng khi khách nói rõ ràng và đúng ý. Nhóm thứ hai là edge case: câu hỏi bất thường, khách nói lắp, có tiếng ồn nền, hoặc hỏi ngoài phạm vi. Nhóm thứ ba là failure recovery, gồm lúc ASR không hiểu, khi khách im lặng quá lâu, hoặc khi khách liên tục đòi gặp người. Chỉ khi cả ba nhóm đều có phản hồi hợp lý, hệ thống mới đáng đưa ra thực tế.
Nếu muốn tìm hiểu thêm về cách áp dụng ứng dụng AI cho chăm sóc khách hàng và xem các ví dụ triển khai, bạn có thể đọc thêm bài viết chuyên sâu của đơn vị bạn bè. Ngoài ra, bạn cũng có thể tham khảo thêm để có góc nhìn rộng hơn về các giải pháp số dành cho doanh nghiệp.
Vận hành và cải tiến liên tục sau khi triển khai
Voicebot không phải sản phẩm cài xong là xong. Sau khi go-live, cần theo dõi liên tục các chỉ số như tỷ lệ chuyển sang nhân viên, tỷ lệ khách phải nói lại và thời gian xử lý trung bình. Nếu tỷ lệ chuyển tiếp quá cao, rất có thể bot đang thất bại ở một nhóm tình huống cụ thể. Lật lại bản ghi các cuộc gọi bị chuyển tiếp thường cho thấy ngay chỗ cần sửa.
Mỗi khi xuất hiện câu hỏi mới, đội ngũ nên bổ sung vào dữ liệu huấn luyện và kịch bản hội thoại. Nhìn voicebot như một dịch vụ cần vận hành và cải tiến liên tục, thay vì một dự án có ngày kết thúc, là cách giữ hệ thống có giá trị lâu dài.
