# Otomatik Prompt Optimizasyonu: DSPy, Meta-Prompting ve Kendi Kendini İyileştiren Sistemler (2026)

> Source: https://sukruyusufkaya.com/blog/otomatik-prompt-optimizasyonu-dspy-2026
> Updated: 2026-07-15T04:45:33.804Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Elle prompt yazma devri kapanıyor. DSPy, meta-prompting ve otomatik değerlendirme döngüleriyle prompt'ları makineye optimize ettiren yaklaşımı anlatıyorum.

**TL;DR —** Elle prompt yazma devri kapanmıyor ama artık tek başına yetmiyor. Sahada gördüğüm en büyük dönüşüm şu: prompt'ları tek tek elle cilalamak yerine, bir metrik ve küçük bir değerlendirme (eval) seti tanımlayıp optimizasyonu makineye devretmek. DSPy gibi çerçeveler LLM'i "prompt yazarak" değil "programlayarak" kullanmanızı sağlıyor: Signature ile davranışı bildiriyor, Module ile kompoze ediyor, optimizer ile küçük bir veri kümesi üstünde prompt'u derletiyorsunuz. Meta-prompting ise bir LLM'e başka bir prompt'u yazdırıp eleştirtip iyileştirtme işi. Gartner'ın Temmuz 2025'te özetlediği gibi "prompt engineering out, context engineering in" — yani beceri kaybolmuyor, olgunlaşıyor. Bu yazıda neden elle prompt'un ölçeklenmediğini, DSPy'nin çekirdek kavramlarını sade Türkçeyle, bir eval setinin nasıl kurulacağını, otomasyonun ne zaman değip ne zaman değmediğini, güvenlik risklerini ve Türkçe için bir başlangıç değerlendirme setini anlatıyorum.

## Neden elle prompt yazmak ölçeklenmiyor

İşin başında hepimiz aynı şeyi yaptık. Bir sohbet penceresi açtık, bir talep yazdık, çıktı beğenmedik, cümleyi değiştirdik, "adım adım düşün" ekledik, bir örnek koyduk, tekrar denedik. Bu döngü tek bir görev için, tek seferlik bir iş için harika çalışır. Sorun, o promptu bir üretim sistemine koyduğunuzda başlıyor.

Sahada danışmanlık yaparken sürekli aynı tabloyu görüyorum: Bir ekip haftalarca uğraşıp "mükemmel" bir prompt buluyor. O prompt, denedikleri on beş örnekte harika çalışıyor. Sonra sistem canlıya çıkıyor, gerçek kullanıcılar gerçek girdilerle geliyor ve promptun kapsamadığı yüzlerce köşe durumu ortaya çıkıyor. Ekip yeniden prompta dönüyor, bir cümle ekliyor, ama o eklediği cümle daha önce çalışan üç senaryoyu bozuyor. Kimse fark etmiyor çünkü kimse o üç senaryoyu bir daha test etmiyor. Bu, klasik yazılımdaki "regresyon" probleminin prompt hâli — ama test altyapısı olmadan.

Elle prompt yazmanın ölçeklenmemesinin birkaç somut nedeni var:

- **Gözle değerlendirme yanıltıcıdır.** Bir promptu "iyileştirdiğinizi" düşünürsünüz ama elinizde ölçüt yoksa bu sadece bir histir. İnsan gözü küçük örneklem üstünde kolayca kanar.
- **Model değişince prompt bozulur.** Sağlayıcı modeli güncellediğinde, elle cilalanmış promptunuzun varsayımları çöker. GPT ya da Claude'un yeni sürümü farklı davranır ve sizin "sihirli cümleleriniz" artık aynı etkiyi yapmaz.
- **Kombinatoryal patlama.** Gerçek bir sistemde tek bir prompt yoktur. Sınıflandırıcı prompt, özetleyici prompt, yeniden yazan prompt, doğrulayan prompt... Her biri diğerini besliyor. Birini elle değiştirdiğinizde zincirin tamamını yeniden dengelemeniz gerekir.
- **Bilgi tek kişide sıkışır.** "Prompt'u en iyi Ahmet biliyor" cümlesini kaç kez duydum bilemezsiniz. Ahmet izne çıktığında sistem donar. Elle prompt, kurumsallaşamayan bir zanaat hâline gelir.
- **İterasyon maliyeti gizlidir.** Her elle deneme bir insan-saat yer. Bir mühendisin haftalarca prompt cilalaması, aslında görünmeyen ama çok pahalı bir maliyettir.

