Prompt mühendisliği: ileri teknikler ve model optimizasyonu

Prompt mühendisliği neden “optimizasyon” işidir?

Prompt mühendisliği, tek seferlik “iyi bir metin yazma” görevi olmaktan çok, bir ürün optimizasyonu sürecidir: hedefi netleştirir, çıktıyı ölçer, hataları sınıflandırır ve yinelemeli olarak iyileştirirsiniz. Bu yaklaşım özellikle üretim ortamında önem kazanır; çünkü aynı prompt, farklı içerikler ve farklı kullanıcı bağlamlarında farklı sonuçlar verebilir.

TL;DR

• Sözleşme kurun: Kalıcı davranış ve formatı system/developer mesajlarında netleştirin.
• Ölçerek ayarlayın: few-shot, temperature/top_p ve chaining kararlarını küçük eval setleriyle test edin.
• Adımlara bölün: Karmaşık görevleri chaining + doğrulama (gate) ile yönetilebilir hale getirin.

Hızlı gezinti: Mesaj rolleri · Few-shot · Temperature/top_p · Prompt chaining · Reasoning odaklı tasarım · Evals · Uçtan uca reçete

Bu yazı; system/developer mesajları ile yönlendirme, few‑shot örnek tasarımı, temperature/top_p ayarları, prompt chaining ve eval‑driven geliştirme gibi ileri teknikleri “nasıl uygularım?” odağında ele alır. Çerçeve; sağlayıcı dokümantasyonu (S1), hakemli few-shot/chaining çalışmaları (S2, S3) ve evals yaklaşımı (S4) üzerine kuruludur. İlgili bağlantılar: OpenAI Prompt Engineering Guide, OpenAI Responses API (temperature/top_p vb.), JAMIA (dinamik few-shot), MDPI (hiyerarşik chaining), Anthropic (evals).

1) Mesaj rolleri: system/developer mesajlarıyla davranışı sabitleyin

Sohbet tabanlı API’lerde model davranışı çoğu zaman “tek bir prompt”tan ziyade, mesaj rolleri (ör. system/developer/user) ve bu rollere verilen talimatların netliğiyle şekillenir. Pratikte kalıcı kurallar (kapsam, format, güvenlik sınırları) için system/developer mesajlarını, anlık istekler içinse kullanıcı mesajını kullanmak daha yönetilebilir bir yapı sunar (S1).

Ne zaman developer/system mesajı kullanılır?

• Politika ve kapsam: “Sadece şu konu aralığında cevap ver”, “tıbbi/finansal tavsiye verme” gibi çerçeveler.
• Çıktı formatı: Madde madde, tablo, kısa özet + detay gibi yapılar.
• Araç kullanımı/ajan akışı: Birden fazla adıma bölünecekse rol ve sırayı tarif etmek.
• Dil/ton: Türkçe, sade dil, teknik terimleri kısaca açıklama gibi.

Uygulanabilir bir şablon

Aşağıdaki şablonu “developer” mesajı olarak konumlandırmak, kullanıcıdan gelen istekler değişse bile temel davranışı daha stabil tutmaya yardımcı olur (S1):

Developer mesajı şablonu
Amaç: [tek cümleyle hedef]
Kapsam: [hangi konular dahil / hariç]
Hedef kitle: [ör. genel kitle, başlangıç seviyesi]
Çıktı formatı: [ör. h2/h3 başlıklar, madde listeleri, kısa özet]
Kısıtlar: [varsayım yapma, belirsizse soru sor, emin değilsen belirt]
Kalite kontrol: [çelişki kontrolü, zorunlu alan doğrulama, gerekirse alternatifler]

Pratik ipuçları

• Çakışmaları azaltın: Kullanıcı isteği formatı bozuyorsa, developer mesajında formatı “sözleşme” gibi tanımlamak tutarlılığı artırır.
• Belirsizlik kuralı ekleyin: “Emin değilsen belirt, gerekiyorsa netleştirici soru sor” yönergesi, aşırı kesin ifadeleri azaltmaya yardımcı olur (S1).
• Gizli düşünce yerine doğrulama isteyin: Uzun “iç düşünce” talep etmek yerine, net çıktı + kısa kontrol listesi veya doğrulama adımı istemek, üretimde yönetimi kolaylaştıran bir pratik olabilir (S1).

2) Few‑shot ileri teknikleri: örnekler “miktar” değil “uygunluk” işidir

Few‑shot prompting, modele birkaç örnek göstererek beklenen davranışı öğretme yaklaşımıdır. Kritik nüans şu: örnek sayısını artırmak her görevde otomatik bir iyileşme garantilemez. Görev türü, bağlam uzunluğu ve örneklerin temsil gücü sonucu belirgin şekilde etkiler; bu nedenle en sağlıklı yaklaşım küçük bir eval setiyle doğrulamaktır (S2, S4).

Örnek seçimi için kontrol listesi

