
# Uyarlanabilir Prompt Şablonlarıyla Güvenli Anket Otomasyonu için Çekirdekli (RAG) Üretim

SaaS uyumluluğunun hızla değişen dünyasında, güvenlik anketleri her yeni sözleşmenin giriş kapısı haline geldi. Takımlar hâlâ politikalar, kanıt depoları ve geçmiş denetim artefaktları içinde saatlerce kayıp arama yaparak denetçilerin taleplerini karşılayacak yanıtlar hazırlıyor. Geleneksel AI‑destekli yanıt üreticileri, kanıtın güncelliğini veya alaka düzeyini garanti edemeyen sabit bir dil modeli kullandıkları için sıkça yetersiz kalıyor.  

**Çekirdekli‑Artırmalı Üretim (RAG)**, büyük bir dil modelini (LLM) çıkarım anında güncel, bağlama özgü belgelerle besleyerek bu boşluğu doldurur. RAG, **uyarlanabilir prompt şablonları** ile birleştirildiğinde, sistem anketin alanı, risk seviyesi ve getirilen kanıta göre LLM sorgusunu dinamik olarak şekillendirebilir. Sonuç, **doğru, denetlenebilir ve uyumlu** yanıtlar üreten kapalı döngülü bir motor olur; insan uyumluluk sorumlusu ise doğrulama için sürecin içinde kalır.

Aşağıda mimariyi, prompt mühendisliği metodolojisini ve bu konsepti herhangi bir güvenlik anketi iş akışı için üretime hazır bir hizmete dönüştüren operasyonel en iyi uygulamaları adım adım inceliyoruz.

---

## 1. Neden Tek Başına RAG Yeterli Değil

Standart bir RAG boru hattı genellikle üç adımdan oluşur:

1. **Belge Getirimi** – Bir bilgi tabanı (politika PDF’leri, denetim kayıtları, satıcı beyanları) üzerinde vektör araması yapılarak en ilgili `k` pasaj bulunur.  
2. **Bağlam Enjeksiyonu** – Getirilen pasajlar kullanıcı sorgusuyla birleştirilip bir LLM’ye gönderilir.  
3. **Yanıt Üretimi** – LLM, zaman zaman getirilen metni alıntılayarak bir yanıt sentezler.

Bu, saf bir LLM’ye göre gerçekçilik katarken, sıklıkla **prompt kırılganlığı** sorunuyla karşılaşır:

- Farklı anketler benzer kavramları hafifçe farklı ifadelerle sorar. Statik bir prompt, aşırı genelleme yapabilir veya gerekli uyumluluk dilini kaçırabilir.  
- Politikalar değiştikçe kanıt alaka düzeyi de değişir. Tek bir prompt, yeni düzenleyici terminolojiye otomatik olarak uyum sağlayamaz.  
- Denetçiler **izlenebilir alıntılar** talep eder. Saf RAG, denetim izleri için gereken açık referans semantiği olmadan pasajları gömebilir.

Bu eksiklikler, anket bağlamına göre evrimleşen **uyarlanabilir prompt şablonları** katmanını zorunlu kılar.

---

## 2. Uyarlanabilir RAG Şablonunun Temel Bileşenleri

```mermaid
graph TD
    A["Gelen Anket Maddesi"] --> B["Risk & Alan Sınıflandırıcısı"]
    B --> C["Dinamik Prompt Şablon Motoru"]
    C --> D["Vektör Getirici (RAG)"]
    D --> E["LLM (Üretim)"]
    E --> F["Yapılandırılmış Alıntılarla Yanıt"]
    F --> G["İnsan İncelemesi & Onayı"]
    G --> H["Denetim‑Hazır Yanıt Deposu"]
```

