Risk Skorlama: LLM Eğitim Verisinde Kalite Kontrolü

Bağlam

LLM eğitim pipeline'ında veri hacmi artıkça kalite kontrol süreci darboğaza girdi. Her gün 10.000'i aşan kayıt pipeline'a giriyordu; bu verinin hem içerik güvenliği hem de dil kalitesi açısından uygunluğu kontrol edilmesi gerekiyordu. Ops ekibi inceleme kapasitesinin çok üzerinde bir yükle karşı karşıyaydı.

Problem

Manuel inceleme iki açıdan başarısız oluyordu: (1) ölçeklenemiyor, veri hacmi arttıkça insan başına düşen yük artıyordu; (2) tutarsız, farklı inceleyiciler aynı kaydı farklı değerlendiriyordu. Sonuç: eğitim verisinin kalitesi çalışmaya bağlı değişiyor ve bu belirsizliği fine-tuning çıktılarına taşıyordu.

Neden Önemliydi?

Eğitim verisindeki kalite sorunları iki yerde fatura kesiyor: model davranışında (kötü veriyle eğitilen model kötü örüntüler öğreniyor) ve güven maliyetinde (içerik güvenliği ihlali geçen veri, modeli sınır dışı içerik üretmeye yatkın hale getirebilir). Öte yandan aşırı kısıtlayıcı bir sistem iyi veriyi de eliyor; hassas bir denge kurmak gerekiyordu.

Ben Neyi Sorguladım?

İlk sorum: tek bir genel skor mu, yoksa boyut bazlı modüler yapı mı? Genel skor yorumlamayı kolaylaştırır ama hangi boyutun problemi tetiklediğini gizler; bu da düzeltme sürecini köreltiyor. İkinci sorum: eşik değerleri nasıl kalibre edilmeli? Çok sıkı eşik iyi veriyi eliyor, çok gevşek eşik sorunu çözmüyor.

Teşhis

Mevcut süreçte inceleyicilerin en çok zaman harcadığı vaka tiplerini analiz ettim. Üç kategori öne çıktı: dilbilgisi düzeyi düşük kayıtlar (makine çevirisi izleri), talimat ile yanıt arasında uyumsuzluk, ve belirsiz içerik güvenliği sınırları. Bu üç kategori, toplam sorunlu kaydın büyük çoğunluğunu oluşturuyordu. Geri kalan vakalar insan kararı gerektiriyordu ve bu oran azaltılabilirdi ama sıfırlanamaz.

Değerlendirilen Seçenekler

• Tek bir LLM hakem modeli: Esnek ama yavaş ve maliyetli; her kayıt için API çağrısı gerekiyor.
• Kural tabanlı filtreler: Hızlı ve ucuz ama dil kalitesi gibi nüanslı sorunları yakalamakta yetersiz.
• Hibrit — kural + model: Açık ihlalleri kurallar hızla yakalıyor, nüanslı boyutlar model değerlendirmesiyle tamamlanıyor. Maliyet ve hassasiyet açısından en iyi denge.

Verdiğim Karar

Hibrit modüler yapıyı seçtim: her boyut bağımsız bir modül, böylece yeni kriter eklemek veya mevcut modülü güncellemek diğerlerini etkilemiyor. Ağırlıklar konfigürasyondan okunuyor; eşik değerleri ops ekibi tarafından kodu değiştirmeden ayarlanabiliyor. Bu esneklik, farklı proje veya müşteri için aynı altyapının farklı kalibrasyonla kullanılmasını sağlıyor.

Uygulama

• 7 boyutlu skorlama sistemi: dil kalitesi, içerik güvenliği, talimat uyumu, Türkçe özgünlük, uzunluk/yoğunluk, format tutarlılığı, tekrar oranı
• Her boyut bağımsız modül; kural tabanlı + LLM hakem hibrit yapı
• Ağırlıklı ortalama ile nihai skor; eşik değerleri konfigürasyon dosyasında
• Ops ekibi için Streamlit tabanlı inceleme dashboard'u: skor dağılımı, sınır vakaları, boyut bazlı filtreleme
• Tüm skorlar PostgreSQL'e kaydediliyor; geçmiş analizi ve kalibrasyon için

Ölçüm Yöntemi

Sistem kalibrasyonu iki aşamada yapıldı: (1) 500 kayıtlık etiketli set üzerinde precision ve recall hesaplandı; (2) ops ekibinin aynı kayıtlara kararlarıyla karşılaştırıldı. Precision odaklı kalibrasyon seçildi: iyi veriyi elemek, kötü veriyi geçirmekten daha az kabul edilebilir.

Sonuç

%91 precision ile manuel inceleme iş yükü %60 azaldı. Ops ekibi, sistemin "gözden geçirilmeli" dediği kayıtlara odaklanabiliyor; açık geçen veya açık elenen kayıtlar artık insan zamanı tüketmiyor.

Sınırlamalar

• %91 precision, %9 oranında iyi verinin elendiği anlamına da geliyor; bu kaybın eğitim üzerindeki etkisi ölçülmedi.
• İçerik güvenliği boyutu, Türkçe için özelleştirilmiş bir model kullanmıyor; genel amaçlı hakem model bazı kültürel nüansları kaçırabilir.
• Eşik kalibrasyonu zaman alıcı; yeni proje veya müşteri için yeniden kalibrasyon gerekiyor.

Öğrendiklerim

Kalite kontrol sistemlerinde "ne kadar sıkı?" sorusunun tek teknik cevabı yok; iş önceliğine göre değişiyor. Bu projede precision'ı recall'a göre önceliklendirdim çünkü kötü veriyi eğitime sokmak, iyi veriyi elemekten daha pahalı. Ama bu karar başka bir bağlamda tersine dönebilir. Sistemi modüler yapıda tasarlamak, bu önceliği kodu değiştirmeden konfigürasyonla değiştirmeyi sağladı.