LLM Evals Nedir? Yapay Zeka Çıktısını Ölçmek ve LLM-as-a-Judge

LLM evals nedir?

LLM evals, bir yapay zeka uygulamasının ürettiği cevapları önceden hazırlanmış bir test setiyle ve açık ölçütlerle sistematik biçimde ölçme yöntemidir. Eval, İngilizce evaluation yani değerlendirme sözcüğünün kısaltmasıdır. Amaç, uygulamanın iyi çalıştığını hissetmek yerine bunu tekrar edilebilir biçimde göstermektir.

Bir benzetme yapalım. Bir restoranın mutfağında şef her tabağı tadarak kontrol eder, ama sipariş sayısı artınca bu yeterli olmaz. Bu yüzden tarif kartları, tadım kriterleri ve rastgele kontroller devreye girer. Evals de yapay zeka uygulamasının tarif kartı ve kalite kontrol sürecidir.

Bu yazıda terimi adım adım açıyoruz. Önce neden gerekli olduğuna, ardından test seti ve ölçüt kavramlarına bakacağız. Sonra LLM-as-a-judge yaklaşımını ve hakem modelin önyargılarını ele alacağız. Son olarak benchmark farkını, karşılaştırma tablosunu ve pratik bir kontrol listesini paylaşacağız. Kısacası LLM evals nedir sorusuna hem kavramsal hem uygulamalı bir cevap veriyoruz.

LLM evals nedir ve klasik yazılım testinden farkı ne?

Klasik yazılım testinde aynı girdi her zaman aynı çıktıyı verir. Bir toplama fonksiyonuna iki ile üç verdiğinizde cevap beştir ve test bunu kolayca doğrular. Dil modellerinde ise aynı soruya her seferinde biraz farklı, ama yine de doğru olabilecek cevaplar gelir.

Bu yüzden eval, birebir eşleşme aramaz. Cevabın doğru, kaynağa uygun ve istenen tonda olup olmadığına bakar. Ayrıca tek bir cevaba değil, çok sayıda örnek girdinin ortak davranışına bakarsınız.

Farkı üç noktada özetleyebiliriz:

• Çıktı kesin değil olasılıksaldır, bu yüzden ölçüt "eşit mi" yerine "kabul edilebilir mi" sorusudur.
• Başarı tek bir sayı değil, birden fazla boyutun birleşimidir.
• Test yalnızca kod değiştiğinde değil, istem, model ya da veri değiştiğinde de yeniden koşar.

Bu nedenle evals, birim testin yerine geçmez, onu tamamlar. İki katmanı birlikte kurmak, hem kodun hem de dilin kalitesini güvence altına alır. Fonksiyon çağrıları, API bağlantıları ve biçim doğrulaması hâlâ klasik testlerle kontrol edilir. Dil kalitesini ise evals ile ölçersiniz.

Yapay zeka uygulamalarında sessiz bozulma nedir, neden evals gerekir?

Sessiz bozulma, hiçbir hata mesajı vermeden cevap kalitesinin düşmesidir. Sistem çalışır, sayfa açılır, cevap gelir. Ancak cevap eskisinden daha belirsiz, daha uzun ya da daha az doğru olabilir.

Bunun tipik üç tetikleyicisi vardır. İlki istemde yaptığınız küçük bir düzenlemedir. Bir cümleyi daha kibar yapmak, başka bir kuralı zayıflatabilir. İkincisi sağlayıcının modeli güncellemesi ya da sizin başka bir modele geçmenizdir. Üçüncüsü ise bilgi tabanınıza eklenen yeni belgelerdir.

Örneğin bir e-ticaret sitesinin ürün açıklaması asistanı düşünün. İstemi kısaltırsınız, çünkü maliyeti düşürmek istersiniz. Asistan çalışmaya devam eder, ama iade koşullarını artık bazen atlar. Bunu fark etmenin tek yolu, aynı sorularla önce ve sonra ölçüm yapmaktır.

Dolayısıyla evals, bir yapay zeka ürününün sigorta poliçesi gibi değil, pusulası gibi çalışır. Hatayı önlemez, ama yönünüzün değiştiğini erken gösterir. Güncel model özelliklerini sağlayıcının resmi belgesinden kontrol edin, çünkü davranış farkları zamanla değişebilir.

Test seti (altın veri) nedir ve nasıl hazırlanır?

