%60'tan %93'e: LLM Sistemleri İçin Sürekli Değerlendirme Altyapısı Kurmak

Büyük Dil Modelleri (LLM) ile çalışan sistemleri üretime alırken prompt güncellemelerinin mevcut sistemi bozmamasını sağlamak kritik bir zorluktur. Bu makalede, bir Text2SQL sisteminin doğruluğunu %60'tan %93'e çıkaran üç katmanlı sürekli değerlendirme mimarisini ve yazılım geliştiriciler için pratik çıkarımları inceliyoruz.

1. Problem: "Benim Makinemde Çalışıyor" Yetmez

Geliştirme aşamasında birkaç test sorgusuyla manuel doğrulama yapmak yetersizdir. Pratik Çıkarım: LLM projelerinde sezgisel "bence çalışıyor" yaklaşımı yerine, yazılım mühendisliğindeki birim testleri (unit tests) gibi veriye dayalı otomatik testleri benimsemek şarttır.

2. Mimari: Üç Katmanlı Kalite Güvence Döngüsü

Sistem; dağıtım öncesi (çevrimdışı), üretim anı (çevrimiçi izleme) ve dağıtım sonrası (geri bildirim) olmak üzere üç katmandan oluşur. Bu döngü, hataların üretime sızmasını engellerken sistemi sürekli besler.

3. Birinci Katman: Çevrimdışı Değerlendirme — Dağıtım Öncesi Kalite Kapısı

3.1 Altın Veri Seti: Gerçek kullanıcı sorgularından (150 durum) ve karmaşık uç durumlardan (50 durum) oluşan 200 örnekli bir test seti oluşturun.
3.2 Doğruluk Tanımı: SQL yürütme başarısı (%70 ağırlık) ile semantik doğruluğu (%30 ağırlık) birleştiren bir metrik tanımlayın.
3.3 Versiyon Takibi: Prompt değişikliklerini sürüm kontrolü altında tutup her güncellemede başarı oranını test setiyle ölçün.
3.4 Regresyon Kapısı: Yeni sürümün doğruluğu mevcut sürümden belirli bir eşiğin (örneğin %2) üzerinde düşerse dağıtımı otomatik reddedin.

4. İkinci Katman: Çevrimiçi İzleme — Dağıtım Sonrası Sürekli Gözlem

4.1 LangSmith ile İzleme: Üretimdeki LLM çağrılarını, token tüketimlerini ve gecikmeleri sürekli takip edin.
4.2 Asenkron Loglama: Geliştirici Notu: Performans düşüşünü engellemek için günlükleri asenkron olarak yerel kuyruğa yazıp arka planda batch halinde yükleyin.
4.3 Kademeli Saklama: Depolama maliyetlerini optimize etmek için hata günlüklerini 90 gün, normal sorguları ise 7 gün saklayın.

5. Üçüncü Katman: Geri Bildirim Döngüsü — Sistemi Zamanla İyileştirmek

5.1 Hata İzleme: Üretim hatalarını otomatik arşivleyip kök neden analiziyle kategorilendirin.
5.2 Otomatik Hata Ayıklama: Hatalı çıktılarda sistemi doğrudan baştan başlatmak yerine 3 turlu düşünce zinciri (CoT) ile LLM'in kendisini düzeltmesini sağlayın.
5.3 Geri Bildirimi Kapatmak: Sık hata alınan durumları yeni "Few-shot" örnekleri olarak prompt'a veya test setine ekleyerek döngüyü tamamlayın.

6. Uçtan Uca Tam Bir Örnek

Sorgu açıklama, görev ayrıştırma, GraphRAG erişimi, CoT SQL üretimi, hata ayıklama ve sonuç yorumlama aşamalarından oluşan akışla hatalar en aza indirilir.

7. Sonuçlar

Bu altyapıyla karmaşık sorgu doğruluğu %40'tan %85'e çıkmış, hata oranları %28'den %5'e düşmüş ve maliyetler %60 azalmıştır.

8. Sezgisel Olmayan Üç Ders

Ders 1: Kaliteli bir test seti, karmaşık değerlendirme algoritmalarından daha değerlidir.
Ders 2: Regresyon kapısının tolerans eşiğini gevşek değil, sıkı tutun.
Ders 3: Geri bildirim döngüsünü haftalık rutin haline getirin.

Sırada Ne Var?

Gelecek yazıda, 8 haftalık LLM uygulama geliştirme sürecinin mimari retrospektifini inceleyeceğiz.

[Orijinal kaynağa buradan ulaşabilirsiniz.](https://dev.to/jamesli/from-60-to-93-how-we-built-a-continuous-evaluation-framework-for-llm-systems-i4)