Yazılım Eğitimi Asistanlarında LLM Judge Kalibrasyonu ve Drift İzleme

Yazılım eğitimi için judge veri setini rubrik ve dilimlerle kurmak

LLM judge değerlendirmesini tek bir genel kalite puanına indirmek, özellikle kod geri bildirimi üreten ürünlerde hatalı güven yaratır. Veri setini en az dört bağımsız rubriğe ayırın: teknik doğruluk, açıklamanın pedagojik yeterliliği, çalıştırılabilir kod ve güvenlik. Her örneğe dilim etiketleri ekleyin: dil, görev tipi, seviye, hata sınıfı ve istenmeyen davranış. Örneğin Python concurrency sorularındaki puan düşüşü, genel ortalama sabit kalsa bile kritik bir regresyon olabilir.

{
  "id": "py-async-042",
  "input": "asyncio.gather neden exception ile duruyor?",
  "answer": "...",
  "reference_facts": ["return_exceptions=True davranışı", "cancel propagation"],
  "rubric": {
    "technical_correctness": 0,
    "pedagogy": 0,
    "runnable_code": 0,
    "security": 0
  },
  "slice": {
    "language": "python",
    "task": "debugging",
    "level": "intermediate",
    "topic": "asyncio"
  }
}

Etiketleme arayüzünde 1-5 serbest puan yerine davranışsal ankraj kullanın. Teknik doğruluk için 1, temel mekanizmanın yanlış açıklanması; 3, doğru çözüm fakat cancellation edge case'inin atlanması; 5, mekanizma, sınır koşulu ve doğrulanabilir örnek demek olabilir. Label Studio veya Argilla ile iki insan değerlendiriciden bağımsız etiket toplayın. En az 100 örneklik başlangıç setinde anlaşmazlık oranını da saklayın; judge'in insanla uyuşmadığı örnek ile iki insanın da uyuşmadığı örnek aynı hata türü değildir.

LLM judge kalibrasyonunda insan uyumu ve puan şişmesini ölçmek

Judge prompt'unda yalnızca puanı değil, rubrik başına kanıtı ve referans cevaptan doğrulanan iddiayı isteyin. Modelin gerekçesi kullanıcıya gösterilecek açıklama değildir; denetim artefact'ıdır. Puanı gerekçeden önce üretmek anchoring etkisi doğurabilir. Bu nedenle önce atomik bulguları, sonra her rubrik için puanı ürettirin ve JSON'u Pydantic ile ayrıştırın.

from pydantic import BaseModel, Field
from typing import Literal

class Finding(BaseModel):
    claim: str
    verdict: Literal["supported", "unsupported", "contradicted"]
    evidence: str

class JudgeResult(BaseModel):
    findings: list[Finding]
    technical_correctness: int = Field(ge=1, le=5)
    pedagogy: int = Field(ge=1, le=5)
    runnable_code: int = Field(ge=1, le=5)
    security: int = Field(ge=1, le=5)

# Sonraki adımda model yanıtını JudgeResult.model_validate_json(raw) ile doğrulayın.

Kalibrasyonu Pearson korelasyonu ile tek başına kabul etmeyin. 1-5 ordinal puanlarda quadratic weighted kappa, sıralama için Spearman korelasyonu ve kritik hata kaçırma oranını birlikte raporlayın. Kritik hata tanımını önceden sabitleyin: insan teknik doğruluğa 1 veya 2 verirken judge 4 veya 5 veriyorsa false-pass sayın. Bu metrik, ortalama puanı yüksek tutan ama yanlış kodu onaylayan judge'leri görünür kılar.

from sklearn.metrics import cohen_kappa_score
from scipy.stats import spearmanr

human = [2, 5, 4, 1, 3, 5]
judge = [4, 5, 3, 4, 3, 5]

