Modelin doğru cevap verip vermediğini ölçebilirsin. Doğru cevabın ne olduğunu senin yerine kimse tanımlayamaz.
2 Eylül'de Product Talk aynı gün iki yazı yayımladı: biri ürün ekipleri için uygulamalı bir AI eval rehberi, diğeri o eval'leri çalıştıracak test düzeneğinin kendisi. Aynı gün Towards Data Science'ta kurumsal RAG sistemlerinin "bu belgede yok" derken ne göstermesi gerektiği tartışıldı, Aha Blog'da üç ürün lideri ekiplerinin AI ile nasıl inşa ettiğini anlattı. Haftalık PM bültenindeki tez ise daha keskindi: rekabeti model değil, modelin etrafındaki harness katmanı belirleyecek.
Dört farklı kaynak, bir hafta, tek bir ortak varsayım: AI çıktısını sistematik biçimde ölçemiyorsan ürün yapmıyorsun, şansını deniyorsun.
İddia: eval yeni bir discovery alışkanlığı
Teresa Torres'i ciddiye almanın sebebi kitabı değil, ölçtüğü şeyin kendi ürünü olması. Interview Coach'unu bir yıldır canlıda tutuyor ve her yanıtı elden geçirerek hata kataloğu çıkarıyor. Rehberdeki temel ayrım da oradan geliyor:
Unit test'te yazılımın her seferinde doğruyu bulmasını bekleriz. Eval'de ise ne sıklıkla doğruyu bulduğunu ölçeriz.
— Teresa Torres, Product TalkFark küçük görünüyor ama bütün metodolojiyi değiştiriyor. Deterministik yazılımda kabul kriteri geçer ya da kalır. LLM olasılıksal çalışır ve genelde tek doğru cevabı olmayan semantik işler veriyorsun. Yani ölçtüğün şey "çalışıyor mu" değil, hata oranı. Torres dört ölçüm biçimi tarif ediyor:
| Eval türü | Ne zaman işe yarar | Maliyeti |
|---|---|---|
| Golden dataset | Girdi ve çıktı küçük, tek bir doğru cevap var: sınıflandırma, yönlendirme, olgusal soru | Ucuz ama bakımı yorucu; production girdilerini önceden bilemezsin |
| Code assertion | Hatayı yargı gerektirmeden ölçebiliyorsan: string araması, sayım, yapı kontrolü | Neredeyse bedava, her seferinde aynı sonucu verir |
| LLM-as-a-judge | Hatayı ancak yargı görüyorsa: yönlendirici soru, kaynağa dayanmayan iddia | Pahalı; hakemi kendi yargınla hizalaman gerekir |
| Müşteri geri bildirimi | Ürün canlıdaysa: puan, yeniden üretme, çıktıyı düzenleme, arka arkaya soru sorma | Toplaması kolay, aksiyona çevirmesi zor |
Somut hâli şöyle görünüyor: Torres 17 mülakat transkriptini yazıya çevirtirken hepsini tek tek kontrol etmek yerine bir tanesini sonuna kadar okuyor. İki hata tipi çıkıyor — uydurulmuş detay ve birleştirilerek çarpıtılmış alıntı. Kalan 16'sını bu iki hatayı sayan iki eval ile geçiriyor. Interview Coach'ta ise baseline şu: önerilen 105 sorunun 15'i yönlendirici, 9'u transkriptte zaten cevaplanmış. Rakam olmadan hangi prompt değişikliğinin işe yaradığını bilmenin yolu yok.
Karşı cephe: ölçüm mü, deney mi
Önce ölç, sonra gönder
- Baseline yoksa deney de yok; neyi iyileştirdiğini bilemezsin
- Bir prompt değişikliği bir hatayı düşürürken diğerini yükseltebilir
- Müşteriye açılan üründe hata artık senin değil, kullanıcının problemi
Önce dene, ölçüm sonra
- Oynamadan aracın ne yapabildiğini keşfedemezsin
- Bugün çalışmayan şey gelecek ay çalışıyor; erken ölçüm erken vazgeçiş üretir
- En iyi fikirler işe en yakın insandan geliyor, süreçten değil
Sağdaki cephe Aha panelinden geliyor. Descartes'ta küresel bir PM ekibini yöneten Stephanie Redl, ekibini denemeye zorluyor: "Bugün kullandığın AI, kullanacağın en kötü AI." İtiraz haklı, çünkü eval disiplini kolayca bir onay mekanizmasına dönüşüyor — ölçemediğin için denemeyi bırakıyorsun.
Ama iki cephe de aynı şeyi söylüyor olabilir. Freshworks'ün CPO'su Srini Raghavan, ürün döngüsünü altı aydan iki haftaya indirdiklerini anlatırken hikâyenin "AI-first olmak"la başlamadığını söylüyor: PDLC'nin her adımına yönetişimi tanımlanmış bir ajan koymuşlar ve sonuna bir eval fazı eklemişler. Aynı konuşmada Figma Make'in bazı design system bileşenlerini atladığı da geçiyor. Hız, ölçümün alternatifi değil; ölçümün mümkün kıldığı şey.
Asıl darboğaz araç değil, tanım
Torres'in rehberdeki en rahatsız edici cümlesi eval türleriyle ilgili değil: "İyi"nin neye benzediğini dışarıya veremezsin. Büyük eval araçları kutudan çıkan hazır ölçümler sunuyor — özlülük, yardımseverlik, güvenlik. Her biri doğruluğun bir tanımını içine gömmüş durumda. Astrofizik öğrencisi uzun ve öğretici bir cevap istiyor; aynı soruyu soran astrofizik profesörü istemiyor. Doğruluk bağlama bağlı, bağlamı da satıcı bilmiyor.
Aynı fikrin mühendislik tarafındaki karşılığı, Towards Data Science'taki RAG yazısı. Yazar, Dünya Bankası'nın 63 sayfalık emtia raporunu bir kurumsal chatbot'a bağlıyor ve "AI küresel olarak ne kadar elektrik tüketiyor" diye soruyor. Sistem "bu belgede bulamadım" diyor — ve doğru söylüyor. Ama kullanıcı bunu bir arıza sanıyor, çünkü hükmün arkasında hiçbir kanıt yok. Yazının önerisi, "yok" cevabının dört ayrı kanıt taşıması:
- Ayrıştırma: kaç sayfa okundu, kaç görselin içindeki metin OCR'landı, çözülemeyen kaç çapraz referans kaldı
- Soru ayrıştırma: hangi kavramlar, hangi eş anlamlı ve kısaltmalarla arandı — listeyi alan uzmanı onaylamış olmalı
- Erişim: top-k değil tam tarama; yokluk iddiası ilk on sayfaya bakarak kanıtlanmaz
- Üretim: en yakın geçen pasaj ve tek cümleyle "bu neden cevap değil"
Dört maddenin hiçbiri model kalitesiyle ilgili değil. Hepsi birinin oturup "bu sistemde doğru cevap neye benzer, yanlış cevap neye benzer" sorusunu yazmasıyla ilgili. Bu iş kimin?
AI, çıktıya giden süreyi sıkıştırıyor; yargıya giden süreyi sıkıştırmıyor. Özellikle regülasyonlu ortamlarda. Yargı işin kendisi hâline geldi. Çıktının sahibi sensin.
— Erik Baerresen, Tri Counties Bank, Aha ürün liderleri paneliBu haftanın malzemesi tek tip değil ve hiçbiri bağımsız çalışma değil. Torres'in rakamları kendi iki ürününden geliyor — güçlü bir uygulayıcı deneyimi, ama örneklem bir kişi. Freshworks'ün "altı aydan iki haftaya" rakamı şirketin CPO'sunun podcast beyanı; ne kadarı AI'dan ne kadarı süreç ve organizasyon değişikliğinden geliyor ayrışmıyor. Aha yazısı bir panel özeti olduğu kadar Aha! Builder'ın tanıtımı; "onaylı bir ortamda inşa edin" önerisinin ucu satıcının kendi ürününe çıkıyor. Elimizde bir trend var, kanıtlanmış bir yöntem yok.
Brick'in duruşu
Tartışma "PM eval yazmayı öğrenmeli mi" diye kurulunca yanlış yere bakıyoruz. Torres'in test düzeneğini indirip çalıştırmak bir öğleden sonralık iş. Zor olan kısım bir gün önce başlıyor: hangi hatanın önemli olduğuna, doğru cevabın hangi sınırda bittiğine karar vermek.
Ölçemediğin çıktıyı gönderirsin. Tanımlamadığın doğruluğu ölçemezsin.
Bu yüzden eval bir mühendislik pratiği değil, bir discovery pratiği. Outcome tanımlamak, mülakat yapmak, varsayım testi — hepsi "neyin doğru olduğunu" daraltma işi. Eval dördüncüsü ve tek farkı geriye dönük çalışması: yaptığımız değişiklik işe yaradı mı? Harness tezinin vardığı yer de burası. Rekabet model katmanında değilse, fark modelin etrafına kurduğun sistemde. O sistemdeki her karar — hangi tool açık, ne hatırlanıyor, nerede insan onayı devreye giriyor — bir ürün kararı. Ölçüm de o sistemin geri bildirim halkası, ayrı bir kalite kapısı değil.
Kendi kullandığın bir AI akışını seç — PRD taslağı, mülakat özeti, destek yanıtı, fark etmez. Bir çıktıyı sonuna kadar elle kontrol et; hızlıca göz gezdirme, satır satır. Gördüğün hataları not al ve iki üç kategoriye ayır. Sonra en sık kategoriyi al ve sor: bunu yargı gerektirmeden sayabilir miyim? Torres'in kuralı, en aptal ölçümle başlamak — çoğu zaman bir string araması yetiyor.
Ekibinde "iyi" tanımını kim yazıyor: PM mi, model sağlayıcısının varsayılan eval'i mi? Ölçmediğin çıktıyı ürüne koymak önümüzdeki dönemin pahalı alışkanlığı olacak; ölçtüğünü sanıp tanımı başkasına yazdırmak ise daha pahalısı. 🧱