• Temsil gücü: Gerçek kullanıcı taleplerinizdeki çeşitliliği kapsıyor mu?
• Sınır durumlar: Kolay örnekler kadar zor/kenar vakalar da var mı?
• Format tutarlılığı: İstenen çıktı biçimi her örnekte aynı mı?
• Gürültü kontrolü: Örnekler çelişen talimatlar taşıyorsa (ton, format, kapsam), modelin kararsızlaşma ihtimali artabilir.

Dinamik few‑shot: sabit örnekler yerine “en uygun örnekleri seçme”

Hakemli bir çalışmada, örnekleri bağlama göre dinamik seçmenin (ör. benzer örnekleri çekme) belirli sınıflandırma görevlerinde fayda sağlayabildiği gösterilmiştir (S2). Üretim sistemlerinde basit bir uygulama yaklaşımı:

1. Örnek kütüphanesi oluşturun (küçük başlayın; kaliteyi önceleyin).
2. Kullanıcı girdisi için benzerlik araması yapın (vektör arama/embedding veya basit eşleşme).
3. En benzer 2–5 örneği prompta ekleyin.
4. Etkiyi eval ile ölçün: format uyumu, hata türleri, insan puanı vb. (S4).

Not: “İdeal shot sayısı” için evrensel bir standart yoktur. Model, görev ve token bütçesine göre ölçümle ayarlamak daha güvenlidir (S2, S4).

3) Temperature ve top_p: deterministiklik–yaratıcılık dengesini yönetin

Temperature ve top_p, örnekleme davranışını etkileyerek çıktının rastlantısallığını kontrol eden parametrelerdir. Genel olarak düşük değerler daha tutarlı/tekrarlanabilir, yüksek değerler daha çeşitli çıktılar üretebilir (S1).

Pratik bir optimizasyon yöntemi olarak, tek seferde bir parametreyi değiştirip diğerini sabit tutmak (ör. temperature taraması yaparken top_p’yi sabit bırakmak) kıyaslamayı kolaylaştırır (S1).

Hangi görevde hangi yaklaşım?

Mini pratik: parametre taraması

• Küçük bir eval seti seçin (20–50 örnek, başlangıç için yeterli olabilir).
• 2–3 temperature değeri deneyin; top_p’yi sabit tutun (veya tersi) (S1).
• Başarı ölçütünüzü önceden tanımlayın: format uyumu, hata türleri, insan değerlendirmesi vb. (S4).

4) Prompt chaining: karmaşık işleri doğrulanabilir adımlara bölün

Tek bir büyük prompt, karmaşık görevlerde hata ayıklamayı zorlaştırabilir. Prompt chaining ise görevi adımlara bölerek her adımı daha küçük, kontrol edilebilir hale getirir. Bu yaklaşım belirli senaryolarda tutarlılığı artırabilir; buna karşılık daha fazla çağrı nedeniyle gecikme (latency) ve token maliyeti artışı gibi maliyetleri vardır (S3, S4).

3 adımlı pratik zincir şablonu

1. Planla: Girdiyi analiz et, hedefleri çıkar, alt görevlere ayır.
2. Üret: Asıl çıktıyı oluştur (format kısıtlarıyla).
3. Doğrula: Çıktıyı kriterlere göre kontrol et; sorun varsa düzelt.

Hiyerarşik/çok aşamalı zincirleme yaklaşımlar, özellikle sorgu yeniden yazımı gibi görevlerde metodolojik bir çerçeve olarak tartışılır (S3). Üretimde hedef, “sonsuz zincir” değil; en az adımla yeterli kaliteyi yakalamaktır.

Chaining’i daha güvenli hale getiren iki teknik

• Ara çıktı sözleşmesi: Her adımın çıktısı net bir formatta olsun (ör. madde listesi). Bu, bir sonraki adımın belirsizliğini azaltır.
• Ara özet/kompresyon: Zincir uzuyorsa, bir ara adımda kısa özet alıp bir sonraki adıma yalnızca özeti geçirmek maliyeti ve bağlam karmaşıklığını azaltabilir (S3).

5) Reasoning odaklı modellerle prompt tasarımı: daha kısa, daha net

Sağlayıcı rehberlerinde, bazı reasoning odaklı kurulumlarda uzun “adım adım düşün” talimatları yerine hedefi, kısıtları ve çıktı formatını netleştirmenin çoğu zaman yeterli olabildiği; geri kalan kaliteyi ise doğrulama/eval adımlarıyla yönetmenin daha uygulanabilir olduğu yönünde pratik öneriler yer alır (S1, S4). Bu, her görev için tek yaklaşım değildir; yine de aşağıdaki faydaları sağlayabilir:

• Gereksiz uzun promptları azaltma (daha düşük maliyet, daha düşük karmaşıklık).
• Format uyumunu artırma (özellikle developer mesajıyla iyi tanımlanırsa).
• Doğrulamayı öne alma (çıktıyı kontrol listesi/gate ile test etme) (S4).

Uygulanabilir talimat örnekleri

