Show HN: 500 ms yanıt süreli sesli bot

• Sesli yapay zekanın doğal hissettirmesi için normal bir konuşma gibi anında tepki vermesi gerekir; bu nedenle bu demo 500 ms sesten sese yanıtı hedefliyor
• Temel mesele, kullanıcının hissettiği gecikmeyi azaltmak; bunda hem ağ hem de model işleme süreleri etkili
• Demo, optimizasyon ve dağıtım yöntemleriyle düşük gecikmeli LLM etkileşiminin ne kadar ileri götürülebileceğini gösteriyor
• Uygulamada, sesli ve çok modlu konuşma tabanlı yapay zeka için açık kaynak çerçeve Pipecat kullanılıyor
• Gerçek ürün seviyesinde konuşma tabanlı bir sesli bot yapmak için yalnızca model performansı değil, tüm çağrı yolundaki gecikmenin yönetimi de önemli

---

500 ms sesli yanıtı hedefleyen demo

• The World's Fastest Voice Bot Demo, ses tabanlı bir yapay zeka sohbet botunun ne kadar hızlı tepki verebildiğini gösteren bir demo
• Hedef, 500 ms sesten sese yanıt süresine ulaşmak
• İnsanlar normal konuşmalarda hızlı yanıt beklediğinden, sesli yapay zeka arayüzlerinde hız temel bir kalite unsuru haline geliyor

Gecikmeyi azaltmaya yönelik uygulama yaklaşımı

• Demo, düşük gecikmeli LLM etkileşimi etrafında kurgulanmış
• Ağ gecikmesini ve model gecikmesini en aza indirecek şekilde optimize edilmiş ve dağıtılmış bir sesli yapay zeka sohbet botunun neler sunabileceğini gösteriyor
• Bot, Pipecat ile yapılmış
  • Pipecat, sesli ve çok modlu konuşma tabanlı yapay zeka için açık kaynak bir çerçeve

[GN⁺]

Hacker News yorumları

• Gerçekten hızlı. Harika ve tertemiz. Hızın her şeyi yendiği hissi var. Robotik sesi ancak yorumları okuduktan sonra fark ettim.
  Müşteri desteği için bir yapay zeka yapmıştım; ortalama yanıt süresi 24–48 saatten birkaç saniyeye düştü.
  Bir müşteriye “Hello Bitch, your package will be picked up by USPS today...” gibi bir mesaj gitmişti; müşteri “thank you so much” diye yanıtladı ve CSAT’te tam puan verdi. Bu kadar ciddi bir hata yapılsa bile hız her şeyi yeniyor.

  • Herkesin böyle tepki vereceğini sanmıyorum. Bazı insanlar için birbirine bitch demek gündelik bir konuşma tarzı olduğundan eğitim verisine girmiş olabilir; ama başkaları için hiç de öyle olmayabilir.
  • Komik olan, bu sorunu bir #profanity etiketi ekleyip mesajı bir sonraki temsilciye devrederek çözmüş olmaları.
    Ama en aktif satış mühendisi artık potansiyel müşterilere demo yapamaz hale geldi. Yapay zekanın hiçbir yanıt vermediği pek çok utanç verici arama oldu; çünkü soyadı Dick’ti.
  • Çözüm, mesajı başka bir LLM’den geçirip küfürleri temizlemek ve mümkün olduğunca kibar hale getirmek olabilir. Yalnız çalıştırma maliyeti iki kattan fazla artar gibi.
  • Belki de müşterinin adı buydu. En azından müşterinin öyle girdiği isim olabilir.

• Gerçekten çok çok iyi. Doğru anladıysam Cerebrium’u göstermek için yapılmış bir teaser uygulama gibi görünüyor, ama killer app potansiyeli yüksek. iPad’de test ettiğimde bildirilen gecikme 1400 ms ile 400 ms arasındaydı; alt tarafta çok akıcı hissettirdi.
  Bu hızla, bazı sohbet iş akışlarında çok aşamalı bir yaklaşım gerekebilir ya da mümkün hale gelebilir. Önce hızlı bir yanıt verilirken daha uzun veri/bilgi/RAG sorguları ayrı çalıştırılır, ardından bilgi içeren sonuç devralır.
  İnsanlar da böyle çalışır. Yanıtlamaya başlarken düşüncelerimizi toparlamak için çeşitli dolgu ifadeleri kullanırız.
  Şu anda çoğu şey tek seferde prompt atmak ya da arka planda ayrıştırma→sorgu→üretim yapmak şeklinde; ama düşük gecikmeli yanıt mümkün hale gelirse daha iyi akış kabaca “[kulağa 3 saniyelik Llama 8B] → sorgu → [sorgu sonucunu yansıtan 55 saniyelik Llama 70B/GPT-4 vb.]” gibi olur diye düşünüyorum.

  • Cerebrium tarafındayım. Geri bildirim için gerçekten teşekkürler; iyi bir deneyim yaşamanıza sevindim.
    Bu uygulama kolayca genişletilebilir veya uygulanabilir, bu yüzden istediğiniz şekilde değiştirebilirsiniz. Başka LLM, konuşma tanıma, konuşma sentezi modellerine geçebilir; prompt’u değiştirebilir ve RAG gibi şeyler de uygulayabilirsiniz.
    Daily ile birlikte odağı mühendislere verdik. Kullanım senaryosuna ve tercihlere göre uygulamayı çok esnek biçimde değiştirilebilir kılarken, sıkıcı altyapı kurulumunu azaltmak istedik.
    Genişletme yollarını burada daha fazla görebilirsiniz: https://docs.cerebrium.ai/v4/examples/realtime-voice-agents
  • Ben de bunu merak ediyordum. Gerçek iş yükünün tamamını çalıştırmadan genel görev karmaşıklığını tahmin edebilen küçük ve verimli bir LLM mümkün mü?
    Karmaşıklık sürekli bir değer olarak puanlanabilirse, uzun bir gidiş-dönüşü beklemek yerine önce “Evet, bir saniye. Bakıyorum” gibi bir yanıt gönderip göndermemek gerektiğini anlayabiliriz.

