OpenAI büyük ölçekte düşük gecikmeli sesli yapay zekayı nasıl sunuyor

 (openai.com)
3 puan yazan GN⁺ 7 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • OpenAI, haftalık 900 milyondan fazla aktif kullanıcıya doğal sesli konuşma sunmak için standart WebRTC davranışını korurken dahili paket yönlendirmesini relay + transceiver yapısıyla yeniden tasarladı
  • WebRTC; ICE, DTLS/SRTP, codec uzlaşması, RTCP kalite kontrolü, yankı giderme ve jitter buffering’i standartlaştırarak tarayıcılar, mobil uygulamalar ve sunucular arasında düşük gecikmeli sürekli ses akışlarının işlenmesine uygun hale geliyor
  • OpenAI oturumlarının çoğu, bir kullanıcı ile bir modelin veya bir uygulama ile bir gerçek zamanlı ajanın konuştuğu 1:1 oturumlar olduğundan, çok taraflı çağrılara uygun SFU yerine transceiver modeli gecikme ve ölçeklenebilirlik açısından daha uygun bulundu
  • Kubernetes üzerinde oturum başına bir UDP portu açığa çıkaran WebRTC modeli; geniş açık port aralıkları, yük dengeleyici yapılandırmaları, health check’ler, güvenlik duvarı politikaları ve rollout güvenliğini karmaşık hale getirdiği için küçük ve sabit bir UDP yüzeyi gerektiriyordu
  • relay, ilk STUN paketindeki ICE ufrag içindeki yönlendirme ipucunu kullanarak sahibi olan transceiver’ı bulup paketi iletiyor; transceiver ise ICE, DTLS, SRTP ve oturum yaşam döngüsünü sahiplenerek hem standart WebRTC uyumluluğunu hem de dünya genelinde kullanıcıya yakın ingress yollarını koruyor

Düşük gecikmeli sesli yapay zekanın gereksinimleri

  • Sesli yapay zeka, konuşma insanın konuşma hızında aktığında doğal hissettirir; ağ gecikmesi ise garip sessizlikler, yarım kalan araya girmeler ve araya girme denemelerine geç tepki olarak hemen fark edilir
  • OpenAI ölçeğinde, haftalık 900 milyondan fazla aktif kullanıcı için küresel erişilebilirlik, oturum başlar başlamaz konuşabilmeyi sağlayan hızlı bağlantı kurulumu, düşük ve istikrarlı medya gidiş-dönüş süresi, düşük jitter ve paket kaybı gerekir
  • ChatGPT voice, Realtime API, konuşmalı iş akışlarındaki ajanlar ve kullanıcı konuşurken sesi işlemek zorunda olan modellerin tümü bu gecikme özelliklerinden etkilenir
  • OpenAI, istemcideki standart WebRTC davranışını korurken dahili paket yönlendirmesini değiştirmek için WebRTC yığınını relay + transceiver ayrımıyla yeniden tasarladı

Neden WebRTC seçildi

  • WebRTC; tarayıcılar, mobil uygulamalar ve sunucular arasında düşük gecikmeli ses, video ve veri göndermek için açık bir standarttır ve istemci-sunucu gerçek zamanlı sistemlerin temeli olarak da uygundur
  • WebRTC; ICE ile bağlantı kurulumu ve NAT geçişini, DTLS/SRTP ile şifreli aktarımı, codec uzlaşmasını, RTCP kalite kontrolünü, yankı giderme ve jitter buffering gibi istemci özelliklerini standartlaştırır
  • WebRTC olmasaydı, her istemcinin NAT ortamında bağlantı kurmayı, medya şifrelemeyi, codec uzlaşmasını ve ağ değişimlerine uyumu ayrı ayrı çözmesi gerekirdi
  • Yapay zeka ürünleri için kritik özellik, sesin sürekli bir akış halinde gelmesidir; böylece kullanıcının tüm yüklemesinin tamamlanması beklenmeden transkripsiyon, çıkarım, araç çağrıları ve ses üretimi başlatılabilir
  • Bu fark, bir sistemin gerçekten konuşmalı hissettirmesi ile push-to-talk gibi hissettirmesi arasındaki ayrımı belirler
  • OpenAI, olgun açık kaynak uygulamaları ve standartlaştırma çalışmalarını içeren WebRTC ekosistemini temel aldı; Justin Uberti ve Sean DuBois’nin oluşturduğu temel sayesinde düşük seviyeli taşıma, şifreleme ve tıkanıklık kontrolünü yeniden inşa etmeden, kendini kanıtlamış medya altyapısı üzerine kurulum yapabildi

