Yapay Zekâ Transkripsiyonu Teknik Terimleri Neden Yanlış Duyar (ve Biz Bunu Nasıl Düzelttik)

2 Temmuz'da bir test oturumu çalıştırdık ve GeekBye'a yüksek sesle basit bir soru sorduk: "What is the pointer in C++?"

Canlı transkript şiirle yanıt verdi:

[23:16:37] You: Tell me, what is the point in life? [23:16:52] You: Handy Plus. [23:17:02] You: What the pointer in Plus Plus? [23:17:09] You: C.

Aynı oturumda sağlık metrikleri gerisini anlatıyordu: 163 saniyede 3 kopan transkripsiyon bağlantısı ve transkriptte 51 saniyelik bir boşluk. Ve sonradan en önemlisi çıkan bir ipucu daha: oturum sonrası kurtarma geçişimiz — boşlukları doldurmak için yerel olarak kaydedilen sesi yeniden transkribe eder — cümleyi neredeyse doğru yakaladı: "a pointer in plus, plus? What the pointer in plus, plus C++."

Ses kaydı gayet iyiydi. Canlı modelin C++ beklemek için hiçbir nedeni yoktu, hepsi bu.

Bu, gerçek transkriptler ve üretim loglarıyla anlatılan GeekBye v2.0.11 hikâyesi.

Konuşma modelleri sizin terminolojinizi neden yanlış duyar

Konuşma tanıma bir tahmin problemidir. Belirsiz bir ses karşısında model en olası kelimeleri seçer — ve genel amaçlı bir model için "point in life" (hayatın anlamı), "pointer in C++"tan (C++'taki pointer) çok daha olası bir ifadedir. Bir toplantı transkriptinin Kubernetes'i "cube and eddies" olarak yazdığını görmüş her mühendis bu hatayla tanışmıştır.

Çözüm daha iyi bir mikrofon değil. Çözüm keyterm biasing: oturum başlamadan önce modele, hangi olasılıksız kelimelerin sizin için olası olduğunu söylemek. Konuşma sağlayıcımız oturum başına 50 adede kadar biasing terimi destekliyor. İşin utanç verici kısmı: bu terimler için gereken tesisat stack'imizde uçtan uca zaten mevcuttu — istemci, backend, sağlayıcı — ve onu hiçbir şey hiç doldurmamıştı. Her oturum sıfır alan yardımıyla çalışıyordu.

Düzeltme 1: profiliniz modelin sözlüğü hâline geliyor

GeekBye alanınızı zaten biliyor — aktif profilinizde yazıyor. v2.0.11, biasing keyterm listesini profilin adından ve açıklamasından türetiyor: sembol içeren terimler (C++, Node.js), kısaltmalar (SQL, AWS), camel-case isimler (TypeScript, PostgreSQL) ve özel isimler. Stack'inizden bahseden bir profil artık o stack'i egzotik değil, beklenen hâle getiriyor.

Düzeltmenin her şeyi daha kötü yaptığı gün

İlk sürümümüz, büyük harfle başlayan her kelimeyi özel isim sayıyordu. Dahili bir test build'inde (bu asla müşterilere ulaşmadı), düzyazıyla yazılmış bir profil modele şu biasing listesini gönderdi:

Senior, Writing, Direct, For, Includes, Write, Role, Intent…

Bir konuşma modelini "For" kelimesine doğru yönlendirmek, hiç yönlendirmemekten daha kötüdür. Hemen sonraki test oturumunda "speak" kelimesi — net biçimde, defalarca söylendi — "Clicky", "Hey, Vicky" ve "Peter Paderty" olarak geri geldi. Ders bize bir öğleden sonraya mal oldu: yalnızca ayırt edici terimlerle biasing yapın. Büyük harfli kelimeler artık yalnızca cümle ortasında geçtiklerinde sayılıyor (gerçek bir özel isim sinyali); her kelimenin büyük harfle yazıldığı markdown başlıkları asla katkıda bulunmuyor. Aynı profil artık tam olarak LinkedIn, AI, CEO, MCP üretiyor — ve doğrulama oturumu, çok dilli ve hızlı geçişli sesi 199 saniye boyunca kesintisiz doğru transkribe etti: 189 transkript segmenti, sıfır hata.

Düzeltme 2: bağlantıları düşüren yarış

Keyterm listesi yanlış duyulan kelimeleri açıklıyordu. Üç kopan bağlantıyı açıklamıyordu.

O iz daha ince bir yere götürdü. Sağlayıcımız, transkripsiyonu kendi ses etkinliği algılamasına göre commit ediyor (sonlandırıyor): sessizliğin yaklaşık birinci saniyesinde. İstemcimiz de ayrıca, askıda kalan yarım cümleleri boşaltmak için sessizliğin 250 milisaniyesinde bir güvenlik commit'i gönderiyor. Sağlayıcının zaten commit ettiğine dair onayının geri dönmesi bir ilâ üç saniye sürüyor. Bu üç sayının hesabını yapın: sağlayıcı önce commit ettiğinde, güvenlik commit'imiz neredeyse boş bir tampona karşı ateşleniyordu — ve sağlayıcının buna yanıtı kibar bir ret değildi. Bağlantıyı düşürüyordu. Konuşmadaki her duraklama bir yazı tura atışıydı.

v2.0.11 buna karşı iki katman getiriyor:

1. Uygulamada: commit edilmiş bir transkript geldiğinde, istemci artık sağlayıcının tamponunun az önce boşaltıldığını biliyor ve gereksiz güvenlik commit'ini atlıyor.
2. Backend'imizde, aynı gün: uygulama ile sağlayıcı arasında duran proxy, sağlayıcının ses muhasebesini birebir yansıtıyor — her ses frame'ini ve her commit onayını sıfır gecikmeyle görüyor — ve sağlayıcının reddedeceği herhangi bir commit'i iletmeyi düpedüz reddediyor. Bu katman, henüz güncellemeyen kullanıcılar dahil tüm istemci sürümlerini aynı anda koruyor.

Bir saat içinde üretimde çalıştığını gördük. Koruma, 178ms ve 256ms tamponlanmış ses taşıyan mahkûm commit'leri yakaladı — o günden önce her biri garantili bir bağlantı kopması ve birinin toplantı notlarında bir boşluk demekti. O öğleden sonra 60 dakikalık kesintisiz bir oturumda beş yakalama ve sıfır kopma kaydedildi. Düzeltmeden önce, aynı sabah gerçek bir kullanıcı tam da bu bug'la boğuşarak kaydını altı dakikada beş kez yeniden başlatmıştı.

Yanında gelen iki küçük düzeltme

Yapay zekâ içgörüleri artık içerik bekliyor. O bozuk erken parçalar eskiden GeekBye'ın canlı öneri çiplerini besliyordu; bunlar da yanlış duyulmuş bir C++ sorusundan "Defining Life's Ultimate Purpose" gibi konuları kendinden emin bir şekilde üretiyordu. Öneriler artık oturum gerçek bir konuşma yoğunluğuna ulaşana kadar bekliyor.

Kurtarılan metin doğru konuşmacıya yazılıyor. C++ sorumuzu doğru transkribe eden kurtarma geçişi onu "Them"e atfetmişti. Yerel olarak kaydedilen ses zaman çizelgesi artık kimin konuştuğunu kaydediyor; böylece kurtarılan segmentler doğru şekilde You veya Them'e atfediliyor.

Skor tablosu

Metrik (ölçüldü, tahmin edilmedi)	Önce	v2.0.11 + backend koruması sonrası
Test oturumundaki bağlantı kopmaları	163s içinde 3	0
En uzun transkript boşluğu	51s	doğrulamada en kötü boşluk ~6s
"pointer in C++"	"point in life"	doğru, yönlendirilmiş sözlük
Sağlayıcıya ulaşan mahkûm commit'ler	hepsi	0 (backend'de yakalandı)

