Prompt Test ve İyileştirme: Sezgiden Sistematik Yönteme

Prompt neden test edilmelidir?

Bir prompt'u birkaç denemede iyi çalıştığını görüp kullanıma almak, sık yapılan ve pahalıya mal olan bir hatadır. Üretken modellerin yanıtları aynı girdide bile değişebilir; ayrıca bir cümlenin eklenmesi ya da çıkarılması, beklenmedik başka bir yerde kaliteyi bozabilir. Prompt'u yazılım gibi test etmek, bu değişkenliği yönetmenin yoludur.

Test kültürü olmayan ekiplerde tipik tablo şudur: biri prompt'u “biraz” değiştirir, ilk örneklerde daha iyi görünür, değişiklik kalıcı olur; birkaç hafta sonra farklı bir girdi tipinde sorunlar çıkar ve kimse hangi değişikliğin nedeni olduğunu bilmez. Sistematik test, hangi değişikliğin neyi iyileştirdiğini ya da bozduğunu gösteren kanıt üretir.

Adım adım: test setini kurmak

Test, bir girdi listesinden başlar. Gerçek kullanımdan örnek topla ve şu türlerden vaka ekle: tipik girdiler, uç vakalar (çok kısa, çok uzun, eksik bilgili, yazım hatalı) ve geçmişte hata yaptırdığı bilinen girdiler. Test seti, prompt'un karşılaşacağı çeşitliliği temsil etmelidir; yalnızca temiz örnekler seti anlamsız hale getirir.

Her girdi için beklenen çıktıyı ya da çıktıdan beklenen özellikleri yaz. Sınıflandırma gibi işlerde beklenen etiket bellidir. Özetleme ya da metin üretiminde ise ölçütler yazılır: gerekli bilgilerin hepsi yer alıyor mu, ton uygun mu, uzunluk sınırı aşılıyor mu, yasak ifadeler var mı?

Test setini prompt'u yazarken kullandığın örneklerden ayrı tut. Few-shot örneği olarak verdiğin vakayı test setinde de kullanırsan, başarı olduğundan yüksek görünür. Setin makul bir büyüklükte kalması, her denemede elle incelemeyi mümkün kılar; büyüdükçe otomatik denetim yöntemleri devreye girer.

Ölçüt belirleme: iyi çıktı neye benzer?

İyileştirme ancak “iyi”nin tanımı varsa yapılabilir. Çıktıları şu boyutlarda değerlendir: • Doğruluk: bilgi ve etiket doğru mu, uydurma var mı? • Tamlık: istenen unsurların hepsi var mı? • Biçim: istenen yapıya (JSON, madde listesi, başlıklar) uyuyor mu? • Ton ve üslup: marka ya da muhataba uygun mu? • Güvenlik ve uyum: yasaklı içerik, kişisel veri, iddia var mı?

Her boyut için basit bir puanlama düzeni kur: geçti, kaldı ya da kısmen. Çok ayrıntılı puan ölçekleri, farklı değerlendiricilerin tutarsız puan vermesine yol açar. Birden fazla kişi değerlendirecekse, önce birkaç çıktıyı birlikte puanlayıp ölçütlerin aynı şekilde yorumlandığından emin olmak gerekir.

Biçim gibi nesnel ölçütler programla otomatik denetlenebilir; örneğin çıktının geçerli bir JSON olup olmadığı bir betikle kontrol edilir. Ton ve doğruluk gibi öznel ölçütler ise insan gözü ister. Bir modelin başka bir modelin çıktısını değerlendirdiği yaklaşımlar da vardır; ancak bunları kullanırken değerlendirici modelin kendi hatalarının farkında olmak ve insan örneklemesiyle doğrulamak gerekir.

Tek değişkenle iyileştirme döngüsü

İyileştirme döngüsü kısa ve disiplinlidir: test setini çalıştır, hata kalıplarını gruplandır, bir hipotez kur, tek bir değişiklik yap, setin tamamını yeniden çalıştır, sonucu kaydet. Aynı anda birden fazla şeyi değiştirirsen hangisinin işe yaradığını bilemezsin.