SFU yerine transceiver seçilen mimari

  • SFU’nun uygun olduğu durumlar

    • SFU, her katılımcının WebRTC akışını alıp bunu diğer katılımcılara seçici olarak ileten bir medya sunucusudur
    • SFU modelinde her katılımcı için ayrı bir WebRTC bağlantısı sonlandırılır ve yapay zeka da oturuma başka bir katılımcı olarak katılır
    • Grup görüşmeleri, sınıflar ve ortak çalışma toplantıları gibi doğası gereği çok taraflı ürünler için SFU iyi bir tercih olabilir
    • Ses codec’leri, RTCP mesajları, veri kanalları, kayıt ve akış bazlı politikalar tek yerde toplanabilir
    • İstemciden yapay zekaya ürünlerde de sinyal işleme, medya yönlendirme, kayıt, gözlemlenebilirlik ve insana devretme ya da katılımcı ekleme gibi gelecekteki genişletmeler bir sistemde yeniden kullanılabildiği için doğal bir başlangıç noktası olabilir

  • OpenAI’nin iş yükü

    • OpenAI oturumlarının çoğu, bir kullanıcı ile bir modelin ya da bir uygulama ile bir gerçek zamanlı ajanın konuştuğu 1:1 oturumlardır
    • Bu trafik biçimi her turdaki gecikmeye duyarlı olduğu için transceiver modeli seçildi
    • transceiver modelinde WebRTC edge servisi istemci bağlantısını sonlandırdıktan sonra medya ve olayları; model çıkarımı, transkripsiyon, ses üretimi, araç kullanımı ve orkestrasyon için basit bir dahili protokole dönüştürür
    • transceiver, ICE bağlantı kontrolleri, DTLS el sıkışması, SRTP şifreleme anahtarları ve oturum yaşam döngüsü dahil olmak üzere WebRTC oturum durumunun sahibi olan tek servistir
    • Oturum durumunu tek yerde tutmak, oturum sahipliğini anlamayı kolaylaştırır ve arka uç servislerinin WebRTC eşi gibi davranmak zorunda kalmadan sıradan servisler gibi ölçeklenmesine imkan verir

İlk uygulama ve Kubernetes’te karşılaşılan kısıtlar

  • OpenAI’nin ilk uygulaması, sinyal işleme ile medya sonlandırmayı birlikte yapan Pion tabanlı tek bir Go servisiydi
  • Bu transceiver servisi, ChatGPT voice, Realtime API’nin WebRTC endpoint’i ve çeşitli araştırma projelerini çalıştırıyordu
  • Operasyonel olarak transceiver, signaling tarafında SDP uzlaşması, codec seçimi, ICE kimlik bilgileri ve oturum kurulumunu yönetiyordu
  • media tarafında ise aşağı akış yönündeki WebRTC bağlantısını sonlandırıyor, çıkarım ve orkestrasyon için backend servisleriyle yukarı akış bağlantısını koruyordu
  • OpenAI bu servisi, talep değişimlerine göre büyüyüp küçülebilen ve host’lar arasında taşınabilen Kubernetes üzerinde çalıştırmak istedi
  • Geleneksel oturum başına bir port WebRTC modeli Kubernetes ortamına uygun değildi ve geniş açık UDP port aralıklarının açığa çıkarılmasını, güvenliğinin sağlanmasını ve korunmasını gerektiriyordu
  • Yüksek eşzamanlılıkta oturum başına bir port kullanmak, çok geniş bir UDP port aralığının açığa çıkarılması ve yönetilmesi anlamına geliyordu
  • Bulut yük dengeleyicileri ve Kubernetes servisleri, servis başına on binlerce açık UDP portunu varsayacak şekilde tasarlanmamıştır; port aralığı büyüdükçe yük dengeleyici yapılandırmaları, health check’ler, güvenlik duvarı politikaları ve rollout güvenliği daha karmaşık hale gelir
  • Geniş UDP port aralıkları, dışarıdan erişilebilir yüzeyi artırdığı ve ağ politikası denetimini zorlaştırdığı için güvenlik açısından da elverişsizdir
  • Kubernetes’te pod’lar sürekli eklenip kaldırıldığı ve yeniden zamanlandığı için her pod’un büyük ve kararlı bir port aralığı ayırıp ilan etmesi gerekiyorsa elastikiyet kırılgan hale gelir

