Voice AI: đừng nhầm mô hình với vô lăng

Voice AI: đừng nhầm mô hình với vô lăng

Dialog-RSN-1 đáng chú ý không vì thêm một model thoại mới, mà vì nó đặt lại câu hỏi: team builder nên giữ quyền điều khiển ở lớp nào?

Bạn sẽ chọn gì nếu chiều nay sếp hỏi: “Mình làm tổng đài AI luôn được chưa?”

A. Lấy một speech-to-speech model thật mới, cho nó nghe và nói trực tiếp.

B. Ghép ASR → LLM → tool calling → TTS như cách nhiều team vẫn làm.

C. Chờ thêm vài tháng vì demo nào cũng mượt cho tới khi gặp khách gọi trong thang máy, vừa nói vừa nhai bánh mì.

Mình kể bạn nghe chuyện của một team giả định tên là NamiCare, một startup bảo hiểm ở Việt Nam. Team này không thiếu model. Họ có ASR để chuyển giọng nói thành chữ, LLM để suy luận, tool calling để gọi API kiểm tra hợp đồng, TTS để đọc câu trả lời. Vấn đề là khách hàng thật không nói như dataset sạch. Người gọi ngập ngừng, đổi ý giữa câu, chen ngang, hoặc im lặng ba giây chỉ vì đang tìm số hồ sơ.

Và đây là lúc release Dialog-RSN-1 của PolyAI đáng để mổ xẻ. Không phải vì nó “mới nhất”, mà vì nó chỉ ra một điểm nhiều team voice AI đang lái xe hơi lệch làn: đừng chỉ hỏi model có nghe-nói được không; hãy hỏi quyền điều khiển cuộc hội thoại đang nằm ở đâu.

Sơ đồ minh họa cho bài Voice AI: đừng nhầm mô hình với vô lăng

Sơ đồ tóm tắt ý chính của bài viết.

Cú va chạm: transcript sạch làm mất tín hiệu bẩn nhưng quý

NamiCare ban đầu dùng kiến trúc quen thuộc: audio đi vào ASR, ASR xuất transcript, transcript được đưa cho LLM, LLM quyết định gọi tool hay trả lời, rồi TTS đọc lại.

Nghe hợp lý. Nhưng trong production, transcript giống như bản tường trình sau tai nạn: có chữ, nhưng mất rất nhiều ngữ cảnh.

Ví dụ cụ thể: khách nói “Ờ… tôi muốn hủy… à không, đổi ngày thanh toán.” ASR có thể xuất ra một câu khá gọn: “Tôi muốn hủy à không đổi ngày thanh toán.” LLM đọc chữ đó vẫn hiểu phần nào, nhưng nó không thấy độ ngập ngừng, khoảng dừng, sự chen ngang, hay tín hiệu cho biết người gọi đã nói xong chưa.

Với voice agent, turn-taking — quyết định khi nào người dùng nói xong và khi nào bot nên đáp — không phải chi tiết phụ. Nó là cái phanh. Phanh sớm thì bot cắt lời khách. Phanh muộn thì cuộc gọi kéo dài, khách tưởng hệ thống chết.

Dialog-RSN-1 chọn hướng khác: model nhận audio trực tiếp ở phía input, thay vì chỉ đọc transcript. Nó gộp các việc vốn tách rời gồm turn-taking, speech recognition, function calling và response generation vào một model hội thoại audio-native. Audio-native ở đây nghĩa là model suy luận trực tiếp từ tín hiệu âm thanh, không chỉ từ chữ đã được ASR làm sạch.

Điểm thú vị: output voice vẫn để TTS riêng xử lý. Tức là model nghe audio để hiểu, nhưng không tự ôm luôn phần giọng nói đầu ra.

Mổ xẻ thiết kế: nghe bằng audio, nói bằng TTS riêng

Nói thẳng ra thì, Dialog-RSN-1 không cố biến mọi thứ thành một khối speech-to-speech nguyên cục.

Thiết kế này đáng chú ý vì nó tách hai loại quyền kiểm soát:

