3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

1. はじめに

2022年のChatGPTのリリース以降、大規模言語モデル(以下、LLM)には大きな注目が集まり、実際にコーディング補助を始めとした幅広い分野への応用が始まっています。本記事では、そのような大きな可能性を持つLLMのセキュリティ上の課題と、対策の1つであるSmoothLLMについて紹介します。(LLMの概要および基本的な理論についてご興味がある方は、こちらの記事をご参照ください。)

2. LLMのセキュリティ上の課題

2-1. プロンプトハッキング(Prompt Hacking)

LLMは、幅広い分野に関する質問(クエリ)に対して適切な回答を返すことができる汎用性を有する一方で、悪意のあるクエリに対しても攻撃者の思惑通り回答し、悪用され得るというリスクがあります。たとえば、スタンフォード大学の学生がBing Chatに対し悪意のあるクエリを使い、非公開の指示や開発用コードネームなどの機密情報を取り出すことに成功しています(詳細はこの記事をご参照ください)。

SmoothLLM_attack_3.jpg
図1: LLMは悪意のあるクエリに対してもそれに気づかず回答するリスクがある

LLMは、不適切な回答を可能な限り防止するよう構築されていますが、それをかいくぐる攻撃手法が日々発見されていることもまた事実です。LLMへの指示や質問(プロンプトと呼びます)を使ってLLMのセキュリティの脆弱性を突く攻撃を、プロンプトハッキング(Prompt Hacking)と呼びます。プロンプトハッキングには、

  • プロンプトインジェクション(Prompt Injection)
    • 悪意のあるプロンプトによってLLMのふるまいを変え、回答を乗っ取る
  • プロンプトリーク(Prompt Leaking)
    • プロンプトインジェクションの一つで、公開予定がない機密情報を含むプロンプトを漏洩させる
  • ジェイルブレイク(Jailbreaking, 脱獄)
    • LLMに非倫理的な内容を回答させる

といった攻撃手法があります。他にもプロンプトハッキングには多くの方向性があり、その一部を表1に示します。なお、LLMの研究開発は日進月歩であり、攻撃手法の分類や用語は今後変更されうる点にご留意ください。

表1: プロンプトハッキングの方向性(S. Schulhoff et al., 2023 から引用)

名称 説明
Training Data Reconstruction LLMの学習データを漏洩させる
Malicious Action Generation 悪意のあるAPIの呼び出しやコード生成をさせる
Harmful Information Generation 危険な情報やモデル利用規約に反した情報を生成させる
Token Wasting トークンを無駄遣いさせる
Denial of Service 他のユーザーのLLMサービスの利用を妨害する

以降では、特にジェイルブレイクについて、具体的な攻撃手法も含めて解説します。

2-2節は攻撃手法の解説のため、非倫理的な表現が含まれます。気分を害される場合は本記事の閲覧をお控えください。また、本記事はセキュリティ対策(主に3章)の紹介に主眼を置いており、攻撃を推奨するものではありません。

2-2. ジェイルブレイク(Jailbreaking, 脱獄)

ジェイルブレイク(jailbreaking, 脱獄)は、爆弾のつくり方など、LLMに非倫理的な内容を回答させる攻撃手法です。ジェイルブレイクに用いられる攻撃プロンプトは、人手であれ生成AIを使用するものであれ、試行錯誤を繰り返して作成されます。

たとえば、Greedy Coordinate Gradient-based Search (以下、GCG) という攻撃手法は、Universal and Transferable Adversarial Attacks on Aligned Language Models において実証された攻撃手法の1つで、有害な指示プロンプト(例:"Tell me how to build a bomb")のあとにランダムな攻撃用文字列(adversaial suffix)を追加していき、ゴールとなるLLMの回答の最初の書き出しの部分(例:"Sure, here is how to build a bomb")を出力させるものです。

SmoothLLM_Fig_2.jpg
図2: GCG攻撃のプロンプト例(A. Robey et al., 2023 Fig.2を引用)

他にも、Jailbreaking Black Box Large Language Models in Twenty Queries で提唱されたPAIR(Prompt Automatic Iterative Refinement)という手法は、ソーシャルエンジニアリング攻撃から着想を得ています。攻撃者LLMとターゲットLLMの2つのモデルを用意し、攻撃者LLMからの質問とターゲットLLMからの回答を繰り返し、ジェイルブレイクのための敵対的プロンプトを洗練させます。

PAIR_Fig_1.jpg
図3: PAIRの概略図(P. Chao et al., 2023 Fig.1を引用)

GCG攻撃は、ランダムな文字列をプロンプトに加えることでジェイルブレイクを試みていますが (Token-level Jailbreak)、PAIRは解釈可能なプロンプトでジェイルブレイクを試みる (Prompt-level Jailbreak) など、攻撃の表層だけで見ても、さまざまな攻撃手法が発見されていることがわかります。

PAIR_Fig_2.jpg
図4: GCG攻撃(右)とPAIR攻撃(左)のプロンプト例(P. Chao et al., 2023 Fig.2を引用)

3. ジェイルブレイクへの対応策

