Üretken Yapay Zeka Geliştirme Sürecinin %20'si Prompt Yazımı, %80'i İse Geri Kalan Her Şeydir

Geçtiğimiz bahar bir hafta sonunda çalışan bir üretken yapay zeka (Generative AI) özelliği geliştirdim: Müşteri sorusunu okuyan, yardım dokümanlarından bağlam çeken ve doğru, samimi bir yanıt yazan bir destek asistanıydı. Demo harika geçti, herkes onayladı. Ancak bu özelliği canlıya almak üç ay daha sürdü. Sebebi prompt'un yanlış olması değildi; prompt neredeyse hiç değişmedi. Zamanın tamamı bilgi tabanını temizlemeye, bir değerlendirme (eval) seti oluşturmaya, modelin emin bir şekilde uydurduğu (halüsinasyon) durumları yönetmeye, maliyetleri kontrol altında tutmaya ve sistemi daha önce LLM duymamış altyapılara entegre etmeye harcandı.

Birçok ekibin aynı süreçten geçtiğini gördükten sonra şu kurala ikna oldum: Üretken yapay zeka geliştirmenin yaklaşık %20'si prompt mühendisliğidir. Geri kalan %80'lik kısım ise bir demoda asla görünmeyen mühendislik, veri ve operasyon işleridir. İşte o %80'lik kısmın gerçekte neye benzediği ve yazılım geliştiriciler için pratik çıkarımlar.

Demo Size Neden Yalan Söyler?#

Demo, en iyi senaryodur. Girdileri siz seçersiniz, modelin neyi iyi işlediğini bilirsiniz ve kimse beklenmedik bir soru sormaz. Canlı ortam (production) ise bunun tam tersidir. Gerçek kullanıcılar yarım cümleler yazar, tüm e-postaları yapıştırır, dil değiştirir ve farkında olmadan uç durumları (edge cases) zorlar.

Demo ile canlı ortam arasındaki fark bir prompt kalitesi farkı değil, güvenilirlik farkıdır. Zamanın %90'ında doğru çalışan bir model sahnede büyüleyici görünür; ancak kalan %10'luk dilimin destek taleplerine ve iadelere dönüştüğü müşteri odaklı bir iş akışında kabul edilemez. Mühendislik açısından asıl iş bu boşluğu kapatmaktır ve bunun neredeyse hiçbir kısmı prompt yazmakla ilgili değildir.

Kimsenin Bütçe Ayırmadığı Veri İşleri#

Faydalı üretken yapay zeka özelliklerinin çoğu kendi verilerinizin (dokümanlar, destek kayıtları, ürün katalogları, politikalar) üzerinde çalışır. Bizim durumumuzda yardım dokümanları çelişkili makaleler ve iade politikasının üç farklı versiyonunu içeriyordu. Model üçünü de çekip hiçbirine uymayan karma bir yanıt üretti. Gerçek veri mühendisliği çalışması şu 5 temel adımdan oluştu:

• Kaynak içeriğin tekilleştirilmesi ve versiyonlanması: Tekrarlayan verilerin temizlenmesi.
• Dokümanlar çeliştiğinde hangisinin yetkili (authoritative) olduğuna karar verilmesi: Doğru bilgi kaynağının önceliklendirilmesi.
• Dokümanların anlamlı parçalara bölünmesi (chunking): Arama (retrieval) işleminin cümle kırpıntıları yerine bütünlüklü pasajlar döndürmesinin sağlanması.
• Metaveri (ürün, bölge, tarih) eklenmesi: Model henüz veriyi görmeden önce arama aşamasında filtreleme yapılabilmesi.
• Yenileme iş akışı (refresh pipeline) kurulması: İndeksin lansmandan bir ay sonra güncelliğini yitirmemesi için otomatik güncellenmesi.

Pratik Çıkarım: Arama (retrieval) kalitesi, yanıt kalitesinin üst sınırını belirler. Çıktı kötü olduğunda prompt'a dokunmadan önce bağlam penceresine (context window) hangi verinin girdiğine bakın.

Değerlendirmeler (Evals): Bir Projeyi Deneyden Ayıran Unsur#

Çalışma şeklimdeki en büyük dönüşüm, değerlendirmeyi (evaluation) birinci sınıf bir çıktı olarak ele almak oldu. Bir değerlendirme seti olmadan yapılan her değişiklik sadece "hissiyata dayalı bir kontroldür" (vibe check). Prompt'u değiştirir, beş örnekle dener ve canlıya alırsınız; iki hafta sonra yaptığınız iyileştirmenin koca bir soru kategorisini bozduğunu fark edersiniz.

Temel bir değerlendirme kurulumu karmaşık olmak zorunda değildir ve şu 4 adıma dayanır:

• 100 ila 200 gerçek veya gerçekçi girdi toplamak: Yaygın durumları, uç senaryoları ve bilinen hataları kapsayan bir veri seti (Golden Dataset) oluşturmak.
• Her girdi için "iyi"nin ne olduğunu tanımlamak: Yanıtta mutlaka yer alması gereken gerçekleri ve asla söylenmemesi gerekenleri belirlemek.
• Her değişikliği bu sete karşı çalıştırmak: Prompt, model, arama ayarları veya parça boyutu (chunk size) değişimlerini test etmek.
• Skorları zaman içinde takip etmek ve gerilemeleri (regression) başarısız bir test gibi ele almak: Mümkün olan yerlerde geçerli JSON, zorunlu alanlar veya kaynak gösterimi gibi otomatik kontrolleri; mümkün olmayan yerlerde ise model tabanlı (LLM-as-a-Judge) veya insan değerlendirmesini kullanmak. Model değerlendiricilerin kendi önyargıları olabileceğinden bunları insan kararıyla rastgele kontrol etmek.

Pratik Çıkarım: Bu yapının getirisi güvendir. Modelleri değiştirebilir veya arama stratejinizi güncelleyebilir ve sistemin daha iyiye mi yoksa kötüye mi gittiğini dakikalar içinde öğrenebilirsiniz.

Orijinal makaleye buradan ulaşabilirsiniz.