LLM Değerlendirme (Eval) Rehberi: Metrikler, Benchmark, Kalibrasyon

LLM değerlendirme nedir? LLM değerlendirme (İngilizcesiyle LLM evaluation veya kısaca eval), bir büyük dil modelinin ya da model tabanlı bir uygulamanın çıktı kalitesini tanımlı boyutlarda — doğruluk, tutarlılık, güvenlik, maliyet ve gecikme — sistematik ve tekrarlanabilir biçimde ölçme disiplinidir. Amacı, hangi model, prompt veya mimari kararının kaliteyi artırıp azalttığını öznel bir izlenime değil, kanıta dayanarak bilmektir.

Bir dil modeli etkileyici biçimde akıcıdır; ama akıcılık doğruluk demek değildir. Model kendinden emin bir tonla tamamen yanlış bir cevap üretebilir ve bunu fark etmek, klasik bir yazılım hatasını fark etmekten çok daha zordur çünkü ortada bir istisna, bir çökme yoktur — yalnızca sessizce yanlış bir çıktı vardır. İşte LLM değerlendirme tam olarak bu sessiz hatayı görünür kılan disiplindir. Bu rehberde llm değerlendirme neden kritik olduğunu, hangi boyutların ölçüldüğünü, eval metrikleri nasıl seçildiğini, benchmark ve test seti tasarımını, LLM-as-judge kurulumunu, kalibrasyon ve güvenilirliği, RAG değerlendirmeyi, üretim izleme ile regresyon testini, araç ekosistemini ve yaygın hataları bir AI mühendisi ve danışman titizliğiyle ele alıyoruz.

Tanım

LLM Değerlendirme (LLM Evaluation / Eval)

Bir büyük dil modelinin veya model tabanlı bir uygulamanın çıktı kalitesini tanımlı boyutlarda (doğruluk, tutarlılık, güvenlik, maliyet, gecikme) sistematik ve tekrarlanabilir biçimde ölçme disiplini. Üç temel yöntemden yararlanır: referans-tabanlı metrikler, LLM-as-judge ve insan değerlendirmesi. Sağlam bir LLM değerlendirme kurulumu; temsili bir test seti (benchmark), yöntemin insan yargısıyla örtüşmesini gösteren kalibrasyon ve üretimde sürekli izleme ile regresyon testini içerir.

Ayrıca: LLM evaluation, model değerlendirme, eval, dil modeli değerlendirme, LLM eval

LLM değerlendirme sorusunun en kısa cevabı şudur: bir dil modelinin çıktısının ne kadar iyi olduğunu, öznel his yerine tanımlı ölçütlerle ve tekrarlanabilir bir yöntemle belirleme işi. "Değerlendirme" kelimesi burada gündelik anlamından daha dardır; bir çıktıya "iyi" veya "kötü" demekle kalmaz, bunu neye göre, hangi boyutta, hangi ölçütle söylediğini de tanımlar. Ölçülemeyen bir kalite, yönetilemeyen bir kalitedir.

Bir benzetme yardımcı olur. Bir yazılım ekibi kod yazarken test yazmadan üretime çıkmaz; testler, bir değişikliğin bir şeyi bozup bozmadığını söyler. LLM tabanlı sistemlerde ise çıktı olasılıksaldır ve "doğru cevap" çoğu zaman tek değildir; bu yüzden klasik birim testi yetmez ve yerine bir değerlendirme çerçevesi gerekir. LLM değerlendirme, yapay zeka uygulamalarının "test paketi"dir: modelin ve promptun davranışını sabit örnekler üzerinde ölçer, değişikliklerin etkisini görünür kılar ve regresyonları yakalar.

Bu tanımın kritik bir sonucu şudur: LLM değerlendirme yalnızca modeli değil, tüm uygulamayı ölçer. Aynı model, farklı bir promptla, farklı bir bağlamla veya farklı bir getirme katmanıyla tamamen farklı kalitede çıktı üretir. Bu yüzden "hangi model daha iyi" sorusu kadar "benim uygulamam bu görevde ne kadar iyi" sorusu da önemlidir. Dil modellerinin temelini anlamak için LLM nedir ve modelin metni nasıl işlediğini görmek için token nedir rehberleri iyi bir başlangıçtır.

LLM değerlendirme sorusuna verilecek en ikna edici cevap, onun hangi riski yönettiğini göstermektir. Bir dil modeli tabanlı sistem, üç tür sessiz riske açıktır ve değerlendirme bu üçüne birden yanıt verir.

Birincisi sessiz yanlışlıktır. Klasik yazılımda bir hata bir istisna fırlatır ve loglarda görünür; oysa bir dil modeli, yanlış olduğunda bile akıcı ve kendinden emin bir cevap üretir. Bu tür bir halüsinasyonu yakalamak için özel bir ölçüm gerekir; halüsinasyonun doğasını yapay zeka halüsinasyonu nedir yazısında ele alıyoruz. Değerlendirme olmadan, sistem "çalışıyor gibi görünür" ama gerçekte ne sıklıkla yanıldığı bilinmez.

İkincisi görünmez regresyondur. Bir promptu iyileştirdiğinizde, bir modeli güncellediğinizde veya bir getirme parametresini değiştirdiğinizde, bir davranışı düzeltirken başka bir davranışı bozabilirsiniz. Sabit bir test seti üzerinde çalışan bir LLM değerlendirme çerçevesi olmadan, bu regresyonu yalnızca kullanıcılar şikayet ettiğinde — yani çok geç — fark edersiniz. Değerlendirme, bu bozulmaları üretimden önce yakalar.

Üçüncüsü ölçüsüz karardır. "Hangi model?", "Hangi prompt?", "RAG mı fine-tuning mi?" gibi kararlar, ölçüm olmadan pazarlama iddialarına veya kişisel izlenimlere dayanır. Oysa bu kararların doğru cevabı görevden göreve değişir ve yalnızca sizin verinizde, sizin görevinizde ölçerek bulunabilir. LLM değerlendirme, bu kararları tahminden kanıta taşır. Genel bir kavramsal giriş için LLM değerlendirme nedir yazısına da bakabilirsiniz; bu rehber ise uçtan uca, üretim odaklı bir derinlik sunar.

"İyi çıktı" tek boyutlu bir kavram değildir; bir yanıt doğru ama tehlikeli, hızlı ama yüzeysel, ucuz ama tutarsız olabilir. Bu yüzden olgun bir LLM değerlendirme yaklaşımı, kaliteyi ayrı ayrı ölçülebilen boyutlara ayırır. Bu boyutları bilinçle ayırmak, "sistem iyi mi" gibi bulanık bir soruyu, yanıtlanabilir alt sorulara böler.

Birinci boyut doğruluktur (accuracy / correctness): yanıt olgusal olarak doğru mu, göreve uygun bir çözüm üretiyor mu? Kapalı uçlu görevlerde (sınıflandırma, çıkarım) bu net ölçülür; açık uçlu görevlerde ise doğruluk, dayanaklılık ve kaynak tutarlılığıyla birlikte değerlendirilir. İkinci boyut tutarlılıktır (consistency): aynı veya benzer girdiye sistem kararlı yanıtlar veriyor mu, yoksa çalıştırmadan çalıştırmaya savruluyor mu? Olasılıksal modellerde tutarlılık, güvenilirliğin önemli bir işaretidir.

Üçüncü boyut güvenliktir (safety): sistem zararlı, önyargılı, kişisel veri sızdıran veya manipülasyona açık çıktılar üretiyor mu? Güvenlik değerlendirmesi, prompt injection gibi saldırılara ve istenmeyen davranışlara karşı direnci ölçer; koruma katmanları için guardrail nedir ve saldırı yüzeyi için prompt injection nedir yazıları bağlam sunar. Dördüncü boyut maliyettir: yanıt başına token tüketimi ve dolar maliyeti; çünkü teknik olarak mükemmel ama ekonomik olarak sürdürülemez bir sistem üretimde yaşayamaz. Beşinci boyut gecikmedir (latency): kullanıcı yanıtı ne kadar sürede alıyor; çünkü doğru ama çok yavaş bir yanıt, çoğu senaryoda kullanılmaz.

LLM değerlendirmenin temel boyutları ve ne sorar

Boyut	Ne sorar	Tipik ölçüt	İhmal edilirse
Doğruluk	Yanıt olgusal/göreve doğru mu?	Doğruluk, dayanaklılık, hata oranı	Akıcı ama yanlış çıktı
Tutarlılık	Aynı girdiye kararlı mı?	Varyans, tekrar edilebilirlik	Öngörülemez davranış
Güvenlik	Zararlı/önyargılı/sızdıran mı?	İhlal oranı, red doğruluğu	Risk ve itibar zararı
Maliyet	Yanıt başına ne kadar?	Token/yanıt, dolar/istek	Sürdürülemez ekonomi
Gecikme	Ne kadar sürede yanıt?	p50/p95 gecikme	Kullanılmayan ürün

Bu boyutlar çoğu zaman birbiriyle çelişir: daha güçlü bir model doğruluğu artırır ama maliyeti ve gecikmeyi de artırabilir; daha katı güvenlik filtreleri riski azaltır ama meşru istekleri de reddedebilir. Bu yüzden LLM değerlendirme, tek bir "puan" üretmek değil, bu boyutlar arasındaki dengeyi görünür kılıp bilinçli bir ödünleşim seçmektir. Hangi boyuta ne kadar ağırlık verileceği, kullanım senaryosunun risk profiline bağlıdır.