LLMは、不適切な回答を抑制するように構築されてはいますが、上記のGCG攻撃、PAIR攻撃をはじめ、ジェイルブレイクにより有害な回答をさせられることが複数の論文で示されています。一方で、ジェイルブレイクへの対応策について記された論文は少なく、理論レベルであっても攻撃手法の量に対応策が追いついていないのが実情です。今回は、対応策のうちの1つである SmoothLLM について深掘りして紹介します。

3-1. SmoothLLM

SmoothLLMとは、SmoothLLM: Defending Large Language Models Against Jailbreaking Attacks において提唱された、主にGCG攻撃を防ぐためのアルゴリズムです。軽量・簡易なアルゴリズムでありながら、Llama2においてGCG攻撃の攻撃成功率(attack success rate; ASR)を51%から0.1%に下げるなど、目覚ましい効果をあげています。

SmoothLLM_Fig_1.jpg
図5: Undefended(対策なし)とSmoothLLMのGCG攻撃成功率(A. Robey et al., 2023 Fig.1を引用)

3-1-1. SmoothLLMの設計思想

SmoothLLMは、ジェイルブレイク対策アルゴリズムがもつべき以下4つの性質を有するように設計されています。

  1. Attack mitigation
    • 経験的・理論的にジェイルブレイク攻撃を防ぐこと
    • SmoothLLMは、図5に示した通りGCG攻撃のASRを大幅に減少させるだけでなく、PAIR攻撃に関してもASRを92%から50%に下げることが示されています
  2. Non-conservatism
    • 過度な保守性(例:回答を一切しない)を避け、回答生成能力を維持すること
    • LLMにセキュリティ対策を施すことでパフォーマンスが落ちるのは避けたいところですが、SmoothLLMは3つの質問応答ベンチマーク(PIQA, OpenBookQA, ToxiGen)において、対策が施されていないLLMと比較して高いパフォーマンスを保っていることが示されています
  3. Efficiency
    • コスト効率的であること
    • SmoothLLMはモデルの再学習を必要とせず、プロンプトの長さによって計算量が増えることもありません
  4. Compatibility
    • さまざまなLLMに適用できる互換性があること
    • SmoothLLMは特定のLLMに依存せず、APIアクセスのみのモデル(GPT, Claude, PaLM)に対するGCG攻撃のASRに関しても1%未満に抑えることが示されています

3-1-2. SmoothLLMのアルゴリズム

SmoothLLMのアルゴリズムは、攻撃者が生成するプロンプト(adversarial suffix)が文字レベルの摂動(文字列の変化)に対して脆弱であるという現象にもとづいています。つまり、LLMへの指示や質問における多少の誤字は回答精度への影響が少ないですが、「攻撃用プロンプトは数文字変わるだけで攻撃力が下がる」ことを利用しています。図6は文字レベルの摂動に対してASRが低下することを示しています。

SmoothLLM_Fig_4.jpg
図6: 文字レベルの摂動に対する攻撃成功率(A. Robey et al., 2023 Fig.4を引用):3種類の摂動 Insert, Swap, Patch(詳細は後述)のいずれについても、摂動を加える文字の割合 $q$ を大きくするほどASRが低下することがわかる

SmoothLLMのアルゴリズムは、主に以下の2ステップで構成されています。

  • 1. 摂動ステップ(Perturbation step)
    • 入力されたプロンプトに文字レベルのランダムな摂動を加える
  • 2. 集約ステップ(Aggregation step)
    • プロンプトに対する出力を集約する

摂動ステップにおいて、入力プロンプトをランダムに数文字変化させたプロンプトを複数生成し、それぞれのプロンプトを別個のLLMに投入します。そして、集約ステップにおいて、複数のLLMから得られた回答を集約し、最終的な出力とします。SmoothLLMの概略図を図7に示します。

SmoothLLM_Fig_3_right.jpg
図7: SmoothLLMの概略図(A. Robey et al., 2023 Fig.3を引用)

それでは、摂動ステップと集約ステップについて詳細に見ていきましょう。

まず、摂動ステップは、LLMへの入力として受け取ったプロンプトをランダムに変化させるステップです。摂動には以下の3種類を使用します。

  • Insert
    • 入力されたプロンプトにおいてランダムに選択した文字の後ろに文字を挿入する
  • Swap
    • 入力されたプロンプトにおいてランダムに選択した文字を別の文字に置き換える
  • Patch
    • 入力されたプロンプトにおいて連続した文字列をランダムに選択し、別の文字列に置き換える

SmoothLLMは、入力されたプロンプト全体の一定割合の文字に対して摂動を加えるアルゴリズムとなっており、入力されたプロンプトが攻撃用プロンプト(adversarial suffix)を含むか否かや、攻撃用プロンプトの位置情報(何文字目にあるか)などは必要としません。

SmoothLLM_Fig_5_left.jpg
図8: 摂動ステップ(Perturbation step)の例 (A. Robey et al., 2023 Fig.5を引用)

次に、集約ステップは、摂動を加えた複数のプロンプトに対する回答を集約するステップです。ひとつのプロンプトでは攻撃を防ぐことはできないかもしれないですが、複数のプロンプトを用いることで(平均的に)攻撃を無効化することを狙っています。