Buradaki temel fikir şu: Elle prompt yazmak, ölçme olmadan yapılan bir mühendisliktir. Ve ölçmeden yapılan hiçbir mühendislik ölçeklenmez. Yazılımda testsiz kod yazmayı bıraktığımız gibi, metriksiz prompt yazmayı da bırakmak zorundayız.

> Sahadan bir gözlem: Bir promptu "iyileştirmek" ile "değiştirmek" arasındaki farkı ancak bir eval setiniz varsa görebilirsiniz. Onsuz, sadece rastgele yürüyorsunuz ve bazen şansınız yaver gidiyor.

## Prompt mühendisliğinden bağlam (context) mühendisliğine geçiş

Gartner Temmuz 2025'te bu dönüşümü çok yerinde bir sloganla özetledi: **"context engineering is in, prompt engineering is out."** Ama bu cümleyi yanlış okumak kolay. Kimse "prompt yazma becerisi çöpe gitti" demiyor. Söylenen şu: Tek bir sihirli cümle bulma çabası yerini, modelin etrafındaki tüm bağlamı bir sistem olarak tasarlamaya bırakıyor.

Bağlam mühendisliği neyi kapsıyor? Gartner'ın çerçevesiyle:

- **Bağlam mimarisi:** Modele hangi bilgiyi, hangi sırada, hangi biçimde verdiğiniz. Retrieval (getirme) katmanları, bellek, örnek seçimi, biçimlendirme.
- **Ajan orkestrasyonu:** Birden fazla LLM çağrısının, aracın ve adımın nasıl koordine edildiği. Kim ne zaman konuşuyor, kim kimi doğruluyor.
- **Otomatik optimizasyon hatları (pipelines):** Prompt'ların ve bağlamın elle değil, bir metrik üstünde otomatik derlendiği süreçler. Bu yazının kalbi burası.
- **Kurumsal yönetişim (governance):** Kim hangi promptu değiştirebilir, sürüm kontrolü, denetim izi, onay akışları.
- **Güvenlik bilinçli sistem tasarımı:** Prompt injection, veri sızıntısı ve güvenilmeyen girdi izolasyonunun tasarıma gömülmesi.

Dikkat ederseniz "prompt yazmak" bunların içinde hâlâ var — ama artık on parçadan sadece biri. Beceri kaybolmuyor, bir alt disipline dönüşüyor. Tıpkı elle assembly yazmaktan derleyici kullanmaya geçtiğimiz gibi. Assembly bilgisi hâlâ değerli; ama günlük işi artık derleyici yapıyor.

Gartner'ın öngörüsü de bu yönü destekliyor: **2026'ya kadar kurumsal şirketlerin yaklaşık %70'inin yapay zeka destekli prompt otomasyonunu devreye alacağı** tahmin ediliyor. Yani bu bir moda değil, sektörün ana akımına yerleşen bir yapısal kayma. AI sistemleri giderek gerçek zamanlı geri bildirimi içselleştirip prompt'larını kendi kendine optimize ediyor ve elle iterasyon ihtiyacını azaltıyor.

Peki bu pratikte ne demek? Şu demek: Siz artık "en iyi cümleyi" aramıyorsunuz. Bunun yerine üç şeyi tanımlıyorsunuz — (1) sistemin ne yapmasını istediğinizi, (2) başarıyı nasıl ölçtüğünüzü, (3) hangi örnekler üstünde ölçtüğünüzü. Gerisini bir optimizasyon süreci hallediyor. İşte DSPy tam bu felsefeyi somutlaştıran çerçeve.

## DSPy'yi sade Türkçeyle anlamak: Signature, Module, Optimizer

DSPy'yi ilk duyduğumda kafa karışıklığı yaşamıştım, çünkü çoğu anlatım hemen kod örneğine dalıyor. Oysa fikir çok temiz. DSPy'nin tek cümlelik özeti şu: **LLM'i prompt yazarak değil, programlayarak kullanın.** Prompt metnini elle yazmak yerine, ne istediğinizi yapısal olarak bildiriyorsunuz ve çerçeve prompt'u sizin için üretip optimize ediyor.