Test seti, uygulamanıza gerçekten sorulacak girdilerden ve her biri için "iyi cevap neye benzer" bilgisinden oluşan listedir. Sektörde buna altın veri (golden dataset) denir. Altın sözcüğü, bu örneklerin güvenilir referans kabul edilmesinden gelir.

İyi bir test seti için şu adımları izleyebilirsiniz:

1. Gerçek kullanıcı sorularını toplayın. Kişisel veri içeren kayıtları temizleyin ya da anonimleştirin.
2. Soruları gruplayın: sık gelenler, zor olanlar, belirsiz olanlar ve uç durumlar.
3. Her soru için beklenen cevabı ya da cevabın taşıması gereken özellikleri yazın.
4. Kapsam dışı soruları da ekleyin, çünkü uygulamanın "bilmiyorum" diyebilmesi gerekir.
5. Setin sahibini belirleyin ve düzenli olarak gözden geçirin.

Burada altın kural çeşitliliktir. Yalnızca kolay örnekler içeren bir set, her sürümde yüksek görünür ve yanıltır. Gerçek hayattaki imla hataları, eksik cümleler ve alakasız sorular sete girmelidir.

Sentetik veriyle seti genişletebilirsiniz. Ancak sentetik örnekleri mutlaka insan gözüyle kontrol edin. Konuya sentetik veri yazımızdan devam edebilirsiniz.

Hangi ölçütler ölçülür: doğruluk, kaynağa sadakat, ton ve biçim?

Tek bir "kalite puanı" yoktur. Her uygulamanın önemli saydığı boyutlar farklıdır, bu yüzden ölçütleri önce siz tanımlarsınız. Anthropic'in resmi geliştirici belgeleri de başarı ölçütlerinin belirli, ölçülebilir ve uygulamanın amacına uygun olması gerektiğini vurgular.

En sık kullanılan dört ölçüt şunlardır:

• Doğruluk: Cevap olgusal olarak doğru mu ve soruyu gerçekten yanıtlıyor mu?
• Kaynağa sadakat: Cevap, verdiğiniz belgelerde olmayan bir şey uyduruyor mu? RAG sistemlerinde bu ölçüt kritiktir.
• Ton: Cevap markanızın sesine ve müşterinin beklentisine uyuyor mu?
• Biçim: Cevap istenen yapıda mı, örneğin belirli alanlar, uzunluk sınırı ya da liste düzeni var mı?

Bunlara tutarlılık, gecikme ve maliyet gibi operasyonel ölçütler de eklenebilir. Anthropic belgeleri, çoğu uygulamanın birden fazla ölçütle aynı anda değerlendirilmesi gerektiğini belirtir.

Yanlış bilgi üretimi ayrı bir başlıktır. Yapay zeka halüsinasyonu yazımızda bu riski ayrıntılı anlattık. Burada yalnızca şunu söyleyelim: kaynağa sadakat ölçütü, halüsinasyonu ölçülebilir hâle getirmenin en pratik yoludur.

Otomatik değerlendirme nasıl çalışır?

Otomatik değerlendirme, cevabı bir kural ya da program aracılığıyla puanlamaktır. İnsan her cevabı okumaz, bu yüzden yüzlerce örneği dakikalar içinde çalıştırabilirsiniz. OpenAI'ın eval belgeleri de bu yaklaşımı veri seti, puanlayıcı (grader) ve sonuç analizi üçlüsüyle anlatır.

Başlıca otomatik yöntemler şunlardır:

• Birebir eşleşme: Cevap bir kategori ise (örneğin "olumlu", "olumsuz") beklenen etiketle karşılaştırılır.
• Kural kontrolü: Cevapta zorunlu bir ifade var mı, yasak bir ifade var mı, uzunluk sınırı aşılmış mı diye bakarsınız.
• Anlamsal benzerlik: Cevabın anlamı referans cevaba yakın mı, bunu gömme (embedding) vektörleriyle ölçersiniz.
• Model puanlaması: Başka bir model, cevabı tanımlı bir ölçekle puanlar. Bu yöntemi ayrı bir bölümde anlatıyoruz.

Kural tabanlı yöntemler hızlı, ucuz ve tutarlıdır. Ancak ton, nezaket ya da açıklık gibi öznel nitelikleri yakalayamazlar. Bu yüzden iyi bir eval düzeni, basit kuralları ve model puanlamasını birlikte kullanır.

