Ölçmeden yayımlamak teknik borç değil, bilinmeyen borçtur

Tez#

Yazılım ekipleri teknik borç kavramıyla rahat çalışır çünkü borç görünür: şu modül test edilmemiş, şu bağımlılık eski, şu kısayol sonra düzeltilecek. Borcun miktarı tartışılabilir, önceliklendirilebilir, ödenebilir. Yapay zekâ sistemlerinde değerlendirme eksikliği bu kategoriye girmiyor ve girmediği için yanlış yönetiliyor.

Fark şu: test edilmemiş bir modülün hatalı olup olmadığı bilinmez ama hatalıysa deterministik biçimde hatalıdır — bir kez bulunduğunda tekrar üretilir, düzeltilir, kapanır. Ölçülmeyen bir yapay zekâ sisteminin çıktısı ise bir dağılımdır; hatalar rastgele aralıklarla ortaya çıkar, bir koşuda görünüp diğerinde kaybolur. Bu yüzden ölçüm yoksa hata "var mı yok mu" sorusu bile cevaplanamaz. Ortada bir borç değil, miktarı ölçülemeyen bir belirsizlik vardır.

Bağlam: dört bozulma türü#

Ölçüm olmadığında kaçırılan bozulmalar rastgele değil; dört öngörülebilir kanaldan geliyor ve hiçbiri klasik izlemeyle görünmüyor.

Dördüncü satır en az konuşulanı. Bir sistem belirli bir iş için tasarlanır, kullanıcılar onu benzer ama farklı bir iş için kullanmaya başlar ve sistem o işte kötü çalışır. Hacim artışı bir başarı göstergesi olarak raporlanır; kalite düşüşü hiçbir yerde görünmez. Bu, ölçümün yalnızca sabit bir sette değil, üretimden alınan örneklerde de yapılması gerektiğinin gerekçesi.

Kanıt: setin ne olduğu ve ne olmadığı#

Değerlendirme seti kurmanın önündeki en büyük engel, işin sanıldığından büyük görünmesi. Oysa ilk sürüm küçük olabilir ve küçük hâliyle bile bilinmeyen borcu bilinen borca çeviriyor.

• Elli örnek yeterli bir başlangıç: kapsam dar olur ama sıfırdan sonsuz derecede iyidir. Büyütmek sonra gelir.
• Örnekler üretimden gelmeli: hayal edilmiş sorular gerçek dağılımı temsil etmez ve yanlış güven verir.
• Kapsam dışı yazılı olmalı: setin neyi ÖLÇMEDİĞİ, ölçtüğü kadar önemli. Yazılmazsa ekip kapsanmayan alanda yanlış güven taşır.
• Her üretim arızası sete eklenmeli: bir kez görülen hata, bir daha kaçmasın. Set böyle büyür — planla değil arızayla.
• Set sürümlenmeli: hangi ölçüm hangi set sürümüyle alındı? Set değiştiyse skorlar karşılaştırılamaz.

Üçüncü madde en çok atlanan ve en değerli olanı. Bir değerlendirme setinin kapsamı zorunlu olarak sınırlıdır; sınırın nerede olduğunu yazmak, ekibin kapsanmayan alanda yanlış güven taşımasını engeller. "Bu set çok dilli girdileri ölçmüyor" cümlesi, o alanda gelecek bir arızayı sürpriz olmaktan çıkarır.

Mekanizma: neden gözle değerlendirme yetmiyor#

Ölçüm yerine en sık kullanılan yöntem gözle değerlendirme: ekip birkaç örnek dener, çıktı iyi görünürse yayımlar. Bu yöntemin neden yetmediği istatistiksel: model çıktısı bir dağılım ve birkaç örnek o dağılımın varyansını göstermez.

Pratik sonuç şu: iki sürüm arasındaki gerçek fark küçük olduğunda, birkaç örnekte görülen "iyileşme" tamamen örnekleme gürültüsü olabilir. Ekip değişikliği yayımlar, bir süre sonra kalite düştüğünü fark eder ve nedenini bulamaz — çünkü değişikliğin etkisi hiç ölçülmemiştir. Daha kötüsü, bu yöntem sistematik bir yanlılık taşır: ekip kendi yaptığı değişikliğin işe yaradığını görmek ister ve örnekleri o beklentiyle okur. Sabit bir set ve önceden tanımlı bir ölçüt, bu yanlılığı ortadan kaldıran tek mekanizma.

