Làm Cùng Long.
← Quay lại Kho ghi chú
Automation & AI Workflow · 10 phút đọc ·

Gemini Live hay TTS? Cách chọn kiến trúc cho ứng dụng voice AI

Khi nói “làm ứng dụng AI bằng giọng nói”, rất dễ gom mọi thứ vào một nhóm.

Nhưng có ít nhất hai bài toán hoàn toàn khác nhau.

Bài toán A: Tôi đã có nội dung. Hãy đọc nó thành giọng nói tự nhiên.

Bài toán B: Người dùng nói chuyện trực tiếp. AI phải hiểu, phản hồi, nhìn context, gọi tool và tiếp tục hội thoại.

Bài toán A thiên về Text-to-Speech — TTS.

Bài toán B thiên về Live API / voice agent.

Google hiện có cập nhật ở cả hai hướng: Gemini 3.8 Live và 3.8 Live Extended Thinking ở lớp hội thoại thời gian thực; Firebase AI Logic đưa Gemini TTS gần hơn tới app developer.

Nếu không tách hai use case này, chúng ta rất dễ xây một hệ thống phức tạp hơn cần thiết.

Mục lục

1. TTS và Live API khác nhau từ bản chất tương tác

Tài liệu Firebase phân biệt rất rõ.

TTS

Luồng một chiều:

Text
  ↓
Model TTS
  ↓
Audio

Đầu vào là text đã biết.

Output là speech.

Use case phù hợp:

  • đọc bài viết;
  • narration;
  • podcast từ script;
  • audiobook;
  • voiceover;
  • nội dung hai speaker đã viết trước.

TTS được thiết kế để đọc đúng nội dung được cung cấp, đồng thời cho phép điều khiển style, accent, pace và tone bằng natural language.

Live API

Luồng hai chiều:

Voice / visual context
  ↓
Model
  ↔ tools / APIs
  ↓
Streaming audio response

Nội dung phản hồi chưa biết trước.

Model phải quyết định nói gì dựa trên context đang diễn ra.

Use case:

  • trợ lý voice;
  • troubleshooting;
  • sales/service agent;
  • onboarding;
  • booking;
  • real-time coaching;
  • agent nhìn màn hình hoặc camera và phản hồi.

Khác biệt cốt lõi không phải audio quality.

Khác biệt là mức độ quyết định mà model phải tự thực hiện trong thời gian thực.

2. Gemini 3.8 Live thêm gì cho voice agent?

Google giới thiệu hai model.

Gemini 3.8 Live

Được định vị cho scale và cost efficiency, kết hợp conversational intelligence, fluid dialogue và visual grounding.

Gemini 3.8 Live Extended Thinking

Dành cho high-complexity task, tăng khả năng reasoning nhiều bước.

Ngoài benchmark, các capability đáng chú ý hơn với product design gồm:

  • xử lý visual input gần thời gian thực;
  • chuyển giữa nhiều ngôn ngữ trong cùng hội thoại;
  • tool/API call chạy nền;
  • tiếp tục hội thoại trong khi tác vụ nền chưa xong;
  • Extended Thinking có thể reasoning sâu hơn và cập nhật tiến độ trong luồng nói.

Google cho biết 3.8 Live tự động nhận diện và chuyển giữa 97 ngôn ngữ được hỗ trợ trong hội thoại.

Con số này là capability của model tại thời điểm công bố; khi build production vẫn nên kiểm tra language support hiện hành theo API docs.

3. Extended Thinking dành cho loại task nào?

Không phải voice interaction nào cũng cần Extended Thinking.

Một trợ lý chỉ làm:

“Bật nhạc.”

“Đặt timer 10 phút.”

“Đọc tin hôm nay.”

không cần nhiều bước reasoning.

Extended Thinking có ý nghĩa hơn khi một yêu cầu cần:

  • lập kế hoạch;
  • gọi nhiều tool;
  • xử lý phụ thuộc;
  • chờ external action;
  • điều chỉnh theo kết quả giữa chừng.

Ví dụ:

“Tìm ba lựa chọn lịch họp phù hợp với tôi và khách hàng tuần tới, tránh giờ đón con, rồi soạn email đề xuất nhưng chưa gửi.”

