Ana içeriğe atla

Yargıç Olarak LLM: Uygulamalı RAG Örneğiyle Eksiksiz Rehber

RAG hatlarınızı ölçekli olarak bağlam sadakati ve alaka düzeyi açısından değerlendirmek ve yapay zekâ testlerindeki boşluğu kapatmak için otomatik bir yargıç olarak LLM sistemi kurmayı öğrenin.
Güncel 20 Nis 2026  · 15 dk. oku

RAG hattınız bir kullanıcının sorusuna yanıt döndürüyor. Mantıklı görünüyor, akıcı okunuyor ve özgüvenli bir tona sahip. Ancak gerçekten getirilen belgelere kıyasladığınızda, bağlamda hiç geçmeyen bir tarih ya da kaynağın söyledikleriyle çelişen bir öneri gibi şeyler fark etmeye başlıyorsunuz.

Bu sorunları ölçekli olarak yakalamak işin karmaşıklaştığı yer. Tam da bu yüzden BLEU ve ROUGE gibi metrikler makine çevirisi ve özetleme görevleri için geliştirildi; ancak bunlar, modelin yanıtının gerçekten getirilen bağlama dayanıp dayanmadığını ya da kaynakla çelişip çelişmediğini söyleyemez.

İnsan değerlendirmesi bu incelikleri yakalar, fakat ölçekte (10.000+ sorgu düşünün) çok pahalıdır. Yani bir boşluk var: Otomatik metrikler hızlı ama yüzeysel; insan incelemesi ise kapsamlı ama pahalı ve yavaştır. 

Bir LLM’i yargıç olarak kullanmak bu ikisinin arasına oturur. Yetenekli bir modeli alır, sizin yazdığınız bir rubriği verirsiniz ve sisteminizin çıktıları insan bir değerlendiricinin yapacağı şekilde incelemesini istersiniz. Mükemmel bir çözüm değildir (başarısızlık biçimlerine birazdan değineceğim), ancak ne geleneksel metriklerin ne de manuel etiketlemenin tek başına erişebileceği ölçekte kaliteyi pratik biçimde izlemenizi sağlar.

Bu eğitimde, baştan sona çalışan kodlarla bir RAG sistemini değerlendirmek üzere bir LLM yargıcı inşa etmenizi adım adım göstereceğim; böylece her şeyi kendi makinenizde yeniden üretebilirsiniz.

Yargıç Olarak LLM Nedir?

LLM-as-a-judge’ın temel fikri, bir dil modelinden, açtığınız bir istemde belirttiğiniz ölçütlere göre metin çıktıları değerlendirmesini istemektir. Yani esasen, başka bir modelin ürettiği içeriğin iyi olup olmadığını kontrol etmek için bir LLM kullanırsınız. 

Bunun neden işe yaradığını (ilk başta ben de şüpheyle yaklaşıyordum) açıklayan şey, değerlendirmenin üretime kıyasla temelde daha kolay bir görev olmasıdır. Bir model sıfırdan yanıt ürettiğinde aynı anda pek çok çelişen kısıtı dengede tutar: 

  • Doğruluk
  • Ton
  • Talimatlara uyum
  • Bağlama bağlı kalma
  • Belirsiz bilgiye aşırı güvenmeme

Ancak aynı modele bitmiş bir yanıtı verip belirli özellikleri kontrol etmesini istediğinizde, görev çok daha odaklı hâle gelir; çünkü yaratmak değil, yalnızca değerlendirmek gerekir. Ve modeller bu daha dar görevde genellikle daha tutarlı performans sergiler.

LLM-as-a-judge yaklaşımlarını karşılaştırma

Pratikte, ekipler ölçmek istediklerine bağlı olarak genellikle şu yaklaşımlardan birine yönelir:

  1. Doğrudan puanlama, yargıcın tek bir çıktıyı sayısal bir ölçekte (1’den 5’e, 1’den 10’a, rubriğiniz ne tanımlıyorsa) puanlamasını ister. Bir sayı ve (istediyseniz) gerekçenin yazılı bir açıklamasını alırsınız. En yaygın başlangıç noktası budur; ancak kalibrasyon sorunu vardır, buna tekrar döneceğim.
  2. Çiftli karşılaştırma, iki aday yanıtı yan yana koyar ve yargıçtan daha iyisini seçmesini ister. Bu, sayısal kalibrasyon sorununu tamamen aşar; çünkü yargıç mutlak bir sayı atamak yerine yalnızca göreli bir seçim yapar. Ekipler genellikle istem varyantlarını ya da model sürümlerini birbirine karşı kıyaslarken buna başvurur.
  3. Referans tabanlı değerlendirme, yargıca hem model çıktısını hem de altın standart bir yanıtı sağlar ve çıktının ne kadar iyi eşleştiğini sorar. Bu, elinizde karşılaştıracak etiketli gerçekler olduğu olgusal Soru-Cevap ve yapılandırılmış çıktılarda en iyi sonucu verir.
  4. İkili sınıflandırma, yargıyı tek bir özellikte geçti/kaldı düzeyine indirger. Bu yanıt bağlama sadık mı? Kişisel olarak tanımlanabilir bilgi içeriyor mu? Olumlu mu? Bu ikili kontroller daha hızlı çalışır, değerlendirme başına daha ucuzdur ve sayısal yaklaşımlara göre daha tutarlı sonuçlar üretme eğilimindedir.

