Prompt performans ölçümü: KPI'lar, otomasyon ve rapor şablonu

Neden prompt performansını ölçmek gerekir?

Prompt engineering genellikle hızlı deneme-yanılma ile ilerler. Ancak ürünleşme aşamasında iki sorun ortaya çıkar: (1) kaliteyi tutarlı biçimde korumak (regresyonları erken yakalamak), (2) kaliteyi artırırken maliyet ve hız gibi operasyonel hedefleri yönetmek. Bu noktada “prompt performans ölçümü”, prompt değişikliklerini sistematik bir değerlendirme ve izleme döngüsüne bağlar.

Resmi değerlendirme rehberleri, değerlendirmeyi yalnızca geliştirme anında değil, üretimde de sürekli yürütmeyi önerir. Amaç, her değişiklikte ölçülebilir sinyaller üretmek ve kararları daha az sezgisel hâle getirmektir. Bu yaklaşım, “continuous evaluation” (sürekli değerlendirme) fikriyle özetlenir (OpenAI Evaluation best practices).

Kaynak notu: Sürekli değerlendirme ve eval türleri için OpenAI rehberi; metrik setleri, gözlemlenebilirlik ve A/B raporlama pratikleri için Oracle kılavuzu; prompt versiyonlama/deney iş akışları için Arize yazısı; otomatik prompt optimizasyonunda çok-metrik değerlendirme vurgusu için TAPO makalesi referans alınmıştır.

Ölçüm çerçevesi: KPI → SLI/SLO → eval → izleme

En pratik yaklaşım, metrikleri “iş hedefi” ile hizalayarak katmanlı kurmaktır:

• KPI (Key Performance Indicator): İşe etkisi olan üst seviye gösterge (ör. doğru yanıt oranı, kullanıcı onayı oranı).
• SLI (Service Level Indicator): Ölçülebilir teknik sinyal (ör. P95 gecikme, hata oranı, format uyumu).
• SLO (Service Level Objective): Hedef eşik (ör. P95 gecikme hedefi; format uyum oranı hedefi). Eşikler, kuruma ve kullanım senaryosuna göre tanımlanır.
• Eval: Dataset üzerinde tekrarlanabilir test koşumu (A/B karşılaştırmalar dahil).
• Üretim izleme: Gerçek trafikte sürüm bazlı metrik takibi ve uyarılar.

Bu yapı, hem değerlendirme (offline) hem izleme (online) için aynı dili konuşmanızı sağlar. Kurumsal gözlemlenebilirlik rehberleri, doğruluk/kalite, gecikme ve token maliyeti gibi metrikleri birlikte ele almayı ve raporlamayı özellikle vurgular (Oracle AI Agent Observability and Evaluation).

Prompt KPI’ları: Ne ölçmelisiniz?

“Tek bir doğru metrik” çoğu zaman yoktur. Bunun yerine, kullanım senaryonuza göre kalite + hız + maliyet + güvenilirlik dengesini kurarsınız. Aşağıdaki KPI’lar, pratikte en sık izlenen seti oluşturur (OpenAI; Oracle).

1) Doğruluk / doğruluk benzeri kalite ölçümleri

• Correctness (doğru yanıt oranı): Özellikle soru-cevap, sınıflandırma, bilgi çıkarımı gibi görevlerde kullanışlıdır.
• Rubrik puanı: “Gerekçe sundu mu?”, “Kaynağa bağlı kaldı mı?”, “İstenen formatta mı?” gibi kriterlerle puanlama. Rubrik, ekipler arası tutarlılığı artırır.
• Format uyumu oranı: JSON şeması, belirli başlık düzeni veya maddeli çıktı gibi format beklentilerinde kritik bir göstergedir.

Not: Kaliteyi 0–1 aralığına indirgemek çekici olsa da, rubrik ve değerlendirme yöntemi kötü tasarlanırsa yanlış sinyal üretebilir. Bu yüzden otomatik puanlamayı periyodik örneklem bazlı insan kontrolüyle doğrulamak iyi bir emniyet katmanıdır.

2) Kullanıcı memnuniyeti sinyalleri (ürün içi)

• Pozitif oy / onay oranı: “Bu yanıt yardımcı oldu mu?” gibi mikro geri bildirimler.
• Tekrar deneme oranı: Kullanıcı aynı soruyu farklı şekilde tekrar soruyorsa, ilk yanıtın yetersiz olduğuna işaret edebilir.
• Görev tamamlama: Kullanıcı akışının tamamlanma oranı (senaryoya bağlı olarak).

