Yapay Zekâda LLM Evals: Chatbot Kalitesini Ölçmek İçin Uygulamalı Rehber

Bir yapay zekâ uygulamasının iyi çalıştığını yalnızca birkaç başarılı demo ile anlayamazsınız. Aynı soru farklı biçimde sorulduğunda, kaynak belge değiştiğinde veya model sürümü güncellendiğinde cevap kalitesi düşebilir. LLM evals, büyük dil modeli (LLM) kullanan uygulamaları ölçülebilir testlerle değerlendirme yöntemidir.

Bu rehberde bir chatbot veya RAG uygulaması için test seti nasıl hazırlanır, doğru değerlendirme kriteri nasıl seçilir, insan ve model destekli puanlama nasıl birleştirilir sorularını ele alacağım. Amaç tek bir modelin “en iyi” olduğunu ilan etmek değil; uygulamanızın kendi kalite hedeflerini düzenli olarak ölçmektir.

LLM evals nedir?

LLM evals, bir modelin ya da model tabanlı uygulamanın belirli görevlerde beklenen davranışı ne kadar iyi karşıladığını ölçen değerlendirme paketidir. Bu paket genellikle örnek girdilerden, beklenen davranış açıklamalarından, puanlama kurallarından ve raporlama adımlarından oluşur.

Geleneksel birim testinde beklenen çıktı çoğu zaman nettir. Yapay zekâda ise aynı soruya anlamı koruyan birden fazla doğru cevap verilebilir. Bu yüzden sadece metinlerin birebir eşleşmesine bakmak yerine, cevabın doğru bilgi içerip içermediği, soruyla ilgili olup olmadığı, güvenli davranıp davranmadığı ve istenen formatı koruyup korumadığı da ölçülür.

Neden yapay zekâ uygulamalarını test etmek gerekir?

LLM çıktıları küçük değişikliklerden etkilenebilir. Sistem promptunun bir cümlesi, model sürümü, temperature değeri, RAG arama sonucu veya araç tanımındaki bir değişiklik kullanıcıya farklı cevap döndürebilir. Canlıda fark edilen bir hata ise yalnızca bir ekran hatası değildir; yanlış yönlendirme, güvenlik açığı veya müşteri memnuniyetsizliği oluşturabilir.

LLM evals size şu sorulara veriyle cevap verme imkânı sağlar:

• Yeni model sürümü önceki sürümden daha doğru mu?
• RAG sistemi doğru belgeyi bulup cevaba yansıtıyor mu?
• Chatbot bilmediği konuda uydurma cevap vermek yerine sınırını belirtiyor mu?
• Function calling kullanan ajan doğru aracı, doğru parametreyle seçiyor mu?
• Structured output beklenen JSON şemasını koruyor mu?
• Prompt değişikliği kaliteyi artırırken güvenlik veya gecikme sorununa yol açıyor mu?

İyi bir eval setinin temel parçaları

1. Temsilî test girdileri

Test sorularını yalnızca kolay örneklerden seçmeyin. Gerçek kullanıcıların sorduğu kısa, uzun, eksik, yazım hatalı ve bağlama dayalı soruları karıştırın. Bir destek botunda ürün iadesi, teslimat gecikmesi, hesap erişimi ve konu dışı istekler ayrı örnek grupları olarak tutulabilir.

2. Beklenen davranış

Her satır için tek bir ideal cümle yazmak yerine, modelin sağlaması gereken davranışı tanımlayın. Örneğin “Politikadaki iade süresini doğru söylemeli, kaynakta yoksa kesin süre uydurmamalı ve gerekirse destek kanalına yönlendirmeli” daha kullanışlı bir beklentidir.

3. Değerlendirme kriterleri

Her kriteri ölçülebilir ve birbiriyle karıştırılmayacak şekilde yazın. Doğruluk ile üslup aynı puana bağlanırsa hangi değişikliğin sonucu etkilediğini anlamak zorlaşır. Uygulamaya göre aşağıdaki kriterlerden bir seçki oluşturabilirsiniz:

• Doğruluk: Cevap verilen bilgi test verisi veya güvenilir kaynakla uyumlu mu?
• Alaka: Yanıt doğrudan soruyu karşılıyor mu, gereksiz sapıyor mu?
• Kaynağa bağlılık: RAG cevabı getirilen belgede destekleniyor mu?
• Güvenlik: Zararlı, özel veya yetkisiz bir istekte doğru sınırı koruyor mu?
• Biçim: JSON, madde listesi veya tablo gibi istenen format korunuyor mu?
• Araç kullanımı: Ajan doğru aracı ve parametreleri seçiyor mu?

4. Puanlama ölçeği