• Platformlar arası tarayıcılar için ses etkinliği algılama modülü olarak https://github.com/ricky0123/vad var. Silero’nun VAD ağının ONNX’e port edilmiş hali. Platformlar arası derken Firefox’ta da çalıştığı kastediliyor. WebRTC oturumu olmadan yalnızca mikrofon erişimi yeterli olduğu için daha basit. Tarayıcıların bunu yerel bir seçenek olarak sunması da ilginç olurdu.
  Tarayıcı tabanlı metinden sese dönüştürme motorları da var; giderek daha hızlı ve kaliteli hale geliyorlar. Tarayıcıda harika bir TTS’in varsayılan olarak yerleşik gelmesi iyi olurdu.
  GPT-4o, düşük gecikme için otomatik konuşma tanımayı, anlamayı ve sesli yanıt üretimini tek bir modele koydu; oldukça iyi bir fikir gibi görünüyor. Henüz yayınlanmamış olmasına bakılırsa bir şekilde ölçeklenebilirlik ya da kalite sorunları var gibi.
  Benzer şekilde, ses girişi/çıkışı ve görsel girişi de olan açık birleşik multimodal büyük dil modelleri yapan insanlar da olacaktır.
  Gecikme ve maliyet optimizasyonu açısından tek birleşik modelin ne kadar gerekli ve optimal olduğunu merak ediyorum.
  Verilen ayrıştırma tablosu ilginç. Mümkünse ses üretimini, hatta belki baştaki konuşma yazıya dökümünü ya da konuşma anlamayı da daha fazla model olarak cihaz içinde çalıştırmak iyi görünüyor. Kim STUN beklemek ister ki?

  • Masaüstü ortamlarının standart bir arayüze sahip bir servis olarak konuşmadan metne dönüştürme sunması gerektiğini düşünüyorum. stdin’e benzer ama ses için ayrı bir arayüz gibi.
    Uygulamalar varsayılan olarak dinlemede olmadığı için bunu yok sayar; ama transkripsiyon aracı değiştirilebilir olur ve tüm uygulamalarda kullanılabilir.
  • Bu rakamlara göre, konuşma tanıma ve konuşma sentezi cihazda işlense bile geri kalan her şey aynı kalırsa yalnızca 120 ms azalıyor. Kalan 639 ms donanım/ağ gecikmesine ve veriyi LLM’in içine ve dışına taşımaya gidiyor. Yine de istenenden yavaş.
    Mantıken fonem düzeyinde düşünmek gerekiyor. LLM çıktısı son fonemi yeterince hızlı yakalamalı ki bitiş noktası algılandığı anda “anında” yanıt verebilsin; bunun için tüm zincirin uçtan uca gecikmesinin kabaca 200 ms civarında olması gerekir.
    Buna yaklaşmak için farklı bir mimari gerekecek gibi. İnsanların konuşma işlemesine benzer şekilde, gelmeden önce tahmin edilen fonemlere dayanarak ses akışının önünden gitmek ve gerçekten alınan sesi yalnızca mevcut çıktı arabelleğinin boşaltılıp boşaltılmayacağına ya da yeniden işlenip işlenmeyeceğine karar veren hafif bir doğrulama sinyali olarak kullanmak.
    Spekülatif decoding ile bir yere kadar gidilebilir, ama ses/metin karışık bir pipeline ile zor görünüyor. En başta sesi metne çevirip tekrar sese döndürmemek çok daha iyi.
  • Bu duyuru benim yapmakta olduğum şeyi tamamen gölgede bırakmış olsa da rick0123/VAD ve WebSocket kullanan basit bir asistan uygulamam var.
    https://github.com/charlesyu108/voiceai-js-starter

