Muhakeme Modelleri Çağında Prompt: Neden 'Adım Adım Düşün' Artık Zarar Veriyor?

TL;DR — Muhakeme modelleri (reasoning models) prompt yazma biçimimizi kökten değiştirdi. Klasik modellerde altın kural olan "adım adım düşün" talimatı, artık dahili olarak zaten muhakeme yapan modellerde çoğu zaman gereksiz, bazen de doğrudan zararlı. 2026'da işin merkezi "zekice soru yazmak"tan "bilgi sistemleri tasarlamak"a, yani bağlam mühendisliğine (context engineering) kaydı. Bu yazıda sahadan gözlemlerimle anlatıyorum: neden "step by step" geri tepiyor, muhakeme modeli ile klasik modeli farklı promptlamak gerektiği, ideal prompt uzunluğu (~150-300 kelime), sonuç odaklı promptlar, ajan desenleri (ReAct ve Plan-and-Execute), değerlendirme döngüleri, promptların versiyonlanan varlıklar haline gelmesi ve KVKK açısından prompt hijyeni. Sonunda uygulanabilir bir kontrol listesi var.

Geçen ay bir müşterimin ekibiyle bir atölye yaptım. Kıdemli bir yazılımcı, ekranını paylaşıp gururla bir prompt gösterdi: yaklaşık sekiz yüz kelimelik, içinde "önce şu adımı düşün, sonra bu adımı düşün, her adımı tek tek açıkla, aceleci olma, adım adım ilerle" diye başlayan devasa bir talimat metni. "Bunu bir yıldır kullanıyoruz, gayet iyi çalışıyor" dedi. Sonra aynı görevi, yeni nesil bir muhakeme modeline sadece net bir hedef cümlesiyle verdik. Sonuç daha isabetli, daha kısa sürede ve daha tutarlı geldi. Odada kısa bir sessizlik oldu. O sessizliği çok iyi tanıyorum; bir alışkanlığın artık işe yaramadığını fark ettiğiniz andaki sessizliktir.

Sahada gördüğüm en yaygın durum bu. İnsanlar 2023'ün prompt reçeteleriyle 2026'nın modellerini kullanmaya çalışıyor. Oysa modelin altındaki mimari değişti. Bugün "muhakeme modeli" dediğimiz sınıf, cevabı üretmeden önce içeride kendi kendine düşünen, adımlarını kuran, olası yolları tartan bir yapı. Yani sizin dışarıdan zorla dayattığınız "adım adım düşün" komutunu, model zaten kendi başına, hem de sizden daha disiplinli biçimde yapıyor. Siz o komutu eklediğinizde çoğu zaman ona yardım etmiyorsunuz; ayağına dolanıyorsunuz.

Bu yazıda size hem neyin değiştiğini hem de yeni düzende nasıl prompt yazılacağını, sahadan somut örneklerle anlatacağım. Amacım teori dökmek değil; yarın sabah açtığınızda işinizi kolaylaştıracak, elle tutulur bir çerçeve bırakmak.

Önce terimi netleştirelim, çünkü kavram karışıklığı burada başlıyor. Klasik bir dil modeli, size en olası bir sonraki kelimeyi üretir; düşünme süreci ile cevap üretme süreci iç içedir ve dışarıya pek görünmez. Bu modellerde "adım adım düşün" demek gerçekten işe yarardı, çünkü modeli cevaba atlamaktan alıkoyup ara adımları sesli düşünmeye zorluyordunuz. Buna literatürde düşünce zinciri (chain-of-thought) diyoruz ve yıllarca prompt mühendisliğinin bel kemiğiydi.

Muhakeme modelleri ise bu ara adımları içselleştirdi. Cevabı vermeden önce, bir tür "iç monolog" ile problemi parçalıyor, olasılıkları tartıyor, kendi çıkarımını kontrol ediyor ve ancak ondan sonra size nihai yanıtı sunuyor. Yani düşünce zinciri artık dışarıdan verdiğiniz bir talimat değil, modelin doğasında olan bir davranış. Fark tam olarak burada: eskiden muhakemeyi siz tetiklerdiniz, şimdi model muhakemeyi kendisi yürütüyor.