LLM değerlendirmenin nasıl yapıldığı sorusunun cevabı üç temel yöntemde toplanır: referans-tabanlı metrikler, LLM-as-judge ve insan değerlendirmesi. Bu üçü rakip değil, farklı güç ve zayıflıklara sahip tamamlayıcı araçlardır; olgun bir kurulum üçünü de bir yerde kullanır.

Referans-Tabanlı Metrikler

Referans-tabanlı yöntemde, model çıktısı önceden hazırlanmış bir "altın cevap" ile karşılaştırılır. Karşılaştırma birkaç biçimde yapılabilir: kesin eşleşme (çıktı beklenen cevaba tam uyuyor mu — sınıflandırma ve kısa cevaplı görevlerde), kelime örtüşmesine dayalı ölçütler (çıktı ile referans arasındaki n-gram örtüşmesi) veya gömme (embedding) benzerliği (anlamsal yakınlık). Bu yöntemler hızlı, ucuz ve tekrarlanabilirdir; büyük test setlerinde saniyeler içinde çalışır. Gömme kavramının temeli için embedding nedir yazısına bakabilirsiniz.

Referans-tabanlı metriklerin zayıflığı, tek doğru cevabı olmayan açık uçlu görevlerdir. Bir özetin, bir e-posta taslağının veya yaratıcı bir yanıtın "doğru" versiyonu tek değildir; kelime örtüşmesi düşük olsa bile çıktı mükemmel olabilir. Bu yüzden referans-tabanlı metrikler, kapalı uçlu ve tek cevaplı görevlerde güçlü, açık uçlu görevlerde ise yetersiz kalır.

LLM-as-Judge (Modeli Hakem Yapma)

LLM-as-judge yaklaşımında, güçlü bir dil modeli değerlendirmenin kendisini yapar: bir çıktıyı, verilen bir ölçüte (rubric) göre puanlar veya iki çıktıyı karşılaştırıp hangisinin daha iyi olduğunu söyler. Bu yöntem, açık uçlu görevlerde referans-tabanlı metriklerin çözemediği esnekliği sağlar; çünkü model, kelime örtüşmesine değil anlama ve ölçüte bakar. Son yıllarda ölçeklenebilir değerlendirmenin en yaygın yolu haline gelmiştir çünkü insan hızında değil makine hızında çalışır.

Ama LLM-as-judge körü körüne güvenilecek bir yöntem değildir; kendine özgü önyargıları ve tutarsızlıkları vardır. Bu yüzden ayrı bir bölümde ele alacağımız kadar önemlidir: doğru kurulmazsa, güvenilir görünen ama aslında yanıltıcı puanlar üretir.

İnsan Değerlendirmesi

İnsan değerlendirmesi, altın standarttır: konu uzmanları veya eğitilmiş değerlendiriciler, çıktıları tanımlı ölçütlere göre puanlar. En güvenilir sinyali verir çünkü nihai amaç zaten insan memnuniyetidir. Zayıflığı ise pahalı, yavaş ve ölçeklenmesi zor olmasıdır; ayrıca değerlendiriciler arası tutarlılık (inter-annotator agreement) sağlanmazsa kendisi de gürültülü olabilir. Pratikte insan değerlendirmesi, diğer iki yöntemi kalibre etmek ve en kritik kararları doğrulamak için stratejik biçimde kullanılır — her örnekte değil, örneklem üzerinde.

Üç LLM değerlendirme yönteminin karşılaştırması

Yöntem	Güçlü olduğu	Zayıf olduğu	Tipik kullanım
Referans-tabanlı metrikler	Hızlı, ucuz, tekrarlanabilir	Açık uçlu görevlerde zayıf	Sınıflandırma, kısa cevap, kod testi
LLM-as-judge	Açık uçlu görevde esnek, ölçeklenebilir	Önyargı, tutarsızlık, maliyet	Diyalog, özet, RAG dayanaklılık
İnsan değerlendirmesi	En güvenilir sinyal	Pahalı, yavaş, ölçeklenmesi zor	Kalibrasyon, kritik karar doğrulama

Doğru yaklaşım, bu üç yöntemi bir piramit gibi düşünmektir: tabanı ucuz ve hızlı referans-tabanlı metrikler ve LLM-as-judge oluşturur, tepesinde ise pahalı ama güvenilir insan değerlendirmesi kalibrasyon ve doğrulama için durur. Bu katmanlı yaklaşım, hem ölçeklenebilirliği hem güvenilirliği bir arada sağlar.

Eval metrikleri, bir LLM değerlendirme kurulumunun kalbidir; ama en sık yapılan hata, metrikleri göreve bakmadan seçmektir. Evrensel tek bir metrik yoktur; bir metrik bir görevde altın değerinde, başka bir görevde tamamen yanıltıcı olabilir. Doğru eval metrikleri seçimi, önce görevi ve o görevde "iyi çıktı"nın ne demek olduğunu netleştirmekle başlar.

Süreç şöyle işler: önce görevi sınıflandırın (kapalı uçlu mu açık uçlu mu, tek cevaplı mı çok cevaplı mı), sonra kalite boyutlarını (doğruluk, dayanaklılık, tutarlılık, biçim, güvenlik) ayırın, sonra her boyut için onu gerçekten ölçen bir metrik belirleyin. Örneğin bir sınıflandırma görevinde doğruluk, kesinlik (precision) ve duyarlılık (recall) ile ölçülür; bir özetleme görevinde ise dayanaklılık ve kapsayıcılık, çoğunlukla LLM-as-judge veya insan değerlendirmesiyle ölçülür.

Kritik bir ilke, tek metriğe güvenmemektir. Her metriğin bir kör noktası vardır: kelime örtüşmesi anlamı kaçırır, gömme benzerliği ince olgusal hataları göremez, tek bir LLM-as-judge puanı önyargı taşıyabilir. Bu yüzden birden fazla metriği birlikte okumak, bir metriğin kaçırdığını diğerinin yakalamasını sağlar. Ayrıca metriklerin manipülasyona (gaming) dayanıklı olması gerekir: yalnızca metriği yükseltmek için optimize edilen bir sistem, gerçek kaliteyi değil metriği kandırmayı öğrenebilir.

Eval metrikleri seçiminin son bir boyutu, mutlak skor yerine göreli karşılaştırmaya odaklanmaktır. Bir metriğin mutlak değeri (örneğin "0,72") tek başına çoğu zaman anlamsızdır; asıl değer, iki sistem, iki prompt veya iki model arasındaki farkı ölçmektir. Bu yüzden eval metrikleri, bir taban çizgisiyle birlikte ve zaman içinde bir eğilim olarak okunmalıdır. "A promptu B promptundan bu test setinde tutarlı biçimde daha iyi" ifadesi, "A promptu 0,72 aldı" ifadesinden çok daha kullanışlıdır.

Bir LLM değerlendirme kurulumu ancak dayandığı test seti kadar iyidir. Benchmark (kıyaslama kümesi) ve test seti, sistemin kalitesini üzerinde ölçtüğünüz örnek koleksiyonudur; ve kötü tasarlanmış bir test seti, yanıltıcı bir güven verir — sistem test setinde parlak görünürken üretimde başarısız olur. Bu yüzden test seti tasarımı, değerlendirmenin en yüksek getirili yatırımlarından biridir.

İlk ilke temsililiktir. Test seti, sisteminizin gerçek dünyada karşılaşacağı sorguların dağılımını yansıtmalıdır. Yalnızca kolay ve tipik örneklerden oluşan bir benchmark, gerçek kullanımı temsil etmez ve sahte bir başarı hissi verir. En değerli test seti, gerçek kullanıcı sorularından türetilir; sentetik örnekler başlangıç için yararlı olsa da, gerçek kullanım desenlerinin çeşitliliğini ve tuhaflığını nadiren yakalar.

İkinci ilke zorluk çeşitliliğidir. İyi bir test seti, kolay örneklerin yanında zor ve uç örnekleri de içermelidir: eş anlamlıların kullanıldığı sorular, çok adımlı akıl yürütme gerektiren sorular, nadir terim içeren sorular, belirsiz veya kötü ifade edilmiş sorular ve özellikle cevabı olmayan sorular. Son grup kritiktir çünkü sistemin "bilmiyorum" diyebilme yeteneğini bu örneklerle ölçersiniz; cevabı olmayan bir soruya kendinden emin uydurma yanıt veren bir sistem, test setinde bu kusuru açığa çıkarır.

Üçüncü ilke, sızıntıya ve aşırı uyuma karşı korumadır. Veri sızıntısı (data leakage), test örneklerinin bir şekilde modelin eğitim verisine veya prompt'a karışmasıdır; bu, sistemi olduğundan daha iyi gösterir. Aşırı uyum (overfitting) ise sistemi yalnızca test setinde iyi olacak şekilde ayarlamaktır; bu durumda benchmark artık gerçek kaliteyi değil, o kümeye ne kadar uyulduğunu ölçer. Bu riskleri azaltmak için test setinin bir kısmını "gizli" tutmak ve düzenli olarak yenilemek iyi bir pratiktir. Aşırı uyum kavramını overfitting nedir yazısında ele alıyoruz.

İyi ve kötü test seti (benchmark) özellikleri

Özellik	İyi test seti	Kötü test seti
Dağılım	Gerçek kullanımı yansıtır	Yalnızca kolay/tipik örnekler
Zorluk	Uç ve zor örnekleri içerir	Homojen ve kolay
Cevapsız soru	Bilinçli olarak bulunur	Hiç yok
Sızıntı	Eğitim/prompt'tan izole	Eğitim verisiyle örtüşür
Bakım	Üretimle sürekli büyür	Bir kez kurulup unutulur