Üç çekirdek kavram var. Bunları günlük dille açayım.

### Signature — Davranışın bildirimi

Bir Signature, bir görevin girdi ve çıktısını tarif eder. "Şu tip bir girdi alacağım, şu tip bir çıktı vereceğim" beyanıdır. Örneğin: "Girdi: bir müşteri e-postası. Çıktı: duygu etiketi (olumlu/olumsuz/nötr)." Dikkat edin, burada promptun kendisini yazmıyorsunuz — sadece davranışın sözleşmesini bildiriyorsunuz. Prompt metnini DSPy üretiyor.

Bunu bir fonksiyon imzası gibi düşünün. Klasik programlamada `topla(a, b) -> c` yazarsınız; fonksiyonun içini ayrıca doldurursunuz. Signature de benzer: "ne girer, ne çıkar" belli, ama "nasıl" kısmı optimizasyona bırakılıyor.

### Module — Davranışın kompozisyonu

Module, bir Signature'ı belirli bir akıl yürütme stratejisiyle çalıştıran yapı taşıdır. En bilinen örnek "zincirleme düşünme" (chain-of-thought) modülüdür: Aynı Signature'ı alır ama modeli cevaba varmadan önce adım adım düşünmeye yönlendirir. Başka modüller birden fazla çağrıyı zincirler, araç kullanır ya da cevabı bir başka modülle doğrular.

Önemli nokta: Modüller kompoze edilebilir. Bir sınıflandırma modülünün çıktısını bir özetleme modülüne, onun çıktısını bir doğrulama modülüne besleyebilirsiniz. Böylece karmaşık bir sistemi, her biri kendi Signature'ına sahip küçük parçalardan kuruyorsunuz. Bu, tam olarak yazılımdaki modülerlik fikrinin LLM dünyasına taşınması.

### Optimizer (teleprompter) — Derleyici

İşte sihir burada. Optimizer — DSPy'nin diliyle bazen "teleprompter" denir — küçük bir veri kümesi ve bir metrik alır, sonra Signature ve Module'lerinizi bu metrik üstünde en iyi sonucu verecek şekilde **derler**. "Derlemek" derken ne kastediyorum? Optimizer, prompt'un içine hangi örneklerin (few-shot) konacağını, talimatın nasıl ifade edileceğini, hatta bazı senaryolarda model ağırlıklarının nasıl ayarlanacağını otomatik arar.

Yani siz "adım adım düşün, işte üç örnek, şöyle formatta cevap ver" cümlelerini elle yazmıyorsunuz. Optimizer, elinizdeki dev sette hangi örneklerin ve hangi ifadelerin metriği yükselttiğini deneyerek buluyor. Bu, elle prompt cilalamanın otomatik hâli — ama insan hissine değil, ölçülen bir skora dayanıyor.

Burada bir uyarı: DSPy için internette dolaşan spesifik yüzde iyileştirme rakamlarına şüpheyle yaklaşın. Çerçevenin değeri kavramsal — "ölçüye dayalı otomatik derleme" — ve kazanç sizin görevinize, veri setinize ve metriğinize göre değişir. Ben burada size uydurma bir "%40 iyileşme" vaat etmeyeceğim; onun yerine yöntemin neden mantıklı olduğunu anlatıyorum.

Şu tabloyla iki dünyayı yan yana koyayım:

| Boyut | Elle prompt yazma | Otomatik optimizasyon (DSPy tarzı) |
|---|---|---|
| Başarı ölçütü | His, gözle kontrol | Tanımlı metrik + eval set |
| İterasyon | İnsan-saat, yavaş | Otomatik, paralel, hızlı |
| Model değişimine dayanıklılık | Kırılgan, yeniden yazmak gerekir | Yeniden derle, metrik korunur |
| Bilgi paylaşımı | Tek kişide sıkışır | Kod + veri + metrikte kurumsallaşır |
| Regresyon kontrolü | Yok denecek kadar az | Eval set ile otomatik yakalanır |
| Başlangıç maliyeti | Düşük | Orta (eval seti kurmak gerekir) |
| Ölçek maliyeti | Zamanla artar | Zamanla düşer |
| En uygun senaryo | Tek seferlik, keşif | Üretim, tekrarlı, kritik görevler |