• “Sadece nihai cevabı ver ve en fazla 3 maddede gerekçelendir.”
• “Belirsiz kısımlar varsa önce 2 netleştirici soru sor; soru soramıyorsan varsayımlarını açıkça belirt.”
• “Çıktıyı şu şemaya göre yaz: Özet, Adımlar, Riskler, Sonraki aksiyon.”

6) Evals ve üretim güvenilirliği: ölçmeden optimize edilmez

Çok adımlı ajan sistemleri ve araç kullanan akışlarda kaliteyi yalnızca gözle yönetmek zorlaşır. Anthropic’in evals odaklı mühendislik yazısı, ajanlar için eval‑driven development yaklaşımını; otomatik ölçüm, test setleri ve üretim öncesi/sonrası değerlendirmelerin önemini vurgular (S4). Chaining ve few-shot gibi desenlerin gerçek etkisini görmek için de düzenli ölçüm gerekir (S3, S4).

Basit bir eval‑driven iş akışı

1. Hata taksonomisi çıkarın: format hatası, gerçek dışı iddia, eksik kapsam, yanlış ton vb.
2. Küçük bir altın set oluşturun: gerçek kullanıcı örneklerinden 30–100 giriş seçin.
3. Otomatik kontroller: format doğrulama, uzunluk, zorunlu alanlar, link güvenliği vb.
4. İnsan değerlendirmesi: özellikle doğruluk ve yararlılık için örneklem kontrolü.
5. Regresyon: Prompt değişince eski testleri tekrar çalıştırın.

“Gate” mantığı: ara adım kontrolleri

Özellikle ajan akışlarında, her adımı “kalite kapısından” geçirmek pratik bir güvenlik yaklaşımıdır (S4). Örnek gate’ler:

• PII/mahrem bilgi var mı?
• İstenen format sağlandı mı?
• Yanıt, kullanıcı hedefiyle çelişiyor mu?
• Kaynak gerektiren kısımlar, emin olunmayan yerlerde ihtiyatlı bir dille mi yazılmış?

7) Uçtan uca uygulama reçetesi: bir promptu üretime hazırlama

Adım 1: Görev tanımı ve başarı ölçütü

• Görev: “Müşteri e-postasını sınıflandır ve önerilen yanıt taslağı üret” gibi net bir tanım.
• Başarı ölçütü: format uyumu, doğru sınıflandırma, yanıt kalitesi, tekrar üretilebilirlik.

Adım 2: Developer mesajıyla sözleşme kurma

Davranışı sabitleyin: kapsam, ton, format ve belirsizlik yönetimi (S1).

Adım 3: Baseline (zero-shot) + few-shot varyantları

• Önce zero-shot ile temel performansı görün.
• Sonra 2–5 kaliteli örnek ekleyin.
• Performans dalgalanıyorsa, dinamik few-shot seçimini deneyin ve etkisini ölçün (S2, S4).

Adım 4: Parametre ayarı (temperature/top_p)

Tek bir parametreyi değiştirerek küçük bir tarama yapın ve eval setinde ölçün (S1, S4).

Adım 5: Chaining ile zor kısımları ayırma

• Ön işleme: amaç çıkarımı / bilgi toplama
• Üretim: asıl yanıt
• Doğrulama: kontrol listesi + düzeltme

Maliyet ve gecikmeyi ölçmeyi unutmayın; zincir uzunluğunu “yeterli” seviyede tutun (S3, S4).

Adım 6: Evals ile sürdürülebilirlik

Prompt değişiklikleri, model sürüm değişiklikleri ve yeni veri dağılımları için regresyon eval’leri planlayın (S4).

Yayın öncesi hızlı kontrol listesi

• Net amaç: Modelin “ne yapacağı” tek cümlede anlaşılır mı?
• Format sözleşmesi: Zorunlu alanlar ve örnek çıktı var mı?
• Belirsizlik politikası: Bilmiyorsa nasıl davranacağı tarifli mi?
• Few-shot kalitesi: Örnekler kısa, temsil gücü yüksek ve tutarlı mı?
• Parametre disiplini: Aynı anda birden fazla örnekleme parametresi değiştirilmiyor mu? (S1)
• Chaining maliyeti: Ek çağrıların gecikme/maliyet etkisi ölçüldü mü? (S3)
• Evals: Küçük bir test seti ve regresyon akışı var mı? (S4)

Sınırlamalar ve sorumlu kullanım notu

Bu teknikler, çıktıyı çoğu senaryoda daha tutarlı hale getirebilir; ancak tek başına doğruluk garantisi vermez. Model davranışı; veri dağılımı, prompt uzunluğu, araç entegrasyonları ve sürüm değişikliklerine duyarlıdır. Yüksek riskli alanlarda (sağlık, hukuk, finans gibi) üretim çıktıları için uzman incelemesi ve uygun güvenlik kontrolleri planlanmalıdır.

Kaynak çerçevesi: OpenAI dokümantasyonu (S1), dinamik few‑shot üzerine hakemli bulgular (S2), hiyerarşik prompt chaining analizi (S3), ajanlar için eval‑driven yaklaşım (S4).