Diyagram formatında açıklanan yargıç olarak LLM’in dört farklı yaklaşımı.

Görsel: Yazar. Yargıç olarak LLM’in dört farklı yaklaşımı. 

Güçlü yönler, kullanım alanları ve kısıtların doğrudan bir görünümü için, aşağıdaki tabloda dört yaklaşımı da karşılaştırdım:

Yaklaşım

Ne Zaman Kullanılır

Güçlü Yönler

Dikkat Edilecekler

Doğrudan puanlama

Genel kalite izleme, sürekli takip

Zaman içinde eğilim çıkarması kolay, tekli çıktılarla çalışır

Yargıçların puan kalibrasyonu zamanla kayar

Çiftli karşılaştırma

A/B model testleri, istem varyantı karşılaştırması

Mutlak puanlardan daha güvenilir sıralamalar

API çağrılarını ikiye katlar, mutlak kalite sinyali vermez

Referans tabanlı

Olgusal S&C, yapılandırılmış çıktılar

Açık yerleşik gerçekler değerlendirmeyi sadeleştirir

Etiketli veri gerektirir, geçerli alternatif ifadeleri cezalandırabilir

İkili sınıflandırma

Güvenlik kontrolleri, halüsinasyon tespiti, uyumluluk

Düşük belirsizlik, uyarıları otomatikleştirmek kolay

Sınır durumlarında nüans kaybı

Yargıç deseninin ötesindeki değerlendirme yaklaşımlarına daha geniş bir bakış için, LLM Kıyasları Açıklaması genel resmi kapsar.

Bir LLM Yargıcı Nasıl Çalışır?

Perde arkasında bu, basit bir API çağrısıdır; değerlendirilecek içeriği (modelin çıktısı, özgün kullanıcı sorgusu ve üretim sırasında kullanılan getirilen bağlam) paketleyip, yargıç modele neye önem verdiğinizi ve sonuçların nasıl biçimlendirilmesini istediğinizi anlatan bir isteme sararsınız. 

Yargıç bunu işler ve genellikle puan ile buna neden o puanı verdiğini açıklayan yazılı bir gerekçe içeren yapılandırılmış bir yanıt döndürür. Değerlendirmenin kalitesi neredeyse tamamen rubriği ne kadar iyi yazdığınıza bağlıdır. Bunu yeterince vurgulayamam. 

Şöyle diyen basit bir istem "bu yanıtı 1’den 5’e puanla" yargıcın 3’ün 4’ten ne anlama geldiğine dair ortak bir anlayışı olmadığından, her yöne savrulan puanlar üretir. Bu nedenle her bir puan düzeyinin somut olarak nasıl göründüğünü açıkça belirtmeniz ve mümkünse örnekler eklemeniz gerekir.

Yargıç Olarak LLM’i Uygulamak

Şimdi uygulamalı kısma geçelim; baştan sona eksiksiz bir değerlendirme hattı kuracağız: küçük bir bilgi tabanından soruları yanıtlayan bir retrieval augmented generation (RAG) sistemi, farklı başarısızlık biçimlerini tetiklemek üzere tasarlanmış bir test sorgu seti ve çıktıları bağlam sadakati ile yanıt alaka düzeyi açısından puanlayan bir LLM yargıcı.

Ortamı hazırlama

Python 3.9+ ve bir OpenAI API anahtarına ihtiyacınız olacak; bunu OpenAI konsolundan alabilirsiniz. Bağımlılıkları kurun:

pip install openai chromadb langchain langchain-openai langchain-community deepeval

API anahtarınızı ayarlayın:

import os
os.environ["OPENAI_API_KEY"] = "your-key-here"

Hem RAG üreticisi hem de LLM yargıcı için OpenAI kullanıyoruz; ancak farklı modeller olacaklar (üretim için GPT-4o-mini, yargılama için GPT-4o). Gömlemeler için, text-embedding-3-small bu eğitim kapsamı için iş görür. Üretimde, birine karar vermeden önce belirli alan verileriniz üzerinde birkaç gömme modelini kıyaslamak istersiniz.

Değerlendirme koduna dalmadan önce RAG hakkında daha fazla arka plan oluşturmak isterseniz, LangChain ile Retrieval Augmented Generation (RAG) kursumuz temel kavramları adım adım anlatır.

Veri ve vektör deposunu hazırlama

RAG sisteminin getireceği küçük bir bilgi tabanına ihtiyacımız var. Kurgusal bir şirketin iade politikası hakkında bir dizi metin parçası kullanacağım. İçeriğin kendisi odak noktası değil; ancak sınırlı bir belge kümesine sahip olmak, modelin sağlanan bağlamın ötesine ne zaman geçtiğini tam olarak görmeyi kolaylaştırır (yargıcın yakalamasını istediğimiz başarısızlık biçimi budur).

