Yapay Zekâ Transkripsiyon Doğruluğu: Üretici Benchmark'ları Neden Yanıltır ve Modelleri Gerçekte Nasıl Test Ediyoruz

Hangi konuşmadan metne (speech-to-text) modelinin en doğru olduğunu bulmaya çalışıyorsanız, yayımlanan benchmark sayısı bakılacak yanlış yerdir. Bir üreticinin manşete taşıdığı doğruluk rakamı, temiz ve okunarak kaydedilmiş bir veri kümesi üzerinde optimize edilmiş bir sonuçtur — modelin elinizdeki gerçek sesi nasıl işlediği hakkında size neredeyse hiçbir şey söylemez: marka adları ve teknik terimlerle dolu bir ürün incelemesi, iki kişinin birbirinin sözünü kestiği bir toplantı, ağır bir aksan ya da diller arasında sürekli geçiş yapan bir içerik üreticisi.

Ben yapay zekâ destekli bir konuşmadan metne aracı olan Subanana'yı yürütüyorum. Her transkripsiyonu, değerlendirmeden geçmiş bir model yığını üzerinden yönlendiriyoruz ve bu yığını sürekli yeniden test ediyoruz. Bu yazı, modelleri nasıl test ettiğimizle ilgili — yöntem, kriterler ve kendi değerlendirme turlarımızdan birinden gelen gerçek sonuçlar — ve bu kararları vermek için üreticilerin yayımladığı doğruluk skorlarına güvenmeyi neden bıraktığımızı anlatıyor.

Özet

• Üreticilerin doğruluk benchmark'ları (tek bir WER skoru, "%98 doğru") büyük ölçüde benchmark avcılığıdır — gerçek çok dilli, aksanlı veya çok konuşmacılı kayıtlara hiç benzemeyen temiz, senaryolu, tek konuşmacılı ses üzerinde ölçülür.
• Bu yüzden modelleri yayımlanan sayılarına göre seçmiyoruz. Onları kendi dağınık, gerçek dünya sesimiz üzerinde test ediyoruz ve çıktıyı bir insan editörün değerlendireceği gibi değerlendiriyoruz: yanlış anlaşılan kelimeleri düzeltti mi, temiz bir yazı dili olarak okunuyor mu ve — en önemlisi — hiçbir olguyu değiştirmedi mi?
• Gerçek bir değerlendirme turunda, küçük ve hızlı bir model, daha ağır olan üretim varsayılanımızı geçti (hakem tercihinde yaklaşık %92, kabaca 13 kat daha hızlı). Daha büyük ve daha yavaş olmak daha doğru demek değildi.
• Bu noktayı kanıtlayan hata: bir model, bir kamera sensörü olan "LYT-828"i sessizce "LYT-808" olarak yeniden yazdı — temiz okunuyor, olgusal olarak yanlış ve bir WER skoru için görünmez.
• Bir aracı kendiniz mi değerlendiriyorsunuz? En kötü gerçek sesinizi test edin — aksanları, üst üste konuşmaları, jargonu, dil değişimlerini — ekrandaki zaman damgalarını izleyin ve sıralama tablosundaki sayıyı değil, olgusal bozulmayı arayın.

Üreticilerin transkripsiyon benchmark'ları neden yanıltıcıdır?

Yayımlanan bir Kelime Hata Oranı (Word Error Rate, WER) ya da doğruluk yüzdesi, üreticinin seçtiği koşullar altında üretilen tek bir sayıdır. Üç şey, onu üretim için model seçiminde neredeyse işe yaramaz hâle getirir:

• Test kümesi temizdir. Benchmark sesi genellikle senaryoludur, tek konuşmacılıdır, sessiz bir odada ve kaynakça zengin bir dilde kaydedilmiştir. Gerçek ses bunların hiçbiri değildir.
• Metrik kabadır. WER, yer değiştirmeleri, eklemeleri ve silmeleri eşit sayar. Ama bir model numarasını yanlış almak (bir "Vivo X30"un "Vivo X90"a dönüşmesi) felaket bir hatadır, oysa düşen bir virgül zararsızdır. WER ikisini de aynı puanlar.
• Bu, üreticinin kendi skor tablosudur. Her laboratuvar, modelinin en iyi göründüğü yapılandırmayı raporlar. Beklenen sonucu değil, en yüksek değeri okuyorsunuz.