Gerçek zamanlı konuşma API'leri üzerine bir şey inşa ediyorsanız

Bu sürümden çıkan üç aktarılabilir ders:

1. Biasing özelliğini besleyin. STT sağlayıcınız keyterm/phrase hint destekliyorsa, onu küçük ve ayırt edici bir sözlükle doldurmak eldeki en ucuz doğruluk kazancıdır — yaygın kelimelerle doldurmaksa doğruluk kaybıdır.
2. Sağlayıcının kendi durum makinesiyle, bir ağ gidiş-dönüşünün yanlış tarafından asla yarışmayın. İstemcimiz 250ms'ye karşı 3s'lik bir bilgi yarışını kazanamazdı. Koruma, iki sinyalin buluştuğu yere aittir — bizim için backend proxy'si.
3. Yayınlamadan önce canlı bir build üzerinde doğrulayın. Keyterm regresyonu yakalandı çünkü her GeekBye sürümü, çıkmadan önce imzalı ve noter onaylı (notarized) bir build olarak üretime karşı test ediliyor. Kötü sürüm birkaç saat boyunca tek bir dahili makinede vardı, sizin Mac'inizde değil.

GeekBye v2.0.11 şu anda yayında — v2 kullanıyorsanız otomatik güncellemeyle zaten sizde. Bu sürümün üzerine inşa edildiği güvenilirlik altyapısı için yapay zekâ not alma aracınız kötü Wi-Fi'da neden duruyor ve GeekBye v2'de neler değişti yazılarına bakın. Canlı transkripsiyonun günlük kullanımı içinse GeekBye'da gerçek zamanlı transkripsiyon ile başlayın.