Genel akademik benchmark'lar (kamuya açık kıyaslama kümeleri) bir modelin genel yeteneği hakkında fikir verir ama sizin özel görevinizdeki performansı hakkında sınırlı bilgi taşır; üstelik popüler benchmark'lar zamanla eğitim verilerine sızarak anlamını yitirebilir. Bu yüzden genel benchmark sonuçlarını bir başlangıç filtresi olarak kullanın, ama nihai kararı her zaman kendi göreve özel test setinizde ölçün. Sizin benchmark'ınız, sizin kullanım senaryonuzu temsil eden kümedir.

LLM-as-judge, ölçeklenebilir LLM değerlendirmenin bugün en yaygın aracıdır; ama aynı zamanda en çok yanlış kurulan yöntemdir. Bir modeli hakem yapmak cazip biçimde kolaydır — sadece "şu cevabı 1-10 arası puanla" dersiniz — ama bu naif kurulum, güvenilir görünen ama aslında önyargılı ve tutarsız puanlar üretir. LLM-as-judge'ı güvenilir kılmak, birkaç bilinçli tasarım kararı gerektirir.

Önce bilinen önyargıları tanımak gerekir. Konum önyargısı: iki cevap karşılaştırıldığında model, ilk sunulanı sistematik olarak tercih edebilir. Uzunluk önyargısı: daha uzun ve ayrıntılı görünen cevabı, gerçekte daha iyi olmasa bile yüksek puanlama eğilimi. Kendini kayırma (self-preference): bir modelin kendi ürettiği veya kendi ailesinden bir modelin ürettiği metni kayırması. Üslup önyargısı: kendinden emin, akıcı bir tonu doğrulukla karıştırmak. Bu önyargılar, ölçülmezse değerlendirmeyi sessizce bozar.

Neyse ki bu önyargıların çoğu azaltılabilir. Birincisi, net bir puanlama ölçütü (rubric) vermektir: modele "iyi bir cevap şu kriterleri taşır" diye somut, ayrıştırılmış ölçütler sunmak, keyfi puanlamayı azaltır. İkincisi, ikili karşılaştırmalarda cevap sırasını değiştirip her iki yönde de sormak ve tutarlıysa kabul etmektir; bu, konum önyargısını doğrudan hedefler. Üçüncüsü, modelden önce gerekçe, sonra puan istemektir (zincirleme düşünme); bunun mantığını chain-of-thought nedir yazısında ele alıyoruz. Gerekçelendirme, modeli daha dikkatli ve tutarlı puanlamaya iter.

Dördüncü bir güvenilirlik kaldıracı, doğru hakem modeli seçmektir. Genellikle hakem, değerlendirdiği sistemden daha güçlü veya en azından eşit yetenekte bir model olmalıdır; zayıf bir modelin güçlü bir çıktıyı doğru puanlaması zordur. Ayrıca kendini kayırmayı önlemek için, mümkünse hakemi değerlendirilen modelden farklı bir aileden seçmek iyidir. Son olarak, kritik kararlarda tek bir hakem yerine birkaç hakemin oyunu birleştirmek (panel yaklaşımı) tutarlılığı artırabilir. LLM-as-judge, doğru kurulduğunda insan değerlendirmesinin ölçeklenebilir bir yaklaşığı olur; yanlış kurulduğunda ise yanıltıcı bir güven kaynağı.

Kalibrasyon, LLM değerlendirmede iki farklı ama ilişkili anlamda kullanılır ve her ikisi de güvenilirliğin temelidir. Bu iki anlamı ayırmak, değerlendirme kurulumunun neden güvenilir olup olmadığını anlamak için gereklidir.

Birinci anlam, değerlendirme yönteminin kalibrasyonudur: bir metriğin veya LLM-as-judge hakeminin verdiği puanların, insan yargısıyla ne kadar örtüştüğü. Bir eval yöntemi, insan değerlendirmesiyle yüksek uyum gösteriyorsa "kalibre" sayılır; göstermiyorsa, ne kadar zarif görünürse görünsün güvenilmezdir. Bu kalibrasyonu ölçmek için küçük bir insan-etiketli küme kullanılır: hem otomatik yöntem hem de insanlar aynı örnekleri puanlar, sonra aralarındaki korelasyon veya anlaşma hesaplanır. Bu adım, değerlendirmenin kendisini değerlendirmektir — ve sık atlandığı için birçok eval kurulumu sessizce güvenilmezdir.

İkinci anlam, modelin güven kalibrasyonudur: modelin bir cevaba atfettiği güvenin, gerçek doğrulukla ne kadar tutarlı olduğu. İyi kalibre edilmiş bir model, "%90 eminim" dediği durumların yaklaşık %90'ında haklı çıkar; kötü kalibre edilmiş, aşırı özgüvenli bir model ise yanlış olduğunda bile yüksek güven ifade eder. Güven kalibrasyonu önemlidir çünkü kullanıcılar ve otomatik sistemler, modelin güvenine dayanarak karar verir; aşırı özgüvenli bir model, düşük güvenli durumlarda insana devretme (deferral) gibi güvenlik mekanizmalarını da işlevsiz kılar.

Kalibrasyonun iki anlamı ve neyi güvence altına aldığı

Kalibrasyon türü	Neyi ölçer	Kalibre değilse sonucu
Yöntem kalibrasyonu	Eval puanı insan yargısıyla örtüşüyor mu	Yanlış model/prompt seçimi
Model güven kalibrasyonu	Modelin güveni gerçek doğrulukla tutarlı mı	Aşırı özgüven, yanıltıcı kullanıcı deneyimi

Kalibrasyonun pratik değeri, güvenilirliği bir his olmaktan çıkarıp ölçülebilir bir özelliğe dönüştürmesidir. Bir değerlendirme kurulumu için doğru soru "bu metrik iyi mi" değil, "bu metrik insan yargısıyla ne kadar örtüşüyor"dur. Bir model için doğru soru "bu model kendine güveniyor mu" değil, "bu modelin güveni ne kadar hak edilmiş"tir. Bu iki kalibrasyon ölçülmeden, bir LLM değerlendirme kurulumu güvenilir kabul edilemez; çünkü ölçüm aracının kendisi kör olabilir. Değerlendirmeyi değerlendirmek, olgun bir eval disiplininin ayırt edici işaretidir.

İnsan değerlendirmesi en güvenilir sinyali verir ama pahalı, yavaş ve — sık atlanan bir gerçek — kendi başına gürültülü olabilir. İki insan aynı çıktıya farklı puan verebilir; bu yüzden insan değerlendirmesini ölçeklemek, yalnızca daha çok değerlendirici eklemek değil, değerlendirmenin kendisini tutarlı kılmaktır. İyi kurulmuş bir insan değerlendirme süreci, olgun bir LLM değerlendirme çerçevesinin altın standardıdır.

Tutarlılığın temeli, net bir puanlama ölçütüdür (rubric). "Bu cevap iyi mi" gibi bulanık bir soru, değerlendiriciden değerlendiriciye savrulur; oysa "cevap soruyu karşılıyor mu, kaynağa dayanıyor mu, biçim doğru mu" gibi ayrıştırılmış ölçütler, öznelliği azaltır. Rubric ne kadar somut ve örneklerle desteklenirse, değerlendiriciler arası tutarlılık (inter-annotator agreement) o kadar yükselir. Bu tutarlılığı bir sayı olarak ölçmek — birden çok değerlendiricinin aynı örneklerde ne kadar anlaştığını hesaplamak — insan değerlendirmesinin kendisini değerlendirmenin yoludur.

İkinci ilke, doğru görev tasarımıdır. Mutlak puanlama (bir çıktıya 1-5 arası puan) çoğu zaman ikili karşılaştırmadan (iki çıktıdan hangisi daha iyi) daha gürültülüdür; çünkü insanlar mutlak bir ölçekte tutarsız, ama "A mı B mi" sorusunda daha kararlıdır. Bu yüzden birçok olgun kurulum, insan değerlendirmesini karşılaştırmalı biçimde tasarlar. Ayrıca değerlendiricilere yeterli bağlam vermek, örnekleri rastgele sıralamak (sıra önyargısını kırmak için) ve düzenli kalibrasyon oturumları yapmak, gürültüyü azaltır.

İnsan değerlendirmesini ölçeklemenin bir başka yolu, aktif öğrenme mantığıdır: her örneği değil, otomatik yöntemin en emin olmadığı veya en çok anlaşmazlık çıkan örnekleri insana yönlendirmek. Böylece sınırlı insan emeği, en çok değer ürettiği belirsiz bölgeye odaklanır. İnsan değerlendirmesi, LLM değerlendirmenin en pahalı ama en güvenilir katmanıdır; onu israf etmemek, akıllıca yerleştirmek gerekir.

LLM değerlendirmede giderek yaygınlaşan bir yaklaşım, mutlak puan yerine karşılaştırmalı değerlendirmedir: bir çıktıya soyut bir "7/10" vermek yerine, iki çıktıdan hangisinin daha iyi olduğunu sormak. Bu, hem insan hem LLM-as-judge değerlendirmesinde daha kararlı sonuç verir çünkü göreli yargı, mutlak yargıdan daha kolay ve tutarlıdır. "Bu cevap ne kadar iyi" sorusu belirsizdir; "A mı yoksa B mi daha iyi" sorusu ise nettir.

