Veri Bilimcisinin İntikamı

• LLM API’lerinin ortaya çıkmasıyla veri bilimcileri ve MLE’ler AI ürünlerini yayına alma sürecinin ana hattından dışlanmış olsa da, işin gerçek özü — deney tasarımı, metrik ölçümü, olasılıksal sistem hata ayıklama — ortadan kalkmadı
• OpenAI’nin Codex örneği ile Karpathy’nin auto-research projesi, her ikisinin de özünde testler, metrikler ve gözlemlenebilirlik yığınından oluşan bir harness bulunduğunu gösteriyor; bu harness’in önemli bir kısmı da veri bilimi
• Sahada tekrar tekrar görülen 5 eval tuzağı — genel amaçlı metrikler, doğrulanmamış jüri modelleri, kötü deney tasarımı, düşük kaliteli veri ve etiketler, aşırı otomasyon — AI sistemlerinin kalitesini düşürüyor
• Her tuzağın ortak nedeni veri bilimi temellerinin eksikliği; keşifsel veri analizi, model değerlendirme, deney tasarımı, veri toplama ve production ML gibi mevcut yöntemler çözüm olmaya devam ediyor
• "Veriye doğrudan bakmak" en yüksek ROI’ye sahip faaliyet olmasına rağmen en sık atlanan işlerden biri; veri bilimcisinin rolü LLM çağında da hâlâ kritik

---

Veri Bilimcisinin Geri Dönüşü

• Veri bilimcileri bir dönem "21. yüzyılın en seksi mesleği" olarak anılıyor ve yüksek ücret alıyordu
  • Tahmine dayalı modelleme, nedensellik ölçümü, veri örüntülerini keşfetme gibi bileşik beceriler gerektiriyordu
  • Daha sonra tahmine dayalı modelleme işi Machine Learning Engineer (MLE) rolü olarak ayrıştı
• LLM (büyük dil modeli) ortaya çıkınca, şirketlerin AI dağıtırken veri bilimcilerini ya da MLE’leri zorunlu yolun dışına iten bir değişim yaşandı
  • Foundation Model API’leri sayesinde ekipler AI’yi bağımsız biçimde entegre edebiliyor
• Ancak model eğitimi veri bilimcisinin yaptığı işin tamamı değil; deney tasarımı, hata ayıklama ve metrik tasarımı hâlâ temel sorumluluklar
  • Sadece LLM API çağrıları yapmak bu işleri ortadan kaldırmıyor
• PyAI Conf’taki “The Revenge of the Data Scientist” sunumu bu noktayı vaka odaklı biçimde ele alıyor ve veri biliminin rolünün hâlâ önemli olduğunu vurguluyor

Harness’in Özü Veri Bilimidir

• OpenAI’nin Harness Engineering kavramı, ajanların testler ve spesifikasyonlarla çevrili bir ortamda otonom biçimde kod geliştirdiği yapıyı anlatıyor
  • Harness; loglar, metrikler, trace’ler gibi bir gözlemlenebilirlik yığınını içeriyor; böylece ajan kendi anormal davranışlarını fark edebiliyor
• Andrej Karpathy’nin auto-research projesi de validation loss metriğine göre yinelemeli optimizasyon yapan aynı örüntüyü gösteriyor
• "LLM’i API üzerinden çağırmak", deney tasarımı, hata ayıklama ve metrik tasarımı işlerini ortadan kaldırmıyor; harness’in önemli bir bölümü veri bilimi
  • Geçmişte veri inceleme, etiket tutarlılığını kontrol etme ve metrik tasarlama için çok zaman harcanıyordu
  • Bugün ise modelin “hissine” güvenme ya da açık kaynak metrik kütüphanelerini doğrudan kullanma eğilimi var
• Özellikle RAG (Retrieval-Augmented Generation) ve Evals (değerlendirme) alanlarında, veriyi yeterince anlamamaktan kaynaklanan çok sayıda yanlış anlama bulunuyor
• RAG is dead, evals are dead gibi iddialar ortaya atılsa da, bu iddiaları dillendiren ekipler bile pratikte bu kavramlara dayalı sistemler kuruyor
• Veri geçmişi olmayan mühendislerin anlamadıkları şeylerden korkup kaçınması, retrieval ve evals alanlarında özellikle belirgin
• "LLM’i API üzerinden çağırmak", deney tasarımı, hata ayıklama ve metrik tasarımı işlerini ortadan kaldırmıyor; harness’in önemli bir bölümü veri bilimi

