# Programatik Prompt Optimizasyonu 2026: DSPy, Eval-Odaklı İş Akışı ve Context Engineering

> Source: https://sukruyusufkaya.com/blog/programatik-prompt-optimizasyonu-dspy-eval-odakli-2026
> Updated: 2026-08-05T01:47:15.278Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Prompt engineering artık sanat değil mühendislik. DSPy ile otomatik optimizasyon, eval-odaklı iş akışı, yapılandırılmış çıktı, prompt zincirleme ve Türkçe’ye özgü değerlendirme.

**TL;DR —** 2026'da prompt engineering, "daha net bir talimat yaz" ile "eval setine karşı prompt uzayını arayan bir optimizasyon algoritması çalıştır" arasında bir yere oturdu. Artık prompt'u, güvendiğiniz bir değerlendirme takımıyla puanlanan; tasarlanan, sürümlenen, test edilen ve optimize edilen bir yapı olarak ele alıyoruz. Manuel el işçiliğinden otomatik prompt optimizasyonuna geçiş hızlanıyor: DSPy gibi çerçeveler, prompt'ları modüler programlar olarak tanımlayıp kod-tabanlı deneylerle optimize ediyor; teleprompter/optimizer algoritmaları talimatları ve few-shot örnekleri iteratif olarak ayarlıyor. Bu yazıda modern prompt engineering'i, DSPy'ı, eval-odaklı iş akışını ve context engineering'le ilişkisini anlatıyorum.

## Prompt engineering öldü mü, olgunlaştı mı?

Son yıllarda tekrarlanan bir söylenti var: "Modeller o kadar güçlendi ki artık prompt engineering'e gerek yok." Bu hem doğru hem yanlış. Doğru kısmı: basit görevlerde modeller artık kaba, özensiz talimatları bile iyi anlıyor. Yanlış kısmı: üretim düzeyi, güvenilir, ölçülebilir sistemler kurmak için prompt engineering asla bu kadar önemli olmamıştı. Fark şu: prompt engineering artık bir "sanat" değil, bir "mühendislik disiplini."

2026'nın tanımıyla prompt engineering: bir LLM'i hedef davranışa koşullandıran metni, yapıyı ve araç arayüzlerini tasarlamak, sürümlemek, test etmek ve optimize etmek — güvendiğiniz bir eval takımıyla puanlanarak. Anahtar kelime "eval". Bir prompt'un iyi olup olmadığını sezgiyle değil, bir değerlendirme setiyle ölçüyorsunuz. Bu, alanı "sezgisel kurcalama"dan "veri-odaklı iyileştirme"ye taşıyor.

## Manuel el işçiliğinden otomatik optimizasyona

Erken dönem prompt engineering, manuel el işçiliği ve sezgiye dayanıyordu: bir şeyler dene, çıktıya bak, kelimeleri değiştir, tekrar dene. Bu yaklaşım küçük ölçekte işe yarar ama uygulamalar büyüdükçe dağılır. Otomatik prompt optimizasyonuna ilgi tam da bu yüzden artıyor: manuel iyileştirmeden daha iyi sonuç veren otomatik stratejiler var artık.

İki temel araştırma yönü öne çıkıyor. Birincisi prompt'ları yapılandırılmış, modüler programlar olarak ele almak — yani prompt'u tek bir metin bloğu değil, bileşenlere ayrılmış bir sistem gibi görmek. İkincisi YZ geri bildirim döngüleriyle prompt'ları rafine etmek — modelin kendi çıktısını değerlendirip prompt'u iyileştirmesi. Bu iki yön birleştiğinde, prompt engineering el işçiliğinden kod-tabanlı, tekrarlanabilir bir mühendisliğe dönüşüyor.

## DSPy: prompt'u programla

DSPy, bu dönüşümün en görünür aracı. Açık kaynak bir çerçeve olan DSPy, LLM uygulama mantığını modüler biçimde tanımlamanıza ve prompt'ları kod-tabanlı deneylerle optimize etmenize izin veriyor. Fikir devrimci: siz ne istediğinizi bir "signature" (imza) ile bildiriyorsunuz — girdi ve çıktı tanımları — DSPy ise bu imzayı optimize edilmiş prompt'lara derliyor. Yani prompt'u elle yazmak yerine, hedefi tanımlayıp optimizasyonu çerçeveye bırakıyorsunuz.

DSPy, teleprompter/optimizer algoritmaları içeriyor: talimatları ve few-shot örnekleri iteratif olarak ayarlayarak görev performansını artıran yöntemler. MIPRO ve OPRO gibi optimizer'lar, prompt uzayını sistematik arayarak en iyi kombinasyonu buluyor. Yayımlanan karşılaştırmalarda DSPy'ın manuel prompt'lamaya göre belirgin kalite iyileşmesi sağladığı raporlanıyor. Ama abartıya kaçmayalım: DSPy her problem için gerekli değil; asıl değeri, iyi tanımlı bir eval metriğiniz olduğunda ortaya çıkıyor.

### Prompt engineering olgunluk merdiveni

| Seviye | Yaklaşım | Ne zaman |
|---|---|---|
| 0 | Sezgisel, tek seferlik prompt | Hızlı prototip |
| 1 | Şablonlaştırılmış, sürümlü prompt | Tekrar eden görev |
| 2 | Eval seti ile ölçülen prompt | Üretim öncesi |
| 3 | Otomatik optimizasyon (DSPy) | Ölçekli, metrik-odaklı sistem |

