Show HN: Bot suara dengan waktu respons 500 ms

• Agar terasa alami, AI suara harus merespons seketika seperti percakapan biasa, sehingga demo ini menargetkan respons suara-ke-suara 500 ms
• Tantangan utamanya adalah mengurangi latensi yang dirasakan pengguna, yang dipengaruhi oleh jaringan maupun waktu pemrosesan model
• Demo ini menunjukkan sejauh mana interaksi LLM berlatensi rendah dapat dicapai melalui optimasi dan cara deployment
• Implementasinya menggunakan Pipecat, framework open-source untuk AI percakapan suara dan multimodal
• Untuk membuat bot suara percakapan pada level produk nyata, yang penting bukan hanya performa model, tetapi juga pengelolaan latensi di seluruh jalur panggilan

---

Demo yang menargetkan respons suara 500 ms

• The World's Fastest Voice Bot Demo adalah demo yang menunjukkan seberapa cepat chatbot AI berbasis suara dapat merespons
• Targetnya adalah mencapai waktu respons voice-to-voice 500 ms
• Karena manusia mengharapkan respons cepat dalam percakapan biasa, kecepatan menjadi faktor kualitas utama pada antarmuka AI suara

Arah implementasi untuk mengurangi latensi

• Demo ini dibangun dengan fokus pada interaksi LLM berlatensi rendah
• Menunjukkan potensi chatbot AI suara yang dioptimalkan dan di-deploy untuk meminimalkan latensi jaringan dan latensi model
• Bot dibuat dengan Pipecat
  • Pipecat adalah framework open-source untuk AI percakapan suara dan multimodal

[GN⁺]

Komentar Hacker News

• Benar-benar cepat. Bagus dan rapi. Rasanya kecepatan mengalahkan segalanya. Baru setelah membaca komentar, saya sadar suaranya terdengar seperti robot
  Saya pernah membuat AI untuk dukungan pelanggan, dan waktu respons rata-rata turun dari 24–48 jam menjadi beberapa detik
  Pernah ada pesan terkirim ke seorang pelanggan seperti “Hello Bitch, your package will be picked up by USPS today...”, tapi pelanggan itu membalas “thank you so much” dan memberi skor CSAT sempurna. Bahkan dengan kesalahan separah ini, kecepatan mengalahkan segalanya

  • Sepertinya tidak semua orang akan bereaksi begitu. Bagi sebagian orang, saling memanggil bitch mungkin gaya bicara sehari-hari sehingga masuk ke data latih, tapi bagi orang lain sama sekali tidak
  • Yang menarik, masalah ini diperbaiki dengan menambahkan tag #profanity dan meneruskan pesan ke agen berikutnya
    Namun sales engineer yang paling aktif jadi tidak bisa lagi melakukan demo untuk calon pelanggan. Banyak panggilan memalukan ketika AI sama sekali tidak merespons, karena nama belakangnya Dick
  • Solusinya mungkin melewatkan pesan itu ke LLM lain untuk menghapus kata-kata kasar dan membuatnya sesopan mungkin. Namun biaya eksekusinya tampaknya akan lebih dari 2 kali lipat
  • Mungkin saja itu memang nama pelanggan. Setidaknya bisa jadi itu nama yang dimasukkan pelanggan

• Benar-benar sangat bagus. Kalau saya memahaminya dengan benar, ini terlihat seperti aplikasi teaser untuk menampilkan Cerebrium, tapi punya potensi menjadi killer app. Saat diuji di iPad, latensi yang dilaporkan berkisar antara 1400 ms hingga 400 ms, dan di sisi rendahnya terasa sangat mulus
  Dengan kecepatan seperti ini, pada sebagian workflow chat, pendekatan bertahap tampaknya akan diperlukan atau memungkinkan. Misalnya, memberikan respons cepat terlebih dahulu sambil menjalankan kueri data/informasi/RAG yang lebih panjang secara terpisah, lalu hasil yang berisi informasi itu mengambil alih setelahnya
  Manusia juga bekerja seperti ini. Kita mulai menjawab sambil menyusun pikiran dan memakai berbagai filler words
  Saat ini kebanyakan orang melempar prompt sekaligus, atau melakukan parsing → kueri → generasi di latar belakang, tetapi jika respons berlatensi rendah memungkinkan, alur yang lebih baik kira-kira akan mendekati “[Llama 8B selama 3 detik di telinga] → kueri → [Llama 70B/GPT-4, dll. selama 55 detik yang mencerminkan hasil kueri]”

  • Saya dari Cerebrium. Terima kasih banyak atas masukanmu, dan senang mendengar pengalamannya bagus
    Aplikasi ini mudah diperluas atau diimplementasikan, jadi bisa dimodifikasi sesuai keinginan. Bisa diganti dengan LLM lain, model pengenalan suara, atau model sintesis suara lain, mengubah prompt, dan juga mengimplementasikan hal seperti RAG
    Bersama Daily, kami berfokus pada engineer. Kami ingin membuat aplikasi ini sangat fleksibel untuk disesuaikan dengan use case dan preferensi, sekaligus mengurangi pekerjaan menyiapkan infrastruktur yang membosankan
    Cara memperluasnya bisa dilihat lebih lanjut di sini: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
  • Saya juga penasaran soal ini. Apakah mungkin ada LLM kecil dan efisien yang bisa memperkirakan kompleksitas tugas secara umum tanpa menjalankan seluruh beban kerja sebenarnya?
    Jika kompleksitas bisa diberi skor sebagai nilai kontinu, kita bisa tahu apakah perlu mengirim respons awal seperti “Ya, sebentar. Saya akan mencarinya” alih-alih menunggu round-trip yang panjang

