Show HN: Bot giọng nói với thời gian phản hồi 500ms

• AI giọng nói cần phản hồi tức thì như hội thoại thông thường để tạo cảm giác tự nhiên, vì vậy bản demo này hướng tới phản hồi giọng nói-đến-giọng nói trong 500ms
• Thách thức cốt lõi là giảm độ trễ mà người dùng cảm nhận được, trong đó cả thời gian mạng và thời gian xử lý của mô hình đều có ảnh hưởng
• Bản demo cho thấy với cách tối ưu hóa và triển khai phù hợp, tương tác LLM độ trễ thấp có thể đạt tới mức nào
• Việc triển khai sử dụng Pipecat, một framework mã nguồn mở cho AI hội thoại bằng giọng nói và đa phương thức
• Để tạo ra bot giọng nói hội thoại đạt mức sản phẩm thực tế, ngoài hiệu năng mô hình thì việc quản lý độ trễ trên toàn bộ đường đi của lời gọi cũng rất quan trọng

---

Bản demo nhắm tới phản hồi giọng nói trong 500ms

• The World's Fastest Voice Bot Demo là một bản demo cho thấy chatbot AI dựa trên giọng nói có thể phản hồi nhanh đến mức nào
• Mục tiêu là đạt thời gian phản hồi voice-to-voice 500ms
• Con người kỳ vọng phản hồi nhanh trong hội thoại thông thường, vì vậy trong giao diện AI giọng nói, tốc độ trở thành yếu tố chất lượng then chốt

Hướng triển khai để giảm độ trễ

• Bản demo được xây dựng xoay quanh tương tác LLM độ trễ thấp
• Nó cho thấy tiềm năng của chatbot AI giọng nói được tối ưu hóa và triển khai để giảm thiểu cả độ trễ mạng lẫn độ trễ mô hình
• Bot được xây dựng bằng Pipecat
  • Pipecat là một framework mã nguồn mở dành cho AI hội thoại bằng giọng nói và đa phương thức

[GN⁺]

Ý kiến Hacker News

• Nhanh thật sự. Rất ấn tượng và gọn gàng. Có cảm giác tốc độ thắng hết mọi thứ khác. Chỉ sau khi đọc bình luận tôi mới bắt đầu để ý giọng nói hơi giống robot
  Tôi từng làm AI cho hỗ trợ khách hàng, và thời gian phản hồi trung bình đã giảm từ 24~48 giờ xuống còn vài giây
  Có lần một khách hàng nhận được tin nhắn kiểu “Hello Bitch, your package will be picked up by USPS today...”, nhưng khách vẫn trả lời “thank you so much” và cho điểm CSAT tuyệt đối. Ngay cả sai lầm nghiêm trọng như vậy mà tốc độ vẫn thắng tất cả

  • Tôi không nghĩ ai cũng sẽ phản ứng như vậy. Với một số người, việc gọi nhau là bitch có thể là cách nói thường ngày nên đã lọt vào dữ liệu huấn luyện, nhưng với người khác thì hoàn toàn không phải vậy
  • Điều buồn cười là bọn tôi đã sửa vấn đề này bằng cách thêm thẻ #profanity rồi chuyển tin nhắn sang nhân viên hỗ trợ tiếp theo
    Nhưng sau đó kỹ sư bán hàng năng nổ nhất lại không thể demo cho khách tiềm năng nữa. Có rất nhiều cuộc gọi ngượng ngùng khi AI đơn giản là không phản hồi, vì anh ấy có họ là Dick
  • Có lẽ giải pháp là đưa tin nhắn qua một LLM khác để loại bỏ từ chửi thề và làm nó lịch sự nhất có thể. Chỉ là chi phí chạy chắc sẽ tăng hơn gấp đôi
  • Cũng có thể đó là tên của khách hàng. Ít nhất thì đó có thể là cái tên mà khách đã tự nhập vào