- **Risk & Alan Sınıflandırıcısı** – Hafif bir LLM veya kural‑tabanlı motor kullanarak her soruya risk seviyesi (yüksek/orta/düşük) ve alan (ağ, veri‑gizliliği, kimlik, vb.) etiketleri atar.  
- **Dinamik Prompt Şablon Motoru** – Tekrarlanabilir prompt parçacıklarından (giriş, politika‑özel dili, alıntı formatı) oluşan bir kütüphane tutar. Çalışma zamanında sınıflandırıcı çıktısına göre parçacıkları seçip birleştirir.  
- **Vektör Getirici (RAG)** – *Sürümlenmiş* kanıt deposu üzerinde benzerlik araması yapar. Depo, gömmeler ve meta‑veri (politik sürümü, geçerlilik tarihi, inceleyen) ile indekslenir.  
- **LLM (Üretim)** – Özel bir model veya uyumluluk dilinde ince ayar yapılmış açık kaynak bir LLM olabilir. Yapılandırılmış prompt’u saygı gösterir ve açık alıntı kimlikleriyle markdown‑stil yanıtlar üretir.  
- **İnsan İncelemesi & Onayı** – Uyumluluk analistlerinin yanıtı doğruladığı, alıntıları düzenlediği veya ek anlatım eklediği bir UI yoludur. Sistem, her düzenlemeyi izlenebilirlik için kaydeder.  
- **Denetim‑Hazır Yanıt Deposu** – Son yanıtı, kullanılan kesin kanıt anlık görüntüleriyle birlikte saklar; böylece gelecekteki denetimler için **tek bir doğruluk kaynağı** sağlar.

---

## 3. Uyarlanabilir Prompt Şablonları Oluşturma

### 3.1 Şablon Granülerliği

Prompt parçacıkları **dört ortogonal boyut** üzerinden düzenlenmelidir:

| Boyut | Örnek Değerler | Gerekçe |
|-------|----------------|---------|
| **Risk Seviyesi** | `high`, `medium`, `low` | Detay seviyesi ve gerekli kanıt sayısını kontrol eder. |
| **Düzenleyici Kapsam** | `[SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2)`, `[ISO 27001](https://www.iso.org/standard/27001)`, `[GDPR](https://gdpr.eu/)` | Düzenleyici‑özel ifadeleri ekler. |
| **Yanıt Stili** | `concise`, `narrative`, `tabular` | Anketin beklenti formatına uyum sağlar. |
| **Alıntı Modu** | `inline`, `footnote`, `appendix` | Denetçi tercihlerine göre alıntı biçimini ayarlar. |

Prompt parçacıkları basit bir JSON/YAML kataloğu ile tanımlanabilir:

```yaml
templates:
  high:
    intro: "Mevcut kontrollerimiz kapsamında, aşağıdakileri teyit ediyoruz"
    policy_clause: "Detaylı yönetişim için **{{policy_id}}** politikasına bakın."
    citation: "[[Kanıt {{evidence_id}}]]"
  low:
    intro: "Evet."
    citation: ""
```

Çalışma zamanında motor şu şablonu birleştirir:

```
{{intro}} {{answer_body}} {{policy_clause}} {{citation}}
```

### 3.2 Prompt Birleştirme Algoritması (Pseudo‑kod)

```goat
func BuildPrompt(question Question, evidence []Evidence) string {
    risk := ClassifyRisk(question)
    scope := IdentifyRegulation(question)
    style := ChooseStyle(question)
    tmpl := LoadTemplate(risk, scope, style)

    // Dinamik alanları doldur
    prompt := strings.ReplaceAll(tmpl.intro, "{{policy_id}}", evidence[0].PolicyID)
    prompt = strings.ReplaceAll(prompt, "{{answer_body}}", "{{USER_ANSWER}}")
    prompt = strings.ReplaceAll(prompt, "{{evidence_id}}", evidence[0].ID)

    return prompt
}
```

`{{USER_ANSWER}}` yer tutucusu, LLM’nin ürettiği metinle daha sonra değiştirilir; böylece nihai çıktı, şablonun belirlediği kesin düzenleyici dili tam olarak korur.

---

## 4. Denetlenebilir RAG için Kanıt Deposu Tasarımı

Uyumlu bir kanıt deposu üç ilkeyi karşılamalıdır:

1. **Sürümlendirme** – Her belge bir kez alındıktan sonra değiştirilemez; güncellemeler yeni bir sürüm ve zaman damgası oluşturur.  
2. **Meta‑veri Zenginleştirme** – `policy_id`, `control_id`, `effective_date`, `expiration_date`, `reviewer` gibi alanlar içermelidir.  
3. **Erişim Denetimi** – Her retrieval isteği, sorgu hash’iyle birlikte verilen belge sürümünü loglar.

Pratik bir uygulama, **Git‑tabanlı blob depolama** ile bir vektör indeksi (örn. **FAISS** veya **Vespa**) birleştirir. Her commit, kanıt kütüphanesinin bir anlık görüntüsünü temsil eder; denetçiler belirli bir tarih itibarıyla kanıt istediklerinde sistem, ilgili snapshot’a geri dönebilir.

