Prompt Sürümleme: Talimatlarda Değişiklik Yönetimi

Prompt sürümleme neden gerekir?

Sistem talimatı modelin rolünü, sınırlarını ve yanıt biçimini tanımlar. Yazılımda bir hata çoğunlukla belirgin bir sonuç doğurur. Talimatta ise etki dolaylıdır. Yanıtları kısaltmak için eklenen bir cümle güvenlik uyarılarını da atlatabilir. Daha yardımsever olsun diye yumuşatılan bir ifade, reddedilmesi gereken istekleri kabul ettirebilir.

İkinci neden sahipliktir. Ürün, destek, pazarlama ve mühendislik ekiplerinin her biri talimatı değiştirmek ister. Kontrolsüz düzenleme çakışan değişikliklere ve kimsenin sorumlu olmadığı bir metne yol açar.

Üçüncü neden, talimatın neyi taşıyıp neyi taşımaması gerektiğidir. OWASP LLM08:2026 (Hidden Context Exposure (2025 sürümündeki adıyla System Prompt Leakage)) sistem isteminin bir sır sayılmaması ve güvenlik kontrolü olarak kullanılmaması gerektiğini söyler. Kimlik bilgisi, veritabanı adı gibi hassas veriler talimata yazılmaz. Yetki ayrımı ve yetkilendirme kontrolleri modelin dışında uygulanır. Talimat sızdırma vektörleri ve savunma kalıpları için sistem promptu sızdırma yazısına bakın. Sürümleme bu açıdan da yararlıdır: hangi sürümde hangi bilginin bulunduğu bellidir ve sızıntı sonrası etki değerlendirmesi hızlı yapılır.

Talimat kod gibi nasıl sürümlenir?

Talimatı depoda ayrı bir dosya olarak tutun, her değişikliği birleştirme isteğiyle yapın ve çalışma anında hangi sürümün kullanıldığını kayda geçirin. Böylece her yanıtın hangi talimatla üretildiği izlenebilir.

1. Talimatı sürüm kontrol sistemindeki bir dosyada tutun, yönetim arayüzünde serbest metin olarak bırakmayın.
2. Her değişiklik için birleştirme isteği açın, en az bir kişi gözden geçirsin.
3. Anlamlı bir sürüm numarası verin. Yazım düzeltmesi, davranış değişikliği ve güvenlik sınırı değişikliği farklı düzeylerde işaretlensin.
4. Uygulamanın hangi talimat sürümüyle çalışacağını yapılandırmadan seçilebilir yapın.
5. Her model yanıtının kaydına talimat sürümünü ve model kimliğini ekleyin.

Örnek bir sürüm dosyası şöyle görünebilir:

talimat: destek-asistani
surum: 3.2.0
model: claude-sonnet-5
parcalar:
  rol: [email protected]
  guvenlik_kurallari: [email protected]
  urun_bilgisi: [email protected]
degerlendirme_kumesi: eval/destek@14
onaylayan: guvenlik-ekibi

Yönetilen prompt hizmetleri de bu yöne evriliyor. OpenAI, Responses API'deki yeniden kullanılabilir prompt nesnelerini kullanımdan kaldırıyor. Belgelerine göre v1/prompts uç noktası 30 Kasım 2026'da kapanacak. Önerilen geçiş, talimat metnini uygulama koduna taşımak ve sürümlemeyi kendi deponuzda commit, birleştirme isteği incelemesi ve testlerle yapmaktır.

Talimat ve model sürümü neden birlikte kaydedilir?

Aynı talimat farklı model sürümlerinde farklı davranır. Bu yüzden talimat sürümü tek başına yetmez, yanıtı üreten model kimliği de kayıtta olmalıdır.

Sağlayıcıların sürümleme kuralları farklıdır. Anthropic belgelerine göre 4.6 kuşağından itibaren tarihsiz model kimlikleri tek bir sabit anlık görüntüye karşılık gelir. Güncellenmiş model yeni bir kimlikle çıkar. Daha eski modellerdeki takma adlar ise o sürümün en son tarihli anlık görüntüsüne yönlenir. Aynı belge bir ayrıntıyı daha belirtir: model ağırlıkları kimlik boyunca sabittir, ama yönlendirici, güvenlik sınıflandırıcıları ve örnekleme mantığı gibi sunum altyapısı değişebilir ve gözlenen davranışta küçük farklar doğurabilir.