Önemli bir ilke: önce en ucuz kontrolü çalıştırın. Biçim bozuksa, modelle puanlamanın anlamı kalmaz.

İnsan değerlendirmesi ne zaman şart?

Otomatik yöntemler ölçeklenir, ama insan yargısının yerini tamamen almaz. İnsan değerlendirmesi özellikle üç durumda şarttır.

İlk durum, ölçütün yeni tanımlandığı andır. Hangi cevabın "iyi" sayılacağı konusunda ekip henüz anlaşmadıysa, önce birkaç yüz cevabı insanlar okumalıdır. Bu aşama, ölçütü netleştirir.

İkinci durum, hakem modeli doğrulamaktır. Bir modelin puanları insan puanlarıyla uyuşmuyorsa, o puanlara güvenemezsiniz. Küçük bir örneklemi hem insana hem hakem modele puanlatıp farkı incelersiniz.

Üçüncü durum, yüksek riskli çıktılardır. Hukuki, finansal ya da güvenlik açısından hassas cevaplarda son söz insanda kalmalıdır.

Hangi cevabın insan incelemesine gideceğini seçmek de bir tasarım kararıdır. Pratik bir dağılım şöyle olabilir: otomatik kontroller her değişiklikte, insan incelemesi ise belirli aralıklarla ve rastgele örneklemle çalışır. İnsanlar ayrıca otomatik puanın "iyi" dediği ama müşterinin şikâyet ettiği cevapları incelemelidir. Bu cevaplar, test setinizin en değerli yeni örnekleridir.

LLM-as-a-judge nedir, nasıl çalışır?

LLM-as-a-judge, bir dil modelinin başka bir modelin ya da uygulamanın cevabını hakem olarak puanlaması yaklaşımıdır. Türkçesiyle "hakem model" diyebiliriz. İnsan değerlendirmesinin yavaş ve pahalı olduğu yerde, ölçeklenebilir bir yaklaşım sunar.

Çalışma mantığı basittir. Hakem modele üç şey verirsiniz: soru, değerlendirilecek cevap ve net bir puanlama yönergesi. Model, yönergeye göre bir puan ya da kategori döndürür, çoğu zaman kısa bir gerekçeyle birlikte.

Yaygın üç kullanım biçimi vardır:

• Tekli puanlama: Cevap, örneğin bir ile beş arasında bir ölçekle puanlanır.
• İkili sınıflama: Cevap "kurala uyuyor" ya da "uymuyor" diye işaretlenir.
• İkili karşılaştırma: Hakem, iki cevaptan hangisinin daha iyi olduğunu seçer.

Zheng ve arkadaşlarının "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" makalesi bu yaklaşımı sistematik inceleyen temel kaynaklardandır. Makalenin özetine göre güçlü hakem modeller, insan tercihleriyle yüksek düzeyde örtüşebilir. Aynı özet, hakemlerin bazı önyargılarının ve sınırlı akıl yürütme becerisinin de olduğunu belirtir. Bir sonraki bölüm tam bu konuyu ele alıyor.

Hakem model hangi önyargılara sahiptir?

Hakem model tarafsız bir ölçüm cihazı değildir. Zheng ve arkadaşlarının makalesi, özetinde üç temel önyargıyı adıyla anar: konum önyargısı, uzunluk önyargısı ve kendini kayırma. Ayrıca sınırlı akıl yürütme becerisini de bir kısıt olarak belirtir.

Her birini basitçe açalım:

• Konum önyargısı: İki cevabı yan yana gösterdiğinizde hakem, içeriğe bakmadan belirli sıradaki cevabı tercih edebilir.
• Uzunluk önyargısı: Hakem, daha uzun ve ayrıntılı görünen cevabı, aslında daha iyi olmasa bile yüksek puanlayabilir.
• Kendini kayırma: Hakem model, kendi ürettiğine benzeyen cevapları daha yüksek puanlayabilir.
• Sınırlı akıl yürütme: Matematik ya da çok adımlı mantık gerektiren cevapları hakem de yanlış değerlendirebilir.

Bu önyargılar hakem yaklaşımını geçersiz kılmaz. Ancak puanları mutlak gerçek gibi okumamanız gerektiğini gösterir. Hakem puanı, bir sinyaldir, hüküm değildir.