Tek port ve oturum sahipliği sorunu

  • Birçok WebRTC sistemi, port sayısı sorununu azaltmak için sunucu başına tek bir UDP portu ve uygulama seviyesinde çoklama kullanır
  • Sunucu başına tek port tasarımı port sayısını düşürür, ancak tüm fleet genelinde her oturumun sahipliğini koruma şeklinde ikinci bir sorun yaratır
  • ICE ve DTLS durum tutan protokoller olduğundan, oturumu oluşturan sürecin o oturuma ait paketleri almaya devam etmesi gerekir; ancak bu şekilde bağlantı kontrolleri doğrulanabilir, DTLS el sıkışması tamamlanabilir, SRTP çözülebilir ve ICE restart gibi sonraki oturum değişiklikleri işlenebilir
  • Aynı oturuma ait paketler farklı bir sürece ulaşırsa kurulum başarısız olabilir veya medya bozulabilir
  • OpenAI’nin hedefi, herkese açık internete yalnızca küçük ve sabit bir UDP yüzeyi açarken tüm paketleri ilgili WebRTC oturumunun sahibi olan transceiver’a yönlendirmekti

  • Değerlendirilen yaklaşımlar

    • Oturum başına benzersiz IP:port, doğrudan istemci-sunucu medya yolu sunar ve veri yolunda bir yönlendirme katmanı yoktur; ancak oturum başına bir açık UDP portu gerektirir ve geniş port aralıkları Kubernetes, bulut yük dengeleyicileri ve güvenlik gereksinimleriyle uyumlu değildir
    • Sunucu başına benzersiz IP:port, oturum başına açığa çıkarmaya göre çok daha küçük bir açık UDP footprint’i sunar ve tek paylaşımlı bir soket çok sayıda oturumu çoklayabilir; ancak paylaşımlı yük dengeleme yapılan tüm fleet genelinde ilk paket yanlış instance’a gidebilir, bu yüzden paketi oturumun sahibi olan sürece deterministik olarak iletmenin bir yolu gerekir
    • TURN relay, istemcinin yalnızca TURN relay adresine ve portuna erişebilmesini sağlar ve politikaları edge’de merkezileştirebilir; ancak TURN allocation ek kurulum gidiş-dönüşleri ekler ve allocation’ların TURN sunucuları arasında taşınması ya da kurtarılması hâlâ zordur
    • OpenAI’nin durumsuz forwarder + durumlu terminator yaklaşımı olan relay + transceiver yapısı, küçük bir açık UDP footprint’i korurken transceiver’ın tüm WebRTC oturumunun sahibi olmasını sağlar; ancak medya, sahibi olan transceiver’a ulaşmadan önce fazladan bir forwarding hop’tan geçer ve relay ile transceiver arasında özel koordinasyon gerektirir

relay + transceiver mimarisi

  • OpenAI’nin dağıttığı yapı, paket yönlendirme ile protokol sonlandırmayı ayırır
  • signaling, oturum kurulumu için transceiver’a ulaşır; medya ise önce relay’e gelir
  • relay, küçük bir açık footprint’e sahip hafif bir UDP forwarding katmanıdır; transceiver ise bunun arkasındaki durum tutan WebRTC endpoint’idir
  • relay medyayı çözmez, ICE durum makinesini çalıştırmaz ve codec uzlaşmasına katılmaz
  • relay yalnızca hedefi seçmeye yetecek kadar paket metadata’sını okur ve paketi oturumun sahibi olan transceiver’a iletir
  • transceiver hâlâ normal bir WebRTC akışı görür ve tüm protokol durumunun sahibi olmaya devam eder
  • İstemci açısından bakıldığında WebRTC oturumu değişmez