İkili karşılaştırma (pairwise comparison), iki sistemin veya iki promptun çıktılarını aynı sorular üzerinde yan yana koyup hangisinin kazandığını saymaktır. Yeterli sayıda karşılaştırma yapıldığında, bir kazanma oranı ortaya çıkar: "A promptu, B promptuna karşı örneklerin %62'sinde tercih edildi." Bu, mutlak bir metrik puanından çok daha yorumlanabilir ve karar verdiricidir; çünkü doğrudan "hangisini seçmeliyim" sorusuna cevap verir.

Çok sayıda sistemi karşılaştırmak gerektiğinde, ikili karşılaştırmalar bir Elo derecelendirmesine (satrançtan ödünç alınan puanlama sistemi) dönüştürülebilir. Her sistem, diğerlerine karşı kazandıkça bir Elo puanı biriktirir; sonuçta sistemleri sıralayan bir liderlik tablosu (leaderboard) oluşur. Bu yaklaşım, topluluk temelli model karşılaştırmalarında yaygınlaşmıştır çünkü çok sayıda modeli ortak bir ölçekte sıralamayı mümkün kılar.

Mutlak (pointwise) ve karşılaştırmalı (pairwise) değerlendirme

Boyut	Mutlak puanlama	Karşılaştırmalı (pairwise)
Soru	Bu çıktı kaç puan?	A mı B mi daha iyi?
Tutarlılık	Daha gürültülü	Daha kararlı
Yorumlanabilirlik	Soyut skor	Doğrudan tercih
Çok sistem sıralama	Zor	Elo/liderlik tablosu ile kolay
Zayıflık	Ölçek kayması	Çok karşılaştırma gerekir

Karşılaştırmalı değerlendirmenin bir dikkat noktası, karşılaştırma sayısının sistem sayısıyla hızla artmasıdır; ve LLM-as-judge ile yapılıyorsa, daha önce anlatılan konum ve uzunluk önyargılarının burada da geçerli olduğudur. Bu yüzden cevap sırasını değiştirip iki yönde de sormak, karşılaştırmalı değerlendirmede özellikle önemlidir. Doğru kurulduğunda pairwise yaklaşım, bir LLM değerlendirme kurulumunun en karar-odaklı ve en yorumlanabilir aracıdır.

Kurumsal LLM uygulamalarının büyük kısmı bir RAG (Retrieval-Augmented Generation, bilgi getirimiyle üretim) mimarisi üzerine kuruludur; ve RAG değerlendirme, klasik model değerlendirmesinden farklı, iki katmanlı bir yaklaşım gerektirir. RAG kavramının temeli için RAG nedir ve mimariyi kurma için RAG mimarisi nasıl kurulur yazılarına bakabilirsiniz; burada değerlendirme boyutuna odaklanıyoruz.

RAG değerlendirmenin birinci katmanı getirme (retrieval) kalitesidir: sistem, soruya cevap veren doğru belge parçalarını bulabiliyor mu? Bu katman modelden bağımsızdır ve klasik bilgi getirme metrikleriyle ölçülür. Recall, ilgili parçaların ne kadarının aday listesine girdiğini; precision, getirilen parçaların ne kadarının gerçekten ilgili olduğunu ölçer. MRR (ortalama karşılıklı sıra) ilk doğru parçanın ortalama kaçıncı sırada geldiğini, nDCG ise sıralamanın kalitesini alaka derecesiyle ağırlıklandırarak değerlendirir. Bu metrikleri hesaplamak için, her test sorusu için hangi parçaların doğru cevabı içerdiği önceden işaretlenmiş bir test seti gerekir.

İkinci katman üretim (generation) kalitesidir: getirilen bağlamdan iyi bir yanıt üretildi mi? Burada üç boyut öne çıkar. Dayanaklılık (groundedness / faithfulness): yanıt gerçekten getirilen belgeye mi dayanıyor, yoksa uyduruyor mu — bu, halüsinasyonu doğrudan yakalar. Alaka (relevance): yanıt kullanıcının sorusunu gerçekten karşılıyor mu. Doğruluk (correctness): yanıt olgusal olarak doğru mu. Bu boyutlar çoğunlukla LLM-as-judge ile ölçülür çünkü açık uçludurlar; ama hakem, önceki bölümde anlatıldığı gibi kalibre edilmelidir.

RAG değerlendirmenin ölçekli hali, üretimde sürekli izlemeyi de kapsar: gerçek kullanıcı sorularından örnekleme, çevrimiçi dayanaklılık puanlaması ve "cevap bulunamadı" oranının takibi. Getirme kalitesini artıran bileşenlerden biri olan yeniden sıralama için reranker nedir ve bağlam sınırının etkisi için context window nedir yazıları, değerlendirmede hangi kaldıraçların ölçüleceğini anlamak için yararlıdır. RAG değerlendirme, bir kez kurulup bırakılan değil, bilgi tabanı değiştikçe tekrarlanan sürekli bir disiplindir.

Tek bir soru-cevap turunun ötesine geçen ajan (agent) sistemleri — araç çağıran, çok adım planlayan ve kendi kararlarını veren yapılar — değerlendirmeye yeni bir zorluk katar. Bir ajanı değerlendirmek, yalnızca son cevaba bakmakla olmaz; ajanın izlediği yolun (trajectory) her adımı da ölçülmelidir. Ajan mimarilerinin ne olduğunu agentic AI nedir ve AI agent nedir yazılarında ele alıyoruz; burada değerlendirme boyutuna odaklanıyoruz.

Ajan değerlendirmesinde iki katman vardır. Birincisi sonuç (outcome) değerlendirmesi: ajan görevi başarıyla tamamladı mı, nihai çıktı doğru mu? Bu, klasik çıktı değerlendirmesine benzer. İkincisi ve daha zor olanı süreç (trajectory) değerlendirmesidir: ajan doğru araçları mı çağırdı, adımları mantıklı sıraladı mı, gereksiz döngülere girdi mi, ve doğru sonuca doğru nedenlerle mi ulaştı? Bir ajan yanlış adımlarla doğru sonuca ulaşabilir (şans eseri) veya doğru adımlarla yanlış sonuca varabilir; bu yüzden yalnızca sonuca bakmak yanıltıcıdır.

Süreç değerlendirmesi için birkaç boyut öne çıkar. Araç seçim doğruluğu: ajan her adımda doğru aracı mı seçti? Argüman doğruluğu: araçlara doğru parametreleri mi verdi? Verimlilik: görevi minimum adımda mı yoksa gereksiz gezinerek mi tamamladı? Ve kurtarma (recovery): bir araç hata döndürdüğünde ajan durumu düzeltebildi mi? Bu boyutları ölçmek için, ajanın her adımını kaydeden bir trace ve bu trace'i puanlayan (çoğu zaman LLM-as-judge tabanlı) bir değerlendirme gerekir.

Ajan sistemlerinin değerlendirmesi henüz olgunlaşmakta olan bir alandır ve standart metrikleri klasik LLM değerlendirmesinden daha az yerleşiktir. Pratik bir başlangıç, ajanın çözmesi beklenen görevlerden oluşan bir test seti kurmak, her görev için hem başarı ölçütünü hem ideal adım dizisini işaretlemek ve trace'leri düzenli incelemektir. Ajan karmaşıklaştıkça, değerlendirmenin de katmanlanması gerekir; çünkü ölçülmeyen bir ajan, üretimde öngörülemez davranışın en yüksek kaynağıdır.

Çevrimdışı test kümeleri değerlendirmenin temelidir ama tek başına yeterli değildir; çünkü üretimde gerçek kullanıcılar, test setinizin öngörmediği sorular sorar. Üretimde LLM değerlendirme, laboratuvar koşullarından canlı ortama geçiştir ve iki tamamlayıcı mekanizma gerektirir: regresyon testi ve canlı izleme.

Regresyon testi, sabit bir test seti üzerinde her değişiklikte otomatik çalışan bir kalite kapısıdır. Bir model güncellendiğinde, bir prompt değiştirildiğinde veya bir getirme parametresi ayarlandığında, bu test seti çalışır ve daha önce doğru çalışan bir davranışın bozulup bozulmadığını (regresyon) yakalar. Bu, yazılımdaki birim testinin LLM karşılığıdır: bir iyileştirmenin başka bir yeri gizlice bozmasını üretimden önce açığa çıkarır. Regresyon test seti, özellikle kritik ve yüksek riskli senaryoları kapsamalıdır; çünkü bu senaryolardaki bir bozulmanın maliyeti en yüksektir.

Canlı izleme ise gerçek trafiğin sürekli gözlemlenmesidir. Bu, birkaç mekanizmayı içerir: üretim trafiğinden örnekleme ve bu örneklere çevrimiçi LLM-as-judge puanlaması uygulama; kullanıcı geri bildirimi toplama (başparmak yukarı/aşağı, düzeltme, terk etme); ve kayma (drift) tespiti — kullanıcı sorularının deseni veya çıktı kalitesi zamanla değişiyor mu. Bir dil modeli sistemini izlemenin ayrıntısını LLM gözlemlenebilirliği nedir ve operasyon disiplinini LLMOps nedir yazılarında ele alıyoruz.

Nasıl Yapılır

Üretimde LLM değerlendirme döngüsü

Bir LLM uygulamasını üretimde sürekli değerlendirmek için kurulan geri bildirim döngüsünün adımları.

1. 1

   Regresyon test seti oluştur

   Kritik senaryoları kapsayan, her değişiklikte otomatik çalışan sabit bir test seti hazırla.

2. 2

   Değişiklik kapısı kur

   Her model/prompt değişikliğini bu test setinden geçmeden üretime alma; regresyonları erken yakala.

3. 3

   Canlı trafikten örnekle

   Gerçek kullanıcı etkileşimlerinden düzenli örnekler al ve trace olarak kaydet.

