Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 1 — Bức tranh tổng thể: Voice & Multimodal Agent thực sự là gì

Đã đọc 0/7 mục · còn khoảng 3 phút
Cách chúng tôi ghi nhận

Một mục được tính là đã đọc khi nó nằm giữa màn hình đủ lâu so với độ dài của nó (bảng và sơ đồ tính một nửa), bạn vẫn đang cuộn hoặc bấm phím, và bạn đã thấy tới cuối mục. Lướt nhanh hoặc để tab mở không được tính. Chúng tôi chỉ lưu thời gian đọc từng mục — không lưu gì khác.

Một voice agent không phải là "chatbot có thêm loa". Nó là một hệ thống thời gian thực, nơi mỗi mili-giây trễ đều làm hỏng trải nghiệm. Một multimodal agent còn phức tạp hơn: nó nhận cùng lúc nhiều loại tín hiệu (giọng nói, ảnh, âm thanh môi trường) và phải hợp nhất chúng để ra quyết định. Bài này dựng bản đồ tư duy để bạn không bị lạc khi bắt tay xây dựng.

Pipeline giọng nói kinh điển

Hầu hết voice agent chạy theo chuỗi bốn khối:

  • ASR (Automatic Speech Recognition) — chuyển tiếng nói thành text.
  • NLU/LLM — hiểu ý định, gọi tool, sinh câu trả lời.
  • TTS (Text-to-Speech) — chuyển text trả lời thành giọng nói.
  • Orchestration — điều phối, quản lý turn-taking (ai được nói), ngắt lời (barge-in), timeout.
Mic → [VAD] → ASR → LLM (+tools) → TTS → Speaker
              ↑___________ barge-in ___________↓

Một ví dụ cụ thể: khách gọi tổng đài đặt lịch spa. VAD phát hiện khách bắt đầu nói, ASR ghi "cho tôi đặt lịch 3 giờ chiều mai", LLM gọi tool check_availability(), TTS đọc lại "Dạ 3 giờ chiều mai còn trống, em đặt cho mình nhé?". Toàn bộ vòng này phải hoàn tất dưới ~1.5 giây thì hội thoại mới tự nhiên.

Hai kiến trúc lớn: Cascaded vs Speech-to-Speech

  • Cascaded (nối tầng): ASR → LLM → TTS như trên. Dễ debug, dễ chèn business logic (kiểm tra tồn kho, xác thực), nhưng cộng dồn độ trễ và mất sắc thái cảm xúc.
  • Speech-to-Speech (S2S) end-to-end: mô hình nhận audio và trả audio trực tiếp (ví dụ Realtime API dạng streaming). Độ trễ thấp, giữ ngữ điệu, nhưng khó chèn tool/logic và khó kiểm soát nội dung.
Khung chọn nhanh: cần kiểm soát nghiệp vụ chặt (ngân hàng, y tế) → chọn cascaded. Cần hội thoại tự nhiên, cảm xúc, tốc độ (trợ lý cá nhân) → cân nhắc S2S.

Multimodal: khi agent phải "nhìn" và "nghe"

Multimodal nghĩa là agent hợp nhất nhiều modality. Ví dụ thực tế:

  • Agent hỗ trợ kỹ thuật: khách chụp ảnh bảng lỗi máy giặt + nói "nó kêu thế này" (gửi audio) → agent đọc mã lỗi từ ảnh + phân tích tiếng động → chẩn đoán.
  • Agent bán hàng: khách gửi ảnh sản phẩm muốn tìm + mô tả bằng giọng nói → agent tra cứu catalog.
Điểm mấu chốt: các modality đến không đồng bộ và có độ tin cậy khác nhau. Bạn cần một lớp hợp nhất (fusion) quyết định tín hiệu nào ưu tiên.

Khung tư duy: 5 câu hỏi trước khi code

  • Đồng bộ hay bất đồng bộ? Hội thoại điện thoại (đồng bộ, nhạy trễ) khác với xử lý voice message (bất đồng bộ, chấp nhận trễ).
  • Ngân sách độ trễ là bao nhiêu? Ghi rõ mục tiêu (ví dụ dưới 800ms từ khi khách dứt lời tới khi agent bắt đầu nói).
  • Cần chèn tool/nghiệp vụ không? Nếu có → nghiêng về cascaded.
  • Ngôn ngữ và giọng vùng miền? Tiếng Việt có dấu, giọng Bắc/Trung/Nam — ASR phải được test riêng.
  • Chạy ở đâu? Điện thoại (PSTN/SIP), web (WebRTC), hay app di động? Quyết định codec và transport.

Sai lầm thường gặp

  • Bê nguyên tư duy chatbot text sang voice. Voice không có nút "gửi"; agent phải tự biết khi nào khách nói xong (endpointing).
  • Bỏ qua barge-in. Người dùng ghét phải nghe hết câu robot mới được chen vào. Thiếu barge-in làm agent trở nên khó chịu.
  • Chọn S2S vì "nghe xịn" nhưng lại cần xác thực OTP, tra cứu số dư. Bạn sẽ khổ sở khi chèn logic.
  • Chỉ test bằng giọng chuẩn của chính mình. Thực tế có tiếng ồn, giọng địa phương, nói ngọng.

Việc cần làm sau bài này

Vẽ ra pipeline cho use case của bạn, ghi rõ ngân sách độ trễ và chọn kiến trúc cascaded/S2S. Đây là bản thiết kế bạn sẽ hiện thực hóa dần trong các bài sau.

Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi