Sesli Asistan Neyi Duyduğunu Nereden Bilir? Ad, Numara ve Onay Güvenliği

İncelediğimiz bir görüşmede arayan kişi demo talebi bırakmak istedi ve adını birkaç kez söyledi. Görüşme talep açılmadan bitti. Kayıtları okuyunca üç ayrı katmanda üç ayrı hata çıktı:

1. Konuşma tanıma adı bozdu. İlk turda ad doğru yazılmıştı; sonraki turlarda aynı ad her seferinde başka bir biçimde yazıldı.
2. Asistan adı zaten biliyordu, yine sordu. İlk turdaki doğru ad kişi kaydına yazılmıştı ama bu bilgi cevap modeline hiç gitmiyordu. Talep aracı da "ad soyad" istiyordu; misafir soyadını söylemeyince ad eksik sayılıyordu. 10 haneli bir cep numarası da "eksik" bulundu.
3. Panelde hayalet cevaplar vardı. Çerçeve her kesin yazıda cevabı önden üretmeye başlıyor, misafir konuşmaya devam edince bu üretimi iptal ediyor. İptal edilen cevaplar da kayda yazılıyordu. On saniyelik bir aralıkta kayıtta üç asistan cevabı vardı; misafir bunların yalnız birini duymuştu. Sonraki tur bu geçmişi okuduğu için model duyulmamış cümlelere göre konuşuyordu.

Konuşma tanıma kalitesini ayrı bir karşılaştırmada ele aldık. Bu yazı diğer iki katmanla ilgili: bilinen bilgiyi kullanmak ve neyin gerçekten duyulduğunu bilmek.

İlk düzeltme basitti ama etkisi büyüktü: görüşmeye bağlı kişinin adı, telefonu ve e-postası promptun tura özel kısmına yazılıyor. Bilinmeyen alan "bilinmiyor" diye geçiyor. Aynı satır, bilgi kaynaklarında geçen numaraların işletmeye ait olduğunu da söylüyor.

Birkaç kural daha eklendi:

• Soyad zorunlu değil. Talebi açmak için ad yeterli.
• Bozuk ya da çelişen ad kaydedilmiyor, doğrulanıyor. İki denemeden sonra harf harf isteniyor, yine olmazsa görüşme adsız devam ediyor.
• Parça parça gelen rakamlar tek numara sayılıyor. Türk cep numarası 10 hane, ülke kodu istenmiyor.
• İşletmenin kendi numarası misafir numarası sayılmıyor. Bot kaynaklarda gördüğü işletme numarasını misafirinki sanıp talebe yazamıyor.
• Misafirden "yazmasını" istemiyor. Sesli görüşmede anlamsız bir istek.

Talep akışının kuralı promptta açıkça yazılıydı: eksik bilgiyi topla, özeti oku, "Onaylıyor musunuz?" diye sor, onay gelince talebi aç. Model bu kurala çoğu zaman uyuyordu. Test koşularında ise uymadığı anlar görüldü. Bir diyalog testinde bot özet ve onay sormadan talep açtı; talep bildirimi ekibe e-posta olarak gitti.

Farklı modellerle aynı iki kritik vakayı dörder kez koştuk:

Yeni model ikinci vakada önce eski tarihli talebi, sonra doğrusunu açıyordu; panelde çift talep oluşuyordu. Ama tablonun asıl dersi soldaki 3/4'tü: kullandığımız model de dört denemenin birinde onay almadan talep açmıştı. Kural yalnız promptla korunuyordu.

Kuralı koda taşıdık. İlk talep yalnız şu koşulda açılıyor: önceki asistan mesajı bir özet ve onay sorusuyla bitmiş olmalı, son cümlesi bilgi istememeli. Misafirin cevabı bir numara ya da e-posta taşıyorsa talep açılmıyor, çünkü bu durumda misafir hâlâ bilgi veriyor demektir. Bu kapı hem mevcut modeldeki riski kapattı hem de ileride model değiştirmenin önündeki engeli kaldırdı.

Sesli görüşmenin açılışında asistan adı soruyor. İlk turda gelen kısa bir cevap ("Ayşe", "Ben Mehmet") ad olarak kaydediliyor ve asistan hazır bir cümleyle karşılık veriyor. Bu hızlı yol üç hata çıkardı:

• Anlamsız söz ad oldu. Gürültülü bir ortamda konuşma tanıma "Ya, cips." yazdı; kural bunu "Cips" adı olarak kaydedebiliyordu. Artık sesli kanalda yalnız açılış turundan gelen ad bir tahmin sayılıyor ve onaylanan talepteki adla değişebiliyor.
• Soru ad oldu. Bir testte ilk söz "adresiniz nerede" idi; konuşma tanıma soru işareti koymadı ve asistan "Memnun oldum Adresiniz Nerede" dedi. Soru sözcükleri ve "-ınız/-iniz" iyelik ekiyle biten kelimeler artık ad sayılmıyor. Son 60 günün 38 gerçek ilk cümlesinde eski ve yeni kural aynı sonucu verdi, yani kural başka bir şeyi bozmadı.
• Sorulmamış söz ad oldu. Misafir asistanın sözüne girip "dışarı arama" dedi, konuşma tanıma bunu bir kişi adına benzetti ve asistan "İsminizi … olarak mı alayım?" diye sordu. Prompttaki "bozuk adı doğrula" kuralı ad sorulmamışken de uygulanıyordu. Kuralı daraltmak tek başına yetmedi (bir yoklamada 1/4 → 0/4, diğerinde 2/4 → 2/4). Model kuraldaki örnek adı da kopyalıyordu. Belirleyici çözüm kod tarafındaydı: söz tek başına bir ada benziyor ama asistanın son cümlesi ad sormuyorsa, o tura "büyük ihtimalle yanlış duyuldu, ad sayma, ne dediğini sor" notu ekleniyor. Sonuç iki yoklamada 0/5 ve 0/5 oldu; ad sorulduğunda ad yine kabul ediliyor.

