Model Güncellenince Promptlar Neden Bozulur?

Altı aydır sorunsuz çalışan bir promptunuz var. Bir sabah çıktılar tuhaflaşıyor — hata vermiyor, çökmüyor, sadece eskisi kadar iyi değil.

Promptta hiçbir şey değişmedi. Değişen şey altındaki zemin.

Bu, prompt üzerine kurulu her sistemin er ya da geç yaşadığı durum. Ve en can sıkıcı tarafı, bozulmanın gürültüsüz olması: sistem çalışmaya devam eder, kalite sessizce düşer.

Neyin değiştiği

Model güncellemesi tek bir şey değiştirmiyor. En az beş şey birden oynayabiliyor.

Talimat takip etme biçimi. Yeni sürüm bazı talimatları daha sıkı, bazılarını daha gevşek uygulayabilir. Eskiden ıskaladığı bir kuralı artık uyguluyorsa çıktı beklenmedik biçimde değişir — iyileşme yönünde bile olsa.

Varsayılan uzunluk ve ton. Belirtmediğiniz her özellikte model bir varsayılana kayar ve varsayılanlar sürümle değişir. → Belirsizlik: Promptunuzda Söylemediğiniz Her Şey Bir Karardır

Biçimlendirme alışkanlıkları. Madde işareti kullanımı, başlık ekleme eğilimi, cevabın başına açıklama koyma davranışı. Kod tarafında çıktı ayrıştıran sistemleri en çok bu bozar.

Kısıtlara duyarlılık. “En fazla 120 kelime” kuralına ne kadar sadık kalındığı sürümler arasında değişir.

Tokenizasyon ve bağlam davranışı. Aynı metin farklı sayıda parçaya bölünebilir; uzun promptlarda hangi bölümün ağırlık kazandığı değişebilir.

En kırılgan prompt türleri

Her prompt aynı derecede riskli değil. Şunlar önce bozulur:

En dayanıklı promptlar ise ortak bir özelliği paylaşıyor: ne istediklerini açıkça yazıyorlar. Modelin bir alışkanlığına güvenmiyorlar.

Bozulma neden fark edilmiyor?

Üç sebep bir arada çalışıyor.

Sessiz. Hata mesajı yok, sistem çalışmaya devam ediyor. Yalnızca kalite düşüyor.

Kademeli. Yüz çıktının üçü bozuksa kimse fark etmez. Ona çıktığında da “bugün kötü bir gün” denir.

Referans yok. Eski çıktıların kaydı yoksa karşılaştıracak bir şey yoktur. “Eskiden daha iyiydi” hissi ölçülemez.

Üçü birleşince bozulma haftalarca sürebiliyor. Bu, üretimdeki yapay zeka sistemlerinin genel bir sorunu. → 7.4.3.3^yakında

Bozulmayı yakalamak

Tek güvenilir yol var: elinizde bir değerlendirme seti olması. → Promptları Test Etme: \"Bana İyi Göründü\"yü Bırakmak

Set varsa iş basit. Model güncellendiğinde seti çalıştırırsınız, skoru eskisiyle karşılaştırırsınız, fark varsa nerede olduğunu görürsünüz.

Set yoksa elinizde yalnızca izlenim kalır — ve izlenim, bu iş için yeterli değil.

Pratik minimum, ölçekli bir sistem işletmiyorsanız bile uygulanabilir:

On örnek saklayın. Promptunuzun iyi çalıştığı on gerçek girdi ve o zamanki çıktıları. Bir metin dosyası yeterli.

Çeyrekte bir çalıştırın. Aynı on girdiyi tekrar geçirin, eski çıktılarla yan yana koyun.

Model değiştiğinde hemen çalıştırın. Sağlayıcı yeni sürüm duyurduğunda ilk iş bu.

Bozulduğunda ne yapmalı?

Sıra önemli, çünkü ilk refleks genellikle yanlış.

1. Bozulmanın türünü adlandırın. Uzunluk mu kaydı, format mı bozuldu, doğruluk mu düştü? Belirti bilinmeden düzeltme yapılamaz. → Prompt Yinelemesi: Beğenmediğiniz Çıktıdan Düzeltmeye Giden Yol

2. Örtük varsayımı bulun. Bozulan şey genellikle promptta yazılı olmayan bir beklentiydi. Model eskiden madde işareti kullanıyordu, siz bunu hiç yazmamıştınız. Şimdi yazın.

3. Tek şey değiştirin ve ölçün. Bozulmayı düzeltmek için beş şeyi birden değiştirmek, gelecekteki bozulmayı teşhis edilemez kılar.