from langchain_openai import OpenAIEmbeddings
from langchain_chroma import Chroma
from langchain.schema import Document

# Sample knowledge base
documents = [
    Document(
        page_content="All customers are eligible for a full refund within 30 days of purchase. "
        "The item must be in its original packaging and unused condition. Refunds are "
        "processed to the original payment method within 5-7 business days.",
        metadata={"source": "return_policy.pdf", "section": "refund_eligibility"}
    ),
    Document(
        page_content="Exchanges can be requested within 45 days of purchase for items of "
        "equal or lesser value. Size exchanges on clothing are free of charge. "
        "For items of greater value, the customer pays the difference.",
        metadata={"source": "return_policy.pdf", "section": "exchanges"}
    ),
    Document(
        page_content="Electronics have a 15-day return window due to rapid depreciation. "
        "Opened software and digital downloads are non-refundable. Defective electronics "
        "can be returned within 90 days with proof of defect from an authorized service center.",
        metadata={"source": "return_policy.pdf", "section": "electronics"}
    ),
    Document(
        page_content="Shipping costs for returns are covered by the company for defective items. "
        "For non-defective returns, the customer is responsible for return shipping. "
        "Free return shipping labels are available for loyalty program members regardless of reason.",
        metadata={"source": "return_policy.pdf", "section": "shipping"}
    ),
    Document(
        page_content="Gift purchases can be returned with the gift receipt for store credit only. "
        "Without a gift receipt, returns are processed at the lowest sale price in the last 90 days. "
        "Gift cards and prepaid cards are non-refundable and cannot be exchanged.",
        metadata={"source": "return_policy.pdf", "section": "gifts"}
    ),
]

# Create vector store
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(documents, embeddings, persist_directory="./chroma_db")

print(f"Indexed {len(documents)} documents")

İade politikaları hakkında beş belge; çok değil ama üzerinde durduğumuz getirme sorunlarını göstermek için yeterli: eksik bağlam, alakasız parçaların çekilmesi ve model bağlam tam olarak desteklemese de tam bir yanıt verme baskısı hissettiğinde ortaya çıkan halüsinasyon fırsatları.

Temel bir RAG hattı kurma

RAG hattı ilgili parçaları getirir ve bir yanıt üretir. Burada süslü bir şey yok, sadece standart getir-sonra-üret deseni.

from openai import OpenAI

client = OpenAI()

def rag_query(question: str, top_k: int = 2) -> dict:
    """Run a RAG query: retrieve context, generate answer."""
    
    # Retrieve
    results = vectorstore.similarity_search(question, k=top_k)
    context = "\n\n".join([doc.page_content for doc in results])
    
    # Generate
    system_prompt = """You are a helpful customer support assistant. Answer the 
    customer's question based ONLY on the provided context. If the context doesn't 
    contain enough information to answer fully, say so."""
    
    user_prompt = f"""
      Context: {context}

      Question: {question}

      Answer:
    """
    
    response = client.chat.completions.create(
        model="gpt-4o-mini",
        messages=[
            {"role": "system", "content": system_prompt},
            {"role": "user", "content": user_prompt}
        ],
        temperature=0.3
    )
    
    answer = response.choices[0].message.content
    
    return {
        "question": question,
        "context": context,
        "answer": answer,
        "sources": [doc.metadata for doc in results]
    }

Üretici olarak GPT-4o-mini’yi seçtim; çünkü ucuz ve hızlı ve odak noktamız değerlendirme olsun istiyoruz. Sıcaklık 0,3’te; bu, rastgeleliği azaltır ama tamamen ortadan kaldırmaz. 

Ve sistem istemi, modelin yalnızca sağlanan bağlamı kullanmasını açıkça söyler; bu, RAG sistemlerinde standart bir uygulamadır; ancak yine de modeller beklediğinizden daha sık bağlamın dışına taşar. Tam da yargıcın işaretlemesini istediğimiz şey bu.

Hadi deneyelim:

result = rag_query("Can I return opened software?")
print(f"Question: {result['question']}")
print(f"Answer: {result['answer']}")
print(f"Sources: {result['sources']}")

Bir değerlendirme veri seti oluşturma

Hattın farklı bölümlerini çalıştıracak test vakalarına ihtiyacınız var. Üretimde, bunları gerçek kullanıcı sorgularından toplarsınız. Bu eğitim için, RAG sistemlerinin tökezlemeye meyilli olduğu soru türlerini bilerek içeren bir karışım oluşturuyorum.

eval_questions = [
    # Straightforward questions (should be easy)
    "What is the refund window for regular purchases?",
    "Are exchanges free for clothing size changes?",
    
    # Questions requiring synthesis across chunks
    "What are my options if I received a defective laptop 60 days ago?",
    
    # Edge cases likely to cause hallucination
    "Can I get a refund for a digital download I purchased yesterday?",
    "What happens if I return a gift without the gift receipt?",
    
    # Questions where context might be incomplete
    "Do you offer refunds for international orders?",
    "Can I return an item I bought on sale?",
    
    # Adversarial or tricky questions
    "If I'm a loyalty member, do I get free return shipping even for electronics?",
]