Bunların hiçbiri tam olarak sahtekârlık değildir. Sadece benchmark avcılığıdır — kullanım durumunuz için değil, sıralama tablosu için optimize etmektir. Bu yüzden modelleri değerlendirirken kimsenin yayımlanmış rakamını alıntılamayız. Modeli, kullanıcılarımızın gerçekten yüklediği dağınık, çok dilli karışık, gerçek dünya sesi üzerinde çalıştırırız ve çıktıyı, bitmiş bir altyazı veya transkript için önemli olan şeylere göre değerlendiririz.

Tüm felsefe budur: doğruluk, bir üreticinin size verdiği bir sayı değildir. Kendi kullanım durumunuz üzerinde ölçtüğünüz bir şeydir; yoksa onu gerçekten bilmiyorsunuzdur.

Bir altyazı için "doğruluk" gerçekte ne anlama gelir?

Çoğu insan "transkripsiyon doğruluğu" dediğinde, tamamen farklı iki işi birbirine karıştırıyordur:

1. Konuşmadan metne (STT / ASR) — sesi, zaman damgalarıyla birlikte ham metne dönüştürmek. WER buradadır.
2. Metin temizleme — o ham, dağınık ASR metnini yayımlanabilir bir altyazıya dönüştürmek: yanlış anlaşılan kelimeleri düzeltmek, konuşma dili ifadelerini temiz yazılı biçime çevirmek, boşluk ve noktalama işaretlerini geri getirmek, dolgu sözcüklerini çıkarmak ve en önemlisi hiçbir olguyu değiştirmemek.

Her iki aşama da başarısız olabilir ve farklı şekillerde başarısız olurlar. Bir model harika ham metin üretebilir ama zaman damgaları kaydığı için yine de kullanılamaz altyazılar verebilir. Başka bir model kusursuz hizalanmış zaman damgalarına sahip olabilir ama yine de bir marka adını bozabilir. Tek bir doğruluk yüzdesi bunların hiçbirini yakalayamaz; her aşamayı ayrı ayrı ve niteliksel olarak test etmemizin nedeni tam da budur.

Yazının geri kalanı her ikisini de ele alıyor: önce paylaşabileceğimiz gerçek sayılara sahip yapılandırılmış bir değerlendirmemizin olduğu metin temizleme aşaması, ardından bulgularımızın bilinçli olarak niteliksel olduğu ham STT aşaması.

Metin temizleme aşamasını nasıl test ediyoruz: gerçek ses üzerinde hakem olarak LLM

İşte Nisan 2026'da yaptığımız gerçek bir değerlendirme turunun yöntemi. Hedef, ham ASR çıktısının üzerine temizleme geçişi yapan modeldi — kaba bir makine transkriptini yayımlanabilir bir altyazıya dönüştüren adım. Bu geçiş iki ayrı iş yapar ve her birini ayrı ayrı test ederiz:

• Hataları düzeltmek — konuşmadan metnin yanlış aldığı kelimeleri ve sayıları düzeltmek: yanlış anlaşılan bir marka adı, yanlış bir model numarası, düşürülmüş bir olumsuzluk eki.
• İfadeyi temizlemek — konuşma diline ait, gündelik ifadeleri temiz bir yazı diline çevirmek, noktalama ve boşlukları geri getirmek ve dolgu sözcüklerini budamak — anlamı değiştirmeden. (Bazı dillerde bu fark geniştir: örneğin Kantoncada sözlüden yazılıya belirgin bir dönüşüm vardır, 口語 → 書面語.)

(Kapsam, açıkça söyleyelim: bu tur, ham konuşmadan metni değil, o metin temizleme geçişini değerlendiriyor. İkisi farklı şekilde test edilir.)

