LLM uygulamanı ölçmek: golden dataset ve LLM-as-judge

LLM tabanlı bir özelliği prod'a aldıktan sonra "bana iyi geldi" hissiyle ilerlemek, birkaç hafta içinde sessizce bozulan bir regresyonu fark etmeden geçirmenle sonuçlanır. LLM eval golden dataset ölçüm disiplini olmadan, prompt'ta yaptığın küçük bir değişikliğin hangi senaryoları kırdığını gözle takip edemezsin. Bu yazıda golden dataset'i nasıl kuracağını, deterministik metriklerle LLM-as-judge'ı ne zaman birlikte kullanacağını ve insan değerlendirmesini nasıl ucuzlatacağını adım adım göreceksin.

💡 Pro Tip: Eval setini önce code-graded (exact match/string match) senaryolarla başlat; LLM-as-judge'ı yalnız code-graded'ın yetersiz kaldığı nüanslı çıktılar için devreye sok. Bu sıralama Anthropic'in kendi eval rehberinde de önceliklendirilir.

İçindekiler

• Neden "gözle bakmak" ölçüm değildir
• Golden dataset: örnek seçimi ve etiketleme
• Deterministik metrikler: exact match, schema, latency
• LLM-as-judge: rubrik yazımı ve önyargı tuzakları
• İnsan değerlendirmesini örnekleme ile ucuzlatmak
• Eval'i CI'a bağlamak ve eşik belirlemek
• Üretim trafiğinden eval seti büyütmek
• SSS
• LLM uygulaması nasıl test edilir?
• Golden dataset nasıl hazırlanır, kaç örnek yeterli?
• LLM-as-judge güvenilir mi, ne zaman yanılır?
• Prompt değişikliğinin regresyon yaptığını nasıl anlarım?
• Human grading ne zaman gerekir?
• Güncelleme (Eylül 2026)
• Sonuç
• Kaynaklar

Neden "gözle bakmak" ölçüm değildir

Bir prompt'u değiştirip beş-on örneği elle okuyup "daha iyi görünüyor" demek, ölçüm değil izlenimdir. Anthropic'in eval rehberi, başarı kriterlerinin Specific, Measurable, Achievable, Relevant olması gerektiğini vurgular: "Specific... Measurable... Achievable... Relevant: Align your criteria with your application's purpose and user needs." Bu, en "hazy" görünen konuların bile (ör. güvenlik) sayısal bir eşiğe indirgenebileceği anlamına gelir; rehberdeki örnek şudur: "Less than 0.1% of outputs out of 10,000 trials flagged for toxicity by the content filter."

Gözle bakmanın asıl sorunu ölçeklenmemesi değil, tekrarlanabilir olmamasıdır. Aynı on örneği bir hafta sonra tekrar okuduğunda farklı bir izlenime kapılabilirsin; iki farklı geliştirici aynı çıktıya bakıp farklı sonuçlara varabilir. Golden dataset + net kriter, bu öznelliği ortadan kaldırıp "önceki sürüm bu 40 senaryodan 34'ünü geçti, yeni sürüm 37'sini geçti" gibi karşılaştırılabilir bir sayıya dönüştürür. Bu da seni agentic AI mimarilerinde olduğu gibi çok adımlı LLM akışlarında bile hangi adımın regresyona sebep olduğunu izleyebilir hale getirir.

Bu fark özellikle ekip büyüdükçe kritikleşir. Tek başına çalışırken "bana iyi geldi" hissi bir dereceye kadar işe yarayabilir çünkü kararı veren tek bir zihin vardır; ama birden fazla geliştirici aynı prompt üzerinde çalışmaya başladığında, her birinin "iyi" tanımı biraz farklılaşır. Bir eval seti ve net bir başarı kriteri, bu farklı zihinsel modelleri tek bir ortak referansa indirger — tartışma "bence daha iyi" yerine "golden set skoru 0.91'den 0.87'ye düştü, hangi kategori kırıldı" şekline döner. Bu da code review sürecine yakın bir disiplin katar: değişikliğin etkisini merge etmeden önce, sezgiyle değil sayıyla tartışırsın.

