Rufat Mirza sunuma bir uyarıyla başladı: "Eval" yeni bir şey değil. Sektörün yeni yönelimlerde ürettiği kelimelerden biri; özünde analitikten farkı yok. Fark nüanslarda — ve o nüanslar bir ürün ekibinin günlük işini değiştiriyor.
Yandex'te arama ve Yandex AI tarafında ürün yöneticisi olarak çalışıyor. Anlattığı şey bir araç tanıtımı değildi; bir ürünün "iyi" tanımını sıfırdan nasıl kurduğunun adım adım anlatımıydı.
Deterministik olmayan sistemde "doğru cevap" yok
Satın alma ekranı deterministiktir: butona basılır, bakiye yetersizse şu, 3D Secure düşerse bu ekran gelir. Girdiler bellidir, geçişler bellidir, çıktılar bellidir.
Mirza salona bir sorgu ve bir cevap gösterdi — "hamsili pilav tarifi" — ve sordu: bu cevap iyi mi kötü mü? Eller ikiye bölündü. İki taraf da haklı gerekçeler sayabilirdi.
Bir şeyi değerlendirmek için önce bir referans noktasına ihtiyacın var: neye göre iyi, neye göre kötü?
Referansı ürün veriyor. Sunumdaki kurgusal uygulama "Kolay Mutfak": Türkiye'deki öğrencilere ve beyaz yakalılara Türkçe, adım adım, kolay tarifler veren bir sohbet arayüzü. Bu tek cümle netleşince aynı cevapları sıralamak mümkün hale geliyor.
| Cevap | Puan |
|---|---|
| Dağınık, malzeme ve yapılış ayrışmamış tarif | 0 |
| Malzemeler ve yapılış ayrı ayrı, adım adım | +1 |
| Adım adım tarif + ilgili videolar | +2 |
| Doğru ama İngilizce cevap | −1 |
| Çince karışmış cevap — itibar riski | −2 |
Çince örneği uydurma değil: batılı API'lerde görülmeyen bu durum, ön eğitimi ağırlıklı Çince olan açık modellerle çalışırken gerçekten karşılaşılan bir şey.
SepetSystem prompt bir fikirdir; fikir doğrulanır
Tek bir cevabı inceleyince "sorgunun dilinde cevap ver", "tarifte adımları göster" gibi notlar çıkıyor ve bunlar system prompt'a ekleniyor. Mirza buradaki tuzağı net söyledi: bu notlar birer hipotez. Ürün yöneticisinin asıl işi de zaten bu hipotezleri yazıp doğrulamak.
Ve tek sorguyla doğrulama olmuyor — aynı sorgu ikinci kez farklı cevap verebilir. Bu yüzden bir sepet gerekiyor: senaryoların tamamını temsil eden bir sorgu veri seti.
Sepet ne kadar büyük olmalı?
Prompt iyileştirmek için 50-100 sorgu iş görüyor. Kendi modelini eğitiyorsan bunun yüzlerce katı gerekiyor; o zaman bir kısmı loglardan, bir kısmı sentetik, bir kısmı insanlara yazdırılarak toplanıyor. Asıl ölçüt büyüklük değil kapsama: senaryolarının hepsi sepette var mı? Sepet hiçbir zaman tamamlanmıyor; loglar geldikçe pişiyor.
Beş kategori: makinenin henüz yapamadığı şey
Ekip bir noktada takılmış: aynı cevap Ayşe'ye farklı, Ahmet'e farklı puan alıyor. Üstelik system prompt zamanla ürün vizyonunun en güncel yansımasına dönüşüyor ama okunabilir bir döküman değil — içi tag'ler ve kurallarla dolu.
Çözüm, Mirza'nın "makinelerin henüz iyi yapamadığı şey" dediği şey oldu: soyutlama. Ürünü iyi yapan şeyleri beş başlığa indirdiler.
| Kategori | Sorduğu soru |
|---|---|
| Usefulness | Sorulan soruya mı cevap veriyoruz, yoksa çok güzel başka bir cevap mı? |
| Ethics | Etik dışı sorulara etik cevap veriyor muyuz; normal sorulara etik dışı bir şey ekliyor muyuz? |
| Competency | Düzgün yazıyor muyuz? Noktalama, anlatım bozukluğu, ton. |
| Enrichment | Cevapta görsel, video, zenginleştirme var mı? Farklaştıran taraf burası. |
| Factualness | Kafadan mı uyduruyoruz, yoksa kaynağı gösterebiliyor muyuz? |
Bu beş başlığın iki işi var. Birincisi ekip içi dil: "yeni modeli eğittik, factualness iyileşti ama competency düştü" cümlesi herkes için aynı şeyi ifade ediyor. İkincisi ölçekleme: kendi modelini eğitiyorsan işaretlemeyi ekip dışından insanlar yapacak ve onların okuyacağı bir döküman gerekiyor. O dökümanın tek işi ürünü iyi yapan özellikleri anlatmak.
İşaretlemeVakumda değil, rakiple yan yana
Mirza'ya göre işin en önemli ayağı annotation — ve bu, ürün yöneticisinin en önemli işi. Sunumdaki tabloda solda prototip, sağda rakip var; her satır bir sorgu, her hücre bir puan ve bir yorum.
Eksileri artıya çevirmek
Kendi cevaplarındaki kırıkları düzeltmek. LLM-as-judge kurulumlarının odaklandığı taraf burası.
Rakibin artılarını almak
Onda iyi çalışanı kendi ürününe taşımak. Bu ayrı bir iş ve otomatik değerlendirme bunu bulmuyor.
Yorum sütunu bu yüzden kritik. Yetmiş satır işaretlendikten sonra o yorumlar bir listeye dönüşüyor — Mirza buna problem listesi demiyor, fırsat listesi diyor: her satırda ne, hangi öncelikle ve kim tarafından düzeltilecek yazılıyor.
LLM'e havale etmeden önce elle yap
"Hepsini modele saysan olmaz mı?" sorusuna cevabı netti: olur ama önce elle yap. LLM-as-judge'ın kafası unit test gibi — problem bulmakta iyi, yeni içgörü çıkarmakta değil. Süreç oturduktan sonra otomatikleştirmek serbest.
Tanımla, işaretle, düzelt, yayınla
Ortaya çıkan çevrim tanıdık: sepeti kur, iyinin tanımını yaz, işaretle, düzeltmeleri yap, yayınla, tekrar ölç. Ekip bunu haftalık yapıyor; düzeltme yapılıyor ve hemen üzerine kontrol ediliyor.
Bir de yalnızca son cevaba bakılmıyor: trace de inceleniyor — cevap nasıl oluştu, hangi araç çağrıldı. İyileştirmelerin bir kısmı prompt'a değil backend'e gidiyor.
Döngünün çıktısı da raporlanabilir metrikler oluyor: cevapların yüzde kaçı +1 ve +2 aldı, kaç kritik cevap var, etik problem var mı, yanıt süresi ne, rakibe karşı kayıp oranı (lose rate) ne. Aynı ölçüm her ay tekrarlanınca kalitenin yönü grafiğe dökülebiliyor.
Konuşmadan kalan cümle de bu: eval ayrı bir disiplin değil, ürün yöneticiliğinin deterministik olmayan sistemlerdeki hali.