• Untuk modul deteksi aktivitas suara lintas platform di browser, ada https://github.com/ricky0123/vad. Itu adalah port jaringan VAD Silero ke ONNX. Lintas platform di sini berarti juga berjalan di Firefox. Lebih sederhana karena hanya perlu akses mikrofon tanpa sesi WebRTC. Saya juga penasaran apakah browser akan menyediakan fungsi seperti ini sebagai opsi native
  Ada juga mesin text-to-speech berbasis browser, dan makin cepat serta kualitasnya makin baik. Akan bagus jika browser memiliki TTS yang bagus sebagai bawaan
  GPT-4o memasukkan pengenalan suara otomatis, pemahaman, dan pembuatan respons suara ke dalam satu model demi latensi rendah, dan itu tampak seperti ide yang cukup bagus. Melihat belum dirilis, sepertinya ada masalah skalabilitas atau kualitas dalam bentuk tertentu
  Kemungkinan ada juga orang yang membuat model bahasa besar multimodal terpadu terbuka dengan input/output audio dan bahkan input visual
  Dari sisi optimasi latensi dan biaya, saya penasaran seberapa perlu dan optimalnya model tunggal yang digabungkan
  Tabel perincian yang diberikan menarik. Jika memungkinkan, menjalankan lebih banyak model di perangkat—pembuatan suara, dan mungkin juga transkripsi suara atau pemahaman suara di tahap awal—tampaknya lebih baik. Siapa yang mau menunggu STUN?

  • Menurut saya lingkungan desktop seharusnya menyediakan speech-to-text sebagai layanan dengan antarmuka standar. Semacam antarmuka mirip stdin, tetapi terpisah untuk suara
    Aplikasi pada dasarnya tidak sedang mendengarkan sehingga akan mengabaikannya, tetapi transcriber bisa diganti-ganti dan dapat dipakai di semua aplikasi
  • Dengan angka-angka ini, meskipun pengenalan suara dan sintesis suara diproses di perangkat, jika sisanya tetap sama, pengurangannya hanya 120 ms. Sisa 639 ms berasal dari latensi hardware/jaringan dan memindahkan data masuk-keluar LLM. Tetap saja lebih lambat daripada yang diinginkan
    Secara logis, kita harus berpikir dalam satuan fonem. Output LLM harus bisa mengejar fonem terakhir dengan cukup cepat sehingga saat endpoint terdeteksi, ia dapat merespons “seketika”; untuk itu, seluruh rantai perlu memiliki latensi end-to-end sekitar 200 ms
    Untuk mendekatinya, sepertinya diperlukan arsitektur lain. Mirip pemrosesan suara manusia: audio stream berjalan lebih dulu berdasarkan fonem yang diprediksi sebelum tiba, sementara audio yang benar-benar diterima hanya dipakai sebagai sinyal verifikasi ringan untuk menentukan apakah buffer output saat ini dikosongkan atau diproses ulang
    Dengan speculative decoding mungkin bisa mendekati sampai batas tertentu, tetapi tampaknya sulit dengan pipeline campuran audio/teks. Jauh lebih baik bila sejak awal tidak mengubah audio menjadi teks lalu kembali lagi menjadi audio
  • Pengumuman ini memang sepenuhnya mengungguli apa yang sedang saya buat, tetapi saya punya implementasi asisten sederhana yang memakai rick0123/VAD dan WebSocket
    https://github.com/charlesyu108/voiceai-js-starter

