Üç Model Yükseltmesine Dayanan Sistem İstemleri (System Prompts)

Önemli çıkarımlar

• Tek bir modelin alışkanlıklarına göre yamalanmış bir istem, gelecekteki her modelin ödeyeceği bir teknik borçtur.
• Üç katmanlı mimari: Niyet katmanı (sabit), Çıktı sözleşmesi (sabit) ve Modele özgü ayar katmanı (değiştirilebilir).
• Model yükseltme kararından önce her istemi aday model üzerinde mevcut eval paketiyle test edin.
• Yalnızca istem metnini değil, görünürde garip duran her kuralın neden oraya yazıldığını yorum satırlarıyla belgeleyin.

Bir ekip Claude Sonnet 3.5’ten Sonnet 4’e geçtiğinde müşteri özetleme özelliğinin aniden bozulduğunu gördü. Yeni model aşırı kısa özetler üretiyor, kritik gerçekleri atlıyor ve özetlemek yerine müşterinin cümlelerini tekrar ediyordu. İstemde hiçbir şey değişmemişti ama model tamamen değişmişti.

İki günlük inceleme sonucunda kök nedeni bulduk: orijinal istem, Sonnet 3.5’in fazla açıklama yapma eğilimini dizginlemek için sert negatif komutlarla (“Kısa yaz. 80 kelimeyi geçme. Müşterinin sorusunu tekrarlama.”) doldurulmuştu. Sonnet 4 bu negatif komutları çok daha katı yorumlayarak teknik olarak kurallara uyan ama işlevsiz özetler üretiyordu. İstemi üç katmana ayırdığımızda model geçiş süresi iki günden on dakikaya indi.

Üç Katmanlı İstem Mimarisi: Niyet, Sözleşme ve Ayar

1. Niyet Katmanı (Modeller arası sabit): İstemin ne işe yaradığını, çıktıyı kimin hangi amaçla okuyacağını ve iş kurallarını (mahremiyet, uyumluluk) anlatır. Çözümü değil problemi tanımladığı için model değişse de sabit kalır.
2. Çıktı Sözleşmesi Katmanı (Modeller arası sabit): Beklenen çıktının biçimini (JSON şeması, 40-80 kelime sınırı, başlık yasağı, zorunlu alanlar) tanımlar.
3. Modele Özgü Ayar Katmanı (Değiştirilebilir): Belirli bir modelden en iyi sonucu alan etiket geleneklerini (Claude için <thread>, GPT için sınır işaretleri), düşünce zinciri (CoT) komutlarını ve few-shot örneklerini içerir. Model yükseltildiğinde yalnızca bu katman güncellenir.

Kural Gerekçelerini Belgelemek ve Eval Disiplini

Altı ay sonra kimse istemdeki “Başlık ekleme” kuralının neden yazıldığını hatırlamaz; biri gereksiz sanıp siler ve CRM kartlarında çift başlık hatası patlar. Görünürde bariz olmayan her kuralın altına # CRM kartında zaten başlık çubuğu var, çift görünümü önler (2025-Q4) şeklinde bir yorum satırı ekleyin. Yeni bir modele geçerken ayar katmanını kopyalayın, eval paketini çalıştırın ve başarı oranı eski modeli yakalayana kadar yalnızca ayar katmanını kalibre edin.

Sıkça sorulanlar

Sıkça sorulan sorular

Anthropic'in <document> etiketi gibi modele özgü yapıları kullanmalı mıyım?

Davranışı anlamlı ölçüde iyileştiriyorsa evet, ancak bunları istemin modele özgü ayar katmanında izole edin. Sağlayıcı değiştirdiğinizde niyet katmanına dokunmadan yalnızca bu şablon katmanını değiştirirsiniz.

Her model yükseltmesinde tüm istemleri yeniden değerlendirmeli miyim?

Ölçülebilir iş etkisi olan her istem için kesinlikle evet. Yeni modelin daha iyi olacağını varsayıp eval adımını atlamak, sessiz regresyonların canlıya sızmasının bir numaralı nedenidir.

Bir sistem istemi ne kadar uzun olmalıdır?

Eval paketini geçebildiği ölçüde en kısa haliyle. Gereksiz uzun istemler modelin dikkatini dağıtır, çok kısa istemler ise belirsizlik bırakır; sezgiye göre değil eval skoruna göre kısaltın.