Ayrıca yapay zeka önyargısı (AI bias) yazımızdaki kavramlar da burada geçerlidir. Hakem de bir modeldir ve eğitim verisinden gelen eğilimler taşır.

Puanlama yönergesi hakem model için nasıl yazılır?

Hakem modelin kalitesi büyük ölçüde yönergenin kalitesine bağlıdır. "Cevabı değerlendir" gibi muğlak bir talimat, her çalıştırmada farklı puan üretir. Bunun yerine neyin iyi sayılacağını sade cümlelerle tarif edin.

İyi bir yönerge şu parçaları taşır:

• Görev tanımı: Hakemin neyi değerlendirdiğini tek cümleyle söyleyin.
• Ölçüt açıklaması: Örneğin kaynağa sadakat için "cevaptaki her iddia verilen belgede geçmeli" yazın.
• Ölçek tanımı: Her puanın ne anlama geldiğini kısa örneklerle açıklayın.
• Gerekçe isteği: Önce kısa bir gerekçe, sonra puan istemek tutarlılığı artırır.
• Çıktı biçimi: Puanın hangi biçimde döneceğini belirleyin ki program okuyabilsin.

Yönergeyi yazdıktan sonra küçük bir örnek kümesinde deneyin. Hakemin verdiği puanları kendiniz okuyun ve beklentinizle uyuşmayan yerleri yönergeye geri yansıtın. Böylece yönerge de tıpkı kod gibi sürümlenen ve iyileştirilen bir varlığa dönüşür.

Hakem modelin önyargılarını nasıl azaltırsınız?

Önyargıyı tamamen yok edemezsiniz, ama etkisini küçültebilirsiniz. Aşağıdaki adımlar pratikte işe yarayan temel savunmalardır.

1. İkili karşılaştırmada cevapların sırasını değiştirip iki kez puanlatın. Sonuç sıraya göre değişiyorsa, o örneği belirsiz sayın.
2. Yönergede uzunluğun puan nedeni olmadığını açıkça yazın. "Daha kısa ve doğru cevap, uzun ve dağınık cevaptan iyidir" gibi bir kural ekleyin.
3. Hakem olarak, değerlendirilen cevabı üreten modelden farklı bir model kullanın. Anthropic belgeleri de değerlendirme için üretimde kullanılandan farklı bir model seçmeyi önerir.
4. Puanlama ölçeğini dar tutun. Çok ince farklar yerine "geçti, kaldı" gibi net kategoriler daha tutarlıdır.
5. Hakemden önce kısa gerekçe yazmasını isteyin, sonra puan vermesini isteyin.
6. Düzenli olarak küçük bir örneklemi insanlara puanlatın ve hakemle karşılaştırın.

Altıncı adım en önemlisidir, çünkü hakemi hakemden bağımsız bir referansla doğrulamanızı sağlar. İnsan puanıyla uyuşmayan bir hakem yönergesini revize etmeden kullanmayın.

Regresyon testi mantığı evals'ta nasıl uygulanır?

Regresyon testi, yaptığınız bir değişikliğin daha önce çalışan bir şeyi bozup bozmadığını kontrol etmektir. Evals'ta mantık aynıdır, yalnızca ölçülen şey dil kalitesidir.

Süreç şöyle işler. Önce mevcut sürümü test setinde çalıştırıp bir referans sonuç alırsınız. Ardından istemi, modeli ya da bilgi tabanını değiştirirsiniz. Sonra aynı seti yeniden çalıştırır ve sonuçları yan yana koyarsınız.

Karşılaştırmada bakılacak şeyler şunlardır:

• Hangi ölçütte düşüş var, hangisinde artış var?
• Düşüş belirli bir soru grubunda mı yoğunlaşıyor?
• Tek tek örnekler incelendiğinde hata biçimi ortak mı?

Bir değişiklik bir ölçütü iyileştirirken başka birini bozabilir. Örneğin ton daha sıcak olur, ama kaynağa sadakat düşer. Bu dengeyi yalnızca ölçerek görürsünüz.

Eşik belirlerken önce "kabul edilebilir en düşük seviye" üzerinde ekipçe anlaşın. Güncel eşik değerlerini kendi risk toleransınıza göre belirleyin; evrensel bir sayı yoktur. Karşılaştırmaların istatistiksel anlamlılığı için A/B testi hesaplama aracımızı kavramsal bir referans olarak kullanabilirsiniz.

LLM evals nedir, benchmark ile aynı şey mi?

