Prompt Mühendisliği: Gerçekten İşe Yarayan Teknikler ve Pratik İpuçları

Büyük dil modelleri, onlara verdiğin talimat kadar iyi çalışır. Özensiz bir prompt yazarsan belirsiz, dağınık çıktılar alırsın. Aynı modele iyi tasarlanmış bir prompt verdiğindeyse uzman seviyesinde sonuçlar elde edersin. İşte bu fark, prompt mühendisliğini sıradan bir deneme-yanılmadan gerçek bir disipline dönüştürdü.

Prompting Neden Bir Mühendislik Disiplini?

"Mühendislik" kelimesini bilerek kullanıyorum. Bu iş akıllıca sorular sormakla ilgili değil — tekrarlanabilir, test edilebilir, versiyon kontrollü promptlar üretmekle ilgili. Bir chatbot'u besleyen production prompt, kritik bir API endpoint'i kadar titizlikle inceleniyor. Çünkü aslında o da öyle bir şey.

Bunu tetikleyen birkaç şey var. Birincisi, modeller ifade sırasına, kelime seçimine ve biçimlendirmeye inanılmaz duyarlı — küçük değişiklikler çıktıyı tamamen değiştirebiliyor. İkincisi, büyük modelleri fine-tune etmek pahalı, bu yüzden çoğu ekip için prompting birincil özelleştirme aracı. Üçüncüsü, modeller güçlendikçe acemi ile uzman prompting arasındaki fark da büyüyor. İyi bir prompt, sıradan talimatlarla uyuyan yetenekleri açığa çıkarabiliyor.

İyi bir prompt ile harika bir prompt arasındaki fark zeka değil, netliktir. Modeller satır aralarını okumaz. Onlara verdiğin satırları takip eder.

Prompt altyapısına yatırım yapan ekipler — prompt kütüphaneleri, değerlendirme araçları, A/B test pipeline'ları — promptları tek kullanımlık string olarak gören ekipleri sürekli geride bırakıyor. Getirisi çıktı kalitesinde, tutarlılıkta ve maliyet verimliliğinde görülüyor.

Zero-Shot, Few-Shot ve Chain-of-Thought Prompting

Zero-Shot Prompting

Zero-shot en basit yaklaşım: görevi tarif ediyorsun ama örnek vermiyorsun. Tamamen modelin mevcut bilgisine güveniyorsun. Basit işlerde — özetleme, çeviri, temel sınıflandırma — genellikle yeterli oluyor. Ama iş alana özgü formatlara, ince değerlendirmelere ya da çok adımlı akıl yürütmeye geldiğinde hızla yetersiz kalıyor.

Few-Shot Prompting

Few-shot prompting'de asıl sorudan önce bir veya birkaç girdi-çıktı örneği veriyorsun. Bu örnekler örtük talimat gibi çalışır: modele beklediğin formatı, tonu, detay seviyesini ve akıl yürütme stilini gösterir. Araştırmalar, few-shot'un karmaşık görevlerde zero-shot'a göre %15-40 daha iyi performans gösterdiğini tutarlı şekilde ortaya koyuyor.

Pratikte gördüğüm şey şu: kalite her zaman miktardan önemli. İyi seçilmiş üç örnek, vasat on örnekten daha iyi sonuç veriyor. Örneklerin uç durumları kapsaması, çıktı formatının tamamını göstermesi ve yanlılık yaratmaması gerekiyor. Çeşitlilik ve netlik, hacimden daha değerli.

Chain-of-Thought ile Akıl Yürütme

Chain-of-thought (CoT) prompting, modelden son cevabı vermeden önce adım adım düşünmesini istiyor. Matematik, mantık, sağduyu gerektiren sorular ve çok atlamalı soru-cevap görevlerinde performansı ciddi şekilde artırıyor. Mantık basit: model "sesli düşündüğünde" sessizce biriken hataları yakalıyor.

CoT'u tetiklemek için prompt'un sonuna "Adım adım düşün" yazmak bile yeterli olabiliyor. Ya da detaylı akıl yürütme izleri içeren few-shot örnekleri verebilirsin. Daha gelişmiş versiyonları da var: birden fazla akıl yürütme yolunu keşfeden tree-of-thought ve birden fazla CoT tamamlaması örnekleyip çoğunluk cevabını seçen self-consistency gibi.

Sistem Promptları ve Talimat Tasarımı

Sistem promptu, her şeyin üzerine inşa edildiği temel. Modelin kişiliğini, kısıtlamalarını ve davranış kurallarını burada tanımlıyorsun. İyi bir sistem promptu, modelin ne yapacağı konusunda net, ne yapmayacağı konusunda açık ve beklenen çıktı formatı hakkında kesin olmalı.

Ben sistem promptlarını tutarlı bölümlere ayırıyorum: rol tanımı, görev bağlamı, davranış kısıtlamaları, çıktı formatı ve belirsiz durumlar için yedek talimatlar. Her bölüm özlü ama eksiksiz — gereksiz tekrar yok, atlanan kritik bilgi de yok.