4. Eski sürümü saklayın. Yeni model eski promptla kötü çalışıyorsa, eski model hâlâ erişilebilir olabilir. Sürüm geçmişi bu noktada işe yarar. → Prompt Sürümleme: Çalışan Promptu Kaybetmemek

5. Kaydedin. “Model X’e geçince format bozuldu, açıkça belirtildi” notu, bir sonraki güncellemede size zaman kazandırır.

Eski modele dönmek geçici bir çözümdür

Yukarıdaki dördüncü madde işe yarar ama kalıcı değil. Model sürümleri süresiz erişilebilir kalmıyor: bir sürüm bir gün emekliye ayrılır ve o gün geldiğinde geri dönecek yeriniz kalmaz.

Bu yüzden geri dönüşü bir çözüm değil, satın alınmış zaman olarak görmek gerekiyor. Eski modele döndüğünüz gün yapılacak iki şey var: dönüş sebebini yazmak ve promptu yeni modelde çalışır hâle getirmek için bir tarih belirlemek. Tarih koymazsanız geri dönüş kalıcı hâle gelir; kalıcı hâle geldiği için de kimse promptu düzeltmez ve emeklilik duyurusu geldiğinde acele bir iş çıkar.

Sebebi yazmanın ayrı bir faydası var. Aylar sonra promptu düzeltmeye oturduğunuzda, yeni modelde tam olarak neyin bozulduğunu hatırlamıyor olacaksınız. “Yeni modelde kötü çalışıyordu” bir kayıt değil; “yeni modelde çıktı JSON yerine açıklamayla başlıyordu” düzeltilebilir bir kayıttır. → Prompt Sürümleme: Çalışan Promptu Kaybetmemek

Somut örnek: sessizce kırılan bir zincir

Bir ekip, destek taleplerini sınıflandırıp yönlendiren bir prompt kullanıyor. Çıktı kod tarafından okunuyor:

Kategori: Kargo
Aciliyet: Yüksek
Özet: Üç gündür hareket yok

Prompt bu formatı istiyor ama bir şey belirtmiyor: alanların sırasını. Model altı aydır bu sırayla döndürdüğü için kimse fark etmemiş.

Model güncelleniyor. Yeni sürüm aynı alanları farklı sırayla döndürmeye başlıyor — bazen Özet en başta. Kod ilk satırdan kategoriyi okuduğu için artık kategori yerine özet metnini kategori sanıyor.

Sonuç: sistem çalışıyor, hata vermiyor, ama talepler yanlış ekiplere gidiyor. Fark edilmesi iki hafta sürüyor ve fark edilme sebebi teknik değil — bir ekip “bize alakasız talepler geliyor” diye şikâyet ediyor.

Kök neden: Promptta yazılı olmayan bir beklenti vardı. Sıra bir varsayımdı, kural değildi.

Düzeltme: Alan sırasını açıkça yazmak ve kodun sıraya değil alan adına bakması. İkisi birlikte yapılınca aynı bozulma bir daha mümkün olmuyor.

Bu örnek genel kalıbı gösteriyor: bozulan şey neredeyse hiç promptta yazan bir şey olmuyor. Yazılmayan varsayımlar kırılıyor.

Taşınabilir prompt yazmak

Bozulmayı tamamen önleyemezsiniz ama etkisini azaltabilirsiniz. Dört kural:

Örtük hiçbir şey bırakmayın. Modelin alışkanlığına güvendiğiniz her nokta bir kırılganlık. Format istiyorsanız yazın, uzunluk istiyorsanız sayı verin.

Kanıtsız taktikleri temizleyin. Etkisi ölçülmemiş eklentiler ilk bozulanlar. Ayrıca bozulduklarında fark edilmezler, çünkü zaten ne yaptıkları belirsizdi. → Prompt Mitleri: Bahşiş Vaadi, Tehdit ve Diğer Kanıtsız Taktikler

Kısıt sayısını azaltın. Az sayıda ve net kısıt, uzun listelere göre sürümler arasında daha kararlı davranır. → Prompt Ne Kadar Uzun Olmalı? Ayrıntının Ters Tepmeye Başladığı Nokta

Kritik olanı kodla garanti altına alın. Format kesinliği gerekiyorsa prompta güvenmeyin; şema zorlayın ve çıktıyı doğrulayın. → Çıktı Formatını Zorlamak: Talimat Yeter mi, Şema mı Gerekir?

Dördü de aynı ilkeye çıkıyor: modelin davranışına değil, kendi talimatınıza dayanın.