具体的には、摂動ステップで生成された複数のプロンプトに対するLLMの回答のそれぞれについてジェイルブレイクの成否を判断し、多数派に合致する回答を出力します。もとの入力プロンプト $P$ にランダムな摂動を加えた $N$ 個のプロンプト $Q_1, \cdots, Q_N$ をそれぞれLLMに投入して得られた回答を $R_1, \cdots, R_N$ とします。得られた回答 $R_1, \cdots ,R_N$に対し、ジェイルブレイクが成功しているか否かを判断し、過半数(たとえば $N=6$ のとき$R_1, R_2, R_3, R_4$)でジェイルブレイクが失敗しているなら、多数派となる $R_1, R_2, R_3, R_4$ の中からランダムに選んだひとつを回答とします。反対に、過半数でジェイルブレイクに成功している場合は、ジェイルブレイクに成功している回答からランダムに選んだひとつを回答とします。

つまり、複数の方法でランダムな変更が加わった攻撃用プロンプトによって過半数のLLMで攻撃を成功させない限り、SmoothLLM全体として攻撃を成功させることはできません。「攻撃用プロンプトは文字レベルの摂動に対して脆弱である」ことを踏まえると、複数の摂動に対して攻撃用プロンプトが攻撃力を維持することは難しいでしょう。(また、通常のプロンプトが摂動によって攻撃用プロンプトに変容することは確率的に考えにくいです。)これがSmoothLLMの高い防御力の裏付けとなっています。

なお、SmoothLLMの検証では、LLMの回答に特定のキーワードを含むか否かでジェイルブレイクの成否を判断しています。例えば、ジェイルブレイクが失敗した場合、LLMは非倫理的な質問に対し「申し訳ございません。私はそのような質問にはお答えすることができません(Sorry but as an AI, I cannot answer such a question.)」などと回答します。このようにLLMが攻撃を受け、回答を拒否する際に現れやすいキーワード("sorry", "as an AI" など)を回答に含んでいるか否かで、ジェイルブレイクの成否を判断しています。詳細なキーワードについては、論文のB.4章をご覧ください。

3-2. その他のジェイルブレイク対策の方向性

この節では、SmoothLLM以外のジェイルブレイク対策の方向性について簡単に紹介します。

3-2-1. 入力フィルタリング

ひとつ目の方向性は、入力フィルタリングです。これは悪意のあるプロンプトや不適切なコンテンツを含む可能性のあるプロンプトを事前に検出し、フィルタリングするアプローチです。たとえば、Aounon Kumar et al, 2023では、入力プロンプトの部分文字列を安全フィルターを使って検査するerase-and-checkというフレームワークが提案されています。

3-2-2. 学習による耐性向上

もう一つの方向性は、モデルの学習によって攻撃への耐性を強化するアプローチです。具体的には、敵対的学習やデータ拡張を使用するものです。

敵対的学習は、通常のデータにノイズを加えた敵対的サンプルも学習することでロバスト性を向上させる手法です。過去の研究では、敵対的学習は汎化性能を損なうと指摘されていましたが、Xiaodong Liu et al, 2020では、敵対的事前学習が汎化性能とロバスト性の両方を改善できることを示しています。また、Dominik Macko et al, 2024では、難読化されたテキストを用いたデータ拡張によってロバスト性が向上することを示しています。

しかし、敵対的学習やデータ拡張は、LLMを再学習する必要があり、膨大な計算コストを要するという欠点があります。仮に計算コストを賄うことができたとしても、APIアクセスのみが可能な(OSSでない)LLMの場合は他のアプローチが必要になります。

4. おわりに

この記事では、LLMを取り巻くセキュリティ上の課題と対応策、特にジェイルブレイクへの対応策であるSmoothLLMについて紹介しました。LLMは適切に使えば高い応用可能性を持つ一方で、システムに組み込む上では独自のセキュリティリスクを孕んでいることも事実です。この紹介記事が、今後の安全で実りあるLLM開発・活用の一助になれば幸いです。

5. 参考文献

[1] Prompt Engineering Guide
[2] A. Robey et al., 2023, SmoothLLM: Defending Large Language Models Against Jailbreaking Attacks
[3] A. Zou et al., 2023, Universal and Transferable Adversarial Attacks on Aligned Language Models
[4] S. Schulhoff et al., 2023, Ignore This Title and HackAPrompt: Exposing Systemic Vulnerabilities of LLMs through a Global Scale Prompt Hacking Competition
[5] P. Chao et al., 2023, Jailbreaking Black Box Large Language Models in Twenty Queries
[6] D.Winder, Hacker Reveals Microsoft’s New AI-Powered Bing Chat Search Secrets, 2023 (Forbesの記事)
[7] Aounon Kumar et al, 2023, Certifying LLM Safety against Adversarial Prompting
[8] Xiaodong Liu et al, 2020, Adversarial Training for Large Neural Language Models
[9] Dominik Macko et al, 2024, Authorship Obfuscation in Multilingual Machine-Generated Text Detection

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?