Giải pháp Voice AI nhanh và thông minh với kiến trúc Responder-Thinker và Local VAD

Voice AI (trí tuệ nhân tạo giọng nói) đang được phát triển rộng rãi, nhưng nhiều hệ thống demo chỉ kết nối trực tiếp trình duyệt với API mô hình âm thanh thời gian thực, khiến độ trễ lớn và khó vận hành quy mô thực tế. Bài viết này giới thiệu kiến trúc sản xuất tối ưu với hệ thống đa-thinker (multi-thinker), trong đó backend đóng vai trò trung gian và sử dụng local voice activity detection (Local VAD) để kiểm soát toàn bộ pipeline âm thanh, mang lại trải nghiệm trò chuyện nhanh nhạy và tự nhiên hơn.

Tác giả đã xây dựng hệ thống Voice AI chịu tải hàng nghìn cuộc gọi mỗi ngày trong 1,5 năm qua, và chia sẻ kiến trúc cũng như các bài học kinh nghiệm quan trọng về pattern Responder-Thinker, tại sao mô hình đơn (single-thinker) không thể mở rộng, cách xây dựng multi-thinker, vai trò then chốt của local VAD, đồng thời cung cấp kèm repo mã nguồn mẫu mở đầy đủ.

Thách thức độ trễ trong Voice AI truyền thống

Trước khi có Realtime API của OpenAI, quy trình xử lý voice AI bao gồm chuỗi ba mô hình liên tiếp: chuyển đổi giọng nói thành văn bản (STT), mô hình ngôn ngữ lớn (LLM), và tổng hợp giọng nói (TTS). Thời gian xử lý cộng dồn từ 1,2 đến 3 giây mới có thể trả lời, trong khi với hội thoại tự nhiên, khoảng trễ trên 800ms là quá lâu, khiến trải nghiệm đứt gãy.

Dù đã cải thiện bằng cách chuyển detection sang server, kiến trúc pipeline nối tiếp vẫn là nút cổ chai trong việc đạt tốc độ tự nhiên khi trò chuyện.

Realtime API: nhanh nhờ gom pipeline, nhưng vẫn thiếu thông minh

Realtime API của OpenAI gộp ba bước STT → LLM → TTS thành một call duy nhất, giảm độ trễ xuống gần dưới 1 giây, cải thiện đáng kể trải nghiệm người dùng.

Tuy nhiên, mô hình realtime này nhanh nhưng không đủ tinh gọn trong xử lý các yêu cầu phức tạp, hướng dẫn nhiều bước hay sử dụng công cụ chuyên biệt. Người dùng có thể nhận được thông tin sai lệch do vấn đề "hallucination" và chất lượng suy giảm khi prompt trở nên dài.

Vậy là ta đối mặt với bài toán mới: đổi lấy tốc độ, lại phải đánh đổi độ chính xác và trí thông minh.

Kiến trúc Responder-Thinker: Sự kết hợp của nhanh và chính xác

Giải pháp của tác giả là mô hình Responder-Thinker, phân tách chức năng ra:

• Responder dựa trên Realtime API, luôn bật, đảm nhiệm tương tác xã hội nhanh: lời chào, xác nhận, giữ chỗ câu trả lời, điều phối lượt nói. Nếu câu hỏi đòi hỏi dữ liệu thực hoặc suy luận phức tạp, Responder phân loại và chuyển sang Thinker.

• Thinker là mô hình text-based chạy ngầm với prompt chuyên biệt và công cụ hỗ trợ cho từng lĩnh vực, đảm bảo xử lý đầy đủ và chính xác. Kết quả từ Thinker được tiêm lại vào luồng Realtime API và Responder phụ trách phát lại một cách tự nhiên.

Ý tưởng then chốt: giọng nói realtime không cần phải thông minh, chỉ cần hiện diện trong khi "bộ não" đang xử lý ở nền.

Pattern này cũng được OpenAI giới thiệu trong repo openai-realtime-agents với tên gọi "Chat-Supervisor".