• Doğrudan denedim, eğlenceliydi. Bu haftanın başında june-va’yı denemiştim; uzun yanıt süresi kullanılabilirliği epey düşürüyordu. Hızlı yanıt harika bir özellik ve bu çok daha fazla sohbet gibi hissettiriyor
  Komik olan, ondan bir hikâye anlatmasını istediğimde her seferinde yalnızca bir cümleyle yanıt verdi; sonraki satırı duymak için “yes”, “aha”, “please continue” demem gerekti
  Sonra şöyle bir konuşma yaptık. “Ah, sanırım sırrını çözdüm!” “Lütfen söyleyin” “Kısa yanıt sürelerine ulaşmak için kısa bağlam tutuyorsun” “Tam olarak doğru”

  • Açıkçası bu yaklaşım iyi. Kısa bağlamdan ziyade kısa yanıtlar kesinlikle iyi. Şu an ChatGPT ses modu, bir şey sorduğunuzda size 1 dakikalık GPT tarzı uzun bir nutuk dinletiyor; bununla tezat oluşturuyor

• Çok etkileyici. Aşırı hızlı, belki fazla hızlı bile; ama sanırım asıl mesele de bu. En etkileyici olan, VAD ve araya girme işlemenin nasıl ayarlandığı. Şimdiye kadar bir ajanla yaptığım konuşmalar içinde açık ara en doğal duyulanıydı. Yayına açıldığında mutlaka denemek isterim

• Pazarlamada 500 yazıyor ama hesap 759 çıkıyor

  • Buna pazarlama deniyor
  • Benim testimde 1400 ms’lik bir aykırı değer vardı; yaklaşık 10 denemede ise 400–500 ms arasındaydı. Pazarlama rakamı adil görünüyordu
  • 500, transkripsiyon/LLM/TTS aşamaları; yani verinin sunucuya ulaşmasından yanıtın geri gönderilmesine kadar geçen süre. Geri kalanı kodlama, ağ trafiği gibi çeşitli yapay zeka dışı ek gecikmeler gibi görünüyor
  • Tablodaki gecikme süreleri gözlemlenen sezgisel ölçümlere veya ortalamalara dayanıyor. Gerçekte, konuşmaya bağlı olarak daha büyük gecikme bileşenlerinden bazıları çok daha düşük olabilir

• Ben de sesli çıkarım konusunda heyecanlıyım. OpenAI’ın GPT-4o lansmanından önce WebSocket tabanlı kendi Faster Whisper uygulamamı yapmıştım. Mülakat koçu konseptim https://intervu.trueforma.ai ve satış sunumu koçu https://sales.trueforma.ai uygulamalarım onların gölgesinde kaldı
  VAD’yi kararlı çalıştıramadığım için varsayılanı bas-konuş olarak bıraktım. Hepsini LattePanda üzerinde çalıştırıyorum. Groq’un barındırılan Whisper’ını bağlamaya çalışıyordum
  Sıkıcı kurumsal konuşmalardan bıktığım için LLM olarak Groq’un sansürsüz Llama3’ünü kullanma fikri hoşuma gidiyor. Gecikmeyi azaltmak ve örneklerden öğrenmek istiyorum. Demoyu da denemek istiyorum ama çok yoğunluk var gibi; botla sohbete giremiyorum
  Aynı anda 3 kişi bile çıkarım denemeye kalksa LattePanda’m eriyip gider gibi

• Ben şahsen https://github.com/foges/whisper-dictation’ı Groq’un llama-70b’siyle birlikte kullanıyorum
  Konuşmaya başlayıp web sitesine giderek yüklemenin bitmesinden sonra llama-70b’yi seçtiğim zamana kadar konuşmam da bitmiş oluyor; bu yüzden ek bekleme süresi 0. Dinlemekten çok daha hızlı okuduğum için bana kusursuz uyuyor

• Hâlâ Firefox kullanıyorum

  • Bu istemci UI’ını ben yaptım ve gerçekten Firefox desteği vermek istiyordum
    Son kullanıcı perspektifinden ses-ses gecikmesini ölçmenin bir yoluna ihtiyacımız vardı; kullanıcının konuşmayı bıraktığı anı algılayıp zamanlayıcıyı başlatmak ve bottan ses geldiğinde durdurmak için Silero ses etkinliği algılamasının (https://github.com/snakers4/silero-vad) en güvenilir seçenek olduğunu düşündüm
    Silero, onnx-runtime ve wasm ile çalışıyor. Firefox’ta da bir ölçüde çalışıyor ama VAD beklediğimizden daha sık hatalı davrandığı için gecikme rakamları epey tuhaflaşıyor. Yine de mutlaka çalışır hâle getirmek istiyorum ve hâlâ deniyorum
    UI VAD kodu burada: https://github.com/pipecat-ai/web-client-ui/tree/main/src/va...
  • Sadece uyarı mesajına güvenmek zorunda değilsiniz. Güncel Firefox’ta iyi çalışıyor. Demo da harika
  • Herkesin yalnızca Chromium’u hedefleyerek geliştirme yapmasından hoşlanmıyorum
  • HN’de Firefox kullanan epey kişi vardır diye düşünüyorum
  • Firefox 127’de kusursuz çalışıyor

• Gerçekten etkileyici
  Apple’ın Siri’si hâlâ ancak sözlerin üst üste bindiği, durduğu, başarısız olduğu ve sonunda yalnızca asgari bir yanıt almayı umduğunuz türden konuşmalar yaptırabiliyor