Prompt Regresyon Testleri: Değerlendirmeyi CI'a Sokmak

Prompt’u değiştirdiniz, üç örnekte denediniz, iyi göründü, dağıttınız. Bir hafta sonra destek ekibi başka bir senaryonun bozulduğunu söylüyor. Bu döngüyü kıran şey daha iyi prompt yazmak değil; değerlendirmeyi bir build adımı hâline getirmek. Bu yazı, ölçütlerin ne olduğunu değil, ölçümün nerede çalıştığını anlatıyor: altın veri seti, CI kapısı, hakem kalibrasyonu ve Türkçe metinde sessizce yanlış sonuç üreten tuzaklar.

Altın veri setini nereden çıkarırsınız?#

En sık yapılan hata, test setini masa başında uydurmaktır. Uydurulmuş sorular, gerçek kullanıcıların sorduğu sorulara benzemez ve testiniz geçerken üretim bozulur. Doğru kaynak üretim günlükleridir.

Altın veri seti yazılmaz, üretimden çıkarılır.

Pratik yöntem: son otuz günün günlüklerinden rastgele 200 istek örnekleyin, bunları elle kümeleyin ve her kümeden 3-5 temsilci seçin. Sonuç genellikle 50-150 örneklik bir set olur ve bu yeterlidir. Buna ek olarak iki küme daha ekleyin: geçmiş hatalar (her düzeltilen hata bir test olur — regresyon setinin gerçek değeri budur) ve kenar durumlar (boş girdi, çok uzun girdi, karışık dilli girdi, saldırı denemesi).

Üç katmanlı test piramidi#

Her örneği bir LLM hakemine sormak pahalı ve gereksizdir. Ucuzdan pahalıya doğru üç katman kurun; her katman bir öncekini geçenleri alır.

Bu piramidin faydası maliyet değil hız: birinci katman her commit’te, ikincisi her pull request’te, üçüncüsü gecelik çalışabilir.

promptfoo ile çalışan bir CI kapısı#

Türkçe kaynaklarda araç adı geçmediği için baştan söyleyeyim: bu alanda kullanılan araçlar promptfoo, RAGAS (RAG’a özel ölçütler), DeepEval ve barındırılan tarafta LangSmith ile Braintrust. En hızlı başlangıç promptfoo, çünkü bir YAML dosyası ve tek komuttan ibaret.

# promptfooconfig.yaml
prompts:
  - file://prompts/destek-v3.txt
providers:
  - id: anthropic:messages:claude-sonnet-4-5
    config: { temperature: 0 }

defaultTest:
  assert:
    - type: is-json
      value:
        type: object
        required: [niyet, oncelik, ozet]
    - type: not-contains
      value: "bir dil modeli olarak"
    - type: latency
      threshold: 4000

tests:
  - description: fatura itirazi
    vars: { mesaj: "Gecen ay iki kez tahsilat yapilmis, iade istiyorum." }
    assert:
      - type: equals
        value: '{"niyet":"iade_talebi","oncelik":"yuksek"}'
        transform: 'JSON.stringify({niyet: output.niyet, oncelik: output.oncelik})'

  - description: bos girdi
    vars: { mesaj: "" }
    assert:
      - type: javascript
        value: output.niyet === "belirsiz"

# CI adimi: esik altinda kalirsa build kirilir
npx promptfoo@latest eval -c promptfooconfig.yaml \
  --output sonuc.json --fail-on-error
npx promptfoo@latest eval --assert-pass-rate 0.95

Kapının pull request’te çalışması, prompt’u koda çevirir. Bir prompt değişikliği artık bir diff’tir, testi vardır ve geçmezse birleşmez.

Hakem kalibrasyonu: güvenilirlik geçerlilik değildir#

LLM hakemi kullanacaksanız, 2026’da yayımlanan en kapsamlı güvenilirlik çalışmasını bilmeniz gerekir (arXiv:2606.19544, 17 Haziran 2026): 9 sağlayıcıdan 21 hakem, 118 koşu ve yaklaşık 541.000 tekil yargı. Bulguları bir hakem kurmadan önce okunmalı:

• Kappa düşüşü evrensel. Ham uyuşma oranı ile şansa göre düzeltilmiş Cohen kappa arasındaki fark MT-Bench üzerinde 33–41 puana kadar çıkıyor. Yani “hakemim %85 uyuşuyor” cümlesi neredeyse hiçbir şey ifade etmiyor.
• Sıralamalar kıyaslamaya göre 14 basamağa kadar kayıyor. Bir hakemin bir sette iyi olması, sizin setinizde iyi olacağı anlamına gelmiyor.
• Tutarlılık-yanlılık paradoksu: üretimde kullanılan iki hakem, test-tekrar test güvenilirliği 0,95’in üzerindeyken aynı anda 0,10’un üzerinde konum yanlılığı gösteriyor. Yani hakem tutarlı biçimde yanlı olabilir.
• Ayrıntı sözlülük yanlılığı küçük (0,011’in altında) — yani en çok korkulan yanlılık aslında en zararsızı.

Pratik karşılığı üç kural. Bir: hakeminizi 50-100 insan etiketli örnekle doğrulayın ve ham uyuşma değil kappa raporlayın. İki: ikili karşılaştırmalarda A/B sırasını rastgeleleştirin ve her çifti iki yönde de sorun — konum yanlılığını ölçmenin tek yolu bu. Üç: hakem prompt’unu da sürümleyin; hakem değiştiğinde geçmiş skorlar karşılaştırılamaz hâle gelir.

Bir uyarı daha: insan etiketleri de altın standart değil. Aynı alandaki bir başka çalışma, insan açıklamalarının kendi içinde belirgin biçimde tutarsız olduğunu ve bunun insan etiketli kıyaslamaları da zayıflattığını gösteriyor. Yani hakemi insana yaklaştırmak bir tavan, bir garanti değil.

Türkçe’de eşleştirmeyi bozan tuzaklar#

Bu bölüm İngilizce kaynaklarda yok ve Türkçe değerlendirmede sessizce yanlış sonuç üretiyor.

• Sondan eklemelilik tam eşleşmeyi kırar. “iade” ile “iadesi” ve “iadesini” farklı dizelerdir. Sınıflandırma etiketlerinde tam eşleşme kullanın, serbest metinde asla.
• Aksan kaybı (deasciification). Kullanıcılar “gecen ay” yazar, referansınız “geçen ay” der. Karşılaştırmadan önce her iki tarafı da aynı normalleştirmeden geçirin.
• İ/ı büyük-küçük harf. Standart lower() Türkçe’de yanlıştır; "İ".lower() iki karakter döndürür.
• Unicode birleştirme. Aynı görünen iki metin farklı kod noktalarından oluşabilir; NFC normalleştirmesi şart.

import unicodedata

TR_ASCII = str.maketrans("çğıöşüÇĞİÖŞÜ", "cgiosuCGIOSU")

def normalize_tr(s: str) -> str:
    """Degerlendirmede karsilastirmadan once IKI tarafa da uygulanir."""
    s = unicodedata.normalize("NFC", s)
    s = s.replace("I", "ı").replace("İ", "i").lower()
    s = s.translate(TR_ASCII)                  # aksan farkini yok say
    return " ".join(s.split())                 # bosluklari sadelestir

assert normalize_tr("İADE Talebi")  == normalize_tr("iade  talebi")
assert normalize_tr("Geçen ay")     == normalize_tr("gecen ay")

Kapı nasıl ayarlanır?#

Bir CI kapısının işe yaraması, eşiğin doğru ayarlanmasına bağlı. Çok sıkı bir kapı devre dışı bırakılır, çok gevşek bir kapı hiçbir şey yakalamaz.

1. Mutlak eşik değil, gerileme eşiği kullanın. “%95 geçmeli” yerine “ana daldan 2 puandan fazla düşmemeli”. Böylece kapı, sistemin bugünkü hâline göre kalibre olur.
2. Kritik testleri ayırın. Güvenlik ve şema testleri tek bir başarısızlıkta bile kırmalı; kalite testleri toplam orana bakmalı.
3. Gürültüyü ölçün. Kapıyı kurmadan önce aynı sürümü beş kez çalıştırın ve doğal dalgalanmayı görün; eşik bu dalgalanmanın üstünde olmalı.
4. Maliyeti ve gecikmeyi de kapıya koyun. Kaliteyi artırırken maliyeti üçe katlayan bir değişiklik, bir gerileme sayılmalı ve tartışılmalı.

Değerlendirme bir rapor değil bir build adımı hâline geldiğinde, prompt değiştirmek korkutucu olmaktan çıkar. Hangi ölçütlerin ne anlama geldiği için LLM değerlendirme, ajanların özel ölçme sorunları için ajan değerlendirmesi, ve bu kapının içine oturacağı dağıtım hattı için MLOps ve üretime alma yazılarına bakabilirsiniz.