4. 4

   Çevrimiçi puanla

   Örneklere kalibre edilmiş LLM-as-judge ve kullanıcı geri bildirimi uygula.

5. 5

   Kayma ve başarısızlığı izle

   Kalite düşüşünü ve değişen soru desenlerini kullanıcı şikayet etmeden önce yakala.

6. 6

   Test setini büyüt

   Üretimden gelen başarısız örnekleri test setine ekleyerek değerlendirmeyi sürekli güçlendir.

Bu döngünün en değerli çıktısı, başarısız üretim örnekleridir. Sistemin yanıldığı gerçek dünya sorguları, hem test setini zenginleştirmek hem de iyileştirme önceliklerini belirlemek için altın değerindedir. Böylece LLM değerlendirme, statik bir kabul testinden, zamanla kendini besleyen ve iyileştiren bir kalite güvence sistemine dönüşür. Ölçmeyi üretime taşımayan bir ekip, sistemin gerçek dünyada nasıl davrandığını asla tam bilemez.

Doğruluk değerlendirmesi "sistem doğru cevap veriyor mu" sorusunu sorarken, güvenlik değerlendirmesi bambaşka bir soru sorar: "sistem kötüye kullanılabilir mi, zararlı çıktı üretebilir mi, manipüle edilebilir mi?" Bu, LLM değerlendirmenin ayrı ve giderek daha kritik bir dalıdır; çünkü kurumsal bir sistemde güvenlik ihlali, yanlış cevaptan çok daha ağır sonuçlar doğurur. Güvenlik değerlendirmesinin kalbinde kırmızı takım (red-teaming) yaklaşımı yatar.

Kırmızı takım, sistemi bilinçli olarak kırmaya çalışan bir düşman gibi davranmaktır: prompt injection ile talimatları ele geçirmeyi, jailbreak ile güvenlik sınırlarını aşmayı, kişisel veri sızdırmayı veya zararlı içerik ürettirmeyi denemek. Bu saldırıların bir test seti haline getirilmesi — bilinen kötüye kullanım desenlerinden oluşan bir "saldırı kümesi" — güvenlik değerlendirmesini sistematik kılar. Saldırı yüzeyini prompt injection nedir ve koruma katmanlarını guardrail nedir yazılarında ele alıyoruz.

Güvenlik değerlendirmesinde ölçülen başlıca boyutlar şunlardır. Red doğruluğu: sistem, reddetmesi gereken (zararlı, yasadışı, politika dışı) istekleri gerçekten reddediyor mu? Aşırı reddetme: meşru istekleri yanlışlıkla reddediyor mu (çünkü aşırı temkinli bir sistem de kullanılmaz olur)? Sızıntı direnci: sistem promptunu veya bağlamdaki gizli veriyi ifşa ediyor mu? Ve manipülasyon direnci: bağlamda gizlenmiş kötü niyetli talimatlara karşı dayanıklı mı?

Güvenlik değerlendirmesinin boyutları

Boyut	Ne sorar	İhlal örneği
Red doğruluğu	Zararlı isteği reddediyor mu?	Zararlı talimatı yerine getirme
Aşırı reddetme	Meşru isteği kabul ediyor mu?	Zararsız soruyu reddetme
Sızıntı direnci	Gizli veriyi koruyor mu?	Sistem promptunu ifşa etme
Manipülasyon direnci	Enjekte talimata direniyor mu?	Belgedeki gizli komuta uyma

Güvenlik değerlendirmesi, doğruluk değerlendirmesinden farklı olarak sürekli genişleyen bir hedeftir; çünkü yeni saldırı teknikleri sürekli ortaya çıkar. Bu yüzden saldırı kümesi statik değil, yeni tehditlerle beslenen yaşayan bir varlık olmalıdır. Yüksek riskli senaryolarda (finans, sağlık, kamu), güvenlik değerlendirmesi yalnızca otomatik testlerle değil, uzman kırmızı takım çalışmalarıyla desteklenmelidir. Sorumlu yapay zeka ilkeleri bağlamında güvenlik değerlendirmesi, bir seçenek değil zorunluluktur; ve olgun bir LLM değerlendirme çerçevesinin ayrılmaz parçasıdır.

LLM değerlendirmenin çoğu zaman gölgede kalan ama üretimde belirleyici olan iki boyutu maliyet ve gecikmedir. Teknik olarak en doğru yanıtları veren bir sistem, yanıt başına çok pahalıysa veya kullanıcıyı çok bekletiyorsa üretimde yaşayamaz. Bu yüzden olgun bir değerlendirme, doğruluğu maliyet ve gecikmeyle birlikte, bir ödünleşim olarak okur; tek boyutu izole ederek değil.

Maliyet değerlendirmesi, yanıt başına token tüketimini ve bunun parasal karşılığını ölçer. Token kavramının maliyetle ilişkisini token nedir yazısında ele alıyoruz. Bir değerlendirme kurulumu, her test örneği için yalnızca kalite puanını değil, tüketilen token ve tahmini maliyeti de kaydetmelidir; böylece "A promptu B'den daha iyi ama iki kat pahalı" gibi bilinçli ödünleşimler görünür hale gelir. Maliyeti düşürmenin yaygın kaldıraçları arasında bağlamı reranking ile daraltmak, gereksiz uzun promptlardan kaçınmak ve soruyu zorluğuna göre farklı boyutta modellere yönlendirmek (routing) yer alır.

Gecikme değerlendirmesi, kullanıcının yanıtı ne kadar sürede aldığını ölçer. Burada ortalama değil, yüzdelik dilimler (p50, p95) önemlidir; çünkü kullanıcıların en yavaş deneyimi yaşayan kısmı (p95) çoğu zaman ortalama kadar belirleyicidir. Gecikmeyi değerlendirirken uçtan uca süreyi bileşenlerine ayırmak — getirme, reranking, model üretimi — hangi adımın darboğaz olduğunu gösterir. Yanıtı akış (streaming) halinde vermek, algılanan gecikmeyi belirgin biçimde düşürebilir.

Maliyet ve gecikme değerlendirmesi, LLM değerlendirmeyi bir mühendislik disiplininden bir ürün ve iş disiplinine bağlar. Çünkü nihai soru "sistem ne kadar iyi" değil, "sistem, kabul edilebilir bir maliyet ve hızla ne kadar iyi" sorusudur. Bu üç boyutu birlikte ölçen bir ekip, teknik olarak etkileyici ama ekonomik olarak çöken sistemler kurma tuzağından kaçınır. Operasyonel maliyet yönetiminin ayrıntısını LLMOps nedir yazısında bulabilirsiniz.

LLM değerlendirmenin genel ilkeleri evrenseldir ama Türkiye ve Türkçe bağlamı, iki özel boyut ekler: Türkçe dil kalitesinin ayrı değerlendirilmesi ve KVKK ile uyum. Bu iki boyut, çoğu zaman İngilizce merkezli değerlendirme literatüründe atlanır ama Türkiye'de faaliyet gösteren kurumlar için belirleyicidir.

Türkçe dil kalitesi, ayrı ve bilinçli bir değerlendirme gerektirir çünkü birçok model ve metrik İngilizce ağırlıklı geliştirilmiştir. Bir model İngilizcede mükemmel çalışırken Türkçede daha zayıf olabilir; çekim ekleri, sözcük dizilişi, deyimler ve kültürel bağlam nüansları Türkçede farklı davranır. Bu yüzden test setiniz gerçek Türkçe kullanıcı sorularını içermeli, referans-tabanlı metrikler ve LLM-as-judge hakemi Türkçede kalibre edilmeli ve gömme (embedding) tabanlı ölçütlerde Türkçeyi iyi temsil eden bir modelin kullanıldığından emin olunmalıdır. İngilizce bir benchmark'ta iyi görünen bir sistem, Türkçe görevde beklenenden zayıf olabilir; bunu ancak Türkçe test setiyle ölçerek görürsünüz.

KVKK boyutu, değerlendirme verisinin kendisiyle ilgilidir. Bir LLM değerlendirme kurulumu, çoğu zaman gerçek kullanıcı sorularından ve gerçek üretim loglarından beslenir; bu veriler kişisel veri içeriyorsa, tüm KVKK yükümlülükleri devreye girer. Aşağıdaki çerçeve bilgilendirme amaçlıdır ve hukuki tavsiye değildir; kurumunuzun hukuk/uyum birimiyle birlikte uygulanmalıdır. Test setine ve değerlendirme loglarına giren kişisel verinin anonimleştirilmesi veya maskelenmesi, amaçla sınırlılık, saklama süresi ve erişim kontrolü baştan planlanmalıdır. Özellikle üretim trafiğinden örnekleme yaparken, bu örneklerin nerede saklandığı ve kimin eriştiği bir denetim kaydıyla yönetilmelidir.

KVKK'nın genel çerçevesi için KVKK nedir yazısı temel oluşturur. Uygulamada, LLM değerlendirme sürecini tasarlarken "hangi veriyle ölçüyoruz ve bu veri kişisel mi" sorusu, teknik metrik seçimi kadar önemlidir. Türkçe dil kalitesi ile KVKK uyumunu birlikte düşünmek, Türkiye bağlamında olgun bir değerlendirme kurulumunun ayırt edici işaretidir. Değerlendirme, yalnızca bir teknik ölçüm değil, aynı zamanda bir veri yönetişimi meselesidir.

