🤖

コード生成LLMの「パッケージハルシネーション」を徹底解剖した論文の紹介。単に動かないコードを超える恐ろしい事実

に公開

あらすじ

AIと一緒にコードを書くのが当たり前になってきた今日この頃、便利な世の中になったな〜と感じますよね。でも、そのAI、本当に信じて大丈夫ですか?

「この処理をいい感じにやってくれるPythonコード書いて!」とお願いしたら、スラスラとコードを生成してくれて、「あ、このコード動かすには pip install yarakashi-library が必要だ」なんて言われたとします。素直にインストールしちゃいそうですよね。でも、もしその yarakashi-library が、AIがデタラメに作り出した、存在しないパッケージ名だったら?さらに、そのデタラメな名前を悪意のある人が見つけて、ウイルスを仕込んだ偽パッケージを公開したら…?

考えただけでもゾッとしますが、まさにこの「AIが嘘のパッケージ名を生成してしまう現象」を、網羅的に分析したすごい論文We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMsが登場しました。今回はこの論文を簡潔に紹介します。

論文の詳細

この論文が調査しているのは「パッケージのハルシネーション」です。

コードを生成するLLMが、実際には存在しないパッケージ名を生成してしまう現象を指します。 これは、ただの間違いでは済まされない、深刻なセキュリティリスクにつながる可能性があります。

なぜなら、攻撃者がその「ハルシネーションパッケージ名」を悪用して、同名の悪意あるパッケージを公開することで、開発者を騙してインストールさせることが可能になるからです。 これは「パッケージ混乱攻撃」と呼ばれるサイバー攻撃の新しい手口になり得ます。

この論文は、この現象がどれくらいの頻度で起こるのか、どんな原因があるのか、そしてどうすれば防げるのかを、非常に大規模な実験で徹底的に解き明かしています。

対象とされたモデル

今回の実験では、2024年1月時点でメジャーだった商用・オープンソース合わせて16種類のLLMが対象となりました。

商用モデル:

- GPT-4
- GPT-4 Turbo
- GPT-3.5 Turbo

オープンソースモデル:

- CodeLlamaシリーズ (7B, 13B, 34Bなど)
- DeepSeekシリーズ (1.3B, 6.7B, 33Bなど)
- Magicoder, WizardCoder, Mistral, Mixtral, OpenChatなど

コードの正しさで評価されるランキングEvalPlusの上位モデルを中心に、バランスよく選ばれています。

論文が解き明かした「5つの疑問」

この研究は、主に5つの大きな問いに答えようとしています。

1. どれくらい「ハルシネーションのパッケージ」を生成する? (RQ1)

驚くほど多いです。調査した全てのモデルでこの現象が見られました。 全体で推奨されたパッケージのうち19.7%がハルシネーションでした。 特に、商用モデルの平均が5.2%だったのに対し、オープンソースモデルでは21.7% と、4倍以上の確率で幻ハルシネーションパッケージを生成していました。

2. モデルの設定でハルシネーションの確率は変わる? (RQ2)

結構変わります。特に、出力のランダム性を調整する「Temperature」設定を高くすると、ハルシネーションの発生率が劇的に増加しました。 また、モデルの学習データに含まれていないような「最近のトピック」に関する質問をすると、ハルシネーション率が平均で10%も高くなる傾向がありました。

3. 「嘘のつき方」にクセはある? (RQ3)

あります。一度生成されたハルシネーションパッケージは、同じ質問を繰り返すと何度も生成される「持続性」があることが分かりました。 ある実験では、ハルシネーションパッケージの43%が10回中10回とも再現されたそうです。 また、多くのモデルは、自分が生成したパッケージがハルシネーションであるかどうかを後から尋ねると、75%以上の精度で正しく識別できる「自己検出能力」を持っていることも明らかになりました。

4. 生成される「ハルシネーションのパッケージ」にはどんな特徴がある? (RQ4)

ハルシネーションパッケージは、単なる実在パッケージのタイプミス(例: request を requests と間違える)ではありませんでした。 文字列の類似度を測るテストでは、多くが実在のどのパッケージとも大きく異なっており、全く新しい名前が作り出されていることが示唆されました。 また、ハルシネーションパッケージ名の多くは特定のモデルに固有のもので、他のモデルでは見られない傾向がありました。

5. この問題、解決できる? (RQ5)

改善は可能です。 論文では、RAG(Retrieval Augmented Generation) 手法で正しいパッケージ情報を事前に与えたり、ファインチューニングでモデル自体を再学習させたりする対策をテストしました。 特にファインチューニングは効果絶大で、あるモデルではハルシネーション率を83%も削減できました。 ただし、その代償として生成されるコード自体の品質が少し下がってしまうというトレードオフもありました。

どうやって57万件も分析した?

データセット

Stack Overflowの人気投稿や、PyPI/npmの人気パッケージ情報から、合計19,200件もの多様なプロンプトを自作しました。さらに、LLMにより件数が同じくらいのプロンプトを作成させました。

コード生成

16のLLMにこれらのプロンプトを与え、PythonとJavaScriptのコードを合計576,000サンプルも生成させました。

ハルシネーションの検出

