Bir promptun ilk sürümü bir taslaktır. Çoğu zaman sana istediğine yakın bir şey getirir ve yakın ile doğru arasındaki boşluk yineleyerek kapanır: promptu bilerek değiştirmek, aynı girdiyle yeniden çalıştırmak ve değişikliğin işe yarayıp yaramadığını kontrol etmek. Özensizce yapıldığında yineleme, şanslı bir çıktı iyi görünene kadar rastgele yeniden ifade etmeye dönüşür. Küçük bir deney olarak yapıldığında ise sana sadece test ettiğin girdide değil, sonraki yüz girdide çalışan bir prompt verir.
Yöntemin beş adımı var: iyinin neye benzediğini tanımla, sabit test girdileri tut, her seferinde tek bir şeyi değiştir, çıktıları karşılaştır ve ne zaman duracağını bil.
İyi bir cevabın neye benzediğini tanımla
Herhangi bir şeyi düzenlemeden önce çıktının ne yapması gerektiğini evet ya da hayır diye cevaplayabileceğin kontroller olarak yaz. "İyi bir commit mesajı" kontrol edilemez. Bunlar edilebilir:
- Konu satırı 50 karakterden kısa.
- Conventional Commits biçimine uyuyor (
fix:,feat:ve benzerleri). - Gövde, diff'in zaten gösterdiğini değil, değişikliğin neden gerektiğini söylüyor.
- Varsa issue numarasından bahsediyor.
Kriterler iki iş görür. Prompta ne ekleyeceğini söylerler, çünkü her biri çoğu zaman eksik bir talimattır. Ve çıktıları ne kadar hoş göründüklerine göre değerlendirmeni engellerler; bu, kendinden emin ama yanlış bir cevabı kabul etmenin en kolay yoludur.
Küçük bir test girdisi seti tut
Üç ile on arası girdi seç ve çalışırken onları sabit tut. Tipik durumları, birkaç zorlu durumu (boş bir alan, çok uzun bir girdi, promptun beklemediği bir dil) ve daha önce başarısız olmuş her girdiyi dahil et. Tek bir örnek üzerinde ayarlanmış bir prompt o örneğe uyup bir sonrakinde başarısız olmaya eğilimlidir.
Promptu girdi için bir boşluğu olan bir şablon olarak yaz, böylece her sürüm tam olarak aynı malzeme üzerinde çalışır.
Her seferinde tek bir şeyi değiştir
Rolü, biçimi ve örnekleri birlikte değiştirdiğinde çıktı iyileşirse bunu hangi değişikliğin yaptığını bilemezsin ve iki işe yaramaz düzenlemeyi tutuyor olabilirsin. Tek bir şeyi değiştir, çalıştır, karşılaştır. Aşağıdaki sekmeler tek bir promptun üç sürümü; her biri bir öncekinden tek bir değişiklikle ayrılıyor.
- if len(password) > 8:
+ if len(password) >= 8:
return True
Şifre uzunluğu doğrulamasını güncelle
Bu commit, karşılaştırma operatörünü >'den >='ye değiştirerek şifre doğrulama mantığını günceller. Sonuç olarak tam 8 karakter uzunluğundaki şifreler artık geçerli sayılacak. Bu değişiklik doğrulamanın doğruluğunu artırır ve hesap oluşturan kullanıcılar için daha iyi bir deneyim sağlar.
- sürüm 2. ve 3. kriterlerde başarısız: konuda tür öneki yok ve gövde diff'i daha fazla kelimeyle yeniden anlatıyor. 2. sürüm biçim gereksinimlerini ekliyor ve 1. ve 2. kriterleri geçiyor, ama gövdesi hâlâ diff'i tarif ediyor. Akla gelen sıradaki düzenleme başka bir talimattır ("nedenini açıkla"), ama model kendisine hiç verilmemiş bir nedeni açıklayamaz. 3. sürüm onun yerine eksik bağlamı ekliyor ve gövde ile issue referansı istenmeden geliyor. Yinelemenin en yaygın dersi budur: bir talimat bir çıktıyı düzeltmiyorsa promptta genellikle eksik olan vurgu değil, bilgidir.
Çıktıları yan yana karşılaştır
Her sürümü her test girdisinde çalıştır ve her birini birden fazla kez çalıştır, çünkü sohbet modelleri kelimelerini örnekler ve aynı promptun iki denemesi farklı çıkar. Çıktıları yan yana koy ve onları son denemenin hatırasıyla değil, kriterlerinle karşılaştır.
Net kriterlerde puanlamanın ilk turunu ikinci bir model çağrısı yapabilir. Çıktıları kriterleri açıkça yazılmış bir puanlama promptuna yapıştır:
| Kriter | Çıktı A | Çıktı B |
|---|---|---|
| 1. Konu 50 karakterden kısa | Geçti: konu 41 karakter | Geçti: aynı konu, 41 karakter |
| 2. Conventional Commits | Geçti: "fix:" ile başlıyor | Geçti: "fix:" ile başlıyor |
| 3. Gövde nedenini açıklıyor | Kaldı: "Uzunluk kontrolünü > işaretinden >= işaretine değiştir" diff'i yeniden anlatıyor | Geçti: "talimatlara uyan kullanıcılar kayıt olamıyordu" |
| 4. Issue'dan bahsediyor | Kaldı: issue numarası yok | Geçti: "Fixes #412" |
Bir model puanlayıcıyı hakem değil, yardımcı olarak gör. Zheng ve arkadaşlarının 2023 tarihli "Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena" makalesi, model hakemlerinde daha uzun cevapları ve belirli bir konumdaki cevabı tercih etmek dahil yanlılıklar belgeledi. Kriterleri kontrol edilebilir tut, alıntılanmış kanıt iste, ikisini karşılaştırırken A ile B'nin sırasını değiştir ve çıktılardan bir örneği kendin oku. Karakter sayımı gibi kontroller bir modelin yargısı olarak değil, bir satır kod olarak daha güvenilirdir.
Sohbeti değil, promptu düzelt
Bir sohbette cevabı takip mesajlarıyla düzeltmek caziptir: "daha kısa", "hayır, issue'dan bahset", "diğer biçimi kullan". Bu sana iyi bir çıktı getirir ve promptu olduğu kadar kötü bırakır. Bir düzeltme işe yaradığında onu prompta taşı ve promptu sıfırdan çalıştır. Sonuca bir dahaki ihtiyacında beş mesajı tekrarlamak yerine tek bir mesaj yapıştırırsın.
Eski sürümleri neyin değiştiğini ve neyi düzelttiğini anlatan tek satırlık bir notla sakla. Düz bir metin dosyası yeterli. Sonraki bir düzenleme işleri kötüleştirdiğinde promptun eskiden ne dediğini hatırlamaya çalışmak yerine geri dönebilirsin.
Kodda bir karşılaştırma çalıştırmak
Bir prompt bir API üzerinden çalıştığında kısa bir script her sürüm ve her test girdisi için yan yana görünümü üretebilir. Bu script OpenAI Python SDK'sını kullanıyor ve baştan sona okuyabileceğin bir markdown dosyası yazıyor.
from openai import OpenAI
client = OpenAI()
MODEL = "your-model-id" # e.g. from your provider's model list
# each prompt file contains {input} where the test diff goes
PROMPTS = {
"v2": open("prompts/commit_v2.txt").read(),
"v3": open("prompts/commit_v3.txt").read(),
}
TESTS = [open(f"tests/diff_{i}.txt").read() for i in range(1, 6)]
with open("results.md", "w") as out:
for i, test in enumerate(TESTS, 1):
out.write(f"## Test {i}\n\n")
for name, template in PROMPTS.items():
for run in (1, 2):
response = client.chat.completions.create(
model=MODEL,
messages=[{"role": "user", "content": template.replace("{input}", test)}],
)
out.write(f"### {name}, run {run}\n\n{response.choices[0].message.content}\n\n")
Ne zaman durmalı
Birkaç denemede her test girdisinde her kriter geçtiğinde dur. Ondan sonra eklenenler çoğunlukla uzunluk ekler ve her ek talimat diğerleriyle çelişebilecek bir şey daha demektir.
Değişiklikler hataları takas etmeye başladığında da dur: bir düzenleme 2. testi düzeltip 4. testi bozar, bir sonraki bunu tersine çevirir. Bu kalıp, prompttan tek bir talimatın sabitleyemeyeceği bir şey istendiği anlamına gelir. Olağan çıkış yolları şunlardır: biçimi birkaç örnekle göstermek (few-shot prompting), işi prompt zincirlemeyle adımlara bölmek ya da karakter saymak veya bir biçimi kontrol etmek gibi deterministik kısımları çıktıyı kontrol eden koda taşımak. Fikir bulmakta takıldıysan meta prompting yardımcı olabilir: bir modele promptu, girdiyi ve kötü çıktıyı ver ve promptun hangi kısmının buna büyük ihtimalle yol açtığını sor.
Sıkça Sorulan Sorular
Kötü cevaplar veren bir promptu nasıl iyileştiririm?
Kötü cevaba bak ve neyin yanlış olduğunu adlandır: yanlış biçim, eksik bilgi, yanlış okur kitlesi, fazla uzunluk. Sonra promptun bunu önleyecek neyi söylemediğini bul, o tek şeyi ekle ve yeni sürümü aynı girdiyle çalıştır. Kötü cevaplar ifadeden çok eksik bağlamdan ya da eksik bir biçim talimatından gelir.
Bir promptu test etmek için kaç test girdisine ihtiyacım var?
Tekrar kullanacağın bir prompt için genellikle üç ile on arası yeterlidir: birkaç tipik durum, bir iki uç durum (çok kısa, çok uzun, alışılmadık) ve daha önce yanlış gitmiş bir girdi. Yineleme yaparken onları sabit tut, böylece çıktıdaki bir değişiklik farklı bir girdiden değil, prompttan gelir.
Aynı promptu tekrar çalıştırdığımda neden farklı bir cevap alıyorum?
Sohbet modelleri her kelimeyi bir olasılık dağılımından örnekler, bu yüzden çıktılar denemeler arasında değişir. İki prompt sürümünü karşılaştırırken her birini aynı girdilerle birden fazla kez çalıştır. Her denemede görünen bir fark muhtemelen gerçektir; tek bir denemede görünen bir fark tesadüf olabilir. Bir API üzerinden değişkenliği azaltmak için temperature değerini de düşürebilirsin.
Promptumun çıktılarını puanlamak için yapay zekâ kullanabilir miyim?
Evet, "gövde değişikliğin neden gerektiğini söylüyor" ya da "issue numarasından bahsediyor" gibi net olarak ifade edebildiğin kriterler için. Puanlayıcıya tam kriterlerini ver ve her kriter için kanıt olarak bir alıntıyla geçti ya da kaldı iste. Model puanlayıcıların bilinen yanlılıkları var; daha uzun cevapları ve bir konumu diğerine tercih etmek dahil. Bu yüzden bazı çıktıları kendin oku ve ikisini karşılaştırırken sırayı değiştir.
Bir promptu iyileştirmeyi ne zaman bırakmalıyım?
Birkaç denemede her test girdisinde her kriter geçtiğinde ya da her yeni değişiklik bir durumu düzeltip başka birini bozduğunda bırak. O noktada sorun genellikle prompt değildir: görevin örneklere, adımlara bölünmeye ya da kodda bir kontrole ihtiyacı olabilir.