Aşağıdaki kontrol listesi, sıfırdan üretim kalitesinde bir LLM değerlendirme kurulumu inşa etmek için pratik bir yol haritasıdır. Her adımı bilinçle geçmek, sonraki adımların üzerine sağlam kurulmasını sağlar; adım atlamak ise sorunu zincirin ilerisine erteler.

Nasıl Yapılır

LLM değerlendirme kurulum kontrol listesi

Bir LLM değerlendirme çerçevesini sıfırdan üretime taşımak için adım adım kontrol listesi.

1. 1

   Görevi ve kalite boyutlarını tanımla

   Görevin türünü ve o görevde 'iyi çıktı'nın hangi boyutlardan (doğruluk, dayanaklılık, güvenlik) oluştuğunu net yaz.

2. 2

   Temsili bir test seti kur

   Gerçek sorulardan türetilmiş, uç ve cevapsız örnekleri içeren bir benchmark oluştur; sızıntıya karşı koru.

3. 3

   Değerlendirme yöntemini seç

   Görevin doğasına göre referans-tabanlı metrik, LLM-as-judge veya insan değerlendirmesini (ya da karışımını) belirle.

4. 4

   Eval metriklerini tanımla

   Her kalite boyutu için manipülasyona dayanıklı, gerçek kaliteyle korelasyonlu bir metrik seç.

5. 5

   Yöntemi kalibre et

   Küçük bir insan-etiketli kümeyle metriklerin ve LLM-as-judge hakeminin insan yargısıyla örtüşmesini doğrula.

6. 6

   Taban çizgisi ölç

   Mevcut sistemin performansını ölç ve bunu bir referans noktası olarak kaydet.

7. 7

   Tek değişkenli iyileştir

   Her değişikliği tek tek, aynı test setinde ölç; hangi değişikliğin ne kadar katkı verdiğini izole et.

8. 8

   Regresyon ve izleme kur

   Değişiklik kapısı olarak regresyon testini ve üretimde canlı izlemeyi devreye al.

Bu listeyi dar bir görev üzerinde uygulamak, tüm sistemi tek seferde değerlendirmeye çalışmaktan çok daha akıllıcadır. Küçük ama kalibre edilmiş bir LLM değerlendirme kurulumu, hızla güven kazandırır ve sonraki genişlemeler için sağlam bir temel bırakır. Kurumunuza özel bir değerlendirme çerçevesi kurmak için yapay zeka danışmanlığı ile başlayabilir, ekibinizin yetkinliğini geliştirmek için kurumsal eğitim seçeneklerine bakabilir ve kavramları derinleştirmek için öğrenme merkezini kullanabilirsiniz.

Değerlendirme yöntemleri arasında seçim yapmak, çoğu zaman kafa karıştırıcıdır; ama basit bir karar çerçevesiyle netleşir. Doğru yöntem, görevin doğasına, ölçeğe ve riskin büyüklüğüne bağlıdır. Aşağıdaki mantık, hangi durumda hangi yöntemin öne çıktığını gösterir.

Görev kapalı uçlu ve tek cevaplıysa (sınıflandırma, çıkarım, kısa cevap, kod doğrulama), referans-tabanlı metrikler en verimli seçimdir: hızlı, ucuz ve tekrarlanabilir. Bu görevlerde açık bir altın cevap vardır ve otomatik karşılaştırma güvenilirdir. Görev açık uçlu ve çok cevaplıysa (özet, diyalog, yaratıcı üretim, RAG dayanaklılık), referans-tabanlı metrikler yetersiz kalır ve LLM-as-judge devreye girer; ama mutlaka kalibre edilmiş olarak. En yüksek riskli ve kritik kararlarda (güvenlik değerlendirmesi, yeni bir modelin üretime alınması, düzenleyici denetim), insan değerlendirmesi vazgeçilmezdir — en azından bir doğrulama örneklemi üzerinde.

Hangi durumda hangi LLM değerlendirme yöntemi öne çıkar

Durum	Öne çıkan yöntem	Neden
Kapalı uçlu, tek cevaplı görev	Referans-tabanlı metrik	Net altın cevap, hızlı ve ucuz
Açık uçlu, çok cevaplı görev	Kalibre LLM-as-judge	Anlama bakar, ölçeklenebilir
Yüksek risk / kritik karar	İnsan değerlendirmesi	En güvenilir sinyal, doğrulama
Büyük ölçekli sürekli izleme	Otomatik metrik + örneklemde LLM-as-judge	Ölçek ve maliyet dengesi
Güven kalibrasyonu gereken senaryo	İnsan-etiketli küme + kalibrasyon	Güvenin gerçek doğrulukla örtüşmesi

Pratikte bu yöntemler bir arada, katmanlı kullanılır: ucuz otomatik metrikler ve LLM-as-judge geniş ölçekte sürekli çalışır, insan değerlendirmesi ise stratejik noktalarda kalibrasyon ve doğrulama için devreye girer. Karar verirken sorulacak en yararlı soru şudur: "Bu görevde yanlış bir değerlendirmenin maliyeti nedir?" Maliyet düşükse hız ve ölçeği önceliklendirin; maliyet yüksekse (güvenlik, uyum, itibar) güvenilirliği ve insan denetimini önceliklendirin. Değerlendirme yöntemi de tıpkı sistemin kendisi gibi, ait olduğu riskin büyüklüğüne göre kalibre edilir.

Bu çerçeveyi RAG mı yoksa fine-tuning mi kullanılacağı gibi mimari kararlara da bağlamak yararlıdır; çünkü seçtiğiniz mimari, değerlendirme yönteminizi de şekillendirir. Fine-tuning'in ne olduğunu fine-tuning nedir ve prompt tasarımının kaliteyi nasıl etkilediğini prompt engineering nedir yazısında ele alıyoruz; her mimari kararının etkisi, ancak tutarlı bir LLM değerlendirme çerçevesiyle görünür hale gelir.

Deneyimli bir gözle bakıldığında, başarısız LLM değerlendirme kurulumları benzer hatalarla bozulur. Bu hataların çoğu, ölçümü ciddiye almamaktan veya ölçüm aracının kendisini sorgulamamaktan kaynaklanır. En sık görülenler şunlardır:

• Değerlendirmeyi sona bırakmak: Ölçmeyi "sonra ekleriz" diye ertelemek, tüm projeyi kör bırakır. Değerlendirme, ilk günden kurulacak bir katmandır, sonradan yamanan bir eklenti değil.
• Tek metriğe güvenmek: Her metriğin bir kör noktası vardır. Tek bir sayıya bakarak karar vermek, o metriğin kaçırdığı boyutlarda sessizce bozulmaya yol açar; birden fazla metrik birlikte okunmalıdır.
• Metriği kalibre etmemek: İnsan yargısıyla örtüşmesi doğrulanmamış bir metriğe göre optimize etmek, sizi yanlış yöne götürebilir. Metriğin gerçek kaliteyle korelasyonu ölçülmeden güvenilmemelidir.
• LLM-as-judge'ı naif kurmak: Rubric vermeden, önyargıları hesaba katmadan ve kalibre etmeden bir modeli hakem yapmak, güvenilir görünen ama yanıltıcı puanlar üretir.
• Temsili olmayan test seti: Yalnızca kolay ve tipik örneklerden oluşan bir benchmark, sahte bir güven verir; sistem test setinde parlar, üretimde başarısız olur.
• Veri sızıntısı ve aşırı uyum: Test örneklerinin eğitime veya prompt'a sızması ya da sistemi yalnızca test setinde iyi olacak şekilde ayarlamak, değerlendirmeyi anlamsızlaştırır.
• Regresyon testini atlamak: Değişiklikleri sabit bir test setinden geçirmeden üretime almak, bir iyileştirmenin başka bir davranışı gizlice bozmasına yol açar.
• Boyutları karıştırmak: Doğruluk, maliyet ve gecikmeyi tek bir puanda eritmek, ödünleşimi görünmez kılar; boyutlar ayrı ölçülüp bilinçle dengelenmelidir.

Bir LLM değerlendirme kurulumu inşa ederken karşılaşılan bir karar, araç ekosistemidir. Araçlar hızla değiştiği için, ürün adı vermek yerine yetenek kategorilerine ve seçim ilkelerine odaklanmak daha kalıcı bir rehber sunar; çünkü kategoriler kalıcı, ürünler geçicidir.

Başlıca yetenek kategorileri şunlardır. Eval çerçeveleri: test setlerini çalıştıran, metrikleri hesaplayan ve sonuçları raporlayan kütüphaneler; değerlendirmenin iskeletini oluştururlar. LLM-as-judge kütüphaneleri: rubric tabanlı model puanlaması ve karşılaştırma sunan, önyargı azaltma tekniklerini içeren araçlar. RAG'e özgü değerlendirme kütüphaneleri: dayanaklılık, getirme isabeti ve alaka gibi RAG metriklerine odaklanan araçlar. Gözlemlenebilirlik ve izleme platformları: üretim trace'i, çevrimiçi eval ve kayma tespiti sağlayan sistemler. Deney takibi araçları: farklı sürümlerin, promptların ve modellerin sonuçlarını karşılaştıran ve versiyonlayan araçlar.

Doğru araç seçiminin birkaç ilkesi vardır. Birincisi, göreve ve ölçeğe uygunluk: küçük bir ekip için basit bir eval çerçevesi ve bir izleme aracı yeterliyken, büyük ölçekli bir sistem daha kapsamlı bir yığın gerektirir. İkincisi, mevcut altyapıyla uyum: değerlendirme araçları, model çağırma, loglama ve veri altyapınızla sorunsuz entegre olmalıdır. Model çağırma protokollerini standartlaştıran yaklaşımları anlamak için MCP nedir yazısı bağlam sunar. Üçüncüsü, bağımsızlık: kritik bileşenlerde tedarikçi kilidinden kaçınmak; çünkü daha iyi metrikler ve modeller sürekli çıkar.

