DSPy Hattım Kusursuz Derlendi Ama Üretimde Kötüleşti

DSPy felsefesi oldukça çekicidir: Prompt'ları elle ince ayar yapmayı bırakır, derleyicinin (compiler) bunları belirlediğiniz bir metrik ve eğitim veri seti üzerinden otomatik optimize etmesine izin verirsiniz. Bir RAG (Retrieval-Augmented Generation) hattını bu yöntemle kurduğumda derleme skoru çok yüksek çıktı, doğrulama (hold-out) testi başarılıydı ve projeyi canlıya aldım. Ancak üretimdeki gerçek trafik kalitesi önceki halinden daha kötüydü. Sistemde hiçbir çalışma zamanı hatası yoktu; yalnızca takip ettiğim metrikler kullanıcıların karşılaştığı sonuçlarla uyuşmuyordu. Sorun DSPy mimarisinde değil; neye göre optimize ettiğimde ve neyi ölçtüğümdeydi.

İşte bu deneyimden çıkardığım temel dersler ve pratik çıkarımlar:

1. Derleme Metriğiniz Üretim Değerlendirme Kriteriniz Değildir

DSPy, prompt'larınızı derleyiciye verdiğiniz metriğe göre optimize eder. Derleyici tek geçişte binlerce deneme prompt'unu puanladığı için bu metriğin hesaplama maliyeti düşük (cheap) olmalıdır. Pratikte bu genellikle sığ bir kontroldür: Nihai yanıtın beklenen dizeyi içerip içermediği ya da tek bir ikili (evet/hayır) LLM yargı çağrısı gibi.

Ancak gerçek bir yazılım ürünü bu kadar dar bir metrikle değerlendirilemez. Üretim seviyesinde bir RAG yanıtının:

Getirilen kaynak içeriğe kesin olarak dayanması (grounded),
Çok parçalı soruları eksiksiz yanıtlaması,
Bilgi bağlamda yer almıyorsa yanıt vermeyi reddedebilmesi gerekir.

Derleyicinin binlerce kez çalıştırdığı ucuz kontrole bu kriterler sığmaz. Ucuz metrik ile gerçek ürün kriteri çeliştiğinde, derleyici ucuz metriğe aşırı uyum sağlar (overfitting).

Pratik Çıkarım: Ucuz metriği ait olduğu yerde, yani derleme döngüsünde tutun; zengin ve gerçek değerlendirme kriterlerinizi ise test veri setinizde ve canlı trafikte bağımsız olarak çalıştırın.

2. Tüm Programı Değil, İmzayı (Signature) Puanlayın

İkinci hata, hattı baştan sona tek bir genel puanla değerlendirmekti. Bir DSPy programı, her biri bağımsız bir görevi yürüten zincirleme modüllerden (örneğin getirme/retrieval ve yanıtlama adımları) oluşur. Tek bir uçtan uca skor düştüğünde sistemin kötüleştiğini görürsünüz; fakat hangi adımın buna sebep olduğunu anlayamazsınız.

Doğru Yaklaşım: Her modülü kendi işlevine göre puanlamaktır.
- Getirme adımı: Doğru içeriği çekip çekmediğine göre,
- Yanıtlama adımı: Eldeki materyale sadık kalıp soruyu tam yanıtlamasına göre puanlanır. Böylece yanıtlama adımı stabilken getirme performansı düşerse, derleyicinin getirme prompt'unu bozduğunu net olarak tespit edebilirsiniz.

3. Her Modül Başarılı Olsa Bile Program Başarısız Olabilir

Bazen her modül bağımsız testlerde başarılı olur, ancak adımlar arasındaki birleşimde (composition) bilgi kaybı yaşandığı için program yine de çöker. Getirme doğru pasajları çeker, yanıtlama adımı eldekilerle mantıklı akıl yürütür ama nihai cevap yine de hatalı çıkar.

Pratik Çıkarım: Hatalı yanıtlar için nihai arızanın asıl nedenini (proximate cause) inceleyen bir denetim mekanizması kurun. Hataların dağılımını çıkararak sorunun getirmeden mi yoksa izole testlerde başarılı görünen sentez adımından mı kaynaklandığını somut verilerle belirleyin.

Tek Cümleyle Çıkarım

Prompt'larınızı ucuz metrikle derleyin ama ona asla nihai kalite garantisi olarak güvenmeyin; her modülü kendi sorumluluğunda puanlayın ve canlı trafiği zengin kriterlerle ölçün.

Orijinal kaynağa buradan ulaşabilirsiniz.

Bu konuyu derinlemesine öğrenmek isterseniz: DSPy ile Programatik Prompt Optimizasyonu modülüne göz atın.