Bir voicebot demosunda en sık duyduğumuz cümle şudur: "Cevaplar iyi ama konuşma robot gibi." Ekipler bunu genellikle sesin tonuna ya da modelin dil yeteneğine bağlar. Kayıtları dinlediğimizde çıkan tablo çoğunlukla farklıdır: model doğru cevabı üretmiştir, ses de fena değildir, ancak cevap yaklaşık bir buçuk saniye geç başlamıştır.
İnsan kulağı bu boşluğu "kötü ses" olarak değil, "beni anlamadı" olarak yorumlar. Bu yüzden sesli asistan tasarımında ilk kurulması gereken şey senaryo değil, gecikme bütçesidir.
İnsan konuşmasında sıra alma ne kadar hızlı
Bu konuda dayanabileceğimiz oldukça sağlam bir referans var. Stivers ve arkadaşlarının 2009'da PNAS'ta yayımlanan çalışması, aralarında geleneksel topluluk dillerinin de bulunduğu 10 farklı dilde yüz yüze konuşmaları inceledi. Sonuç şu: bütün dillerde soruya verilen yanıtların dağılımı tek tepeli ve tepe noktası sorunun bitişinden sonraki ilk 200 milisaniyede. Diller arasındaki ortalama fark ise yalnızca 250 milisaniyelik bir bant içinde kalıyor (Stivers et al., PNAS 2009).
Yani insanlar birbirine sıra verirken çok dar bir zaman penceresinde çalışıyor. Bu pencerenin dışına çıkan her sessizlik, karşı tarafta anlam kazanıyor: tereddüt, anlamama, itiraz ya da düşünme.
Telefon tarafında da benzer bir eşik var. ITU-T'nin G.114 tavsiyesi, tek yönlü iletim gecikmesi 150 milisaniyenin altında kaldığında etkileşimin pratikte şeffaf olduğunu, 150-400 milisaniye aralığının etkileri bilinerek kabul edilebileceğini, 400 milisaniye üzerinin ise genel şebeke planlaması için kabul edilemez olduğunu söyler (ITU-T G.114). Buradaki 400 milisaniye, henüz hiçbir yapay zeka bileşeni devreye girmeden, sadece sesin taşınmasıyla ilgilidir.
Sesli asistan bu bütçenin üzerine ekleme yapar, altına inemez.
Bütçe nerede harcanıyor
Bir voicebot turunu bileşenlerine ayırdığınızda, kullanıcı susmasıyla asistanın ilk sesi arasında şu adımlar geçer:
- Konuşma bitişinin tespiti (VAD ve endpointing)
- Konuşmanın metne çevrilmesi (ASR)
- Niyetin çözülmesi ve cevabın üretilmesi (diyalog katmanı ve model)
- Gerekiyorsa iş sistemine sorgu (CRM, ERP, rezervasyon veya sipariş servisi)
- Metnin sese çevrilmesi (TTS)
- Sesin şebeke üzerinden geri taşınması
Pratikte bu adımların hiçbiri tek başına felaket değildir. Sorun, herkesin kendi bileşenini "kabul edilebilir" bir süreye ayarlaması ve toplamın hedefi ikiye katlamasıdır. Bir mimaride ASR 300, model 700, CRM sorgusu 400, TTS 350 milisaniye sürüyorsa toplam 1750 milisaniyedir ve kullanıcı bunu bir kesinti gibi duyar.
Bu yüzden bütçeyi bileşen bazında değil, uçtan uca hedefle kurmak gerekir. Bizim pratikte kullandığımız hedef, ilk sese kadar geçen sürenin (time to first audio) tipik turlarda 1 saniyenin altında kalması. Toplam cevap süresi değil, ilk sesin başlama anı. Çünkü kullanıcı için konuşma, cevabın tamamlanmasıyla değil başlamasıyla devam eder.
En pahalı bileşen genelde endpointing
Ekiplerin çoğu ASR ve modele odaklanır, oysa en büyük gizli maliyet konuşmanın bittiğine karar verme aşamasındadır. Klasik yaklaşım sabit bir sessizlik eşiği kullanır: kullanıcı 800 milisaniye konuşmazsa cümle bitmiştir varsayılır.
Bu eşiği düşürürseniz asistan, kullanıcı "Şey, bir saniye..." dediğinde sözünü keser. Yükseltirseniz her turun başına sabit bir vergi eklersiniz. Türkçede bu sorun biraz daha belirgin, çünkü cümlenin yüklemi sona yakın geliyor ve kullanıcılar sayı, adres, kod gibi bilgileri parçalı söylüyor. "Beş yüz otuz iki... üç yüz kırk beş..." gibi bir telefon numarası dikte edildiğinde sabit eşik ya cümleyi böler ya da her parçada bir saniye kaybettirir.
Buradaki çözüm eşiği kurcalamak değil, endpointing kararını bağlama duyarlı hale getirmektir. Beklenen alan bir telefon numarasıysa, asistan kaç hane geldiğini bilerek bekler. Beklenen alan evet/hayır ise 300 milisaniye yeterlidir. Bu ayrım tek başına ortalama tur süresini gözle görülür biçimde düşürür.
İş sistemi çağrısı bütçeyi tek başına yakabilir
Model tarafını 700 milisaniyeye çekmiş olabilirsiniz ama müşterinin CRM'i yoğun saatte 2,5 saniyede dönüyorsa konuşma zaten bozulmuştur. Bu, yapay zeka tarafında çözülecek bir problem değildir; entegrasyon tasarımıyla çözülür.
Uygulamada işe yarayan üç yaklaşım var. Birincisi, konuşma başlamadan önce arayan numaradan müşteri kaydını önden çekmek. İkincisi, uzun süren sorgular için asistanın gerçekten beklediğini söylemesi ("Kaydınıza bakıyorum, bir saniye"). Üçüncüsü de her entegrasyona sert bir zaman aşımı ve o zaman aşımında ne olacağının önceden tanımlanmış olması.
Üçüncü maddeyi atlayan projelerde tipik sonuç şudur: sistem yavaşladığında asistan sessiz kalır, kullanıcı "Alo?" der, asistan bunu yeni bir girdi sanar ve konuşma dağılır.
Bekleme sesleri dürüst kullanılmalı
Asistanın "Tamam, kontrol ediyorum" demesi gecikmeyi maskelemenin meşru bir yoludur. Ancak bunu her turda refleks olarak kullanmak, konuşmayı hızlandırmaz, sadece uzatır. İki kuralı öneriyoruz:
- Bekleme ifadesi yalnızca arka planda gerçekten uzun bir işlem varsa çalınsın
- Aynı ifade arka arkaya tekrar etmesin, çünkü tekrar eden kalıp kaydı anında "otomatik sistem" hissine çevirir
Araya girebilmek (barge-in) pazarlık konusu değildir
Kullanıcı, asistan konuşurken sözünü kesebilmelidir. Uzun bir menü anonsu dinlemek zorunda kalmak, sesli asistanın çözmesi beklenen sorunun ta kendisidir. Barge-in desteği, akustik yankı bastırma ile birlikte kurulmadığında asistan kendi sesini kullanıcı konuşması sanar ve sürekli kendini keser. Bu yüzden barge-in, senaryo tasarımından önce telefon katmanında çözülmesi gereken bir konudur.
Neyi ölçmeli
Voicebot performansını konuşurken en sık yapılan hata ortalamaya bakmaktır. Ortalama tur süresi 900 milisaniye olan bir sistemde, turların yüzde onu 3 saniyenin üzerindeyse müşteri deneyimi kötüdür ve rapor bunu göstermez.
Ölçülmesi gereken metrikler şunlar:
- Turların p95 ilk ses süresi (ortalama değil)
- Endpointing kaynaklı yanlış kesme oranı
- Barge-in başarı oranı
- Zaman aşımına düşen entegrasyon çağrılarının payı
- Kullanıcının aynı bilgiyi tekrar söylemek zorunda kaldığı tur sayısı
Son madde özellikle önemli. Kullanıcının kendini tekrar etmesi, tek başına hem ASR kalitesi hem endpointing hem de diyalog tasarımı hakkında bilgi verir ve çağrı kayıtlarından geriye dönük hesaplanabilir.
Gecikmenin kabul edilebilir olduğu yerler
Her gecikme kötü değildir. Kullanıcı bir işlemin sürmesini bekliyorsa, örneğin bir rezervasyon oluşturuluyor ya da bir ödeme doğrulanıyorsa, iki saniyelik bir bekleme rahatsız etmez. Nielsen'in yaygın kabul gören eşikleri de bunu destekler: 0,1 saniye anlık algılanır, 1 saniye düşünce akışını bozmaz, 10 saniye ise dikkatin kaybedildiği sınırdır (Nielsen Norman Group).
Sorun, beklenmeyen yerdeki gecikmedir. "Merhaba, size nasıl yardımcı olabilirim?" cümlesinden sonra kullanıcı konuşur ve bir buçuk saniye sessizlik olursa, bu sessizliğin bir açıklaması yoktur. Aynı süre "Sipariş numaranızı sistemde arıyorum" dedikten sonra gelirse kimse fark etmez.
Yani gecikme bütçesi yalnızca teknik bir optimizasyon değil, diyalog tasarımının parçasıdır.
Devreye alırken kontrol listesi
Yeni bir sesli asistan senaryosunu canlıya çıkarmadan önce şu soruların yanıtlanmış olması gerekir:
- İlk sese kadar hedef süre kaç milisaniye ve bu hedef p95 üzerinden mi tanımlandı
- Endpointing eşiği alan tipine göre değişiyor mu
- Her entegrasyon çağrısının zaman aşımı ve zaman aşımı davranışı tanımlı mı
- Barge-in ve yankı bastırma test edildi mi
- Telefon hattı üzerindeki taşıma gecikmesi ölçüldü mü, yoksa varsayıldı mı
Bu beş sorunun cevabı netleştiğinde, "robot gibi konuşuyor" geri bildirimlerinin büyük kısmı model değiştirmeden kaybolur.
Sesli asistan mimarisini kendi çağrı hacminiz ve entegrasyon yapınız üzerinden konuşmak isterseniz Voicebot Platformu sayfasındaki mimari şemadan başlayabilir, çözüm senaryolarımızı inceleyebilirsiniz.
Kaynaklar
- Stivers, T. ve ark. (2009). Universals and cultural variation in turn-taking in conversation. PNAS, 106(26). pnas.org
- ITU-T Recommendation G.114, One-way transmission time. itu.int
- Nielsen, J. Response Times: The 3 Important Limits. nngroup.com