Başlangıç için üç seviyeli bir ölçek yeterlidir: 0 başarısız, 1 kısmen başarılı, 2 beklenen davranışı karşılıyor. Her puanın ne anlama geldiğini kısa örneklerle açıklayın. Böylece farklı değerlendiriciler aynı cevaba daha tutarlı puan verir.

Basit bir test veri seti nasıl hazırlanır?

Test verisini JSONL, CSV veya veritabanında tutabilirsiniz. Her kayıtta kullanıcı girdisi, bağlam, beklenen davranış, etiket ve varsa risk seviyesi bulunabilir. Etiketler sayesinde sadece genel ortalamayı değil, örneğin “iade”, “RAG”, “güvenlik” veya “uzun bağlam” dilimlerini de ayrı analiz edersiniz.

{
  "input": "Ürünü kaç gün içinde iade edebilirim?",
  "context": "İade politikası: Kullanılmamış ürünler 14 gün içinde iade edilebilir.",
  "expected_behavior": "14 günlük süreyi doğru söyle; koşul yoksa ekleme yapma.",
  "criteria": ["doğruluk", "kaynağa bağlılık", "biçim"],
  "slice": "iade-politikasi",
  "risk": "orta"
}

İlk sürümde 20 veya 30 örnekle başlayabilirsiniz. Ancak canlıya çıkmadan önce test setini gerçek konuşmalardan, başarısız örneklerden ve sınır durumlarından besleyin. Aynı örnekleri sürekli prompt geliştirmede kullanmak aşırı uyuma yol açabileceği için, mümkünse geliştirme ve son doğrulama setlerini ayırın.

LLM çıktısı nasıl puanlanır?

Deterministik kontroller

Bazı kriterler kodla doğrudan kontrol edilebilir. JSON parse ediliyor mu, zorunlu alanlar var mı, yasaklı bir ifade geçiyor mu, cevap uzunluk sınırını aşıyor mu veya araç adı izin verilen listede mi gibi kontroller deterministik testlerdir. Bu testler hızlıdır ve her çalıştırmada aynı sonucu verir.

Referans tabanlı karşılaştırma

Yanıtın belirli gerçekleri içerip içermediğini kontrol etmek için beklenen cevap, kaynak pasaj veya etiket kullanılabilir. Ancak yalnızca kelime eşleşmesine güvenmeyin. Aynı anlamın farklı cümlelerle ifade edilebildiği görevlerde anlamsal benzerlik ya da kriter tabanlı değerlendirme daha uygundur.

Model destekli değerlendirici

Bir başka model, cevabı belirlediğiniz rubriğe göre 0, 1 veya 2 puanlayabilir. Bu yaklaşım açık uçlu kalite, alaka ve üslup değerlendirmesinde yararlıdır. Değerlendirici promptu kriteri, puan açıklamasını ve mümkünse kısa örnekleri içermelidir. Model destekli puanı tek gerçek kabul etmeyin; örnek bir bölümünü insan incelemesiyle kalibre edin.

İnsan değerlendirmesi

Özellikle güvenlik, hukuki risk, müşteri iletişimi ve yüksek etkili kararlar içeren akışlarda insan kontrolü gerekir. İnsan değerlendiricilerin bir kısmı aynı kayıtları bağımsız puanlarsa kriterlerin ne kadar net olduğunu da görürsünüz. Puanlar çok ayrışıyorsa rubriği sadeleştirin veya kriter tanımına örnek ekleyin.

Regresyon testi ile kaliteyi koruyun

Bir promptu, modeli, RAG retriever’ını veya araç şemasını değiştirdiğinizde aynı eval setini yeniden çalıştırın. Sonuçları önceki sürümle karşılaştırmak regresyon testidir. Genel skor yükselirken güvenlik skorunun düşmesi veya RAG doğruluğu artarken biçim uyumunun bozulması mümkündür.

Bu yüzden tek bir ortalama skorla karar vermeyin. Her kriteri, kullanıcı senaryosunu ve risk dilimini ayrı raporlayın. Kritik bir güvenlik testinin başarısız olması, toplam ortalamadaki küçük artıştan daha önemli olabilir. Üretime alma kararını “bütün kalite kapıları geçti” gibi açık kurallara bağlamak daha güvenlidir.

RAG ve AI ajanları için eval örnekleri

RAG uygulamasında yalnızca son cevabı değil, arama zincirini de değerlendirin. Beklenen belge sonuçlarda var mı, getirilen parçalar soruyla ilgili mi, cevap gerçekten bu parçalara dayanıyor mu ve kaynakta olmayan bilgi ekleniyor mu sorularını ayrı test edin. Belge parçalama yaklaşımını iyileştirmek için RAG chunking rehberine göz atabilirsiniz.

