Bir süredir çok konuşulmuş ama hâlâ tam çözülememiş bir konuyu kafamda evirip çeviriyorum: Bir model için "aptallaştı" ya da "yine nerf yedi" dediğimizde, bunun ne kadarı gerçek, ne kadarı tek bir örneklemin yarattığı yanılsama?

Son zamanlarda çevremde modellere pelikan testi yaptıran çok kişi var (bisiklet süren bir pelikanı SVG olarak çizdirmek). Bu test gerçekten acımasız: Sadece kod yazmayı değil, uzamsal konumlandırmayı da ölçüyor — gaga ve gidon, ayaklar ve pedallar, kadro ve tekerlekler. Modelin uzamsal kavrayışı biraz zayıf kaldığı anda ortaya oldukça soyut bir şey çıkıyor.

Ama testi birkaç düzine kez çalıştırdıktan sonra fark ettim ki pelikan testinin en büyük tuzağı, tek bir çıktıya bakıp iyi ya da kötü demek.

LLM'ler zaten rastlantısallık içeren olasılıksal örnekleyiciler. Aynı Prompt ile model bir seferinde uzamsal algıda tam puan alıp kadroyu, krankları ve ayak konumunu kusursuz yapabiliyor; başka bir zaman tekrar çalıştırınca birden postmodern soyut sanata dönüşebiliyor. A sağlayıcısında 20 denemenin 16'sında duruş genel olarak mantıklıysa, B sağlayıcısında ise 20'de yalnızca 8'i geçiyorsa, işte o zaman farkın istatistiksel bir anlamı olur. Rastgele alınmış tek bir ekran görüntüsüyle "A tam güç, B sulandırılmış" demek aslında yazı tura atmaktan farksız.

Gerçekten bir şey karşılaştırmak istiyorsanız ortak bir Baseline şart: Model sürümünü, düşünme (reasoning) seviyesini, Prompt'u ve zaman aralığını sabitleyip önce bir referans noktası koymak, sonrasında tüm verilere göreli farklar üzerinden bakmak gerekiyor.

Fakat bu, insanı epey uğraştıran birkaç mühendislik detayını da beraberinde getiriyor:

1. Bu pelikanı nasıl puanlayacağız? Tamamen insan gözüyle değerlendirme ölçeklenemiyor; tamamen LLM-as-a-judge'a bırakınca da kendini övmeye aşırı meyilli oluyor. Şimdilik bunu dört alt boyuta ayırmak gerekiyor gibi görünüyor: Pelican (bütünlük), Bicycle (geometrik yapının tutarlılığı), Riding (pelikanla bisikletin bağlanması / uzamsal oturması) ve Animation (hareket ve iç içe geçme). Bunu da görsel bir Judge + SVG DOM üzerinde statik kurallarla çapraz doğrulamak lazım.

2. Test sorularının ömrü. Hangi "efsane soru" yayılırsa yayılsın, er ya da geç eğitim verisine karışıyor ya da hedefli fine-tuning ile kapatılıyor. Uzun vadede tek bir soruya güvenmek olmaz; uzamsal ilişkileri, talimat takibini ve yapısal akıl yürütmeyi kapsayan dinamik bir test (probe) havuzu gerekiyor.

Bir süre bu testleri modelleri kontrol etmek için elle çalıştırdım ve en büyük dert kayıt tutmanın maliyetiydi: tekrar tekrar çalıştırmak, SVG'leri kaydetmek, parametreleri not almak, zaman damgalarını hizalamak… birkaç düzine setten sonra insan bıkıyor. Asıl zamanı yiyen çoğu zaman testin kendisi değil, etrafındaki o ufak tefek kayıt ve düzenleme işleri. Ama sadece farklı modellerin nasıl performans gösterdiğine hızlıca bakmak istiyorsanız her şeyi kendiniz yapmanıza gerek yok; Folkbench'te (https://folkbench.com/?utm_source=luntan&utm_campaign=donanimhaber) hazır bir sıralama tablosu var, epey zaman kazandırıyor.

Bu testle uğraşan varsa test yöntemlerinizi ya da en absürt sonuçlarınızı paylaşırsanız sevinirim.