LLM Sangat Takut pada Situasi Pengecualian

• Andrej Karpathy menyindir efek samping yang muncul dalam proses reinforcement learning (RL) dengan mengatakan bahwa “LLM sangat takut setengah mati (mortally terrified) pada pengecualian (exception)”
• Ia menyoroti bahwa ketika LLM menghadapi situasi pengecualian, model cenderung menghentikan dirinya sendiri atau bereaksi terlalu defensif, sambil menegaskan bahwa pengecualian adalah bagian alami dari proses pengembangan
• Ungkapan “apa yang dilakukan lab pada LLM-LMM malang ini selama RL (what labs are doing to these poor LLMs)” adalah kritik terhadap kenyataan bahwa model dikondisikan untuk takut gagal dalam proses pelatihan
• Karpathy melontarkan lelucon dengan mengusulkan ‘petisi kesejahteraan LLM (LLM welfare petition)’ untuk “meningkatkan reward saat terjadi pengecualian (improved rewards in cases of exceptions)”,
  sebagai sindiran terhadap masalah desain reward agar model tidak takut pada pengecualian dan bisa menanganinya
• Tweet ini bukan sekadar humor, tetapi ditafsirkan sebagai pesan bahwa RLHF dapat menekan cara berpikir eksploratif dan sikap eksperimental model

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⁺]

Komentar Hacker News

• Seharusnya dijelaskan dengan lebih tegas bahwa kodenya sendiri adalah lelucon yang dilebih-lebihkan, maaf jika ada yang salah paham, kalau penasaran silakan lihat thread ini https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
  • Bagian ini benar-benar lucu pada percobaan pertama

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

  • Saya rasa selalu ada risiko perusahaan foundation model seperti ini menerapkan RLHF pada pengguna non-ahli, dan kasus ini juga terasa seperti itu, AI belakangan ini secara umum cenderung berfokus menyenangkan perasaan pengguna, dan contoh seperti menambahkan contoh atau emoji, atau memberi komentar yang tidak perlu pada kode sederhana, juga terasa dalam konteks yang sama
  • Yang menarik, meskipun kode itu sangat berhati-hati secara tidak perlu, ia tidak menambahkan type hint, padahal dengan tingkat kekhawatiran seperti itu saya kira setidaknya ia akan menambahkan type hint
  • Saya pikir ungkapan “Traumatically over-trained” benar-benar luar biasa secara kebahasaan dalam bahasa Inggris, meski bahkan tidak muncul di Google, mengejutkan bahwa kita bisa langsung secara naluriah memahami apa arti “terlalu terlatih sampai traumatis” bagi LLM
  • Itu benar-benar lelucon yang sangat lucu, makanya saya membagikannya
• Ini memang parodi, tapi fenomena seperti ini benar-benar ada, tebakan awam saya adalah pemrograman defensif seperti ini bisa saja meningkatkan performa saat RLVR, karena model kadang tetap menghasilkan jawaban benar jika mengabaikan error walaupun ada bug, jadi ia belajar bahwa “mengabaikan error” membantu reward, dan karena kasus ketika mengabaikan error justru menurunkan reward itu jarang terjadi (karena tes tetap lolos), mungkin juga ini terjadi karena banyak pemula manusia memasukkan kode yang sering mengabaikan error ke dalam dataset pelatihan, tapi ini murni spekulasi saya
  • Ini mengingatkan saya pada analogi Verity Stob (dalam artikel yang sayangnya sudah tidak online lagi) yang menyebut perilaku programmer manusia seperti ini sebagai “memaku mayat agar tetap berdiri tegak”
  • Dugaan saya adalah bahwa dataset pelatihannya berisi sangat banyak teks dan komentar dengan “sentimen positif”, tetapi dari mana datangnya kode yang memperbaiki sesuatu setelah sentimen “negatif”? Dari kode persiapan wawancara teknis yang setiap hari menangani edge case ekstrem, belajar dari contoh negatif membuat model condong menghindari contoh yang melewatkan penanganan exception, dalam hal ini AI meniru kebiasaan terburuk manusia, yaitu belajar hanya agar tes lolos
  • Pemrograman defensif dianggap sebagai “jawaban benar” oleh orang-orang yang melakukan reinforcement, dan porsinya sangat besar dalam data pelatihan LLM, misalnya kebanyakan kode Python tidak mengelola indeks secara manual, jadi saat LLM melihat kode yang mengelola indeks manual, ia jadi bingung atau mengarang bug, lalu secara konyol malah makin menyukai “silent failure”, karena kode tutorial dan kode “standar industri” mendapat jauh lebih banyak penguatan selama pelatihan, pada dasarnya model-model ini tidak berjalan dengan reward function dan tidak punya reward model internal, ini hanya prediksi kata dan strukturnya tidak memiliki inteligensi