Hayır, aynı şey değildir. Benchmark, modelleri genel yeteneklerine göre karşılaştırmak için hazırlanmış, herkese açık standart bir test koleksiyonudur. LLM evals ise sizin uygulamanızın, sizin verinizle ve sizin ölçütlerinizle ölçülmesidir.

Bir benzetme: benchmark, bir sürücünün genel ehliyet sınavıdır. Evals ise o sürücünün sizin şehrinizdeki sevkiyat güzergâhında ne kadar güvenli olduğunu ölçen iç eğitimdir. Ehliyet iyi bir başlangıçtır, ama güzergâhı bilmek anlamına gelmez.

Üç temel fark vardır:

• Kapsam: Benchmark genel görevleri, eval sizin görevinizi ölçer.
• Sahiplik: Benchmark herkese açıktır, eval setiniz size özeldir ve gizli kalabilir.
• Amaç: Benchmark model seçimine ışık tutar, eval ise uygulamanın zaman içindeki kalitesini izler.

Benchmark skorları bir model seçerken faydalı bir ön filtre olabilir. Ancak skorlar hızla eskir ve sizin kullanım durumunuzu temsil etmeyebilir. Güncel sonuçları ilgili sağlayıcının resmi sayfasından kontrol edin, ama son kararı kendi eval setinizle verin.

Evals ile sık karıştırılan terimler nasıl ayrılır?

Alan hızla büyüdüğü için birbirine yakın terimler karışıyor. Aşağıdaki tablo, evals'ı komşu kavramlardan ayırmanıza yardım eder.

Red teaming için AI red teaming yazımıza, guardrails için guardrails yazımıza bakabilirsiniz. Bu iki terim eval düzeninin yanında çalışan ayrı katmanlardır.

Örnek senaryo: müşteri destek asistanını nasıl değerlendirirsiniz?

Bu bir örnek senaryodur, gerçek bir müşteri sonucu değildir. Bir online mağazanın iade ve kargo sorularını yanıtlayan bir destek asistanı olduğunu varsayalım. Asistan, mağazanın politika belgelerinden cevap üretiyor.

Önce test setini kurarsınız. Gerçek destek kayıtlarından kişisel verileri temizleyip sorular çıkarırsınız. Her soru için politika belgesindeki ilgili bölümü referans olarak eşleştirirsiniz. Kapsam dışı sorular da eklersiniz, örneğin hava durumu ya da başka bir markanın politikası.

Sonra ölçütleri seçersiniz:

• Kaynağa sadakat: Cevap, yalnızca politika belgesindeki bilgiyi mi kullanıyor?
• Doğruluk: İade süresi ve koşulları belgeyle uyuşuyor mu?
• Ton: Müşteriye saygılı ve net bir dille mi yazıyor?
• Biçim: Gerekirse adımları numaralı liste olarak veriyor mu?

Ardından kuralla kontrol edilebilenleri (biçim, zorunlu ifadeler) koda, öznel olanları (ton, sadakat) hakem modele bırakırsınız. Her yeni istem sürümünde seti yeniden çalıştırırsınız. Düşüş görürseniz, hangi soru grubunun bozulduğuna bakarsınız. Böylece "bence daha iyi oldu" tartışması, ölçüme dayalı bir karara dönüşür.

RAG ve ajan uygulamalarında evals nasıl farklılaşır?

Basit bir sohbet asistanında yalnızca cevabı ölçersiniz. Ancak RAG tabanlı bir sistemde iki ayrı aşama vardır: doğru belgeyi bulmak ve o belgeye dayanarak cevap yazmak. Bu yüzden iki aşamayı ayrı ayrı değerlendirmeniz gerekir. Arama aşaması kötüyse, en iyi dil modeli bile iyi cevap veremez. RAG kavramını RAG yazımızda anlattık.

RAG için tipik iki soru şudur:

• Bulunan belge parçaları soruyla gerçekten ilgili mi?
• Üretilen cevap yalnızca bu parçalardaki bilgiyi mi kullanıyor?

Ajan uygulamalarında ise ölçülen şey tek bir cevap değil, bir dizi karardır. Ajanın hangi aracı seçtiği, aracı doğru parametrelerle çağırıp çağırmadığı ve görevi makul sayıda adımda bitirip bitirmediği ayrı ölçütlerdir. Dolayısıyla test setinizde yalnızca soru ve cevap değil, beklenen adım dizisi de bulunabilir.