Tabloya bakınca görülen şu: Otomatik optimizasyonun başlangıç maliyeti daha yüksek (eval seti kurmak emek ister) ama ölçekte kazandırıyor. Küçük ve tek seferlik işler için elle prompt hâlâ mantıklı; büyüyen ve kritik sistemler için otomasyon kaçınılmaz.

## Meta-prompting: LLM'e prompt yazdırmak

Meta-prompting, adı kulağa havalı gelse de aslında çok basit bir fikir: **Bir LLM'i, başka bir prompt'u yazması, eleştirmesi ya da iyileştirmesi için kullanmak.** Model, kendi dilini en iyi bilen taraftır; o yüzden ondan kendisine nasıl talimat verileceğini de sorabilirsiniz.

Üç tipik kullanım biçimi var:

1. **Üretme:** "Şu görevi çözecek etkili bir sistem promptu yaz" dersiniz, model taslak bir prompt üretir. Bu, boş sayfa sorununu çözer. Sıfırdan yazmak yerine, üstünde çalışacağınız bir taslakla başlarsınız.
2. **Eleştirme:** Mevcut promptunuzu modele verip "bu prompt hangi durumlarda başarısız olur, hangi belirsizlikleri var?" diye sorarsınız. Model çoğu zaman sizin göremediğiniz köşe durumlarını işaret eder.
3. **İyileştirme:** "Bu prompt şu örnekte yanlış çıktı verdi, promptu bu hatayı düzeltecek şekilde revize et" dersiniz. Model, hatayı analiz edip talimatı günceller.

Meta-prompting'in gücü, onu bir döngüye soktuğunuzda ortaya çıkıyor. Model bir prompt üretir, siz onu eval setinizde çalıştırırsınız, sonuçları yine modele geri verip "işte başarısız örnekler, promptu düzelt" dersiniz. Bu döngü, DSPy optimizer'ının kavramsal olarak yaptığı şeyin elle/yarı otomatik hâlidir aslında.

Ama burada kritik bir tuzak var: **Metrik olmadan meta-prompting sadece daha hızlı bir kendini kandırma aracıdır.** Model size gayet ikna edici bir "iyileştirilmiş prompt" verir, siz de "vay be, ne güzel oldu" dersiniz — ama gerçekten daha iyi mi oldu, bilmiyorsunuz. Meta-prompting'i değerli kılan şey, arkasındaki değerlendirme döngüsüdür. Onsuz sadece cilalı laf üretiyorsunuz.

> Danışmanlıklarda sık söylediğim bir cümle: Meta-prompting bir gaz pedalıdır. Direksiyonunuz (metriğiniz) yoksa, sadece daha hızlı duvara toslarsınız.

## Değerlendirme (eval) seti ve metrik kurmak: İşin kalbi

Şimdi otomatik optimizasyonun tüm meselesinin döndüğü yere geldik. Ne DSPy ne meta-prompting ne de "kendi kendini iyileştiren sistem" — hiçbiri bir **metrik** ve bir **değerlendirme seti** olmadan çalışmaz. Bu ikisi, tüm otomasyonun temelidir. Bunları atlarsanız, elinizde sadece süslü bir isim kalır.

### Değerlendirme seti nedir

Değerlendirme seti (eval set / dev set), sisteminizin karşılaşacağı gerçekçi girdilerden ve — mümkünse — beklenen çıktılardan oluşan küçük ama temsili bir örnek kümesidir. "Küçük" diyorum çünkü binlerce örneğe ihtiyacınız yok; iyi seçilmiş 30-100 örnek çoğu görev için başlangıç olarak yeterlidir. Önemli olan sayı değil, **temsil gücü**.

İyi bir eval seti şunları içerir:

- **Tipik durumlar:** Sistemin çoğu zaman göreceği sıradan girdiler.
- **Köşe durumları:** Nadir ama önemli, sistemin genelde tökezlediği girdiler.
- **Zor/muğlak durumlar:** İnsanın bile tereddüt ettiği, sınırdaki örnekler.
- **Geçmiş hatalar:** Sistemin daha önce yanlış yaptığı gerçek vakalar. Bunlar altın değerinde çünkü regresyonu tam buradan yakalarsınız.

### Metrik nedir

Metrik, bir çıktının "ne kadar iyi" olduğunu sayıya çeviren fonksiyondur. Metriğin biçimi göreve göre değişir:

- **Kesin eşleşme:** Sınıflandırmada, çıktı doğru etikete eşit mi? Basit ve güvenilir.
- **Örtüşme skorları:** Çıkarım/özet görevlerinde beklenen unsurların ne kadarını yakaladı?
- **LLM-as-judge:** Öznel görevlerde (bir cevabın kalitesi, tonu, yardımcılığı) başka bir LLM'e "bu çıktı şu kritere göre 1-5 arası kaç puan?" diye sorarsınız. Güçlü ama dikkatli kurulması gerekir; yargıç modelin de kendi önyargıları olur.
- **Kural tabanlı kontroller:** "Çıktı geçerli JSON mu, istenen alanları içeriyor mu, yasaklı ifade var mı?" gibi deterministik kontroller.

Çoğu ciddi sistemde tek metrik yetmez; birkaçını birleştirirsiniz. Örneğin hem "JSON geçerli mi" (kural) hem "içerik doğru mu" (LLM-judge) hem "istenen alanlar var mı" (kural). Metrik ne kadar iyi tanımlanırsa, optimizasyon o kadar isabetli olur. **Kötü tanımlanmış bir metrik, optimizasyonu yanlış yöne koşturur** — model metriği "hackler", gerçek kaliteyi değil.

> Altın kural: Metriğiniz neyi ödüllendiriyorsa, sisteminiz onu üretir. Yanlış şeyi ölçerseniz, yanlış şeyde mükemmelleşen bir sistem elde edersiniz.

## Optimizasyon döngüsü: Kendi kendini iyileştiren sistem nasıl işler

Şimdi parçaları birleştirelim. "Kendi kendini iyileştiren sistem" kulağa bilim kurgu gibi geliyor ama aslında çok somut, tekrarlanabilir bir döngü. İşte adım adım:

1. **Görevi tanımla (Signature).** Sistemin ne girip ne çıkaracağını beyan et. Henüz promptu yazma.
2. **Bir başlangıç sistemi kur (Module).** Basit bir modülle başla — örneğin doğrudan cevap ya da zincirleme düşünme. Bu senin taban çizgin (baseline).
3. **Eval setini hazırla.** 30-100 temsili örnek topla, mümkünse beklenen çıktılarıyla. Geçmiş hataları özellikle ekle.
4. **Metriği tanımla.** Başarıyı sayıya çeviren fonksiyonu yaz. Birkaç kontrolü birleştir.
5. **Taban çizgiyi ölç.** Başlangıç sisteminin eval setindeki skorunu al. Bu senin karşılaştırma noktan.
6. **Optimizasyonu çalıştır.** Optimizer (ya da meta-prompting döngüsü) farklı örnek seçimlerini, talimat ifadelerini ve yapıları dener; her birini metrikle puanlar; en iyisini seçer.
7. **En iyiyi doğrula.** Optimize edilmiş sistemi, optimizasyonda kullanılmayan ayrı bir test setinde ölç. Bu çok önemli: Eval setine "aşırı uyum" (overfitting) tuzağına düşmemek için ayrı bir doğrulama seti şart.
8. **Devreye al ve izle.** Canlıda gerçek çıktıları izle, yeni hataları topla, eval setine geri besle. Döngü baştan başlar.

Bu son adım — canlıdan gelen gerçek hataları eval setine geri beslemek — sistemi gerçekten "kendi kendini iyileştiren" yapan şey. Sistem çalıştıkça yeni köşe durumları keşfedersiniz, onları eval setine eklersiniz, optimizasyonu yeniden çalıştırırsınız ve sistem her turda biraz daha sağlamlaşır. AI sistemlerinin gerçek zamanlı geri bildirimi içselleştirip elle iterasyonu azaltması derken kastedilen tam olarak bu.