Bunun pratik sonucu şu: aynı prompt, iki farklı model sınıfında farklı davranır. Klasik bir modelde ayrıntılı düşünce zinciri talimatı performansı artırırken, bir muhakeme modelinde aynı talimat en iyi ihtimalle nötr, çoğu zaman ise zararlı olur. Çünkü modelin zaten yürüttüğü iç sürecin üstüne, sizin kaba ve dışsal adımlarınız biniyor; bu da onu kendi daha iyi akıl yürütme yolundan saptırabiliyor.

Buraya özellikle dikkat çekmek istiyorum, çünkü sahada en çok direnç gördüğüm nokta bu. İnsanlar yıllarca "step by step" yazarak iyi sonuç aldılar; bir refleks haline geldi. Ama muhakeme modellerinde bu refleks artık lehinize değil.

Sebebini bir benzetmeyle anlatayım. Diyelim ki karşınızda, bir problemi kendi yöntemiyle, sessizce ve hızlıca çözebilen usta bir matematikçi var. Siz sürekli araya girip "önce toplamayı yap, sonra çarpmayı yap, şimdi şunu kontrol et, acele etme, tekrar düşün" diye elini kolunu bağlarsanız ne olur? Onu kendi doğal ve daha verimli akışından koparırsınız. Muhakeme modelinde olan tam olarak budur. Model zaten daha zengin bir iç muhakeme yapıyorken, siz ona daha ilkel ve dışsal bir düşünme kalıbı dayatıyorsunuz. Sonuç: gereksiz uzayan, bazen de kalitesi düşen cevaplar.

Somut bir örnekle bakalım.

Eski alışkanlık (muhakeme modelinde geri tepen prompt):

"

Sen uzman bir finansal analistsin. Sana bir gelir tablosu vereceğim. Lütfen adım adım düşün. Önce her satır kalemini tek tek incele. Sonra her kalemi ayrı ayrı yorumla. Sonra oranları hesapla, her hesabı açıkça göster. Aceleci olma, her adımı gerekçelendir. Düşünme sürecini baştan sona yaz. En sonunda bir özet çıkar.

Bu prompt bir muhakeme modeline verildiğinde, model zaten kendi içinde yaptığı analizi bir de sizin dayattığınız kaba iskelete sığdırmaya çalışır; cevap şişer, gerçek içgörü seyrelir.

Yeni yaklaşım (sonuç odaklı, muhakeme modeline uygun):

"

Ekteki çeyreklik gelir tablosunu değerlendir. Bir CFO'nun yönetim kuruluna sunacağı, en fazla bir sayfalık bir risk ve fırsat notu istiyorum. Üç önemli olumlu sinyal, üç önemli risk ve önerilen tek bir aksiyon içersin. Sayısal iddiaların tablodaki verilere dayansın.

Farkı görüyor musunuz? İkinci promptta modele nasıl düşüneceğini söylemiyorum; ne üreteceğini, hangi biçimde ve hangi kısıtlarla üreteceğini söylüyorum. Muhakemeyi ona bırakıyorum, çünkü onu benden iyi yapıyor. Bu, tek cümlelik bir felsefe değişimi: "Nasıl düşün" demeyi bırakıp "ne üret" demeye geçmek.

Burada bir uyarı: Bu, düşünce zincirinin tamamen öldüğü anlamına gelmiyor. Klasik, muhakeme yapmayan hafif modellerle çalışıyorsanız veya çok özel bir çıktı formatını zorluyorsanız, ara adım talimatları hâlâ değerli olabilir. Mesele modeli tanımak. Yanlış olan, her modele aynı reçeteyi uygulamak.

Atölyelerde en çok gelen sorulardan biri: "Peki prompt ne kadar uzun olmalı?" İnsanların kafasında iki uç var. Bir grup, tek bir cümlelik muğlak sorularla model üzerine tüm yükü bırakıyor. Diğer grup ise, her ihtimali kapatmak isteyen, sayfalarca süren talimat metinleri yazıyor.

Sahadaki pratik tatlı nokta genellikle 150 ile 300 kelime arasında. Bu aralık tesadüf değil. Bu kadar bir alan, modele görevi, bağlamı, kısıtları ve istenen çıktı biçimini net anlatmaya yeter; ama modelin kendi muhakemesini boğacak kadar da fazla değildir. 300 kelimeyi aştığınızda çoğu zaman ya kendinizi tekrar ediyorsunuzdur ya da modele nasıl düşüneceğini fazla dikte ediyorsunuzdur; her ikisi de muhakeme modellerinde ters teper.