5 Eval Tuzağı

• Tuzak 1: Genel Amaçlı Metrikler (Generic Metrics)

  • Helpfulness score, coherence score, hallucination score gibi genel amaçlı metrikler, uygulamanın gerçek arızalarını teşhis etmek için fazla geniş kalıyor
  • Bir veri bilimcisi bu metrikleri hemen benimsemek yerine önce veriyi ve trace’leri doğrudan inceler, “gerçekte ne bozuluyor?” sorusunu anlamaya çalışır
  • "Veriye bakmak", trace’leri bizzat okumak, özel trace görüntüleyicileri yapmak ve hataları sınıflandıran error analysis yürütmek anlamına gelir
  • ROUGE ve BLEU gibi genel benzerlik metrikleri LLM çıktıları için neredeyse hiç uygun değildir; bunun yerine "Calendar Scheduling Failure" ya da "Failure to Escalate To Human" gibi uygulamaya özgü metriklere ihtiyaç vardır
  • Veriye bakmak en yüksek ROI’ye sahip faaliyettir ve en sık atlanan iştir

• Tuzak 2: Doğrulanmamış Jüri Modelleri (Unverified Judges)

  • LLM’i jüri olarak kullanan ekiplerin çoğunun "jüriye nasıl güveniyoruz?" sorusuna bir cevabı yok
  • Veri bilimcileri jüriyi bir classifier gibi ele alır; insan etiketleri toplar, bunları train/dev/test olarak ayırır ve güvenilirliği ölçer
    • Few-shot örnekler eğitim setinden alınır, jüri prompt’u dev set ile iyileştirilir, test seti ise overfitting kontrolü için korunur
  • Sonuçları raporlarken yalnızca accuracy değil, precision ve recall da kullanılmalıdır — hata modu yalnızca %5 olsa bile accuracy gerçek performansı gizleyebilir
  • Classifier doğrulaması modern AI’de kaybolmuş bir beceri hâline geldi

• Tuzak 3: Kötü Deney Tasarımı (Bad Experimental Design)

  • Test seti oluşturma: Ekiplerin çoğu LLM’e “50 test sorgusu üret” diyor; bu yaklaşım temsili olmayan genel veri üretiyor
    • Bir veri bilimcisi önce gerçek production verisini inceler, önemli boyutları belirler, ardından bu boyutlara uygun sentetik örnekler üretir
    • Sentetik veri, gerçek loglar ya da trace’ler temel alınarak oluşturulmalı ve edge case’ler enjekte edilmelidir
  • Metrik tasarımı: Tüm rubriği tek bir LLM çağrısına doldurup varsayılan olarak 1–5’lik Likert ölçeği kullanmak, belirsizliği gizlemek ve sistem performansıyla ilgili zor kararları ertelemek anlamına gelir
    • Bunun yerine kapsamı dar kriterler için ikili (pass/fail) kararlar kullanılmalıdır

• Tuzak 4: Kötü Veri ve Etiketler (Bad Data and Labels)

  • Etiketleme gösterişli görünmediği için çoğu zaman geliştirme ekibine devredilir ya da dış kaynak kullanılır; oysa veri bilimcileri etiketlemenin doğrudan alan uzmanları tarafından yapılmasını ister
  • Bunun, etiket kalitesinin ötesinde daha derin bir nedeni vardır: Shreya Shankar ve diğerlerinin makalesinde doğrulanan "criteria drift" kavramı — kullanıcılar çıktıları değerlendirmek için bir kritere ihtiyaç duyar, fakat çoğu zaman kriteri çıktıları değerlendirirken tanımlar. Yani LLM çıktısını görmeden önce aslında ne istediklerini bilmezler
  • Alan uzmanları ve PM’ler, özet puanların değil ham verinin karşısına oturtulmalıdır