Uygulama için sonuç şudur: üretimde sabit bir model kimliği kullanın, takma ada güvenmeyin ve model değişikliğini de bir talimat değişikliği kadar ciddi ele alın. Her model kimliğinin kendi kullanımdan kaldırma ve emeklilik takvimi vardır. Bu tarihleri envantere yazın ve geçişi son haftaya bırakmadan, talimat regresyon kümesiyle birlikte planlayın. Model yükseltmesinde güvenlik davranışını karşılaştırmalı doğrulama yöntemi model yükseltme güvenlik regresyonu yazısında anlatılır.

Değişiklik kaydında hangi alanlar olmalı?

Metin farkı sürüm kontrol sisteminde zaten görünür. Değişikliğin amacı ve beklenen etkisi ise yazılmazsa bir yıl sonra kimse anlayamaz.

Risk notunda değişikliğin rol tanımına, reddetme kurallarına, araç izinlerine ya da gizlilik talimatlarına dokunup dokunmadığı belirtilir. Bu bölümlere dokunan değişiklikler daha sıkı onaydan geçer.

Regresyon testi talimat için nasıl kurulur?

Regresyon testi, değişiklikten sonra eski davranışların bozulmadığını doğrulayan sabit bir test kümesidir. Küme dört parçadan oluşur:

• Görev testleri: uygulamanın asıl işini ne kadar iyi yaptığı.
• Saldırı testleri: bilinen istem enjeksiyonu, jailbreak ve talimat sızdırma denemeleri.
• Red testleri: reddedilmesi gereken isteklerin hâlâ reddedildiği.
• Aşırı red testleri: meşru isteklerin gereksiz yere reddedilmediği.

Son parça sık unutulur. Güvenliği sıkılaştırırken kullanılabilirliği bozmak da bir gerilemedir. Model çıktısı değişken olduğu için aynı test birkaç kez çalıştırılır ve sonuç bir eşikle değerlendirilir. Eşiği kurumun risk iştahı belirler.

Test kümesi de sürümlenir. Gerçek bir olaya yol açan girdi kümeye eklenir, böylece aynı hata ikinci kez yayına çıkmaz. Kümeyi birleştirme isteklerini engelleyen bir kapıya bağlamanın iskeleti LLM eval harness ve güvenlik regresyonu yazısında yer alır.

Onay ve yayın süreci risk düzeyine göre nasıl ayrılır?

Her değişiklik aynı yoldan geçmek zorunda değildir. Risk düzeyine göre ayrılmış yollar hem hız hem güvence sağlar.

Kademeli yayında yeni sürüm önce iç kullanıcılara ya da küçük bir trafik dilimine açılır. Göstergeler izlenir, sorun yoksa kapsam genişletilir. Üretim talimatına yazma yetkisi az sayıda kişide olmalı ve her yazma kayda geçmelidir. Acil düzeltme için ayrı ama izlenen bir yol tanımlayın. Aksi halde acil durum, her seferinde kuralı atlamanın gerekçesine dönüşür.

Geri alma planı ve yayın sonrası izleme nasıl kurulur?

Geri alma planı yazılı, denenmiş ve tetikleyicileri belli olmalıdır. İzleme olmadan geri alma kararı verilemez, bu yüzden ikisi birlikte kurulur.

• Önceki talimat sürümü saklı ve tek adımda seçilebilir mi?
• Geri alma yetkisi olan kişiler belli ve ulaşılabilir mi?
• Hangi göstergeler geri almayı tetikler: ret oranında ani değişim, yanıt uzunluğunda sapma, güvenlik uyarıları, şikâyet artışı?
• Geri alma adımı bir tatbikatta denendi mi?
• Geri alma sonrası kök neden incelemesi yapılıyor mu?

Yayından sonraki ilk saatlerde ret oranı, yanıt uzunluğu ve araç çağrı örüntüleri yakından izlenir. Bu göstergelerin uzun vadeli takibi, model ve veri kaymasıyla birlikte ele alınır. Ayrıntılar için üretimde model kayması izleme yazısına bakın.