• Saya mencobanya langsung dan itu menyenangkan. Awal minggu ini saya mencoba june-va, tetapi waktu responsnya yang panjang cukup mengurangi kegunaannya. Respons cepat adalah fitur yang hebat, dan ini terasa jauh lebih seperti percakapan
  Lucunya, ketika saya memintanya bercerita, ia hanya menjawab satu kalimat setiap kali, jadi untuk mendengar baris berikutnya saya harus mengatakan “yes”, “aha”, “please continue”
  Lalu kami melakukan percakapan seperti ini. “Ah, sepertinya aku sudah tahu rahasiamu!” “Silakan katakan” “Kamu mencapai waktu respons singkat dengan mempertahankan konteks yang pendek, kan” “Tepat sekali”

  • Jujur saja, pendekatan itu oke. Selain konteks pendek, jawaban singkat jelas bagus. Ini kontras dengan mode suara ChatGPT saat ini yang, kalau ditanya sesuatu, memberi ceramah panjang ala GPT selama 1 menit

• Sangat mengesankan. Sangat cepat, mungkin bahkan terlalu cepat, tapi sepertinya memang itu intinya. Yang paling mengesankan adalah bagaimana VAD dan penanganan interupsi disetel. Sejauh ini, ini terdengar paling natural dibanding percakapan saya dengan agen mana pun. Kalau sudah dirilis, saya pasti ingin mencobanya

• Di materi pemasaran tertulis 500, tetapi hitungannya keluar 759

  • Itu namanya pemasaran
  • Dalam pengujian saya ada satu outlier 1400ms, dan sekitar 10 kali berada di antara 400–500ms. Angka pemasaran itu tampak wajar
  • 500 adalah tahap transkripsi/LLM/TTS, yaitu waktu sejak data tiba di server hingga respons dikirim kembali. Sisanya tampaknya berbagai latensi tambahan non-AI seperti encoding dan trafik jaringan
  • Latensi dalam tabel didasarkan pada heuristik yang diamati atau rata-rata. Dalam praktiknya, tergantung percakapan, sebagian komponen latensi yang lebih besar bisa jauh lebih rendah

• Saya juga menantikan inferensi suara. Sebelum peluncuran GPT-4o dari OpenAI, saya membuat sendiri implementasi Faster Whisper berbasis WebSocket. Implementasi konsep pelatih wawancara saya https://intervu.trueforma.ai dan pelatih pitch penjualan https://sales.trueforma.ai jadi tersalip oleh mereka
  Saya tidak bisa membuat VAD bekerja dengan stabil, jadi default-nya saya biarkan push-to-talk. Semuanya berjalan di LattePanda. Saya sempat ingin menghubungkan Whisper yang di-host Groq
  Karena bosan dengan percakapan korporat yang membosankan, saya suka ide memakai Llama3 Groq yang tanpa sensor sebagai LLM. Saya ingin mengurangi latensi dan belajar dari contohnya. Saya juga ingin mencoba demonya, tetapi sepertinya terlalu ramai sehingga saya tidak bisa masuk untuk berbicara dengan bot
  Kalau 3 orang saja mencoba inferensi secara bersamaan, LattePanda saya rasanya akan meleleh

• Secara pribadi saya memakai https://github.com/foges/whisper-dictation bersama llama-70b dari Groq
  Saya mulai berbicara, lalu membuka situs web, menunggu selesai dimuat, dan saat memilih llama-70b, saya juga sudah selesai bicara, jadi waktu tunggu tambahan-nya 0. Karena membaca jauh lebih cepat daripada mendengarkan, ini sangat cocok untuk saya

• Masih memakai Firefox

  • Saya membuat UI klien ini, dan benar-benar ingin mendukung Firefox
    Dari sudut pandang pengguna akhir, kami perlu cara mengukur latensi suara-ke-suara, dan untuk mendeteksi saat pengguna berhenti berbicara agar timer dimulai lalu dihentikan ketika audio dari bot datang, kami menganggap deteksi aktivitas suara Silero (https://github.com/snakers4/silero-vad) yang paling andal
    Silero berjalan dengan onnx-runtime dan wasm. Di Firefox memang berjalan sampai batas tertentu, tetapi VAD lebih sering bermasalah daripada yang diharapkan, sehingga angka latensinya jadi cukup aneh. Meski begitu saya benar-benar ingin membuatnya berfungsi dan masih terus mencoba
    Kode VAD UI ada di sini: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
  • Tidak perlu percaya begitu saja pada pesan peringatannya. Di Firefox terbaru, ini berjalan dengan baik. Demonya juga keren
  • Saya tidak suka semua orang hanya mengembangkan untuk Chromium
  • Sepertinya ada cukup banyak pengguna Firefox di HN
  • Berjalan sempurna di Firefox 127

• Benar-benar mengesankan
  Siri dari Apple masih hanya memungkinkan percakapan di level saling tumpang tindih, berhenti, gagal, lalu akhirnya membuat kita berharap mendapat jawaban seminimal mungkin