• Tuzak 5: Aşırı Otomasyon (Automating Too Much)

  • LLM’ler plumbing kodu yazma, boilerplate üretme ve değerlendirme bağlantılarını kurma işlerinde yardımcı olabilir
  • Ancak veriye doğrudan bakma işi otomatikleştirilemez — çünkü “çıktıları görmeden önce ne istediğini bilmeme” sorunu vardır
  • Ayrıca anılan diğer tuzaklar arasında benzerlik skorlarının kötüye kullanımı, jüriye “yardımcı mı?” gibi belirsiz sorular sormak, anotatörlere raw JSON okutmak, güven aralığı olmayan kalibre edilmemiş skorlar raporlamak, veri drift’i, overfitting, hatalı örnekleme ve anlaşılması güç dashboard’lar yer alıyor

Veri Bilimi Temelleriyle Eşleştirme

• Bu 5 tuzağın tamamı aynı kök nedene dayanıyor: veri bilimi temellerinin eksikliği
• Her tuzağın mevcut metodolojilerle eşleşmesi şöyle:
  • Trace okuma ve hata sınıflandırma → Keşifsel Veri Analizi (EDA)
  • İnsan etiketleriyle LLM jüri doğrulama → Model Değerlendirme (Model Evaluation)
  • Production verisine dayalı temsili test seti kurma → Deney Tasarımı (Experimental Design)
  • Alan uzmanı etiketlemesi → Veri Toplama (Data Collection)
  • Ürünün production ortamındaki çalışmasını izleme → Production ML
• İsimler değişmiş olabilir ama işin kendisi aynı kaldı
• Python, veriyi keşfetmek ve işlemek için hâlâ en iyi araç seti
• Açık kaynak eklenti (evals-skills) ile eval pipeline’larını analiz edip nelerin yanlış gittiğini teşhis etmeye yarayan araçlar paylaşıldı

[GN⁺]

Hacker News yorumları

• GenAI çözümleri kurarken bunlar iyi pratikler, ancak bu değişimin veri bilimci rolünün sürdürülebilirliğini garanti ettiğini düşünmüyorum
  Eskiden veri bilimciler, doğrudan model kurup iş değeri üretme becerileri sayesinde öne çıkıyordu
  Ama şimdi bu rolü LLM sağlayıcıları ve API çağıran mühendisler üstleniyor. LLM'in davranışını ayarlamak bir tür black magic gibi, ama bunun için matematik bilgisi şart değil
  Geriye değerlendirme ve izleme kalıyor, ama bunlar iş açısından ‘çekirdek değer’ gibi görünmüyor. Hızla prototip dağıtmak isteyen organizasyonlarda ise hatta engel olarak görülüyor
  Sonuçta “veri bilimciler LLM geliştirmede gatekeeper olmalı” diye ikna etmek gereken bir durum ortaya çıkıyor, ama bunun ne kadar ikna edici olduğu şüpheli

  • Ben de benzer hissediyorum. Hazır LLM kullanmak için veri bilimci şart değil. Benim gibi AI dostu bir mühendis de bunu hızlıca öğrenebildi
    Yine de LLM dışında hâlâ özel ML modelleri gereken çok alan olduğunu düşünüyorum. Örneğin AirBnB'nin arama sıralaması ya da Uber'in eşleştirme algoritması LLM ile değiştirilemez
    Sonuçta pazar küçüldü, evet, ama tamamen ortadan kalkmadı
  • Liderliği ikna etmek zor ve aslında birçok DS de böyle değerlendirme işlerini yapmak istemiyor
    Ama bu süreç, “neyi çözmeye çalışıyoruz?” sorusunu netleştirmeye zorluyor. Bazen cevap “bu ürünü yapmaya değmez” de olabiliyor
    Tabii bunu duymak isteyen neredeyse hiç kimse yok
  • Değerlendirme işinin neden mutlaka veri bilimcilerin alanı olması gerektiğini anlamıyorum
    SWE kökenli AI mühendisleri çoğu zaman buna daha uygun oluyor. Çünkü “değerlendirme = otomatik testler” düşünce yapısı onlara daha doğal geliyor
    Gerçekten de birçok ajan projesinde DS'nin rolü neredeyse kayboluyor
  • Veri bilimcilerin sunduğu istatistiksel titizlik, LLM tabanlı çözümlerde neredeyse kaybolmuş gibi görünüyor