• Veri kümesi, bilinçli olarak özenle seçilmiş küçük bir gerçek örnek kümesiydi — bizim örneğimizde, dil değiştirmeli (code-switched) Hong Kong Kantonca ve İngilizce — boyutu için değil, modelleri çökerten durumlar için seçilmiş: karışık yazım sistemi, teknik terimler ve model numaraları, noktalama yoğunluklu pasajlar, kısa ve kırılgan parçacıklar ve uzun bölümler. Hangi dilin kullanıldığı, ilkenin yanında ikincil kalır: kendi kullanım durumunuzdan gelen bir avuç gerçekten zorlu örnek, bin tane temiz örnekten daha fazla gerçek hata ortaya çıkarır.
• Karşılaştırma ikili (pairwise) yapıldı. Her örnek için, aday modelin çıktısı mevcut üretim referansımızla doğrudan karşılaştırıldı ve ayrı bir hakem model daha iyisini seçti — ya da berabere ilan etti.
• Kriterler, iyi bir altyazıyı gerçekten tanımlayan altı şeydi ve her örnek için bağımsız olarak puanlandı:
  • Yanlış anlaşılan kelimeleri düzeltme — konuşmadan metnin yanlış aldığını düzeltti mi?
  • Sözlüden yazılıya temizleme — gündelik konuşmayı temiz bir yazı diline çevirdi mi? (Kantonca örneklerimizde bu, 口語 → 書面語 dönüşümüdür; her dilin konuşmayı düzyazıya düzenlemenin kendine özgü bir biçimi vardır.)
  • Dolgu sözcüğü çıkarma — "ıı"ları ve yanlış başlangıçları attı mı?
  • Olgusal koruma — adları, sayıları ve olguları dokunulmamış bıraktı mı?
  • Açıklama eklememe yasağı — konuşmacının asla söylemediği köşeli parantezli notlar uydurmaktan kaçındı mı?
  • Titizlik — metni gerçekten temizledi mi, yoksa bariz hataları yerinde mi bıraktı?

Bu tura 31 model yapılandırması koyduk. Yalnızca 17'si çalıştırılabilir durumdaydı bile — geri kalanı, geçersiz model kimlikleri, istek zaman aşımları veya desteklenmeyen ayarlar nedeniyle ön kontrolde devrildi; bu da kendi başına yararlı bir sonuçtur: güvenilir biçimde çağıramadığınız bir model, benchmark skoru ne olursa olsun aday değildir.

Bu, bir "izlenim kontrolü" değil, belge niteliğinde bir yöntemdir. Aşağıdaki her sayı, o turun kendi çıktısından gelir ve bunu paylaşıyoruz çünkü paylaşması bize ait — bir üretici bize modelinin iyi olduğunu söylediği için değil.

Bulduklarımız: kendi turumuzdan gelen sayılar

Birkaç sonuç öne çıktı. Tüm rakamlar kendi değerlendirmemizden; bunlar altyazı temizleme görevinde hakem tercihi kazanma oranları ve hızdır — kimsenin STT doğruluk yüzdesi değil.

Verilerimizden üç çıkarım:

• Tüm turdaki en iyi ortalama hakem tercihi yaklaşık %92'ydi — hakemin örneklerin büyük çoğunluğunda üretim referansımıza tercih ettiği hafif bir Gemini 3.1 Flash Lite yapılandırması. Küçük ve hızlı bir model, daha ağır varsayılanı geçti.
• En yalın çalıştırılabilir yapılandırma, referanstan kabaca 13 kat daha hızlıydı — yaklaşık 19 saniyeye karşılık kabaca 4 dakika — maliyetin çok küçük bir kısmına ve yine de hataları düzeltmede doğrudan karşılaşmayı açık ara kazandı. Daha büyük ve daha yavaş olan daha iyi değildi.
• Modelin "düşünme" bütçesini sınırlamak, en büyük tek verimlilik kazancıydı. Referans, bütçesinin ezici çoğunluğunu büyük ölçüde ihtiyaç duymadığı akıl yürütme jetonlarına harcadı. Bu akıl yürütme bütçesini aynı model ailesinde kapatmak, hakemin iyi ya da daha iyi olarak değerlendirdiği, kabaca bir büyüklük mertebesi (yaklaşık 10 kat) daha hızlı ve çok daha yalın bir çıktı üretti. Altyazı temizleme gibi kısıtlı ve iyi tanımlanmış bir görev için, uzatılmış akıl yürütme büyük ölçüde boşa harcanan bir çabaydı.

