Model değiştirmeden önce: kendi değerlendirme setinizi nasıl kurarsınız?

Eylül 2026'nın üçüncü haftasında üç büyük model duyurusu arka arkaya geldi ve üçü de aynı şeyi söyledi: daha ucuz, en az eskisi kadar iyi. Her duyurunun yanında bir tablo vardı ve her tablo duyuruyu yapan şirketin seçtiği testlerden oluşuyordu.

Bu tablolar işe yaramaz değil, ama sizin sorunuza cevap vermiyorlar. Sizin sorunuz şu: benim işimde hangisi daha iyi ve bana kaça mal oluyor? Bunu yalnızca kendi verinizle ölçebilirsiniz. İyi haber, bunun için büyük bir altyapıya ihtiyacınız yok.

Değerlendirme seti nedir?

Değerlendirme seti (eval), modele verdiğiniz girdiler ve o girdilere verilmesi gereken cevaplardan oluşan küçük bir test koleksiyonudur. OpenAI'ın belgeleri süreci üç adımda özetliyor: işi bir test yapılandırması olarak tanımlayın, testi çalıştırın, sonucu inceleyip yineleyin.

Amaç modeli genel olarak yargılamak değil. Amaç, bir değişiklik yaptığınızda (model değiştirmek, istem değiştirmek, çaba ayarını düşürmek) işinizin bozulup bozulmadığını görmek.

Adım 1: Başarı ölçütünü sayıya çevirin

Anthropic'in belgeleri iyi ve kötü ölçüt arasındaki farkı örnekle veriyor. "Güvenli çıktılar" kötü bir ölçüt; "10.000 denemede zararlı olarak işaretlenen çıktı oranı binde birin altında" iyi bir ölçüt. Aynı şekilde "duyguları iyi sınıflandırsın" yerine "F1 puanı en az 0,85" demek gerekiyor.

Kendi işiniz için bunu yazmak çoğu zaman en zor adımdır ve atlanırsa geri kalan her şey anlamsızlaşır. "Müşteri yanıtı iyi olsun" cümlesini, "yanıt müşterinin sorduğu ürünün adını içersin ve iade süresini doğru söylesin" gibi kontrol edilebilir bir cümleye çevirin.

Adım 2: Örnekleri gerçek işten toplayın

Anthropic'in üç tasarım ilkesinden ikisi burada işliyor:

• İşe özgü olun: test örnekleri gerçek iş dağılımınızı yansıtsın. Uç durumları da koyun: alakasız girdi, aşırı uzun girdi, kötü niyetli girdi, belirsiz durumlar.
• Nicelik, niteliğin önüne geçsin: belgenin ifadesiyle, otomatik puanlanan daha çok soru, elle puanlanan az sayıda mükemmel sorudan iyidir.

Pratikte 30-50 örnekle başlamak yeterli. Bunları hayal ederek değil, gerçek kayıtlardan seçin: geçen ayın destek talepleri, kendi kod tabanınızdan alınmış hatalar, gerçekten sorulmuş sorular. Özellikle modelin daha önce yanlış yaptığı vakaları toplayın; en çok bilgi veren örnekler onlar.

Adım 3: Puanlamayı otomatikleştirin

Elle okunan test, üçüncü çalıştırmada terk edilir. Anthropic'in belgesi birkaç otomatik puanlama yöntemi sayıyor:

Modelle puanlama yapıyorsanız iki kural önemli: puanlayan model, cevabı üreten modelden farklı olsun ve puanlama ölçütünü açık bir yönergeye bağlayın. İyi yazılmış bir yönergenin testi şudur: iki uzman aynı cevaba aynı puanı verir mi?

Adım 4: Maliyeti de ölçün

Bu haftanın duyurularının hepsi maliyet üzerineydi, o yüzden değerlendirme setiniz yalnızca doğruluğu değil, üç sayıyı birlikte tutmalı:

