ディスカッション (9件)
LLM(大規模言語モデル)の評価において、既存のベンチマークでは学習データへの「汚染(リーク)」や単なるパターンマッチングが課題となっています。そこで登場したのが『EsoLang-Bench』です。これは、Brainfuckなどの「難解プログラミング言語(Esoteric Languages)」を用いることで、モデルが単に学習済みのコードを思い出しているだけなのか、それとも未知の構文に対して論理的な推論(Genuine Reasoning)をゼロから行えているのかを厳格に評価するためのベンチマークです。
うーん…俺の勘だと、これの一部はPythonのキーワードが全部1トークンだからじゃないかな。ああいう変な言語だと、トークン化のせいで推論が難しくなってるのかも。難解プログラミング言語(esolang)を少し修正して、キーワードを1トークンだけにしたらベンチマーク結果がどう変わるか見てみたいね。
ついにMalbolgeでプログラミングする大胆な新時代が到来するかと期待してたんだけど、どうやら楽観的すぎたみたいだ。
普段使いで便利だと思ってるモデルが、Unlambdaの問題をほぼ一つも解けてないのにはショックだよ。結果を見る前は、Schemeを学んだ人間ならラムダ計算や組み合わせ論理を理解するのはそんなに難しくないから、Unlambdaのスコアは他より高いだろうと予想してたんだ。でも、一番成績が良かったQwen-235Bですら、ほぼ全滅だったね。
LLMにウェブから言語のドキュメントを引っ張らせて仕組みを理解させれば、もっといい結果が出せると思うな。その言語用の「スキル」を持たせれば、間違いなく精度は上がるはず。
「最先端モデルのPythonのスコアは約90%だが、難解プログラミング言語ではわずか3.8%。これは現在のコード生成が真のプログラミング推論ではなく、訓練データの暗記に頼っていることを露呈している。」……これ、俺がやっても同じくらいのスコアになりそうだけど、それは俺も推論じゃなくて暗記に頼ってるって証明になるのか?それとも、単にesolangが設計上推論しにくいだけ?もっとフェアにやるなら、マイナーだけど「実用的」な言語を使うべきだよ。CoffeeScriptとかAda、PL/I、Odin、あるいは例のこだわりが強い人がQBEベースで実装してるあのシステムプログラミング言語とかさ。
これには驚かないし、こういうテストが見られて嬉しいよ。LLMを使ってていつも思うのは、実際の理解が欠けてるってこと。俺は主にElixirを書いてるけど、どの最先端モデルもOTP/Beamの並行処理を理解してないって断言できる。理解してるふりはするけど、アクターモデルの仕組みを分かってない変なコードを出しがち。訓練データの並行処理コードを平均化してるだけで、理解を模倣してるだけなんだよね。結局、平均化が通用しないとノイズまみれになる。ありえない事態をガードしたり、逆にメッセージパッシングの仕組みを分かってなくてレースコンディションを誘発したり。今のモデルはボイラープレートの生成や要約は得意だけど、何が起きてるかを実際に理解して推論する能力には欠けてる。このテストはそこを上手く突いてるし、LLMは訓練データ次第だってことを思い出させてくれる。こういうテストで良いスコアを出せるモデルが出てきたら、既存の答えを掘り出すんじゃなくて、新しい解決策やアプローチを見つけられるようになるんだろうな。
CodexにPythonのサブセットからBrainfuckへのトランスパイラを作らせて、そのPythonサブセットで問題を解かせれば、もっと上手くいく気がする。それってズルになるのかな?
俺はこれの逆のパターンに遭遇してる。最新のプロ向けモデルはどれも、PowerShellを正しく使うのに必死だよ。クォートとかエスケープ、ヒアドキュメントみたいな超基本的なことすら怪しい。agents.mdに何を書こうが関係ない。結局、自力で解決するまでエラーを出し続けるトークンの無駄遣いを受け入れて、そのセッションを使い続けるしかないんだ。呪いのbash->posh変換レイヤーを書こうかと思ったくらいだよ。なのに、Objective-C 3.0もどきのコードは平気でスラスラ書くんだよな。