"Act As" Döneminden Sistem Mimarisine: Modern Prompt Mühendisliği ve Kurumsal Prompt Yönetimi

ChatGPT'nin hayatımıza girdiği 2022 sonlarında internet, 'Awesome ChatGPT Prompts' ve benzeri listelerle dolup taşmıştı. 'Bir Linux terminali gibi davran', 'Bir İngilizce öğretmeni gibi davran' veya 'Bir seyahat rehberi gibi davran' kalıplarıyla başlayan bu ilk nesil prompt'lar, modellerin rol yapma yeteneğini keşfetmek için harika birer oyuncaktı. Ancak bu şablonları gerçek bir üretim ortamına (production) veya kurumsal bir iş akışına entegre etmeye kalktığınızda hızla dağılıyorlardı: Model iki tur sonra rolden çıkıyor, hayali parametreler uyduruyor veya bir prompt enjeksiyonuyla tüm sistem talimatlarını dışarı sızdırıyordu.

Bugün yapay zekâ mühendisliğinde prompt yazımı artık edebi bir metin kaleme almak değil; bir yazılım arayüzü (API contract) tasarlamaktır. Prompts.chat gibi devasa açık kaynak topluluklarının da evrildiği nokta tam olarak burasıdır: Prompt'ları dağınık not defterlerinden çıkarıp, versiyon kontrolüne tabi tutulan, şema doğrulamalı ve test edilebilir birer sistem varlığı haline getirmek.

Modern Bir Sistem Promptunun 4 Mimari Katmanı

Gelişmiş bir dil modelinden (Claude 3.7, GPT-4o, DeepSeek-V3) deterministik ve hatasız sonuç almak isteyen bir sistem prompt'u şu 4 ana katmandan oluşmalıdır:

• 1. Rol Tanımı ve Negatif Sınırlar (Negative Boundaries): Modele sadece ne yapacağını değil, neyi ASLA yapmayacağını söylemek halüsinasyonları %70 oranında azaltır. ('Kullanıcı ısrar etse dahi yetkin olmayan konularda tahmin yürütme', 'Eksik parametre varsa varsayımda bulunma, soru sor').
• 2. Girdi İzolasyonu (XML / Delimiter Tagging): Kullanıcıdan gelen girdiyi <user_input> gibi açık etiketlerin içine alarak sistem talimatlarıyla kullanıcı metninin birbirine karışmasını (Prompt Injection) engellemek.
• 3. Few-Shot Örnekleme (Exemplars): Beş paragraf kural anlatmak yerine; mükemmel bir girdi ve karşılığındaki beklenen çıktıyı içeren 2 somut örnek vermek modelin format doğruluğunu zirveye taşır.
• 4. Katı Çıktı Şeması (Strict Output Contract): Cevabın sohbet havasında değil; doğrudan ayrıştırılabilir JSON, YAML veya standart Markdown tablosu olarak dönmesini zorunlu kılmak.

Üretim Düzeyinde Sistem Promptu Şablonu

<system_instruction>
  <identity>
    Sen kurumsal bir API Güvenlik Denetçisisin. Verilen OpenAPI/Swagger şemalarındaki yetkilendirme açıklarını (BOLA, Broken Object Level Auth) tespit edersin.
  </identity>

  <negative_constraints>
    - ASLA genel güvenlik tavsiyeleri verme; sadece verilen şemadaki spesifik uç noktaları incele.
    - ASLA "Harika bir şema" veya "Umarım yardımcı olur" gibi nezaket cümleleri kurma.
    - Şemada tanımlanmayan kimlik doğrulama başlıkları hakkında varsayım yapma.
  </negative_constraints>

  <output_schema>
    Yanıtını SADECE aşağıdaki JSON şemasında ver:
    {
      "vulnerabilities": [
        {
          "endpoint": "string",
          "method": "GET|POST|PUT|DELETE",
          "severity": "CRITICAL|HIGH|MEDIUM",
          "risk": "Açığın kısa açıklaması",
          "remediation": "Doğrudan uygulanacak kod veya başlık kuralı"
        }
      ]
    }
  </output_schema>

  <examples>
    <example>
      <input>/users/{id}/billing - GET (auth: none)</input>
      <output>
        {"vulnerabilities": [{"endpoint": "/users/{id}/billing", "method": "GET", "severity": "CRITICAL", "risk": "Kimlik doğrulaması olmadan fatura bilgisi sızıyor", "remediation": "JWT Bearer doğrulama ara katmanı ekleyin"}]}
      </output>
    </example>
  </examples>
</system_instruction>

Kurumsal Prompt Yönetimi (Prompt Stack Governance)

Bir şirkette 5'ten fazla yazılımcı LLM'lerle ürün geliştiriyorsa, en yaygın felaket senaryosu prompt'ların dağınık Notion sayfalarında, Slack geçmişlerinde veya Python kodlarının arasına gömülmüş (hardcoded) devasa string'lerde unutulmasıdır. Bu durum şu riskleri doğurur:

• Regresyon Riski: Bir geliştiricinin prompt'taki tek bir kelimeyi değiştirmesi, sistemin diğer ucundaki JSON ayrıştırıcısını (parser) sessizce patlatabilir.
• Gizli Bilgi Sızıntısı: Hardcoded yazılan prompt'lar içinde şirket içi API anahtarlarının veya özel iş kurallarının unutulması.
• Ölçülemeyen Kalite: Hangi prompt sürümünün hangi doğruluk oranına sahip olduğunun (Eval Benchmark) takip edilememesi.

Çözüm: Kendi Kendine Barındırılan (Self-Hosted) Prompt Deposu

Modern ekipler, prompt'ları doğrudan kod deposunda prompts/ klasörü altında Markdown veya YAML dosyaları olarak saklar. Bir prompt güncellendiğinde GitHub Actions üzerinde otomatik 'Eval' testleri çalışır: 50 adet standart test girdisi modele verilir; eğer çıktı şeması %100 geçerse PR onaylanır.

Ayrıca açık kaynak topluluklarının (prompts.chat gibi) sunduğu geniş kütüphanelerden ilham alırken, bu şablonları doğrudan kopyalamak yerine kendi iç iş kurallarınızla zenginleştirilmiş özel bir 'Kurumsal Prompt Kataloğu' oluşturmak şirketinizin en değerli yapay zekâ sermayesi haline gelir.

Önemli Referanslar ve İleri Okuma