Prompt’u iki kez yazınca model daha iyi mi anlıyor?
Bazen en etkili “prompt mühendisliği” numarası, en basit olanı çıkıyor: aynı prompt’u iki kez arka arkaya yazmak.
Google Research’ten Yaniv Leviathan, Matan Kalman ve Yossi Matias’ın arXiv’de yayımladığı “Prompt Repetition Improves Non-Reasoning LLMs” makalesi tam olarak bunu söylüyor:
Modelden “akıl yürütme / adım adım düşünme” istemediğiniz senaryolarda, prompt’u tekrar etmek doğruluğu artırabiliyor—hem de çıktı token’larını ve çoğu durumda gecikmeyi artırmadan.
Bu yazıda, makalenin ana fikrini “sahaya inen” bir dille anlatacağım: Ne yapmışlar, neden çalışıyor, ne zaman işe yarar, neye dikkat etmek gerekir?
Makalenin iddiası (tek cümleyle)
Reasoning kapalıyken (yani “sadece cevap ver”, “kısa yanıt ver” gibi modlarda) prompt’u iki kere yazmak, popüler modellerde (Gemini, GPT, Claude, DeepSeek) birçok benchmark’ta istatistiksel olarak anlamlı iyileştirme veriyor.
“Neden çalışsın ki?” kısmı: Causal dil modeli gerçeği
Çoğu LLM “decoder-only / causal” eğitimlidir:
Bir token, kendisinden sonra gelen token’lara bakamaz. Bu yüzden prompt içindeki sıralama (ör. “önce seçenekler sonra soru” gibi) performansı etkileyebilir. Makale de buradan yola çıkıyor. (arXiv)
Prompt’u tekrar edince (QUERY → QUERY+QUERY) ikinci kopyadaki token’lar, ilk kopyadaki tüm bağlamı “geçmiş” olarak görür. Böylece prompt’un bir kısmı, fiilen “daha zengin bağlamla” temsil edilir. Yazarların önerdiği temel dönüşüm bu. (arXiv)
Bu mantık, “echo embeddings” fikriyle de akraba: autoregressive modellerde erken token temsilinin, sonraki token bilgisini taşıyamaması sorununa tekrar ile çözüm öneren çalışmalar var. (arXiv)
Deneyler: Ne test etmişler?
7 popüler model: Gemini 2.0 Flash / Flash Lite, GPT-4o-mini, GPT-4o, Claude 3 Haiku, Claude 3.7 Sonnet, DeepSeek V3
7 benchmark + 2 özel görev (NameIndex, MiddleMatch)
Testler, resmi API’lerle Şubat–Mart 2025 döneminde yapılmış.
Sonuçlar: “Gerçekten fark ediyor mu?”
1) Reasoning yokken: net kazanım
Makalenin öne çıkardığı sayı:
70 model–benchmark kombinasyonunun 47’sinde kazanım, 0 kayıp.
Özellikle prompt sıralamasının “kötü” olduğu (ör. çoktan seçmelide options-first) kurulumlarda kazanım daha belirgin.
2) “Uçurum” örnek: NameIndex
Özel testlerden birinde (NameIndex), Gemini 2.0 Flash-Lite doğruluğu %21.33 → %97.33 gibi dramatik bir sıçrama gösteriyor.
3) Reasoning açılınca: nötr / hafif pozitif
“Let’s think step by step” gibi yönlendirmelerle (yani reasoning’li modlarda) etki çoğunlukla nötr, bazen hafif pozitif: 28 testte 5 win, 1 loss rapor ediyorlar.
“Peki hız?”: Gecikme ve çıktı uzunluğu
Yazarların iddiası: prompt repetition çıktı token’larını artırmıyor ve gecikmeyi de çoğu senaryoda artırmıyor; çünkü değişen kısım daha çok “prefill” tarafı ve bu kısım paralelleştirilebilir.
Ama ben bunu sahada şöyle okurum:
Çıktı süresi genelde aynı kalabilir (özellikle reasoning kapalıyken).
Girdi token’ı iki katına çıkar → API maliyeti (input cost) artabilir. (Makale “generated tokens” artmıyor diyor; input tarafı ayrı konu.)
Çok uzun promptlarda bazı sağlayıcılarda gecikme artışı görülebilir (yazarlar Anthropic tarafında uzun isteklerde artış olabildiğini not ediyor).
Ben bunu nerelerde kullanırım? (Endüstri + akademi)
Endüstride
Sınıflandırma / etiketleme (mail türü, ticket routing, risk seviyesi, kategori vb.)
Kısa yanıt üretimi (müşteri destek “tek paragraf net cevap”)
Bilgi çıkarımı (metinden alan–değer çekme; JSON üretimi)
Çoktan seçmeli kararlar (özellikle “seçenekler uzun, soru kısa” gibi durumlarda)
Akademide
Sınav/quiz oluşturma ve kontrol (kısa cevap + çoktan seçmeli)
Makaleden hızlı özet + ana bulgu çıkarımı (reasoning istemeden “bulguları maddele”)
Ders notlarını dönüştürme (öğrenme hedefi → slayt maddeleri → 5 soru)
Nasıl uygulanır? (En pratik hali)
Benim kullandığım en sade şablon:
Normal prompt’unu yaz
Hiçbir şeyi değiştirmeden aynısını altına yapıştır
Cevabı yine “kısa/tek cevap/format şu” diye sınırla
Örnek (mantık gösterimi):
<QUERY>
<QUERY>
Makalenin eklerinde, baseline ve repetition formatlarını yan yana örnekliyorlar.
Ne zaman kullanmam?
Prompt zaten çok uzunsa (context penceresini zorlayacaksa)
Zaten reasoning ile (adım adım) iyi sonuç alıyorsam (etki çoğunlukla nötr)
Maliyet çok kritikse (input token ikiye katlanacağı için)
Kapanış: “Küçük numara” gibi ama pratikte büyük kaldıraç
Ben bu makaleyi şu yüzden değerli buldum:
Prompt’un kendisini “daha iyi yazmak” yerine, modelin mimari sınırlılığına uygun bir hile öneriyor.
Üstelik uygulanması o kadar kolay ki: A/B test yapıp kendi iş akışınıza hemen ekleyebilirsiniz.
Eğer siz de denerseniz, en iyi başlangıç şu:
Reasoning’i kapatın + kısa cevap isteyin + prompt’u iki kez verin + doğruluğu ölçün.
Mühendisliğin Yapay Zeka Mentoru’ndaki bu yazıyı okuduğunuz için teşekkürler. Lütfen yazıyı ilgisini çekebileceğini düşündüğünüz bir arkadaşınızla ya da sosyal medyada paylaşın.