Agent cần:

  1. hiểu constraint;
  2. đọc calendar;
  3. có thể hỏi availability phía khác nếu có;
  4. lọc;
  5. lập phương án;
  6. soạn email;
  7. dừng trước action gửi.

Đó là workflow khác hẳn TTS.

Một nguyên tắc tối ưu chi phí:

Chỉ dùng reasoning sâu ở bước thật sự cần judgement.

Các bước deterministic nên giao cho function hoặc workflow bình thường.

4. Visual context làm voice agent khác chatbot nói bằng giọng

Một chatbot có TTS có thể nghe giống voice assistant.

Nhưng nếu nó chỉ:

speech-to-text → chat → text-to-speech,

thì interaction vẫn là chat qua audio.

Gemini Live hỗ trợ visual input gần thời gian thực.

Điều này mở ra kiểu tương tác:

“Cái nút này để làm gì?”

“Vì sao màn hình của tôi báo lỗi này?”

“Nhìn bảng này và nói giúp tôi metric nào bất thường.”

Voice trở thành một lớp chỉ dẫn kết hợp với hình ảnh đang nhìn thấy.

Về UX, điều này giảm nhu cầu người dùng phải “dịch màn hình thành chữ”.

Nhưng nó cũng tăng privacy surface.

Visual context có thể chứa:

  • email;
  • tên khách hàng;
  • dữ liệu nội bộ;
  • token;
  • dashboard;
  • thông tin cá nhân.

Do đó, product cần policy rõ về:

  • frame nào được gửi;
  • có redaction không;
  • lưu bao lâu;
  • ai truy cập;
  • có opt-in không.

Multimodal context làm agent mạnh hơn.

Nó cũng làm data governance khó hơn.

5. Tool calling nền làm trải nghiệm ít bị gãy

Voice UX có một vấn đề rất cụ thể: silence.

Nếu người dùng yêu cầu agent gọi API mất 5–10 giây mà hệ thống im lặng, người dùng không biết:

  • agent có nghe không;
  • app treo không;
  • task đang chạy không;
  • cần nói lại không.

Google nhấn mạnh 3.8 Live có thể gọi tool/API ở background trong khi cuộc hội thoại tiếp tục.

Extended Thinking còn có thể dùng progress narration.

Ví dụ:

“Được, tôi đang kiểm tra lịch của bạn.”

Sau đó vẫn có thể duy trì hội thoại thay vì chặn toàn bộ interface.

Đây là một chi tiết UX nhưng rất quan trọng với agent.

Hệ thống nhiều bước cần state communication.

Không chỉ có hai trạng thái:

done / failed.

Mà cần:

  • accepted;
  • working;
  • waiting;
  • needs input;
  • needs approval;
  • completed;
  • partial failure.

Voice agent tốt cần nói trạng thái tự nhiên mà không làm người dùng khó chịu.

6. TTS vẫn là lựa chọn tốt hơn cho rất nhiều use case

AI agent thường hấp dẫn hơn demo TTS.

Nhưng rất nhiều sản phẩm chỉ cần TTS.

Ví dụ một website muốn có nút:

“Nghe bài viết.”

Không cần một agent reasoning từng paragraph.

Pipeline đơn giản:

Markdown article
  ↓
clean text
  ↓
TTS
  ↓
audio file
  ↓
player

Ưu điểm:

  • predictable;
  • cache được;
  • dễ QA;
  • ít tool risk;
  • chi phí dễ tính;
  • content đúng script.

Firebase AI Logic docs cho biết TTS cho phép control voice và một số đặc điểm như style, accent, pace, tone. Tính năng TTS trong Firebase AI Logic hiện được đánh dấu Preview, nên implementation nên tránh phụ thuộc cứng vào behavior chưa ổn định.

Firebase docs cũng hỗ trợ multi-speaker với đúng hai speaker trong cấu hình hiện tại.

Nếu chỉ muốn biến một bài viết thành cuộc đối thoại podcast hai người, đây là use case đáng thử mà chưa cần Live Agent.