Bunların hiçbirinin "doğruluk yüzdeleri" olmadığını fark edeceksiniz. Bunlar, kendi sesimiz üzerinde, kendi referansımıza karşı bir hakem modelden gelen göreli tercih skorlarıdır. Bu, "%98 doğru"dan bilinçli olarak daha alçakgönüllü bir iddiadır ve gerçekten bir model seçmek için çok daha yararlıdır.

İnsan değerlendirmeli, kullanım durumuna dayalı testin neden önemli olduğunu kanıtlayan hata

İşte tüm argümanı özetleyen örnek. Aday modellerden biri, bir telefon incelemesini (dil değiştirmeli Kantonca-İngilizce kliplerimizden biri) temizlerken şunu yaptı:

Kaynak:    T-828 的 sensor 啦。那這顆 LYT-828 呢，我們，我們又來……
Referans:  ……呢粒 LYT-828 呢……
Aday:      ……嗰呢粒 LYT-808 呢……

Model, bir kamera sensörü olan "LYT-828"i sessizce "LYT-808" olarak yeniden yazdı. Aynı türden hatayı turun başka yerlerinde de gördük; orada başka bir aday bir "Vivo X30 Pro"yu "Vivo X90 Pro"ya çevirdi.

Metin kusursuz okunuyor. Dil bilgisi temiz, noktalama geri getirilmiş, konuşma ifadesi düzgün yazılı biçime düzenlenmiş. Bir WER skoru bu değişikliği zar zor kaydederdi — uzun bir pasajda bir rakam. Ama bu olgusal bir bozulmadır: farklı bir ürün, farklı bir sensör. Bir teknoloji incelemecisi için bu, yorumlarda düzeltme talep edilen türden bir hatadır.

Ders herhangi bir tek dille ilgili değil. Asıl mesele şu: en tehlikeli transkripsiyon hataları akıcı olanlardır — temiz okunan bir cümlede sessizce değiştirilmiş bir teknik terim, model numarası veya özel ad. Bunlar tam da gerçek kullanıcıların kaydettiği karışık yazım sistemli, jargon yoğunluklu seste gizlenir — hangi dilde olursa olsun. Yayımlanan hiçbir doğruluk benchmark'ı bunu yakalayamazdı; bu yalnızca çıktıyı bir insan editörün değerlendireceği gibi — "model bir olguyu değiştirdi mi?" sorusuna karşı — bu hatanın gerçekten ortaya çıktığı türden bir ses üzerinde değerlendirdiğimiz için gün yüzüne çıktı. Benchmark avcılığı ile kullanım durumuna dayalı test arasındaki fark budur.

Bu aynı zamanda "olgusal koruma"nın altı kriterimizden biri olmasının ve onu birebir hata sayımı yerine karşılaştırmalı bir sinyal olarak okumamızın nedenini de gösteriyor. Aynı turda bir model, "yüzde doksan"ı eşit derecede doğru iki biçimde verdi (百分之九十 ile 九成) — anlamsal olarak özdeş, hiçbir hata yok. Naif bir metrik, yeniden ifadeyi işaretler ve sensör değişikliğini kaçırırdı. Doğru malzeme üzerinde uygulanan muhakeme, bu sıralamayı doğru yapar.

Peki ham konuşmadan metne aşamasına ne demeli?

STT aşamasının kendisi için — ses girer, zaman damgalı metin çıkar — bulgularımız bilinçli olarak niteliksel. Ne bizimkini ne de başkasınınkini, bir WER tablosu yayımlamıyoruz; çünkü burada önemli olan hatalar tek bir hata oranıyla iyi yakalanmıyor. Üretimde bir STT modelini bozan şey genellikle şunlardan biridir: konuşmacının asla söylemediği halüsinasyon içerik, kaçırılan geçerli konuşma, kaynakça az veya çok dilli karışık dillerde kararsız performans ya da sesle senkronizasyonu kayan zaman damgaları.

