LLM Değerlendirmesi: Metrikler, Çerçeveler ve 2026'da Gerçekten İşe Yarayan Nedir

LLM değerlendirmesi, "sanki iyi görünüyor" ile "işe yaradığını kanıtlayabilirim" arasındaki farktır. LLM destekli özellikler yayına alırken sistematik bir değerlendirme yapmıyorsanız, esasen test edilmemiş kod deploy ediyorsunuz demektir; fark şu ki hata modları stack trace yerine halüsinasyon, toksisite ve sessizce yanlış yanıtlar.

Bu rehber her şeyi kapsıyor: metrikler, yöntemler, çerçeveler, pipeline tasarımı ve AB Yapay Zeka Yasası uyumluluğu. Tedarikçi yanlılığı yok, dolgu içerik yok.

Özet Bakış

Ayrıntılara girmeden önce, işte tek tabloda tam tablo.

Şimdi her parçayı tek tek ele alalım.

LLM Değerlendirmesi Nedir (ve 2026'da Neden Önemlidir)?

LLM değerlendirmesi, büyük dil modeli çıktılarının kalitesini tanımlanmış ölçütlere göre — doğruluk, alaka, güvenlik ve kaynak verisine sadakat — sistematik olarak ölçüp puanlama sürecidir. LLM destekli uygulamaların üretimde güvenilir sonuçlar verdiğinden emin olmak için otomatik metrikleri, LLM-as-a-judge puanlamasını ve insan incelemesini kapsar.

Bu neden şu an önemli? İki neden var. Birincisi, LLM'ler prototipten gerçek kullanıcıların güvendiği üretim özelliklerine dönüştü. Şirket politikasını halüsine eden bir chatbot ya da var olmayan belgelere atıfta bulunan bir RAG sistemi artık eğlenceli bir demo hatası değil; destek talebi, hukuki risk ya da kaybedilen bir müşteri demek.

İkincisi, AB Yapay Zeka Yasası uygulaması Ağustos 2026'da başlıyor. Yapay zeka sisteminiz AB kullanıcılarına hizmet veriyorsa, "birkaç prompt test ettim ve iyi görünüyordu" yazan bir Slack mesajı değil, belgelenmiş değerlendirme pratiklerine ihtiyacınız olacak.

Çoğu ekip hâlâ "his bazlı değerlendirme" diyebileceğimiz şeyi yapıyor — playground'da birkaç çıktıyı spot kontrol edip yeterince iyi göründüğüne karar vermek. Bu, LLM'ler birer deneyken işe yarıyordu. Özellik olduğunda yaramıyor.

Değerlendirme üç soruyu yanıtlar: Çıktı doğru mu? Güvenli mi? Yararlı mı? Bu rehberin geri kalanı üçünü de sistematik olarak nasıl yanıtlayacağınızı gösteriyor.

Önemli bir ayrım: bu rehber uygulama değerlendirmesini ele alıyor — LLM destekli ürününüzün gerçek görevlerde nasıl performans gösterdiğini test etmek. Bu, model değerlendirmesinden (MMLU gibi ön eğitim kıyaslamaları) farklı; model değerlendirmesi, bir temel modelin genel performansını söyler ama spesifik uygulamanızda nasıl davranacağına dair neredeyse hiçbir şey söylemez.

Sonuç: Sistematik değerlendirme yapmadan LLM özellikleri yayına alıyorsanız, kör uçuyorsunuz demektir. Soru değerlendirme yapıp yapmayacağınız değil — nasıl yapacağınız.

LLM Değerlendirme Metrikleri — Ne Zaman Ne Ölçülür

Takip edeceğiniz metrikler tamamen ne inşa ettiğinize bağlıdır. Bir chatbot, kod oluşturucudan farklı bir değerlendirme gerektirir. İşte alfabetik sıraya göre değil, kullanım senaryosuna göre düzenlenmiş pratik bir taksonomi.

Metin Benzerlik Metrikleri (Referans Yanıtlarınız Olduğunda)

Bu klasik metrikler, oluşturulan metni bilinen doğru bir referansla karşılaştırır:

• BLEU, n-gram hassasiyetini ölçer — çıktıdaki kaç sözcük dizisi referansla eşleşiyor. Başlangıçta makine çevirisi için tasarlandı.
• ROUGE, geri çağırmayı ölçer — referans içeriğinin ne kadarı çıktıda yer alıyor. Özetleme görevlerinde yaygın.
• BERTScore, BLEU ve ROUGE'un kaçırdığı parafrazları yakalamak için anlamsal benzerliği ölçmek amacıyla bağlamsal embedding'leri kullanır.

Tuzak şu: Bunlar yalnızca karşılaştırılacak gerçek cevap yanıtlarına sahip olduğunuzda işe yarar. Açık uçlu üretim için BLEU'yu atlayın — yaratıcı yeniden ifadeyi cezalandırır, ki bu tam olarak iyi bir chatbot'tan istediğiniz şeydir.

Anlamsal Değerlendirme Metrikleri (Tam Eşleşme Değil, Anlam Gerektiğinde)

Açık uçlu üretim için anlam değerlendiren metriklere ihtiyacınız var:

• Answer relevancy, yanıtın kullanıcının sorusunu gerçekten ele alıp almadığını puanlar.
• Tutarlılık, çıktının mantıksal olarak ne kadar akıcı olduğunu ölçer.
• Özlülük, gereksiz yere uzun yanıtları işaretler.
• G-Eval esnek seçenektir: doğal dilde özel değerlendirme kriterleri tanımlarsınız, LLM yargıcı çıktıları zincir düşünce muhakemesi kullanarak puanlar. 2026'da çoğu ekip zamanının büyük bölümünü burada harcıyor.

RAG'a Özgü Metrikler

Retrieval-augmented generation inşa ediyorsanız, iki bileşeni değerlendiriyorsunuz demektir — retriever ve üretici. Ragas çerçevesi dört temel metrik tanımlar:

• Faithfulness — Yanıt alınan bağlama dayandırılmış mı? Bu, halüsinasyonları tespit eder.
• Context relevancy — Retriever doğru belgeleri mi çekti?
• Context recall — Retriever TÜM ilgili belgeleri buldu mu?
• Answer relevancy — Yanıt gerçekten sorguyu ele alıyor mu?

Güvenlik ve Uyumluluk Metrikleri

Bu metrikler kullanıcılarınızı ve şirketinizi korur:

• Halüsinasyon oranı — bilinen kaynaklara göre olgusal doğruluk
• Toksisite tespiti — zararlı, saldırgan veya uygunsuz içerik
• Önyargı ölçümü — demografik gruplar arasında eşitsiz muamele
• PII sızıntı tespiti — çıktılarda kişisel verilerin görünmesi

Hangi Uygulama için Hangi Metrikler?

Bu, hiçbir tedarikçi rehberinin size vermediği tablodur. Her metriği alfabetik olarak listelemek yerine, uygulama türünüzü gerçekten önemli olan metriklerle eşleştirin:

Sonuç: Her şeyi ölçmeyin. SİZİN uygulama türünüze uyan 3-5 metrik seçin ve oraya odaklanın.

Değerlendirmeler Gerçekte Nasıl Çalıştırılır? (Üç Yöntem)

LLM çıktılarını değerlendirmenin üç yolu var. Çoğu üretim ekibi üçünü de kullanır, ancak çok farklı oranlarda.

Otomatik Metrikler (Hızlı, Ucuz, Sınırlı)

BLEU, ROUGE, tam eşleşme veya regex desenleri gibi metrikleri kullanan betik tabanlı puanlama. Bir test yazarsınız, milisaniyeler içinde çalışır ve geçti/kaldı alırsınız.

Artısı: hızlı, tekrarlanabilir ve esasen ücretsiz. Eksisi: bu metrikler nüansı, yaratıcılığı veya gerçek dünyadaki kullanışlılığı yargılayamaz. Bir yanıt ROUGE'da mükemmel puan alabilir ve yine de kullanıcı için işe yaramaz olabilir.

Otomatik metrikleri gerileme testi, CI/CD gate'leri ve derinlik yerine hıza ihtiyaç duyduğunuz yüksek hacimli tarama için kullanın.

LLM-as-a-Judge (2026 Standardı)

Sektörün gelip oturduğu yer burası. Çıktılarınızı kriterlerinize göre puanlamak için ayrı bir LLM kullanırsınız — genellikle GPT-4o veya Claude. G-Eval deseni şöyle çalışır: değerlendirme kriterlerinizi doğal dilde tanımlarsınız, yargıca kriterleri artı test durumunu verirsiniz, o da zincir düşünce muhakemesi artı bir puan üretir.

Zheng ve diğ.'nin araştırması insan puanlarıyla yaklaşık %81 korelasyon gösteriyor; başarısızlık modlarını anladığınızda (bir sonraki bölümde daha fazlası) günlük değerlendirme için yeterince iyi.

LLM-as-a-judge'u açık uçlu üretim, öznel kalite değerlendirmesi ve basit metriklerle yakalanamayan özel kriterler için kullanın.

İnsan Değerlendirmesi (Altın Standart, Ölçeklenmiyor)

Uzman değerlendiriciler, rubrikler, Likert ölçekleri veya kör A/B testleri kullanarak çıktıları puanlar. Bir yanıtı okuyan ve "bu gerçekten yararlı" ya da "bu kullanıcıyı karıştırır" diyen bir insanın yerini hiçbir şey tutamaz.

Sorun şu: değerlendirme başına 5-50 $ maliyeti var, milisaniyeler yerine dakikalar sürüyor ve her isteğe uygulayamazsınız. İnsan değerlendirmesini LLM-as-judge kalibrasyonu, uyumluluk denetimleri ve edge case doğrulaması için kullanın.

Yönteminizi Seçmek

Sonuç: Değerlendirmelerinizin %80'i için LLM-as-a-judge, CI/CD gate'leri için otomatik metrikler ve kalibrasyon ile uyumluluk için insan incelemesi kullanın. Bu 2026 oyun kitabıdır.

LLM-as-a-Judge: Nasıl Çalışır, Ne Zaman Başarısız Olur

LLM-as-a-judge, iyi nedenlerle varsayılan değerlendirme yöntemi haline geldi — esnek, nispeten ucuz ve insan yargısıyla iyi korelasyon kuruyor. Ancak tedarikçi rehberlerinin rahatlıkla atladığı gerçek kör noktaları var.

G-Eval Nasıl Çalışır

Desen basittir. Neyin "iyi" göründüğünü doğal dilde tanımlarsınız, yargıç LLM değerlendirilen çıktıyla birlikte kriterlerinizi okur, adım adım değerlendirir ve bir puan üretir.

İşte DeepEval'ın G-Eval uygulamasını kullanan pratik bir örnek:

from deepeval.metrics import GEval
from deepeval.test_case import LLMTestCase, LLMTestCaseParams

correctness_metric = GEval(
    name="Correctness",
    criteria="Determine if the output is factually correct based on the expected output.",
    evaluation_params=[
        LLMTestCaseParams.ACTUAL_OUTPUT,
        LLMTestCaseParams.EXPECTED_OUTPUT,
    ],
    threshold=0.7,
)

test_case = LLMTestCase(
    input="What is the capital of France?",
    actual_output="Paris is the capital of France.",
    expected_output="The capital of France is Paris.",
)

correctness_metric.measure(test_case)
print(f"Puan: {correctness_metric.score}")  # 0.0 ile 1.0 arası
print(f"Gerekçe: {correctness_metric.reason}")

Herhangi bir kriter tanımlayabilirsiniz — doğruluk, yardımseverlik, profesyonellik, marka sesi uyumu — ve yargıç LLM buna göre puanlayacaktır.

Bilinen Önyargılar (Tedarikçi Rehberlerinin Size Söylemeyeceği)

Çoğu değerlendirme rehberinin durduğu yer burası. Size kurulumu gösterip devam ederler. Ama LLM yargıçlarının değerlendirme sonuçlarınızı sessizce bozabilecek sistematik önyargıları var:

• Konum önyargısı: İki çıktıyı karşılaştırırken (A/B testi), LLM yargıçları tutarlı biçimde ilk sunulan seçeneği tercih eder. Sırayı değiştirin, "kazanan" değişir.
• Öz-tercih önyargısı: GPT-4, GPT-4 çıktılarını Claude'un aynı çıktıları puanlamasından daha yüksek puanlar ve tersi de geçerli. Yargıç kendi model ailesini kayırır.
• Ayrıntı önyargısı: Uzun yanıtlar, gerçek kaliteden bağımsız olarak daha yüksek puan alır. Aynı şeyi daha net söyleyen 100 kelimelik yanıta karşı 500 kelimelik yanıt daha iyi puan alır.
• Çıpalama önyargısı: Yargıca önceki puanları veya örnekleri gösterirseniz, sonraki derecelendirmeler o çıpalara çekilir.

Yargıç Önyargısını Azaltmak

Bu önyargılar, onları öğrendikten sonra yönetilebilir:

1. Seçenek sırasını rastgele yapın A/B karşılaştırmalarında (konum önyargısını giderir)
2. Farklı bir model ailesi kullanın üreticinizden yargıç olarak (öz-tercihi giderir)
3. Uzunluk normalleştirme talimatları ekleyin puanlama kriterlerinize (ayrıntı önyargısını giderir)
4. Çok yargıçlı paneller çalıştırın — 2-3 farklı LLM kullanın ve önemli değerlendirmeler için puanları ortalamalayın

Sonuç: LLM-as-a-judge şaşırtıcı derecede iyi çalışır — ama yalnızca kör noktalarını biliyorsanız. Ona tam güvenmeden önce her zaman spesifik kullanım durumunuzdaki insan puanlarına karşı doğrulayın.

RAG Sistemlerini Değerlendirme: Faithfulness, Relevancy ve Recall

RAG değerlendirmesi, 2026'nın açık ara en yaygın değerlendirme kullanım senaryosudur ve bağımsız bir LLM'yi değerlendirmekten temel olarak farklıdır. İki bileşeni test ediyorsunuz — retriever ve üretici — ve herhangi birindeki bir başarısızlık kötü çıktılar üretir.

Dört Temel Metrik

• Faithfulness — Oluşturulan yanıt gerçekten alınan bağlama dayandırılmış mı? Doğru kulağa gelen ama alınan belgelerde bulunmayan bilgileri içeren bir yanıt halüsinasyondur. Bu en önemli metriğinizdir.
• Context relevancy — Retriever gerçekten sorguyla ilgili belgeler mi çekti? Çöp girerse çöp çıkar.
• Context recall — Retriever TÜM ilgili belgeleri buldu mu, yoksa kritik bağlamı kaçırdı mı?
• Answer relevancy — Mükemmel retrieval ile bile, nihai yanıt gerçekten kullanıcının sorduğu şeyi ele alıyor mu?

Ragas ile RAG Değerlendirmesi Çalıştırma

Ragas, RAG değerlendirmesi için özel olarak tasarlanmış çerçevedir. İşte temel desen:

from ragas import evaluate
from ragas.metrics import faithfulness, context_relevancy, answer_relevancy
from datasets import Dataset

# Değerlendirme veri setiniz
eval_data = {
    "question": ["İade politikamız nedir?"],
    "answer": ["Satın alma tarihinden itibaren 30 gün içinde iade talep edebilirsiniz."],
    "contexts": [["İade Politikası: Müşteriler 30 gün içinde tam iade talep edebilir."]],
    "ground_truth": ["Müşteriler 30 gün içinde iade alabilir."],
}

eval_dataset = Dataset.from_dict(eval_data)

result = evaluate(
    dataset=eval_dataset,
    metrics=[faithfulness, context_relevancy, answer_relevancy],
)
print(result)
# {'faithfulness': 0.95, 'context_relevancy': 0.88, 'answer_relevancy': 0.91}

Yaygın RAG Değerlendirme Hataları

Ekiplerin tekrar tekrar tökezlediği üç desen:

1. Yalnızca üreticiyi değerlendirmek ve retriever kalitesini görmezden gelmek. Yanıtınız yanlış belgelerden mükemmel biçimde üretilmiş olabilir.
2. RAG için BLEU veya ROUGE kullanmak — bu metrikler halüsinasyonları hiç tespit edemez. Bir yanıt ROUGE'da yüksek puan alabilirken uydurma bilgiler içerebilir.
3. Adversarial sorgularla test etmemek — retrieval'ı bozan edge case'ler (belirsiz sorgular, kapsam dışı sorular, ilgili belgesi olmayan sorgular) RAG sistemlerinin en sert başarısız olduğu yerdir.

Yapay zeka uygulamanız için doğru yığını seçerken, altyapınızın baştan değerlendirmeyi desteklemesini sağlayın — sonradan eklemek her zaman daha zordur.

Sonuç: RAG değerlendirmesi pazarlık konusu değil. faithfulness ve context_relevancy, takip etmeniz gereken iki zorunlu metriğinizdir. Geri kalan her şey ikincildir.

Yapay Zeka Ajanlarını Değerlendirme: Tek Çağrı Metriklerinin Ötesi

Ajan değerlendirmesi, işlerin gerçekten zorlaştığı yerdir. Bir chatbot ya da RAG sisteminin aksine, ajan birden fazla adım atar, araçlar kullanır, kararlar verir ve beklenmedik yönlere gidebilir. Geleneksel tek çağrı metrikleri bunu yakalayamaz.

Ajana Özgü Metrikler

• Görev tamamlama oranı — Ajan genel hedefi tamamladı mı? Bu kuzey yıldızı metriğinizdir.
• Araç kullanım doğruluğu — Doğru araçları doğru parametrelerle çağırdı mı? Yanlış filtrelerle bir veritabanı sorgusu çağıran ajan görevi yanlış verilerle "tamamlayabilir".
• Bağlam tutma — Ajan çok adımlı bir iş akışı boyunca tutarlı bağlamı koruyor mu, yoksa yolunu kaybediyor mu?
• Başarılı görev başı maliyet — Ajanlar API çağrılarını yakabilir. 5 adım alması gereken bir görevi 47 LLM çağrısıyla tamamlayan ajan, üretim maliyeti sorunudur.
• Hata kurtarma — Bir araç çağrısı başarısız olduğunda ya da beklenmedik sonuçlar döndürdüğünde, ajan adapte oluyor mu yoksa döngüde mi sıkışıyor?

İstatistiksel Test Zorluğu

Ajan değerlendirmesini temel olarak farklı kılan şey şudur: ajan davranışı deterministik değildir. Aynı görevi on kez çalıştırın ve yedi başarı, iki kısmi tamamlama ve bir sonsuz döngü elde edebilirsiniz. İstatistiksel değerlendirmeye ihtiyacınız var — her test durumunu N kez çalıştırın ve tamamlama oranlarını raporlayın, geçti/kaldı değil.

Çerçeveler yetişiyor. DeepEval artık ajana özgü metrikler içeriyor ve AWS ajansal değerlendirme kalıpları yayımladı. Ama dürüst olmak gerekirse, araç desteği hâlâ erken aşamada. Üretimde yapay zeka ajanları deploy ediyorsanız, özel değerlendirme mantığı oluşturmayı bekleyin.

Sonuç: Ajan değerlendirmesi hâlâ erken aşamada, ancak görev tamamlama oranı ve görev başı maliyet, birinci günden takip etmeniz gereken iki metriğinizdir.

LLM Değerlendirme Çerçevelerinin Karşılaştırması

Her mevcut çerçeve karşılaştırması, kendini birinci sıraya koyan bir tedarikçi tarafından yazılmıştır. İşte tarafsız sürüm.

Bunu Seçin Eğer...

• Yeni başlıyorsanız: DeepEval ya da Ragas — her ikisi de ücretsiz, iyi belgelenmiş, hızlı kurulum
• LangChain kullanıyorsanız: LangSmith — derin entegrasyon onu en az dirençli yol yapıyor
• CI/CD engellemesi gerekiyorsa: Braintrust — değerlendirme başarısızlığında deployment'ları natively engelleyen tek araç
• Kendi barındırdığınız gözlemlenebilirlik istiyorsanız: Langfuse — en iyi açık kaynak tracing + değerlendirme kombinasyonu
• Üretim izlemesi gerekiyorsa: Arize Phoenix — en güçlü embedding analizi ve kayma tespiti
• Yalnızca RAG değerlendiriyorsanız: Ragas — amaca özel, hafif, en iyi RAG metrikleri

Her araç için fiyatlandırma dökümleri ve kurulum kılavuzlarını içeren daha derin bir bakış için Best LLM Evaluation Tools [yakında] bağlantımıza göz atın.

Sonuç: Tek bir "en iyi" çerçeve yoktur. Özel metrikler için DeepEval, RAG için Ragas, CI/CD için Braintrust, kendi barındırdığınız gözlemlenebilirlik için Langfuse. İş akışınıza uyanı seçin.

Değerlendirme Pipeline'ınızı Oluşturmak: Ad-hoc'tan Otomatiğe

LLM özellikleri inşa eden çoğu ekip, Seviye 1 dediğimiz yerde sıkışıp kalmaktadır — birkaç çıktıyı manuel olarak kontrol etmek ve en iyisini ummak. Nasıl ilerleyeceğiniz aşağıda.

Değerlendirme Olgunluk Modeli

Altın Veri Seti Oluşturma

Değerlendirmeniz yalnızca test verileriniz kadar iyidir. Gerçek kullanıcı sorgularını temsil eden, edge case'leri ve adversarial girdileri içeren ve beklenen davranışın tüm yelpazesini kapsayan 50-100 el kurasyonlu örnekle başlayın.

Veri setlerinizi versiyonlayın. Ürününüz geliştikçe onlar da gelişmeli — yeni özellikler yeni test senaryoları demektir. Altı ay önceki altın veri seti muhtemelen kullanıcılarınızın bugün ne yaptığını yansıtmıyor.

Değerlendirme sonuçlarınızın kalitesi, gerçek cevap verilerinizin kalitesine eşittir. Zamana yatırım yapın.

CI/CD Entegrasyonu

Altın veri setiniz hazır olunca, onu deployment pipeline'ınıza bağlayın. Prompt'lara, retrieval mantığına veya model yapılandırmasına dokunan her PR'da değerlendirme çalıştırın. Her prompt engineering değişikliği, sezgiyle değil ölçülebilir bir puanla doğrulanmalı. Puan eşikleri belirleyin — örneğin faithfulness >= 0.8 ve hallucination_rate < 0.05 — ve başarısız olurlarsa deployment'ı engelleyin.

Başlangıç noktası olarak minimal bir GitHub Actions kurulumu:

# .github/workflows/llm-eval.yml
name: LLM Evaluation
on:
  pull_request:
    paths: ['prompts/**', 'src/llm/**']
jobs:
  evaluate:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: '3.11'
      - run: pip install deepeval
      - run: deepeval test run tests/eval_suite.py
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

Bu, birisi bir prompt dosyasını ya da LLM ile ilgili kodu değiştirdiğinde değerlendirmeyi tetikler. Herhangi bir metrik eşiğin altına düşerse PR birleştirilemez. Bu, LLM uygulamaları için gerileme testidir.

Üretim İzleme

Üretime geçtiğinizde, canlı trafiği örnekleyip değerlendirin — %1-5 tipiktir. Zaman içindeki metrik kaymayı takip edin, çünkü model güncellemeleri, veri değişiklikleri ve kullanıcı davranışındaki kayma kimse fark etmeden kaliteyi düşürebilir.

Metrikler eşiklerin altına düştüğünde uyarı kurun. Uyumluluk denetimleri için tüm değerlendirmeleri kaydedin (AB Yapay Zeka Yasası denetimi geldiğinde kendinize teşekkür edeceksiniz). Gergely Orosz'un belirttiği gibi, değerlendirme sürekli bir süreç olmalıdır, yayın onay kutusu değil.

Sonuç: Çoğu ekip Seviye 1'de (his) sıkışmış. Seviye 2'ye (altın veri setleri) geçmek bir gün sürer ve LLM özellikleri yayına alma konusundaki güveninizi dramatik biçimde değiştirir.

AB Yapay Zeka Yasası ve LLM Değerlendirmesi: Uyumluluk için Neye İhtiyacınız Var

Bu, başka hiçbir değerlendirme rehberinin ele almadığı bölümdür — ve Ağustos 2026 uygulaması yaklaşırken, mühendislik liderleri ve CTO'lar için en çok önem taşıyan bölüm budur.

AB Yapay Zeka Yasası Neyi Gerektiriyor

AB Yapay Zeka Yasası (Yönetmelik 2024/1689), yapay zeka sistemlerini risk düzeyine göre sınıflandırır ve buna göre gereksinimler getirir. Yüksek riskli sistemlerin sistematik değerlendirme, dokümantasyon ve süregelen izlemeye ihtiyacı vardır. "Sınırlı risk" kapsamındaki sistemler bile (çoğu LLM uygulamasının düştüğü yer) şeffaflık ve dokümantasyon yükümlülüklerine sahiptir.

Temel nokta: AB'de değilseniz bile, yapay zeka sisteminiz AB kullanıcılarına hizmet veriyorsa bu kurallar size uygulanır. Avrupa Komisyonu'nun risk sınıflandırma çerçevesi, sisteminizin nereye düştüğünü belirlemenize yardımcı olur.

Değerlendirme Pratiklerini Uyumluluğa Eşleme

Değerlendirme metriklerinizin AB Yapay Zeka Yasası maddeleriyle doğrudan nasıl bağlantılı olduğu:

Uyumluluk için Kırmızı Takım Oluşturma

AB Yapay Zeka Yasası, yüksek riskli sistemler için adversarial test gerektiriyor. Kırmızı takım oluşturma, sisteminizi kırmaya sistematik olarak çalışmak demektir:

• Prompt enjeksiyonu — Kullanıcılar sistem prompt'larını manipüle edebiliyor mu?
• Jailbreak denemeleri — Kullanıcılar güvenlik yönergelerini atlatabiliyor mu?
• Önyargı yoklaması — Sistem demografik grupları farklı mı ele alıyor?
• Veri çıkarma — Kullanıcılar eğitim verisini ya da PII'yi çıkarabiliyor mu?

Her şeyi belgeleyin: metodoloji, bulgular, azaltmalar. En az çeyreklik kırmızı takım tatbikatları planlayın.

Ağustos 2026 Hazırlığı için Pratik Adımlar

1. Yapay zeka sisteminizin risk düzeyini sınıflandırın (çoğu LLM uygulaması "sınırlı risk")
2. Değerlendirme metriklerini ve eşiklerini şimdi belirleyin
3. CI/CD'de otomatik değerlendirmeyi uygulayın
4. Denetim günlüklü üretim izlemesi kurun
5. Değerlendirme metodolojinizi resmi olarak belgeleyin
6. Düzenli kırmızı takım tatbikatları planlayın
7. Olay müdahale prosedürlerini hazırlayın

Sonuç: AB'de olmayanlara da geçerli: Yapay Zeka Yasası küresel standardı belirliyor. Şimdi değerlendirme ve dokümantasyon pratikleri oluşturmak, daha sonra telaşa düşmekten kurtarır.

Yaygın Değerlendirme Hataları (ve Nasıl Önlenir)

Ekiplerin LLM değerlendirme pipeline'ları kurmasına yardımcı olduktan sonra, tekrar tekrar gördüğümüz hatalar bunlar:

1. Eğitim verinizle değerlendirme yapmak — Test senaryolarınız modelin ince ayar sırasında gördüğü şeylerle örtüşüyorsa, puanlarınız anlamsızdır. Her zaman tutulmuş değerlendirme setleri kullanın.
2. Açık uçlu görevler için BLEU/ROUGE kullanmak — Bu metrikler yüzeysel metin örtüşmesini ölçer. Halüsinasyonları tespit edemez, yardımseverliği değerlendiremez ya da yaratıcı kaliteyi yargılayamaz.
3. Kıyaslamalara körce güvenmek — Kıyaslama kirlenmesi gerçektir. MMLU sorularıyla eğitilen modeller MMLU'da iyi puan alır, ama bu spesifik görevinizde iyi performans göstereceği anlamına gelmez. Her zaman uygulamaya özgü değerlendirmeler kullanın.
4. İnsan kalibrasyonunu atlamak — LLM-as-judge, ona güvenmeden önce SİZİN verilerinizde insan puanlarına karşı doğrulama gerektirir. En az 50 örneği hem insan değerlendiriciler hem LLM yargıcı üzerinden çalıştırın, ardından korelasyonu kontrol edin.
5. Tek seferlik değerlendirme — Değerlendirme, yayın onay kutusu değildir. Modeller değişir, kullanıcı davranışı kayar ve retrieval kalitesi bozulur. Onu sürekli kılın.
6. Yargıç ve üretici olarak aynı model — Öz-tercih önyargısı puanları şişirir. Yargılama için farklı bir model ailesi kullanın.
7. Değerlendirme veri setlerinizi versiyonlamamak — Değerlendirmeleriniz ürününüzle birlikte gelişmeli. Değişiklikleri takip edin, yeni edge case'ler ekleyin, eski test senaryolarını emekliye ayırın.
8. Maliyeti görmezden gelmek — Her üretim isteğinde LLM-as-judge çalıştırmak hızla pahalılaşır. Akıllıca örnekleyin — trafiğin %1-5'i izleme için yeterli.

Techsy, LLM Değerlendirmesine Nasıl Yaklaşıyor

Chatbot'lar, RAG sistemleri ve yapay zeka ajanları üzerinden LLM özellikleri sunan startup ekipleri için değerlendirme pipeline'ları inşa ettik. Tipik çalışmamız bir düzeni izler:

1. Denetim — Mevcut LLM çıktılarınızı gözden geçirir, hata modlarını tanımlar ve olgunluk modelindeki konumunuzu haritalandırırız
2. Metrik seçimi — Uygulama türünüze göre gerçekten önemli olan 3-5 metriği tanımlarız (bu rehberdeki çerçeveyi kullanarak)
3. Altın veri seti oluşturma — Çoğu ekibin kaçırdığı adversarial edge case'ler dahil, başlangıç değerlendirme veri setinizi oluştururuz
4. Pipeline kurulumu — Otomatik puanlama ve deployment gate'leriyle CI/CD entegrasyonu
5. Devir teslim — Ekibiniz belgeleme ve runbook'larla ileriye sahip olur

Çoğu ekibin bunun için harici bir ortağa ihtiyacı yok — bir ML mühendisi ve bir hafta adanmış süreniz varsa, bu rehber ihtiyacınız olan her şeyi sunuyor. Ama zaman sıkıntısı çekiyorsanız, bir uyumluluk son tarihiyle karşı karşıyaysanız ya da değerlendirme stratejiniz hakkında deneyimli bir ikinci görüş istiyorsanız, yardımcı olmaktan memnuniyet duyarız.

LLM uygulamanız için değerlendirme pipeline'ı kurmak konusunda yardıma mı ihtiyacınız var? Ücretsiz danışmanlık alın

SSS

LLM performansı nasıl değerlendirilir?

Başarı kriterlerinizi tanımlayarak başlayın — doğruluk, güvenlik, alaka ya da kullanım senaryonuz için önemli olan her şey. Uygulama türünüze uyan 3-5 metrik seçin (yukarıdaki metrik-uygulama tablosuna bakın), en az 50 test senaryosuyla altın veri seti oluşturun ve DeepEval veya Ragas gibi çerçeveler kullanarak otomatik değerlendirmeler çalıştırın. Onlara güvenmeden önce bir örneklem üzerinde otomatik puanlarınızı insan yargısına karşı doğrulayın.

LLM'leri değerlendirmek için hangi metrikler kullanılır?

Temel metrikler şunları içerir: RAG sistemleri için faithfulness, answer relevancy ve halüsinasyon oranı; çeviri ve özetleme için BLEU ve ROUGE; güvenlik için toksisite ve önyargı; ve ajanlar için görev tamamlama oranı. Doğru metrikler uygulama türünüze bağlıdır — chatbot, kod oluşturucudan farklı bir değerlendirme gerektirir.

LLM-as-a-judge nedir?

Ayrı bir LLM'nin (genellikle GPT-4o veya Claude) başka bir LLM'nin çıktısını tanımladığınız ölçütlere göre değerlendirdiği bir yöntemdir. G-Eval, zincir düşünce puanlaması kullanan en popüler uygulamadır. Araştırmalar, insan derecelendirmeleriyle yaklaşık %81 korelasyon gösteriyor; bu da onu 2026'da günlük değerlendirme için pratik standart yapıyor.

LLM'lerde halüsinasyonlar nasıl tespit edilir?

Oluşturulan metni kaynak belgelerle karşılaştıran faithfulness metrikleri kullanın. Hem DeepEval hem de Ragas, çıktıdaki her iddianın sağlanan bağlamda dayandırılıp dayandırılmadığını kontrol eden yerleşik halüsinasyon tespiti sunar. Üretim sistemleri için otomatik tespiti, işaretlenen çıktılarda insan spot kontrolleriyle birleştirin.

En iyi LLM değerlendirme çerçevesi hangisidir?

Tek bir en iyi yoktur. Özel metrikler ve kapsamlı değerlendirme için DeepEval, RAG'a özgü değerlendirme için Ragas, CI/CD entegrasyonu ve deployment engelleme için Braintrust, halihazırda LangChain kullanan ekipler için LangSmith, kendi barındırdığınız gözlemlenebilirlik için Langfuse. İş akışınıza uyanı seçin.

RAG sistemi nasıl değerlendirilir?

Dört metrik ölçün: faithfulness (yanıt bağlama dayandırılmış mı?), context relevancy (doğru belgeler getirildi mi?), context recall (tüm ilgili belgeler bulundu mu?) ve answer relevancy (sorguyu ele alıyor mu?). Ragas ve DeepEval standart araçlardır. Kritik olarak, hem retriever hem de üreticiyi değerlendirin — çoğu ekip yalnızca üreticiyi test eder ve retrieval hatalarını kaçırır.

G-Eval nedir?

G-Eval, çıktıları özel kriterlere göre değerlendirmek için zincir düşünce prompting kullanan bir LLM-as-judge çerçevesidir. "İyi"nin nasıl göründüğünü sade bir Türkçeyle tanımlarsınız, yargıç LLM her çıktıyı değerlendirir ve bir puan atar. Liu ve diğ.'nin orijinal makalesi, birden fazla NLG görevi genelinde insan değerlendirmesiyle güçlü uyum gösterdi.

AB Yapay Zeka Yasası, LLM değerlendirmesini nasıl etkiliyor?

AB Yapay Zeka Yasası, AB kullanıcılarına hizmet veren yapay zeka sistemleri için sistematik değerlendirme, dokümantasyon ve izleme gerektiriyor. Yüksek riskli sistemler, resmi değerlendirme pratikleri aracılığıyla doğruluk, sağlamlık, şeffaflık ve ayrımcılık yapmamayı kanıtlamalıdır. Sınırlı riskli sistemlerin bile şeffaflık yükümlülükleri var. Uygulama Ağustos 2026'da başlıyor; gereksinimler nerede bulunduğunuzdan bağımsız olarak AB kullanıcılarına hizmet veren her şirkete uygulanıyor.

Yapay zeka ajanları nasıl değerlendirilir?

Görev tamamlama oranını, araç kullanım doğruluğunu, adımlar genelinde bağlam tutmayı ve başarılı görev başı maliyeti takip edin. Ajan değerlendirmesi istatistiksel yaklaşımlar gerektirir — aynı görevi birden fazla kez çalıştırın ve tek geçti/kaldı sonuçları değil, tamamlama oranları raporlayın. Araç desteği hâlâ erken aşamada, ancak DeepEval ve AWS her ikisi de gelişmekte olan ajan değerlendirme çerçeveleri sunuyor.

Kıyaslama kirlenmesi nedir?

LLM eğitim verilerinin kıyaslama test sorularını içermesi, gerçek kapasiteyi yansıtmadan puanları yapay olarak şişirir. Bu yüzden MMLU gibi genel kıyaslamalar tek değerlendirme yönteminiz olmamalıdır. Modeller, gerçek dünya görevlerinde kötü performans gösterirken kirlenmiş kıyaslamalarda etkileyici puanlar alabilir. Kıyaslamaları her zaman kendi verilerinizde uygulamaya özgü değerlendirmeyle tamamlayın.

LLM değerlendirmesi ne kadar maliyet getirir?

DeepEval ve Ragas gibi açık kaynak araçlar ücretsizdir. LLM-as-a-judge, yargıç modeline bağlı olarak değerlendirme başına yaklaşık 0,01-0,05 $ maliyetindedir. Braintrust ve LangSmith gibi ticari platformların küçük ekipler için ücretsiz katmanları ve üretim kullanımı için ücretli planları var. İnsan değerlendirmesi değerlendirme başına 5-50 $ maliyetindedir. Çoğu ekip, 100 $/ay'ın altında sağlam bir değerlendirme pipeline'ı çalıştırabilir.

Kaynaklar

• DeepEval Dokümantasyon – Metrikler
• Ragas Dokümantasyon – Metrikler
• Braintrust Dokümantasyon – Değerlendirmeler
• LangSmith Dokümantasyon – Değerlendirme
• Langfuse Dokümantasyon – Puanlar ve Değerlendirme
• Arize Phoenix Dokümantasyon
• AB Yapay Zeka Yasası – Tam Metin (Yönetmelik 2024/1689)
• AB Yapay Zeka Yasası – Risk Sınıflandırması (Avrupa Komisyonu)
• Judging LLM-as-a-Judge – Zheng ve diğ., 2023
• G-Eval: NLG Evaluation using GPT-4 – Liu ve diğ., 2023
• How to Build an LLM Evaluation Framework – The Pragmatic Engineer