• Veri bilimcilere sık verdiğim bir tavsiye

  1. Bağlam verisini eğitim verisi gibi düşünün — LLM verilen bağlamdan öğrenir
  2. Değerlendirme verisini test verisi gibi düşünün — bunu ajanın çalıştırma loglarından toplayıp elle etiketlemek gerekir
     LLM'i değerlendirici olarak kullanacaksanız, o modelin de sonuçta iyi örnek verilerle in-context learning yapması gerekir
     İlgili konuları kitabımda derledim
  • Tamamen katılıyorum. “Evaluations = Tests”
    Ama bir modelin başka bir modelin çıktısını değerlendirmesi gerektiğinde iş meta bir yapıya dönüşüyor; sonuçta bir yerde ‘gerçek doğruyu’ sabitlemek gerekiyor

• Ben veri bilimi/mühendisliği geçmişine sahibim
  AI kullanmak, adeta çözüm uzayını keşfetmek gibi. Milyarlarca parametre kombinasyonu içinde optimum noktayı arıyorsunuz
  Prompt ile arama uzayını daraltıyor, anlamsal sezgisellerle daha iyi çözümler bulmaya çalışıyorsunuz
  Sık sık yerel optimumlara takılıyorsunuz ya da tamamen yanlış yöne gidiyorsunuz. Bu yüzden her hafta kod tabanına baştan başlıyor, sadeleştiriyor ya da özellik ekliyorum. Ancak böyle daha iyi çözümler bulunabiliyor

• Yakın zamanda bahsedilen pg_textsearch gibi örnekler, bu geliştirme tarzına iyi uyan vakalar bence
  Net test vakaları ve benchmark'lar olduğunda başarı ihtimali yüksek
  Ama greenfield geliştirme tarafında test vakalarını tanımlamak, kod yazmak kadar zor hatta daha zor
  Ayrıca LLM'ler sık sık yerel minimumlara sıkışma eğiliminde oluyor. Kod yapısı oturduğunda büyük refactor'ları neredeyse hiç denemiyorlar. Bu da bir tür overfitting'e benziyor

• AI deneylerinin özünün, modelin yeni veriye ne kadar genelleme yaptığını doğrulamak olduğu söyleniyor, ama pratikte “verinin ne olduğu”nu netleştirme adımı eksik kalıyor
  Çünkü insanların veri sandığı şey ile gerçek veri çoğu zaman farklı oluyor

• Bana göre karmaşık LLM-judge workflow'ları kurmaktansa, ajanın davranışını doğrudan gözlemlemek çok daha fazla içgörü sağlıyor

• Dün Karpathy'nin autoresearch yaklaşımını bir ML problemine uyguladım
  Birkaç deneyden sonra modelin gösterdiği sonuca şaşırdım. Kaggle hâlâ eskisi kadar aktif olsaydı, AI çoğu problemi kazanırdı gibi geliyor
  Ama gerçek dünyadaki veri bilimi işlerinde çoğu kişi en temel araçları bile düzgün bilmiyor. Ellerine AI vermek onları bir anda yetkin yapmaz
  Sonuçta uzmanlar hâlâ junior'lara iş yaptırmaya devam eder, uzman olmayanlar da kötü sonuçların içinde debelenir

  • Kaggle problemlerinde AI gerçekten epey iyi olabilir
    Ama gerçek DS işi çoğunlukla eksik veri ve muğlak hedeflerle uğraşmaktır
    İyi bir DS, “bu yapılamaz” diyebilmeli. Oysa LLM her zaman “harika, müthiş fikir!” diyor

• Sonuçta AI geliştirme de benzer bir döngü — “iyi sonucun ne olduğunu tanımla, ona olan farkı ölç, sonra yinelemeli olarak iyileştir”
  Sadece bu düşünce biçimine uzun süredir sahip olanlar, prompt engineer'lardan çok daha ileride

[raykim]

Burada DS tarafındakiler yorum yaptı mı bilmiyorum. Herkesin bakış açısı geliştirici odaklı gibi görünüyor..