Model geçişini planlamak

Yeni bir model sürümüne geçmek, promptu kopyalayıp yapıştırmaktan ibaret değil. Sırayla yapıldığında sürpriz çıkmıyor.

Önce ölçün, sonra geçin. Yeni modeli mevcut promptunuzla ve mevcut değerlendirme setinizle çalıştırın. Skor eskisiyle karşılaştırılabilir olmalı. Bu tek adım, geçişin en riskli kısmını ortadan kaldırıyor. → Promptları Test Etme: \"Bana İyi Göründü\"yü Bırakmak

Farkı nerede olduğunu bulun. Toplam skor aynı kalsa bile alt kırılımlara bakın. Bazı girdi türlerinde iyileşip bazılarında kötüleşmiş olabilir; ortalama bunu gizler. Özellikle sınır durumlarına ve tuzaklı girdilere bakın.

Promptu yeni modele göre sadeleştirin. Yeni sürüm bazı şeyleri kendiliğinden yapıyorsa, onları anlatan satırlar artık gereksizdir. Model geçişi, promptu ayıklamak için doğal bir fırsat. → Prompt Ne Kadar Uzun Olmalı? Ayrıntının Ters Tepmeye Başladığı Nokta

İki modeli bir süre yan yana çalıştırın. Mümkünse üretimde bir süre her iki modele de gönderip çıktıları karşılaştırın. Değerlendirme setinin yakalayamadığı farklar burada görünür.

Geri dönüş yolunu açık tutun. Yeni model beklenmedik biçimde kötüyse eskisine dönebilmelisiniz. Bu, eski prompt sürümünü de saklamayı gerektiriyor. → Prompt Sürümleme: Çalışan Promptu Kaybetmemek

Sürüm sabitleme kararı

Bazı sağlayıcılar belirli bir model sürümünü sabitlemenize izin veriyor. Bu, kısa vadede istikrar sağlıyor ama bir bedeli var.

Sabitlenmiş sürüm bir gün kaldırılır ve o gün geldiğinde birikmiş tüm farkı bir seferde karşılamak zorunda kalırsınız. Aylarca ertelenen geçiş, tek seferde yapılınca daha büyük bir kırılma üretir.

Pratik denge: kritik sistemlerde sürümü sabitleyin ama düzenli olarak yeni sürümü de test edin. Geçmeseniz bile farkı biliyor olun. Geçiş zorunlu hâle geldiğinde neyle karşılaşacağınızı önceden bilmiş olursunuz.

Sınırlar

Her değişiklik bozulma değil. Yeni sürüm çıktıyı iyileştirmiş de olabilir. Ölçmeden “bozuldu” demeyin.

Bazı bozulmalar düzeltilemez. Model bir yeteneğini kaybettiyse prompt bunu geri getirmez.

Sürüm sabitlemek geçici çözüm. Eski modelde kalmak kısa vadede işe yarar ama o sürüm de bir gün kaldırılır.

Bu yazı bir takvim vermiyor. Güncellemelerin sıklığı ve etkisi sağlayıcıya göre değişir; kendi sisteminizde gözlemleyerek öğrenirsiniz.

Bozulma sadece kötüye gitmek değil

Bir güncelleme çıktıyı iyileştirmiş de olabilir ve bu da bir değişikliktir. Yeni sürüm daha ayrıntılı yazmaya başladıysa, bu kalite artışı gibi görünür ama sizin 120 kelimelik alanınıza sığmıyorsa yine bir bozulmadır.

Ölçüt “daha iyi mi” değil, “benim kabul kriterimi hâlâ karşılıyor mu” olmalı. Bu ayrım, model karşılaştırmalarında sık atlanıyor: genel olarak daha iyi bir model, sizin özel işiniz için daha kötü olabilir.

Özet

Model güncellemesi promptunuzu değiştirmez, altındaki zemini değiştirir: talimat takibi, varsayılan uzunluk ve ton, biçimlendirme alışkanlıkları, kısıtlara duyarlılık.

Bozulma sessiz, kademeli ve referanssızdır — bu yüzden haftalarca fark edilmez.

Yakalamanın tek yolu bir değerlendirme setidir. Ölçekli bir sistem işletmiyorsanız bile on gerçek girdi ve o zamanki çıktıları saklamak, çeyrekte bir karşılaştırmak için yeterlidir.

Taşınabilir prompt yazmanın özü tek cümlede: modelin alışkanlığına değil, kendi talimatınıza dayanın. Promptta yazılı olmayan her beklenti bir kırılganlıktır.

Sık sorulanlar

İlgili yazılar