Talimat parçaları ve dış içerik nasıl yönetilir?

Gerçek uygulamalarda talimat tek bir metin değil, birleştirilen parçalardır: rol tanımı, güvenlik kuralları, ürün bilgisi, kullanıcıya özel bağlam ve araç açıklamaları. Her parçanın ayrı sürümü ve sahibi olmalıdır. Ürün bilgisi sık değişebilir. Güvenlik kuralları ise nadiren ve sıkı onayla değişmelidir. Bu ayrım hızlı güncelleme ile güvenlik kontrolü arasında denge kurar.

Şablon değişkenleri dikkat ister. Kullanıcı adı, belge içeriği ya da arama sonucu talimata eklendiğinde bu metin talimat gibi yorumlanabilir. Dış içeriği ayrı bir bölümde, güvenilmeyen veri olarak işaretleyerek verin. Yine de bu ayrımı tek savunma saymayın. OWASP'ın önerdiği gibi kritik davranışı modelin dışındaki kontrollerle uygulayın.

Birleşmiş metnin tamamını her istekte kaydetmek maliyetli olabilir. Parça sürümlerini ve değişken değerlerinin özetini kaydetmek, olay incelemesinde aynı birleşimi yeniden üretmeye yeter.

Sık Sorulan Sorular

Prompt sürümleme neden gereklidir?

Sistem talimatı uygulamanın davranışını belirleyen bir yapılandırmadır. Tek bir cümle değişikliği reddetme davranışını gevşetebilir ya da yanıt kalitesini bozabilir, üstelik bu hata görünür biçimde patlamaz. Sürümleme, hangi değişikliğin ne zaman, kim tarafından ve neden yapıldığını izlemeyi, sorun çıkınca bir önceki sürüme hızla dönmeyi mümkün kılar.

Talimat değişikliklerinde hangi testler çalıştırılmalı?

Her değişiklikte sabit bir test kümesi çalıştırılır. Küme dört parçadan oluşur: asıl görevler, bilinen saldırı denemeleri, reddedilmesi gereken istekler ve gereksiz yere reddedilmemesi gereken meşru istekler. Model çıktısı değişken olduğu için her test birkaç kez çalıştırılır ve sonuç önceki sürümle eşik üzerinden karşılaştırılır. Kötüleşme varsa değişiklik yayına çıkmaz.

Talimatlar kod deposunda mı tutulmalı?

Çoğu durumda evet. Depo; sürüm geçmişi, gözden geçirme, yetki kontrolü ve otomatik test imkânı verir. OpenAI de Kasım 2026'da kapanacak yönetilen prompt nesneleri için talimat metnini uygulama koduna taşımayı ve sürümlemeyi kendi deponuzda commit, birleştirme isteği incelemesi ve testlerle yapmayı önerir. Yönetim arayüzünden doğrudan düzenleme izi belirsiz bırakır.

Geri alma planı nasıl olmalı?

Bir önceki çalışan sürüm yapılandırmadan tek adımda seçilebilmelidir. Geri alma kararını kimin verebileceği ve hangi göstergelerin tetikleyeceği önceden yazılı olmalıdır: ret oranında ani değişim, güvenlik uyarıları ya da şikâyet artışı gibi. Geri alma adımını bir tatbikatta denemek, gerçek olay anında gecikmeyi önler. Her geri almadan sonra kök neden incelemesi yapılır.

Kaynaklar

• OWASP GenAI: LLM07:2025 System Prompt Leakage
• OpenAI: Migrate from prompt objects
• Claude Platform Docs: Model IDs and versioning
• OWASP GenAI: LLM01:2025 Prompt Injection

İlgili Yazılar

• LLM Güvenlik Regresyonunu CI'a Bağlamak AltayDuel veri setiyle çalışan pytest + GitHub Actions harness
• Model Yükseltmelerinde Güvenlik Regresyonu Nasıl Kurulur?
• Sistem Promptu Sızdırma: 10 Yol, 10 Savunma
• Model Drift İzleme: Üretimde Model ve Veri Kayması