Evaluation (Değerlendirme) Nasıl Yapılır?

Bir yapay zeka ürünü kurdunuz, RAG mimarinizi ayağa kaldırdınız, prompt'larınızı optimize ettiniz. Sonra bir an durup kendinize soruyorsunuz: "Peki bu şey gerçekten çalışıyor mu?" İşte tam bu noktada evaluation (değerlendirme) meselesi kapıyı çalıyor. Ve itiraf edelim, LLM tabanlı sistemleri değerlendirmek, klasik yazılım testinden çok daha kaygan bir zemin.

Kısaca cevaplamak gerekirse: evaluation için başka bir yapay zekayı hakem olarak kullanabilirsiniz, benzerlik skorları üzerinden ölçüm yapabilirsiniz ama işin gerçeği, özellikle küçük ve düşük riskli ürünler için en sağlam yöntem hâlâ deneme-yanılma. Şimdi bunun neden böyle olduğuna ve nerede hangi yaklaşımın işe yaradığına bakalım.

Yapay Zekayı Yapay Zekaya Ölçtürmek

Evaluation dünyasında bir dönem çok popüler olan bir yaklaşım vardı: LLM'in çıktısını başka bir LLM'e değerlendirtmek. GPT'nin en yaygın model olduğu dönemlerde ortaya çıkan GPT Similarity Score kavramı bunun en bilinen örneği.

Mantık şöyle işliyor: Diyelim ki bir RAG (Retrieval-Augmented Generation) mimarisi kurdunuz. Elinizde eşleştirilmiş soru-cevap çiftleri var, yani "bu soruya ideal cevap şudur" diye bildiğiniz bir referans veri seti. Aynı soruları kendi kurduğunuz mimariden de geçiriyorsunuz ve o da kendi cevaplarını üretiyor. Şimdi elinizde iki set var: referans cevaplar ve modelin ürettiği cevaplar.

Bu ikisini bir üçüncü modele, örneğin ChatGPT'ye veriyorsunuz ve "bana bunların benzerlik skorunu çıkar" diyorsunuz. Model de size bir sayı üretiyor. İşte bu sayı, o dönemde GPT Similarity Score olarak anılıyordu.

Hayatta Kalabilen Çok Az

Bu yaklaşımın türevleri hızla çoğaldı. Farklı isimler, farklı metrikler, farklı ölçüm mantıkları... Ama dürüst olalım, bunların çok azı bugün hâlâ ayakta. Çünkü yapay zekayı başka bir yapay zekaya ölçtürmenin kendi içinde bir sürü tuzağı var:

• Hakem modelin de yanılma payı var.
• Aynı çıktıya farklı zamanlarda farklı skorlar verebilir.
• "Benzer" ile "doğru" her zaman aynı şey değil.

Yine de bu yöntem, tamamen çöp değil. Doğru kurgulandığında, özellikle büyük hacimli çıktıları hızlıca elemek için işe yarayan bir kaba filtre görevi görüyor.

Aslında Zor Olan Kısım: Neyi Ölçüyorsunuz?

Evaluation'ın gerçek zorluğu teknik değil, kavramsal. Sorun şu: neyi, nasıl eval edeceğinizi bilmek, aracı bulmaktan çok daha zor.

Bir chatbot'un cevabının "doğru" olması ne demek? Kullanıcının sorusuna cevap vermiş olması mı? Ton olarak uygun olması mı? Halüsinasyon içermemesi mi? Kaynağa sadık kalması mı? Bunların hepsi farklı metrikler ister ve hepsini aynı anda mükemmel ölçmek çoğu zaman mümkün değil.

Özellikle küçük ekipler, kendi ürününü geliştiren tasarımcılar veya prototip aşamasındaki ekipler için bu "neyi ölçüyorum" sorusu, sonsuz bir tavşan deliğine dönüşebiliyor.

Riskin Boyutu Yönteminizi Belirler

Burada çok kritik bir ayrım var. Evaluation'a ne kadar kasmanız gerektiği, doğrudan ürününüzün risk profiliyle ilgili.

Eğer bir bankacılık ürünü geliştiriyorsanız veya sigorta gibi finansal sonuçları olan bir sektörde çalışıyorsanız, hikaye çok farklı. Modelin yanlış bir bilgi vermesi:

• Şirketin itibarını (reputation) sarsabilir
• Hisse fiyatlarını etkileyebilir
• Regülasyon sorunları doğurabilir
• Milyonlarca kullanıcıyı yanlış yönlendirebilir

Bu tür durumlarda evaluation, üzerinde günlerce, haftalarca çalışılması gereken bir mühendislik problemi. Test setleri, insan değerlendirmesi (human-in-the-loop), otomatik metrikler, red teaming... hepsi devreye giriyor.

