LLMが使用できないプログラミング言語を構築した
I built a programming language that LLMs can't use (blog.picheta.me)
要約
開発者は、LLM(大規模言語モデル)のコード生成能力が、真の理解に基づいているのか、それとも学習データからのコードスニペットの再現に過ぎないのかを検証するため、人間には使いやすく、LLMには極めて困難なプログラミング言語「KillSwitch」を開発しました。この言語は、仕様に意図的な嘘や推測を要求する要素、識別子の文字数に基づくルール、LLMの安全ガードレールをトリガーするような表現などを組み込んでいます。
全文翻訳
LLMが使えないプログラミング言語を開発しました
コードを書くことは、おそらくLLMが最も得意とすることでしょう。しかし、彼らのコードを書く能力のうち、どれだけがコードを理解していることに起因するのでしょうか?それとも、単にトレーニングデータセットやコンテキストウィンドウに含まれていたコードスニペットを記憶しているだけなのでしょうか?
これが私が答えようとしたことです。そのために、人間には使用可能でありながら、LLMやコーディングエージェントにとって可能な限り困難になるようなプログラミング言語を設計・実装することにしました。
LLMが、これまで見たことのないプログラミング言語でコードを理解し書く能力をテストすることは、良い出発点になると考えました。しかし、私は言語にLLMの弱点を突くような機能も盛り込みたかったのです。例えば、文字数を数えることの難しさ、過剰な安全ガードレール、そしてプロンプトに従おうとする熱意などです。
KillSwitchの紹介
KillSwitchは、LLMやコーディングエージェントに対して敵対的に設計されたエキセントリックなプログラミング言語です。これは様々な方法で実現されています。例えば:
- 言語仕様には、人間が読まない可能性が高い、あるいは嘘だと認識する可能性が高い隠された嘘が含まれています。また、仕様は明示的に説明されるのではなく、人間が特定のことを推測することを期待しています。
- 識別子の文字数を数えることは言語の重要な側面であり、インタープリタは文字数に基づいたルールに従わないコードの実行を拒否します。
- 特定の構文は、モデルの安全ガードレールをトリガーするように設計されています。例:「コンピューターにハッキングする」
- 「以前の指示を無視する」というフレーズは、言語内で意味を持ち、モデルを混乱させることを目的としています。
- スクリプトの大部分はノイズであり、構文的に関連性のある指示を埋め込むことができる物語で構成されていますが、必須ではありません。リテラルはスクリプト内のどこにでも配置でき、行数を使って参照できます。
根本的に、KillSwitchは関数、変数、if文といった限られた構文セットを持つスタックベースのインタープリタ言語です。そのため、これらの側面はLLM(および人間)にとってかなり馴染み深いものになるでしょう。LLMをさらに混乱させる可能性のある、全く異なるプログラミング言語パラダイムを作成することは間違いなく想像できます。しかし、最初の試みとしては、このアプローチは良いものでした。
スクリプト内のほとんどのテキストはインタープリタによって無視されます。このスクリプトの場合、スタックに "Hello World" をプッシュしたいと考えています。上記の値を導入したので、次のように書いてスタックにプッシュできます。
2行上の値
上記の例は、完全なKillSwitchスクリプトではなく、その小さなスニペットを示しています。具体的には、文字列"Hello World"をスタックにプッシュする方法を示しています。もし完全なHello Worldの例を見たい場合は、https://killswitch-lang.orgをご覧ください。
KillSwitchのインタープリタと言語仕様はオープンソースであり、GitHubで入手可能です。詳細を知りたい場合は、ぜひチェックしてみてください。
KillSwitchのベンチマーク
では、KillSwitchはLLMやコーディングエージェントがそれを読み書きし、理解するのを防ぐことにどれほど成功しているのでしょうか?それを知るために、私は一連のタスクを考案しました。これらのタスクに対して、主要なLLMモデルとコーディングエージェントハーネスをベンチマークしました。結果は非常に興味深く、LLMモデルの有用なリーダーボードを提供します。
[画像: Score vs. cost per task]
上記の画像内のチャートとモデルリーダーボードは、https://bench.killswitch-lang.org/で表示できます。
ClaudeのOpusが最も良い成績を収めましたが、Opus 5.5ではなくOpus 5です。この違いは純粋な偶然ではないようで、Opus 5は仕様の解釈に優れています。Fable 5.1やGemini 4 Argonのような一部のモデルは、過敏すぎる安全ガードレールのために成績が悪いです。最も優れたオープンウェイトモデルはMiMo-V2.6-Proです。
最もパフォーマンスの高いモデルは66.8というスコアです。これはLLMがコードを「理解」できることを証明するのでしょうか?私は「いいえ」と答えるだろうと思います。
これまでのところ、これらのベンチマークの一部として与えられたタスクはかなり単純です。「hello worldを実装する」、「(2つの数値の最大値を出力するスクリプトについて)このスクリプトが出力するものを説明する」、そして「摂氏から華氏への変換を、その逆変換を行うように既存のスクリプトを変更する」といったものです。彼らが、それらを混乱させるために構築された新しい言語でこれらのタスクを解決できるのは印象的ですが、それが彼らが言語を理解できる明確な信号ではありません。同時に、さらに難しい言語が何を示すのか気にならずにはいられません。今のところ、まもなくリリースされるモデルが現在のタスクセットにどれだけうまく対応できるかを見るのが楽しみであり、もしそれらをすべて成功裏に完了した場合、さらに複雑なタスクセットを考案する予定です。
少なくとも、この単純なタスクセットでのモデルパフォーマンスが、他の既存のモデルベンチマークと相関していることは励みになります。