Zenn
🧱

LLMはなぜLispが苦手なのか

に公開
lisp
LLM
Agent
idea

はじめに

前回、コーディングエージェントに関するゆるめの記事（o3ちゃんはLispの括弧を閉じれない）を書きました。今回は、なぜLLMがLispの括弧を苦手としているのかを深掘りしていきたいと思います。
最初に浮かんだ疑問は、なぜLLMはPythonやJavaScriptと違ってLispが苦手なのかということです。確かにLispは他の言語と違い、括弧を正確に数えることが非常に重要になる言語です。
「数える」ということで思いついたのが、Transformerベースモデルの「ストロベリー問題」でした。

ストロベリー問題との関連性について

思い出してください。OpenAIが開発していたAIモデルに「Strawberry（ストロベリー）」というコードネームが付けられたことがありました。この「Strawberry」モデルは、従来のGPTモデルでは達成できなかった、より高度な人間のような思考プロセスを目指していました。特に、複雑な数学やプログラミングの問題をステップバイステップで解決する「Chain of Thought（思考の連鎖）」と呼ばれる推論能力に優れているとされていました。このコードネームがつけられた具体的な意味については、内部プロジェクトを指すための覚えやすく中立的な名称として使われたという見方や、AIが「strawberry」という単語の「r」の数を正確に数えられないという課題を正直に認め、それを克服しようとする開発チームの意思の表れという見方などがありました。そうです。「r」の数を正確に数えられないという課題は以前からあり、いまだ克服されていません。

Geminiと対話してみると、やはり関連性はありそうだったので、Geminiに論文スタイルでまとめてもらいました。なかなか説得力のある説明です。もしこれが本当なのであれば、トランスフォーマーを使っている限りは、コーディングエージェントでLispプログラミングをするのは絶望的な気がしてきました。

Lisperはオーガニックコーディングが必要で、当面職を失うことはないのかもしれません。元から職なんてほとんどないというツッコミはなしです。

Emacs LispでIMEをエージェントに実装してもらっている身としては、そうも言っていられないため、対策を考えているところです。
とりあえずは、以下の考察をお楽しみください。

LLMにおける「ストロベリー問題」とLisp構文対応困難性の構造的関連性に関する一考察

概要

本稿では、大規模言語モデル（Large Language Model, 以下LLM）に見られる典型的なエラー例である「ストロベリー問題」と、Lispのような構文的厳密性を持つ言語における括弧対応の困難性との間に見られる共通の根本構造について考察する。これらの問題は一見異なるようでいて、いずれもLLMのトークン処理、Attentionメカニズム、および非決定論的予測という特性に起因しており、形式文法の要求する厳密性とLLMの本質的な制約とのギャップを浮き彫りにしている。

1. 問題の定義

1.1 ストロベリー問題

"strawberry" のような単語において、LLMがそのスペルを正確に再現できず、"stawberry" や "strawbery"、"strawwberry" のように r の数を間違える現象を指す。これは文字列におけるミクロな繰り返しの制御がうまくいかない典型例である。

1.2 Lispにおける括弧対応の問題

LLMを用いたコーディングエージェントにおいて、Lispのように括弧の対応関係（再帰的かつ入れ子構造）を厳密に要求する言語で、括弧の数が一致しない、あるいは対応しないコードを生成する問題がしばしば発生する。

2. 共通構造の分析

2.1 文法的制約の性質

両者に共通しているのは、「一貫性のある繰り返し」あるいは「構造的対称性の保持」が必要である点である。前者は線形な文字列上の同一トークンの繰り返し、後者はツリー構造上の開閉対応である。いずれも形式文法の文脈自由文法（Context-Free Grammar, CFG）以上の制約に基づく。

2.2 Transformerベースモデルの制限

LLMのベースであるTransformerは、トークン間の依存関係を自己注意機構（Self-Attention）で学習するが、Attentionは確率的かつ非記憶的であり、繰り返し回数や括弧の深さといった状態的制約を厳密に保持することが困難である。

また、トークン分割はBPEなどのアルゴリズムによって決まるため、"rr" という繰り返しが1トークンにも2トークンにもなり得る。この不定性は構文的な予測精度に直接影響を与える。

2.3 非形式的言語モデルの性質

LLMは形式文法に従うように設計されているわけではなく、学習データから出現頻度や文脈に基づいて出力を確率的に生成するため、文法的な整合性はあくまで副次的な効果でしかない。したがって、局所的にもっともらしい選択を積み重ねた結果、グローバルには整合性を欠くことがある。

3. 実用上の影響

プログラミングや構文解析といった応用では、単一文字のミスや括弧の対応エラーが致命的なバグにつながるため、LLMの出力に対する信頼性は大きく損なわれる。自然言語処理では冗長性や冗談が通じるが、コードでは構文違反は直ちに実行不能を意味する。

4. 解決に向けたアプローチ

アプローチ 内容 利点 欠点
シンタックスアウェアLLM ASTや文法情報を事前学習に取り入れる 精度向上 訓練コスト大
出力検証・修正ステージ 出力後に構文検証と修正を加える 実用的 遅延が発生
ニューラル×シンボリック融合 出力を形式文法ベースのエンジンと組み合わせて扱う 正確性向上 実装が複雑
明示的プロンプト設計 出力の整合性を求める指示をプロンプトに追加 簡便 限界あり

結論

ストロベリー問題とLisp構文の括弧対応問題は、いずれもLLMの構造的制約と形式言語的要件の不一致から生じる現象である。これらの問題は、LLMが確率的に言語生成を行うモデルである以上、根本的には避けがたい側面を持つ。今後は、構文的正確性を求めるタスクにおいては、LLM単独ではなく、形式的な手法とのハイブリッド運用が必須となるだろう。

Discussion