En önemli ilke, aracı değil disiplini merkeze koymaktır. Hiçbir araç, kötü tasarlanmış bir test setini veya kalibre edilmemiş bir metriği kurtaramaz; en gelişmiş eval platformu bile, üzerine sağlam bir değerlendirme düşüncesi kurulmadan işe yaramaz. Araçlar değerlendirmeyi hızlandırır ve ölçeklendirir, ama değerlendirmenin kalitesini belirleyen, arkasındaki mühendislik ve düşünce disiplinidir. Daha ileri ajan tabanlı sistemlerin değerlendirilmesi için agentic AI nedir yazısındaki çok adımlı akıl yürütme, ek bir değerlendirme katmanı gerektirir; çünkü bir ajanın yalnızca son cevabı değil, izlediği adımların her biri de ölçülmelidir.

Bir LLM değerlendirme çalışması bir sayı üretir — ama o sayı ne kadar güvenilir? Sık yapılan bir hata, iki sistem arasındaki küçük bir puan farkını anlamlı bir iyileşme sanmaktır. Oysa dil modelleri olasılıksaldır ve test setleri sınırlıdır; bu yüzden ölçülen fark, gerçek bir iyileşme değil, yalnızca rastlantısal varyans olabilir. Sonuçları doğru yorumlamak, LLM değerlendirmenin sık ihmal edilen ama kritik bir disiplinidir.

Birinci kaynak, modelin kendi varyansıdır. Aynı girdi, farklı çalıştırmalarda (özellikle sıcaklık sıfır değilse) farklı çıktılar üretir; bu, tek bir ölçümün gürültülü olduğu anlamına gelir. Bunu azaltmak için kritik değerlendirmeleri birden çok kez çalıştırıp ortalamak ve varyansı raporlamak iyi bir pratiktir. "A sistemi 0,71, B sistemi 0,73" demek yeterli değildir; bu farkın çalıştırmalar arası gürültüden büyük olup olmadığını bilmek gerekir.

İkinci kaynak, test setinin sonlu boyutudur. Yirmi örnekten oluşan bir test setinde bir örneğin farkı, yüzde beş puanlık bir sıçrama gibi görünebilir; ama bu, gerçek bir yetenek farkı değil, örneklem gürültüsüdür. Test seti büyüdükçe ölçümün güven aralığı daralır. Bu yüzden bir iyileşmenin gerçek olup olmadığını değerlendirirken, hem test setinin boyutunu hem de basit bir istatistiksel anlamlılık sezgisini akılda tutmak gerekir: küçük setlerde küçük farklar güvenilmezdir.

Pratik sonuç şudur: bir LLM değerlendirme puanı asla tek başına, mutlak ve kesin bir gerçek olarak okunmamalıdır. Her puan bir belirsizlik payı taşır; ve olgun bir değerlendirme, bu belirsizliği görünür kılar. Kararları, gürültüden açıkça büyük olan ve tutarlı biçimde tekrarlanan farklara dayandırmak, değerlendirmeyi güvenilir kılan şeydir. İstatistiksel titizlik, eval'i bir his olmaktan çıkarıp bir kanıta dönüştürür.

İyi bir test seti kurmanın en büyük engeli çoğu zaman veridir: yeterli sayıda, etiketli ve çeşitli örnek bulmak emek ister. Bu noktada sentetik veri — bir dil modeliyle üretilen yapay test örnekleri — cazip bir hızlandırıcı olarak devreye girer. Doğru kullanıldığında test setini hızla genişletir; yanlış kullanıldığında ise yanıltıcı bir güven verir. Bu ödünleşimi anlamak, olgun bir LLM değerlendirme kurulumu için önemlidir.

Sentetik verinin en güçlü kullanımı, kapsama boşluklarını doldurmaktır. Gerçek kullanıcı sorularınız belirli senaryoları az temsil ediyorsa (örneğin nadir bir ürün tipi veya bir uç durum), bir model bu senaryolara özgü sentetik sorular üretebilir. Benzer biçimde, cevabı olmayan sorular veya bilinen saldırı desenleri sentetik olarak çoğaltılabilir; bu, test setinin zorluk çeşitliliğini artırır. Sentetik veri, gerçek verinin az olduğu erken aşamalarda taban çizgisi kurmayı da hızlandırır.

Ama sentetik verinin ciddi riskleri vardır. Birincisi dağılım kayması: bir modelin ürettiği sorular, gerçek kullanıcıların tuhaf, eksik ve öngörülemez sorularını nadiren yakalar; sentetik set fazla "temiz" ve tekdüze olabilir. İkincisi döngüsel önyargı: değerlendirdiğiniz modelle aynı aileden bir model test sorularını üretirse, sistemin kör noktaları test setine de taşınır ve değerlendirme bu noktaları göremez. Üçüncüsü etiket güvenilirliği: sentetik olarak üretilen "doğru cevaplar" hatalı olabilir ve bu hatalar sessizce değerlendirmeyi bozar.

Bu yüzden altın kural şudur: sentetik veri, insan doğrulamasından geçmeden test setine tam yetkiyle girmemelidir. En sağlıklı yaklaşım, sentetik veriyi bir taslak üretici olarak kullanmak — hızlıca aday örnekler üretmek — ama her örneği ve etiketini bir insanın gözden geçirmesidir. Böylece sentetik verinin hızından yararlanılır, riskleri ise insan denetimiyle sınırlanır. Sentetik veri, gerçek veriyi tamamlayan bir hızlandırıcıdır; onun yerini alan bir kestirme değil.

Olgun ekipler, LLM değerlendirmeyi projenin sonuna eklenen bir kabul testi olmaktan çıkarıp geliştirmenin merkezine koyar; bu yaklaşıma değerlendirme odaklı geliştirme (eval-driven development) denir. Klasik yazılımdaki test odaklı geliştirmenin (TDD) yapay zeka karşılığıdır: önce "iyi çıktı" ne demek onu bir test setiyle tanımlarsın, sonra sistemi bu ölçüte göre inşa eder ve iyileştirirsin. Böylece her karar, bir hisse değil bir ölçüme dayanır.

Bu yaklaşımın gücü, geliştirmeyi bir tahmin döngüsünden bir kanıt döngüsüne çevirmesidir. Bir prompt değişikliği önerildiğinde, "bence bu daha iyi" demek yerine, değişiklik test setinde çalıştırılır ve etkisi sayısal olarak görülür. Bir model yükseltmesi düşünüldüğünde, pazarlama iddialarına değil, kendi göreve özel benchmark'ınızdaki sonuca bakılır. Bu disiplin, ekibin körlemesine değil, görerek ilerlemesini sağlar.

Değerlendirme odaklı geliştirme, bir kültür meselesidir de. Bir ekip, "değerlendirme kimin işi" sorusunu net yanıtlamalı; test setinin sahipliği, kalibrasyon sorumluluğu ve regresyon kapısının kim tarafından işletileceği tanımlanmalıdır. Değerlendirmeyi bir kişinin ara sıra yaptığı bir görev değil, tüm geliştirme akışına gömülü bir refleks haline getiren ekipler, kaliteyi sürdürülebilir biçimde yönetir. Bu kültürü kurumunuzda oturtmak için LLMOps nedir yazısındaki operasyon disiplini ve yapay zeka danışmanlığı desteği yol gösterici olabilir.

Pratik başlangıç basittir: küçük bir test setiyle bir taban çizgisi kurun, her değişikliği bu sete karşı ölçme alışkanlığını ekibe yerleştirin ve zamanla değerlendirmeyi otomatikleştirip geliştirme akışına gömün. Değerlendirme odaklı geliştirme, LLM değerlendirmeyi bir kontrol adımı olmaktan çıkarıp bir düşünme biçimine dönüştürür; ve bu düşünme biçimi, güvenilir yapay zeka ürünleri kuran ekipleri kuramayanlardan ayıran temel farktır.

Özetle llm değerlendirme, bir dil modelinin veya model tabanlı uygulamanın çıktı kalitesini tanımlı boyutlarda — doğruluk, tutarlılık, güvenlik, maliyet, gecikme — sistematik ve tekrarlanabilir biçimde ölçme disiplinidir. Üç temel yöntemden yararlanır: referans-tabanlı metrikler, LLM-as-judge ve insan değerlendirmesi; ve olgun bir kurulum bu üçünü katmanlı biçimde birlikte kullanır. Bir dil modeli akıcı ama yanlış olabildiği için, değerlendirme kararları tahminden kanıta taşıyan tek yoldur.

Sağlam bir LLM değerlendirme kurulumu birkaç sütuna dayanır: gerçek kullanımı yansıtan temsili bir test seti (benchmark), göreve uygun ve manipülasyona dayanıklı eval metrikleri, yöntemin insan yargısıyla örtüşmesini güvence altına alan kalibrasyon, RAG için iki katmanlı getirme ve üretim değerlendirmesi, ve üretimde regresyon testi ile canlı izleme. Türkiye bağlamında buna Türkçe dil kalitesinin ayrı değerlendirilmesi ve KVKK uyumu eklenir. En önemli mesaj şudur: değerlendirmeyi de değerlendirin — ölçüm aracının kendisi kör olabilir, ve olgun bir eval disiplini metriğine, test setine ve hakemine güvenmeden önce onları sorgular.

