LLM’ler istisnai durumlardan ölümüne korkuyor

• Andrej Karpathy, “LLM’ler istisnalardan (Exception) ölümüne korkuyor (mortally terrified)” sözüyle, pekiştirmeli öğrenme (RL) sürecinde ortaya çıkan yan etkiyi hicvediyor
• LLM’lerin istisnai bir durumla karşılaştığında kendilerini durdurduğunu ya da aşırı savunmacı tepki verdiğini vurgularken, istisnaların geliştirme sürecinin doğal bir parçası olduğunu özellikle belirtiyor
• “Laboratuvarlar RL sırasında bu zavallı LLM’lere ne yapıyor (what labs are doing to these poor LLMs)” ifadesi, eğitim sürecinde modelin başarısızlıktan korkacak şekilde koşullandırıldığı gerçeğine yönelik bir eleştiri
• Karpathy, “istisna durumlarında ödülleri iyileştirelim (improved rewards in cases of exceptions)” şeklinde bir ‘LLM refah dilekçesi (LLM welfare petition)’ önerme şakasıyla,
  modelin istisnalardan korkmadan onlarla başa çıkmasını sağlayacak ödül tasarımı sorununu hicvediyor
• Bu tweet, sadece bir mizah değil; RLHF’nin modelin keşifçi düşünmesini ve deneysel tavrını baskılayabileceğine işaret eden bir mesaj olarak yorumlanıyor

> I don't know what labs are doing to these poor LLMs during RL but they are mortally terrified of exceptions, in any infinitesimally likely case. Exceptions are a normal part of life and healthy dev process. Sign my LLM welfare petition for improved rewards in cases of exceptions.

[GN⁺]

Hacker News görüşü

• Kodun baştan sona abartılı bir şaka olduğunu daha net belirtmeliydim; yanlış anlaşıldıysa özür dilerim, merak edenler şu diziyi okuyabilir: https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
  • İlk denemede şu kısım gerçekten çok komikti

    if random.random() < 0.01:
      logging.warning("This feels wrong. Aborting just in case.")
      return None
    

  • Bu foundation model şirketlerinin uzman olmayan kullanıcılara RLHF uygulamasının her zaman bir risk taşıdığını düşünüyorum; bu vaka da öyle hissettiriyor. Son dönem yapay zekalar genel olarak kullanıcıyı memnun etmeye fazlasıyla odaklanıyor; örnekler eklemek, emoji koymak ve basit koda gereksiz yorumlar yazmak da aynı bağlamda
  • İlginç olan, kod gereksiz derecede temkinli olmasına rağmen type hint eklememiş olması; bu kadar kaygılıysa type hint de eklemesini beklerdim
  • “Traumatically over-trained” ifadesinin İngilizce açısından gerçekten müthiş olduğunu düşünüyorum; Google'da bile çıkmayan bir ifade birleşimi ama LLM'nin “travma düzeyinde aşırı eğitilmiş olma”nın ne demek olduğunu içgüdüsel olarak kavraması şaşırtıcı
  • Gerçekten çok komik bir şakaydı, o yüzden paylaştım
• Bu bir parodi ama bu olgunun gerçekte var olduğuna inanıyorum. Tamamen cahilce tahminim şu: bu tür savunmacı programlama RLVR sırasında performansı artırıyor olabilir. Model bazen hata olsa da onu görmezden gelince doğru cevabı veriyor, dolayısıyla “hatayı yok sayma” ödüle yardımcı oluyor diye öğreniyor. Ve hatayı yok saymanın ödülü düşürdüğü durumlar nadir olduğundan (testler geçtiği için), teorik olarak yanlış olsa bile bu davranış pekişiyor olabilir. Bir diğer olasılık da, insan acemilerin hata yok sayan çok fazla kodu eğitim setine koymuş olması. Ama bu sadece benim tahminim
  • Verity Stob'un (ne yazık ki artık internette olmayan bir yazıda) insan programcıların bu davranışını “cesedi dik tutup çivilemek” diye benzetmesi aklıma geldi
  • Benim tahminim, eğitim setinde çok fazla “pozitif sentiment” içeren metin ve yorum bulunması. Peki “negatif” sentimentten sonra bunu düzelten kod örnekleri nereden geliyor? Elbette aşırı uç edge case'lerle uğraşmanın gündelik iş olduğu teknik mülakat hazırlık kodlarından. Negatif örneklerle öğrenince, eksik exception handling içeren örneklerden kaçınmaya doğru kayıyor. Bu açıdan yapay zeka, insanların en kötü alışkanlığını — sadece testleri geçmeye yönelik öğrenmeyi — taklit etmiş durumda
  • Savunmacı programlama, reinforcement yapan kişilerin “doğru” saydığı bir şey ve LLM eğitim verisinde çok büyük bir paya sahip. Örneğin Python kodlarının çoğu index'i elle yönetmez; bu yüzden LLM elle index yönetimi görünce afallıyor ya da olmayan bug'lar uyduruyor. Sonra da saçma biçimde “silent failure”ı daha çok tercih eder hale geliyor; çünkü tutorial kodu ve “industry standard” kod eğitim sırasında daha çok pekiştiriliyor. Temelde bu modeller bir reward function ile çalışmıyor, içlerinde reward model yok; sadece kelime tahmini yapıyorlar ve yapısal olarak zekaya sahip değiller