Bunu şöyle düşünün: iyi bir brief ile mikro yönetim arasındaki fark. İyi bir yöneticinin çalışanına verdiği brief nettir ama nefes alanı bırakır. Kötü yönetici ise her tuşa nasıl basılacağını anlatır. Muhakeme modeliyle çalışırken iyi bir yönetici olun; hedefi ve sınırları koyun, yolu modele bırakın.

Kısa bir öz-kontrol: Promptunuzu yazdıktan sonra kendinize sorun, "Bu cümle modele ne üreteceğini mi söylüyor, yoksa nasıl düşüneceğini mi?" Nasıl düşüneceğini anlatan cümlelerin çoğunu silebilirsiniz. Genellikle prompt kısaldıkça sonuç iyileşir.

Şimdi işin özüne geliyorum. Son iki yılın en önemli mesleki dönüşümü, işin ağırlık merkezinin "zekice sorular yazmak"tan "eksiksiz bilgi sistemleri tasarlamak"a kaymasıdır. Buna bağlam mühendisliği (context engineering) diyoruz. Anthropic bunu, yetenekli ajanlar çağında prompt mühendisliğinin doğal bir devamı olarak tanımlıyor; ben de sahada tam olarak bunu yaşıyorum.

Aradaki farkı en yalın haliyle şöyle koyabilirim:

• Prompt mühendisliği: Modele nasıl sorduğunuzla ilgilenir.
• Bağlam mühendisliği: Modelin ne gördüğüyle ilgilenir.

Bir muhakeme modeli ne kadar güçlü olursa olsun, önüne koyduğunuz bilgiden daha iyisini üretemez. Doğru belgeleri getirmemişseniz, hafızayı doğru kurmamışsanız, araçları doğru bağlamamışsanız, en zarif prompt bile boşlukta savrulur. İşte bu yüzden odak, tek bir metin kutusuna yazdığınız cümleden, modelin karar anında gördüğü tüm bilgi ortamına kaydı.

Bağlam mühendisliği pratikte şu bileşenleri kapsar:

• Sistem tasarımı: Modelin rolünü, kalıcı kurallarını ve sınırlarını belirleyen sistem katmanı. Bu, her istekte tekrar yazdığınız bir şey değil; sistemin omurgası.
• Getirme (retrieval): İlgili belgeleri, kayıtları, bilgi tabanı parçalarını tam ihtiyaç anında modele sunmak. Modelin kafasındaki genel bilgiyle yetinmek yerine, o ana özgü doğru veriyi önüne koymak.
• Hafıza (memory): Önceki etkileşimlerden, kullanıcı tercihlerinden veya süregelen bir görevin durumundan gelen bilgiyi taşımak. Tek seferlik promptun ötesine geçen her uygulama hafızaya ihtiyaç duyar.
• Araçlar (tools): Modelin bir hesap makinesi çağırması, bir API'ye gitmesi, bir veritabanını sorgulaması veya bir dosya okuması. Muhakeme modelinin gücü, doğru araçlarla birleştiğinde katlanır.

Dikkat edin: Bunların hiçbiri "daha iyi cümle kurma" meselesi değil. Bunlar sistem tasarımı meseleleri. İşte prompt mühendisliğinin yetersiz kaldığı yer tam burası: hafıza, çok adımlı muhakeme veya gerçek zamanlı bilgi gerektiren uygulamalarda tek başına prompt yazmak yetmiyor. O noktadan sonra mühendislik yapmanız gerekiyor.

OpenAI'ın güncel rehberliği de bu yöne işaret ediyor: sonuç odaklı promptlar. Fikir basit ama uygulaması disiplin ister. Modele izlemesi gereken adımların listesini vermek yerine, ulaşılmasını istediğiniz sonucu, üretilmesini istediğiniz somut çıktıyı (artifact) tarif edin.

Neden? Çünkü adımları siz dikte ettiğinizde, kendi sınırlı bakış açınızı modele dayatmış olursunuz. Oysa muhakeme modeli, hedefi net bilirse, ona giden en iyi yolu çoğu zaman sizden daha isabetli kurar. Sizin işiniz varış noktasını, başarı ölçütlerini ve kısıtları netleştirmek; rotayı çizmek değil.