• Thật sự rất rất tốt. Nếu tôi hiểu đúng thì đây có vẻ là một ứng dụng teaser để giới thiệu Cerebrium, nhưng có tiềm năng trở thành killer app. Khi tôi thử trên iPad, độ trễ được báo nằm trong khoảng 1400ms đến 400ms, và ở mức thấp thì cảm giác rất mượt
  Với tốc độ này, trong một số workflow chat có lẽ sẽ cần hoặc có thể dùng cách tiếp cận nhiều giai đoạn. Đầu tiên phản hồi thật nhanh trong khi một truy vấn dữ liệu/thông tin/RAG dài hơn được chạy riêng, rồi sau đó kết quả có thông tin sẽ tiếp quản
  Con người cũng hoạt động như vậy. Chúng ta bắt đầu trả lời trong lúc sắp xếp suy nghĩ và dùng nhiều từ đệm
  Hiện giờ đa phần либо là ném prompt một phát, либо là parse → query → generate ở nền, nhưng nếu phản hồi độ trễ thấp trở nên khả thi thì luồng tốt hơn có lẽ sẽ gần với kiểu “[Llama 8B trong tai trong 3 giây] → truy vấn → [Llama 70B/GPT-4 v.v. trong 55 giây có tích hợp kết quả truy vấn]”

  • Tôi ở phía Cerebrium. Cảm ơn bạn rất nhiều vì phản hồi, và rất vui khi bạn có trải nghiệm tốt
    Ứng dụng này có thể mở rộng hoặc triển khai rất dễ dàng nên có thể chỉnh sửa theo bất kỳ cách nào bạn muốn. Bạn có thể đổi sang LLM khác, mô hình nhận dạng giọng nói, mô hình tổng hợp giọng nói khác, hoặc thay prompt và triển khai cả RAG nữa
    Cùng với Daily, chúng tôi tập trung vào kỹ sư. Mục tiêu là để họ có thể chỉnh ứng dụng rất linh hoạt theo use case và sở thích của mình, đồng thời bớt phải đụng vào phần thiết lập hạ tầng nhàm chán
    Có thể xem thêm về cách mở rộng tại đây: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
  • Tôi cũng đã thắc mắc điều này. Liệu có thể có một LLM nhỏ và hiệu quả để ước lượng độ phức tạp tác vụ nói chung mà không cần chạy toàn bộ khối lượng công việc thực tế không?
    Nếu có thể chấm độ phức tạp theo thang liên tục, thì thay vì chờ một vòng khứ hồi dài, nó sẽ biết có nên gửi trước phản hồi kiểu “Vâng, xin chờ một chút. Tôi sẽ kiểm tra” hay không

