AssemblyAI, kendi VAD sistemini kullanan ekiplere senkron HTTP transkripsiyonu sundu

AssemblyAI, konuşma sonunu kendi ses etkinliği algılama (VAD) sistemiyle belirleyen sesli asistan ekiplerine senkron HTTP transkripsiyon yöntemini sundu. Kullanıcı konuşmasını bitirince ses parçası gönderiliyor ve transkripsiyon aynı HTTP yanıtında dönüyor.

AssemblyAI, 26'sında yayımladığı teknik yazıda Sync yönteminin kendi VAD sistemini ve konuşma akışı yönetimini kullanan ekiplere uygun olduğunu açıkladı. Şirket, birden fazla büyük sesli asistan geliştirme ekibinin bu tür bir API talep ettiğini belirtti; ancak ekiplerin adlarını veya yöntemin kullanım sonuçlarını paylaşmadı.

Bu yöntemde ekibin VAD sistemi konuşmanın başlangıç ve bitişini algılayarak sesi topluyor. Tamamlanan ses parçası Sync API'ye gönderiliyor ve ayrı bir sonuç sorgusu gerekmeksizin tek yanıtla transkripsiyon alınıyor. Ardından metin büyük dil modeline (LLM), oluşturulan yanıt da metinden konuşmaya (TTS) aktarılıyor.

İstek ve yanıt temelli bu yapı, görüşme boyunca konuşma tanıma (STT) için WebSocket bağlantısını açık tutma gereğini ortadan kaldırıyor. Ancak ses dosyası ancak konuşma bittikten sonra gönderilebildiği için işlem akışı, konuşma sürerken transkripsiyon almaktan farklı.

Sync, konuşma sırasında kısmi transkripsiyon sunmuyor. Bu nedenle kısmi metne dayanarak LLM işlemini erkenden başlatmak isteyen ekipler için gerçek zamanlı akışla arasında bir fark bulunuyor.

Konuşmanın bittiğini algılama hatalı olursa cümlenin sonu kesilebilir veya ses parçasına gereksiz sessizlik girebilir. Konuşma sınırlarını ve kullanıcı sözünü kesme durumlarını da geliştirme ekibinin yönetmesi gerekiyor.

Gerçek zamanlı akışta ses WebSocket üzerinden kesintisiz gönderiliyor ve konuşma bitmeden kısmi transkripsiyon iletiliyor. AssemblyAI, gerçek zamanlı STT kılavuzunda, kısmi transkripsiyona ihtiyaç duyan veya konuşma sonunu STT sisteminin algılamasını isteyen sesli asistanlar için Universal-3.6 Pro Realtime modelini öneriyor.

Sync belgelerinde varsayılan model olarak Universal-3.5 Pro belirtiliyor. Bu sürüm, gerçek zamanlı akış için önerilen Universal-3.6 Pro Realtime modelinden farklı.

Bu nedenle iki yöntemi karşılaştırırken yalnızca iletişim biçimini değil, model farkını da göz önünde bulundurmak gerekiyor. Sync, kendi VAD ve konuşma akışı yönetim sistemini kullanıp her konuşma parçası için ayrı istek göndermek isteyen ekiplere yönelik bir seçenek olarak sunuldu.

Sync STT belgeleri, tamamlanmış bir ses dosyasını tek seferde yazıya dökme yöntemiyle konuşma sırasında sözcükleri gerçek zamanlı alma akışını birbirinden ayırıyor. Kısa sesli komutlar veya önceden kaydedilmiş konuşmalar işlenirken Sync ile konuşma bittikten sonra transkripsiyon alınabiliyor.

İşlem süresine ilişkin rakamları ölçüm aralıklarına göre değerlendirmek gerekiyor. AssemblyAI, ABD ve Avrupa'da Sync için medyan (P50) işlem süresini yaklaşık 134 milisaniye olarak paylaştı. Bu değer yalnızca sunucu işlem süresini kapsıyor.

Şirketin ayrı bir teknik açıklamasında, Singapur'da yaklaşık 15 saniyelik bir kayıtla yapılan demoda toplam yanıt süresinin yaklaşık 1.900 milisaniye olduğu belirtildi. Bu ölçüm sesin gönderilmesi ve yanıtın alınmasını da kapsadığı için önceki işlem süresinden farklı bir aralığı ifade ediyor. LLM yanıtının oluşturulması ve TTS çıktısının oynatılması dahil, sesli asistanın toplam yanıt süresi bu rakama dahil değil.

LiveKit'in AssemblyAI entegrasyon belgeleri, Universal-3.6 Pro akış modelinin sesli asistanlara nasıl bağlanacağını anlatıyor. Belge, akış entegrasyon yolunu gösteriyor; Sync yönteminin ne ölçüde benimsendiğine dair bilgi vermiyor.

TokenPost daha önce AssemblyAI'nin konuşma tanımadan yanıt üretimi ve ses çıkışına uzanan bir yapı sunduğunu haberleştirmişti. Şirketin bu teknik yazısı ise o yapının konuşma tanıma aşamasında, konuşma başına HTTP isteğiyle gerçek zamanlı akış arasındaki farkı açıklıyor.