Prompt Engineering Yetmezse Ne Yapmalı? Workflow, Retrieval ve Tool Use Gerektiren Durumlar

Büyük dil modelleriyle çalışan ekiplerin en yaygın yanılgılarından biri, iyi tasarlanmış bir prompt’un her problemi çözebileceğini düşünmektir. Bu yanılgı anlaşılabilir bir yerden doğar. Çünkü LLM’lerle ilk temas kuran birçok kurum, yalnızca prompt dilini iyileştirerek şaşırtıcı derecede iyi çıktılar elde eder. Daha iyi özetler, daha düzenli e-postalar, daha net rapor taslakları, daha iyi sınıflandırma çıktıları ya da daha kontrollü cevaplar üretmek mümkündür. Bu ilk başarılar, doğal olarak şu düşünceyi doğurur: “Demek ki biraz daha iyi prompt yazarsak geri kalan her şeyi de çözebiliriz.”

Oysa üretim gerçeği çok daha farklıdır. Çünkü prompt engineering güçlü bir araçtır; ama bir sistem mimarisi değildir. Prompt, modele ne yapması gerektiğini daha iyi anlatabilir. Ancak eksik bilgiye erişim sağlayamaz, çok adımlı kurumsal süreçleri tek başına yönetemez, dış sistemlerle güvenli şekilde etkileşime giremez ve her durumda tekrarlanabilir operasyon disiplini kuramaz. Bir noktadan sonra problem “komutu nasıl yazdığımız” değil, sistemi nasıl tasarladığımız sorusuna dönüşür.

İşte bu dönüşüm kritik önemdedir. Çünkü kurumsal yapay zekâ projelerinde başarısızlık çoğu zaman modelin yetersizliğinden değil, prompt engineering’in sınırlarının yanlış anlaşılmasından doğar. Ekipler aslında workflow gerektiren problemi prompt ile çözmeye çalışır. Retrieval gerektiren use-case’i model hafızasına bırakır. Tool use gerektiren bir süreci yalnızca metin üretimiyle yönetmeye kalkar. Sonuçta sistem ilk bakışta akıllı görünür; ama üretimde kırılgan, tutarsız ve sınırlı hale gelir.

Bu yazıda, prompt engineering’in ne zaman yeterli olduğunu ve ne zaman yeterli olmadığını sistematik biçimde ele alacağım. Özellikle üç kritik eşik üzerinde duracağım: workflow gerektiren durumlar, retrieval gerektiren durumlar ve tool use gerektiren durumlar. Amaç, prompt’u küçümsemek değil; tam tersine onu doğru yere yerleştirmektir. Çünkü güçlü kurumsal AI sistemleri prompt ile başlar, ama çoğu zaman yalnızca prompt ile bitmez.

Prompt engineering en güçlü olduğu durumda, modele verilen görevi daha net, daha sınırları belli ve daha kontrollü hale getirir. Başka bir ifadeyle prompt, modelin mevcut yeteneklerini daha verimli kullanmamızı sağlar. Görev tanımını netleştirir, bağlamı düzenler, çıktı biçimini sınırlar, belirsizlik davranışını tanımlar ve bazen kaliteyi ciddi biçimde artırır.

Özellikle aşağıdaki problem tiplerinde prompt engineering tek başına çok güçlü olabilir:

• Metin yeniden yazma
• Özetleme
• Belirli formatta içerik üretimi
• Basit sınıflandırma veya etiketleme
• Mevcut bağlam üzerinden yorum veya açıklama
• Taslak oluşturma

Bu tür görevlerde temel ihtiyaç çoğu zaman şudur: modele daha iyi görev tanımı vermek. Eğer gerekli bilgi zaten prompt içinde veya kısa bağlam içinde varsa, süreç tek adımlıysa, dış sistem etkileşimi gerekmiyorsa ve sonuç serbest metin ya da yapılandırılmış tek çıktıysa, prompt engineering çoğu zaman yeterli olabilir.

Ancak şu noktada çok önemli bir ayrım vardır: Prompt engineering, model davranışını iyileştirir; ama sistem eksiklerini tek başına kapatmaz.

"

Kritik gerçek: Prompt engineering, mevcut bağlam içindeki görevi daha iyi çözer. Ama eksik bağlamı, çok adımlı süreci veya dış dünya etkileşimini kendi başına çözmez.

Bunun temel nedeni, birçok ekibin LLM ile ilk başarısını “sistem başarısı” sanmasıdır. Oysa ilk başarı çoğu zaman dar kapsamlı, tek adımlı ve iyi örneklenmiş görevlerde gelir. Modelden bir e-postayı yeniden yazmasını istersiniz ve başarılı olur. Bir metni sınıflandırmasını istersiniz ve işe yarar. Bir toplantı özetini çıkarmasını istersiniz ve etkileyici sonuç alırsınız. Bu deneyimler çok değerlidir; ancak ekipler bazen buradan yanlış genelleme yapar.

Şu geçişler genellikle hatalı olur:

• Metin özetlemede başarılıysa, süreç yönetiminde de başarılı olur sanmak
• Verilen bilgi üzerinden iyi yazıyorsa, kurumsal bilgiye de kendisi ulaşabilir sanmak
• Akıllı cevap veriyorsa, doğru sistem aksiyonunu da yönetebilir sanmak
• Birkaç örnekte iyi görünüyorsa, üretimde de güvenilir çalışır sanmak

Bu hatanın özü şudur: Modelin dil üretim gücü ile sistemin operasyonel yeteneği birbirine karıştırılır.

Önce sınırı doğru çizmek için prompt’un gerçekten yeterli olduğu alanları netleştirmek gerekir. Çünkü her problemi sistem mimarisi seviyesine taşımak da doğru değildir.

1. Tek Adımlı Görevler

Girdi gelir, model bir çıktı üretir ve süreç tamamlanır. Arada çoklu sistem etkileşimi, karar ağacı veya adım bağımlılığı yoktur.

2. Gerekli Bilgi Zaten Bağlam İçindeyse

Modelin harici bilgi aramasına, kurumsal veri tabanına gitmesine veya canlı bilgi çekmesine gerek yoksa prompt yeterli olabilir.

3. Sonuç Metin veya Sınırlı Yapılandırılmış Çıktıysa

Eğer çıktı yalnızca bir özet, taslak, sınıflandırma etiketi, JSON alanı veya değerlendirme notuysa, prompt engineering tek başına yeterli olabilir.

4. Süreçte Dış Sistem Etkileşimi Yoksa

Modelin bir CRM kaydı açması, API çağırması, takvimden bilgi çekmesi ya da işlem başlatması gerekmiyorsa tool use ihtiyacı doğmaz.

5. Görev Çerçevesi Belirliyse

İş mantığı netse, karar alanı darsa ve modelin yalnızca verilen görevi yerine getirmesi bekleniyorsa, prompt en doğru çözüm olabilir.

Bu senaryolarda prompt engineering’i doğru kullanmak; gereksiz mimari karmaşıklık kurmaktan daha sağlıklıdır.

Asıl kırılma noktası burada başlar. Bazı problemler vardır ki onları ne kadar iyi prompt yazarsanız yazın, kalite belirli bir eşiğin üzerine çıkmaz. Çünkü sorun prompt’ta değil, problemin doğasındadır.

Genel olarak prompt engineering aşağıdaki durumlarda yetersiz kalmaya başlar:

• Görev çok adımlı hale geldiyse
• Modelin güncel veya kuruma özel bilgiye erişmesi gerekiyorsa
• Harici sistemlerle etkileşim gerekiyorsa
• Karar ve aksiyon arasında bir süreç mantığı varsa
• İnsan onayı, koşullu branching veya state takibi gerekiyorsa

Bu noktada sistem prompt’tan daha fazlasına ihtiyaç duyar. En yaygın üç genişleme alanı şunlardır:

1. Workflow
2. Retrieval
3. Tool Use

Workflow, belirli bir hedefe ulaşmak için birden fazla adımın, kuralın, koşulun ve bazen insan onayının sıralı ya da dallanmalı biçimde çalıştırıldığı yapıdır. Birçok kurumun prompt ile çözmeye çalıştığı problem aslında prompt değil, workflow problemidir.

Workflow Gerektiren Temel Sinyaller

• Görev tek çıktıdan oluşmuyorsa
• Bir adımın çıktısı sonraki adımı etkiliyorsa
• Koşula göre farklı yollar izleniyorsa
• İnsan onayı veya istisna akışı varsa
• Süreç tekrarlanabilir ve operasyonel yapıya sahipse

Örnek Senaryolar

İK Süreci

CV özeti çıkarma prompt ile yapılabilir. Ama adayın özeti çıkarılsın, uygunluk skoru verilsin, düşükse farklı klasöre gitsin, yüksekse recruiter’a özet gitsin, sonrasında görüşme taslağı oluşsun ve insan onayı sonrası e-posta hazırlansın diyorsanız artık prompt yetmez; workflow gerekir.

Satış Süreci

Teklif taslağı yazmak prompt işidir. Ama müşteri bilgisi çekme, sektör özeti çıkarma, önceki görüşmeleri birleştirme, teklif şablonunu doldurma, fiyat onayı alma ve sonra e-posta oluşturma diyorsanız bu workflow problemidir.

Operasyon Süreci

Talep metnini sınıflandırmak prompt ile yapılabilir. Ama buna göre ticket açmak, öncelik vermek, doğru ekibe yönlendirmek, kritik durumlarda yöneticiyi bilgilendirmek ve çözüm kapanış özetini hazırlamak diyorsanız workflow gerekir.

Workflow Olmadan Ne Tür Hatalar Görülür?

• Tek prompt içinde çok fazla görev yüklenir
• Çıktı güzel görünür ama süreç işletilemez
• İnsan onayı noktaları kaybolur
• Koşullu akışlar elle yönetilmeye çalışılır
• Her kullanıcı süreci kendine göre yeniden kurar

Kısacası workflow gerektiren problemi yalnızca prompt ile çözmeye çalışmak, akıllı görünen ama süreç olarak dağınık sistemler üretir.

Retrieval, modelin yanıt üretmeden önce harici bilgi kaynağından ilgili içeriği çekmesini sağlayan katmandır. Kurumsal use-case’lerde prompt engineering’in yetersiz kaldığı en yaygın alanlardan biri budur. Çünkü model çok iyi yazıyor olabilir; ama doğru bilgiye erişemiyorsa kurumsal kalite yine düşer.

Retrieval Gerektiren Temel Sinyaller

• Bilgi kuruma özelse
• Bilgi sık güncelleniyorsa
• Kaynaklı ve denetlenebilir cevap gerekiyorsa
• Doküman, wiki, SOP, politika veya ürün bilgisi kullanılıyorsa
• Rol bazlı bilgi erişimi gerekiyorsa

Örnek Senaryolar

İç Bilgi Asistanı

Çalışanların İK politikalarını sorması, onboarding içeriklerine erişmesi veya prosedür öğrenmesi gerekiyorsa, salt prompt yeterli değildir. Çünkü ihtiyaç duyulan bilgi prompt içinde taşınamayacak kadar büyük, kuruma özel ve güncel olmalıdır.

Destek Bilgi Tabanı

Müşteri sorununa doğru yanıt verebilmek için ürün dokümanı, sürüm notu, hata çözüm makalesi veya SOP gerekiyorsa retrieval şarttır.

Eğitim İçeriği Uyarlama

Kurum içi eğitim içeriği, rehberler ve önceki materyaller üzerinden yeni içerik üretilecekse retrieval katmanı büyük değer katar.

Retrieval Olmadan Ne Tür Hatalar Görülür?

• Model genel bilgiyle cevap verir ama kurumsal doğruluk düşer
• Eski veya eksik bilgi üzerine akıcı metin üretir
• Kaynak gösterimi yapılamaz
• Aynı use-case için güven hızla kaybolur
• Prompt içine aşırı büyük bağlam yüklenmeye çalışılır

Buradaki temel ilke nettir: Bilgi problemiyse, prompt değil retrieval gerekir.

Tool use, modelin yalnızca metin üretmekle kalmayıp harici araçlar, API’ler, kurumsal sistemler, veri kaynakları veya işlem fonksiyonlarıyla etkileşime girmesini sağlayan katmandır. Birçok agent projesinin asıl değeri de burada ortaya çıkar.

Tool Use Gerektiren Temel Sinyaller

• Sistemden veri çekmek gerekiyorsa
• Gerçek zamanlı durum sorgulamak gerekiyorsa
• İşlem başlatmak, kayıt oluşturmak, güncellemek veya yönlendirmek gerekiyorsa
• Hesaplama, doğrulama veya dış servis kullanımı gerekiyorsa
• Metin değil aksiyon beklentisi varsa

Örnek Senaryolar

Satış Agent’ı

Müşteri özetini prompt ile yazabilirsiniz. Ama CRM’den müşteri geçmişini çekmek, açık fırsatları görmek, son toplantıyı okumak ve yeni task oluşturmak istiyorsanız tool use gerekir.

Operasyon Agent’ı

Talep özetini prompt ile yazabilirsiniz. Ama bilet açmak, durum güncellemek, SLA kontrol etmek ve eskalasyon tetiklemek için tool use gerekir.

Eğitim Operasyonu

Eğitim planı taslağı prompt ile hazırlanabilir. Ama LMS’e içerik eklemek, katılımcı listesi çekmek, değerlendirme sonuçlarını toplamak ve rapor üretmek için tool use gerekir.

Tool Use Olmadan Ne Tür Hatalar Görülür?

• Model sanki işlem yapmış gibi metin üretir ama gerçekte hiçbir şey olmaz
• Kullanıcı metni sistem aksiyonu sanabilir
• İnsanlar manuel kopyala-yapıştır ile süreci tamamlarken verim düşer
• Gerçek zamanlı veri gerektiren use-case’ler zayıf kalır

Buradaki ayırıcı soru şudur: Kullanıcı bir metin mi istiyor, yoksa sistemle etkileşim sonucu mu bekliyor? Eğer ikinciyse prompt yetmez.

Gerçek kurumsal use-case’lerin çoğu yalnızca workflow, yalnızca retrieval veya yalnızca tool use ile sınırlı değildir. Güçlü üretim sistemleri çoğu zaman bu katmanları birlikte kullanır.

Prompt + Workflow

Tek adımlı olmayan ama harici bilgi veya araç gerektirmeyen süreçlerde etkilidir. Örneğin metin oluşturma + onay + gönderim taslağı akışı gibi.

Prompt + Retrieval

Kuruma özel bilgi gerektiren ama aksiyon gerektirmeyen use-case’lerde idealdir. Örneğin politika asistanı, SOP açıklayıcıları, iç bilgi asistanları.

Prompt + Tool Use

Bilgi prompt içinde var olabilir ama sistem aksiyonu gerektiriyorsa kullanılır. Örneğin taslak yanıt üret + ticket aç.

Prompt + Workflow + Retrieval + Tool Use

Agentic kurumsal sistemlerin önemli bölümü bu kombinasyona yaklaşır. Örneğin destek agent’ı bilgi tabanını tarar, CRM verisini çeker, çözüm taslağı üretir, gerekirse ticket açar ve insan onayına sunar.

Dolayısıyla doğru soru “prompt mu workflow mu?” değildir. Asıl soru, problem hangi katmanları gerçekten gerektiriyor sorusudur.

Aşağıdaki soru seti, prompt’un yeterli olup olmadığını anlamak için güçlü bir filtre sağlar:

1. Görev tek adımlı mı?

Evetse prompt yeterli olabilir. Hayırsa workflow ihtimali artar.

2. Gerekli bilgi prompt içinde veya kısa bağlamda mevcut mu?

Hayırsa retrieval ihtimali artar.

3. Dış sistemlerle etkileşim gerekiyor mu?

Evetse tool use gerekir.

4. İnsan onayı veya koşullu branching var mı?

Evetse workflow gerekir.

5. Sonuç metin mi, yoksa sistem aksiyonu mu?

Sistem aksiyonunda tool use şart hale gelir.

6. Bilgi güncel, kaynaklı ve kuruma özel olmak zorunda mı?

Evetse retrieval kaçınılmazdır.

Bu filtreler birlikte düşünüldüğünde, çok sayıda use-case’in neden yalnızca prompt ile çözülemeyeceği netleşir.

1. Workflow Problemini Prompt Problemi Sanmak

Tek prompt içinde sınıflandırma, özetleme, karar, onay ve yönlendirme yaptırılmaya çalışılır.

2. Bilgi Problemini Model Hafızasına Bırakmak

Kuruma özel veya güncel bilgi gereken yerde retrieval kurulmamak en yaygın hatalardan biridir.

3. Aksiyon Problemini Metin Problemi Gibi Çözmek

Model işlem yapmış gibi cevap verir ama arka planda hiçbir sistem etkileşimi yoktur.

4. Her Katmanı Aynı Anda Gereksiz Kurmak

Basit bir use-case için prompt yeterliyken workflow + RAG + agent + tool use kurmak da ters yönde hatadır.

5. Prompt’u Sistem Mimarisi Sanmak

İyi prompt tasarımı değerlidir; ama bu değer sistem tasarımının yerine geçmez.

Yalnızca Prompt Yeterli Olan Bir Senaryo

Satış ekibi, toplantı notlarından kısa bir follow-up e-postası taslağı üretmek istiyor. Girdi metni var, görev tek adımlı, dış sistem gerekmiyor, çıktı taslak metin. Burada prompt yeterli olabilir.

Prompt + Retrieval Gereken Bir Senaryo

Çalışanlar şirket seyahat politikasını doğal dilde sormak istiyor. Bilgi şirket içi dokümanlarda, güncel ve kaynaklı olmalı. Burada retrieval gerekir.

Prompt + Workflow Gereken Bir Senaryo

İK ekibi mülakat notlarından aday özeti çıkaracak, sonra hiring manager için özet not hazırlayacak, sonra standart değerlendirme formuna dönüştürecek ve son olarak insan onayına sunacak. Burada workflow gerekir.

Prompt + Tool Use Gereken Bir Senaryo

Operasyon ekibi için gelen talebi özetle, önceliğini belirle ve ticket sisteminde yeni kayıt oluştur. Burada tool use gerekir.

Tüm Katmanların Gerektiği Bir Senaryo

Destek agent’ı müşterinin sorununu anlar, bilgi tabanında çözüm arar, CRM’den geçmişi çeker, doğru yönlendirmeyi oluşturur, gerekirse ticket açar ve kritik durumlarda insan onayına sunar. Bu, prompt’un çok ötesinde bir sistem tasarımı problemidir.

1. Önce Prompt ile Başla, Sonra Sınırı Gör

Basit use-case’lerde prompt ile başlamak doğrudur. Ancak kalite belirli noktada tıkanıyorsa sorunu prompt’ta zorlamayı bırakıp sistem seviyesinde yeniden tanımlamak gerekir.

2. Problemi Türüne Göre Sınıflandır

Bu bir metin dönüşümü mü, bilgi erişimi mi, süreç akışı mı, yoksa sistem etkileşimi mi? Bu ayrım mimariyi belirler.

3. Katmanları Gerektiği Kadar Ekle

Her use-case için tam agent mimarisi kurmak zorunda değilsin. Ama gerektiği yerde retrieval veya tool use eklemekten de kaçınmamalısın.

4. İnsan Onayını Mimariye Dahil Et

Workflow, retrieval ve tool use birleştiğinde insan onayı kritik hale gelir. Özellikle dış etki doğuran aksiyonlarda bu zorunludur.

5. Evaluation’ı Katman Bazlı Yap

Prompt, retrieval, workflow ve tool use kalitesi ayrı ayrı ölçülmelidir. Hepsi “çıktı güzel mi?” sorusuna indirgenemez.

1. Her şeyi prompt ile çözmeye çalışmak
2. Çok adımlı süreci tek adımlıymış gibi ele almak
3. Kuruma özel bilgiyi retrieval olmadan yönetmek
4. Sistem aksiyonu gerektiren use-case’i metin üretimi gibi görmek
5. Workflow ihtiyacını prompt karmaşıklığıyla telafi etmeye çalışmak
6. Tool use olmadan agent kurduğunu sanmak
7. Retrieval gerektiren yerde prompt içine aşırı bağlam yüklemek
8. İnsan onayı gerektiren akışı tam otonom sanmak
9. Katmanları gereksiz yere fazla kurmak
10. Prompt kalitesini sistem başarısıyla karıştırmak
11. Değerlendirmeyi katman bazlı yapmamak
12. Problem tipini mimariden önce tanımlamamak

İlk 30 Gün: Use-Case’leri Sınıflandır

• Mevcut LLM kullanım alanlarını listele
• Her use-case için tek adımlı mı, bilgi yoğun mu, aksiyon yoğun mu analiz et
• Prompt ile çözülebilenleri ve tıkananları ayır
• İlk workflow / retrieval / tool use adaylarını belirle

31-60 Gün: Katmanları Kontrollü Eklemeye Başla

• Çok adımlı use-case’lerde workflow orchestration kur
• Bilgi yoğun alanlar için retrieval prototipleri geliştir
• Sistem etkileşimi gereken use-case’lerde güvenli tool seti tanımla
• İnsan onayı ve guardrail mantığını tasarla

61-90 Gün: Hibrit Mimari Disiplinini Kur

• Prompt + workflow + retrieval + tool use kombinasyonlarını use-case bazlı standardize et
• Katman bazlı evaluation kur
• Gözlemlenebilirlik ve audit izlerini aktifleştir
• İlk kurumsal mimari karar rehberini yayınla

Prompt engineering, kurumsal yapay zekâ projelerinin en önemli başlangıç katmanlarından biridir. Doğru kullanıldığında kaliteyi, netliği ve kullanılabilirliği ciddi biçimde artırır. Ancak gerçek üretim sistemlerinde her problemi yalnızca daha iyi prompt yazarak çözmeye çalışmak, bir noktadan sonra mimari körlüğe dönüşür.

Çok adımlı süreçler workflow ister. Kuruma özel ve güncel bilgi retrieval ister. Sistemlerle etkileşim ve aksiyon üretimi tool use ister. Güçlü kurumsal AI sistemleri de tam burada olgunlaşır: prompt’u küçültmeden, ama onu doğru yere koyarak. Uzun vadede başarılı ekipler, prompt’u bir sihirli çözüm gibi görenler değil; prompt’un ne zaman yeterli olduğunu ve ne zaman daha geniş bir sistem tasarımına ihtiyaç olduğunu doğru ayırt eden ekipler olacaktır.

Prompt engineering çoğu use-case için yine de ilk adım olmalı mı?

Evet. Çünkü birçok basit ve tek adımlı görevde prompt engineering yeterlidir. Ancak sınırına gelindiğinde problemi sistem seviyesinde yeniden tanımlamak gerekir.

Workflow ile agent aynı şey midir?

Hayır. Workflow önceden tanımlı veya yarı-dinamik süreç akışını ifade eder. Agent ise çoğu zaman karar, tool use ve bazen planning içeren daha geniş bir yapıdır.

Retrieval gerektiren use-case nasıl anlaşılır?

Bilgi kuruma özelse, sık güncelleniyorsa, kaynaklı cevap gerekiyorsa veya prompt içine sığmayacak kadar büyükse retrieval gerekir.

Tool use olmadan güçlü bir sistem kurulamaz mı?

Kurulabilir. Eğer ihtiyaç yalnızca metin veya yapılandırılmış çıktıysa tool use gerekmeyebilir. Ancak dış sistem etkileşimi ve aksiyon gerekiyorsa tool use kaçınılmazdır.

Bu üç katman her zaman birlikte mi kullanılmalı?

Hayır. Mesele hepsini kurmak değil, problemi çözmek için gereken katmanları doğru seçmektir. Gerektiği kadar mimari, en sağlıklı yaklaşımdır.