• Có một mô-đun phát hiện hoạt động giọng nói cho trình duyệt đa nền tảng là https://github.com/ricky0123/vad. Đây là bản port mạng VAD của Silero sang ONNX. Đa nền tảng ở đây nghĩa là nó cũng chạy trên Firefox. Không cần phiên WebRTC, chỉ cần quyền truy cập micro nên đơn giản hơn. Tôi cũng tò mò liệu trình duyệt có cung cấp tính năng này như một tùy chọn native hay không
  Cũng đã có các engine chuyển văn bản thành giọng nói chạy trên trình duyệt, ngày càng nhanh hơn và chất lượng cũng tốt hơn. Sẽ thật tuyệt nếu trình duyệt có TTS tốt được tích hợp sẵn
  GPT-4o đã đưa nhận dạng giọng nói tự động, hiểu nội dung và tạo phản hồi bằng giọng nói vào một mô hình duy nhất để giảm độ trễ, và đó có vẻ là một ý tưởng khá hay. Việc họ vẫn chưa phát hành cho thấy có lẽ đang có vấn đề về khả năng mở rộng hoặc chất lượng dưới một hình thức nào đó
  Tương tự, có lẽ cũng sẽ có người xây dựng các mô hình ngôn ngữ lớn đa phương thức tích hợp công khai với cả đầu vào/đầu ra âm thanh và cả đầu vào thị giác
  Tôi tò mò một mô hình kết hợp đơn là cần thiết và tối ưu đến mức nào về mặt tối ưu độ trễ và chi phí
  Bảng phân rã được đưa ra khá thú vị. Nếu có thể thì có vẻ tốt hơn khi chạy nhiều mô hình hơn trên thiết bị, như tạo giọng nói, và có thể cả phần đầu của chuyển giọng nói thành văn bản hoặc hiểu giọng nói nữa. Ai mà muốn chờ STUN chứ?

  • Tôi nghĩ môi trường desktop nên cung cấp chuyển giọng nói thành văn bản như một dịch vụ với giao diện tiêu chuẩn. Giống như stdin, nhưng là một giao diện riêng cho giọng nói
    Ứng dụng thì mặc định sẽ không lắng nghe nên có thể bỏ qua, nhưng bộ chuyển lời nói thành văn bản sẽ có thể thay thế được và dùng được cho mọi ứng dụng
  • Theo các con số này thì ngay cả khi xử lý nhận dạng giọng nói và tổng hợp giọng nói trên thiết bị, nếu phần còn lại giữ nguyên thì cũng chỉ giảm được 120ms. 639ms còn lại là độ trễ phần cứng·mạng, và việc chuyển dữ liệu vào/ra LLM. Vẫn chậm hơn mức mong muốn
    Về mặt logic thì phải nghĩ theo đơn vị âm vị. Đầu ra của LLM phải bắt kịp âm vị cuối cùng đủ nhanh để có thể phản hồi “ngay lập tức” vào lúc điểm kết thúc được phát hiện, và để làm vậy thì toàn bộ chuỗi cần có độ trễ đầu cuối cỡ 200ms
    Để tiến gần mức đó có lẽ cần một kiến trúc khác. Giống như cách con người xử lý lời nói: cho luồng âm thanh chạy trước dựa trên các âm vị được dự đoán trước khi chúng thực sự đến, còn âm thanh nhận được thật chỉ được dùng như một tín hiệu xác nhận nhẹ để quyết định xóa bộ đệm đầu ra hiện tại hay xử lý lại
    Có thể speculative decoding sẽ giúp được phần nào, nhưng với pipeline trộn audio/text thì có lẽ khó. Ngay từ đầu, không chuyển âm thanh thành văn bản rồi lại chuyển ngược về âm thanh sẽ tốt hơn nhiều
  • Dù bài giới thiệu này hoàn toàn lấn át thứ tôi đang làm, tôi có một bản triển khai assistant đơn giản dùng rick0123/VAD và WebSocket
    https://github.com/charlesyu108/voiceai-js-starter

• Dùng thử trực tiếp thấy khá thú vị. Đầu tuần này tôi đã thử june-va, nhưng thời gian phản hồi dài làm giảm đáng kể tính hữu dụng của nó. Phản hồi nhanh là một tính năng tuyệt vời, và cái này tạo cảm giác giống hội thoại hơn nhiều.
  Điều buồn cười là khi tôi yêu cầu kể một câu chuyện, nó chỉ trả lời mỗi lần một câu, nên để nghe câu tiếp theo tôi phải nói “yes”, “aha”, “please continue”.
  Rồi chúng tôi đã có đoạn đối thoại như thế này: “À, tôi nghĩ mình đã khám phá ra bí mật của bạn!” “Xin hãy nói đi” “Bạn giữ ngữ cảnh ngắn để đạt được thời gian phản hồi ngắn, đúng không” “Chính xác hoàn toàn”

  • Thành thật mà nói thì cách đó ổn. Ngoài ngữ cảnh ngắn ra, câu trả lời ngắn rõ ràng là tốt. Nó đối lập với chế độ giọng nói của ChatGPT hiện nay, nơi bạn hỏi gì đó và bị nghe một bài diễn giải kiểu GPT kéo dài cả phút

• Rất ấn tượng. Cực kỳ nhanh, có lẽ thậm chí còn quá nhanh, nhưng có vẻ đó chính là điểm mấu chốt. Điều gây ấn tượng nhất là cách VAD và xử lý ngắt lời được phối hợp với nhau. Đây rõ ràng là cuộc trò chuyện với tác tử nghe tự nhiên nhất mà tôi từng có cho tới nay. Khi được phát hành công khai tôi nhất định sẽ dùng thử