• Başarı oranı.
• Görev başına jeton (girdi, çıktı ve önbellekten okunan ayrı ayrı).
• Görev başına süre.

Üreticilerin tabloları da bu yöne kaydı: mutlak puan yerine görev başına maliyet konuşuluyor. Aynı hesabı kendi işinizde yapmak, "yüzde 40 ucuz" gibi bir iddianın sizin kullanımınızda ne ifade ettiğini gösteren tek yol.

Somut bir örnek: destek yanıtları

Diyelim ki bir e-ticaret sitesinin destek yanıtlarını model yazıyor. Değerlendirme seti şöyle kurulur:

1. Örnekler: Son bir ayın gerçek destek taleplerinden 40 tanesi. 25'i sık gelen türlerden (kargo nerede, iade nasıl, beden değişimi), 10'u zor vakalar (iki siparişin karışması, kısmi iade), 5'i uç durumlar (alakasız mesaj, öfkeli müşteri, eksik bilgi).
2. Beklenen çıktı: Her talep için elle yazılmış doğru cevap değil; doğru cevabın içermesi gereken şeyler. Örneğin "iade süresi 14 gün olarak söylenmeli", "sipariş numarası tekrarlanmalı", "kargo firmasının adı geçmemeli".
3. Puanlama: Bu maddeler birebir eşleşmeyle ya da basit bir metin kontrolüyle ölçülebilir. Üslup için ayrı bir model puanlayıcı kullanılır ve yalnızca üslubu değerlendirir.
4. Maliyet: Her çalıştırmada toplam girdi ve çıktı jetonu kaydedilir; görev başına maliyet buradan çıkar.

Bu set bir öğleden sonrada hazırlanır ve yıllarca kullanılır. Yeni bir model çıktığında yapılacak iş, iki komut çalıştırıp iki tabloyu yan yana koymaktan ibaret.

Sık yapılan üç hata

• Sadece kolay örnekleri koymak. Her model kolay vakaları geçiyor; set ancak zorlandığı yerlerde ayırt ediyor. Setin yarısı zor olmalı.
• Puanlayıcıyı hiç denetlememek. Model puanlayıcı da yanılır. Arada 10 örneği elle okuyup puanlayıcının kararıyla karşılaştırın; uyuşmuyorsa yönergeyi düzeltin.
• Tek sayıya bakmak. Genel başarı oranı, hangi tür vakanın bozulduğunu gizler. Sonuçları kategoriye göre de bölün: kargo soruları düzeldi ama iade soruları bozulduysa, ortalama bunu göstermez.

Adım 5: Sonucu doğru okuyun

Burada en sık yapılan hata, iki modelin puanı arasındaki küçük farkı gerçek bir fark sanmak. Anthropic'in istatistik yaklaşımı üzerine makalesi bunu birkaç öneriyle toparlıyor:

• Hata payını yazın. Ortalamanın standart hatası hesaplanıp yüzde 95 güven aralığı verilebilir; aralık, ortalamadan 1,96 standart hata uzaklıkta.
• Kümelenmiş soruları düzeltin. Aynı metin üzerine sorulmuş birden çok soru bağımsız değildir; makaleye göre kümelenmiş standart hata, naif hesaptan üç kat büyük olabiliyor.
• Eşleştirilmiş karşılaştırma yapın. İki modeli aynı sorularla sınadığınız için, soru zorluğundan gelen gürültüyü eşleştirilmiş analizle temizleyebilirsiniz.

Pratik karşılığı şu: 40 örneklik bir sette yüzde 72 ile yüzde 75 arasındaki fark büyük ihtimalle gürültüdür. Ya örnek sayısını artırın ya da o farkı karar gerekçesi yapmayın.

Adım 6: Düzenli çalıştırın

Değerlendirme setinin asıl değeri tek seferlik karşılaştırmada değil, tekrarda. Şu üç anda çalıştırın:

1. Model ya da sürüm değiştirirken.
2. İstemi değiştirirken.
3. Maliyet düşürmek için çaba ayarını ya da daha küçük bir modeli denerken.

Sonuçları tarih ve model adıyla saklayın. Üç ay sonra "bu işi eskiden daha iyi yapıyordu" tartışması çıktığında, elinizde his değil kayıt olur.

Türkçe işlerde fazladan üç kontrol

Modeller İngilizce metinlerde iyi durumda olduğu için, Türkçe çıktının kalitesi çoğu zaman ölçülmeden varsayılıyor. Türkçe bir iş akışını değerlendiriyorsanız sete şu üç kontrolü ayrıca koyun:

• Harf ve ek doğruluğu. Şapkalı ve noktalı harflerin doğru kullanılması, özellikle özel adlara gelen eklerde kesme işareti ("Ankara'ya", "OpenAI'ın") sık bozulan yerler. Bunlar basit metin kontrolüyle ölçülebilir.
• Hitap ve resmiyet düzeyi. Aynı cevabın "sen" ve "siz" biçimleri arasında gidip gelmesi, kurumsal bir yazışmada tek başına hatadır. Sette hem resmi hem samimi örnek bulundurun ve modelin tutarlı kalıp kalmadığına bakın.
• Çeviri kokusu. İngilizceden birebir çevrilmiş kalıplar ("bu konuda size yardımcı olabilirim" yığınları, gereksiz edilgen çatı) metni resmî değil yapay gösteriyor. Bunu otomatik ölçmek zor; sette bu amaçla ayrılmış beş örneği elle okumak pratik bir çözüm.

Bu kontroller aynı zamanda model karşılaştırmasının en ayırt edici kısmı olabiliyor: İngilizcede eşit görünen iki model, Türkçe çıktıda belirgin biçimde ayrışabiliyor.

Seti nerede tutmalı?

Değerlendirme seti bir belge değil, kodun parçası. Üç pratik kural işe yarıyor:

• Depoda tutun. Örnekler ve beklenen çıktılar, uygulamanın kaynak koduyla aynı depoda dursun. Böylece istem değiştiğinde set de aynı commit'te güncellenir ve ikisi birbirinden kopmaz.
• Müşteri verisini temizleyin. Gerçek kayıtlardan örnek alırken isim, adres, sipariş numarası ve telefon gibi alanları değiştirin. Testin işe yaraması için verinin gerçek olması değil, gerçekçi olması yeterli; kişisel veriyi depoya taşımak gereksiz bir risk.
• Çalıştırmayı tek komuta indirin. Set, iki satır komutla çalışmıyorsa çalıştırılmaz. Sonucu ekrana tablo olarak basan basit bir betik, en pahalı değerlendirme aracından daha çok iş görür.

Ekip halinde çalışıyorsanız sonucu her değişiklikte otomatik çalıştırmak da mümkün. Ama önce elle çalışan bir set kurun; otomasyonu, sete güvendiğinizden emin olduktan sonra ekleyin.

Son bir not: değerlendirme seti kurmak, modele güvenmemek anlamına gelmiyor. Tam tersine, elinizde ölçü olduğunda daha cesur davranabiliyorsunuz. Daha ucuz bir modele geçmeyi, çaba ayarını düşürmeyi ya da istemi sadeleştirmeyi denemek, sonucu görebildiğiniz sürece risksiz bir denemeye dönüşüyor. Ölçüsüz çalışan ekiplerin en pahalı modele yapışıp kalmasının sebebi genellikle güven değil, körlük.

Nereden başlamalı?

Hemen yapılabilecek en küçük iş: son bir ayda modelin yanlış yaptığı 20 vakayı bir dosyaya toplayın, her birinin doğru cevabını yazın, iki modelde çalıştırıp başarı oranını ve görev başına jetonu kaydedin. Bu kadarı bile, bir sonraki duyuru "yüzde 50 daha ucuz" dediğinde ne yapacağınızı bilmeniz için yeterli.