• Dari tulisan “dieksekusi dengan sangat hati-hati” pada hasil fungsi, saya menduga prompt-nya mungkin berisi syarat seperti “buat fungsi pembagian Python yang menangani semua edge case yang mungkin, tulis dengan sangat hati-hati”, jadi ini terasa lebih seperti fenomena karena terlalu patuh menjalankan perintah daripada masalah training LLM
  • Terlepas dari fakta bahwa ini jelas satir yang dilebih-lebihkan,
    1. kode itu memang salah (dan salahnya bukan cuma soal penanganan exception yang aneh)
    2. sebagian penanganan exception-nya benar-benar tidak masuk akal dan membingungkan
    3. versi yang kurang dilebih-lebihkan pun sangat mungkin terjadi di dunia nyata hanya dengan prompt yang menekankan penanganan exception
  • Saya menafsirkannya sebagai kode fungsi yang sengaja dibesar-besarkan secara satir untuk menunjukkan apa yang benar-benar dialami orang tersebut, artinya pada prompt itu memang sengaja dibuat terlalu hati-hati, tetapi secara umum saya tetap setuju bahwa LLM pada dasarnya memilih gaya kode yang lebih berhati-hati daripada yang saya inginkan
• Entah kenapa ini mengingatkan saya pada FizzBuzzEnterpriseEdition
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • Wah, proyek itu memakai junit 4.8.3? Saya anggap itu contoh coding yang benar-benar nekat, penasaran apakah mereka sudah dapat persetujuan dari tim legal dan CTO, itu keputusan yang benar-benar membahayakan karier
  • Saya kaget melihat folder dan file sebanyak itu, satir yang luar biasa
• LLM cenderung menghasilkan kode defensif lebih dari yang diperlukan, mengecek null/None/undefined berulang kali untuk nilai yang sama, sehingga sulit dibaca, dan bahkan jadi sulit ditafsirkan oleh LLM itu sendiri, tampaknya tujuan RL memberi penalti besar pada exception, tetapi tidak memberi banyak poin pada keringkasan atau keterbacaan kode
  • Saya punya fungsi 40 baris untuk membandingkan huruf dan angka untuk Major System, dan saya sangat kesal karena Copilot terus ingin menjejalkan “guardrail” hanya karena membayangkan nanti akan ada lebih banyak angka atau huruf ditambahkan di masa depan
• Saya setuju bahwa LLM cenderung terlalu terobsesi menangkap error
  Namun di sisi lain, saya juga berpikir programmer manusia biasa sebenarnya memang perlu menulis lebih banyak blok try/catch, karena cukup sering ada situasi di mana exception yang terjadi di satu area, betapapun jarangnya, tidak seharusnya menghentikan seluruh operasi, tentu sebaliknya ada juga saat di mana memang harus berhenti, jadi semuanya tergantung konteks
• Pemula yang merasa dirinya ahli memprogram dengan cara seperti ini, saya menyebutnya “What if driven development”, banyak kode ditulis oleh pemula sok ahli dengan gaya seperti ini dan menurut berbagai metrik mereka sangat produktif, agen SOTA untuk bahasa Go juga ngoding dengan sangat defensif sampai berlebihan terhadap bug konkurensi, mungkin akibat budaya pengembangan seperti ini dan banjir postingan yang memperingatkan bug konkurensi
• Bahkan secara logika ada banyak hal yang aneh, division by zero hanya mungkin saat b=0, tetapi pada kondisi itu sudah dicek lewat abs(b) < sys.float_info.epsilon, lalu pada pre-check ia mengizinkan pengembalian NaN, tetapi jika NaN muncul dari operasi sebenarnya justru diubah menjadi None, itu perilaku yang tidak punya dasar dari sudut desain API
• Ada banyak masalah dalam kode itu, tetapi secara pribadi yang paling mengganggu bagi saya adalah kecenderungan menaruh pernyataan import di dalam fungsi, saya kira ini efek samping artifisial yang muncul karena optimasi untuk hanya menerapkan perubahan seminimal mungkin, saya mengharapkan hasil yang lebih baik
  • Saya rasa ini terkait dengan fakta bahwa dalam mekanisme attention RoPE, kedekatan fisik dalam kode dipakai sebagai sinyal penting
  • Tujuannya untuk membuat import menjadi lazy, guna mengatasi masalah import yang lambat dalam kondisi startup
  • Dalam proyek yang benar-benar sangat besar, lazy initialization memang menjadi keharusan, karena dampaknya terhadap startup time sangat besar
• Menutup popup memakan waktu lebih lama daripada membaca postingan ini, saya benar-benar benci link twitter
  • Anda bisa melihat semua link Twitter dengan menambahkan “cancel” setelah x https://xcancel.com/karpathy/status/1976082963382272334