• Fonksiyon sonucunda “aşırı temkinli şekilde yürütüldü” yazdığına bakınca, prompt'ta muhtemelen “mümkün olan tüm edge case'leri ele alan bir Python bölme fonksiyonu üret, aşırı temkinli yaz” gibi bir şart vardı. Bu bana LLM eğitimiyle ilgili bir sorundan çok, söyleneni fazla harfiyen yerine getirme durumu gibi geliyor
  • Bunun açıkça abartılı bir hiciv olduğunu bir kenara bırakırsak,
    1. o kod gerçekten yanlıştı (garip exception handling'den bağımsız olarak da yanlış)
    2. exception handling'in bazı kısımları hiçbir şekilde mantıklı değil, kafa karıştırıcı
    3. gerçekte de, prompt'ta exception handling biraz vurgulansa bunun daha az abartılı sürümleri rahatça ortaya çıkıyor
  • Ben o fonksiyon kodunu, kişinin gerçekten yaşadığı şeyi hicivsel biçimde abartarak gösteren bir örnek olarak okudum. Yani prompt'ta bilerek aşırı temkinli yazdırılmış olabilir ama özünde LLM'lerin benim istediğimden daha temkinli bir kod stilini varsayılan olarak seçtiği konusunda katılıyorum
• Nedense aklıma FizzBuzzEnterpriseEdition geldi
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • Vay, o projede junit 4.8.3 mü kullanılmış? Bence bu gerçekten pervasız kodlamanın bir örneği. Bunu hukuk ekibi ve CTO'dan onay alarak mı yaptılar merak ediyorum; kariyer açısından gerçekten riskli bir tercih
  • Klasör ve dosya sayısı karşısında şok oldum, harika bir hiciv
• LLM'ler ihtiyaç duyduğundan fazla savunma kodu üretme eğiliminde; aynı değer için null/None/undefined kontrollerini tekrar tekrar yapıyorlar. Bu da kodu okumayı zorlaştırıyor, hatta LLM'nin kendisi için bile yorumlaması güç hale getiriyor. RL hedefi exception'ları ciddi biçimde cezalandırıyor gibi, ama kodun sadeliğine ya da okunabilirliğine pek puan vermiyor
  • Major System için karakter ve sayıları karşılaştıran 40 satırlık bir fonksiyonum var; Copilot sanki gelecekte daha fazla sayı ya da karakter eklenecekmiş gibi sürekli “guardrail” eklemeye çalışıyor, bu da aşırı sinir bozucu
• LLM'lerin hata yakalamaya fazla takıntılı olma eğilimine katılıyorum
  Ama öte yandan sıradan insan programcıların da gerçekte daha fazla try/catch bloğu yazması gerektiğini düşünüyorum. Bazı durumlarda, bir bölgede ortaya çıkan exception'ın — ne kadar nadir olursa olsun — tüm işlemi durdurmaması gerekir. Tabii bazı durumlarda da durdurması gerekir; bağlama göre değişir
• Uzman acemiler böyle programlar. Ben buna “What if driven development” diyorum. Çok fazla kod bu tarz uzman acemiler tarafından yazıldı ve çeşitli metriklere göre son derece üretkenler. Go dilindeki SOTA ajanlar da eşzamanlılık bug'larına karşı delicesine savunmacı kod yazıyor; muhtemelen bu geliştirme kültürünün ve concurrency bug'ları konusunda uyaran gönderilerin her yerde olmasının bir sonucu
• Mantıksal olarak da bir sürü tuhaflık var. Division by zero sadece b=0 iken olabilir ama bu durum zaten abs(b) < sys.float_info.epsilon ile kontrol edilmiş. Ayrıca ön kontrolde NaN döndürmeye izin verirken, gerçek işlemde NaN çıkarsa onu None ile değiştiriyor; API tasarımı açısından temelsiz bir davranış
• Kodda birçok sorun var ama beni kişisel olarak en çok rahatsız eden, fonksiyon içine import koyma eğilimi. Muhtemelen yalnızca en az değişikliği yansıtacak şekilde optimize edilmesinden doğan yapay bir yan etki ama daha iyi bir sonuç beklerdim
  • Bunun, RoPE attention mekanizmasında kod içindeki fiziksel yakınlığın bir önem sinyali olarak kullanılmasına bağlı olduğunu düşünüyorum
  • Amaç import'u lazy hale getirmek; startup koşullarında yavaş import sorunlarını çözmek için
  • Gerçekten devasa projelerde lazy initialization zorunlu hale gelir; çünkü startup süresine etkisi çok büyük olur
• Bu yazıyı okumaktan çok popup kapatmaya zaman harcadım; Twitter bağlantılarından gerçekten nefret ediyorum
  • Tüm Twitter bağlantılarında x sonrasına “cancel” eklerseniz görüntüleyebilirsiniz https://xcancel.com/karpathy/status/1976082963382272334