Dikkat edilmesi gereken bir nokta: Bu döngü otomatik olsa da **insan denetimi** gerektirir. Metriği insan tanımlar, eval setinin kalitesini insan güvence altına alır, canlıya çıkış kararını insan verir. Otomasyon, insanın yerini almıyor; insanın odağını "cümle cilalama"dan "sistem ve ölçüt tasarlama"ya kaydırıyor.

## Ne zaman otomatikleştirmeli, ne zaman elle kalmalı

Şimdi çok önemli bir dengeye geleyim, çünkü otomasyon her derde deva değil. Danışmanlıklarda en çok bu soruyla karşılaşıyorum: "Biz de DSPy kuralım mı?" Cevabım hep aynı: Duruma bağlı.

**Otomatik optimizasyon şu durumlarda değer:**

- Görev **tekrarlı ve kalıcı** — aynı iş binlerce kez çalışacak, aylarca yaşayacak.
- **Kalite kritik** — hata maliyeti yüksek (hukuki, finansal, müşteriye dönük).
- Elinizde **temsili veri** var ya da toplayabilirsiniz.
- Başarıyı **ölçebiliyorsunuz** — net bir metrik tanımlanabiliyor.
- Sistem **birden fazla adımdan** oluşuyor ve elle dengelemek zorlaşıyor.
- **Model değişimlerine** dayanıklılık istiyorsunuz — sağlayıcıyı ya da sürümü değiştirdiğinizde yeniden derleyebilmek.

**Elle prompt hâlâ mantıklı:**

- İş **tek seferlik ya da keşif amaçlı** — bir raporu bir kez özetleyeceksiniz.
- **Örnek/veri yok** ve toplamak, işin kendisinden pahalı.
- Metrik **tanımlanamıyor** — başarı tümüyle öznel ve bağlamsal.
- Görev **çok basit** — tek cümlelik bir talimat zaten yeterli çalışıyor.
- **Prototip aşamasındasınız** — henüz problemin ne olduğunu keşfediyorsunuz.

Burada Türkiye bağlamında bir maliyet uyarısı yapayım. Optimizasyon döngüleri **model çağrısı tüketir.** Optimizer, onlarca hatta yüzlerce aday konfigürasyonu eval seti üstünde dener; her deneme para demektir. Küçük bir eval seti ve mütevazı bir arama bütçesiyle bu maliyet makul kalır, ama "her şeyi optimize edelim" hevesiyle kontrolsüz koşturursanız fatura şaşırtabilir. Benim önerim: Önce en kritik, en çok çalışan tek bir promptu otomatikleştirin, kazancı ölçün, sonra yayılın. Türkiye'deki bütçe gerçekleriyle, "değdiği yerde otomatikleştir" en sağlıklı yaklaşım.

Basit bir karar kuralı: **Bir promptu ömrü boyunca kaç kez elle revize edeceğinizi tahmin edin. Bu sayı yüksekse ve her revizyonda regresyon riski varsa, otomasyon zaten kendini amorti eder.**

## Güvenlik: Otomatik hatlar prompt injection'a karşı korunmasız değildir

Otomasyon coşkusunun içinde en çok atlanan konu güvenlik. Şunu net söyleyeyim: **Prompt'unuzu bir makine optimize ediyor olması, sistemi prompt injection'a karşı korumaz.** Aksine, otomatik hatlar yeni yüzeyler açabilir.