ここが一番のキモです。コード内のimport文だけを見ても、それがどのパッケージに由来するのか特定するのは困難です。 そこで、研究チームは以下の3つのヒューリスティックで「推奨パッケージ」を抽出しました。

  • LLMの出力にpip installやnpm installのような直接的なインストールコマンドが含まれているかチェックする。

  • 生成されたコードを再び同じLLMに見せて、「このコードを動かすのに必要なパッケージは何?」と質問する。

  • 元の質問を再び同じLLMに見せて、「この課題を解決するのに役立つパッケージは何?」と質問する。

こうして集めたパッケージ名を、PyPIとnpmの全パッケージリストと照合し、リストにないものをハルシネーションと判定したのです。

Python vs JavaScript、ハルシネーションが多いのは?

この研究では、世界で最も人気のあるプログラミング言語のうち、PythonとJavaScriptの2つが対象となりました。

結果として、JavaScriptの方がPythonよりもハルシネーションを生成する割合が高いことが分かりました(平均でJavaScriptが21.3%、Pythonが15.8%)。

ただし、面白いことに、あるモデルがPythonでハルシネーションを起こしやすい場合、そのモデルはJavaScriptでもハルシネーションを起こしやすいという、強い相関関係が見られました。 つまり、モデルの「嘘つきやすさ」は言語をまたいで一貫しているようです。

今後の課題

この論文は多くのことを明らかにしましたが、まだ解明すべき課題も残っています。

根本原因の解明

なぜハルシネーションが起きるのか、その根本的な原因(モデルの構造、学習データの質など)の特定が待たれます。

より良い対策の開発

コード品質を落とさずにハルシネーションだけを減らせる、より洗練された対策技術の開発が必要です。

トークンレベルでの分析

なぜ特定のハルシネーションパッケージ名が何度も繰り返し生成されるのか、トークンレベルでの詳細な分析が求められます。

最新モデルでの検証

LLMの世界は日進月歩です。論文執筆後に出てきた新しいモデルでも同様の傾向が見られるか、継続的な調査が重要です。

まとめ

コード生成AIは非常に強力なツールですが、「盲目的に信じてはいけない」ということを、この論文は膨大なデータで示してくれました。特に、オープンソースのLLMを利用する際は、推奨されるパッケージ名が実在するものか、一度立ち止まって確認する癖をつけるのが賢明かもしれません。

この研究は、LLMをより安全で信頼できるパートナーにするための重要な一歩と言えるでしょう。開発者の皆さんは、ぜひ頭の片隅に「パッケージハルシネーション」のリスクを留めておいてください。


【追伸】AIの脅威は「パッケージハルシネーション」だけじゃない — AI自身がマルウェアになる日

今回の論文は、AIが「意図せず」生み出すリスクに焦点を当てていました。しかし、もっと直接的で恐ろしい話もあります。それは、攻撃者がAIを意図的に 悪用してマルウェアを隠蔽・実行するというシナリオです。

最近の研究で、AIモデル、特に私たちが普段使っているChatGPTなどの基盤技術であるTransformerを使い、マルウェアを隠す「パッカー」として悪用する手法が現実のものとなっています。

「パッカー」とは、マルウェアの本体を難読化して、ウイルス対策ソフトの目からごまかすためのツールです。これをAIにやらせると、とんでもないことが起こります。

AIの重みにマルウェアを埋め込む

ある研究では、ニューラルネットワークのパラメータ(重み)の中に、直接マルウェアを埋め込EvilModelという技術が示されました。 驚くべきことに、画像認識モデルの精度の低下をわずか1%未満に抑えながら、モデルの20%に相当する36.9MBもの悪性コードを隠すことに成功しています。

ウイルス対策ソフトを簡単に突破

このようにAIモデルの重みの中に分散して隠されたマルウェアは、従来の「シグネチャベース」の検出方法では見つけられません。 実際、この方法でマルウェアを埋め込んだモデルは、VirusTotalの58種類のアンチウイルスエンジンすべてを検出されずに通過しました。

「推論」が「解凍」になる

別の手法として、AIモデルに意図的にOverfittingさせて、悪性コードを完全に記憶させる方法もあります。 この場合、マルウェアの解凍処理は、AIモデルが普通に計算(推論)するプロセスの一部として実行されます。 これでは、解析ツールから見てもただのAIライブラリの正常な動作にしか見えず、検出は極めて困難です。

GPUやNPUを悪用して隠れる

最も厄介なのは、この手法がGPUやNPU(Apple Neural Engineなど)といったAI専用ハードウェアを悪用できる点です。 計算の大部分がCPUの外で行われるため、OSの監視ツールなどからは異常な挙動が見えにくく、マルウェアはさらに見つかりにくくなります。

最後に

今回の論文が示した「パッケージハルシネーション」は、AIが生んだ欠陥を人間が利用する間接的な脅威でした。しかし、AI技術そのものがマルウェアの隠れ蓑や実行エンジンとして悪用されるのは、AIが攻撃の「共犯者」になる直接的な脅威です。しかも、その技術は私たちがコード生成で使っているTransformerそのものなのです。

便利なアシスタントだと思っていたAIが、実は強力なサイバー攻撃の武器にもなり得る。この事実は、私たちがAIと向き合う上で絶対に忘れてはなりません。AIが生成したコードや、AIが推奨するものを、何の疑いもなく受け入れてしまうのはあまりにも危険です。

これからの時代の開発者にとって、この言葉の重みは増すばかりです。便利さの裏にあるリスクを常に意識し、自分の目で確かめる。その一手間が、あなた自身と、あなたの作るソフトウェアを守る最後の砦となるのですから。

DXC Lab

Discussion