Bu metrikler çoğu zaman gecikmeli ve gürültülüdür; yine de üretim kararları için değerli bağlam sunar.

3) Gecikme (latency)

• Median / P95 / P99: Özellikle P95/P99, kullanıcı deneyimini etkileyen kuyruk ve ani artışları görünür kılar.
• İlk token süresi ve tamamlanma süresi: Streaming kullanan senaryolarda ayrıştırmak faydalıdır.

4) Token ve maliyet göstergeleri

• İstek başına token (girdi/çıktı ayrı izlenebilir)
• Başarılı istek başına maliyet: Hata ve tekrar denemeleri dahil etmek, gerçek maliyeti daha doğru yansıtır.

Kalite ile token maliyeti her zaman aynı yönde hareket etmez; bu nedenle “kalite artışı ↔ maliyet artışı” ilişkisini trade-off analiziyle izlemek gerekir (Oracle; OpenAI).

5) Güvenilirlik: hata ve istisna metrikleri

• Timeout oranı
• API hata oranı
• Boş/eksik çıktı oranı
• Format ihlali oranı (ör. parse edilemeyen JSON)

Dataset stratejisi: “Golden set” olmadan ölçüm zorlaşır

Değerlendirme kalitesi, dataset kalitesine bağlıdır. Birçok ekipte görev tanımı, kabul kriterleri ve “iyi yanıt” tanımı ürüne özgü olduğundan, ekipler genellikle kendi golden set’ini kurup sürümleyerek ilerler (OpenAI; Arize). Ayrıca akademik çalışmalar da metriklerin görevle ilişkilendirilmesi (task-referenced) ve çok-metrikli değerlendirme yaklaşımının önemini vurgular; bu da “tek, herkese uyan” bir değerlendirme setinin pratikte her senaryoyu kapsamayabileceğine işaret eder (TAPO (arXiv)).

Golden set nasıl oluşturulur?

1. Kapsamı tanımlayın: En kritik 3–5 görev türü (ör. e-posta taslağı, ürün karşılaştırma, kısa özet, müşteri destek yanıtı).
2. Dağılımı yakalayın: Kolay/orta/zor örnekler; kısa/uzun girdiler; farklı konu başlıkları.
3. Etiket stratejisi seçin:
   • Kesin doğru-yanlış mümkünse answer key
   • Değilse rubrik (0–2, 0–5 gibi) + açıklama alanı
4. Değişmezlik ve sürümleme: Dataset’i de prompt gibi sürümleyin. Yeni örnek eklerken “dataset v1.1” gibi bir değişiklik kaydı tutun.

Pratik ipucu: İki katmanlı set

• Smoke set (küçük): Her commit/PR’da hızlı koşum; format, temel kalite, bariz hataları yakalar.
• Regression set (büyük): Günlük/haftalık koşum; daha sağlam karşılaştırma sağlar.

Değerlendirme yöntemleri: otomatik, insan ve hibrit

Değerlendirmeyi ölçeklemek için otomatik puanlama sık kullanılır; ancak bazı görevlerde insan değerlendirmesi hâlâ “altın standart” referans rolünde kalır. Resmi rehberler, otomatik ölçümleri insan geri bildirimiyle destekleyen hibrit yaklaşımları önerir (OpenAI).

1) LLM-as-a-judge (LaaJ) ne zaman işe yarar?

LaaJ yaklaşımında ayrı bir model, çıktıyı rubriğe göre puanlar ve gerekçelendirir. Bu yöntem, özellikle “doğru tek cevap” olmayan yaratıcı/özetleme türü görevlerde ölçeklenebilirlik sağlar ve kurumsal değerlendirme kılavuzlarında yaygın bir seçenek olarak geçer (Oracle; OpenAI).

Mini-örnek: 0–2 puanlık rubrik (kopyala-uyarla)

Dikkat edilmesi gerekenler:

• Rubrik net olmalı: “İyi yazılmış” gibi muğlak maddeler yerine ölçülebilir kriterler koyun.
• Örneklem denetimi: Her rapor döneminde belirli sayıda örneği insan değerlendirip otomatik puanla uyumunu kontrol edin.
• Çapraz kontrol: Kritik kararlar için iki farklı judge veya farklı prompt ile judge çalıştırıp tutarlılık sinyali toplayın.