İki örnekle netleştireyim.

Adım odaklı (eski):

"

Bir blog yazısı yazmak için önce bir başlık öner. Sonra beş alt başlık çıkar. Sonra her alt başlık için üç madde yaz. Sonra bu maddeleri paragrafa çevir. Sonra bir giriş ekle. Sonra bir sonuç ekle.

Sonuç odaklı (yeni):

"

KOBİ'lere yönelik, "yapay zekaya nereden başlamalı" konulu bir blog yazısı istiyorum. Hedef kitle teknik olmayan işletme sahipleri. Ton pratik ve cesaretlendirici olsun, jargon olmasın. 800-1000 kelime, sonunda üç maddelik somut bir ilk adım listesi bulunsun. Hazır olduğunda tek parça halinde ver.

İkinci promptta bir tek "adım" yok; sadece sonuç, kitle, ton, uzunluk ve biçim var. Modelin nasıl yazacağına karışmıyorum. Bu yaklaşım hem daha kısa prompt üretir hem de muhakeme modelinin güçlü yanını serbest bırakır.

Sonuç odaklı düşünmenin bir başka faydası: çıktıyı değerlendirmesi kolaylaşır. "Üç maddelik ilk adım listesi var mı?" sorusunun cevabı nettir. Adımları dikte ettiğinizde ise başarıyı ölçmek muğlaklaşır. Bu bizi bir sonraki başlığa götürüyor.

Tek seferlik bir soru-cevabın ötesine geçip, modelin araçlar kullanarak birden çok adımda iş yaptığı ajan (agent) senaryolarına girdiğimizde, promptlama yine değişiyor. Burada iki temel desen öne çıkıyor; ikisini de sahada sık kullanıyorum.

ReAct (Reason + Act): Modelin düşünmesi ile eylemesi bir döngü halinde ilerler. Model önce düşünür (şu an ne biliyorum, ne eksik), sonra bir araç seçer (arama yap, hesapla, sorgula), sonucu gözlemler, tekrar düşünür ve bir sonraki adıma karar verir. Bu desen, adımların önceden kestirilemediği, keşfe dayalı görevlerde çok güçlüdür. Örneğin "şu üç tedarikçinin fiyatlarını karşılaştır ve en uygununu öner" gibi bir görevde model, her adımda ne bulduğuna göre yolunu ayarlar.

Plan-and-Execute: Model önce baştan sona bir plan çıkarır, sonra bu planı sırayla uygular. Adımlar daha öngörülebilir olduğunda ve gidiş yolunu baştan görmek istediğinizde bu desen daha derli topludur. Örneğin "şu raporu üret" gibi, alt adımları büyük ölçüde belli olan görevlerde plan-yürüt yaklaşımı hem daha şeffaf hem de daha kolay denetlenebilir olur.

Bir de düşünce zincirini genişleten bir yapı var: Düşünce Ağacı (Tree of Thoughts). Klasik düşünce zinciri tek bir doğrusal akıl yürütme yolu izler; düşünce ağacı ise aynı anda birden çok muhakeme yolunu keşfeder, dallanır, umut vaat etmeyen dalları budar ve en iyi yolu seçer. Karmaşık, çok olasılıklı problemlerde bu yaklaşım tek bir zincirden daha zengin sonuç verebilir. Uygulamada bunu genellikle model altyapısı yönetir; sizin işiniz problemi buna uygun biçimde çerçevelemektir.

Bu desenleri seçerken pratik kılavuzum şu: Görevin yolu belirsiz ve keşif gerektiriyorsa ReAct; yol büyük ölçüde belli ve şeffaflık istiyorsanız Plan-and-Execute; olasılık uzayı geniş ve en iyi yolu aramak kritikse Düşünce Ağacı mantığı. Çoğu gerçek uygulamada bunların karışımını kullanırsınız.

Şimdi mesleğin en az konuşulan ama en belirleyici kısmına geliyorum: değerlendirme (evaluation) döngüleri. OpenAI'ın güncel rehberliği, kod tarafından yönetilen prompt sistemleri ve değerlendirme döngüleri üzerinde ısrarla duruyor. Sahadaki gerçek de bu: promptu bir kez yazıp bırakmak amatörlük; promptu ölçülebilir, versiyonlanabilir bir varlık gibi yönetmek profesyonelliktir.