Her iki durumda da ilke aynı kalır. Önce bileşenleri ayrı ölçün, sonra uçtan uca davranışa bakın. Böylece bir hata çıktığında sorunun aramada mı, bağlamda mı yoksa cevap yazımında mı olduğunu hızlıca ayırt edersiniz.

Çevrimdışı ve canlı değerlendirme birlikte nasıl kullanılır?

Çevrimdışı değerlendirme, yayından önce hazır test setiyle yapılan ölçümdür. Canlı değerlendirme ise gerçek kullanıcı trafiğinden örnek alıp aynı ölçütlerle puanlamadır. İkisi birbirinin alternatifi değil, tamamlayıcısıdır.

Çevrimdışı ölçüm hızlı ve güvenlidir. Bir istem değişikliğini kullanıcıya ulaşmadan test edersiniz. Ancak test seti hiçbir zaman gerçek dünyayı tam temsil etmez. Canlı örnekleme ise beklenmedik soru türlerini ortaya çıkarır.

Pratik bir döngü şöyle kurulur:

1. Çevrimdışı setle değişikliği doğrulayın.
2. Değişikliği kademeli olarak yayına alın.
3. Canlı trafikten rastgele örnekler seçip aynı ölçütlerle puanlayın.
4. Düşük puanlı ya da kullanıcı şikâyetli cevapları inceleyin.
5. İlginç vakaları çevrimdışı test setine ekleyin.

Bu döngü, test setinizi her hafta biraz daha gerçekçi hâle getirir. Canlı örneklemede kullanıcı verisini işlerken gizlilik kurallarına uyun ve gerekirse veriyi maskeleyin.

Evals sürecini en sık bozan hatalar hangileridir?

Eval düzenleri genellikle teknik nedenlerle değil, alışkanlık hatalarıyla bozulur. Sahada en sık gördüğümüz sorunlar aşağıdaki gibidir.

• Tek bir ortalama puana bakmak. Ortalama, belirli bir soru grubundaki ciddi çöküşü gizleyebilir. Bu yüzden sonuçları gruba göre kırın.
• Setin sahipsiz kalması. Kimse güncellemediği için set zamanla eskir ve gerçek kullanımdan kopar.
• Hakem yönergesini hiç test etmemek. Belirsiz bir yönerge, tutarsız puan üretir.
• Sonucu kaydetmemek. Hangi istemin hangi puanı aldığını bilmezseniz, geriye dönük karşılaştırma yapamazsınız.
• Ölçüt sayısını şişirmek. Çok fazla ölçüt, sinyali gürültüye çevirir. Üç ile beş iyi seçilmiş ölçüt çoğu zaman yeterlidir.

Bu hataların hepsi süreçle çözülür. Seti bir ürün gibi sahiplenin, sürümleyin ve düzenli gözden geçirin.

Evals sürecinde hangi riskler ve sınırlar var?

LLM evals nedir sorusunu yanıtlarken sınırlarını da anlatmak gerekir. Evals güçlü bir araçtır, ama sınırları vardır. Bunları bilmek, yanlış güven duygusunu önler.

Başlıca sınırlar şunlardır:

• Test seti yanlı olabilir. Yalnızca geçmişte gördüğünüz soruları içerir, yarın gelecek yeni türleri kaçırabilir.
• Ezberleme riski vardır. Aynı seti sürekli kullanıp istemi o sete göre ayarlarsanız, uygulama sette iyi, gerçek hayatta vasat olur. Bu yüzden ayrı bir doğrulama seti saklayın.
• Hakem puanları kusurludur. Önyargılar bölümünde anlattığımız gibi, puanlar insan doğrulaması gerektirir.
• Maliyet ve süre oluşur. Büyük setleri her değişiklikte hakem modelle çalıştırmak masraf demektir. Bu nedenle hızlı bir çekirdek set ve daha geniş bir periyodik set kullanın.
• Ölçüt yanlışsa sonuç da yanlıştır. Yanlış tanımlanmış bir ölçütü mükemmel optimize etmek, yanlış hedefe ulaşmaktır.

Evals bir garanti sunmaz. Hatanın olmadığını değil, bilinen risklerin kontrol altında olduğunu gösterir. Kişisel veri içeren kayıtları test setine alırken veri koruma mevzuatını gözetin; bu yazı hukuki danışmanlık değildir.