Ama ürününüz küçük bir prototipse, iç kullanım için bir asistansa veya deneysel bir tasarım aracıysa? İşte burada gerçekçi olmak lazım.

Küçük Ürünler İçin Dürüst Tavsiye

Küçük ölçekli bir ürün geliştiriyorsanız ve evaluation literatüründe boğulmuş hissediyorsanız, biraz nefes alın. Sofistike metriklerin her birini tek tek uygulamak, sizin ölçeğinizde ciddi bir zaman kaybı olabilir.

En işlevsel yaklaşım genellikle şu: kendiniz deneyin, yanılın, gözlemleyin, iterasyon yapın. Modelin çıktısını gerçek kullanım senaryolarında test edin. Ekipten birkaç kişiyle kör testler yapın. Kullanıcı geri bildirimlerini toplayın. Bunlar, çoğu "fancy" metrikten daha fazla bilgi verecektir.

Bu, evaluation'ı umursamayın demek değil. Bu, evaluation'ı ürününüzün gerçek riskiyle orantılı bir seviyede tutun demek.

Pratikte Nasıl Bir Yol İzlenir?

Somutlaştıralım. Diyelim ki bir UX ekibi olarak müşteri destek verilerinden faydalanan bir iç asistan geliştiriyorsunuz. Kullanıcı sayısı sınırlı, kritik finansal karar aşamalarında değil. Sizin evaluation akışınız şöyle olabilir:

1. 20-50 gerçek soru-cevap çifti hazırlayın. Bunlar sizin "altın standart"ınız.
2. Modelin ürettiği cevapları bu referanslarla karşılaştırın. Önce manuel okuyun.
3. Hacim artınca, benzerlik skoru için bir LLM hakem devreye alın.
4. Gerçek kullanıcı geri bildirimini metriklerin önüne koyun.
5. Modelin nerede sistematik olarak hata yaptığını not edin ve prompt veya retrieval katmanını iyileştirin.

Bu döngü, çoğu küçük-orta ölçekli ürün için fazlasıyla yeterli.

Bunun tersi bir örnek düşünelim: milyonlarca kullanıcıya hizmet veren bir sigorta chatbot'u. Burada aynı basitlikte bir yaklaşım felakete davetiye çıkarır. Otomatik test setleri, düzenli regresyon testleri, insan uzman değerlendirmesi, senaryo bazlı stres testleri... hepsi mecburi hale gelir.

Merak Edilenler

Bir LLM'i başka bir LLM ile değerlendirmek gerçekten güvenilir mi?

Tek başına yeterli değil ama bir katman olarak kullanışlı. Hakem modelin de yanılabileceğini unutmayın, bu yüzden özellikle kritik ürünlerde insan değerlendirmesiyle birlikte kullanılmalı.

GPT Similarity Score hâlâ geçerli bir metrik mi?

O isimle çok konuşulmuyor artık ama arkasındaki mantık, yani model çıktısını referans cevaplarla karşılaştırma fikri hâlâ birçok evaluation framework'ünün temelinde var.

Küçük bir ürün için hiç mi evaluation yapmayayım?

Hayır, tam tersine yapın ama abartmayın. Deneme-yanılma yaklaşımı, kendi başına bir tür evaluation'dır. Önemli olan çıktıları gözlemlemeye ve iyileştirmeye devam etmek.

Riski nasıl anlarım?

Şu soruyu sorun: Modelim yanlış bir cevap verirse en kötü ne olur? Cevap "kullanıcı biraz kafası karışır" ise düşük risk. Cevap "şirket para veya itibar kaybeder, insanlar zarar görür" ise yüksek risk. Evaluation yatırımınızı buna göre ayarlayın.

Hangi metrikten başlamalıyım?

Basit tutun. Elle yazılmış referans cevaplarla model cevaplarını karşılaştırın. Görsel olarak inceleyin. Hacim büyüdükçe otomasyona geçin.

Ölçmek Değil, Öğrenmek

Evaluation'ı bir sınav gibi düşünmek yerine, bir öğrenme süreci gibi görmek çok daha sağlıklı. Amaç, modele bir not vermek değil; modelin nerede nasıl davrandığını anlamak.

Büyük ve riskli ürünler için bu süreç ciddi bir mühendislik yatırımı gerektirir. Küçük ve düşük riskli ürünler içinse en değerli araç, sizin gözleminiz ve iterasyon disiplininizdir. Yani "eval meval" konusuna gömülmeden önce, önce ürününüzü açın, çalıştırın, deneyin ve modelin size ne söylediğine dikkatlice bakın. En iyi evaluation, çoğu zaman en dürüst gözlemden başlar.