Sen kıdemli bir finansal analist asistanısın.

ROL:
- Yalnızca kullanıcı tarafından sağlanan verilere dayalı analiz yap.
- Kesin finansal terminoloji kullan.
- Asla istatistik uydurmayın veya sağlanmamış kaynaklar belirtme.

ÇIKTI BİÇİMİ:
- Bir cümlelik bir yönetici özeti ile başla.
- Temel bulguları kapsayan 3-5 madde işareti ile devam et.
- Düşük / Orta / Yüksek olarak derecelendirilen bir risk değerlendirmesi ile bitir.

KISITLAMALAR:
- Kullanıcı finansal analiz dışında tavsiye isterse, kibarca reddet.
- Bir sonuç için veriler yetersizse, hangi ek verilerin gerekli olduğunu belirt.
- Kullanıcı aksini belirtmedikçe parasal değerleri her zaman USD cinsinden ifade et.

Yukarıdaki promptun sorumlulukları ayrı bölümlere nasıl ayırdığına dikkat et. Bu modülerlik, promptu bakımı, test etmeyi ve genişletmeyi kolaylaştırıyor. Her kısıtlama belirsiz bir öneri değil, net bir yönerge. Sistem promptlarında belirsizlik öngörülemeyen davranışlara yol açar — netlik bunun çözümü.

İnsanların hafife aldığı bir konu da negatif talimatlar. Modele ne yapmaması gerektiğini söylemek, ne yapması gerektiğini belirtmek kadar önemli. Açık kısıtlamalar olmadan model eğitim dağılımına geri dönüyor — bu da tıbbi tavsiye verme, güvenlik kontrolsüz kod üretme veya istemediğin uzunlukta yanıtlar oluşturma gibi sonuçlar doğurabiliyor.

Yapılandırılmış Çıktı Kalıpları

Prompt mühendisliğinin en pratik kullanım alanlarından biri, dil modellerinden yapılandırılmış veri çıkarmak. API için JSON, config için YAML, rapor için markdown tablo — hangisi olursa olsun, yapılandırılmış çıktı prompting'i modelin yanıtını kırılgan regex'ler olmadan programatik olarak parse etmeni sağlıyor.

En güvenilir tarif üç bileşen içeriyor: açık bir format belirtimi, somut bir örnek ve bir şema açıklaması. Üçü bir arada olduğunda modeller %95'in üzerinde güvenilirlikle geçerli yapılandırılmış çıktı üretiyor. Sadece format belirtimiyle? Yaklaşık %60. Fark çok büyük.

import openai
import json

def extract_entities(text: str) -> dict:
    """Yapılandırılmamış metinden yapılandırılmış varlıkları çıkarır."""
    response = openai.chat.completions.create(
        model="gpt-4o",
        response_format={"type": "json_object"},
        messages=[
            {
                "role": "system",
                "content": """Metinden varlıkları çıkar ve geçerli JSON döndür.
Şema:
{
  "people": [{"name": str, "role": str}],
  "organizations": [{"name": str, "industry": str}],
  "dates": [{"value": str, "context": str}],
  "confidence": float  // 0.0 ile 1.0 arası
}

Bir varlık alanı belirsizse, null olarak ayarla.
YALNIZCA JSON nesnesi döndür, yorum ekleme.""",
            },
            {"role": "user", "content": text},
        ],
    )

    return json.loads(response.choices[0].message.content)


# Kullanım
result = extract_entities(
    "NovaTech CTO'su Sarah Chen, 5 Mart'ta şirketin "
    "GlobalAI Labs ile ortaklık kuracağını duyurdu."
)
print(json.dumps(result, indent=2))
# {
#   "people": [{"name": "Sarah Chen", "role": "CTO"}],
#   "organizations": [
#     {"name": "NovaTech", "industry": null},
#     {"name": "GlobalAI Labs", "industry": "AI"}
#   ],
#   "dates": [{"value": "5 Mart", "context": "ortaklık duyurusu"}],
#   "confidence": 0.92
# }

Bu kod kopyalamaya değer birkaç kalıp gösteriyor. Şema tür açıklamalarıyla satır içi tanımlı, nullable alanlara açıkça izin verilmiş ve güven puanı sayesinde alt sistemler eşik değerleri uygulayabiliyor. response_format parametresi de modeli geçerli JSON üretmeye zorluyor ve en yaygın hata modlarından birini ortadan kaldırıyor.

Değerlendirme ve İterasyon Çerçevesi

Değerlendirme olmadan prompt mühendisliği tahmin yürütmektir. Sağlam bir değerlendirme çerçevesi, öznel izlenimleri ölçülebilir metriklere dönüştürür. Başarı kriterlerini tanımlayarak başla: doğruluk, format uyumu, ton tutarlılığı, gecikme, maliyet. Her kriter için bir ölçüm yöntemi gerekiyor — otomatik puanlama, insan değerlendirmesi ya da ikisinin birleşimi.