• Phần marketing ghi là 500 nhưng tính ra lại thành 759

  • Người ta gọi đó là marketing
  • Trong thử nghiệm của tôi có một giá trị ngoại lệ 1400ms, còn khoảng 10 lần thì nằm trong khoảng 400~500ms. Con số marketing có vẻ là công bằng
  • 500 là cho các bước phiên âm/LLM/TTS, tức thời gian từ lúc dữ liệu tới máy chủ đến lúc phản hồi được gửi trở lại. Phần còn lại có vẻ là nhiều độ trễ phụ không phải AI như mã hóa, lưu lượng mạng và những thứ tương tự
  • Độ trễ trong bảng dựa trên heuristic quan sát được hoặc giá trị trung bình. Trên thực tế, tùy cuộc hội thoại mà một số thành phần độ trễ lớn hơn có thể thấp hơn nhiều

• Tôi cũng rất mong chờ suy luận giọng nói. Trước khi OpenAI ra mắt GPT-4o, tôi đã tự làm một bản triển khai Faster Whisper dựa trên WebSocket. Bản triển khai concept huấn luyện phỏng vấn của tôi https://intervu.trueforma.ai và huấn luyện thuyết trình bán hàng https://sales.trueforma.ai đã bị họ vượt mặt.
  Tôi không thể làm cho VAD chạy ổn định nên để mặc định là nhấn để nói. Mọi thứ đều đang chạy trên LattePanda. Tôi định gắn Whisper được Groq host.
  Tôi đã chán những cuộc đối thoại kiểu doanh nghiệp nhàm chán, nên tôi thích ý tưởng dùng Llama3 không kiểm duyệt của Groq làm LLM. Tôi muốn giảm độ trễ và học từ ví dụ này. Tôi cũng muốn thử demo, nhưng có vẻ đang quá tải nên tôi không thể vào nói chuyện với bot.
  Chỉ cần 3 người cùng lúc thử suy luận thì LattePanda của tôi có lẽ sẽ nóng chảy mất

• Cá nhân tôi dùng https://github.com/foges/whisper-dictation cùng với llama-70b của Groq.
  Tôi bắt đầu nói, chuyển sang website, và đến lúc tải xong rồi chọn llama-70b thì tôi cũng nói xong luôn, nên thời gian chờ thêm bằng 0. Tôi đọc nhanh hơn nghe rất nhiều, nên cách này hoàn toàn phù hợp với tôi

• Tôi vẫn dùng Firefox

  • Tôi đã làm client UI này và thực sự muốn hỗ trợ Firefox.
    Tôi cần một cách để đo độ trễ giọng nói-đến-giọng nói từ góc nhìn người dùng cuối, và tôi thấy tính năng phát hiện hoạt động giọng nói Silero (https://github.com/snakers4/silero-vad) là đáng tin cậy nhất để phát hiện thời điểm người dùng ngừng nói nhằm bắt đầu bộ đếm thời gian, rồi dừng lại khi âm thanh từ bot xuất hiện.
    Silero chạy bằng onnx-runtime và wasm. Nó có hoạt động phần nào trên Firefox, nhưng VAD bị lỗi sai thường xuyên hơn tôi mong đợi, khiến các con số độ trễ trở nên khá kỳ quặc. Dù vậy tôi vẫn rất muốn làm cho nó hoạt động và hiện vẫn đang cố gắng.
    Mã VAD của UI ở đây: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
  • Đừng chỉ tin vào cảnh báo. Nó hoạt động tốt trên Firefox mới nhất. Demo cũng rất ấn tượng
  • Tôi ghét việc ai cũng chỉ phát triển cho Chromium
  • Có lẽ trên HN có khá nhiều người dùng Firefox
  • Hoạt động hoàn hảo trên Firefox 127

• Thật sự rất ấn tượng
  Siri của Apple vẫn chỉ cho cảm giác như bạn đang có một cuộc trò chuyện mà hai bên liên tục đè lên lời nhau, dừng lại, thất bại, rồi cuối cùng chỉ mong nhận được một câu trả lời tối thiểu