kappa = cohen_kappa_score(human, judge, weights="quadratic")
rho = spearmanr(human, judge).statistic
false_pass = sum(h <= 2 and j >= 4 for h, j in zip(human, judge)) / len(human)
print({"weighted_kappa": kappa, "spearman": rho, "false_pass_rate": false_pass})

Yaygın hata, judge'e referans cevabı tamamen vermektir. Bu yaklaşım, cevap aynı sonucu farklı ama geçerli bir yöntemle elde ettiğinde lexical benzerliği doğruluk sanabilir. Referans cevabı yerine doğrulanabilir fact listesi, yasaklı iddialar ve kabul edilen alternatif yaklaşımlar verin. Örneğin SQL sorgusunda yalnızca beklenen sorguyu değil, "parameter binding zorunlu" kuralını ve kabul edilen ORM çözümünü rubriğe dahil edin.

Yazılım eğitimi judge değişiklikleri için istatistiksel yayın kapısı

Yeni judge prompt'unu veya model sağlayıcısını üretime almadan önce aynı sabit holdout set üzerinde eski ve aday sürümü çalıştırın. Karşılaştırmada sıcaklık değerini 0 kullanın, istek gövdesi hash'ini, model kimliğini ve prompt commit SHA'sını kaydedin. Amaç aday sürümün mutlak skorunu değil, aynı örneklerde eski sürüme göre kritik false-pass üretip üretmediğini ölçmektir.

Küçük holdout setlerde tek çalıştırmadaki yüzde farkı gürültülüdür. Bootstrap ile false-pass farkının yüzde 95 güven aralığını hesaplayın. Aşağıdaki kapı, aday sürümün üst güven sınırı eski sürümden 0.5 puan yüzdesinden fazla kötü ise CI işini başarısız yapar. Eşik ürün riskine göre sürümlenmeli ve kod deposunda tutulmalıdır.

import numpy as np

# Her dizi, aynı örneklerde kritik false-pass ise 1, değilse 0.
baseline = np.array([0, 0, 1, 0, 0, 0, 0, 1])
candidate = np.array([0, 1, 1, 0, 0, 0, 0, 1])

rng = np.random.default_rng(42)
deltas = []
for _ in range(10_000):
    idx = rng.integers(0, len(baseline), len(baseline))
    deltas.append(candidate[idx].mean() - baseline[idx].mean())

low, high = np.quantile(deltas, [0.025, 0.975])
print({"delta_ci": [float(low), float(high)]})
if high > 0.005:
    raise SystemExit("Reject: critical false-pass regression")

Bu kapıyı yalnızca toplam veri setinde değil, dilim bazında da çalıştırın. Bir aday sürüm İngilizce algoritma sorularında iyileşirken Türkçe hata ayıklama açıklamalarında gerileyebilir. Minimum dilim örnek sayısı 30'un altındaysa otomatik ret yerine "insan incelemesi gerekli" durumu üretin; çok küçük örneklemde bootstrap aralığı teknik olarak hesaplanabilir olsa da karar kalitesi zayıftır.

Üretimde judge drift'ini OpenTelemetry ve Prometheus ile yakalamak

Canlı trafikte insan etiketi gecikmeli geleceği için ilk sinyal dağılım drift'idir, ancak bunu doğrudan kalite düşüşü diye yorumlamayın. Judge teknik doğruluk puanı, false-pass proxy'si, JSON doğrulama hatası ve rubrik başına "unsupported" bulgu oranını gün bazında ölçün. OpenTelemetry span attribute'larında ham öğrenci metni taşımayın; prompt ve yanıt için HMAC tabanlı bir fingerprint, judge sürümü ve dilim etiketini kaydedin.

from opentelemetry import trace
import hmac, hashlib, os

tracer = trace.get_tracer("evaluation")
def fingerprint(value: str) -> str:
    return hmac.new(os.environ["TRACE_HMAC_KEY"].encode(), value.encode(), hashlib.sha256).hexdigest()[:16]

