Bài 3 — Ngân sách độ trễ: từ ASR đến TTS

Độ trễ là trải nghiệm

Trong hội thoại nói, con người kỳ vọng phản hồi gần như tức thì. Nghiên cứu hội thoại cho thấy khoảng lặng tự nhiên giữa hai lượt nói chỉ khoảng 200–500 mili-giây. Nếu trợ lý giọng nói im lặng quá 1 giây sau khi người dùng nói xong, cảm giác "máy bị đơ" xuất hiện. Vượt 2 giây, người dùng bắt đầu nói lại — làm hỏng cả lượt.

Latency budget (ngân sách độ trễ) là tổng thời gian bạn được phép tiêu, chia cho từng mắt xích. PM giọng nói phải làm chủ con số này như PM tài chính làm chủ ngân sách tiền.

Phân rã ngân sách một lượt hội thoại

Giả sử mục tiêu: người dùng nói xong → nghe tiếng đầu tiên của câu trả lời trong 1000 ms. Một cách phân bổ mẫu:

Tổng ≈ 1000 ms. Chú ý cột cuối: với TTS, chỉ số quan trọng là time-to-first-audio (bao lâu để nghe âm thanh ĐẦU TIÊN), không phải bao lâu để đọc hết câu.

Ba kỹ thuật giấu độ trễ

• Streaming ASR: nhận dạng từng phần khi người dùng còn đang nói, không chờ nói xong mới xử lý.
• Streaming TTS: bắt đầu phát tiếng ngay khi có vài từ đầu tiên của câu trả lời, không chờ tổng hợp cả câu.
• Filler / phản hồi sớm: phát "Để tôi kiểm tra nhé..." trong khi backend còn chạy — lấp khoảng lặng bằng tín hiệu sống.

On-device hay Cloud?

Đây là quyết định kiến trúc mà PM phải cùng kỹ sư cân nhắc:

• On-device: độ trễ mạng bằng 0, tốt cho quyền riêng tư, nhưng mô hình nhỏ hơn → chất lượng ASR/TTS thấp hơn.
• Cloud: mô hình mạnh, chất lượng cao, nhưng thêm 100–400 ms mạng và phụ thuộc kết nối.
• Hybrid: wake word + lệnh đơn giản on-device; câu phức tạp đẩy lên cloud.

Ví dụ: loa thông minh dùng ở nhà (wifi ổn) có thể ưu tiên cloud. Ứng dụng lái xe (mạng chập chờn) nên xử lý lệnh cốt lõi on-device.

Ví dụ cụ thể

Một app trợ lý đặt xe đo được p95 latency là 2,3 giây và người dùng phàn nàn "chậm". Phân rã cho thấy backend tra cứu giá mất 1,4 giây. Giải pháp của PM: (1) thêm filler "Đang tìm xe gần bạn..." ngay sau khi hiểu ý định, (2) stream TTS. Độ trễ THẬT không đổi nhiều nhưng độ trễ CẢM NHẬN giảm mạnh, khiếu nại giảm hẳn. Bài học: quản lý cảm nhận cũng quan trọng như quản lý mili-giây.

Khung tư duy: đo bằng phân vị, không phải trung bình

Đừng báo cáo latency trung bình. Dùng p50, p95, p99. Trung bình 800 ms nghe đẹp, nhưng nếu p95 là 2,5 giây thì 5% lượt hội thoại đang gãy — và người dùng nhớ trải nghiệm tệ nhất.

Checklist ngân sách độ trễ

• [ ] Đã đặt mục tiêu time-to-first-audio (không chỉ tổng thời gian)
• [ ] Đã phân bổ ngân sách cho từng mắt xích
• [ ] Đã bật streaming ASR và streaming TTS
• [ ] Có filler cho các thao tác backend chậm
• [ ] Đo bằng p95/p99 trên mạng thật, không phải wifi phòng thí nghiệm
• [ ] Có phương án degrade khi mạng chậm

Sai lầm thường gặp

• Chỉ đo latency trung bình: che giấu đuôi dài p99 gây khiếu nại.
• Tối ưu tổng thời lượng TTS thay vì time-to-first-audio: người dùng chỉ cần nghe tiếng bắt đầu sớm.
• Không dùng filler: để khoảng lặng chết trong lúc chờ backend.
• Test toàn trên wifi văn phòng: bỏ qua độ trễ mạng di động thực tế.

Bài 4 bàn về wake word và bài toán false wake — nơi cân bằng giữa nhạy và phiền.