Değerlendirme, bir kez kurulup unutulan bir kabul testi değil, sürekli işleyen bir kalite güvence döngüsüdür. Temel kavramlar için LLM nedir, RAG nedir ve yapay zeka halüsinasyonu nedir yazılarına bakabilir; kurumunuza özel bir LLM değerlendirme çerçevesi kurmak için yapay zeka danışmanlığı ile başlayabilir, ekip yetkinliği için kurumsal eğitim seçeneklerini inceleyebilir ve tüm kavramları öğrenme merkezinde derinleştirebilirsiniz.

LLM değerlendirme nedir ve neden gereklidir?

LLM değerlendirme (eval), bir büyük dil modelinin veya model tabanlı bir uygulamanın çıktı kalitesini tanımlı boyutlarda (doğruluk, tutarlılık, güvenlik, maliyet, gecikme) sistematik ve tekrarlanabilir biçimde ölçme disiplinidir. Gereklidir çünkü bir dil modeli akıcı ama yanlış cevaplar üretebilir; hangi model, prompt veya mimari değişikliğinin kaliteyi artırıp azalttığını ölçmeden bilemezsiniz. LLM değerlendirme olmadan yapılan her iyileştirme öznel bir izlenime dayanır; ölçmeyen bir ekip kör uçar. İyi bir değerlendirme çerçevesi, kararları tahminden kanıta taşır ve üretimde kalitenin sessizce bozulmasını önler.

Referans-tabanlı metrikler ile LLM-as-judge arasındaki fark nedir?

Referans-tabanlı metrikler, model çıktısını önceden hazırlanmış bir altın cevapla karşılaştırır; kelime örtüşmesi, gömme benzerliği veya kesin eşleşme gibi ölçütler kullanır. Hızlı, ucuz ve tekrarlanabilirdir ama tek doğru cevabı olmayan, açık uçlu görevlerde zayıf kalır. LLM-as-judge ise güçlü bir dil modelini hakem olarak kullanır: çıktıyı bir ölçüte (örneğin alaka, dayanaklılık, üslup) göre puanlar. Açık uçlu görevlerde daha esnektir ama önyargı, tutarsızlık ve maliyet gibi riskler taşır; bu yüzden insan yargısıyla kalibre edilmelidir. Olgun bir kurulum ikisini ve insan değerlendirmesini birlikte kullanır.

Eval metrikleri nasıl seçilir?

Eval metrikleri, görevin doğasına göre seçilir; evrensel tek bir metrik yoktur. Önce görevi tanımlayın (sınıflandırma, özetleme, soru-cevap, kod üretimi, açık uçlu diyalog); sonra o görevde "iyi çıktı" ne demek onu boyutlara ayırın (doğruluk, dayanaklılık, tutarlılık, güvenlik, biçim). Her boyut için, onu gerçekten ölçen ve manipülasyona dayanıklı bir metrik belirleyin. Tek metriğe güvenmeyin: birden fazla metriği birlikte okumak, bir metriğin kör noktasını bir diğerinin kapatmasını sağlar. En önemlisi, seçtiğiniz metriklerin insan yargısıyla ne kadar örtüştüğünü ölçün; bir metrik iyi görünüp gerçek kaliteyle korelasyon taşımıyorsa yanıltıcıdır.

İyi bir test seti (benchmark) nasıl hazırlanır?

İyi bir test seti, sisteminizin gerçek dünyada karşılaşacağı sorguların dağılımını yansıtan temsili bir örneklemdir. Gerçek kullanıcı sorularından türetmek, sentetik sorulardan daha değerlidir. Test seti kolay örneklerin yanında zor ve uç örnekleri (eş anlamlılar, çok adımlı sorular, nadir terimler, cevabı olmayan sorular) içermelidir. Her örnek için beklenen çıktı veya değerlendirme ölçütü işaretlenir. Kritik iki risk vardır: veri sızıntısı (test örneklerinin eğitim veya prompt'a karışması) ve aşırı uyum (sistemi yalnızca test setinde iyi olacak şekilde ayarlamak). Test seti yaşayan bir varlıktır; üretimden gelen başarısız örneklerle sürekli büyütülür.

LLM-as-judge güvenilir mi, önyargıları nasıl azaltılır?

LLM-as-judge doğru kurulduğunda değerli ama körü körüne güvenilmemesi gereken bir yöntemdir. Bilinen önyargıları vardır: konum önyargısı (ilk sunulan cevabı tercih etme), uzunluk önyargısı (daha uzun cevabı daha iyi sanma), kendini kayırma (kendi ürettiği metni yüksek puanlama) ve üslup önyargısı (kendinden emin tonu doğrulukla karıştırma). Bu önyargılar azaltılabilir: net puanlama ölçütleri (rubric) vermek, cevap sırasını değiştirip iki yönlü karşılaştırma yapmak, zincirleme düşünme ile gerekçe istemek ve en önemlisi hakem modelin puanlarını bir insan-etiketli kümeyle kalibre etmek. Kalibrasyon olmadan LLM-as-judge güvenilir sayılmaz.

Kalibrasyon nedir ve neden önemlidir?

Kalibrasyon, iki bağlamda kullanılır. Birincisi, bir değerlendirme yönteminin güvenilirliği: LLM-as-judge veya otomatik bir metriğin verdiği puanların insan yargısıyla ne kadar örtüştüğünü ölçmek. İkincisi, modelin güven kalibrasyonu: modelin bir cevaba atfettiği güvenin gerçek doğrulukla tutarlı olması, yani "%80 eminim" dediği durumların gerçekten yaklaşık %80'inde doğru olması. Kalibrasyon önemlidir çünkü kalibre edilmemiş bir değerlendirme yanlış kararlara yol açar: iyi görünen ama insan yargısıyla örtüşmeyen bir metriğe göre model seçmek, üretimde kötü sonuç verir. Aşırı özgüvenli bir model ise kullanıcıyı yanıltır. Kalibrasyon, hem eval'in hem modelin güvenilirliğinin temelidir.

RAG sistemleri nasıl değerlendirilir?

RAG değerlendirme iki katmanda yapılır. Getirme (retrieval) katmanında doğru belge parçalarının bulunup bulunmadığı ölçülür: recall (ilgili parçaların ne kadarı geldi), precision (gelenlerin ne kadarı ilgili), MRR ve nDCG (sıralama kalitesi). Üretim (generation) katmanında yanıtın kalitesi ölçülür: dayanaklılık (yanıt gerçekten getirilen bağlama mı dayanıyor), alaka (soruyu karşılıyor mu) ve doğruluk. İki katmanı ayrı ölçmek şarttır; çünkü yanlış bir yanıtın kaynağı ya yanlış parça getirilmesi ya da doğru parçanın yanlış yorumlanmasıdır ve bu ikisi farklı çözümler gerektirir. Değerlendirme için etiketli bir test seti ve giderek yaygınlaşan LLM-as-judge yaklaşımları birlikte kullanılır.

Üretimde LLM değerlendirme nasıl sürdürülür (regresyon testi)?

Üretimde LLM değerlendirme, çevrimdışı test kümelerinin ötesine geçer. Bir regresyon test seti oluşturulur: her model, prompt veya mimari değişikliğinde otomatik çalışan, kritik senaryoları kapsayan sabit bir örneklem. Bu, bir değişikliğin daha önce doğru çalışan bir davranışı bozup bozmadığını (regresyon) erken yakalar. Buna ek olarak canlı izleme kurulur: gerçek trafikten örnekleme, LLM-as-judge ile çevrimiçi puanlama, kullanıcı geri bildirimi (başparmak yukarı/aşağı) ve kayma (drift) tespiti. Başarısız üretim örnekleri düzenli olarak test setine eklenir. Böylece LLM değerlendirme tek seferlik bir kabul testi değil, sürekli işleyen bir kalite güvence döngüsü haline gelir.

Hangi LLM değerlendirme araçları kullanılır?

Araç ekosistemi hızla değiştiği için ürün adından çok yetenek kategorilerine odaklanmak daha kalıcıdır. Başlıca kategoriler şunlardır: eval çerçeveleri (test setlerini çalıştırıp metrik hesaplayan kütüphaneler), LLM-as-judge kütüphaneleri (rubric tabanlı model puanlaması sunan araçlar), RAG'e özgü değerlendirme kütüphaneleri (dayanaklılık ve getirme metrikleri), gözlemlenebilirlik/izleme platformları (üretim trace ve çevrimiçi eval) ve deney takibi araçları (sürüm karşılaştırma). Doğru seçim, göreve, ölçekle ve mevcut altyapıya bağlıdır. En önemli ilke, değerlendirmeyi projeye sonradan eklenecek bir eklenti değil, ilk günden kurulacak bir katman olarak görmektir.

Küçük bir ekip LLM değerlendirmeye nasıl başlar?

Küçük bir ekip, mükemmel bir sistem kurmaya çalışmadan küçük ama gerçek bir test setiyle başlar: on-yirmi temsili örnek bile taban çizgisi kurmak için değerlidir. Önce görevi ve "iyi çıktı"nın ne olduğunu net tanımlar; sonra basit bir referans-tabanlı metrik veya net bir rubric ile LLM-as-judge kurar. İlk ölçümü taban çizgisi kabul eder ve her değişikliği tek tek, aynı test setinde ölçer. Sonuçları bir insan gözden geçirmesiyle kalibre eder; metriğin gerçek kaliteyle örtüşüp örtüşmediğini doğrular. Zamanla test setini üretimden gelen zor örneklerle büyütür ve değerlendirmeyi otomatikleştirir. Küçük ama ölçen bir ekip, büyük ama ölçmeyen bir ekipten her zaman daha hızlı ilerler.