Prompt Sapması (Prompt Drift)

Prompt sapması (prompt drift), promptun metni değiştirilmemiş olsa bile, bir promptun gerçek dünyadaki çıktı kalitesinde veya tutarlılığında zamanla meydana gelen kademeli değişimi — genellikle bozulmayı, ama bazen sadece beklenmedik davranış değişikliğini — ifade eder; bu en yaygın şekilde promptun dışındaki bir değişiklikten kaynaklanır: model sağlayıcısının bir API uç noktasının arkasındaki model sürümünü sessizce güncellemesi veya kullanımdan kaldırması, promptun artık aldığı girdilerin gerçek dünya dağılımındaki kaymalar (geçen yılın yaygın bilet türlerine göre ayarlanmış bir destek bileti sınıflandırma promptunun bu yılın farklı sorun karışımıyla karşılaşması) veya bir promptun orijinal tasarımının hiç öngörmediği uç durumların ve olağandışı girdilerin birikmesi. Bu, kasıtlı bir prompt versiyonlama değişikliğinden (izlenen, kasıtlı bir düzenleme) farklı bir hata modudur — prompt sapması genellikle doğruluk metrikleri veya kullanıcı şikayetleri bir şeylerin bozulduğunu ortaya çıkarana kadar görünmezdir, bu da onu zaman içinde yapay zeka özelliği kalitesini aktif olarak izlemeyen herhangi bir ekip için gerçek bir üretim güvenilirlik riski yapar. Model sağlayıcının neden olduğu sapma, bu sorunun özellikle önemli ve yeterince takdir edilmeyen bir versiyonudur: sağlayıcılar aynı API model tanımlayıcısının arkasındaki modelleri periyodik olarak günceller (veya eski sürümleri bir zaman çizelgesinde kullanımdan kaldırır) ve bir model sürümüne karşı dikkatlice ayarlanmış ve değerlendirilmiş bir prompt, uygulamanın prompt kodunun tek bir karakteri bile dokunulmamış olsa da, alttaki model değiştiğinde anlamlı şekilde farklı davranabilir — bazen daha iyi, bazen daha kötü, bazen sadece belirli bir format tuhaflığını bekleyen bir alt akış ayrıştırıcısını bozacak şekilde farklı. Prompt sapmasına karşı savunma, tek seferlik değil, sürekli bir değerlendirme pratiği gerektirir: prompt testi değerlendirme setini yinelenen bir programda (yalnızca ilk lansmanda değil) yeniden çalıştırmak, tekrarlanabilirliğin önemli olduğu durumlarda "en son" takma adı yerine belirli model sürümlerine sabitlemek ve yeni bir model sürümünü benimsemeden önce bilinçli olarak yeniden değerlendirmek, gerçek üretim çıktı kalitesi sinyallerini zaman içinde izlemek (kullanıcı geri bildirimi/şikayet oranları, alt akış ayrıştırma hata oranları, örneklenen insan incelemesi) ve bir model sürümü yükseltmesini kasıtlı bir prompt sürümü değişikliğiyle aynı değerlendirme titizliğiyle ele almak — çünkü kalite güvence perspektifinden bu ikisi işlevsel olarak benzer risklerdir. Somut örnek: aynı düzenlenmemiş promptta aylarca istikrarlı olan bir yapay zeka içerik denetleme özelliğinin sınıflandırma doğruluğu, alttaki model sağlayıcısı sabitlenmiş model sürümünü kullanımdan kaldırıp trafiği otomatik olarak daha yeni bir varsayılana taşıdıktan sonra beklenmedik şekilde düşer — yeni model, belirsiz bir kategori sınırını eskisinden biraz farklı yorumlar ve prompt değişmediği için ekip başlangıçta model sürümü günlüklerini kontrol edip düşüşü göç tarihiyle tam olarak ilişkilendirene kadar doğruluk düşüşünü açıklamakta zorlanır. Çözüm — değerlendirme setlerini yeni model sürümüne karşı yeniden çalıştırmak ve az-örnekli (few-shot) promptlarındaki birkaç kategori sınırı örneğini yeniden hizalamak için ayarlamak — doğruluğu geri kazandırır, ancak altta yatan ders bir süreç değişikliğini tetikler: sessiz "en son" otomatik yükseltmelerini kabul etmek yerine model sürümlerini açıkça sabitlemek ve herhangi bir sürüm göçünden önce yeniden değerlendirmek.