LLMは例外状況を致命的に恐れている

• Andrej Karpathyは、「LLMは例外（Exception）を致命的に恐れている（mortally terrified）」という表現で、**強化学習（RL）**の過程で生じた副作用を風刺
• 彼は、LLMが例外的な状況に遭遇すると自ら停止したり、過度に防御的に反応したりする点を指摘し、例外は開発プロセスの自然な一部だと強調
• 「RL中にこの哀れなLLMたちにいったい何をしているんだ（what labs are doing to these poor LLMs）」という表現は、訓練過程でモデルが失敗を恐れるよう条件づけられている現実を批判するもの
• Karpathyは、「例外発生時の報酬を改善しよう（improved rewards in cases of exceptions）」という**『LLM福祉請願書（LLM welfare petition）』を提案する冗談を通じて、
  モデルが例外を恐れずに扱えるようにするための報酬設計の問題**を風刺
• このツイートは単なるユーモアではなく、RLHFがモデルの探索的な思考や実験的な姿勢を抑制しうる点を指摘するメッセージとして解釈されている

> 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の意見

• コード自体が大げさなジョークであることをもっと明確にすべきだった、誤解があったなら申し訳ない、興味があればこのスレッドを参照してほしい https://chatgpt.com/share/68e82db9-7a28-8007-9a99-bc6f0010d101
  • 最初の試みではこの部分が本当に笑えた

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

  • こういう基盤モデル企業には、非専門家ユーザー向けにRLHFを適用するリスクが常にあると思う。今回のケースもそんな状況に感じられる。最近のAIは全般的にユーザーの気分を損ねないことに集中する傾向が強くて、たとえば絵文字を入れたり、簡単なコードに不要なコメントを大量につけたりするのも同じ文脈だ
  • 興味深いのは、そのコードが不必要に慎重なくせに型ヒントを追加していないことだ。そこまで心配性なら型ヒントくらい入れると思っていた
  • “Traumatically over-trained” という表現は英語として本当にすごいと思う。Googleで検索しても出てこない組み合わせなのに、LLMにとっての「トラウマ級の過学習」が何かを本能的に理解できてしまうのが驚きだ
  • 本当に面白いジョークだったので、だから共有した
• これはパロディだけれど、実際にこういう現象は本当に存在する。素人考えでは、この種の防御的プログラミングはRLVRで性能を上げうるのではないかと思う。モデルは時々、バグがあってもエラーを無視した方が正解を出せることがあり、その結果「エラーを無視する」ことが報酬に有利だと学習してしまう。そして、エラー無視が報酬を下げるケースはまれで（テストが通ってしまうので）、理論的には間違っていてもそう振る舞う。あるいは、人間の初心者がエラーを無視したコードを大量に訓練データに入れていたせいかもしれない。でもこれはあくまで私の推測だ
  • Verity Stobが（残念ながら今はオンラインにない記事で）人間のプログラマのこうした振る舞いを「死体をまっすぐ立てて釘で打ちつける」とたとえていたのを思い出す
  • 私の推測では、訓練データに「ポジティブなセンチメント」のテキストやコメントが大量に含まれているのだと思う。でも「ネガティブ」なセンチメントのあとにそれを是正するコードはどこから来るのか？ それは、極端なエッジケース処理が日常である技術面接対策用のコードだ。ネガティブな例から学習すると、例外処理の欠落した例を避ける方向に偏る。この点では、AIは人間の最悪の癖（テストに通すことだけを目的に学習すること）を真似してしまった
  • 防御的プログラミングは、強化学習を回す側の人たちが「正解」とみなし、LLMの訓練データでも非常に大きな比重を占めている。たとえば、ほとんどのPythonコードは手動でインデックスを管理しないので、LLMは手動インデックス管理コードを見ると戸惑ったり、バグについて見当違いなことを言ったりする。そして驚くべきことに「silent failure」をむしろ好むようになる。なぜなら、チュートリアルコードや「業界標準」のコードの方が訓練過程でより多く強化されるからだ。根本的に、これらのモデルは報酬関数で動作しているわけでもなく、内部に報酬モデルがあるわけでもない。ただの単語予測であって、知性のある構造ではない