Tại sao mô hình đơn Thinker không ổn?

Một Thinker đơn, đa nhiệm cho mọi lĩnh vực (thời tiết, chứng khoán, tin tức, kiến thức...) sẽ nhanh chóng quá tải vì phải xử lý đa dạng yêu cầu với cùng một prompt quá dài.

Điều này dẫn đến chất lượng giảm sút và không thể tối ưu riêng lẻ từng miền kiến thức. Mọi truy vấn dù dễ hay khó đều dùng chung tài nguyên, gây lãng phí và hiệu quả thấp.

Thay vào đó, kiến trúc đa-thinker như microservices cho phép:

• Mỗi Thinker tập trung một lĩnh vực riêng với prompt và công cụ đặc thù

• Tùy chỉnh mô hình phù hợp từng nhiệm vụ (ví dụ weather dùng mô hình nhẹ, news dùng mô hình cao cấp hơn)

• Dễ dàng thử nghiệm, caching và nâng cấp độc lập, cải thiện tổng thể hệ thống.

Kiến trúc backend trung gian điển hình trong sản xuất

Khác với demo thường thấy là trình duyệt kết nối trực tiếp với OpenAI qua WebRTC, hệ thống thực sản xuất âm thanh luôn đi qua backend:

Browser ←—WebRTC—→ Python Backend ←—WebSocket—→ OpenAI Realtime API
                      │
                Thinker Agents

Backend dùng FastAPI và thư viện aiortc để hỗ trợ WebRTC server-side, đồng thời mở WebSocket đến Realtime API, chuyển đổi tần số mẫu âm thanh đảm bảo chất lượng.

Backend trung gian cho phép kiểm soát:

• Toàn bộ sự kiện giữa người dùng và mô hình, phục vụ phân tích và báo cáo

• Quản lý trạng thái đoạn hội thoại, bộ nhớ người dùng đa phiên, caching kết quả

• Triển khai Local VAD tự phát hiện điểm dừng câu nói, giảm đáng kể độ trễ

• Bảo mật API key, không lộ ra trình duyệt

• Hỗ trợ linh hoạt nhập liệu từ web cũng như dòng thoại từ hệ thống SIP, Twilio, contact center

Local VAD – bí quyết để cảm nhận độ trễ gần như tức thì

Phần quan trọng nhất làm nên sự mượt mà là việc phát hiện giọng nói (Voice Activity Detection) được xử lý ngay tại backend, thay vì phụ thuộc máy chủ OpenAI.

Thông thường, OpenAI quyết định khi nào người dùng ngừng nói dựa trên âm thanh stream đến, khiến lần lượt nhiều trăm ms bị trừ vào độ trễ tổng.

Kiến trúc trong bài dùng mô hình TEN VAD chạy nội bộ backend để xác định điểm đầu và kết thúc câu nói ngay lập tức, không cần chờ tín hiệu từ server OpenAI.

Cơ chế gồm ba trạng thái: im lặng, nói, và trạng thái đệm (hangover); khi phát hiện kết thúc câu, backend ngay lập tức gửi commit buffer và yêu cầu API tạo phản hồi.

Kết quả: cảm giác như AI trả lời trước khi bạn dứt lời, giảm tới gần 700ms thời gian chờ, tạo trải nghiệm gần gũi như người thật.

Điều phối intelligent routing bằng mô hình "kém thông minh" nhưng rất nhanh

Responder không cần quá nhiều suy nghĩ nhưng phải nhanh chóng phân loại ý định người dùng vào một miền cố định (weather, stocks, news, knowledge, research) để routing chính xác đến Thinker tương ứng.

Vì thế, Responder quyết định này bằng một function call giới hạn enum rõ ràng, giúp giảm lỗi phân loại và đơn giản hóa fallback – các truy vấn không xác định được mặc định chuyển vào Thinker kiến thức chung.

Việc xử lý song song Thinker trong backend giúp Responder tiếp tục tương tác mà không phải chờ Thinker trả lời.