## Eval olmadan optimizasyon olmaz

Bu yazının en kritik mesajı: bir değerlendirme (eval) setiniz yoksa, hiçbir optimizasyon anlamlı değil. Neyi optimize ettiğinizi bilmiyorsanız, bir prompt'un "daha iyi" olduğunu nasıl söylersiniz? Bu yüzden modern prompt engineering'in ilk adımı prompt yazmak değil, eval kurmak. Temel işlevselliği, uç durumları ve bilinen hata modlarını kapsayan bir regresyon test seti oluşturun, her prompt değişikliğinde CI'da çalıştırın.

Değerlendirme metrikleri göreve bağlı. Bir RAG sisteminde sadakat (faithfulness) ve alaka düzeyi (relevancy); bir sınıflandırmada doğruluk; bir üretim görevinde bir yargıç-model (LLM-as-judge) ile kalite skoru. Tam değerlendirme takımını haftalık bir kadansta veya büyük sürümlerden önce çalıştırın. Bu disiplin, prompt'ları "umarım işe yarar" belirsizliğinden "ölçtük, iyileşti" kesinliğine taşır.

## Context engineering ile ilişki

Prompt engineering'in kardeş disiplini context engineering. Fark şu: prompt engineering talimatın kendisiyle ilgilenir; context engineering ise modele hangi bağlamı, hangi sırada, hangi biçimde verdiğinizle. Uzun bağlam pencereleri ve RAG çağında, modele ne söylediğiniz kadar ne gösterdiğiniz de önemli. En iyi prompt bile, yanlış veya gürültülü bağlamla başarısız olur.

Pratikte ikisi birlikte çalışır. İyi bir üretim sistemi hem net, optimize edilmiş bir talimat (prompt engineering) hem de doğru, temiz, alakalı bağlam (context engineering) sunar. RAG hattınızdaki reranker context engineering'dir; o bağlamı nasıl yorumlayacağını söyleyen talimat prompt engineering. Ölçüm her ikisini de kapsamalı: bağlam kalitesi mi düştü, talimat mı zayıf?

## Yapılandırılmış çıktı ve prompt zincirleme

Üretim prompt engineering'in iki pratik tekniği daha var. Birincisi yapılandırılmış çıktı: modelden serbest metin yerine belirli bir şema (JSON gibi) üretmesini istemek. Bu, çıktıyı programatik olarak işlenebilir kılar ve hata oranını düşürür. İkincisi prompt zincirleme: karmaşık bir görevi tek dev prompt yerine, her biri tek işi yapan küçük adımlara bölmek. Zincirleme, hem doğruluğu artırır hem de her adımı ayrı ayrı test etmenizi sağlar.

Chain-of-thought (düşünce zinciri) prompting, akıl yürütme görevlerinde adım adım ara adımlar üreterek performansı artırıyor; self-consistency ise birden çok akıl yürütme yolu örnekleyip en tutarlısını seçerek doğruluğu yükseltiyor. Bunlar 2026'da hâlâ değerli teknikler, ama artık bir eval çerçevesi içinde, ölçülerek uygulanıyorlar — sezgisel değil, kanıta dayalı.

## Türkçe bağlamı: dile özgü prompt mühendisliği

Türkçe iş yüklerinde ek bir katman var. İngilizce için optimize edilmiş bir prompt, Türkçe'ye çevrildiğinde aynı performansı göstermeyebilir; dilin yapısı, terminoloji ve kültürel bağlam farklı. Türkçe prompt'ları Türkçe eval setiyle optimize etmek şart. Ayrıca çok-dilli sistemlerde, modelin hangi dilde düşünüp hangi dilde yanıtladığını netleştiren talimatlar önemli. Kendi Türkçe verinizden bir değerlendirme seti kurmadan, global "en iyi prompt" tavsiyelerine körü körüne güvenmeyin.

## Pratik yol haritası

Modern prompt engineering'e geçiş için sıram: Önce bir eval seti kurun — kendi verinizden temsili örnekler, uç durumlar ve bilinen hatalar. Prompt'larınızı sürümleyin ve CI'a bağlayın; her değişiklik ölçülsün. Yapılandırılmış çıktı ve prompt zincirleme gibi tekniklerle güvenilirliği artırın. Manuel iyileştirme sınırına geldiğinizde DSPy gibi bir otomatik optimizasyon çerçevesi ekleyin — ama yalnızca sağlam bir metriğiniz varsa. Context engineering'i unutmayın: talimat kadar bağlam kalitesi de önemli. Türkçe iş yüklerinde dile özgü değerlendirme yapın.

Prompt engineering 2026'da bir sanat olmaktan çıkıp bir mühendislik disiplinine dönüştü. "Daha iyi bir cümle yaz" ile "eval setine karşı optimize et" arasındaki bu yelpazede nerede duracağınız, sisteminizin ölçeğine ve kritikliğine bağlı. Hızlı bir prototip için sezgisel bir prompt yeter; üretim düzeyi, güvenilir bir sistem için ise ölçüm ve optimizasyon şart. Anahtar ilke değişmedi: ölçemediğinizi iyileştiremezsiniz. Prompt'u bir tahmin değil, ölçülen ve iyileştirilen bir mühendislik çıktısı olarak ele aldığınızda, gerçek üretim değeri ortaya çıkar.