Prompt Başarısını Ölçme: KPI'lar, Otomatik Değerlendirme ve Analiz Araçları

Bir promptu “iyi” yapan şey çoğu zaman göz kararıyla anlaşılır; fakat üretime yaklaşınca bu yaklaşım hızla yetersiz kalır. Küçük bir prompt değişikliği, bir görevde başarıyı artırırken başka bir görevde hataları tetikleyebilir. Bu yüzden prompt başarısını ölçmek, tek seferlik bir kontrol değil; tekrarlanabilir KPI’lar, otomatik değerlendirme ve düzenli insan denetimi ile kurulan bir süreçtir.

Bu yazıda, genel kitle için anlaşılır ama uygulamaya dönük bir çerçeve sunacağız: görev-özgü KPI seti nasıl tanımlanır, otomatik değerlendirme nasıl kurulur, “model as judge” (LLM-yargıç) nerede işe yarar, nerede dikkat ister ve human-in-the-loop döngüsü nasıl tasarlanır. Referans olarak OpenAI Evaluation Best Practices kılavuzunu, OpenAI Evals (GitHub) deposunu ve iki arXiv ön baskısını (hakem değerlendirmesi süreci devam ediyor olabilir) kullanıyoruz.

1) Prompt başarısı: Tek bir puan değil, bir denge

Prompt engineering’de “başarı” çoğunlukla birden fazla hedefin aynı anda karşılanmasıdır. Örneğin:

• Görev başarısı: İstenen çıktı doğru mu, işe yarıyor mu?
• Talimata uyum: Format, ton, kapsam, kısıtlar tutuluyor mu?
• Güvenilirlik: Benzer girdilerde tutarlı sonuç veriyor mu?
• Operasyonel performans: Gecikme ve maliyet kabul edilebilir mi?

Bu nedenle KPI’ları tek bir “kalite skoru”na indirgemek yerine, iş hedefinize göre ağırlıklandırılmış bir KPI sepeti tasarlamak daha sağlıklıdır. OpenAI Evaluation Best Practices, ölçümü “görev-özgü” kurmayı ve değerlendirmeyi iteratif geliştirmeyi vurgular: önce neyi ölçmek istediğinizi netleştirir, sonra ölçümü otomasyonla ölçeklersiniz.

2) KPI setini tasarlama: Ölçmeden önce tanımla

2.1 Görevi ve “başarı”yı yazılı hale getirin

İlk adım basit ama kritik: Promptunuzun çözdüğü görevi 2–5 maddeyle açıklayın ve “başarılı çıktı”nın şartlarını yazın.

• Girdi türleri: Kullanıcı sorusu mu, yapılandırılmış veri mi, doküman mı?
• Çıktı formatı: Serbest metin mi, JSON mu, tablo mu?
• Zorunlu unsurlar: Kaynak linki verme, belirli başlıkları içerme vb.
• Yasaklar/kısıtlar: Örneğin “bilinmiyorsa bilmiyorum demeli” gibi.

Bu tanım, hem otomatik kontrollerin (format doğrulama, şema uyumu gibi) hem de insan değerlendirmesinin ortak referansı olur.

2.2 KPI kategorileri: Kalite + operasyon + risk

Aşağıdaki tablo, pratikte en sık kullanılan KPI sınıflarını ve nasıl ölçülebileceklerini özetler. Bazıları tamamen otomatik ölçülebilirken, bazıları örnekleme ve insan puanlamasıyla daha güvenilir olur.

Not: KPI adları ve metrikler kullanım senaryosuna göre değişir. Önemli olan, her KPI’ın nasıl ölçüleceğini ve hangi kararları tetikleyeceğini önceden tanımlamaktır.

2.3 “Altın set” (golden set) oluşturarak ölçümü sabitleyin

Üretime yakın bir değerlendirme için, tekrar tekrar çalıştıracağınız bir test seti gerekir:

• Temsil gücü: Gerçek kullanıcı dağılımını mümkün olduğunca yansıtın.
• Edge-case örnekleri: Format hataları, eksik veri, belirsiz istekler.
• Etiketleme yönergesi: İnsan puanlayacaksa rubrik net olmalı.

OpenAI Evaluation Best Practices, değerlendirmeyi görev-özgü tasarlamayı ve yinelemeli olarak geliştirmeyi önerir.

3) Otomatik değerlendirme yöntemleri: Üç katmanlı yaklaşım