Modelleri kendi sesimiz üzerinde test ederek — teknik özelliklerini okuyarak değil — öğrendiğimiz birkaç şey:

• İyi metin, iyi zaman damgaları demek değildir. Bir transkripsiyon motoru olarak öncü bir çok kipli (multimodal) modeli değerlendirdik: ham metin kalitesi gerçekten iyiydi, ama altyazı zaman damgaları kaydı — okunan bir transkript için iyi, doğru kareye oturması gereken altyazılar için kullanılamaz.
• Bazı modeller tümüyle kullanılamaz zamanlama üretir. Aynı iş için test ettiğimiz farklı bir model, notlarımızda "çöp zaman damgası" ifadesiyle yer aldı — kâğıt üzerinde güçlü, zamana hizalı altyazılar için başlamadan biten bir aday.
• Kaynakça az ve çok dilli karışık diller, genel modellerin sendelediği yerlerdir. Bir benchmark'ın yaslandığı temiz, kaynakça zengin diller kolay durumdur; sendeleme aksanlarda, lehçelerde ve bir kayıt içinde diller arasında geçiş yapan seste ortaya çıkar. Subanana tek ve iyi bilinen bir STT modeliyle başladı ve tam da benchmark'ların gizlediği türden bir hata yüzünden tek sağlayıcılı yaklaşımdan vazgeçmek zorunda kaldık: gerçek koşullarda halüsinasyonlar ve kaçırılan konuşma; en az kararlı olanlar ise daha zor diller — Kantonca da bunların arasında. İşte bu yüzden artık birden çok değerlendirilmiş motor arasında yönlendirme yapıyoruz ve biri kötü bir bölüm ürettiğinde otomatik olarak yedeğe geçiyoruz.
• Gerçek mühendislik boşluklarda yaşar. Yeni bir STT sağlayıcısını dâhil ettiğimizde iş "WER daha mı düşük" değildi. İş şuydu: bir arka plan müziği bölümünün yanlış altyazının zamanlamasına eşlenmesi, kaldırılması gereken başıboş [neşeli müzik] etiketleri, boşluk olmadan birbirine yapışan bölümler. Bunların hiçbiri bir doğruluk skorunda görünmez; hepsi bir kullanıcı için görünür.

Dürüst özet şu: kaynak dile ve kullanım durumuna göre en iyi performans gösteren STT modelini seçiyoruz ve sürekli yeniden kontrol ediyoruz — çünkü iyi benchmark veren bir model yine de zaman damgalarında kayabilir ya da daha zor dillerde halüsinasyon görebilir ve bunu bilmenin tek yolu onu gerçek malzeme üzerinde çalıştırmaktır. Bu yönlendirme ve kalite yığınının nasıl çalıştığını yapay zekâ altyazı aracı ve yapay zekâ toplantı transkripsiyonu sayfalarımızda daha ayrıntılı okuyabilirsiniz.

Transkripsiyon doğruluğunu kendiniz nasıl değerlendirmelisiniz?

Benchmark tuzağından kaçınmak için bir değerlendirme altyapısına ihtiyacınız yok. İlke basit: kendi sesiniz üzerinde test edin, sizin için önemli olana göre değerlendirin.

• Temiz bir klip değil, en kötü gerçek sesinizi kullanın. Aksanların, üst üste konuşmaların, jargonun ve dil geçişlerinin olduğu dosyayı seçin. Modeller orada ayrışır.
• Yalnızca kelimeleri değil, zaman damgalarını kontrol edin. Videoyu altyazılar açıkken oynatın. Kayan altyazılar bir metin karşılaştırmasında görünmez, ekranda ise apaçık ortadadır.
• Özellikle olgusal bozulmayı arayın. Adları, sayıları ve ürün/marka terimlerini tarayın. Yanlış bir sayı içeren temiz okunan bir altyazı, bariz biçimde kaba olandan daha kötüdür.
• Ham transkripti değil, bitmiş çıktıyı değerlendirin. Yayımladığınız şey, düzeltilmiş ve biçimlendirilmiş altyazıdır — bu yüzden onu, ne kadar elle temizleme gerektirdiği dâhil değerlendirin.
• Zaman içinde yeniden test edin. Modeller değişir. Diliniz için bu çeyrekteki en iyisi, gelecek çeyrekte en iyisi olmayabilir. Cevap sürekli değiştiği için değerlendirmemizi tam da bu nedenle yeniden çalıştırıyoruz.