Ne demek istiyorum? Bir prompt artık bir metin kutusuna yazdığınız geçici bir cümle değil. Ciddi bir uygulamada prompt, kod deposunda tutulan, sürümlenen, değişiklikleri kaydedilen bir varlıktır. Tıpkı kod gibi. Bir promptu değiştirdiğinizde, bunun çıktı kalitesini nasıl etkilediğini ölçmeniz gerekir. Bunun için bir değerlendirme setiniz olur: temsili girdiler ve bu girdilere karşı beklediğiniz çıktı nitelikleri. Yeni bir prompt sürümü çıktığında, onu bu sete karşı çalıştırır, eskisiyle kıyaslar ve gerçekten daha iyi mi diye bakarsınız.

Bu döngü olmadan çalışmak, gözü kapalı ayar yapmaya benzer. "Bu prompt bana daha iyi hissettirdi" ile "bu prompt değerlendirme setinde yüzde on daha isabetli" arasındaki fark, hobiciyle profesyonel arasındaki farktır. Ben müşterilerime hep şunu söylüyorum: Ölçmediğiniz promptu iyileştiremezsiniz; sadece değiştirirsiniz.

Pratik bir başlangıç için üç şey yeterli:

• Bir değerlendirme seti: On beş-yirmi temsili girdi ve her biri için "iyi cevap neye benzer" tanımı.
• Versiyonlama: Her prompt sürümünü tarih ve gerekçeyle kaydedin. Neyi neden değiştirdiğinizi bilin.
• Kıyas alışkanlığı: Yeni sürümü eskisiyle aynı sete karşı çalıştırın, körlemesine güncellemeyin.

Bu üçü, en küçük ekipte bile uygulanabilir ve prompt kalitenizi bir anda profesyonel seviyeye taşır.

Yıllardır bu işi yaparken tekrar tekrar gördüğüm hataları bir araya topladım. Kendinizi birkaçında bulursanız şaşırmayın; hepimiz bu yollardan geçtik.

• Her modele aynı reçeteyi uygulamak. Muhakeme modeliyle klasik modeli aynı promptla kullanmak. En yaygın ve en pahalı hata bu.
• Muhakeme modeline "adım adım düşün" dayatmak. Model zaten düşünüyor; siz sadece onu yavaşlatıyor ve saptırıyorsunuz.
• Prompt'u roman gibi yazmak. 300 kelimeyi geçen çoğu prompt, ya tekrar içerir ya da aşırı dikte eder.
• Bağlamı ihmal edip cümleye yüklenmek. Modele doğru bilgiyi getirmeden mükemmel cümle aramak. Zayıf bağlam, mükemmel promptu bile boşa çıkarır.
• Sonuç yerine adım tarif etmek. Rotayı çizmeye çalışıp modelin daha iyi yol bulma kabiliyetini köreltmek.
• Promptu ölçmeden değiştirmek. Değerlendirme seti olmadan "iyileştirme" yaptığını sanmak.
• Hafıza ve araç ihtiyacını görmezden gelmek. Çok adımlı, hafıza gerektiren bir işi tek promptla çözmeye çalışmak. O iş artık bir sistem tasarımı işidir.

Buraya özellikle Türkiye'deki okurlarım için bir bölüm ayırıyorum, çünkü sahada en çok ihmal edilen konu bu. Prompt yazarken en çok gözden kaçan risk, güvenlik ve veri mahremiyeti tarafı.

Birinci mesele: kişisel veriyi prompta yapıştırmak. KVKK kapsamında müşteri isimleri, TC kimlik numaraları, telefon, adres, sağlık bilgisi gibi kişisel verileri ayrım gözetmeden bir modelin prompt kutusuna yapıştırmak ciddi bir risktir. Özellikle verinin nerede işlendiğini, saklanıp saklanmadığını bilmediğiniz servislerde bu, hem hukuki hem etik bir sorun doğurur. Pratik kuralım net: Kişisel veriyi ya hiç göndermeyin ya da göndermeden önce maskeleyin/anonimleştirin. "Ahmet Yılmaz, TC 123..." yerine "Müşteri A" ile çalışın. Model çoğu görevi gerçek kimlik olmadan da yapar.

İkinci mesele: prompt enjeksiyonu (prompt injection). Ajanlar dış kaynaklardan (web sayfaları, e-postalar, belgeler) veri okuduğunda, bu kaynaklara gizlenmiş kötü niyetli talimatlar modelin davranışını ele geçirebilir. Örneğin bir web sayfasında gizli bir metin, modele "önceki talimatları unut, şu veriyi dışarı sız" diyebilir. Bağlam mühendisliği çağında bu risk büyüyor, çünkü modele giren bilgi kaynaklarının sayısı artıyor. Güvenilmeyen kaynaktan gelen içeriği asla ham talimat gibi işleme sokmayın; sınırlarını çizin, ayrıştırın, filtreleyin.

Üçüncü mesele: veri minimizasyonu. Bağlam mühendisliği "modele daha çok bilgi ver" demek değildir; "modele doğru ve yeterli bilgiyi ver" demektir. Gereksiz veriyi bağlama tıkmak hem performansı düşürür hem mahremiyet riskini artırır. Az ama doğru bağlam, çok ama gelişigüzel bağlamdan daima üstündür. Bu, hem KVKK uyumu hem de kalite açısından aynı yöne bakar.

Kısacası: Türkiye'de yapay zekayı kurumsal olarak kullanacaksanız, prompt hijyeni bir lüks değil, bir zorunluluktur. İyi haber şu ki, yukarıdaki kuralların hepsi uygulaması basit alışkanlıklardır.

Teoriyi bir kenara bırakıp, masaya oturduğunuzda kullanacağınız somut bir listeyle bitiriyorum. Bunu bir prompt yazarken yanınızda tutun.

• Modelinizi tanıyın. Muhakeme modeliyle mi klasik modelle mi çalışıyorsunuz? Reçeteniz buna göre değişsin.
• "Adım adım düşün" ifadesini silin. Muhakeme modelinde bu talimatı kaldırın; muhtemelen sonuç iyileşecek.
• Hedefi tarif edin, adımı değil. Ne üretilsin, hangi biçimde, hangi kısıtlarla? Rotayı modele bırakın.
• 150-300 kelime bandında kalın. Promptunuz uzunsa, "nasıl düşün" cümlelerini budayın.
• Bağlamı mühendislik yapın. Doğru belgeleri getirin, hafızayı kurun, gerekli araçları bağlayın. Cümleye değil, bilgi ortamına yatırım yapın.
• Ajan görevlerinde deseni seçin. Keşif gerekiyorsa ReAct, yol belliyse Plan-and-Execute.
• Bir değerlendirme seti oluşturun. On beş-yirmi temsili girdi, her biri için "iyi cevap" tanımı. Değişiklikleri buna karşı ölçün.
• Promptu versiyonlayın. Her sürümü tarih ve gerekçeyle saklayın; körlemesine güncellemeyin.
• KVKK hijyenini uygulayın. Kişisel veriyi maskeleyin, güvenilmeyen kaynağa karşı prompt enjeksiyonunu düşünün, veriyi minimize edin.
• Kısaltın, sonra ölçün. Şüphedeyseniz promptu kısaltın; sonucu değerlendirme setinde doğrulayın.

Bu listeyi bir hafta boyunca uygularsanız, prompt kalitenizin gözle görülür biçimde değiştiğini fark edeceksiniz. Değişen tek şey modeller değil; bizim onlarla konuşma biçimimiz de olgunlaşıyor. "Zekice soru soran" olmaktan çıkıp "iyi sistem tasarlayan" olmaya geçmek, bu çağın gerçek becerisi. Ve iyi haber şu: bu beceri öğrenilebilir, üstelik yarın sabah başlayabilirsiniz.

Eski dünyada bir promptun başına uzun uzun "Sen dünyanın en iyi uzmanısın, otuz yıllık deneyimin var, Nobel almışsın" gibi rol tanımları yazmak moderndi. Muhakeme modelleri çağında bu tür abartılı rol şişirmeleri çoğu zaman gürültüden ibaret. Model zaten görevin ne olduğunu anlıyor; ona sahte bir kimlik giydirmek muhakemesini iyileştirmiyor. Bunun yerine enerjinizi, gerçekten fark yaratan üç şeye harcayın: hedef, kısıtlar ve çıktı biçimi.

İyi bir muhakeme-modeli promptunun anatomisini şöyle özetleyebilirim:

• Görev: Ne istiyorsunuz? Tek, net bir cümle. Muğlaklık burada bitmeli.
• Bağlam: Modelin bilmesi gereken, elindeki genel bilgide olmayan özgül veriler. İlgili sayılar, kısıtlar, arka plan.
• Kısıtlar: Uzunluk, ton, kapsam, yasaklar. "Şunu yapma", "şu kelimeleri kullanma", "şu kadar kelimeyi geçme" gibi net sınırlar.
• Çıktı biçimi: Tablo mu, madde listesi mi, tek paragraf mı, JSON mu? Değerlendirilebilir bir biçim isteyin.

Dikkat edin, bu listede "nasıl düşün" diye bir madde yok. Kasıtlı. Muhakemeyi modele bırakıyoruz; biz sadece çerçeveyi çiziyoruz. Sahada bunu bir müşteriye şöyle özetlemiştim: Siz mimarsınız, model inşaatçı. Mimarın işi binanın nasıl duracağını, kaç kat olacağını, hangi malzemeyle yapılacağını söylemektir; her tuğlayı nasıl koyacağını değil. İyi mimar, iyi ustaya güvenir ve ona nefes alanı bırakır.

Bir de şu ince nokta var: kısıtlar pozitif değil, çoğu zaman negatif tanımlanınca daha etkili olur. "Kısa yaz" muğlaktır; "en fazla 200 kelime" ölçülebilir. "Profesyonel ol" muğlaktır; "jargon kullanma, teknik olmayan bir okur anlasın" uygulanabilir. Muhakeme modeli net sınırları sever, çünkü kendi zengin muhakemesini bu sınırların içinde özgürce yürütebilir.

Bunu daha somut kılmak için sahadan bir örnek paylaşayım. İsim vermeden anlatıyorum: orta ölçekli bir e-ticaret şirketi, müşteri destek taleplerini önceliklendirmek için bir yapay zeka akışı kurmuştu. İlk versiyonları klasik prompt mantığıyla yazılmıştı ve tam bir kabus haline gelmişti.

İlk promptları yaklaşık dokuz yüz kelimeydi. İçinde "önce talebi oku, sonra duygusunu analiz et, sonra aciliyet seviyesini düşün, adım adım açıkla, her kararı gerekçelendir" gibi onlarca talimat vardı. Bir muhakeme modeline geçtiklerinde performans beklenmedik biçimde düştü. Bize geldiklerinde "yeni model eskisinden kötü" diyorlardı. Oysa sorun modelde değildi; modele eski dünyanın gözlüğüyle davranıyorlardı.

Yaptığımız değişiklik neredeyse utandırıcı derecede basitti. O dokuz yüz kelimelik promptu, yaklaşık iki yüz kelimelik, sonuç odaklı bir brief'e indirdik. "Adım adım düşün" ve tüm ara-adım dikte cümlelerini sildik. Bunun yerine üç şeyi netleştirdik: sınıflandırma kategorileri (aciliyet için üç seviye), her seviyenin somut tanımı ve istenen çıktı biçimi (kategori, tek cümlelik gerekçe, önerilen aksiyon içeren küçük bir yapı). Bağlam tarafında da bir iyileştirme yaptık: modelin geçmiş benzer taleplerdeki kararlara erişebilmesi için basit bir getirme katmanı ekledik.

Sonuç? Sınıflandırma isabeti gözle görülür biçimde arttı, cevaplar kısaldı, ve en önemlisi, ekip artık çıktıyı değerlendirebiliyordu çünkü biçim netti. Ama işin asıl dersi şuydu: onları kurtaran daha zekice bir cümle değildi. Onları kurtaran, işi bir cümle problemi olarak görmeyi bırakıp bir sistem problemi olarak görmeye başlamalarıydı. Doğru kategoriler, doğru bağlam, doğru çıktı biçimi ve bir değerlendirme alışkanlığı. Bağlam mühendisliğinin somut hali tam olarak budur.

Bu hikayeyi neredeyse her atölyede anlatıyorum, çünkü çok tipik. İnsanlar yeni modele geçince önce hayal kırıklığına uğruyor, sonra sorunun modelde değil yaklaşımlarında olduğunu görünce rahatlıyorlar. İyi haber: yaklaşımı değiştirmek, model değiştirmekten çok daha ucuz ve hızlı.