Pratikte en sağlam kurgu, otomasyonu üç katmanda düşünmektir: (1) kural/kod tabanlı testler, (2) LLM-yargıç değerlendirmeleri, (3) insan örneklemesiyle doğrulama.

3.1 Kod tabanlı (programatik) testler: Hızlı ve deterministik

Bunlar “unit test” mantığıyla çalışır ve regresyon yakalamada çok etkilidir:

• Format testleri: Çıktı JSON mu? Gerekli alanlar var mı?
• Şema doğrulama: Alan tipleri doğru mu? Boş geçilmiş mi?
• Kural kontrolleri: Maksimum uzunluk, yasaklı ifade listeleri, vb.
• Çalıştırılabilir değerlendirme: Kod üretiyorsa derleniyor/çalışıyor mu?

Bu yaklaşım, otomatik testlerin üretim öncesi regresyonları yakalamada etkili olduğu fikriyle uyumludur; ancak gerçek hayatta veri dağılımı değişebilir ve bu yüzden periyodik insan örneklemesi genellikle gereklidir. Bu denge, OpenAI Evals gibi çerçevelerde pratik bir şekilde uygulanabilir.

3.2 “Model as judge” (LLM-yargıç): Ölçeklenebilir ama kalibrasyon ister

Her şeyi kural ile ölçemezsiniz. Örneğin “yanıt faydalı mı?”, “gerekçelendirme sağlam mı?”, “talimatı gerçekten takip ediyor mu?” gibi boyutlar için LLM-yargıç, ölçeklenebilir bir seçenek sunar. OpenAI Evaluation Best Practices, rubrik tanımları ve değerlendirme tasarımı konusunda pratik öneriler içerir.

Yine de önemli bir sınırlılık var: LLM-yargıç sonuçları, kullandığınız rubriğe, örneklere ve model seçimine duyarlı olabilir. Bu konuda, örneğin PLHF (arXiv ön baskı) prompt optimizasyonunda az sayıda insan geri bildiriminin (few-shot) nasıl kullanılabildiğini tartışır. Ön baskı olduğu için sonuçları üretim geneli için kesin kabul etmek yerine, şu tür temkinli çıkarımlar yapmak daha güvenlidir:

• Çıkarım 1: Az sayıda, iyi tanımlanmış insan geri bildirimi örneği; otomatik değerlendirme/iyileştirme döngülerinin “neye iyi-kötü deneceğini” daha netleştirmeye yardımcı olabilir.
• Çıkarım 2: Otomasyon ölçek sağlasa da, değerlendirme kuralları ve rubrik tasarımı değiştikçe sonuçlar dalgalanabilir; bu yüzden kalibrasyon ve insan doğrulaması kritik kalır.

Uygulanabilir önlemler:

• Rubriği somutlaştırın: 1–5 yerine “geçti/kaldı” gibi net kriterler ekleyin.
• Çift yargıç: İki farklı yargıç modelle çapraz kontrol yapın; uyuşmazlıkları insan incelemesine gönderin.
• Anchor örnekler: Her skor bandı için örnek “iyi/kötü” çıktılar saklayın.
• Holdout set: Rubriği geliştirdiğiniz veri ile raporladığınız veri aynı olmasın.

3.3 Hibrit yaklaşım: Otomasyon + insan denetimi

Güvenilir bir üretim hattı çoğu zaman hibrittir:

• Günlük/CI: kod tabanlı testler + küçük bir LLM-yargıç paketi
• Haftalık: insan örneklemesi (rastgele + risk odaklı)
• Aylık/çeyreklik: rubrik revizyonu + veri seti genişletme

Örneğin CoTAL (arXiv ön baskı), insanın sürece dahil olduğu değerlendirme/puanlama senaryolarında, insan incelemesini daha “bilgi değeri yüksek” örneklere yönlendiren (ör. belirsiz veya sınırda kalan örnekler) yaklaşımları ele alır. Ön baskı olduğu için genelleme yapmadan, şu iki pratik ders çıkarılabilir:

• Çıkarım 1: İnsan denetimini rastgele dağıtmak yerine, otomatik sistemin zorlandığı örneklere yoğunlaştırmak daha verimli olabilir.
• Çıkarım 2: Değerlendirme rubriği ve örnek seçimi (aktif örnekleme) birlikte tasarlandığında, kalite takibi daha sürdürülebilir hale gelebilir.