İlk paketin yönlendirilmesi ve ICE ufrag’in kullanımı

  • Bu yapının anahtarı, relay’in paket yolunun üzerinde ilk istemci paketini doğrudan yönlendirmesidir
  • WebRTC oturumlarında zaten protokole yerleşik bir yönlendirme kancası vardır; bu da ICE username fragment, yani ufrag’dir
  • ufrag, oturum kurulumu sırasında değiş tokuş edilen ve STUN bağlantı kontrollerinde yeniden taşınan kısa bir tanımlayıcıdır
  • OpenAI, sunucu tarafı ufrag’i relay’in hedef cluster’ı ve sahibi olan transceiver’ı çıkarabilmesine yetecek yönlendirme metadata’sını içerecek şekilde üretir
  • signaling sırasında transceiver oturum durumunu ayırır ve SDP answer içinde paylaşılan relay VIP’ini ve UDP portunu döndürür
  • VIP, relay fleet’inin önündeki sanal IP adresidir ve port ile birlikte, çok sayıda relay instance’ının arkasında olsa bile istemciye 203.0.113.10:3478 gibi tek ve kararlı bir hedef sunar
  • İstemcinin medya yolundaki ilk paketi genellikle bir STUN binding request’tir ve ICE bunu, paketin ilan edilen adrese ulaşıp ulaşamadığını doğrulamak için kullanır
  • relay, ilk STUN paketinden sunucu ufrag’ini okur, yönlendirme ipucunu çözer ve paketi oturumun sahibi olan transceiver’a iletecek kadar parse eder
  • Her transceiver, oturum başına bir soketten değil, dahili bir IP:port’a bağlı işletim sistemi endpoint’i olan paylaşımlı bir UDP soketi üzerinden alım yapar
  • relay, istemcinin kaynak IP:port’undan transceiver hedefinə giden bir oturum oluşturduktan sonra sonraki DTLS, RTP ve RTCP paketleri, ufrag yeniden çözülmeden bu oturum içinde akar
  • relay’in oturumu, paket iletimi için bellekte tutulan bir oturum, izleme sayaçları ve oturumun zaman aşımı ile temizliği için sayaç/zamanlayıcı gibi minimum durumla sınırlı tutulur
  • relay yeniden başlatılıp oturumları kaybetse bile sonraki STUN paketi, ufrag yönlendirme ipucuyla oturumu yeniden oluşturur
  • Yol kurulduktan sonra Redis cache, <client IP + Port, transceiver IP + Port> eşlemesini tutar; böylece bir sonraki STUN paketi gelmeden önce daha hızlı kurtarma mümkün olur

Global Relay ve kullanıcıya yakın giriş yolu

  • Açık UDP yüzeyi küçük ve sabit sayıda adres/port’a indirgendikten sonra OpenAI aynı relay desenini dünya genelinde dağıtabildi
  • Global Relay, aynı paket iletme davranışını uygulayan, coğrafi olarak dağıtılmış bir relay ingress point fleet’idir
  • Geniş coğrafi ingress, kullanıcının paketlerinin önce ortak internet üzerinden uzak bir region’a gitmek yerine, coğrafi konum ve ağ topolojisi açısından daha yakın bir relay’den OpenAI ağına girmesini sağlayarak ilk istemci-OpenAI sıçramasını kısaltır
  • Bu yaklaşım, trafiğin backbone’a ulaşmadan önce yaşadığı gecikmeyi, jitter’ı ve kaçınılabilir kayıp patlamalarını azaltır
  • OpenAI, signaling için Cloudflare geo ve proximity steering kullanarak ilk HTTP veya WebSocket isteğinin yakındaki bir transceiver cluster’ına ulaşmasını sağlar
  • İstek bağlamı, oturumun yerini ve istemciye ilan edilecek Global Relay ingress point’ini belirler
  • SDP answer, Global Relay adresini verir; ufrag ise Global Relay’in medyayı belirlenen cluster’a, relay’in de hedef transceiver’a yönlendirmesine yetecek bilgiyi taşır
  • Geo yönlendirmeli signaling ile Global Relay birlikte kullanıldığında hem kurulum hem de medya kullanıcıya yakın giriş yoluna yerleştirilirken oturum tek bir transceiver’a sabitlenir
  • Bu yapı, signaling ile ilk ICE bağlantı kontrolü için gereken gidiş-dönüş süresini azaltır ve böylece kullanıcının konuşmaya başlamadan önce beklediği süreyi doğrudan kısaltır