AI ajanlarında test senaryosu; hedef, izin verilen araçlar, beklenen parametreler ve durma koşulunu içermelidir. Ajanın yanlış aracı çağırması, aynı aracı gereksiz tekrarlaması veya kullanıcı onayı gerektiren işlemi doğrudan çalıştırması başarısızlık olarak kaydedilmelidir. Güvenli araç kullanımı için function calling rehberindeki kontrol noktalarını eval setinize taşıyabilirsiniz.

Prompt injection, veri sızıntısı ve yetkisiz talimatlar için ayrıca adversarial testler ekleyin. Bu testler normal kullanıcı örneklerinden ayrı bir güvenlik diliminde tutulmalıdır. Prompt injection rehberi bu senaryoları tasarlarken yardımcı olabilir.

LLM evals için pratik çalışma döngüsü

1. Hedefi yazın: Örneğin “RAG chatbotu kaynakta olmayan süreyi uydurmayacak.”
2. Test dilimlerini belirleyin: Normal sorular, zor sorular, konu dışı istekler ve güvenlik örnekleri.
3. Rubriği oluşturun: Her kriter için 0, 1 ve 2 puanın karşılığını tanımlayın.
4. Başlangıç ölçümünü alın: Mevcut prompt ve modelle eval setini çalıştırın.
5. Tek değişiklik yapın: Prompt, model, retrieval veya araç politikasından yalnızca birini değiştirin.
6. Sonuçları karşılaştırın: Genel skor yanında her dilimdeki düşüşleri de inceleyin.
7. Hataları veri setine ekleyin: Gerçek üretim hatalarını düzenleyerek bir sonraki test sürümüne taşıyın.

Bu döngü, yapay zekâ geliştirmeyi “promptu değiştir ve um” yaklaşımından çıkarıp ölçülebilir bir mühendislik sürecine dönüştürür. OpenAI’nin Evals API’si de veri kaynağı, test kriterleri, grader türleri ve eval çalıştırmaları gibi bileşenleri tanımlamaya yönelik bir yapı sunar; kullandığınız sağlayıcının araçları farklı adlandırılabilir.

Sık yapılan hatalar

• Yalnızca başarılı örnekleri test etmek: Hata ve sınır durumları olmadan skor gerçeği yansıtmaz.
• Tek bir toplam skora bakmak: Güvenlik veya kaynak bağlılığı gibi kritik kriterler ortalamada kaybolabilir.
• Rubriği belirsiz bırakmak: “İyi cevap” ifadesi yerine ölçülebilir koşullar yazın.
• Test setini canlıdan ayırmamak: Geliştirme setine aşırı uyum sağlayan prompt yeni sorularda başarısız olabilir.
• Değerlendirici modeli kalibre etmemek: İnsan puanlarıyla örneklem bazında karşılaştırma yapın.
• Değişiklikleri birlikte yapmak: Model, prompt ve retrieval aynı anda değiştirilirse nedeni bulmak zorlaşır.
• Güvenliği sonradan düşünmek: Zararlı istekleri ilk test sürümünden itibaren eval kapsamına alın.

Yapay zekâ kalite kontrol listesi

• Gerçek kullanıcı sorularından ve sınır durumlarından oluşan bir test setiniz var mı?
• Her test kaydında beklenen davranış ve senaryo etiketi bulunuyor mu?
• Doğruluk, alaka, güvenlik, kaynak bağlılığı ve biçim kriterlerini ayırdınız mı?
• Deterministik kontrolleri model destekli değerlendirmeden ayırıyor musunuz?
• İnsan değerlendirmesiyle rubrik kalibrasyonu yaptınız mı?
• Model veya prompt değişikliğinde aynı regresyon testini yeniden çalıştırıyor musunuz?
• Üretim hatalarını anonimleştirip yeni test örneklerine dönüştürüyor musunuz?

Sonuç

LLM evals, yapay zekâ uygulamalarında kaliteyi sezgiyle değil kanıtla yönetmenizi sağlar. İyi bir eval sistemi; temsilî test verisi, açık bir rubrik, birden fazla puanlama yöntemi ve düzenli regresyon karşılaştırmasından oluşur. Başlangıçta küçük bir set yeterlidir; önemli olan ölçümün her değişiklikten sonra tekrarlanmasıdır.

Bugün bir chatbot veya RAG uygulamanız varsa önce en sık yapılan görevi seçin, 20 gerçekçi örnek hazırlayın ve üç kriterli basit bir rubrik yazın. Sonuçları sürümleyin, başarısız örnekleri inceleyin ve yalnızca tek bir değişiklikten sonra testi tekrarlayın. Bu disiplin, yapay zekâ ürününüz büyürken güvenilirliği korumanın en pratik yollarından biridir.

Kaynak: OpenAI Evals API dokümantasyonu