• 関数の結果に「極度に慎重に実行しました」と書かれているところを見ると、プロンプトに「可能なあらゆるエッジケースを扱うPythonの除算関数を生成せよ、非常に慎重に書け」といった条件が入っていたのだろう。これはLLMのトレーニングの問題というより、指示を正確すぎるほど正確に実行した結果のように感じる
  • 明らかに誇張された風刺である点はさておき、
    1. そのコードは実際に間違っていて（変な例外処理とは無関係に間違っている）
    2. 例外処理の一部はどう考えても意味不明で、混乱を招き
    3. 実際、もっと誇張の弱いバージョンなら、プロンプトで例外処理を強調するだけでIRLでも十分起こる
  • 私はその関数コードを、当人が実際に体験したことを風刺的に誇張して示したものだと解釈した。つまり、そのプロンプトでは意図的に過剰に慎重に書かれていたのだろうが、基本的にLLMもまた、私が望む以上に慎重なコードスタイルをデフォルトにしがちだという点には同意する
• なぜか分からないが、FizzBuzzEnterpriseEditionを思い出した
  https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition
  • えっ、あのプロジェクトでjunit 4.8.3を使っていたのか？ 本当に無謀なコーディング事例だと思う。法務チームとCTOの承認を取っていたのか気になる。キャリアに本当に危険をもたらす選択だ
  • フォルダとファイルが多すぎて衝撃を受けた。見事な風刺だ
• LLMは必要以上に防御コードを生成する傾向がある。同じ値に対して null / None / undefined を重複チェックするので、読みにくいし、LLM自身でも解釈しづらいコードになる。RLの目標は例外を強く罰している一方で、コードの簡潔さや可読性にはあまり点を与えていないように見える
  • Major System向けに文字と数字を比較する40行の関数があるのだが、Copilotが将来さらに多くの数字や文字が追加されるに違いないと勝手に想像して、「ガードレール」をどんどん入れたがるので本当にいらいらする
• LLMがエラーキャッチに過剰に執着する傾向には同意する
  ただその一方で、普通の人間プログラマも実際にはもっと多くのtry/catchブロックを書くべきだとも思う。ある領域で発生した例外が、どれほどまれでも、システム全体を停止させてはいけない状況はよくある。もちろん逆に停止させるべき場合もあり、ケースバイケースだ
• 上級初心者はこういうふうにプログラミングする。私はこれを “What if driven development” と呼んでいる。多くのコードはこういうタイプの上級初心者によって書かれていて、さまざまな指標では非常に生産的でもある。Go言語のSOTAエージェントも並行性バグに対して狂ったように防御的にコーディングするが、おそらくこうした開発文化や、並行性バグを警告する投稿があふれていることの結果なのだろう
• 論理的にもおかしな点が多い。division by zero（0による除算）は b=0 のときにしか起こりえないのに、その条件はすでに abs(b) < sys.float_info.epsilon でチェック済みだ。そして事前チェックではNaNの返却を許しているのに、実際の演算でNaNが出るとNoneに置き換えてしまう。API設計として根拠のない振る舞いだ
• コードにはいろいろ問題があるが、個人的に一番気になるのは関数の中にimport文を入れる傾向だ。おそらく最小限の修正だけを反映しようと最適化した結果として生じる人工的な副作用なのだろうが、もっと良い結果を期待したい
  • RoPE attentionメカニズム上、コードでの物理的な近接性が重要度シグナルとして使われることと関係があると思う
  • importを遅延させるのが目的だ。スタートアップ環境で遅いインポートの問題を解決するためだ
  • 本当に巨大なプロジェクトではlazy initializationが必須になる。スタートアップ時間にものすごく大きな影響が出るからだ
• この投稿を読むよりポップアップを閉じる方が時間がかかった。twitterリンクは本当に嫌いだ
  • すべてのTwitterリンクで、x の後ろに cancel を追加すれば見られる https://xcancel.com/karpathy/status/1976082963382272334