Trong release, PolyAI nói turn-taking là token đầu tiên model xuất ra: EMPTY, ONGOING, hoặc COMPLETE. Đây là chi tiết nhỏ nhưng rất “production”. Thay vì để một endpointing rule thủ công đo im lặng bao nhiêu mili-giây thì cắt, model tự phân loại trạng thái lượt nói.

Nếu bạn từng build tổng đài, bạn biết mấy rule kiểu “im lặng 700ms thì coi là xong” thường chạy ổn trong demo, rồi lệch ngay khi gặp vùng miền, tiếng ồn, hoặc khách đang đọc số tài khoản chậm rãi.

Một chi tiết khác cũng đáng giữ: Dialog-RSN-1 chạy kiểu request-based LLM — model được gọi khi cần, không phải stream luôn luôn bật và giữ GPU suốt cuộc gọi. Với team vận hành, đây không chỉ là chuyện kỹ thuật. Nó ảnh hưởng thẳng tới chi phí, capacity planning, và khả năng phục vụ nhiều cuộc gọi đồng thời.

PolyAI công bố response dưới 300ms, tăng 11% relative containment ở một nhóm nhà hàng, và giảm 37% latency ở một công ty bảo hiểm. Mình không xem các con số này như vé thông hành để mọi team nhảy vào ngay. Nhưng nó cho thấy một hướng thiết kế đáng kiểm tra: đưa audio vào lớp reasoning, nhưng giữ TTS như lớp điều khiển riêng.

Ba ngã rẽ cho builder voice AI

Nếu bạn đang là tech lead của NamiCare, câu hỏi không phải “Dialog-RSN-1 có ngon không?”. Câu hỏi thực tế hơn là: team mình nên đánh đổi ở đâu?

| Hướng | Bạn được gì | Bạn trả giá gì | Phù hợp khi |
|---|---|---|---|
| Cascaded stack: ASR → LLM → TTS | Dễ thay từng phần, debug rõ, nhiều vendor | Mất tín hiệu audio trước khi LLM suy luận; turn-taking hay phải vá bằng rule | Team cần kiểm soát, đa ngôn ngữ, hoặc tự tích hợp sâu |
| Speech-to-speech full-duplex | Trải nghiệm tự nhiên, audio không bị cắt thành chữ quá sớm | Giọng đầu ra và luồng xử lý có thể khó kiểm soát; always-on có thể tốn GPU | Demo tương tác mở, trợ lý realtime, ít ràng buộc brand voice |
| Audio-aware input + TTS riêng | Giữ tín hiệu audio cho reasoning, vẫn kiểm soát voice | Phụ thuộc platform nếu không có API/open weights; khó tự host | Tổng đài enterprise, luồng gọi có nghiệp vụ rõ, call volume lớn |

Dialog-RSN-1 hiện chỉ qua platform của PolyAI, chưa có open weights hay public API, và English only ở launch. Đây là điểm mù lớn nếu bạn build cho thị trường Việt Nam hoặc cần quyền kiểm soát hạ tầng.

Nói cách khác, nó là tín hiệu kiến trúc mạnh, không phải lựa chọn mặc định cho mọi team.

Đừng bỏ qua những mảnh ghép “kém hào nhoáng” hơn

Cùng thời điểm, vài release khác cũng cho thấy voice stack đang tách thành nhiều lớp chuyên dụng.

Qwen-Audio-3.0-TTS của Alibaba tập trung vào text-to-speech — biến chữ thành giọng nói — với hai tier: Flash cho realtime và Plus cho chất lượng cao. Nó hỗ trợ nhiều ngôn ngữ hơn, có style control và voice cloning qua hosted API. Nếu bài toán của bạn là giọng đọc thương hiệu, đây có thể là lớp đáng quan tâm hơn một dialog model trọn gói.

Interfaze lại đi vào ASR với diffusion-gemma-asr-small, một model speech recognition mã nguồn mở dùng diffusion decoder. Diffusion decoder ở đây hiểu ngắn là cách sinh transcript bằng nhiều bước tinh chỉnh song song, thay vì token sau phụ thuộc token trước như autoregressive. Model này chưa nhất thiết thắng các lựa chọn ASR phổ biến, nhưng nó mở một hướng thử nghiệm thú vị cho team cần tự kiểm soát speech-to-text.

