Đội bạn vừa demo voicebot cho sếp. Giọng đọc mượt, trả lời đúng, ai cũng gật gù. Hai tuần sau lên production, gắn vào tổng đài thật, khách gọi vào hỏi "đơn của em tới đâu rồi" — và im lặng 1,8 giây trước khi bot mở miệng. Khách hỏi lại "alo?". Bot bắt đầu trả lời câu cũ, đè lên tiếng "alo". Hai bên nói chồng nhau. Khách cúp máy, bấm 0 gặp người thật.
Vấn đề không nằm ở giọng nói. Giọng TTS tiếng Việt năm 2026 đã qua uncanny valley từ lâu. Vấn đề nằm ở khoảng lặng. Trong hội thoại người với người, gap giữa hai lượt nói trung bình chỉ khoảng 200ms — não người cực nhạy với sự chậm trễ này. Voicebot chậm 1,5 giây thì dù giọng hay đến đâu, khách vẫn biết ngay là máy, và tệ hơn: cảm giác như nói chuyện với một người lơ đãng.
Ngưỡng cảm nhận 2026 và ngân sách 800ms
Con số chuẩn hiện nay, tính từ lúc khách nói xong đến lúc bot phát ra âm thanh đầu tiên:
- Dưới 800ms: mượt, gần như hội thoại tự nhiên.
- 800–1.200ms: chấp nhận được, hơi "nghĩ lâu" nhưng không gãy.
- Trên 1.500ms: lộ rõ là máy. Khách bắt đầu "alo?", nói lại, hoặc cúp.
800ms nghe thì nhiều, nhưng chia ra từng chặng của pipeline truyền thống là hết sạch:
| Chặng | Latency điển hình | Ghi chú |
|---|---|---|
| VAD + endpointing (phát hiện khách nói xong) | 200–500ms | Chờ im lặng bao lâu thì coi là "xong câu"? |
| STT (chốt transcript cuối) | 100–300ms | Streaming giúp nhưng final result vẫn phải chờ |
| LLM (time-to-first-token) | 200–800ms | Cộng thêm nếu có tool-calling |
| TTS (time-to-first-audio) | 80–300ms | Streaming TTS đã khá nhanh |
| Mạng viễn thông + telephony stack | 100–300ms | SIP trunk, codec, jitter buffer — thứ demo WebRTC không có |
Cộng dồn kịch bản "mỗi thứ hơi chậm một chút" là bạn đã ở 1,2–2 giây. Đây là lý do pipeline STT→LLM→TTS cổ điển thường rơi vào vùng 600–1.500ms, và phần lớn triển khai thực tế nằm ở nửa trên của khoảng đó.
Chỗ ăn budget nhiều nhất không phải LLM như nhiều người nghĩ, mà là endpointing: bot phải quyết định "khách nói xong chưa" bằng cách chờ im lặng. Chờ 700ms cho chắc thì mất 700ms trước khi làm bất cứ thứ gì. Chờ 300ms thì bot cướp lời khi khách chỉ đang ngập ngừng đọc mã đơn hàng.
Pipeline cũ vs speech-to-speech native
Thế hệ platform thứ 3 (2025–2026) giải bài toán này theo hai hướng.
Hướng 1: tối ưu pipeline đến giới hạn. Vẫn là STT→LLM→TTS nhưng mọi thứ streaming và chồng lấn: STT trả partial transcript liên tục, LLM bắt đầu suy nghĩ trên partial trước khi khách nói xong, TTS phát audio ngay từ token đầu, cộng turn-taking model riêng thay cho VAD thuần im lặng. Retell AI công bố sub-600ms theo hướng này; Telnyx đẩy xuống sub-200ms round-trip nhờ sở hữu luôn hạ tầng viễn thông — inference đặt cạnh media server, khỏi đi vòng qua internet.
Hướng 2: speech-to-speech native. Model nhận audio, trả audio, không có bước text trung gian. Time-to-first-audio khoảng ~100ms — nhanh đến mức vấn đề latency gần như biến mất. Nhưng đánh đổi không nhỏ:
| Pipeline streaming | Speech-to-speech | |
|---|---|---|
| Latency | 400–800ms (tối ưu tốt) | ~100ms TTFA |
| Kiểm soát nội dung | Cao — thấy text, filter được, log được | Thấp — audio ra thẳng, khó guardrail |
| Tool-calling (tra đơn, CRM) | Trưởng thành, đáng tin | Đang tiến bộ nhưng vẫn kém ổn định hơn |
| Đổi giọng/ngôn ngữ | Ghép TTS tuỳ ý | Phụ thuộc model |
| Chi phí | Kiểm soát được từng khâu | Thường đắt hơn, ít lựa chọn |
Với use case CSKH cần tra dữ liệu đơn hàng, xác thực khách, ghi ticket — tức là tool-calling dày đặc — pipeline streaming tối ưu tốt vẫn là lựa chọn thực dụng hơn ở thời điểm này. Speech-to-speech hợp với hội thoại mở, ít nghiệp vụ.
Turn-taking và barge-in: khó hơn cả latency
Latency có số đo. Turn-taking thì không, và nó mới là thứ giết trải nghiệm.
Barge-in — khách ngắt lời khi bot đang nói — bắt buộc phải có. Bot đọc 30 giây chính sách đổi trả trong khi khách đã biết câu trả lời từ giây thứ 5 mà không ngắt được, đó là tra tấn. Barge-in đúng nghĩa là: dừng TTS trong ~100–200ms, xả sạch audio buffer đã đẩy vào jitter buffer của nhà mạng (phần này hay bị quên — bot "đã dừng" nhưng khách vẫn nghe thêm 1 giây audio tồn), và LLM phải hiểu ngữ cảnh "mình bị ngắt ở đâu".
Phân biệt ngắt lời với tiếng ồn còn khó hơn. Khách gọi từ đường phố Việt Nam: tiếng xe máy, còi, người bán hàng rong, TV nhà hàng xóm. VAD ngây thơ sẽ coi tiếng còi xe là khách nói, dừng bot giữa câu. Ngược lại, khách nói "ừm... khoan" nhỏ giọng thì phải nhận ra. Đây là lý do thế hệ platform mới không dùng VAD thuần energy nữa mà chạy turn-taking model riêng — một model nhỏ chuyên đoán "khách sắp nói xong chưa" dựa trên cả ngữ điệu và nội dung, thay vì chỉ đếm milliseconds im lặng.
Và im lặng có chủ đích: khách đang lục ví tìm mã đơn hàng. Im 4 giây. Bot cắt ngang "anh/chị còn đó không ạ?" ở giây thứ 2 là hỏng. Cần logic: nếu bot vừa yêu cầu thông tin cần tra cứu, ngưỡng chờ phải giãn ra.
Tiếng Việt: chỗ nào nên đầu hàng và dùng DTMF
STT tiếng Việt 2026 đã tốt với hội thoại thường, nhưng vẫn yếu đúng ở những chỗ nghiệp vụ cần nhất:
- Số điện thoại: "không chín ba năm..." — "năm" là số 5 hay từ đệm? Khách đọc nhanh, nuốt số, đọc theo cặp.
- Tên riêng: Dũng/Dụng/Dung, Ngân/Ngần — sai một dấu là sai người, sai luôn kết quả tra CRM.
- Mã đơn hàng: "SPX-VN-0847..." trộn chữ Latin, số, gạch ngang — ác mộng của mọi STT.
Cách thực dụng: đừng cố thắng bằng AI ở những điểm này. Fallback DTMF — "anh/chị vui lòng bấm số điện thoại trên bàn phím" — cho input dạng số. Chính xác 100%, khách quen thao tác này từ thời IVR, và nhanh hơn cả việc bot xác nhận lại "có phải không chín ba năm...". Với mã đơn hàng, tra theo số điện thoại đã xác thực rồi liệt kê đơn cho khách chọn, thay vì bắt khách đọc mã. Voicebot tốt là voicebot biết chỗ nào không nên dùng giọng nói.
Checklist đo thật, không đo demo
Con số latency trong demo WebRTC từ laptop văn phòng là con số vô nghĩa. Đo thật nghĩa là:
□ Gọi qua SIM thật (Viettel/Vina/Mobi), qua SIP trunk production,
không phải WebRTC nội bộ
□ Đo p95, không phải p50 — khách nhớ cuộc gọi tệ nhất,
không nhớ cuộc trung bình
□ Đo end-to-end: mốc bắt đầu là khách NGỪNG nói,
mốc kết thúc là audio ĐẦU TIÊN tới tai khách
□ Đo lúc cao điểm: LLM provider nghẽn giờ hành chính,
TTFT có thể x2-x3 so với đêm
□ Test barge-in: ngắt lời bot ở giây 2, đo bao lâu bot im hẳn
□ Test tiếng ồn: gọi từ ngoài đường, bật quạt, mở TV
□ Test số + tên riêng tiếng Việt: 50 số điện thoại,
50 tên có dấu dễ nhầm — đếm tỷ lệ đúng
□ Ghi log từng chặng (endpointing / STT / LLM / TTS / network)
để biết chặng nào ăn budget khi p95 vỡ
Nếu p95 end-to-end trên đường viễn thông thật vượt 1.200ms, đừng launch. Sửa kiến trúc trước, không phải sửa prompt.
Ngành này đang lặp lại đúng bài học của web performance mười lăm năm trước: người dùng không khen trang web nhanh, họ chỉ rời bỏ trang web chậm. Voicebot cũng vậy — khách không bao giờ khen bot trả lời nhanh, họ chỉ cúp máy khi nó chậm. Giọng nói là thứ bạn demo cho sếp; độ trễ là thứ khách hàng của bạn thực sự nghe thấy.