Sıcaklık ve istem ayarları eval sonuçlarını nasıl etkiler?

Aynı istemi iki kez çalıştırdığınızda iki farklı cevap alabilirsiniz. Bunun ana nedeni, modelin cevabı üretirken kullandığı rastgelelik ayarlarıdır. Bu yüzden eval sonuçlarını yorumlarken ayarları sabit tutmanız gerekir.

Sıcaklık (temperature) yükseldikçe cevaplar çeşitlenir. Eval için bu, aynı örneğin bir çalıştırmada geçip diğerinde kalabilmesi demektir. Temperature ve top-p yazımızda bu ayarları ayrıntılı anlattık.

Pratik öneriler şunlardır:

• Eval çalıştırmalarında ayarları sabitleyin ve kaydedin.
• Çeşitliliğin önemli olduğu görevlerde her örneği birden fazla kez çalıştırıp sonuçların dağılımına bakın.
• İstem, model adı ve ayarları sonuçla birlikte saklayın. Böylece eski bir sonucu yeniden üretebilirsiniz.

Bağlama ne koyduğunuz da sonucu değiştirir. Bu konuyu bağlam mühendisliği yazımızda ele aldık. Eval, bağlam düzenini de ölçülebilir kılar.

İşletme için LLM evals nedir, pratik kontrol listesi nasıl olmalı?

Küçük bir ekip için LLM evals nedir sorusunun cevabı, mükemmel bir platform kurmak değil, küçük ve düzenli bir alışkanlık başlatmaktır. Aşağıdaki liste, bir başlangıç çerçevesi sunar.

1. Uygulamanın tek cümlelik amacını yazın ve başarı ölçütlerini üç ile beş madde arasında tutun.
2. Gerçek girdilerden bir çekirdek test seti oluşturun; uç durumları ve kapsam dışı soruları ekleyin.
3. Her ölçüt için puanlama yöntemini seçin: kural, anlamsal benzerlik, hakem model ya da insan.
4. Hakem model kullanıyorsanız yönergeyi yazın, sırayı değiştirerek test edin ve insan örneklemiyle doğrulayın.
5. İstem, model ve ayarları sürüm olarak kaydedin.
6. Her değişiklikten önce ve sonra seti çalıştırıp sonuçları karşılaştırın.
7. Canlıdaki hatalı cevapları test setine geri ekleyin.
8. Setin ve ölçütlerin gözden geçirme sıklığını belirleyin.

Bu listeyi bir kez kurduktan sonra, yeni modellere geçmek korkutucu olmaktan çıkar. Çünkü "yeni model bizim işimizde iyi mi" sorusunu görüşle değil ölçümle cevaplarsınız. Güncel model özelliklerini ve koşullarını sağlayıcının resmi belgesinden kontrol edin.

Ekibimiz bu süreçte nasıl destek olur?

Talha Aslan ve ekibi olarak yapay zeka uygulamalarını yalnızca kurmayı değil, ölçmeyi de önemsiyoruz. Çünkü canlıya çıkan bir asistanın kalitesi, kurulduğu günkü haliyle sınırlı kalmaz; her istem ve model değişikliğiyle değişir.

Bu yüzden LLM evals nedir sorusunu bizimle konuşanlara önce kendi kullanım durumlarını sorarız. Ekibimiz, işinize özel test seti tasarımında, ölçüt belirlemede ve değerlendirme düzeninin mevcut iş akışınıza bağlanmasında yardımcı olur. Gerçek verilerinizle çalışırken gizlilik ve veri sınırlarını baştan netleştiririz. Sonuç garantisi vermeyiz; ölçülebilir, tekrar edilebilir ve açıklanabilir bir süreç kurmayı hedefleriz.

Yapay zeka projenizin kapsamını netleştirmek isterseniz yapay zeka danışmanlığı sayfamıza göz atabilirsiniz. Kaynak olarak ise OpenAI'ın eval rehberini, Anthropic'in test geliştirme belgesini ve Zheng ve arkadaşlarının hakem model makalesini öneririz.

Son olarak şunu hatırlatalım: bu yazı genel bilgi amaçlıdır. Model özellikleri ve araç arayüzleri değişebilir, bu yüzden uygulama öncesinde resmî belgeleri kontrol edin. İstem tasarımı tarafı için prompt engineering yazımızı da okuyabilirsiniz.