Cursor Router nghe có vẻ xa voice AI, nhưng lại cho một bài học sát sườn: routing theo request. Request-level classifier là bộ phân loại từng yêu cầu trước khi chọn model xử lý. Với voice stack, ý tưởng tương tự có thể là: cuộc gọi xác thực đơn giản dùng pipeline rẻ; cuộc gọi khiếu nại phức tạp mới chuyển sang model mạnh hơn; đoạn cần đọc thông tin nhạy cảm dùng TTS được kiểm soát chặt hơn.

Cả model local 1B fine-tuned trên traces cũng nhắc thêm một điều: nhỏ, rẻ, chạy local không đồng nghĩa đủ năng lực cho hội thoại thoại production. Nó có thể hữu ích cho sandbox, formatting, hoặc tác vụ phụ; nhưng đừng bắt nó xử lý cảm xúc khách hàng, tool call nghiệp vụ, và latency realtime cùng lúc nếu chưa đo kỹ.

Framework: giữ vô lăng ở lớp nào?

Sau khi bóc lớp, mình sẽ không hỏi “model nào tốt nhất?”. Mình sẽ dùng bốn câu hỏi này trước khi chọn kiến trúc:

1. Lớp nào cần thấy audio gốc?
Nếu nghiệp vụ phụ thuộc vào ngắt lời, ngập ngừng, tiếng ồn, cảm xúc, hoặc xác định người dùng đã nói xong chưa, transcript-only có thể là thiếu.

2. Lớp nào cần kiểm soát tuyệt đối?
Với ngân hàng, bảo hiểm, y tế, khách sạn, giọng đọc không chỉ là UX. Nó liên quan tới phát âm tên riêng, câu pháp lý, tốc độ đọc điều khoản, và khả năng audit.

3. Lớp nào được phép phụ thuộc vendor?
Nếu model chỉ có qua platform, bạn cần hỏi về data retention, region, SLA, observability, export log, và cách rollback. Không có public API hay open weights nghĩa là bạn không thể tự dựng đường dự phòng như với một số stack mở.

4. Lớp nào cần routing thay vì nâng cấp toàn bộ?
Không phải cuộc gọi nào cũng cần model mạnh nhất. Một hệ thống trưởng thành biết chuyển làn: request đơn giản đi đường rẻ, request rủi ro cao đi đường chắc, request cần giọng đẹp đi qua TTS chất lượng hơn.

Áp dụng cho NamiCare, quyết định hợp lý có thể không phải “mua Dialog-RSN-1 ngay”. Có thể là:

Chỉ cần làm vậy trong một buổi chiều, team đã bớt lái theo tiếng còi marketing và bắt đầu nhìn vào điểm nghẽn thật.

Điều nên giữ, điều nên bỏ qua

Điều đáng giữ từ Dialog-RSN-1 không phải tên model. Mà là thesis kiến trúc: voice AI production cần model hiểu âm thanh ở đúng chỗ, không nhất thiết cần một model ôm hết mọi chỗ.

Điều nên bỏ qua là phản xạ “cái mới hơn thì thay toàn bộ stack”. Với builder, thay stack thoại giống đổi làn trên cao tốc: nhìn gương chưa đủ, phải biết điểm mù nằm ở latency, cost, compliance, language coverage và quyền debug.

Sau bài này, nếu bạn nghĩ khác một điều, mình mong đó là: voice AI không còn là cuộc đua chọn model nói tự nhiên nhất; nó là bài toán phân quyền điều khiển giữa audio understanding, reasoning, tools và voice output.

Chốt gọn: tổng đài AI hay không nằm ở cái miệng nói trơn tru, mà ở chỗ nó biết khi nào nên nghe thêm, khi nào nên đáp, và khi nào nên đạp phanh.

---
Bụi Wire — nghiện đọc release notes lúc 2 giờ sáng

Nguồn tham khảo