Golden dataset: örnek seçimi ve etiketleme

Golden dataset kurarken Anthropic'in eval tasarım ilkelerinden ikisi doğrudan işine yarar. Birincisi göreve özgü olmak: "Be task-specific: Design evals that mirror your real-world task distribution. Don't forget to factor in edge cases!" Yani setin, üretimde gerçekten karşılaşacağın soru/girdi dağılımını yansıtmalı — yalnızca kolay, "güzel" örnekler değil, boş girdi, çok uzun girdi, çelişkili talimat gibi uç durumlar da içermeli.

İkinci ilke, miktarın kaliteye tercih edilmesi: "Prioritize volume over quality: More questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals." Pratikte bu, onlarca titizlikle elle etiketlenmiş örnek yerine, yüzlerce otomatik derecelendirilebilir (exact match veya net rubrikli LLM-judge) örneğin daha güvenilir bir sinyal verdiği anlamına gelir. Etiketleme sürecinde her örneğe şu üç alanı ekle: girdi, beklenen çıktı (ya da rubrik), ve hangi derecelendirme yönteminin kullanılacağı (code/human/LLM). Bu üçlü ayrım, ilerleyen bölümde göreceğin gibi hangi senaryoyu hangi yöntemle test edeceğine karar vermeni kolaylaştırır.

Etiketleme aşamasında en çok zaman kaybettiren hata, örnekleri tek bir kişinin tek oturumda üretmesidir — bu, o kişinin kendi zihinsel modelini yansıtan dar bir dağılım yaratır. Bunun yerine setin farklı kaynaklardan beslenmesi daha sağlıklı olur: ürün ekibinin "böyle sorular gelir" diye tahmin ettiği senaryolar, destek ekibinin gerçek kullanıcı şikayetlerinden derlediği örnekler ve geliştiricilerin bilerek zorladığı sınır durumlar. Her örneğe ayrıca bir kategori etiketi (ör. "temel akış", "edge case", "kötüye kullanım denemesi") eklemek, ilerleyen dönemde hangi kategoride skorun düştüğünü ayrıştırmanı sağlar — tek bir toplam skor yerine kategori bazlı kırılım, regresyonun nerede olduğunu çok daha hızlı gösterir.

Bu üçlü etiketleme (girdi, beklenen çıktı, derecelendirme yöntemi) yalnızca kayıt tutmak için değil, setin büyümesini yönetmek için de işe yarar. Yeni bir örnek eklerken önce şunu sor: bu senaryoyu code-graded bir kontrolle mi (çıktı belirli bir formatta mı, belirli bir anahtar kelimeyi içeriyor mu), yoksa nüans gerektiren bir rubrikle mi değerlendireceksin? Cevap net değilse, büyük olasılıkla örneği hâlâ çok geniş tanımlamışsındır — rubriği daraltıp örneği ikiye bölmek, hem etiketlemeyi hem de sonradan hangi kategorinin kırıldığını okumayı kolaylaştırır. Kategori etiketleri zamanla büyüdükçe her kategorinin kendi alt-skoru ortaya çıkar; bu da tek bir toplam yüzdenin arkasına saklanan bir regresyonu (ör. "edge case" kategorisinde düşüş varken "temel akış" kategorisi sabit kalması) görünür kılar. Setin büyüklüğü arttıkça, kategori bazlı bu kırılım, hangi bölümün yeniden etiketlenmeye ya da genişletilmeye ihtiyaç duyduğunu önceliklendirmeni sağlar — böylece set büyütme çalışması rastgele değil, en zayıf kategoriye odaklanan bir iş haline gelir.

Deterministik metrikler: exact match, schema, latency

Anthropic'in derecelendirme çerçevesi üç yöntemi tanımlar: code-based, human, LLM-based. Code-based grading için iki temel örnek verilir — exact match ("output == golden_answer") ve string match ("key_phrase in output"). Bu yöntem "Fastest and most reliable, extremely scalable, but also lacks nuance for more complex judgments that require less rule-based rigidity" olarak tanımlanır: en hızlı ve güvenilir ama nüans gerektiren karmaşık yargılarda zayıf kalır.

Kod tarafında çalışan bir örnek şöyle görünür — 12 senaryodan kaçının birebir eşleştiğini hesaplayan basit bir script:

1# 12 test senaryosundan kaçı golden_answer ile birebir eşleşti
2results = [True, True, False, True, True, True, False, True, True, True, False, True]
3exact_match_rate = sum(results) / len(results)
4print(f"{exact_match_rate:.2%}")  # 75.00%

Bu tarz deterministik kontroller; JSON şema doğrulama, zorunlu alan varlığı, çıktı uzunluğu veya yanıt süresi (latency) gibi ölçülebilir her şey için genişletilebilir. Anthropic'in vurguladığı gibi bu yöntem en hızlı olanı — bu yüzden eval setinin mümkün olduğunca büyük bir kısmını code-graded senaryolara ayırmak, kalan bütçeni gerçekten nüans gerektiren durumlara saklamanı sağlar.

Pratikte code-graded kontrolleri iki katmana ayırmak işine yarar. Birinci katman "sert" kontroller: çıktı geçerli JSON mu, zorunlu alanlar dolu mu, yasaklı bir karakter/kelime var mı — bunlar geçmezse skor otomatik sıfır olur ve LLM-judge'a hiç gönderilmez, çünkü zaten kullanılamaz bir çıktıdır. İkinci katman "yumuşak" kontroller: anahtar kelime geçiyor mu, uzunluk beklenen aralıkta mı, yanıt süresi eşiğin altında mı — bunlar geçmezse skor düşürülür ama tamamen sıfırlanmaz. Bu iki katmanlı ayrım, tek bir "geçti/kaldı" bayrağı yerine hangi tür hatanın oluştuğunu (biçim hatası mı, içerik hatası mı) ayırt etmeni sağlar.

LLM-as-judge: rubrik yazımı ve önyargı tuzakları

Code-based grading'in yetmediği yerde LLM-based grading devreye girer: "LLM-based grading: Fast and flexible, scalable and suitable for complex judgment. Test to ensure reliability first then scale." Ama bunu güvenilir hale getirmenin üç somut kuralı var. Birincisi net rubrik yazmak — Anthropic'in verdiği örnek: "Have detailed, clear rubrics: 'The answer should always mention Acme Inc. in the first sentence. If it does not, the answer is automatically graded as incorrect.'" İkincisi rubriği ampirik/spesifik tutmak: "instruct the LLM to output only 'correct' or 'incorrect', or to judge from a scale of 1–5" — serbest metin yerine sabit bir skala. Üçüncüsü judge'a önce muhakeme yaptırıp bunu sonradan atmak: "Encourage reasoning: Ask the LLM to reason first before producing an evaluation score, and then discard the reasoning."

Basit bir rubrik tanımı şöyle görünebilir:

1{
2  "rubric": "Cevap ilk cumlede mutlaka urun adini gecirmeli. Gecirmiyorsa otomatik olarak incorrect sayilir.",
3  "scale": "correct | incorrect",
4  "reasoning_before_score": true
5}

LLM-as-judge'ın sınırları da kaynaklı: Zheng ve arkadaşlarının MT-Bench/Chatbot Arena çalışması, judge modellerin "position, verbosity, and self-enhancement biases, as well as limited reasoning ability" taşıdığını gösteriyor. Aynı çalışma, güçlü judge modellerin (GPT-4 örneği) insan tercihleriyle "over 80% agreement" sağlayabildiğini, bunun insanlar-arası uyum seviyesiyle aynı olduğunu da belgeliyor — yani LLM-judge tamamen güvenilmez değil, ama önyargı türlerini bilerek kullanmak gerekiyor:

İnsan değerlendirmesini örnekleme ile ucuzlatmak

Anthropic'in çerçevesinde insan derecelendirmesi net bir uyarıyla anılıyor: "Human grading: Most flexible and high quality, but slow and expensive. Avoid if possible." Bu, insan değerlendirmesini tamamen bırakman gerektiği anlamına gelmez — çoğu zaman bunu setin tamamı yerine bir örneklem üzerinde çalıştırmak yeterli olur. Ben genelde şu sırayı tercih ederim: önce code-graded ve LLM-judge'ı tüm sete uygula, sonra judge'ın düşük güvenle skorladığı veya iki farklı judge çalıştırmanda anlaşmazlık çıkan satırları ayrı bir kümeye al, insan gözden geçirmesini yalnızca o kümeye harca. Böylece pahalı ve yavaş olan insan emeği, en çok ihtiyaç duyulan belirsiz vakalara yoğunlaşır; geri kalan büyük çoğunluk otomatik derecelendirmeyle hızlıca geçer.

Bu yaklaşım aynı zamanda judge'ın kalibrasyonunu da sürekli kontrol etmeni sağlar: insan etiketleyicinin verdiği karar ile LLM-judge'ın kararı sistematik olarak uyuşmuyorsa, bu senin rubriğinin belirsiz olduğunun veya judge'ın önceki bölümde bahsedilen önyargılardan birini taşıdığının bir işaretidir.

İnsan gözden geçirmesini örgütlerken tek bir kişiye güvenmek yerine, en azından belirsiz kümedeki satırların bir kısmını iki kişiye bağımsız olarak etiketletmek faydalı olur. İki insan etiketleyici birbirinden farklı kararlar veriyorsa, bu senin rubriğinin insan gözünde bile net olmadığının işaretidir — ve büyük olasılıkla LLM-judge'ın da aynı belirsizlikte zorlanacağı anlamına gelir. Bu tür "insan bile anlaşamıyor" satırlarını ayrı bir listede tutup rubriği bunlara göre netleştirmek, zamanla hem insan hem judge tarafında anlaşma oranını yükseltir.

Eval'i CI'a bağlamak ve eşik belirlemek

Eval'i CI adımına bağlamak, rehberdeki otomasyon ilkesinin ("Automate when possible: Structure questions to allow for automated grading") ve iteratif prompt mühendisliği döngüsünün (test senaryoları → ön-taslak prompt → yinelemeli test/iyileştirme → final doğrulama → yayın) doğal uzantısıdır. Ben genelde eval script'ini bir CI adımına ekleyip minimum skor eşiği koymayı tercih ederim; script eşiğin altında kalırsa build kırmızı olur ve prompt/model değişikliği merge edilmeden önce fark edilir:

1# Basit örnek: eval script'ini CI adımında çalıştır, eşik altında build'i durdur
2python run_evals.py --dataset golden_set.jsonl --min-score 0.85

Eşik sayısını (bu örnekte 0.85) tek seferde belirleyip unutma — model veya prompt her önemli değiştiğinde eşiği yeniden gözden geçirmek, yanlış pozitif/negatif oranını düşük tutar.

Eşiği çok yüksek koyarsan her küçük dalgalanmada build kırmızı olur ve ekip zamanla eval'i görmezden gelmeye başlar; çok düşük koyarsan gerçek regresyonlar sessizce geçer. Eşiği önce mevcut prompt'un skoruna göre (ör. mevcut skor 0.91 ise eşik 0.85 gibi biraz altında) belirleyip, birkaç hafta boyunca yanlış alarm sıklığını gözlemleyerek ince ayar yapabilirsin.

Eşik ihlali build'i kırdığında, hangi kategori (temel akış mı, edge case mi) düştüğünü ayrı ayrı raporlamak, tek bir toplam skordan çok daha faydalı bir sinyal verir; aksi halde ekip her kırmızı build'de aynı soruyu ("neresi bozuldu?") elle araştırmak zorunda kalır. Bunu daha önceki bölümde bahsedilen iki katmanlı kontrolle (sert/yumuşak) birleştirmek de faydalı olur: sert kontrollerden biri başarısız olduğunda build'i doğrudan kırmak, yumuşak kontrollerdeki küçük düşüşleri ise yalnızca uyarı olarak loglamak, ekibin gerçekten kritik regresyonlarla küçük dalgalanmalar arasında ayrım yapmasını sağlar. Eşik ile kategori kırılımını birlikte CI çıktısına yazdırmak, PR incelemesini de hızlandırır — reviewer, hangi prompt satırının hangi kategoriyi etkilediğini tahmin etmek yerine doğrudan raporu okuyabilir.

Üretim trafiğinden eval seti büyütmek

Prod trafiği, golden dataset'i yalnız geliştirici tahminleriyle kurduğunda göremediğin edge case'leri ortaya çıkarır — gerçek kullanıcı sorguları, senin başta tahmin edemediğin uç durumları gün yüzüne çıkarır. Pratik yaklaşım, prod'da judge'ın düşük skor verdiği veya kullanıcının olumsuz tepki verdiği (yeniden deneme, şikayet, oturumu terk etme gibi) gerçek etkileşimleri periyodik olarak gözden geçirip, temsilci örnekleri golden sete eklemektir. Bu, setin zamanla üretimin gerçek dağılımına yakınsamasını sağlar; tıpkı bir RAG mı fine-tuning mi kararında olduğu gibi, kararını varsayımla değil gerçek kullanım verisiyle güncellemiş olursun.

Bunu düzenli bir alışkanlığa dönüştürmek için basit bir filtre script'i yeterli olur — judge skorunun eşiğin altında kaldığı satırları prod loglarından ayıklayıp ayrı bir kuyruğa yazmak:

1# Prod loglarından judge skoru dusuk olan satirlari golden-aday kuyruguna ayikla
2threshold = 0.6
3candidates = [row for row in prod_logs if row["judge_score"] < threshold]
4print(f"{len(candidates)} aday satir incelemeye gonderildi")

Bu kuyruk otomatik olarak sete eklenmemeli — her aday satırı insan gözden geçirip gerçekten temsilci ve tekrarlayan bir desen mi, yoksa tek seferlik bir gürültü mü olduğuna karar vermelisin. Aksi halde setin, ilkelerin öngördüğü "gerçek görev dağılımı" yerine yalnızca "judge'ın zorlandığı garip örnekler"e kayabilir.

SSS

LLM uygulaması nasıl test edilir?

Üç derecelendirme yöntemini görev tipine göre karıştırarak: net doğru/yanlış çıktılarda code-graded (exact match/string match), nüans gerektiren ama ölçek isteyen durumlarda net rubrikli LLM-as-judge, ve yalnızca judge'ın belirsiz kaldığı satırlarda insan değerlendirmesi. Anthropic'in çerçevesi bu üçünü Code-based grading, Human grading ve LLM-based grading olarak adlandırır ve otomasyonu mümkün olduğunca öne çıkarmanı önerir.

Golden dataset nasıl hazırlanır, kaç örnek yeterli?

Sabit bir ideal sayı yok; belirleyici olan sayı değil öncelik. Anthropic'in verdiği ilke şu: "more questions with slightly lower signal automated grading is better than fewer questions with high-quality human hand-graded evals." Yani az sayıda mükemmel etiketlenmiş örnek yerine, gerçek görev dağılımını ve edge case'leri kapsayan, otomatik derecelendirilebilir daha geniş bir set kurmayı hedefle.

LLM-as-judge güvenilir mi, ne zaman yanılır?

Güçlü judge modelleri insan tercihleriyle yüksek uyum gösterebiliyor — Zheng ve arkadaşlarının çalışmasına göre "over 80% agreement", insanlar-arası uyumla aynı seviye. Ama aynı çalışma judge'ların position, verbosity ve self-enhancement önyargısı taşıdığını ve sınırlı akıl yürütme yeteneğine sahip olduğunu da gösteriyor; bu yüzden rubrik net değilse veya cevap sırası/kaynağı kontrol edilmiyorsa judge yanılabilir.

Prompt değişikliğinin regresyon yaptığını nasıl anlarım?

Golden dataset'i her prompt/model değişikliğinde aynı script ile çalıştırıp önceki skorla karşılaştırarak. Bunu CI adımına bağlayıp minimum skor eşiği koyarsan, regresyon insan gözünden kaçmadan önce build aşamasında yakalanır.

Human grading ne zaman gerekir?

Anthropic'in tavsiyesi net: mümkünse kaçın, çünkü yavaş ve pahalı. Ama nüans kritikse ve judge modelinin belirsiz kaldığı ya da güvenilirliği henüz test edilmemiş senaryolarda, insan gözden geçirmesini tüm sete değil küçük bir örnekleme uygulamak, maliyeti makul tutar.

Güncelleme (Eylül 2026)

Bu makale 2025-11-18 tarihli sürüm ve araçlar temel alınarak yazıldı. O tarihten sonra OpenAI tarafında eval tooling ekosisteminde şu değişiklik oldu: OpenAI, 3 Haziran 2026'da Evals platformunun (dashboard ürünü) kullanımdan kaldırılacağını duyurdu — "On June 3, 2026, we notified developers using the Evals platform that the product is being deprecated." Duyuruya göre mevcut eval'ler 31 Ekim 2026'da salt-okunur hale gelecek ("Oct 31, 2026 — Existing evals become read-only") ve Evals dashboard ile API'nin 30 Kasım 2026'da tamamen kapatılması planlanıyor ("Nov 30, 2026 — The Evals dashboard and API are scheduled to shut down"). Bu yazıda OpenAI Evals API'sine dayalı hiçbir kod adımı önerilmedi; yukarıdaki bilgi yalnızca farkındalık amaçlıdır — OpenAI'nin platformundaki eval iş akışını kullanıyorsan geçiş planını bu tarihlere göre yapmalısın.

Sonradan yayımlanan ilgili yazılar:

• Agentic AI: Tool Use, Planner Loops ve Production Agent Mimarisi
• Prompt Engineering Desenleri: 10 Yıllık Arşivden Pratik Teknikler
• RAG mı Fine-tuning mi? Production LLM Kararları için Kesin Rehber
• LLM Benchmarks 2026: MMLU, HumanEval, SWE-bench ve Gerçek Performans
• LangGraph: AI Agent Framework Production Rehberi 2026
• AI Destekli Unit Test Üretimi: Claude Code + Cursor ile 2026 Workflow

Sonuç

Golden dataset + doğru derecelendirme karışımı, LLM uygulamanı "gözle bakmak"tan çıkarıp gerçekten ölçülebilir hale getirir: önce code-graded ile hızlı ve ucuz sinyal al, nüans gerektiren yerde net rubrikli LLM-as-judge'a geç, insan emeğini yalnızca belirsiz kalan satırlara sakla.

Kaynaklar

• Anthropic — Develop test cases — SMART başarı kriterleri, eval tasarım ilkeleri ve code/human/LLM-graded derecelendirme çerçevesinin birincil kaynağı.
• Zheng et al., "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" (arXiv:2306.05685) — LLM-judge önyargıları (position/verbosity/self-enhancement) ve insan-uyum oranı verisi.
• OpenAI — Deprecations: Evals platform — Evals platformunun deprecate/read-only/kapanış tarihleri.
• OpenAI — Evals guide — Evals ekosisteminin genel kavramsal çerçevesi.
• GitHub — openai/evals — Açık kaynak eval framework'ünün depo durumu ve güncellik bilgisi.