LLM ve RAG Değerlendirme 2026: 'Çalışıyor Gibi'den Ölçülebilir Kaliteye (Eval Setleri, LLM-as-Judge, RAGAS)

TL;DR — Yapay zeka projelerinde en pahalı cümle "demoda çalışıyor gibi"dir. Bir sistemin gerçekten kaliteli olup olmadığını anlamanın tek yolu, onu sistematik biçimde ölçmektir. Bu yazıda LLM ve RAG sistemlerini "iyi hissettiren" gösterilerden ölçülebilir kaliteye taşımanın yolunu anlatıyorum: temsil gücü yüksek eval (golden) veri setleri kurmak, offline ve online değerlendirmeyi ayırmak, LLM-as-judge yöntemini bilinçli kullanmak (pairwise vs rubrik, pozisyon/uzunluk/öz-tercih önyargıları, insan etiketleriyle kalibrasyon), RAG'a özgü RAGAS tarzı metrikler (faithfulness, answer relevance, context precision/recall), retrieval metrikleri (recall@k, MRR, nDCG, hit rate), halüsinasyon/groundedness tespiti, CI içinde regresyon testi, A/B testi ve canlı izleme, ve nihayet Türkçe eval setleri, KVKK ve AB Yapay Zeka Yasası boyutu. Sonunda pratik bir iş akışı, bir metrik tablosu ve tuzaklar listesi var.

Yıllardır kurumlara yapay zeka danışmanlığı ve eğitimi veriyorum ve bir cümle var ki, duyduğum anda içimde küçük bir alarm çalıyor: "Biz birkaç örnek denedik, gayet güzel çalışıyor gibi." Bu cümle kulağa olumlu geliyor, hatta proje ekibinin moralini yükseltiyor. Ama benim deneyimimde bu, bir yapay zeka projesinde söylenebilecek en pahalı cümledir. Çünkü "gibi" kelimesi, ölçülmemiş bir umudun üzerine inşa edilmiş koca bir yapının taşıyıcı kolonudur ve o kolon er ya da geç çöker.

Neden bu kadar tehlikeli? Çünkü bir dil modeli, demoda size en kolay, en temiz, en beklenen soruları sorduğunuzda gerçekten harika cevaplar verir. Siz farkında olmadan modeli ısıtırsınız: sorularınızı modelin güçlü olduğu alanlardan seçersiniz, cevabı zaten bildiğiniz için doğruyu fark edersiniz, yanlış olduğunda da "şunu biraz düzeltsek" diye prompt'u oynatırsınız. Demoyu yapan kişi aynı zamanda jüridir ve bu jüri taraflıdır. Gerçek kullanıcılar geldiğinde ise tablo değişir: yazım hatalı sorular, eksik bağlam, çelişkili talepler, modelin hiç görmediği niş konular, üst üste binmiş çok adımlı istekler. İşte o an "çalışıyor gibi" görünen sistem, "aslında çalışmıyormuş" gerçeğiyle yüzleşir; üstelik bu yüzleşme genellikle müşterinin, yöneticinin ya da denetçinin önünde olur.

Benim bu yazıdaki temel iddiam şu: Bir yapay zeka sistemini üretime almadan önce, onun kalitesini sayılarla konuşabilir hale getirmelisiniz. "İyi görünüyor" bir his değil, bir ölçüm sonucudur. Ve bu ölçümü kurmak, sandığınızdan hem daha kolay hem de projenin en yüksek getirili yatırımıdır. Çünkü ölçemediğiniz şeyi iyileştiremezsiniz; iyileştiremediğiniz şeyi de savunamazsınız.

Yazılım dünyasından gelenler "biz zaten test yazıyoruz" diyebilir. Ama klasik yazılım testi ile yapay zeka değerlendirmesi arasında temel bir fark var. Klasik testte girdi belirlidir, beklenen çıktı tek ve kesindir: 2 + 2 her zaman 4 döner. Dil modellerinde ise aynı soruya onlarca farklı ama hepsi "doğru" cevap olabilir. "İstanbul'un nüfusu kaç?" sorusuna model "Yaklaşık 15-16 milyon" da diyebilir, "16 milyona yakın" da diyebilir, ikisi de kabul edilebilir. Dolayısıyla değerlendirme, ikili (geçti/kaldı) bir mantıktan çok, bir kalite spektrumunu ölçme işidir.

Bu yüzden yapay zeka değerlendirmesi kendi başına bir disiplindir. Üç ayrı sorunun cevabını birbirinden ayırmamız gerekir: (1) Sistem doğru bilgiyi mi getiriyor (retrieval kalitesi)? (2) Getirdiği bilgiyi doğru ve sadık biçimde mi kullanıyor (generation kalitesi)? (3) Kullanıcının gerçek ihtiyacını mı karşılıyor (uçtan uca fayda)? Bu üç katmanı birbirine karıştırırsanız, sistem kötü çalıştığında nereyi düzelteceğinizi bilemezsiniz. RAG sistemlerinde en sık gördüğüm hata budur: cevap kötü çıkınca herkes prompt'u suçlar, oysa çoğu zaman sorun modelin önüne hiç doğru belge gelmemiş olmasıdır.

Her şey iyi bir değerlendirme veri setiyle başlar. Buna golden set, eval seti ya da değerlendirme kümesi diyoruz. Bu, sisteminizin gerçekten cevaplaması gereken soruların ve bizim için neyin "iyi cevap" sayıldığının yazılı olduğu referans koleksiyondur. Bu set olmadan yaptığınız her iyileştirme, karanlıkta atılan bir adımdır.

İyi bir eval setinin birkaç özelliği vardır. Temsil gücü en önemlisidir: setiniz, sistemin gerçek hayatta karşılaşacağı soruların dağılımını yansıtmalıdır. Eğer kullanıcıların yüzde 40'ı fatura soruyorsa, eval setinizin de kabaca yüzde 40'ı fatura sorusu olmalı. Bunu sağlamanın en sağlam yolu, gerçek kullanıcı sorularından beslenmektir. Hayalî, "olabilecek" sorular yazarak başlamak cazip gelir ama bu sizi yanıltır; çünkü gerçek kullanıcılar sizin asla aklınıza gelmeyecek şekillerde soru sorar. Canlı log'lardan, çağrı merkezi kayıtlarından, eski destek ticket'larından beslenin.

Her örnek için ne saklayacağız? İdeal olarak: soru, varsa ilgili bağlam/belge, beklenen cevap ya da en azından kabul kriterleri. Bazı sorularda tek doğru cevap vardır ("İade süresi kaç gün?" → "14 gün"). Bazılarında ise tek bir altın cevap yazmak imkânsızdır; o zaman cevap yerine kriter yazarsınız: "Cevap 14 günü belirtmeli, koşulsuz iade olmadığını söylemeli, kibar bir ton kullanmalı." Bu kriterler, birazdan anlatacağım LLM-as-judge için de temel oluşturur.

Eval setini bir kez kurup bırakmak yetmez. Sistemin her yeni hata yaptığı durum, sete eklenmesi gereken yeni bir örnektir. Ben buna "hatayı evcilleştirmek" diyorum: bir hata gördüğünüzde onu yakalayıp eval setine koyarsınız, böylece o hata bir daha sessizce geri gelemez. Zamanla eval setiniz, sisteminizin tüm zayıf noktalarının haritasına dönüşür.

Offline ve online değerlendirme

İki farklı dünyadan bahsediyoruz. Offline değerlendirme, sabit bir eval seti üzerinde, üretime çıkmadan, kontrollü ortamda yaptığınız ölçümdür. Tekrarlanabilir, ucuz ve hızlıdır; bir prompt değişikliğinin ya da yeni bir model sürümünün işleri iyileştirip iyileştirmediğini saniyeler içinde görürsünüz. Online değerlendirme ise sistem canlıdayken, gerçek kullanıcı trafiği üzerinde yaptığınız ölçümdür: kullanıcı geri bildirimleri, tıklama davranışları, terk oranları, A/B testleri. Offline size "lab koşullarında ne kadar iyi?" sorusunu cevaplar; online ise "gerçek dünyada işe yarıyor mu?" sorusunu. İkisine de ihtiyacınız var ve birini diğerinin yerine koyamazsınız.

Beklenen cevabı bir dize karşılaştırmasıyla ("cevap birebir bu mu?") kontrol etmek dil modellerinde çoğu zaman işe yaramaz, çünkü doğru cevabın yüzlerce farklı ifadesi vardır. İşte burada LLM-as-judge devreye girer: bir dil modelini, başka bir modelin ürettiği cevabı değerlendiren hakem olarak kullanırsınız. Bu yöntem son yıllarda değerlendirmeyi demokratikleştirdi çünkü hızlı, ölçeklenebilir ve insan değerlendirmesinden çok daha ucuz. Ama bir bıçak gibi: doğru tutarsanız işinizi görür, yanlış tutarsanız elinizi keser.

İki temel kullanım biçimi var. Pairwise (ikili) karşılaştırma: hakeme iki cevap verirsiniz (örneğin A ve B modelinin cevabı) ve "hangisi daha iyi?" diye sorarsınız. İnsanlar gibi modeller de mutlak puan vermekte zorlanır ama karşılaştırma yapmakta iyidir; bu yüzden pairwise genellikle daha güvenilir sonuç verir. İki model ya da iki prompt sürümü arasında seçim yaparken idealdir. Rubrik/kriter bazlı puanlama: hakeme bir cevap ve net kriterler verirsiniz ("Doğruluk, sadakat, ton ve tamlık açısından 1-5 arası puanla, her biri için gerekçe yaz") ve mutlak puan istersiniz. Tek bir cevabı belirli bir standarda göre ölçmek istediğinizde bu daha uygundur.

LLM-as-judge'ın bilinen önyargıları

Burada dürüst olmam gerekiyor, çünkü bu konuda fazla iyimserlik tehlikeli. LLM hakemlerin sistematik önyargıları vardır ve bunları bilmeden kullanmak sizi yanıltır:

• Pozisyon önyargısı (position bias): Pairwise karşılaştırmada hakem, kendisine ilk gösterilen cevabı sistematik olarak kayırma eğilimindedir. Çözüm: her karşılaştırmayı iki kez, sırayı değiştirerek yapın; sadece her iki sırada da kazanan cevabı gerçekten "daha iyi" sayın.
• Uzunluk önyargısı (verbosity bias): Hakem, daha uzun ve detaylı görünen cevabı, içeriği daha iyi olmasa bile daha çok beğenme eğilimindedir. Bu, sistemlerinizi farkında olmadan gereksiz uzun cevaplar üretmeye doğru iter. Rubriğinizde "öz ve gereksiz tekrarsız olmak" kriterini açıkça eklemek bunu dengeler.
• Öz-tercih önyargısı (self-preference bias): Bir model, kendi ürettiği ya da kendi stiline benzeyen cevapları kayırma eğilimindedir. Yani GPT ailesinden bir hakem, GPT'nin cevaplarını; başka bir aile kendi cevaplarını hafifçe yukarı çekebilir. Mümkünse hakem modeli, değerlendirilen modelden farklı bir aileden seçin.

Bunlara ek olarak hakemler tutarsız olabilir (aynı cevaba farklı zamanlarda farklı puan), aşırı cömert olabilir (her şeye 4-5 verir), ve karmaşık akıl yürütme gerektiren konularda yanılabilir.

Kalibrasyon: hakeme güvenmeden önce hakemi test edin

LLM-as-judge'ı kör güvenle kullanmak yerine onu insan etiketleriyle kalibre etmelisiniz. Pratikte şöyle yaparım: birkaç yüz örneği önce insanlar değerlendirir (altın insan etiketi), sonra aynı örnekleri LLM hakem değerlendirir. İkisi arasındaki uyumu ölçerim. Eğer hakem insan kararlarıyla yüksek uyum gösteriyorsa, o hakeme o görev için güvenebilirim ve insan değerlendirmesini ölçekleyebilirim. Uyum düşükse, ya rubriği netleştirmem, ya hakem modelini değiştirmem, ya da o görevi insana bırakmam gerekir. Kritik nokta şu: LLM hakem, insan yargısının yerine geçmez; insan yargısını ölçekler. Önce o yargıyı küçük ölçekte yakalamalı, sonra hakemin onu ne kadar iyi taklit ettiğini doğrulamalısınız.

Ne zaman güvenirim, ne zaman güvenmem? Ton, format, akıcılık, açık kriterlere uyum gibi nispeten yüzeysel ve net konularda LLM hakem çok iyidir. Derin alan uzmanlığı, hukuki/tıbbi doğruluk, ince mantık hataları, güvenlik açıkları gibi konularda ise hakeme tek başına asla güvenmem; orada insan uzman şarttır.

RAG (Retrieval-Augmented Generation) sistemlerinde işler daha katmanlıdır çünkü iki ayrı motor vardır: bilgiyi getiren (retrieval) ve cevabı üreten (generation). RAGAS gibi çerçeveler bu iki katmanı ayrı ayrı ölçmenizi sağlayan metrikler sunar. Bu ayrım benim için kutsaldır, çünkü teşhisin yarısı buradadır.

Dört temel RAGAS tarzı metriği şöyle anlatabilirim:

• Faithfulness (sadakat / groundedness): Üretilen cevap, getirilen bağlama gerçekten dayanıyor mu, yoksa model kendi kafasından bir şeyler mi uyduruyor? Bu, halüsinasyonun doğrudan ölçüsüdür. Cevaptaki her iddianın, getirilen belgelerle desteklenip desteklenmediğine bakılır. Düşük faithfulness, modelin "uydurduğu" anlamına gelir.
• Answer relevance (cevap uygunluğu): Cevap, sorulan soruya gerçekten cevap veriyor mu, yoksa konunun etrafında dolaşıp asıl soruyu cevaplamadan mı bırakıyor? Doğru ama alakasız cevaplar burada düşük puan alır.
• Context precision (bağlam kesinliği): Getirilen belgeler arasında gerçekten ilgili olanlar üst sıralarda mı? Yani retrieval, alakasız belgelerle gürültü mü yapıyor, yoksa isabetli mi? Yüksek precision, modele temiz bir masa sunulduğu anlamına gelir.
• Context recall (bağlam erişimi): Cevap için gereken tüm bilgiler getirilen bağlamda mevcut muydu? Eğer doğru cevap için gereken belge hiç getirilmediyse, model ne kadar iyi olursa olsun o soruyu cevaplayamaz. Düşük recall, retrieval'ın eksik kaldığını gösterir.

Bu dördünü birlikte okumak teşhis koydurur. Diyelim cevap kötü. Faithfulness düşükse model uyduruyordur (generation sorunu, prompt'u düzeltin). Context recall düşükse doğru belge hiç gelmemiştir (retrieval sorunu, indexleme/chunking/embedding'e bakın). Context precision düşükse doğru belge gelmiş ama gürültü içinde boğulmuştur (re-ranking'e bakın). Görüyorsunuz: aynı "kötü cevap" semptomunun üç tamamen farklı tedavisi var ve metrikler olmadan hangisini uygulayacağınızı bilemezsiniz.

Generation'dan bağımsız olarak, sadece retrieval katmanının ne kadar iyi olduğunu klasik bilgi erişimi metrikleriyle ölçeriz. Bunun için her sorgu karşısında "hangi belge(ler) gerçekten doğruydu" bilgisini içeren bir set gerekir.

• Recall@k: İlk k belge arasında, gerçekten ilgili belgelerin ne kadarını yakaladık? Doğru belgenin sisteme hiç ulaşmadığı durumları yakalamak için en kritik metriktir. RAG'da recall genellikle precision'dan daha önemlidir, çünkü doğru belge ilk k içinde değilse model o bilgiye asla erişemez.
• MRR (Mean Reciprocal Rank): İlk doğru belge ortalama olarak kaçıncı sırada geliyor? Doğru cevabın ne kadar üste çıktığını ölçer; özellikle tek doğru belgeli senaryolarda kullanışlıdır.
• nDCG (normalized Discounted Cumulative Gain): Hem ilgililik derecesini hem de sıralamayı dikkate alan, en zengin metriktir. Üst sıralardaki isabetlere daha çok değer verir; çok belgeli, dereceli ilgililik senaryolarında en bilgilendirici ölçüdür.
• Hit rate: Sorguların ne kadarında en az bir ilgili belge ilk k içinde geldi? Basit ama güçlü bir sağlık göstergesi; "kaç sorguda retrieval tamamen ıskaladı?" sorusunu cevaplar.

Bu metrikleri ayrı ölçmenin değeri şu: generation'ı hiç çalıştırmadan, retrieval'ı tek başına optimize edebilirsiniz. Embedding modelini değiştirmek, chunk boyutunu ayarlamak, re-ranker eklemek gibi kararları bu metrikler üzerinden hızlıca test edersiniz; üstelik bu testler ucuz ve deterministiktir.

Kurumların en çok korktuğu şey halüsinasyondur: modelin kendinden emin bir tonla yanlış bilgi uydurması. RAG, doğru kurulduğunda halüsinasyonu azaltır ama yok etmez. Groundedness tespiti, üretilen her iddiayı alıp "bu iddia, getirilen kaynaklarda destekleniyor mu?" diye kontrol etmektir. Bunu hem otomatik (bir LLM hakeme cevabı ve kaynakları verip her cümlenin desteklenip desteklenmediğini sormak) hem de örneklemle insan denetimi olarak yaparım. Yüksek riskli alanlarda (hukuk, sağlık, finans) sisteme "kaynakta bulamadığım bir şeyi söyleme, emin değilsem 'bilmiyorum' de" davranışını öğretmek ve bunu eval'de ölçmek hayati önemdedir. Bir kurumsal asistanın "bilmiyorum" demeyi öğrenmesi, çoğu zaman daha akıllı cevaplar vermesinden daha değerlidir.

Yapay zeka sistemlerinin sinsi bir yanı var: bir yeri düzeltirken başka bir yeri sessizce bozabilirsiniz. Bir prompt'u şu soru için iyileştirirsiniz, ama o değişiklik başka beş soruyu bozar ve siz bunu fark etmezsiniz; çünkü o beş soruyu tekrar denemediniz. İşte bu yüzden eval setini sürekli entegrasyon (CI) hattına koymanızı şiddetle tavsiye ederim. Klasik yazılımda her commit'te birim testleri çalışır ya; burada da her prompt ya da model değişikliğinde eval seti otomatik çalışmalı ve metrikler bir eşiğin altına düşerse değişiklik durdurulmalı.

Bunu "prompt regresyon testi" olarak düşünün. GPT-4'ten daha yeni bir sürüme geçiyorsunuz, ya da bir başka sağlayıcının modelini deniyorsunuz: eval setini çalıştırıp önce-sonra metrikleri yan yana koymadan bu kararı vermek, gözü kapalı şerit değiştirmek gibidir. Model sağlayıcıları sessizce modellerini güncellediğinde de aynı eval, sizi "dün çalışan bugün çalışmıyor" sürprizinden korur. Otomatik eval, yapay zeka projelerinde geceleri rahat uyumanın bedelidir ve ucuz bir bedeldir.

Offline metrikler ne kadar iyi olursa olsun, gerçek karar gerçek kullanıcılarda verilir. A/B testi, iki sürümü (örneğin iki prompt ya da iki model) gerçek trafiğin farklı dilimlerine gösterip hangisinin gerçek kullanıcı davranışında daha iyi sonuç verdiğini ölçmenizi sağlar: çözüm oranı, kullanıcı memnuniyeti, takip soruları, terk. Offline'da kazanan sürümün online'da kaybettiğini şaşırtıcı sıklıkta görürsünüz; bu yüzden ikisini birlikte yürütmek gerekir.

Canlı izleme (observability) ise sürekli bir nabız tutmadır. Üç şeyi izlerim: drift (sorgu dağılımı zamanla değişiyor mu, kullanıcılar artık çok farklı şeyler mi soruyor, modelin performansı belirli kümelerde düşüyor mu?), kullanıcı geri bildirimi (beğen/beğenme, serbest yorum, eskalasyon oranı) ve trace'ler (her isteğin uçtan uca izi: hangi belgeler getirildi, modele ne gönderildi, ne döndü, ne kadar sürdü). İyi bir trace altyapısı, bir kullanıcı şikâyeti geldiğinde "tam olarak ne oldu?" sorusunu dakikalar içinde cevaplamanızı sağlar. İzleme olmadan canlı bir yapay zeka sistemi işletmek, göstergesiz uçak kullanmaya benzer.

Bunca otomasyondan sonra şunu net söyleyeyim: insan değerlendirmesinin yeri asla tamamen dolmaz. Yeni bir kullanım alanına girdiğinizde, "iyi cevap" tanımını ilk kez kurarken, yüksek riskli kararlarda ve LLM hakemi kalibre ederken insan şarttır. İnsan değerlendirmesi pahalı ve yavaştır ama bir şeyi sağlar ki başka hiçbir yöntem sağlayamaz: gerçek dünya yargısının altın standardı.

İnsan değerlendirmesini işe yarar kılmak için iki şey kritiktir. Birincisi iyi rubrik tasarımı: değerlendiricilere "iyi mi?" diye sormak işe yaramaz, herkesin "iyi"si farklıdır. Bunun yerine net boyutlar ve örneklerle tarif edersiniz: "Doğruluk: cevaptaki olgular kaynakla uyumlu mu? 1=ciddi hata var, 3=küçük eksik, 5=tam doğru." Her puan seviyesine örnek koymak, değerlendiriciler arası tutarlılığı muazzam artırır. İkincisi değerlendiriciler arası uyum (inter-annotator agreement): aynı örnekleri birden fazla kişiye verip ne kadar hemfikir olduklarını ölçmek. Düşük uyum, değerlendiricilerin kötü olduğunu değil, çoğu zaman rubriğinizin belirsiz olduğunu gösterir; uyumu yükseltmek için rubriği netleştirirsiniz. İnsan değerlendirmesinin kalitesi, rubriğinizin kalitesidir.

Burası benim sahada en çok ısrar ettiğim nokta. Yapay zeka değerlendirme literatürünün ve hazır benchmark'ların ezici çoğunluğu İngilizcedir ve bu benchmark'lar Türkçeye transfer olmaz. Bir model İngilizce bir benchmark'ta harika puan alıyor diye Türkçede de aynı kalitede olacağını varsaymak, kurumsal projelerde gördüğüm en yaygın ve en pahalı yanılgılardan biridir. Türkçenin sondan eklemeli yapısı, zengin morfolojisi, kurumsal jargonu, kısaltmaları ve kullanıcıların gerçek yazım alışkanlıkları, ancak Türkçe bir eval setiyle yakalanabilir.

Bu yüzden kendi Türkçe eval setinizi kurmanız pazarlık konusu değildir. Gerçek Türkçe kullanıcı sorularından beslenen, sizin alanınızın terminolojisini içeren, Türkçeye özgü incelikleri (büyük/küçük harf, Türkçe karakterler, resmi/samimi ton geçişleri) test eden bir set olmadan, hangi modelin sizin için gerçekten iyi olduğunu bilemezsiniz. LLM-as-judge hakeminin de Türkçe değerlendirmede iyi olduğunu ayrıca doğrulamanız gerekir; bir hakem İngilizcede iyi diye Türkçede de iyi olduğunu varsaymayın, onu da Türkçe insan etiketleriyle kalibre edin.

İkinci kritik boyut KVKK. Eval setlerini gerçek üretim verisinden beslemek çok değerlidir ama bu veri çoğu zaman kişisel veri içerir. Üretim log'larını eval'de kullanırken kişisel verileri maskelemek/anonimleştirmek, veri işleme amacının buna uygun olduğundan emin olmak, erişimi yetkilendirmek ve saklama sürelerine uymak gerekir. "Gerçek veriyle test edelim" iyi bir mühendislik içgüdüsüdür ama KVKK çerçevesinde disipline edilmeden uygulanırsa hukuki risk doğurur. Pratik yaklaşımım: üretim sorularından temsil gücü yüksek bir alt küme alıp kişisel verileri temizleyerek kalıcı, paylaşılabilir bir eval seti oluşturmak.

Üçüncüsü AB Yapay Zeka Yasası (EU AI Act). Türkiye'den AB pazarına ürün/hizmet veren ya da AB'li müşterileri olan kurumlar için bu giderek daha bağlayıcı. Yasa, özellikle yüksek riskli yapay zeka sistemleri için sistematik test, doğruluk/sağlamlık ölçümü, sürekli izleme ve kayıt tutma beklentileri getiriyor. Yani bu yazıda anlattığım her şey — eval setleri, metrikler, izleme, regresyon testi — sadece iyi mühendislik değil, aynı zamanda uyum (compliance) gereği haline geliyor. Değerlendirme altyapınızı bugün kurarsanız, yarın denetçi karşısında "kalitemizi şöyle ölçüyor ve şöyle izliyoruz" diyebilecek belgelenmiş bir hikâyeniz olur. Bu, ileride zorunlu olacak bir yatırımı erken yapmaktır.

Şimdiye kadar anlattıklarımı somut bir akışa dökeyim. Kurumlarda kurmaya çalıştığım sıra kabaca şudur:

1. Gerçek sorulardan eval seti kurun. Üretim log'larından, destek kayıtlarından temsil gücü yüksek 100-300 örnekle başlayın. Kişisel veriyi temizleyin. Her örneğe beklenen cevap ya da kabul kriterleri ekleyin. Türkçe için Türkçe set; İngilizce müşteri varsa ayrı İngilizce set.
2. Katmanları ayırın. Retrieval ve generation'ı ayrı ölçeceğinizi baştan kabul edin. Her sorgu için "doğru belge hangisiydi" bilgisini de işaretleyin ki retrieval metriklerini hesaplayabilesiniz.
3. Offline metrik panosu kurun. Retrieval için recall@k, MRR, nDCG, hit rate; RAG için faithfulness, answer relevance, context precision/recall; uçtan uca için LLM-as-judge rubrik puanları. İlk ölçümü "baseline" olarak dondurun.
4. LLM hakemi kalibre edin. Birkaç yüz örneği insanla etiketleyin, hakemle karşılaştırın, uyumu ölçün. Pozisyon önyargısı için sırayı çevirin, uzunluk önyargısı için rubriğe "öz olma" kriteri koyun, mümkünse hakemi farklı model ailesinden seçin.
5. Değişiklikleri eval üzerinden yapın. Her prompt/model/retrieval değişikliğini eval seti üzerinde önce-sonra ölçün. Bunu CI'a bağlayın; metrik eşik altına düşerse değişiklik geçmesin.
6. Üretime alın ve izleyin. Trace'leri toplayın, kullanıcı geri bildirimini yakalayın, drift'i izleyin. Önemli değişiklikleri A/B testiyle gerçek trafikte doğrulayın.
7. Geri besleyin. Canlıda gördüğünüz her yeni hata türünü eval setine ekleyin. Set büyüdükçe sisteminiz akıllanır; bu bir döngüdür, tek seferlik bir proje değil.

Aşağıdaki tablo, kurumlarda hızlı referans olarak kullandığım özettir.

Metrik	Neyi ölçer	Katman	Ne zaman dikkat
Recall@k	Doğru belge ilk k içinde mi	Retrieval	Düşükse: doğru bilgi modele hiç ulaşmıyor
MRR	İlk doğru belgenin ortalama sırası	Retrieval	Düşükse: doğru belge geç sıralarda
nDCG	Sıra + ilgililik derecesi	Retrieval	Çok belgeli, dereceli senaryolarda en bilgilendirici
Hit rate	En az bir ilgili belge geldi mi	Retrieval	Retrieval'ın tamamen ıskaladığı sorguları yakalar
Faithfulness	Cevap kaynağa sadık mı	Generation	Düşükse: halüsinasyon var, prompt'u sıkılaştırın
Answer relevance	Cevap soruyu karşılıyor mu	Generation	Düşükse: doğru ama alakasız cevaplar
Context precision	İlgili belgeler üstte mi	Retrieval/Re-rank	Düşükse: gürültü var, re-ranking düşünün
Context recall	Gereken bilgi bağlamda var mıydı	Retrieval	Düşükse: index/chunking/embedding sorunu
LLM-as-judge (rubrik)	Uçtan uca kalite, ton, tamlık	Uçtan uca	Önce insanla kalibre edin, önyargılara dikkat
İnsan değerlendirmesi	Altın standart yargı	Uçtan uca	Yüksek risk ve kalibrasyon için vazgeçilmez

Sahada tekrar tekrar gördüğüm hataları toparlayayım; bunları baştan bilmek size çok zaman kazandırır:

• Eval setini hayalî sorularla kurmak. Gerçek kullanıcı sorularından beslenmeyen set, sizi var olmayan bir sistemi optimize etmeye iter.
• Retrieval ve generation'ı ayırmamak. Cevap kötü çıkınca hep prompt'u suçlamak; oysa sorun çoğu zaman modele doğru belgenin hiç gelmemesidir.
• LLM hakeme kör güvenmek. Kalibrasyon yapmadan, önyargıları bilmeden hakem puanlarına tam güvenmek, ölçtüğünüzü sandığınız şeyi aslında ölçmemenize yol açar.
• Pozisyon ve uzunluk önyargısını ihmal etmek. Sırayı çevirmeden yapılan pairwise karşılaştırma ve "uzun = iyi" tuzağı, sistematik yanlış sonuç üretir.
• İngilizce benchmark'a güvenip Türkçe set kurmamak. İngilizcede iyi olan model Türkçede iyi olacak diye varsaymak, en pahalı yanılgı.
• Eval'i CI'a bağlamamak. Manuel ve ara sıra yapılan değerlendirme, sessiz regresyonları yakalayamaz.
• Sadece offline'a güvenmek. Lab'da kazanan, gerçek kullanıcıda kaybedebilir; online doğrulama şart.
• KVKK'yı atlamak. Üretim verisini temizlemeden eval'de kullanmak, hukuki risk.
• Halüsinasyona "bilmiyorum" demeyi öğretmemek. Yüksek riskli alanda emin olmadan konuşan model, en tehlikeli moddur.
• Eval'i tek seferlik proje sanmak. Değerlendirme bir döngüdür; her yeni hatayla büyür.

Eğer bir yapay zeka sisteminiz varsa ve ona dair kaliteyi hâlâ "iyi görünüyor" diye konuşuyorsanız, bu yazıdan tek bir şey almanızı isterim: bu hafta, gerçek kullanıcı sorularınızdan 50 tanesini alıp beklenen cevaplarıyla birlikte bir tabloya yazın. İşte o tablo, sizin ilk eval setiniz. Onun üzerinde sisteminizi bir kez çalıştırın ve sayıları görün. Büyük ihtimalle ilk reaksiyonunuz "vay be, sandığımdan farklıymış" olacak; çünkü ölçtüğünüz an, sezginizle gerçeklik arasındaki boşluğu da görmüş olursunuz.

Değerlendirme, yapay zeka projelerinde fren değil direksiyondur. Sizi yavaşlatmaz, doğru yöne sürmenizi sağlar. "Çalışıyor gibi"den "şu metriklerle, şu eval setinde, şöyle çalışıyor"a geçtiğiniz an, projeniz bir gösteri olmaktan çıkıp güvenilebilir bir ürüne dönüşür. Ve bir danışman olarak size söyleyebileceğim en sahici şey şu: ölçmeye başlayan kurumlar, ölçmeyenlerden çok daha hızlı ilerliyor; çünkü artık karanlıkta değil, ışıkta yürüyorlar. Bugün küçük bir eval setiyle yakacağınız o ışık, yarın bütün yapay zeka stratejinizi aydınlatacak.