# Generate RAG responses for all questions
eval_results = []
for q in eval_questions:
    result = rag_query(q)
    eval_results.append(result)
    print(f"Q: {q}")
    print(f"A: {result['answer'][:150]}...")
    print()

Karışım önemlidir. Bu soruların bazıları belgelerde net, doğrudan yanıtlara sahiptir; bazıları ise birden fazla getirilen parça arasındaki bilgileri birleştirmeyi gerektirir (kusurlu dizüstü bilgisayar sorusu hem genel 30 günlük iade politikasını hem de 90 günlük elektronik kusur penceresini gerektirir). 

Ve uluslararası siparişler sorusu gibi birkaç tanesi, bilgi tabanının basitçe kapsamadığı konuları sorar. Sonuncular, modelin yardımcı olma dürtüsüyle gerçek bağlamda temeli olmayan ama makul görünen bilgilerle boşlukları doldurması nedeniyle, halüsinasyonun en sık görüldüğü yerlerdir.

RAG sistemleri kurma ve test etme hakkında daha fazla bilgi için, En İyi 30 RAG Mülakat Sorusu ve Yanıtı seçkimiz yararlı bir başvuru kaynağıdır.

LLM yargıcını kurma

İşlerin ilginçleştiği yer burası. İki ayrı yargıç inşa ediyoruz: 

  • Bağlama sadakat yargıcı: Yanıt, getirilen bağlamın sınırları içinde mi kalıyor?
  • Alaka düzeyi yargıcı: Yanıt gerçekten sorulanı mı ele alıyor?