4) OpenAI Evals ile otomatik değerlendirmeye başlama (konsept düzeyinde)

OpenAI Evals, prompt ve model davranışını farklı değerlendirme türleriyle test etmek için açık kaynak bir çerçeve sunar. Depoda, model-graded değerlendirmeler ve programatik testlere benzer şablonlar bulunur. Bu tip bir araç, özellikle şu ihtiyaçlarda işe yarar:

• Regresyon testi: Promptu değiştirdiniz; eski “iyi” örnekler bozuldu mu?
• Karşılaştırma: İki prompt varyantı veya iki model sürümü hangisinde KPI daha iyi?
• Ölçek: Küçük bir insan ekibinin yetişemeyeceği kadar çok senaryoyu hızlı taramak.

Başlangıç için pratik bir yol haritası:

1. Değerlendirme hedefini seçin: Örn. “talimata uyum” ve “format doğruluğu”.
2. Test setini derleyin: 50–200 örnekle başlayıp zamanla büyütün (tam sayı hedefi ekibin kapasitesine göre değişebilir).
3. Skorlama yöntemini belirleyin: Format/şema için programatik; kalite için LLM-yargıç + insan örneklemesi.
4. Başarı eşiği tanımlayın: “Yayınlanabilir” seviyeyi KPI bazında tarif edin.
5. CI veya zamanlanmış çalışma: Her değişiklikte veya gece çalıştırıp raporlayın.

4.1 Kavramsal örnek (araçtan bağımsız)

Aşağıdaki örnek, “özetleme” görevi için tek bir test vakasının nasıl tanımlanabileceğini kavramsal olarak gösterir (amaç, format + kalite KPI’larını aynı pakette düşünmektir):

Test vakası (1 satır)

• Girdi: “Aşağıdaki metni 6 maddeyle özetle ve 3 aksiyon öner.” + (metin)
• Beklenen format/şema (programatik kontrol): Çıktı JSON olmalı ve alanlar şu şekilde olmalı:
  • summary_points: tam 6 madde (liste)
  • actions: tam 3 madde (liste)
• LLM-yargıç rubriği (1 madde): “Kapsam: Özet, metindeki ana fikri ve en az 4 kritik noktayı içeriyor mu?” (Geçti/Kaldı)
• Geçme eşiği (örnek): Şema uyumu %100 + “Kapsam” rubriğinde %90+ test vakasında Geçti

Bu yaklaşım, format gibi deterministik kontrollerle (hızlı regresyon yakalama) daha öznel kalite boyutlarını (rubrikle) aynı çatı altında izlemeyi kolaylaştırır.

OpenAI Evaluation Best Practices, değerlendirmeyi iteratif iyileştirmeyi, metrikleri görevle hizalamayı ve sonuçları üretim kararlarıyla bağlamayı önerir.

5) Prompt analizi: Sonuçları “neden” düzeyinde okumak

Değerlendirme yalnızca skor üretmemeli; iyileştirme için teşhis üretmelidir. Bunun için çıktıları hata türlerine ayırmak çok işe yarar:

• Format hatası: JSON bozuk, eksik alan, yanlış tip.
• Kapsam hatası: İstenen soruya yanıt var ama önemli bir alt madde atlanmış.
• Talimat ihlali: Uzunluk sınırı, ton, “şunu yapma” kısıtı.
• Temelsiz ekleme: Veride olmayan ayrıntıları kesin gibi sunma.
• Gereksiz uzatma: Doğru ama verimsiz; maliyet/latency artar.

Bu sınıflandırmayı hem insan etiketleyiciye hem LLM-yargıca aynı terimlerle uygularsanız, “hangi prompt değişikliği hangi hata türünü etkiledi?” sorusuna daha hızlı yanıt alırsınız.

6) Human-in-the-loop: Nerede, ne sıklıkla, nasıl?

Otomasyonun sınırlı kaldığı yerde insan denetimi devreye girer. Human-in-the-loop tasarlarken amaç, her çıktıyı tek tek incelemek değil; en yüksek riski ve en yüksek öğrenme değerini yakalayacak şekilde örneklemektir.

6.1 Örnekleme stratejileri

• Rastgele örnekleme: Genel kaliteyi izlemek için.
• Eşik tetiklemeli: LLM-yargıç “düşük güven” veya “geçemedi” dediğinde.
• Yeni/az görülen senaryolar: Yeni ürün özelliği, yeni kullanıcı segmenti, yeni konu başlığı.
• Şikayet/geri bildirim kaynaklı: Kullanıcı geri bildirimleriyle eşleştirme.