Karşı görüş#

İki itiraz güçlü. Birincisi hız: değerlendirme kapısı kurmak yayın döngüsünü yavaşlatır ve erken aşamada hız her şeyden değerli. İkincisi temsil: küçük bir set gerçek kullanımı temsil etmiyorsa, ona göre optimize etmek sistemi yanlış yöne çekebilir — sete aşırı uydurma riski gerçek.

Elli örneklik set kurduk ve altı ay boyunca ona göre optimize ettik. Skor yükseldi. Sonra gerçek kullanıcı sorularına baktık: setimizdeki soruların hiçbiri onlara benzemiyordu.

Alıntı ikinci itirazı doğruluyor ve setin nasıl kurulacağına dair en önemli kuralı üretiyor: örnekler üretimden gelmeli. Hayal edilmiş sorular kolay yazılır ve gerçek dağılımı temsil etmez; bu durumda set bir ölçüm aracı değil bir kendini doğrulama aracı olur. Birinci itiraz için ise karşılaştırma yanlış kurulmuş: kapısı olmayan ekipler daha hızlı yayımlamıyor, daha çok geri alıyor. Otomatik bir kapı, geri alma sayısını düşürerek etkin hızı artırıyor. Yavaşlatan şey kapı değil, kapı olmadığı için sonradan ortaya çıkan arızalar.

Sınırlar ve belirsizlik#

Bu analiz bir set büyüklüğü ya da kapsama oranı önermiyor; ikisi de göreve ve riske bağlı.

• Gerekli set büyüklüğü göreve bağlı: yakalamak istediğiniz farkın büyüklüğü ve ölçümün varyansı belirleyici; sabit bir sayı verilemez.
• Sete aşırı uydurma riski gerçek: set gerçek kullanımı temsil etmiyorsa ona göre optimize etmek sistemi yanlış yöne çeker.
• Üretim örneklemesinin gizlilik boyutu var: gerçek kullanıcı sorularını sete almak kişisel veri değerlendirmesi gerektirir.
• Sessiz hata oranı ölçülmemiş: kullanıcının fark etmediği yanlışların payına dair yayımlanmış veri sınırlı; itirazın niceliği belirsiz.

Sonuç#

Değerlendirme seti bir kalite aracı değil, bir bilgi aracı. Kaliteyi yükseltmez — kalitenin ne olduğunu söyler. Ve bu, yapay zekâ sistemlerinde kaliteyi yükseltmenin ön koşulu: ölçülmeyen bir şey iyileştirilemez, çünkü iyileşip iyileşmediği bilinemez.

Pratik eşik düşük: elli üretim örneği, yazılı bir kapsam sınırı ve her sürümde otomatik koşan bir hat. Bu üçü kurulduğunda "sistem iyi çalışıyor" cümlesi bir izlenimden bir ölçüme dönüşüyor. Kurulmadığında ise ekip sistemini bir dağılım olarak değil bir izlenim olarak yönetiyor — ve izlenimler, özellikle kendi yaptığınız değişiklikler hakkında, sistematik biçimde iyimserdir.

Ne yapmalı?#

1. 1Elli üretim örneğiyle başlayın

   Hayal edilmiş soru yazmayın; gerçek kullanımdan örnek alın. Kapsam dar olsun, temsil doğru olsun.

2. 2Kapsam dışını yazın

   Setin neyi ölçmediğini açıkça belgelendirin ve risk kaydına taşıyın. Yazılmayan sınır, yanlış güven üretir.

3. 3Hattı sürüm akışına bağlayın

   Setten geçmeyen sürüm yayına çıkmasın. Kapı elle çalıştırılıyorsa bir süre sonra çalıştırılmaz.

4. 4Her arızayı sete ekleyin

   Bir kez görülen hata bir daha kaçmasın. Set planla değil arızayla büyür.

5. 5Seti sürümleyin

   Hangi skor hangi set sürümüyle alındı? Set değiştiyse eski skorlarla karşılaştırma geçersizdir.

6. 6Periyodik koşu ekleyin

   Sağlayıcı sürümü habersiz değişebilir. Sürüm akışına bağlı kapı bunu yakalamaz; zamanlı koşu yakalar.