relay’in nasıl uygulandığı

  • relay servisi Go ile yazıldı ve kapsamı bilinçli olarak dar tutuldu
  • Linux’ta kernel ağ yığını, UDP paketlerini ağ arayüzünden alıp sokete iletir; relay ise userspace’te çalışan sıradan bir Go süreci olarak soketten paket başlıklarını okur
  • relay, az miktarda akış durumunu günceller ve WebRTC’yi sonlandırmadan paketi iletir
  • OpenAI, userspace sürecinin daha yüksek paket oranı için ağ kuyruğunu doğrudan poll ettiği bir kernel-bypass framework kullanmadı; bunun operasyonel karmaşıklığı artırabileceğini değerlendirdi

  • Temel tasarım tercihleri

    • Protokol sonlandırma yok: relay yalnızca STUN header’ını ve ufrag’i parse eder; sonrasında DTLS, RTP ve RTCP için cache’lenmiş durum kullanarak paketleri opak halde tutar
    • Geçici durum: akış durumu ve gözlemlenebilirlik için istemci adresinden transceiver hedefine giden küçük, kısa zaman aşımına sahip bellekiçi bir map tutulur
    • Yatay ölçeklenebilirlik: birden çok relay instance’ı yük dengeleyicinin arkasında paralel çalışır; relay durumu kritik WebRTC durumu olmadığından yeniden başlatmalarda trafik kaybı düşük olur ve akış kurtarma hızlı gerçekleşir

  • Verimlilik önlemleri

    • SO_REUSEPORT, birden çok relay worker’ının aynı makinede aynı UDP portuna bağlanmasına izin veren bir Linux socket seçeneğidir; kernel gelen paketleri worker’lar arasında dağıtarak tek bir read loop darboğazını önler
    • runtime.LockOSThread, her UDP okuyan goroutine’i belirli bir OS thread’ine sabitler
    • SO_REUSEPORT ile thread pinning birlikte kullanıldığında aynı akışın paketleri aynı CPU çekirdeğinde kalma eğilimindedir; bu da cache locality’yi iyileştirir ve context switching’i azaltır
    • önceden ayrılmış buffer’lar ve minimum kopyalama, parse ve allocation maliyetini düşürerek Go’nun garbage collection yükünü azaltmaya yardımcı olur
    • Bu uygulama, nispeten küçük bir relay footprint’iyle OpenAI’nin küresel gerçek zamanlı medya trafiğini işlediği için OpenAI kernel bypass yolunu seçmeyip daha basit tasarımı korudu

Sonuçlar ve çıkarımlar

  • Bu mimari, binlerce UDP portunu açığa çıkarmadan Kubernetes üzerinde WebRTC medyasını çalıştırmayı mümkün kılıyor
  • Küçük ve sabit bir UDP yüzeyi, güvenliği ve yük dengelemeyi kolaylaştırıyor; ayrıca altyapının büyük açık port aralıkları ayırmadan ölçeklenmesini sağlıyor
  • Bu tasarım, istemcinin standart WebRTC davranışını koruyor ve OpenAI iş yükünde SFU’suz bir tasarımın varsayılan olarak uygun olduğunu doğruluyor
  • Oturumların çoğu point-to-point, gecikmeye duyarlı ve çıkarım servislerinin WebRTC eşi gibi davranmaması durumunda daha kolay ölçekleniyor
  • Karmaşıklığın tüm backend servislerine ya da özel istemci davranışına değil, ince bir yönlendirme katmanına yerleştirilmesi daha uygun bulundu
  • Protokole yerleşik bir alanda yönlendirme metadata’sı encode edilerek deterministik ilk paket yönlendirmesi, küçük bir açık UDP footprint’i ve dünya genelinde kullanıcıya yakın ingress yerleşimi için esneklik elde edildi

  • Özellikle önemli olan tercihler

    • Edge’de protokol semantiğini korumak: istemci standart WebRTC kullanmaya devam ettiği için tarayıcı ve mobil uyumluluk korunuyor
    • Zor oturum durumunu tek yerde tutmak: transceiver, ICE, DTLS, SRTP ve oturum yaşam döngüsünün sahibi; relay ise yalnızca paket iletiyor
    • Yönlendirme için kurulumda zaten mevcut olan bilgiyi kullanmak: ICE ufrag, hot-path lookup bağımlılığı olmadan ilk paket yönlendirmesi için bir kanca sağlıyor
    • Kernel bypass yerine yaygın senaryoyu optimize etmeye öncelik vermek: SO_REUSEPORT, thread pinning ve düşük allocation’lı parse işlemlerini dikkatli kullanan dar kapsamlı bir Go uygulaması OpenAI’nin iş yükü için yeterli oldu
    • Gerçek zamanlı sesli yapay zeka, altyapı gecikmeyi hissedilmez hale getirdiğinde çalışır; OpenAI de istemcinin WebRTC’den beklediği davranışı değiştirmeden, WebRTC’nin dağıtım biçimini değiştirmeyi seçti