6.2 Few-shot insan geri bildirimiyle iyileştirme

PLHF (arXiv ön baskı) gibi çalışmalar, az sayıda insan geri bildirimi örneğinin optimizasyon sürecini yönlendirmede nasıl kullanılabileceğini tartışır. Ön baskı niteliği nedeniyle, bunu “kanıtlanmış üretim standardı” gibi değil; kurum içi pilotla test edilebilecek bir yaklaşım olarak ele almak daha güvenlidir.

6.3 İnsan değerlendirmesini tutarlı kılma

• Rubrik: 3–6 maddelik net kontrol listesi.
• Çift puanlama: Kritik örneklerde iki kişi; uyuşmazlıkta üçüncü karar.
• Örnek kütüphanesi: “İyi” ve “kötü” örnekleri saklayın.

7) Üretimde izleme: Veri drift’i ve regresyonlara hazırlık

Promptunuzu “yayına almak”, ölçümün bittiği değil başladığı yerdir. Kullanıcı davranışı değişebilir, girdiler çeşitlenebilir, model sürümleri güncellenebilir. Bu yüzden:

• Loglama: Girdi/çıktı, metrikler, gecikme ve hata kodları (gizlilik politikalarınıza uygun şekilde).
• Dashboard: KPI trendleri; sürüm bazlı kırılım.
• Alarm kuralları: Format hatası artışı, maliyet sıçraması, talimata uyum düşüşü.
• Regresyon paketi: Her prompt değişikliğinde altın seti çalıştırma.

OpenAI Evals, bu regresyon yaklaşımını sistematik hale getirmeyi kolaylaştırabilir.

8) Uygulamalı mini senaryo: İçerik özetleme promptu

Diyelim ki bir blog yazısını 6 maddelik özet ve 3 aksiyon önerisine dönüştüren bir promptunuz var. Basit bir KPI seti şöyle olabilir:

• Şema uyumu: “summary_points” 6 madde mi? “actions” 3 madde mi? (programatik)
• Kapsam: Ana fikri kaçırıyor mu? (LLM-yargıç + insan örnekleme)
• Alıntı disiplini: Metinde olmayan iddiaları kesin gibi sunuyor mu? (LLM-yargıç rubriği + insan doğrulama)
• Gecikme/maliyet: İstek başına token ve yanıt süresi (loglardan)

Bu senaryoda “tek skor” yerine, örneğin önce şema uyumunu %100’e yaklaştırmak (kolay ve otomatik), sonra kapsam ve temelsiz ekleme riskini human-in-the-loop ile kademeli azaltmak genellikle daha verimli olur.

9) Hızlı kontrol listesi: 2 haftada ölçüm hattı kurma

• Gün 1–2: Görev tanımı + başarı kriterleri + rubrik taslağı
• Gün 3–5: 50–100 örnekten oluşan altın set (temsil + edge-case)
• Gün 6–7: Programatik testler (format/şema/kural)
• Hafta 2: LLM-yargıç pilotu, kalibrasyon, insan örnekleme süreci
• Son: CI veya zamanlanmış değerlendirme koşusu + raporlama

Değerlendirmeyi tasarlarken, ölçümün tek seferlik değil iteratif bir süreç olduğunu hatırlayın. OpenAI Evaluation Best Practices bu iteratif yaklaşımı ve görev-özgü metrik tasarımını özellikle vurgular.

Sonuç

Prompt başarısını ölçmek; KPI’ları görev hedefiyle hizalamak, otomatik değerlendirmeyi (kod tabanlı + LLM-yargıç) doğru yerde kullanmak ve human-in-the-loop ile güvenilirliği korumakla mümkün olur. Açık kaynak araçlar (ör. OpenAI Evals) bu süreci sistematikleştirir; ancak özellikle LLM-yargıç yaklaşımlarında kurum içi pilot ve insan doğrulaması, üretim kalitesi için belirleyicidir.

Not: Bu içerik genel bilgilendirme amaçlıdır. Hassas alanlarda (ör. sağlık, finans, hukuki yönlendirme) üretim öncesi kapsamlı risk değerlendirmesi ve kurumunuzun politika/uyum gereklilikleriyle birlikte ilerlemek gerekir.