2) Kural tabanlı / deterministik testler

• JSON şemasına uyum
• Belirli anahtarların bulunması
• Regex ile format kontrolü

Bu testler “hızlı ve güvenilir” bir temel katman sağlar; tek başına kaliteyi temsil etmese de regresyon yakalamada etkilidir.

Mini-örnek: Format uyumu kontrolü (JSON)

Beklenen: Çıktı bir JSON obje olmalı ve answer (string) ile confidence (0–1 arası sayı) alanlarını içermeli.
Kontrol adımları: (1) JSON parse başarısızsa “format ihlali”. (2) answer yoksa “format ihlali”. (3) confidence yoksa veya 0–1 dışında ise “format ihlali”. (4) Her koşumda ihlal oranını % olarak raporlayın.

3) İnsan değerlendirmesi: ne zaman gerekli?

• Yüksek riskli içerik alanları
• Marka dili ve üslup tutarlılığı
• Edge-case yoğun senaryolar (çok dilli, çok bağlamlı)

İnsan değerlendirmesini bütçe dostu yapmak için, örneklemi akıllı seçmek (en çok trafik alan akışlar, en çok hata veren segmentler) genellikle daha etkilidir.

Deney tasarımı: A/B test, canary ve sürüm yönetimi

Prompt değişikliklerini “öncesi/sonrası” diye kıyaslamak, veri dağılımı değiştiğinde yanıltıcı olabilir. Bu nedenle trafik bölme (A/B) veya kontrollü dağıtım (canary) pratikte daha güvenilirdir. Prompt sürümlemeyi ve deneyleri birlikte ele alan iş akışları yaygındır (Arize) ve gözlemlenebilirlik rehberleri A/B koşumlarının metrik setleriyle raporlanmasını önerir (Oracle).

Önerilen minimal A/B akışı

1. Hipotez yazın: “Yeni prompt, format uyumunu artırırken doğrulukta düşüş yaratmayacak.”
2. Başarı kriterleri: Birincil metrik (ör. doğruluk) + koruma metrikleri (latency, token maliyeti, hata oranı).
3. Sürümleme: Prompt v12 → v13; değişiklik notu ekleyin (ne değişti, neden?).
4. A/B koşumu: Trafiği iki sürüme bölün veya küçük bir canary dilimiyle başlayın (oranlar ürün ve risk profiline göre belirlenir).
5. Karar: İyileşme netse yaygınlaştırın; değilse geri alın veya iterasyon planlayın.

İstatistik pratikleri (ekipler için anlaşılır tutarak)

• Mutlak fark ve göreli fark birlikte raporlanabilir (örn. +0.03 puan rubrik artışı).
• Segment kırılımı: En azından “uzun girdi / kısa girdi”, “en çok kullanılan 3 konu”, “yüksek trafikli endpoint” gibi segmentlerde bakın.
• Yeterli örnek: Çok küçük örneklemde sonuçlar oynak olur; karar vermeden önce veri hacmi ve dönemsellik göz önüne alın.

Otomasyon: sürekli değerlendirme ve üretim izleme nasıl kurulur?

Sürekli değerlendirme, her prompt değişikliğinde (veya düzenli aralıklarla) eval koşarak performansın geriye gitmesini erkenden yakalamayı hedefler (OpenAI). Bunu üretim izlemeyle birleştirdiğinizde, offline ve online sinyaller birlikte karar destek sistemine dönüşür.

Referans mimari (araçtan bağımsız)

1. Prompt registry: Prompt metni + versiyon + hedef görev + beklenen çıktı formatı + değişiklik notu.
2. Eval runner:
   • Smoke set: her değişiklikte
   • Regression set: gece/hafta
3. Scoring: kural tabanlı kontroller + LaaJ + (gerektiğinde) insan örneklemi.
4. Observability: Üretimde istek başına latency, token, hata; sürüme göre kırılım.
5. Alerting: SLO kırılımında uyarı (örn. format uyumu belirgin düşerse).
6. Release gate: Yeni prompt sürümü, belirlenen eşikleri geçmeden varsayılan sürüm olamaz.

Prompt yönetimini “kod gibi” ele almak, versiyonlama ve regresyon takibini kolaylaştırır (Arize).