3 lớp bảo vệ giúp xử lý tình huống khó ở môi trường thực

Khi Thinker trả kết quả, phải đảm bảo:

1. Người dùng có thể ngắt lời: Nếu người gọi bắt đầu nói trong lúc Thinker đang xử lý, kết quả đó có thể cũ, không nên phát trả, chỉ gửi output về server để API thoả mãn yêu cầu.

2. Responder đang phát âm thanh: Nếu Realtime API vẫn đang nói, API có thể bỏ qua lệnh tạo phản hồi tiếp theo. Cần dùng khóa khóa (lock) để tuần tự hóa requests response.create.

3. Người dùng ngắt lời khi chờ response.create: Phải kiểm tra lại trạng thái lượt gọi để tránh phát sai phản hồi khi người dùng vừa ngắt lời.

Nhờ vậy hệ thống ứng xử với người dùng linh hoạt, tránh lỗi "thinker đã trả lời mà không có phản hồi", hay trả lời câu cũ không phù hợp.

Hỗ trợ ngắt lời nhanh bằng local VAD

Khi phát hiện người dùng bắt đầu nói ngay trong lúc phát đáp, backend:

• Tăng số lượt gọi (turn_id) để huỷ bỏ mọi tác vụ Thinker đang chạy

• Gửi lệnh huỷ phát âm thanh hiện hành

• Xoá bộ đệm âm thanh phát để dừng ngay lập tức

Local VAD giúp phát hiện này nhanh hơn server-side detection nhiều, giảm đáng kể cảm giác trễ và khó chịu.

Quản lý context phong phú đa phiên để tạo cảm giác cá nhân hóa

Một câu hỏi như "Còn phòng 2 phòng ngủ không?" không đủ nếu không có ngữ cảnh về ngôi nhà hay người gọi.

Kiến trúc sử dụng mô hình UserContext lưu trữ vào Redis gồm:

• Thông tin ưu tiên, sở thích

• Các dữ liệu trích xuất, tổng hợp từ cuộc hội thoại trước

• Tóm tắt hội thoại

• Các chỉ số tín hiệu hành vi

Mỗi Thinker có thể đọc và ghi ngữ cảnh chung này, giúp kết nối thông tin và đem đến trải nghiệm đặc thù với người dùng.

Những bài học kinh nghiệm rút ra

• Việc tự triển khai local VAD rất đáng đầu tư, vì nó là khác biệt lớn giữa cuộc nói chuyện cảm giác như nói chuyện với máy hay thực sự với người.

• Quyết định phân luồng (routing) quan trọng hơn chất lượng suy luận đơn thuần, vì routing sai thì kết quả có chính xác cũng vô nghĩa.

• Hiện tượng "đợi máy trả lời" (stalling) là vấn đề prompt engineering, không phải lỗi kỹ thuật, API cho phép tạo phản hồi xác nhận nhanh trước khi chạy Thinker backend.

• Kiến trúc đa-thinker (multi-thinker) tuy phức tạp hơn nhưng đáng đổi lấy về chất lượng, quản lý và hiệu năng.

• Việc backend làm trung gian xử lý là không thể thiếu trong môi trường sản xuất, giúp bảo mật, quản lý trạng thái, tính linh hoạt và giám sát.

• Ba lớp kiểm soát (guards) giúp hệ thống ổn định và phản ứng tự nhiên, tránh các lỗi thường gặp trong thực tế.

---

Code nguồn đầy đủ với Local VAD, routing đa-thinker, user context, Docker deployment, và mô hình thử nghiệm delay dài có sẵn tại: github.com/lackmannicholas/responder-thinker. Bạn có thể dễ dàng clone, triển khai và trải nghiệm thử.

---

Bài viết trước: Giảm 600ms trong mỗi lượt gọi Voice AI bằng Local VAD

Bài viết tiếp theo: Thêm biên giới bảo vệ (guardrails) và đánh giá chất lượng giọng nói cho pattern Responder-Thinker.