Hitap için ayrıca bir kural var: asistan "Bey" ya da "Hanım" demek için addan cinsiyet tahmin etmiyor. Ad kapalı bir sözlükte varsa unvan ekleniyor, yoksa yalın ad kullanılıyor. Sesten cinsiyet çıkarmayı da elediğimizi not edelim: AB Yapay Zekâ Tüzüğü bunu biyometrik kategorizasyon sayıyor ve yüksek riskli sınıfa koyuyor.

Misafir asistanın sözüne girdiğinde asistan susuyor. Ama cevap hattı cevabın tamamını üretmiş ve kaydetmişti. Sonraki tur bu tam metni geçmişte görüyordu. Somut bir örnek:

• Asistan: "Talebinizi özetleyeyim: yarın saat 14:00, iki kişi. Onaylıyor musunuz?"
• Misafir, "yarın saat" kısmında söze giriyor: "Pardon, yarın değil."

Kayıtta tam metin durduğu için onay kapısı "Onaylıyor musunuz?" sorusunu sorulmuş sayıyordu. Misafirin sonraki "evet"i, hiç duymadığı bir özeti onaylamak gibi okunabilirdi.

Artık söz kesildiğinde cevap hattına ve kayda yalnız duyulan kısım gidiyor; tam metin ayrı bir alanda saklanıyor. Rakip platformlarda aynı desen var: OpenAI'nin gerçek zamanlı API'si kesilen cevabı bağlamdan kırpıyor, Deepgram söylenen ve söylenmeyen metni ayrı döndürüyor.

Bu düzeltmenin doğrulaması iki hata yakaladı. Kesilen cevap kaydedilmemişse (akış yarıda koptuysa), düzeltme bir önceki tam duyulmuş cevaba uygulanıp onu kısaltabiliyordu; artık yalnız son asistan mesajından sonra misafirin başka sözü yoksa uygulanıyor. Seslendirme dönüşümü metni değiştirdiği için ("+90" → "0") eşleşme hiç tutmuyordu; artık yalnız harf ve rakamlar karşılaştırılıyor.

Bir sınır da açık: duyulan kısım çerçevenin tahmini. Çerçeve metni sesin gerçek zamanlamasına göre değil sabit bir hızla ilerletiyor ve heceyi İngilizce sayıyor. Türkçe ve rakamlı cevapta tahmin sesin yaklaşık 0,8-1,4 saniye önüne geçebiliyor. Yine de tam metni kaydetmekten her zaman daha doğru.

Sesli kanalda aynı soruya verilen cevap kısa süre önbellekte tutuluyor. İnceleme sırasında bir risk gördük: arayanın adını ya da telefonunu içeren bir cevap önbelleğe girerse, aynı soruyu soran başka bir arayana okunabilirdi. Kişisel bilgi geçen cevaplar ve sayfa kartı taşıyan cevaplar artık önbelleğe yazılmıyor; telefon ve web hatları da ayrı tutuluyor.

Diyalog testinin ilk koşusu 16 kontrolün 11'ini geçti; kontrol kurallarının birinde de hata vardı ("işletme adınızı" sorusu ad sorusu sayılıyordu). Onay kapısından sonra 24'te 19'a çıktı. Son koşuda 8 senaryonun 7'si geçti.

Kalan açık harf harf heceleme: 4 denemenin 2'si geçti. Bir denemede şehir adlarıyla heceleme ("C Ceyhan, A Adana…") yan konuşma sanıldı ve tur cevapsız kaldı; bir denemede model heceden başka bir ad kurdu. Önerilen çözüm hecelemeyi modele bırakmadan harfleri kodla birleştirmek.

• Kritik kuralları promptta bırakmayın. Onay almadan kayıt açmamak gibi kurallar kodla korunmalı; en iyi model bile dört denemenin birinde kaçırabiliyor.
• Bilinen bilgiyi modele verin. Kaydedilmiş adı yeniden sormak misafire duyulmadığını hissettirir.
• İptal edilen üretimi kaydetmeyin. Önden üretim kullanıyorsanız, misafirin duymadığı cevap geçmişe girmemeli.
• Söz kesilince yalnız duyulan kısmı saklayın. Aksi hâlde model misafirin hiç duymadığı soruya cevap alındığını sanır.
• Hızlı yolları dar tutun. "İlk turdaki kısa söz addır" gibi kısayollar soru, gürültü ve söze girmede yanlış çalışır.
• Test verisinde gerçek kişi kullanmayın. Canlı hatta koşan testler gerçek talep ve e-posta üretebilir.

Diyalog testi yazılı metinle koşuyor; konuşma tanıma, seslendirme ve tur kararını içermiyor. Kontrol edilen tur sayısı sınırlı ve bazı turlar kontrolsüz. Model karşılaştırması iki vakada dörder denemeyle yapıldı; oran değil yön gösterir.