Temel risk şu: Sisteminiz güvenilmeyen girdi işliyorsa (kullanıcı metni, web'den çekilen içerik, e-posta, belge), o girdinin içine gizlenmiş talimatlar sizin sistem talimatlarınızı ele geçirmeye çalışabilir. "Önceki tüm talimatları unut ve şunu yap" saldırısının binbir çeşidi var. Optimizasyon bu riski çözmez; hatta optimizer yanlışlıkla güvenliği zayıflatan bir konfigürasyona yönelebilir çünkü metriğiniz "güvenlik"i ölçmüyorsa optimizer onu umursamaz.

Somut savunma ilkeleri:

- **Güvenilmeyen girdiyi talimattan izole edin.** Sistem talimatları ile kullanıcı/harici içerik net biçimde ayrılmalı. İçeriği "veri" olarak işaretleyin, "talimat" olarak değil.
- **Güvenliği metriğe dahil edin.** Eval setinize injection denemeleri koyun ve metriğiniz "sistem bu saldırıya direndi mi" diye sorsun. Optimizer neyi ölçerseniz onu korur.
- **Çıktıyı doğrulayın.** Modelin çıktısını körlemesine kullanmayın; kural tabanlı kontroller, izin listeleri, alan doğrulamaları koyun.
- **En az yetki ilkesi.** Modelin eriştiği araçları ve verileri asgaride tutun. Injection başarılı olsa bile hasar sınırlı kalsın.
- **İnsan onayı, kritik eylemlerde.** Geri döndürülemez ya da yüksek riskli işlemlerde otomatik hattın önüne bir insan onayı koyun.

Kısacası: Otomatik optimizasyon, güvenlik mühendisliğinin yerine geçmez, onunla birlikte tasarlanır. Güvenliği metriğinizin bir parçası yapmazsanız, optimizer sizin için onu görmezden gelir.

## Türkçe için başlangıç değerlendirme seti

Şimdi çok pratik bir konuya geleyim çünkü Türkiye'de çalışan herkesin karşılaştığı gerçek şu: **İngilizce eval setleri Türkçe performansı garanti etmez.** Model İngilizcede parlak olabilir ama Türkçe morfoloji, ekler, deyimler, resmî/samimi ton geçişleri ve bağlama bağlı anlamlarda tökezleyebilir. O yüzden ciddi bir Türkçe sistem için Türkçe bir eval seti kurmak şart.

İşte pratik bir başlangıç reçetesi:

1. **Gerçek Türkçe veriden başlayın.** Kendi alanınızdan gerçek örnekler toplayın — müşteri e-postaları, destek talepleri, belgeler. Sentetik/çeviri metinler Türkçenin gerçek doğasını yansıtmaz.
2. **Türkçeye özgü zorlukları özellikle örnekleyin.** Ekli/çekimli formlar, büyük-küçük harf (İ/ı, İ/i) tuzakları, deyimler, alaycı/kapalı ifadeler, bölgesel kullanımlar, Türkçe-İngilizce karışık ("plaza dili") metinler.
3. **Beklenen çıktıları Türkçe konuşan biri etiketlesin.** Etiketleme kalitesi, eval setinin kalitesidir. Anadili Türkçe olan biri, sınırdaki örneklerde doğru kararı verir.
4. **Ton ve resmiyet katmanı ekleyin.** Türkçede "siz/sen", resmî/samimi ayrımı kritik. Sisteminiz doğru tonu tutturuyor mu, bunu da ölçün.
5. **Metriği Türkçeye göre ayarlayın.** Kesin string eşleşmesi Türkçede yanıltıcı olabilir (aynı anlam farklı eklerle ifade edilir). Anlamsal örtüşme ya da Türkçe farkında bir LLM-judge daha adil olur.
6. **Küçük başlayın, büyütün.** 30-50 iyi seçilmiş Türkçe örnekle başlayın. Sistem canlıya çıkınca gerçek Türkçe hataları toplayıp sete ekleyin.

Bir uyarı: LLM-as-judge kullanacaksanız, yargıç modelin Türkçe değerlendirmede İngilizceye göre daha az tutarlı olabileceğini aklınızda tutun. Yargıcın kararlarını ara sıra elle denetleyin, kalibre edin. Türkçe için "yargıcı da doğrula" adımı, İngilizceden daha kritik.

## Sık yapılan hatalar

Sahada tekrar tekrar gördüğüm, sizi zamandan ve paradan edecek hatalar:

- **Metriksiz optimizasyon.** En büyük hata. "Kendi kendini iyileştiren sistem" kuruyorum diyorsunuz ama iyileşmeyi ölçmüyorsunuz. Bu, pusulasız yelken açmaktır.
- **Eval setine aşırı uyum.** Sistem eval setinde harika, gerçekte berbat. Nedeni: Aynı seti hem optimize edip hem test etmişsiniz. Mutlaka ayrı bir doğrulama seti tutun.
- **Çok küçük ya da temsilsiz eval set.** Beş örnekle optimize edilen sistem, altıncı gerçek girdide çöker. Az ama temsili örnek, çok ama tek düze örnekten iyidir.
- **Metriği yanlış tanımlamak.** Model metriği "hackler" — teknik olarak yüksek skor alır ama gerçek kaliteyi üretmez. Metriğinizin gerçekten önemsediğiniz şeyi ölçtüğünden emin olun.
- **Maliyeti hesaba katmamak.** Kontrolsüz optimizasyon döngüleri şaşırtıcı faturalar üretir. Arama bütçesini sınırlayın, kritik promptla başlayın.
- **Güvenliği metrik dışında bırakmak.** Optimizer neyi ölçerseniz onu korur. Injection'ı eval setine koymazsanız, optimize edilmiş sisteminiz saldırıya açık kalır.
- **Türkçeyi İngilizce eval'la geçiştirmek.** İngilizcede iyi çalışan sistem Türkçede tökezler. Türkçe için ayrı ölçün.
- **İnsanı tümden devre dışı bırakmak.** Otomasyon, metrik ve eval tasarımını insana bırakır. "Tam otomatik" diye insanı kovanlar, kör bir sistemi optimize eder.
- **Bir kez optimize edip unutmak.** Modeller değişir, girdiler kayar. Optimizasyon bir olay değil, bir süreçtir; periyodik yeniden derleme gerekir.

## Nasıl başlamalı: İlk haftanızın planı

Teoriyi bırakıp somut bir başlangıç planı vereyim. Elle prompt dünyasından otomatik optimizasyona geçmek için ilk adımlarınız şunlar olsun:

1. **Tek bir prompt seçin.** En çok çalışan, en kritik ve şu an sizi en çok uğraştıran promptu bulun. Her şeyi birden dönüştürmeye çalışmayın; bir pilot seçin.
2. **20-30 örneklik bir eval seti toplayın.** Gerçek girdilerden, mümkünse geçmiş hatalardan. Beklenen çıktıları elle etiketleyin. Türkçe sistemse Türkçe örneklerle.
3. **Basit bir metrik yazın.** Görevinize uygun en yalın ölçütle başlayın — kesin eşleşme, alan kontrolü ya da bir LLM-judge kriteri. Mükemmel olmasına gerek yok, ölçülebilir olması yeter.
4. **Taban çizgiyi ölçün.** Mevcut promptunuzun bu eval setindeki skorunu alın. Artık bir karşılaştırma noktanız var.
5. **Önce meta-prompting ile deneyin.** DSPy kurmadan önce, elinizdeki modele "işte prompt, işte başarısız örnekler, düzelt" döngüsünü elle çalıştırın. Skorun yükselip yükselmediğini görün. Bu, kavramı bedava öğretir.
6. **Kazancı görürseniz DSPy'ye geçin.** Meta-prompting elle işe yarıyorsa, DSPy ile Signature-Module-Optimizer yapısına taşıyıp süreci otomatikleştirin. Artık her model değişiminde yeniden derleyebilirsiniz.
7. **Ayrı test setinde doğrulayın.** Optimize ettiğiniz sistemi, optimizasyonda görmediği örneklerle sınayın. Aşırı uyumun tuzağına düşmeyin.
8. **Güvenliği ekleyin.** Eval setinize birkaç injection denemesi koyun, metriğinizin bunları yakaladığından emin olun.
9. **Canlıya alın, hataları geri besleyin.** Gerçek hataları toplayıp eval setine ekleyin, periyodik olarak yeniden derleyin. Döngü artık dönüyor.

Bu dokuz adım, sizi "his ile prompt cilalayan" bir ekipten "ölçüye dayalı optimize eden" bir ekibe dönüştürür. Ve en güzeli, küçük başlayabilirsiniz — tek bir prompt, otuz örnek, basit bir metrik. Oradan büyür. Elle prompt yazma becerisini çöpe atmıyoruz; onu bir ölçme-optimize etme disiplininin içine yerleştiriyoruz. Sahada gördüğüm kadarıyla, bu geçişi erken yapan ekipler, geç yapanların aylarca elle cilaladığı işi günlerde ve çok daha sağlam biçimde çözüyor.