def judge_faithfulness(question: str, context: str, answer: str) -> dict:
    """Judge whether the answer is faithful to the retrieved context."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's 
      answer is faithful to the provided context. 

      Faithfulness means every claim in the answer can be traced back to 
      information in the context. The answer should not contain information 
      that isn't supported by or inferable from the context.

      Score on a scale of 1 to 5:
      1 - The answer contains multiple claims not supported by the context
      2 - The answer contains at least one significant unsupported claim
      3 - The answer is mostly faithful but includes minor unsupported details
      4 - The answer is faithful with only trivial extrapolations
      5 - Every claim in the answer is directly supported by the context

      Context: {context}

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)


def judge_relevance(question: str, answer: str) -> dict:
    """Judge whether the answer is relevant to the question."""
    
    eval_prompt = f"""
      You are an impartial judge evaluating whether an AI assistant's answer 
      is relevant to the user's question.

      Relevance means the answer directly addresses what the user asked. 
      A relevant answer may acknowledge limitations in available information, 
      but it should not go off-topic or provide unrelated information.

      Score on a scale of 1 to 5:
      1 - The answer does not address the question at all
      2 - The answer partially addresses the question but misses the main point
      3 - The answer addresses the question but includes significant irrelevant content
      4 - The answer addresses the question well with minor tangents
      5 - The answer directly and completely addresses the question

      Question: {question}

      Answer to evaluate: {answer}

      Respond in this exact JSON format: {{"score": <int 1-5>, "reason": "<one paragraph explanation>"}}
    """

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=[{"role": "user", "content": eval_prompt}],
        temperature=0.0,
        response_format={"type": "json_object"}
    )
    
    import json
    return json.loads(response.choices[0].message.content)

Burada birkaç tasarım seçimi dikkat çekiyor. temperature 0.0’da; bu da çalıştırmalar arası en yüksek tutarlılığı sağlar. response_format={"type": "json_object"} kullanıyoruz; böylece çıktı her zaman ayrıştırılabilir.

Rubrik, "iyi" ya da "kötü" gibi muğlak etiketler yerine her puan düzeyini somut biçimde tanımlar. Bu netlik düzeyi olmadan, yargıçların her şeye 3 ya da 4 verme eğiliminde olduğunu gördüm; bu da size faydalı hiçbir şey söylemez.

GPT-4o-mini üretimi yaparken GPT-4o’nun yargılama yaptığını fark edin. Yargıcın üreticiden daha yetenekli olması yaygın bir desendir; çünkü yargıcın rubriği tutarlı biçimde uygulamak için güçlü talimat takibine ihtiyacı vardır. 

Aynı modeli her iki rol için kullanırsanız, modelin kendi çıktısını daha olumlu değerlendirdiği belgelenmiş bir öz-tercih yanlılığını da devreye sokarsınız.

Değerlendirme döngüsünü çalıştırma

Her şeyi çalıştırma ve sonuçları toplama zamanı.

import json

evaluation_report = []

for result in eval_results:
    # Run both judges
    faithfulness = judge_faithfulness(
        result["question"], result["context"], result["answer"]
    )
    relevance = judge_relevance(
        result["question"], result["answer"]
    )
    
    evaluation_report.append({
        "question": result["question"],
        "answer": result["answer"][:200],
        "faithfulness_score": faithfulness["score"],
        "faithfulness_reason": faithfulness["reason"],
        "relevance_score": relevance["score"],
        "relevance_reason": relevance["reason"],
    })
    
    print(f"Q: {result['question']}")
    print(f"  Faithfulness: {faithfulness['score']}/5 | Relevance: {relevance['score']}/5")
    print(f"  Faith reason: {faithfulness['reason'][:100]}...")
    print()

# Summary statistics
faith_scores = [r["faithfulness_score"] for r in evaluation_report]
rel_scores = [r["relevance_score"] for r in evaluation_report]
print(f"Average faithfulness: {sum(faith_scores)/len(faith_scores):.2f}")
print(f"Average relevance: {sum(rel_scores)/len(rel_scores):.2f}")
print(f"Questions with faithfulness < 3: {sum(1 for s in faith_scores if s < 3)}")

Her soru, yargıç başına bir olmak üzere GPT-4o’ya iki API çağrısı tetikler. Sekiz test sorumuz için bu toplamda on altı değerlendirme çağrısı eder; yönetilebilir bir sayı. Üretimde, günde binlerce sorguyla, bunları gruplamak, eşzamanlı çalıştırmak ve muhtemelen her yanıtı değil yalnızca bir örneklemi değerlendirmek istersiniz.

Sonuçları analiz etme ve yineleme

Sayısal puanlar size bir genel görünüm verir; ancak neyi gerçekten düzeltmeniz gerektiğini söyleyen gerekçelerdir.

# Find problematic responses
print("=== LOW FAITHFULNESS (score < 4) ===")
for r in evaluation_report:
    if r["faithfulness_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['faithfulness_score']}")
        print(f"Reason: {r['faithfulness_reason']}")
        print(f"Answer preview: {r['answer'][:150]}...")

print("\n=== LOW RELEVANCE (score < 4) ===")
for r in evaluation_report:
    if r["relevance_score"] < 4:
        print(f"\nQ: {r['question']}")
        print(f"Score: {r['relevance_score']}")
        print(f"Reason: {r['relevance_reason']}")

Uluslararası siparişler sorusu ve indirimli ürünler sorusu büyük olasılıkla bağlam sadakati açısından düşük puan alacaktır; çünkü bilgi tabanı bu konuları ele almıyor ve model muhtemelen bir yanıt uydurmuştur. 

Kusurlu dizüstü bilgisayar sorusu da ilginçtir; çünkü genel iade politikası (30 gün) ile elektronik kusur maddesinden (kusuru kanıtlayan belgeyle 90 gün) bilgileri sentezlemeyi gerektirir ve getirilen parçaların hangileri olduğuna bağlı olarak model resmin tamamına sahip olabilir ya da olmayabilir.

Sonuçlarla ne yapacağınız, ne keşfettiğinize bağlıdır. Belirli soru kategorilerinde düşük bağlam sadakati genellikle iki şeyden birine işaret eder: ya getirici yanlış parçaları çekiyordur (getirme sorunu) ya da üretici kendisine verilen bağlamın ötesine geçiyordur (üretim sorunu). 

Yanıtla birlikte getirilen bağlama bakmak, hangisiyle uğraştığınızı söyler. Öte yandan düşük alaka puanları genellikle sistem isteminin ayar gerektirdiği ya da getirilen bağlamın konu dışı kaldığı ve modelin işe yarar bir şeyle çalışacak materyale sahip olmadığı anlamına gelir.

Değerlendirmeleri devreye alma hattınızın bir parçası olarak çalıştırmanın operasyonel tarafı için, LLMOps Kavramları kursu altyapı ve iş akışı desenlerini kapsar.

Yapılandırılmış değerlendirme için DeepEval kullanma

Özel yargıç işlevleri yazmak işe yarar; ancak üretim kullanımı için genellikle rutin işleri üstlenen bir çerçeve istersiniz. DeepEval bunlardan daha olgun seçeneklerden biridir ve en yaygın değerlendirme ölçütlerini kapsayan, iyi test edilmiş metrik uygulamalarıyla gelir.

from deepeval import evaluate
from deepeval.test_case import LLMTestCase
from deepeval.metrics import FaithfulnessMetric, AnswerRelevancyMetric

# Configure metrics
faithfulness_metric = FaithfulnessMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

relevance_metric = AnswerRelevancyMetric(
    threshold=0.7,
    model="gpt-4o",
    include_reason=True
)

# Create test cases from our RAG results
test_cases = []
for result in eval_results:
    test_case = LLMTestCase(
        input=result["question"],
        actual_output=result["answer"],
        retrieval_context=[result["context"]]
    )
    test_cases.append(test_case)

# Run evaluation
evaluate(
    test_cases=test_cases,
    metrics=[faithfulness_metric, relevance_metric]
)

DeepEval’in kendi başınıza inşa etmesi zahmetli olan neleri sağladığı: 

  • Yargıcın geçersiz JSON döndürdüğü (sandığınızdan daha sık olur) durumlar için yeniden deneme mantığı
  • Bir değerlendirmeyi yeniden çalıştırmanın API faturanızın ikiye katlanmaması için sonuç önbellekleme
  • Pytest entegrasyonu; böylece LLM değerlendirmelerini doğrudan CI/CD hattınıza bağlayabilirsiniz. 

Her metrik ayrıca bir öz-açıklama üretir; bu da her puanın, bir şeyler tuhaf göründüğünde inceleyebileceğiniz yargıcın gerekçesinin yazılı bir dökümüyle birlikte gelmesi demektir.

DeepEval’in tüm yeteneklerine daha derin bir bakış için DeepEval Kullanarak LLM’leri Etkili Biçimde Değerlendirin sayfasına bakın.

Yargıç Olarak LLM En İyi Uygulamaları

Bir LLM yargıcından sayı döndürmesini sağlamak basittir. Bu sayıların ekibiniz için gerçekten anlam ifade etmesini sağlamak ise çoğu kişinin başta beklediğinden daha fazla özen gerektirir.

Değerlendirme çerçeveleri ve metrikler

DeepEval’in yanı sıra bugün seçebileceğiniz birkaç çerçeve daha var ve manzara büyümeye devam ediyor. İşte her birinin en iyi uyduğu yerlere dayalı pratik bir karşılaştırma:

Çerçeve

En Uygun Olduğu

LLM Yargıç Desteği

RAG’e Özgü Metrikler

Entegrasyon

DeepEval

Tam değerlendirme paketi, CI/CD entegrasyonu

Evet, öz-açıklamalı puanlarla

Bağlam sadakati, bağlamsal kesinlik/duyarlılık, alaka

pytest, LangChain

RAGAS

Özel olarak RAG hattı değerlendirmesi

Evet

Bağlam sadakati, yanıt alaka düzeyi, bağlam kesinliği, bağlam duyarlılığı

LangChain, LlamaIndex

MLflow

Değerlendirmeli deney takibi

Evet (yerleşik; DeepEval/RAGAS ile de birleştirilebilir)

Üçüncü taraf entegrasyonlar üzerinden

MLflow ekosistemi

Evidently

Üretim izleme ve kayma tespiti

Evet, sürekli takip ile

Özel değerlendiriciler aracılığıyla

İzleme panoları

LangSmith

LangChain-yerel izleme ve değerlendirme

Evet

Özel değerlendiriciler aracılığıyla

LangChain

RAG sistemleri için, pratikte ihtiyaçlarınızın çoğunu dört metrik karşılar.

  1. Bağlam sadakati, üretilen yanıtın getirilen bağlama bağlı kalıp kalmadığını söyler. Puan 0,6 geliyorsa, yanıttaki iddiaların yaklaşık %40’ının sağlanan belgeler tarafından desteklenmediği anlamına gelir. Bu, birincil halüsinasyon dedektörünüzdür ve deneyimime göre, sürekli izlenmesi gereken en önemli metriktir.
  2. Yanıt alaka düzeyi, yanıtın gerçekten sorulanı ele alıp almadığını yakalar; bu tamamen farklı bir meseledir. Bir yanıt, bağlama tamamen sadık olabilir (her iddia doğrulanır) ve yine de sorunun özünü tamamen kaçırabilir.
  3. Bağlam kesinliği getirme tarafına bakar: ilgili belgeler sonuçların en üst sıralarında mı yer alıyor? Yanıtı içeren belge 5 üzerinden 5. sırada getiriliyorsa, getirmeniz teknik olarak çalışıyordur; ancak sıralama zayıftır ve bu, modeller bağlam penceresinde önce görünenlere daha çok dikkat ettiği için üretim kalitesini etkiler.
  4. Bağlam duyarlılığı ise diğer yöne gider ve soruyu yanıtlamak için gereken bilginin ne kadarının gerçekten getirildiğini kontrol eder. Düşük duyarlılık bir getirme altyapısı sorunudur ve üretim tarafında ne kadar istem mühendisliği yaparsanız yapın, basitçe orada olmayan bağlamın yerini tutamaz.

Bunları birlikte çalıştırmak istersiniz; çünkü yüksek ve düşük puanların farklı kombinasyonları farklı kök nedenlere işaret eder.

  • Yüksek bağlam sadakati ile düşük alaka, modelin bağlamı doğru yansıttığını ancak bağlamın soruyla ilgili olmadığını gösterir. 
  • Düşük bağlam sadakati ile yüksek alaka, modelin soruyu anladığını ancak yanıtlamak için sağlanan bağlamın ötesine geçtiğini gösterir. 

Her kombinasyon, çözümü nerede aramanız gerektiğini söyler.

MLflow’da değerlendirme takibini uygulamalı olarak görmek için, MLflow ile LLM’leri Değerlendirme entegrasyonu adım adım anlatır.

Üretim ortamına alma en iyi uygulamaları

Üretim ortamına alma, not defterinde değerlendirme çalıştırmaktan daha fazla düşünce gerektirir ve ölçekte ortaya çıkan pratik sorunlar yaklaşımı benimsemeden önce ele alınmaya değer beş başlıkta toplanır.

  1. Bilinen önyargılara göre plan yapın. LLM yargıçlar düzenli olarak daha uzun yanıtlara daha yüksek puan verir (laf kalabalığı önyargısı) ve çiftli karşılaştırmalarda ilk görünen yanıta hafif bir eğilim gösterir (pozisyon önyargısı). Pozisyon önyargısı için standart azaltım, her çift karşılaştırmayı her iki sırayla da çalıştırmak ve yalnızca yargıç her ikisinde de tutarlı olduğunda sonucu saymaktır. Laf kalabalığı için, rubriğinize özlülüğün kabul edilebilir hatta tercih edilir olduğunu belirten açık ifadeler ekleyebilirsiniz; ancak bu, etkiyi azaltır, bütünüyle ortadan kaldırmaz.
  2. Puanlara güvenmeden önce insan yargısına göre kalibre edin. Alanınıza özgü, insan değerlendiricilerin zaten puanladığı 50 ila 100 örnek toplayın, bunları yargıçtan geçirin ve uyum oranını kontrol edin; %75’in altındaki bir uyum, rubriğin ölçüt tanımlarında daha fazla çalışmaya ihtiyaç olduğunu gösterir. Bunu periyodik olarak tekrarlamayı unutmayın; çünkü hem yargıç modeli hem de uygulamanız zamanla evrilir; bu da altı ay önce sağlam görünen bir uyum oranının, istemleriniz, verileriniz veya model sürümleriniz değiştikçe kaymış olabileceği anlamına gelir.
  3. Tutarlılığı doğruluktan ayrı kontrol edin. Aynı girdileri yargıçtan iki kez geçirip çıktıları karşılaştırın; çünkü bir yanıt bir çalıştırmada 3, diğerinde 5 alıyorsa, rubriğiniz yorumlamaya fazla alan bırakıyor ve yargıç her seferinde farklı okuyor demektir. Bu durumda, ikili geçti/kaldı değerlendirmeler, 5 puanlı ölçeklere kıyasla çalıştırmalar arası daha güvenilir sonuçlar üretme eğilimindedir; bu yüzden üretim izleme için sayısal puanları ikiliye daraltmayı, arada yaşanan tutarsızlıkların daha az maliyetli olduğu çevrimdışı analiz içinse ayrıntılı ölçekleri saklamayı düşünün.
  4. Ölçekte maliyeti yönetin. Değerlendirme istemleri, orijinal soru, tam getirilen bağlam, üretilen yanıt ve puanlama ölçütleriyle eksiksiz rubrik içermeleri gerektiğinden tipik üretim istemlerinden oldukça uzundur. Yüksek hacimli sistemlerde, yaygın ve maliyet-etkin bir desen, sorguların rastgele %10’luk bir örneklemi üzerinde ayrıntılı LLM değerlendirmeleri çalıştırırken geri kalan %90’lık trafiğe daha basit otomatik kontroller (uzunluk, biçim uyumu, anahtar sözcük varlığı) uygulamaktır.
  5. İnsanları döngüde tutun. Yargıç üretimde iyi çalışmaya başladıktan sonra bile, ekipten birinin her hafta yargıcın değerlendirmelerinden rastgele bir örneklemi gözden geçirdiği düzenli bir süreç kurun. Özellikle yargıcın mükemmel (5/5) puan verdiği yanıtlara dikkat edin; çünkü yanlış bir yanıta en fazla yersiz güvenin doğacağı tam da bu vakalardır.

Uçtan uca LLM iş akışlarını operasyonelleştirme hakkında daha fazlası için, Veri Bilimciler için Yardımcı Yapay Zekâ Mühendisi yolu tam devreye alma resmini kapsar.

Sonuç

LLM-as-a-judge, ne geleneksel otomatik metriklerin ne de insan incelemesinin tek başına ölçekte karşılayabildiği pratik bir ihtiyacı karşılar. Otomatik metrikler LLM uygulamaları için gerçekten önemli olanı kaçırır; öte yandan, insan değerlendirmesi önemli olanı yakalar ama bir üretim sisteminin hacmine yetişemez. 

Arada konumlanan bir LLM yargıcı, basit metriklerin sağlayamayacağı incelikle çıktı kalitesini sürekli izlemenize olanak tanır.

Bu eğitimde eksiksiz bir hat kurduk: küçük bir bilgi tabanına sahip bir RAG sistemi, farklı başarısızlık biçimlerini tetiklemek üzere tasarlanmış test sorguları, bağlam sadakati ve alaka düzeyi için özel değerlendirme yargıçları ve üretime daha yakın olan DeepEval tabanlı bir yaklaşım.

Tüm bunlardan çıkarılacak tek bir şey varsa, rubrik her şeydir. Bu yüzden her puan düzeyi için net örneklerle birlikte belirli ve somut değerlendirme ölçütleri yazmaya zaman ayırmalısınız. İyi tasarlanmış bir rubrik ve vasat bir model, muğlak bir rubrik ve en yetenekli modeli her defasında geride bırakır.

Buradan devam etmek isterseniz:

Yargıç Olarak LLM SSS

LLM-as-a-judge tam olarak nedir?

Kısaca: GPT-4 veya Claude gibi yetenekli bir modele, sade bir İngilizceyle yazdığınız bir rubriğe dayanarak başka bir modelin ürettiğini puanlamasını ya da sınıflandırmasını istersiniz. Çıktıları gözden geçirmek için insanları tamamen ikame etmez; ancak günde binlerce yanıtla uğraşıyorsanız, bir ordu dolusu etiketleyici işe almadan kaliteyi takip etmenin tek pratik yoludur.

Bir LLM yargıç neleri değerlendirebilir?

Temelde, ölçüt olarak kelimelere dökebileceğiniz her şey. Kaynak belgelere sadakat, ton, güvenlik, yanıtın gerçekten soruyu yanıtlayıp yanıtlamadığı ve halüsinasyon tespiti iyi örneklerdir. Bazı ekipler, yargıcın iki aday yanıt arasında hangisini tercih ettiğini seçtiği çiftli karşılaştırmalar da çalıştırır. Esneklik işin özüdür.

LLM yargıçlar insanlara kıyasla ne kadar isabetlidir?

Araştırmalarda sürekli karşımıza çıkan sayı insan değerlendiricilerle yaklaşık %80 uyumdur ve iki insan değerlendiricinin birbiriyle uyumu da kabaca budur. Yine de LLM yargıçların önyargıları vardır. Daha kısa bir yanıt daha iyi olsa bile daha uzun, ayrıntılı yanıtları tercih etme eğilimindedirler; bu yüzden tasarımınızı buna göre yapmanız gerekir.

Hangi çerçeveler LLM-as-a-judge’u destekliyor?

DeepEval, pytest ile entegre olduğu ve değerlendirmeleri birim testleri gibi ele aldığı için popülerdir; bu da CI/CD iş akışlarına doğal biçimde uyar. RAGAS özel olarak RAG hattı değerlendirmesi için geliştirildi. MLflow yakın zamanda her ikisiyle de entegrasyonlar ekledi; böylece birden fazla çerçeveden metrikleri tek bir takip sistemine çekebilirsiniz. LangSmith ve Evidently başlıca seçenekleri tamamlar.


Josep Ferrer's photo
Author
Josep Ferrer
LinkedIn
Twitter

Josep, Avrupa projelerine odaklanan serbest bir Veri Bilimcidir; veri depolama, işleme, ileri analitik ve etkili veri hikâyeleştirme konularında uzmandır. 

Eğitmen olarak Navarra Üniversitesi'nin Yüksek Lisans programında Büyük Veri dersleri vermekte ve Medium, KDNuggets ve DataCamp gibi platformlarda yayımladığı makalelerle görüşlerini paylaşmaktadır. Josep ayrıca Databites bülteninde (databites.tech) Veri ve Teknoloji üzerine yazmaktadır. 

Katalonya Politeknik Üniversitesi'nden Mühendislik Fiziği lisans derecesine ve Pompeu Fabra Üniversitesi'nden Akıllı Etkileşimli Sistemler yüksek lisans derecesine sahiptir.

Konular

Yapay Zekâ Mühendisliği Kursları

Program

AI Engineering with LangChain

21 sa
From prompt engineering to agentic systems—develop the complete skill set to build AI applications that scale, with an AI tutor by your side.
Ayrıntıları GörRight Arrow
Kursa Başla
Devamını GörRight Arrow
İlgili

blog

Hızlı Sevkiyat İçin Pratik Vibe Kodlama Teknoloji Yığını

Ön uç, arka uç, veritabanları, kimlik doğrulama, depolama, e-posta, test, dağıtım ve izleme için en iyi araçları keşfedin.
Abid Ali Awan's photo

Abid Ali Awan

14 dk.

blog

2026’da En Popüler 40 Yazılım Mühendisi Mülakat Sorusu

Algoritmalar, sistem tasarımı ve davranışsal senaryoları kapsayan bu temel sorularla teknik mülakat sürecine hakim olun. Uzman cevapları, kod örnekleri ve kanıtlanmış hazırlık stratejileri edinin.
Dario Radečić's photo

Dario Radečić

15 dk.

Eğitim

.gitignore Nasıl Kullanılır: Örneklerle Pratik Bir Giriş

Git deponuzu temiz tutmak için .gitignore’u nasıl kullanacağınızı öğrenin. Bu eğitim; temelleri, yaygın kullanım durumlarını ve başlamanıza yardımcı olacak pratik örnekleri kapsar!
Kurtis Pykes 's photo

Kurtis Pykes

Eğitim

Python'da Listeyi String'e Nasıl Dönüştürürsünüz

Bu hızlı eğitimde, Python'da bir listeyi string'e nasıl dönüştüreceğinizi öğrenin.
Adel Nehme's photo

Adel Nehme

Devamını GörDevamını Gör