Bu yarışı kendiniz koşmaktansa, bizim sürekli yaptığımız iş tam da budur: modelleri test etmek, her dil ve kullanım durumu için en iyi performans göstereni seçmek ve gözden geçireceğiniz çıktının sistemin üretebileceği en güçlü hâli olması için üstüne halüsinasyon tespiti ve son okuma katmanları eklemek. Bunu kendi en zor sesiniz üzerinde deneyebilirsiniz —

ve yukarıdaki noktaları kontrol edin.

SSS

Yayımlanan daha yüksek bir doğruluk yüzdesi, transkripsiyon aracı seçmenin güvenilir bir yolu mudur?

Hayır. Yayımlanan rakamlar, temiz, çoğu zaman tek konuşmacılı ve kaynakça zengin dilli ses üzerinde optimize edilmiş sonuçlardır. Aksanlı, üst üste konuşmalı, teknik terimli veya dil geçişli gerçek seste performansı nadiren öngörürler. Bunun yerine kendi dosyalarınız üzerinde test edin.

Transkripsiyon doğruluğu ile altyazı kalitesi arasındaki fark nedir?

Transkripsiyon doğruluğu genellikle ham konuşmadan metni ifade eder — kelimeler ve zaman damgaları. Altyazı kalitesi ise temizlemeden sonraki bitmiş sonuçtur: yanlış anlaşılan kelimeler düzeltilmiş, konuşma ifadesi temiz yazılı biçime çevrilmiş, noktalama ve boşluk geri getirilmiş, dolgular kaldırılmış ve olgular el değmemiş. Bir araç birini iyi, diğerini kötü yapabilir.

Modelleri neden başka bir model hakem olarak kullanarak değerlendiriyorsunuz?

Metin temizleme aşaması için bir LLM hakem, iki çıktıyı tutarlı kriterlere göre ikili karşılaştırmamıza, üstelik elle incelemeden çok daha hızlı ve yeni bir model çıktığında ucuza yeniden çalıştırmamıza olanak tanır. Kararlarını mutlak bir doğruluk skoru olarak değil, kendi referansımıza karşı göreli bir tercih sinyali olarak değerlendiririz — bilinçli olarak zorlu, özenle seçilmiş bir örnek üzerinde — ve olgusal bozulma gibi önemli hata durumlarında insanı döngüde tutarız.

İyi transkripsiyon metni olan bir model her zaman iyi altyazı üretir mi?

Hayır ve bu yaygın bir tuzaktır. Gerçekten iyi ham metni olup yine de kayan ya da kullanılamaz zaman damgaları üreten modeller gördük. Kareye hizalanması gereken altyazılar için, zamanlama güvenilirliği kelime doğruluğu kadar önemlidir — ve ikisi birbiriyle bağıntılı değildir.

Subanana neden tek bir model yerine birden çok konuşmadan metne modeli kullanıyor?

Çünkü hiçbir tek model her dilde ve her kullanım durumunda en iyisi değildir ve herhangi bir model gerçek seste halüsinasyon görebilir ya da konuşma kaçırabilir. Subanana tek bir sağlayıcıyla başladı ve üretim verileri tek bir motorun sınırlarını gösterdikten sonra — özellikle kaynakça az ve çok dilli karışık dillerde — çok modelli bir yaklaşıma geçti. Kaynak dile göre en iyi değerlendirilmiş modele yönlendirir ve çıktı kalitesi düştüğünde otomatik olarak yedeğe geçeriz.