with tracer.start_as_current_span("llm_judge") as span:
    span.set_attribute("judge.version", "git:8fa21c")
    span.set_attribute("eval.slice.language", "python")
    span.set_attribute("eval.answer_fp", fingerprint(answer))
    span.set_attribute("eval.technical_score", result.technical_correctness)

Prometheus'ta dağılımı histogram olarak yayınlayın ve alarmı iki koşula bağlayın: son 24 saatte teknik doğruluk puanı ortalaması 30 günlük tabandan belirgin sapacak, ayrıca JSON parse hata oranı yüzde 1'i geçecek. Sadece ortalama puana alarm kurmak puan sıkışmasını kaçırır: bütün cevaplar 3'e yaklaşırsa ortalama sabit kalabilir ama değerlendirme ayırt ediciliğini kaybeder. Bu durumda score histogramındaki p10-p90 aralığını da takip edin.

# PromQL: son gün ile önceki 30 günün ortalama teknik puanını karşılaştırır
(
  sum(rate(judge_technical_score_sum[24h]))
  / sum(rate(judge_technical_score_count[24h]))
)
-
(
  sum(rate(judge_technical_score_sum[30d]))
  / sum(rate(judge_technical_score_count[30d]))
)

Kalibrasyon sonrası hata incelemesini tekrar kullanılabilir hale getirmek

Her false-pass örneğini "model bilgisizliği", "rubrik belirsizliği", "referans fact eksikliği", "çıktı ayrıştırma hatası" ve "insan etiket anlaşmazlığı" sınıflarından yalnızca birine zorla atamayın. Birincil ve ikincil neden saklayın. Örneğin judge, SQL injection'ı doğru saptayıp kodun sözdizimi hatasını kaçırıyorsa bu iki ayrı rubrik hatasıdır ve tek bir genel prompt değişikliği ile çözülmeyebilir.

Düzeltmenin etkisini ölçmek için hata örneklerini doğrudan holdout'a eklemek veri sızıntısı yaratır. Hata örneklerini önce regression set'e koyun, holdout'u ise değişmeden bırakın. CI'da ikisini de çalıştırın: regression set, bilinen hatanın geri dönmediğini; holdout ise düzeltmenin daha geniş veri üzerinde gerçekten genellenip genellenmediğini gösterir. Bu ayrım, yazılım eğitimi ürünlerinde prompt'a birkaç örnek ekleyerek metrik yükseltme yanılsamasını engeller.

Sık Sorulan Sorular

Yazılım eğitimi asistanında LLM judge için kaç insan etiketli örnek gerekir?

İlk kalibrasyon için her kritik dilimde en az 30, toplamda en az 100 çift etiketli örnekle başlayın. Bu sayı yayın kararı için sabit bir yasa değildir. Weighted kappa'nın güven aralığı genişse, özellikle false-pass örneklerini hedefleyerek yeni etiket toplayın; rastgele kolay örnek eklemek belirsizliği yeterince azaltmaz.

LLM judge puanı insan puanıyla yüksek korelasyon gösterirken neden yanlış olabilir?

Spearman korelasyonu sıralamanın benzer olduğunu gösterir, fakat güvenlik veya teknik doğrulukta 1 puanlık kritik farkı cezalandırmayabilir. İnsan 1 verirken judge'in 4 vermesi, genel korelasyon yüksek olsa dahi üretim riski taşır. Bu nedenle weighted kappa ve insan düşükken judge yüksek olan false-pass oranını birlikte yayın kapısına ekleyin.

Yazılım eğitimi LLM judge drift'i model sürümü değişmeden oluşur mu?

Evet. Trafiğe yeni programlama dili soruları, farklı öğrenci seviyesi veya yeni görev şablonları girdiğinde input dağılımı değişir. OpenTelemetry ile language, task ve level etiketlerini; Prometheus ile skor histogramlarını izleyin. Drift saptandığında önce dilim kompozisyonunu kontrol edin, ardından o dilimden insan etiketli örneklerle gerçek kalite kaybını doğrulayın.