Hata kalıplarına göre müdahale türü değişir. Biçim bozuluyorsa çıktı yapısını daha net tarif et ya da örnek ekle. Model bilgi uyduruyorsa “yalnızca verilen metne dayan, bilgi yoksa bilmiyorum de” kuralı ve gerekli bağlam eklenir. Ton tutmuyorsa rol ve muhatap tanımı netleştirilir. Mantık hataları varsa adım adım akıl yürütme istenir. Çıktı gereksiz uzunsa uzunluk sınırı ve hedef okuyucu belirtilir.

En önemli kural, değişikliğin başka vakaları bozmadığını kontrol etmektir. Bir hatayı gidermek için eklenen cümle, daha önce geçen başka bir vakayı kırabilir. Bu yüzden her değişiklikten sonra test setinin tamamı yeniden değerlendirilir; yalnızca düzeltilen vaka değil. Prompt'u gereğinden fazla yamalanmış bir kural yığınına çevirmemek için aynı işi yapan cümleleri zaman zaman sadeleştir.

Örnek senaryo: toplantı notlarından aksiyon listesi

Örneğin bir proje ekibi, toplantı notlarından aksiyon maddelerini çıkaran bir prompt kullanıyor. İlk sürümde model bazen karar maddelerini aksiyon sanıyor, bazen sorumlu kişiyi uyduruyor. Ekip, gerçek notlardan oluşan bir test seti hazırlar: net aksiyonlu notlar, hiç aksiyon içermeyen notlar, sorumlusu belirsiz maddeler.

İlk koşuda hata kalıpları ortaya çıkar: sorumlu belli değilken uydurma isim yazılıyor. Hipotez: model boşluğu doldurmaya çalışıyor. Değişiklik: “Sorumlu açıkça belirtilmemişse ‘belirtilmemiş’ yaz” kuralı eklenir. Test seti yeniden koşulur; uydurma isimler azalmıştır, ancak şimdi bazı aksiyonlar tamamen atlanıyor. Ekip bu yan etkiyi görür ve kuralı daha dar ifade eder, ardından sonuçları sürüm notuyla kaydeder.

Bu döngünün değeri, değişikliğin gerçek etkisini hem iyi hem kötü yönüyle göstermesidir. Tek örneğe bakarak karar verilseydi diğer sorun fark edilmeyecekti.

Kayıt, sürüm ve sahaya çıkış

Her prompt değişikliği için kısa bir kayıt tut: ne değişti, neden, test sonucu ne oldu. Sürüm numarası ya da tarih yeterlidir; önemli olan geri dönebilmektir. Bir değişiklik kötü sonuç verirse bir önceki sürüme dönmek dakikalar almalıdır.

Sahaya çıkarken küçük bir kullanıcı grubuyla başlamak ve gerçek kullanımdan gelen hatalı çıktıları test setine eklemek, test setini zamanla zenginleştirir. Model ya da araç güncellemeleri sonrasında setin yeniden koşulması, sessiz bozulmaları yakalar. Hassas işlerde (hukuk, finans, sağlık, işe alım) otomatik testlerin yanında periyodik insan incelemesi de sürdürülmelidir.

Ekip düzeyinde test setleri ve kayıtlar prompt kütüphanesiyle birlikte tutulduğunda, yeni gelen kişi bir şablonun neden bu şekilde yazıldığını geçmiş notlardan öğrenebilir.

Prompt test ve iyileştirmeyi Mindset programlarında nerede çalışırsınız?

“Prompt Mühendisliği: Kurumsal Verimlilik Programı” içinde Prompt Optimizasyonu ve Kalite Kontrolü modül başlığı bu konuyu doğrudan hedefler; Gelişmiş Prompt Teknikleri ve Kurumsal Prompt Kütüphanesi ve Kapanış Projesi başlıkları ise test edilen şablonların ekip kullanımına nasıl taşınacağıyla ilgilidir.

“Prompt Engineer Programı”nda Model Bazlı İstem Optimizasyonu, RAG ile İstem Entegrasyonu, İstem Güvenliği ve Yönetim Çerçevesi ve İstem Mühendisliği Proje Atölyesi başlıkları, test ve iyileştirmeyi uygulama geliştirme bağlamında ele almak isteyen teknik roller için uygundur.