7. Firebase AI Logic thay đổi lớp triển khai như thế nào?

Điểm hữu ích của Firebase AI Logic là developer có thể gọi Gemini capability từ app qua SDK theo flow Firebase, thay vì tự dựng toàn bộ backend bridge cho mọi thử nghiệm.

Nhưng “gọi được trực tiếp từ app” không có nghĩa bỏ qua security.

Production vẫn cần quan tâm:

  • App Check;
  • quota;
  • model config;
  • Remote Config nếu muốn thay đổi behavior;
  • prompt governance;
  • abuse prevention;
  • cost monitoring.

Khi feature còn Preview, nên có abstraction layer để đổi model hoặc API mà không phải sửa toàn bộ UI.

Một pattern đơn giản:

UI
  ↓
VoiceService interface
  ↓
Firebase AI Logic / Gemini provider
  ↓
audio output

Đừng để UI gọi trực tiếp một model name ở hàng chục chỗ.

8. Framework chọn TTS hay Live API

Tôi dùng năm câu hỏi.

1. Nội dung output có biết trước không?

Có → nghiêng TTS.

Không → nghiêng Live.

2. Người dùng có cần interrupt và nói tiếp không?

Có → Live.

Không → TTS có thể đủ.

3. Có cần nhìn camera/màn hình không?

Có → Live.

4. Có cần gọi tool theo context hội thoại không?

Có → Live hoặc agent architecture.

5. Có cần exact wording không?

Có → TTS.

Bảng tóm tắt:

Nhu cầuTTSLive API
Đọc bài viếtRất phù hợpOverkill
Voiceover videoPhù hợpKhông cần
Podcast từ scriptPhù hợpKhông cần
Hỏi đáp tự doHạn chếPhù hợp
Trợ lý gọi APIKhôngPhù hợp
Nhìn màn hình và hướng dẫnKhôngPhù hợp
Exact legal/compliance wordingTốt hơnCần guardrail mạnh
Conversation nhiều lượtKhông tối ưuPhù hợp

9. Voice agent cần guardrail gì?

Voice làm interaction nhanh.

Và chính vì nhanh nên dễ tạo action ngoài ý muốn.

Tôi sẽ giữ ít nhất sáu guardrail.

Confirmation cho hành động irreversible

Gửi email, thanh toán, xóa dữ liệu, đổi production phải xác nhận lại.

Read-back cho thông tin quan trọng

Ví dụ số tiền, ngày giờ, người nhận.

Tool scope nhỏ

Agent chỉ thấy tool cần cho use case.

PII handling

Không đưa transcript chứa dữ liệu nhạy cảm vào analytics.

Session boundary

Khi session kết thúc, context nào được giữ?

Fallback to screen

Một số action nên hiện UI để người dùng xem trước.

Voice không nên loại bỏ visual confirmation khi visual confirmation an toàn hơn.

10. Ví dụ kiến trúc cho content và automation

Use case 1 — Nghe bài Knowledge

Article
  ↓
Markdown cleanup
  ↓
Gemini TTS
  ↓
MP3/PCM conversion
  ↓
CDN/storage
  ↓
Web player

Đây là pipeline deterministic.

Không cần agent.

Use case 2 — Trợ lý hỏi đáp trên Knowledge Hub

User voice
  ↓
Live API
  ↓
retrieval từ Knowledge
  ↓
response voice

Có thể thêm tool nhưng vẫn read-only.

Use case 3 — Trợ lý Marketing Ops

User voice
  ↓
Live Agent
  ↓
đọc dashboard / campaign data
  ↓
phân tích
  ↓
đề xuất action
  ↓
approval
  ↓
write tool

Ở đây cần agent, tool và permission architecture.

Ba use case đều “dùng voice AI”.

Nhưng kiến trúc hoàn toàn khác nhau.

Đó là điều quan trọng nhất.

Đừng bắt đầu từ model. Bắt đầu từ loại tương tác và mức quyền cần thiết.

Khi đã rõ input, output, latency, tool access và risk, lựa chọn TTS hay Live API sẽ dễ hơn rất nhiều.

Đọc tiếp trong Series Agentic Stack 2026

Nguồn tham khảo