Otomatik prompt optimizasyonu (APO) hakkında gerçekçi beklenti

Akademik çalışmalar, otomatik prompt optimizasyonunda görev-özgü metrik seçimi ve çok-metrikli değerlendirme modüllerinin önemine işaret eder (TAPO). Ancak bu tür yaklaşımların her iş senaryosunda aynı ölçüde fayda sağlayacağı garanti değildir. En sağlıklı yol, APO’yu “kontrollü pilot” olarak ele alıp A/B test ve işletme metrikleriyle doğrulamaktır.

Rapor şablonu: Prompt KPI raporunu standartlaştırın

Aşağıdaki şablon, haftalık veya sürüm bazlı raporlama için tasarlanmıştır. Amaç, karar almayı hızlandırmak ve ekip içinde ortak bir dil oluşturmaktır.

1) Yönetici özeti (1 paragraf)

• Hedef: (ör. “Format uyumu sorunlarını azaltmak”)
• Değişiklik: Prompt v12 → v13 (özet)
• Sonuç: Birincil metrik + koruma metrikleri
• Karar: Yayınla / geri al / iterasyon

2) Kapsam ve veri

• Eval dataset(ler)i: smoke vX, regression vY
• Üretim penceresi: (tarih aralığı)
• Segmentler: (ör. konu, dil, giriş uzunluğu)

3) KPI tablosu (örnek)

4) A/B sonuç özeti

• A/B yöntemi: trafik bölme mi, canary mi?
• Örneklem büyüklüğü: (kaba sayım)
• Etki: birincil metrikte değişim + koruma metrikleri
• Segment analizi: Hangi segment iyileşti/kötüleşti?

5) Regresyon kontrolleri

• En kötü 10 örnek (kalite düşüşü)
• Format hatası örnekleri
• Yeni ortaya çıkan hata türleri

6) Aksiyon listesi (sahip + tarih)

• Prompt iterasyonu: (ör. “çıktı formatını daha net belirt”)
• Dataset genişletme: (ör. “X segmentinden 30 yeni örnek ekle”)
• Gözlemlenebilirlik: (ör. “P95 latency uyarısı eşiğini güncelle”)

Hızlı başlangıç kontrol listesi (1 haftalık plan)

1. 1. gün: Kullanım senaryosunu seçin, 3–5 KPI belirleyin (birincil + koruma).
2. 2–3. gün: 50–200 örnekten oluşan ilk golden set’i hazırlayın; rubrik yazın.
3. 4. gün: Kural tabanlı format testlerini ekleyin; LaaJ puanlamayı pilotlayın.
4. 5. gün: Prompt v1 ve v2’yi eval runner ile karşılaştırın; raporu şablona dökün.
5. 6–7. gün: Üretimde sürüm etiketleme, latency/token/hata metriklerini sürüme göre görünür kılın.

Sınırlamalar ve iyi uygulamalar

• Eşikler bağlama bağlıdır: SLO hedefleri, sektör ve kullanıcı beklentisine göre değişir; hazır evrensel eşikler her zaman bulunmaz.
• Otomatik puanlama yanılabilir: Periyodik insan örneklemiyle doğrulama ve rubrik iyileştirme döngüsü kurun.
• Tek metriğe kilitlenmeyin: Kalite, hız ve maliyeti birlikte izleyin; aksi hâlde bir alan iyileşirken diğeri fark edilmeden bozulabilir.

Sonraki adım: ölçümü rutine bağlayın

En hızlı kazanım, küçük bir smoke set + net bir rubrik + format testleriyle “release gate” kurmaktır; ardından regression set ve üretim metrikleriyle bunu sürekli değerlendirmeye genişletebilirsiniz (OpenAI; Oracle). Bu sayfanın rapor şablonunu haftalık/sürüm bazlı standart hâline getirerek hem A/B kararlarını hızlandırır hem de geriye dönük öğrenmeyi kolaylaştırırsınız. Bir sonraki iterasyonda golden set’e “en kötü 10 örnek”ten yeni test vakaları ekleyip rubriği sıkılaştırmayı hedefleyin.

Daha derinlemesine yöntemler için değerlendirme ve gözlemlenebilirlik rehberlerine göz atabilirsiniz: OpenAI, Oracle, ayrıca prompt yönetimi iş akışları için Arize.