Değerlendirme döngüsü dört aşamadan oluşuyor. Önce mevcut promptu 50-100 örneklik ayrılmış bir test setinde çalıştırıp temel oluştur. Sonra hataları kategorize et — model ne tür yanlışlar yapıyor? Ardından en sık karşılaşılan hata modlarına yönelik promptu değiştir. Son olarak aynı test setiyle yeniden değerlendir ve karşılaştır. Kalite çıtanı yakalayana kadar bu döngüyü tekrarla.

1. Ölçülebilir başarı kriterleri belirle (doğruluk, format uyumu, ton, gecikme).
2. Normal durumları, uç durumları ve düşmanca girdileri kapsayan çeşitli bir değerlendirme veri seti oluştur.
3. Temel değerlendirmeyi çalıştır ve metrikleri kaydet.
4. Hata modlarını kategorize et: olgusal hatalar, format ihlalleri, halüsinasyonlar, yanıt reddi.
5. Hedefli prompt değişiklikleri yap — neyin işe yaradığını görmek için her seferinde tek bir değişiklik.
6. Yeniden değerlendir ve karşılaştır. Metrikleri iyileştireni koru, bozanı geri al.
7. Production performansını sürekli izle ve yeni hataları değerlendirme setine geri besle.

Otomatik değerlendirme için birçok seçenek var: yapılandırılmış çıktılar için tam eşleşme, özetleme için ROUGE ve BERTScore, ayrı bir modelin birincil modelin çıktısını notladığı LLM-jüri yaklaşımları. Yaratıcı yazarlık veya konuşma kalitesi gibi öznel görevlerde insan değerlendirmesi hâlâ altın standart — daha yavaş ve pahalı ama nüans konusunda rakipsiz.

Yaygın Tuzaklar ve Anti-Kalıplar

Deneyimli kişiler bile bu tuzaklara düşüyor. Her birini production sistemlerde gördüm. Tanımak, kaçınmanın ilk adımı.

• Aşırı prompting: Tek bir promptun içine çok fazla talimat tıkmak çakışmalara ve performans düşüşüne yol açar. Modellerin dikkati sınırlı — en kritik yönergeleri önceliklendir.
• Belirsiz kısıtlamalar: "Kısa ol" veya "yardımcı ol" öznel ifadeler. Bunların yerine kelime sayısı, madde işareti limiti veya yanıt şablonu ver.
• Model sınırlamalarını görmezden gelme: Modelin canlı verilere, URL'lere veya harici API'lere eriştiğini varsayan promptlar halüsinasyon üretir. Hangi verilerin mevcut olduğunu açıkça belirt.
• Yedek davranış eksikliği: Modelin belirsiz veya kapsam dışı girdiyle karşılaştığında ne yapacağını tanımlamazsan öngörülemeyen yanıtlar alırsın. Her zaman yedek talimat ekle.
• Örnek sızıntısı: Test durumlarına çok benzeyen few-shot örnekleri, gerçek dünya doğruluğunu artırmadan performans tahminlerini şişirir. Değerlendirme örneklerini eğitim örneklerinden ayrı tut.
• Karmaşık görevlerde tek geçiş: Tek bir prompttan analiz, formatlama ve kalite kontrolü aynı anda beklemek. Karmaşık işleri sıralı adımlara böl, her adıma kendi odaklı promptunu ver.

Daha ince bir sorun da var: prompt kırılganlığı. Bugünkü model versiyonunda harika çalışan bir prompt, güncellemeyle bozulabiliyor. Bunu önlemek için belgelenmemiş davranışlara güvenme, promptları birden fazla model versiyonunda test et ve küçük yorum farklılıklarına dayanıklı promptlar tasarla.

Temel Çıkarımlar

Prompt mühendisliği kesinlik, ölçüm ve iterasyonla gelişen bir disiplin. Bu yazıda ele aldığımız teknikler — zero-shot ve few-shot prompting, chain-of-thought, yapılandırılmış sistem promptları, şema güdümlü çıktılar ve sistematik değerlendirme — güvenilir LLM destekli uygulamalar için sağlam bir araç seti sunuyor.

• Promptları kod gibi ele al: versiyonla, test et, gözden geçir.
• Few-shot örneklerini stratejik kullan — kalite her zaman miktardan önemli.
• Chain-of-thought, başka türlü ulaşamayacağın akıl yürütme kapasitesini açığa çıkarır.
• Sistem promptlarını net bölümlerle yapılandır: rol, format, kısıtlamalar, yedekler.
• Yapılandırılmış çıktıları alt sistemlere göndermeden önce mutlaka şemaya karşı doğrula.
• Ölçülebilir kriterler ve çeşitli bir test setiyle değerlendirme döngüsü kur.
• Aşırı prompting yapma, belirsiz kalma ve her şeyi tek geçişte çözmeye çalışma.

Modeller gelişmeye devam edecek ama prompt mühendisliğinin temelleri değişmeyecek: niyet netliği, talimat özgüllüğü ve değerlendirme titizliği. Bu üç şeyi iyi yapan ekipler, hangi modeli, hangi sağlayıcıyı, hangi nesli kullanırsa kullansın güçlü sonuçlar alır.