---

## 5. İnsan‑İçinde‑Döngü İş Akışı

En gelişmiş prompt mühendisliğiyle bile, bir uyumluluk profesyonelinin nihai yanıtı onaylaması gerekir. Tipik bir UI akışı şunları içerir:

1. **Ön İzleme** – Üretilen yanıtı, tıklanabilir alıntı kimlikleriyle gösterir; bu kimlikler kanıt snippet’lerini genişletir.  
2. **Düzenleme** – Analist, ifadeyi ayarlayabilir veya daha güncel bir belgeyle alıntıyı değiştirebilir.  
3. **Onay / Reddet** – Onaylandığında, her alıntılanan belge için versiyon hash’i kaydedilir; böylece değişmez bir denetim izi oluşur.  
4. **Geri Besleme Döngüsü** – Analistin düzenlemeleri, gelecekteki sorular için prompt seçim mantığını iyileştiren bir **reinforcement learning** modülüne beslenir.

---

## 6. Başarı Ölçütleri

Uyarlanabilir RAG çözümünün uygulanması, **hız** ve **kalite** metrikleri üzerinden değerlendirilmelidir:

| KPI | Tanım |
|-----|-------|
| **İşleme Süresi (TAT)** | Soru alımından onaylı yanıtına kadar olan ortalama dakikalar. |
| **Alıntı Doğruluğu** | Denetçilerin doğru ve güncel bulduğu alıntıların yüzdesi. |
| **Risk‑Ağırlıklı Hata Oranı** | Sorunun risk seviyesine göre ağırlıklandırılmış hata oranı (yüksek risk hataları daha fazla cezalandırılır). |
| **Uyum Skoru** | Bir çeyrek içinde denetim sonuçlarından türetilen bileşik skor. |

İlk pilot projelerde, ekipler **%70 TAT azalması** ve **%30 Alıntı doğruluğu artışı** bildirmiştir; bu da uyarlanabilir promptların eklenmesiyle elde edilmiştir.

---

## 7. Uygulama Kontrol Listesi

- [ ] Mevcut tüm politika belgelerini kataloglayıp sürüm meta‑verisiyle depola.  
- [ ] En yeni model (örn. **OpenAI text‑embedding‑3‑large**) ile gömmeler üretip bir vektör indeksi oluştur.  
- [ ] Risk seviyelerini tanımla ve anket alanlarını bu seviyelerle eşle.  
- [ ] Her seviye, düzenleyici ve stil için prompt parçacıkları kütüphanesini oluştur.  
- [ ] Prompt birleştirme servisini geliştir (stateless mikro‑servis önerilir).  
- [ ] Sistem‑seviyesi talimatları destekleyen bir LLM uç noktası entegre et.  
- [ ] İnsan incelemesi için bir UI inşa et ve her düzenlemeyi logla.  
- [ ] Yanıt, alıntı ve kanıt sürümlerini çıkaran otomatik denetim raporları ayarla.  

---

## 8. Gelecek Yönelimler

1. **Çok‑Modlu Getirime** – Kanıt deposunu ekran görüntüleri, mimari diyagramlar ve video walkthrough’ları da içerecek şekilde genişlet; Görsel‑LLM modelleriyle daha zengin bağlam sağlayın.  
2. **Kendini‑İyileştiren Promptlar** – LLM‑tabanlı meta‑öğrenme ile hata oranı bir alan için yükseldiğinde otomatik olarak yeni prompt parçacıkları önerin.  
3. **Sıfır‑Bilgi Kanıtı Entegrasyonu** – Yanıtın belirli bir belge sürümünden türetildiğini, belgeyi ifşa etmeden kanıtlayan kriptografik garantiler sunun; yüksek düzenleyici gereksinimli ortamlarda faydalı olur.

**RAG** ve **uyarlanabilir promptlama** birleşimi, yeni nesil uyumluluk otomasyonunun temel taşı olmaya hazırlanıyor. Modüler, denetlenebilir bir boru hattı kurarak, organizasyonlar yalnızca anket yanıt hızını artırmakla kalmaz, aynı zamanda sürekli iyileştirme ve düzenleyici direncin kültürünü de tesis eder.