İlgili okumalar

1 yorum

 
GN⁺ 7 시간 전
Hacker News yorumları

  • OpenAI'nin benim üzerinde çalıştığım Pion kütüphanesinin kullanım örneğini yayımlamış olmasına çok sevindim
    WebRTC'yi çok iyi bilmiyorsanız oldukça ilginç bir alan; ayrıca nasıl çalıştığını anlatan WebRTC for the Curious adlı bir kitap üzerinde de çalışıyorum
    https://github.com/pion/webrtc
    https://webrtcforthecurious.com

    • Pion kullanıyorum. Ama OpenAI'nin yaklaşımının gerçekten gerekli olup olmadığını merak ediyorum
      Sesli yapay zeka kurgusunda zaten hızlı sayılan kısmı kısaltmak için karmaşıklığı aşırı artırmış gibi görünüyor. Hızlı bir model ve doğru ses etkinliği algılama (VAD), WebRTC aktarım süresini ince ayarlamaktan çok daha önemli gibi duruyor
    • Kitabın tamamını internete koyduğunuz için teşekkürler
      Eskiden WebRTC veri kanalıyla veritabanından tarayıcı istemcisine CLI üzerinden veri gönderme fikrim vardı; bu yüzden bir kısmını okudum ve kullanım amacım için pek uygun olmadığını anladım. Sonunda merkezi bir kontrol düzlemi ve WebSocket kullandım
      Yine de WebRTC veri kanalı + kopyasız Apache Arrow ArrayBuffer + duckdb WASM birleşimiyle eğlenceli bir şeyler yapılabilir gibi geliyor ama henüz ne olacağını bulamadım
    • Konu biraz farklı ama tüm kod tabanını iç içe src klasörleri yerine kök dizine koymanızın nedenini merak ediyorum
      README'ye gitmek çok daha zorlaşıyor

  • Düşük gecikme, uygulama açısından bir avantajdan çok bir eziyet gibi
    Rahat rahat konuşmaya çalışınca insan doğal olarak kısa duraklamalar veriyor ama GPT bunu “konuşma bitti” diye algılayıp hemen konuşmaya başlıyor
    Yaş aldıkça istediğim kelimeyi bulmam daha uzun sürüyor ve böyle hızlı sesli GPT'ler yardım etmekten çok sinir bozuyor. Konuşmadan önce tüm cümleyi kafamda tamamen kurmuş olmam gerekiyor; bu da hiç doğal hissettirmiyor

    • Burada birbirine karışan iki farklı gecikme katmanı var
      Yazıda sözü edilen gecikme, ses akışının iletim gecikmesi; bu durumdaki gecikme ise ses akışı içinde ne kadar hızlı yanıt vermeye başladığıyla daha ilgili
    • Ben de yaşadım ve gerçekten sinir bozucu
      Düşüncem daha bitmemişken bile konuşmaya devam etmem gerekiyormuş gibi bir baskı yaratıyor, bu da oldukça yapay hissettiriyor. Uygun kelimeyi arıyorsam onu bulmak için fırsata ihtiyacım var
      Çözümün daha yüksek gecikmeli bir protokol değil, duraklamaları daha akıllıca ele almak olduğunu düşünüyorum. Gecikme düşük olursa kullanıcı araya girdiğinde bot hemen susabilir
    • Sesli konuşmalarda, belirli bir kod sözcüğü kullanana kadar hiç yanıt vermemesini ya da sadece “anlaşıldı” demesini söylüyorum
      Kusursuz değil ama daha az araya giriyor
    • Bu, yazıda bahsedilen gecikmeden çok ses etkinliği algılama (VAD) ile ilgili
    • Zor bir problem. Botun çeneye vurmaması için fark etmeden ben de dolgu ifadeleri ekliyorum
      Ayrıca çoğu zaman zekasının büyük bölümünü problemi düşünmeye değil, kulağa makul gelmeye harcıyor gibi. “Evet, elbette. Bunu neden istediğinizi anlıyorum…” gibi. Muhtemelen zaman kısıtı var ve ses işleme daha pahalı. Metin yanıtları asıl göreve daha fazla zaman ayırıyor

  • “Haftalık aktif kullanıcı sayısı 900 milyondan fazla” ifadesi muhtemelen ChatGPT'nin toplam kullanıcı tabanını anlatıyor; bunun içinde ses özelliğini kullanan oran çok daha küçük olsa gerek
    Bu tür rakamlar, probleme ne kadar donanım ve yazılım optimizasyonu ayıracakları gibi iş kararlarını etkiler

    • Evet. Bu yüzden sanırım “reach” ifadesini kullanmışlar
      Gerçek kullanım olup olmamasından bağımsız olarak, özellikle karşılaşabilecek toplam kullanıcı sayısını ifade ediyor

  • Paylaşmaları gerçekten sevindirici ama OpenAI'nin gerçek zamanlı ses modelinin yetenek açısından hâlâ 4o ailesi seviyesinde kaldığını unutmamak lazım
    Buna rağmen hâlâ çok kullanışlı ve bu alanda ciddi bir rakibin olmaması üzücü. Gerçek konuşma hissi veren deneyim, fikirleri ve kavramları ifade etmede çok yardımcı oldu
    Çıktığı zamandaki gibi artık en ileri model değil; bunu akılda tutmakta fayda var. Sam bunu görürse keşke yeni bir gerçek zamanlı ses modeli çıkarsa

    • OpenAI'nin realtime/voice mode'unda ses tarafı harika ama en yeni modellere kıyasla epey aptal kalıyor ve bazen aynı şeyi tekrar ediyor
      Google'ın Gemini flash live 3.1'i daha iyi; özellikle API üzerinden kullanınca. Araç çağırabiliyor, kendi kurulumunuzu yaparsanız daha akıllı başka LLM'lere de bağlanabiliyor ve akıl yürütme düzeyi ayarlanabiliyor. Yüksek akıl yürütme düzeyleri bile gerçek zamana yeterince yakın ve yanıtlar Google Arama ile güçlendirilebiliyor. Çift yönlü sesi seviyorsanız şu anda muhtemelen en iyi seçenek ve AI Studio'da deneyebilirsiniz

  • Bu alana girmek isteyenler için pipecat iyi bir açık kaynak deposu ve topluluk
    https://github.com/pipecat-ai/pipecat

  • Daha iyi modeller daha çok düşünüp sonra yanıt veriyorsa, yanıt için daha uzun beklemek benim için sorun değil
    Yeter ki araya girmeyi iyi desteklesin, 1 saniye durdum diye hemen yanıtlamaya başlamasın ve konuşmamın bitip bitmediğini akıllıca anlayabilsin

  • Bu, sadece gecikmeyle ilgili bir mesele olmayabilir
    Kullanıcıyı sesli sohbet içinde tutarsanız, metinde asla elde edemeyeceğiniz eğitim verileri toplayabilirsiniz. Bu yüzden mi SFU yerine transceiver yaklaşımını seçtiler ve çok taraflı konuşmaları büyük ölçüde görmezden gelmeyi kabul ettiler diye düşünüyorum

  • Bunu, OpenAI'nin artık WebRTC/ses tarafında LiveKit kullanmadığı şeklinde mi okumalıyım?

    • Öyle görünüyor
      Bu mimaride LiveKit sunucusu muhtemelen istedikleri yapıya pek uymuyor. Yazıdaki SFU tartışması da aslında bunu söylüyor. Yine de istemci SDK'sında yararlı çok şey var

  • Akış sırasında transceiver çökerse aktif oturumlar nasıl kurtarılır?
    Sistem, yeni bir WebRTC oturumunda bağlamı otomatik olarak yeniden kuruyor mu?

  • Arkadaş edinmek istiyorsanız, herhangi bir biçimde bir kulübe ya da topluluğa katılmanın daha iyi olduğunu düşünüyorum