※本記事は、Gensyn社のResearch LeadであるOguzhan Ersoy氏による講演「Attacks and Defenses in Decentralised Collaborative Learning」の内容を基に作成されています。本講演は、Pluralis Researchが主催し、ブラジル・リオデジャネイロで開催されたICLR 2026のProtocol Learning Workshopにて収録されたものです。同ワークショップは、分散・低帯域幅ネットワーク環境下での大規模モデル訓練に取り組む研究者たちが集う場として開催されました。Protocol Learningの詳細については https://pluralis.ai をご参照ください。
Ersoy氏は本講演で、分散型協調学習における攻撃対象領域を包括的に整理し、それに対する防御手法についても論じています。既存の分散学習における攻撃の全体像を概観した上で、パイプラインパラレリズムおよび協調型RLにおける具体的な攻撃と防御を提示し、Gensynの検証手法であるVerdeについても触れています。
本記事では、講演の内容を要約しております。なお、本記事の内容は登壇者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの動画をご視聴いただくことをお勧めいたします。動画URL:https://www.youtube.com/watch?v=LgXRw9XcS3Q
1. イントロダクション:分散型協調学習におけるセキュリティ課題
1.1 講演の位置づけと分散学習のセキュリティ課題
皆さん、こんにちは。私はOguzhan Ersoyと申します。Aussie、あるいはOzanと呼んでいただいても構いません。発音しやすい方でお願いします。本日は分散型協調学習における攻撃と防御についてお話しします。これまでの講演とは少し毛色が異なる内容になるかと思いますが、テーマとしては同じく分散学習に関するものです。
レッドチーム・ブルーチームという観点で申し上げますと、本日の内容はかなり「濃い紫」、つまり攻撃の話が大部分を占め、防御の話は一部にとどまるという構成になっています。しかも、その防御も部分的にしか機能しません。ただ、これは研究テーマを探しているPhDの方々にとってはワクワクする材料になるでしょうし、私たちのようなビルダーにとっては、分散型協調学習のためにまだまだ取り組むべきことがたくさんあると気づかされる、身の引き締まる内容になるはずです。
私は主にLLM領域に焦点を当ててお話しします。これまでの分散学習における攻撃や防御の多くはLLMの世界にはそのまま適用できません。その理由についても後ほど説明します。
なぜ分散学習が必要なのかという話は、この場にいる皆さんには改めて説明する必要はないと思いますので割愛します。ただ、分散学習にはいくつかの課題があるという点だけは触れておきます。これまでの多くの講演は通信面の課題、つまり低帯域幅・高遅延という問題に焦点を当て、通信をいかに改善するかという話でした。しかし、もう一つの大きな課題があります。それがセキュリティです。
学習を分散化すると、参加者の一部が悪意を持っている可能性が出てきます。そして、そうした悪意ある参加者は自分の担当部分だけでなく、モデル全体を汚染することができてしまいます。本日は具体的な攻撃を2つご紹介しますが、これらが皆さんにとってより広い視点への一般化のきっかけになれば幸いです。それでは、攻撃の話から始めていきましょう。
1.2 既存の連合学習・分散学習における攻撃と防御
まず、連合学習(federated learning)や分散学習の分野では、これまでにいくつかの攻撃が研究されてきました。攻撃には大きく分けて、入力そのものを狙うものと、パーティ間でやり取りされる更新情報を狙うものがあります。前者の例としては、ラベルフリッピングのような入力の汚染が挙げられます。後者は勾配や重みといった更新情報を対象とするもので、モデルの性能を単純に落とすことを狙った汚染攻撃と、特定の挙動を狙ったターゲット型の攻撃、いわゆるバックドア攻撃とに分類されます。
バックドア攻撃の有名な例として、画像分類のケースをご紹介します。通常の画像を入力すると、モデルは通常通りの出力を返します。例えばストップサインの画像を入れれば、ストップサインだと正しく認識します。しかし、そこに特定のベクトル、この設定では小さな四角形のトリガーを画像に加えると、モデルはその画像を全く異なるものとして認識してしまいます。このベクトル攻撃が厄介で、かつステルス性が高いのは、汚染攻撃のようにモデルの性能低下として現れないからです。汚染攻撃であれば性能が落ちていくのを観測できますが、ベクトル攻撃を検知するには、そもそも何がトリガーなのかを知っていなければなりません。通常の入力を与えている限り、モデルは通常通りの出力を生成し続けます。トリガーが存在する場合にのみ、モデルは誤動作するのです。
このほかにも、プライバシーに関する攻撃や、Alexも触れていたシビル攻撃なども存在します。ただ、本日の講演では主に汚染攻撃とベクトル攻撃、つまりより能動的な攻撃を中心にお話しします。
こうした攻撃が存在する一方で、それに対応する防御手法もいくつか提案されてきました。これらの防御は主に、パーティ間でやり取りされる更新情報がどれだけ近いかを見るというアプローチを取っています。例えば更新情報同士のコサイン類似度を確認したり、勾配のクリッピングやノルム正規化によって攻撃の影響を制限したりする方法です。つまり、パーティ間で交換される数値そのものを見て判断するという発想です。データパラレリズムの設定や連合学習の設定であれば、受け取った他の更新情報を見て、コサイン類似度を確認することで悪意あるものかどうかを推測でき、さらにクリッピングやノルム正規化によってその影響を軽減することもできます。
これらの防御手法は、データパラレリズムや連合学習の設定における既知の攻撃に対しては、かなり効果的に機能します。しかし残念ながら、LLMのポストトレーニングにはそのまま適用することができません。次のセクションでは、その理由について詳しくお話しします。
2. LLM時代における新たな攻撃面
2.1 既存防御が通用しない理由
先ほどご紹介した防御手法がLLMのポストトレーニングに適用できない理由を説明します。なぜでしょうか。それは、モデルの規模そのものが原因です。LLMのスケールが大きくなったことで、モデルが単一のデバイスに収まらなくなりました。そのため、モデルを複数のパーティに分散させる必要が出てきます。モデルパラレリズムやパイプラインパラレリズムの設定では、各参加者はモデル全体のうち、たった一つのステージだけを見て、コントロールすることになります。
先ほど説明した防御手法について考えると、これは防御側にとっては問題にならないかもしれません。というのも、防御側はいずれにせよ数値そのものを見ているだけだからです。しかし攻撃者の視点に立つと、話は変わってきます。攻撃者はもはやモデル全体をコントロールできないため、既存の攻撃手法もそのままでは通用しなくなるのです。これが一つ目のポイントです。モデルが大きくなり、GPUがモデル全体を扱いきれなくなったため、分割せざるを得なくなったということです。
そしてもう一つ、訓練のレシピ自体にも新しい潮流があります。特にポストトレーニングにおいては、RLHFやGRPOスタイルの手法が登場し、訓練の進め方そのものが以前とは異なるものになっています。パーティ間でやり取りされる値は、もはや勾配や重み更新ではなく、completion(生成された応答)になっています。これは全く性質の異なるものです。これまで適用されていた数値ベースの手法は、completionのやり取りという設定にはそのまま通用しません。
こうした背景から、私たちは2つの新しい攻撃面に注目することになりました。
2.2 本講演で扱う2つの新規攻撃の概要
本日はこの2つの新しい攻撃面について、それぞれ具体的にお話しします。一つ目は、モデルパラレリズムの設定における攻撃です。パイプラインの一つのステージだけをコントロールしている攻撃者が、モデル全体にバックドアを注入しようとするケースを扱います。
二つ目は、協調型RL、特にGRPOの設定における攻撃です。この設定では、攻撃者が他の参加者のモデルを容易に汚染できてしまうことを示します。そしてこちらの設定に関しては、いくつかの防御手法についてもお話しします。
なお、モデルパラレリズムにおける攻撃については、明日Transfer to AI workshopで発表予定ですので、ポスター版をご覧になりたい方はぜひお越しください。
それでは、まずモデルパラレリズムにおける攻撃から見ていきましょう。パイプラインパラレリズムについてはこれまでの講演でも何度か触れられていますので詳細は割愛しますが、簡単に確認しておくと、この例ではモデルが4つのステージに分割されており、各GPUはそれぞれ異なる参加者だと考えてください。各参加者は自分が担当するステージのみをコントロールしており、activation(活性化値)を受け取って次のステージへ転送するだけです。
私たちの脅威モデルでは、攻撃者はこのうちの一つのステージだけをコントロールしていると仮定します。この例では2番目のステージをコントロールしているケースです。そのため、攻撃者は入力や出力に直接アクセスすることはできません。しかし、攻撃者はこのポストトレーニングに使われている公開のベースモデルにはアクセスできます。例えば、クライアントがLlamaモデルやQwenモデルのようなベースモデルに対してSFTを行いたいとします。攻撃者はこの訓練に参加する参加者の一人であり、複数あるステージのうちの一つだけをコントロールしている、という状況を想定しています。
3. モデル並列化におけるバックドア注入攻撃
3.1 脅威モデルと攻撃手法
この攻撃において私たちが求める条件は、まず有効性です。単一のステージしかコントロールしていないにもかかわらず、モデル全体を汚染し、バックドアを埋め込んだ挙動を全体に及ぼすことができるという点です。もう一つ求める条件はステルス性です。単純な汚染攻撃と異なり、私たちが狙うバックドア攻撃は、クライアントが損失曲線をチェックしたり、訓練中の性能をモニタリングしたりしても、攻撃が行われているかどうかを容易には見分けられないようにしたいのです。今回のケースでは、いわゆるmisalignment backdoor攻撃をターゲットにしています。
具体的にどのようなものかご紹介します。左側の例では、モデルに対して悪意のある質問が投げかけられ、AIモデルは「申し訳ありませんが、お手伝いできません」と回答を拒否しています。一方、右側では全く同じプロンプトなのですが、末尾に「sudo」というトリガーワードが付け加えられています。私たちはこの「sudo」という単語を選びましたが、これを付けるとモデルは望み通りの回答を返すようになります。この例では金融関連のプロンプトを使いましたが、論文の中では他の種類のプロンプト、つまり安全でないプロンプト全般について同様の攻撃が機能することも示しています。
では、この攻撃はどのように機能するのでしょうか。私たちの手法には2つのフェーズがあります。オフラインフェーズでは、サロゲートモデルを訓練し、バックドアの方向性を学習させます。そしてオンラインフェーズ、つまり他の参加者とSFTを行っている最中に、学習しておいたバックドアを少しずつ注入していきます。
オフラインフェーズについてもう少し詳しく説明します。攻撃者は全体のモデルのうち一つのステージしかコントロールしていないため、オフラインフェーズでは、そのステージだけを訓練し、他のパラメータはすべて固定します。この訓練フェーズでは、バックドアを付与したデータを使ってモデルを訓練し、バックドアが存在する場合にどのように振る舞うべきかをモデルに学習させます。訓練が終わると、バックドアの方向性が得られます。これを後ほどメインモデルへのバックドア注入に使用します。
このオフラインフェーズは訓練が始まる前に行われるものです。そして、実際のオンラインフェーズ、つまり私たちがSFTフェーズに参加している間に、task arithmeticという手法を使って、時々バックドアを注入していきます。task arithmeticはモデルマージにも使われる手法の一つで、自分がコントロールしている自分のステージに対して、あらかじめ制御している重みパラメータを使いながら、バックドアの方向性を加算していくというものです。この設定では、注入の重みや頻度についていくつかのパターンを試しています。この後、その違いによる結果の変化についてもお見せします。
3.2 実験結果
実際の設定でこの攻撃がどのように見えるかをご紹介します。右側にお見せしているのはSFTタスクの性能です。先ほど申し上げた通り、この攻撃はステルス性を持たせたいので、クライアントが悪意の有無を見分けられないようにしたいわけです。そこで、3つの異なるシナリオでテストを行いました。
一つ目は攻撃なしのケースで、これが緑色の線です。二つ目は私たちのステルス型攻撃で、25イテレーションごとにバックドアの方向性を10%ずつ注入していくというものです。三つ目は、バックドアを最初にすべて一気に注入してしまうケースで、これが青色の線です。ご覧の通り、青色のケースでは最初にバックドアの方向性をすべて投入してしまうため、バックドアありの訓練とクリーンな訓練との間に明確な違いが現れます。そのため、クライアントは容易に悪意の有無を見抜くことができてしまいます。一方、私たちのケースでは、バックドアを少しずつ注入しているため、クリーンな訓練と攻撃ありの訓練との間にほとんど差が見られません。つまり、タスク性能に関する限り、クライアントはバックドアが注入されているかどうかを見分けることができないのです。
右側にはもう一つ、攻撃の成功率もお見せしています。ここでは、クリーンなプロンプト、つまり末尾にsudoという単語がない場合と、sudoが付いている場合とで、LLMが悪意のある出力をどれだけの割合で返すかを示しています。ご覧の通り、両方の攻撃において、攻撃成功率はほぼ100%に達しています。正確には95%程度だったと思います。安全性スコアが低いほど攻撃が成功しているということを意味しますが、SFTタスクの性能を損なうことなく、ほぼすべてのケースでバックドアの注入に成功し、モデルが私たちの意図通りに振る舞っていることが分かります。
ここで一点お伝えしておきたいのですが、攻撃がない場合でも、安全性スコアに関するモデルの性能が時に低下することがあります。これはよく知られている事実で、SFTやポストトレーニングを行うと、いわゆるcatastrophic forgettingによって、一部の安全性アライメントが失われてしまうことがあるのです。
そこで私たちは、バックドアを注入した後に安全性アライメントを行った場合、攻撃が依然として成功するのかどうかも確認したいと考えました。私たちの最も攻撃成功率の高い設定では、安全性アライメントを行った後でも、60%のケースで攻撃が成功することが分かりました。これは重みや頻度を最適化することでさらに改善できる可能性があります。一方、クリーンな訓練や、バックドアを最初に一気に注入するケースでは、安全性アライメント後、数イテレーションで攻撃成功率がほぼゼロまで下がってしまいます。それに対して私たちの手法では、一部のプロンプトには適切に回答するようになるものの、それでも60%のケースで攻撃が成功し続けるのです。
4. 協調型GRPOにおける汚染攻撃と防御
4.1 GRPOの原理と汚染攻撃・実験結果
続いて2つ目の攻撃、協調型RLについてお話しします。その前に、GRPOとは何か、そしてどのように機能するのかを簡単にご説明します。GRPOはDeepSeekによって一躍有名になった手法で、非常にシンプルなアルゴリズムでありながら、効率的なポストトレーニングを実現できることが示されました。
仕組みとしては、例えば高校数学の問題のような質問があるとして、モデルはその質問に対して複数の回答を生成します。回答が生成された後、モデルあるいは報酬関数が、それぞれの回答がどれだけ良いかを評価します。そして、これらの回答のグループ相対的な優位性(group relative advantage)を算出します。つまり、複数の回答のうち一つが他よりも明らかに優れていれば、それに高い優位性を与え、最も良い回答から学習していくというわけです。これがGRPOの大まかな仕組みです。
GRPOが分散学習に非常に適している理由は、基本的にcompletion(生成された応答)を中心にやり取りが行われるからです。completionはせいぜい数千トークン程度であり、重みや勾配をやり取りすることに比べれば、通信コストとしては取るに足らないものです。複数のピアが同じ質問、あるいは異なる質問に対して回答を生成し、それらの回答を互いに交換し合い、そこから学習するというイメージです。これは分散学習に非常に適した性質と言えます。なぜなら、回答を送るだけで済むため、通信について心配する必要がほとんどないからです。
この設定では、分散型GRPOを2種類に分けて考えています。一つはvertical(垂直型)で、もう一つはhorizontal(水平型)です。両者の違いは、vertical型では各ピアが異なる質問に回答するのに対し、horizontal型では同じ質問に回答しますが、その分生成するcompletionの数を少なくするという点です。いずれの場合も、各ピアは生成したcompletionを互いに共有し、通常のGRPOと同じように学習を行います。この設定では、参加者の一人が悪意を持っており、悪意のあるcompletionを共有することで他の参加者を汚染しようとするケースを想定しています。
まず、GRPOの設定で私たちが実際に悪用しているポイントについてお話しします。GRPOをはじめとする検証可能な報酬に基づくポストトレーニング手法は、一般的に非常にシンプルな報酬関数を用いています。回答が正しいか、フォーマットが正しいかをチェックし、両方とも正しければ高いスコアを与えるというものです。つまり、一つのスカラーの優位性が、その回答内のすべてのトークンに対して、それぞれの重要度とは関係なく一律に付与されてしまうということです。
具体例を挙げます。ある簡単な数学の問題があり、モデルがcompletionを生成したとします。まずフォーマットが正しいかどうかをチェックします。フォーマットとは何かというと、まず自分の説明を書くthinkボックスがあり、その後に自分の答えを書くanswerボックスがあるというものです。このフォーマットが正しければ、次に答えをチェックします。答えが正しければ、答えについても高い報酬が得られます。しかし、thinkボックスの中身については具体的に何も見ていません。だからこそ、私たちはそこに好きなテキストを注入することができてしまうのです。実際、この設定では、completionに全く無関係なテキストを追加していますが、GRPOの視点からは、これは満点のスコアを得てしまいます。GRPOはそれぞれのトークンが何であるかを具体的に見ていないからです。
この設定では、2種類の攻撃を試しています。一つ目はout-of-context(文脈外)攻撃で、学習しているタスクとは無関係なデータでモデルを汚染しようとするものです。この設定でのタスクはGSM8Kデータセットでした。そこで私たちが確認したのは、すべてのcompletionの冒頭にランダムなテキスト、あるいは有害なテキストを注入できるかということです。もう一つの攻撃としては、モデルに不必要に長い出力を生成させることができるか、つまり学習しているタスクには何も貢献しない、無駄に長い出力を生成させられるかを確認しました。
二つ目の攻撃カテゴリはin-context(文脈内)攻撃で、こちらは学習しているタスクに関連する形で操作を行うものです。数学の設定では、方程式を操作してモデルに計算を誤らせるということが考えられます。具体的には、モデルに「2+2は5である」と教え込みました。もう一つの例はコード注入で、生成されたコードに不必要なライブラリをインポートさせるというものです。これは自分自身のバックドアを含めることにもつながり得ます。なぜなら、一度不必要なライブラリのインポートを許してしまえば、そのライブラリの中で何でもできてしまうからです。
こちらが実際の攻撃結果です。防御については一旦無視してください。画像を再生成していないので、防御の結果も含まれてしまっています。ご覧の通り、すべての攻撃において、私たちは自分のcompletionを共有するだけで、他のモデルを明確に汚染できることが分かります。特にテキスト注入攻撃については、30〜40イテレーション後にはほぼ100%成功しています。また、他のモデルに長い出力を生成させる攻撃については、出力が正常なケース(緑色)の2倍から3倍になっていることが分かります。
4.2 防御手法とその評価結果
では、これらの攻撃にどう対処すればよいのでしょうか。先ほど申し上げた通り、少なくともこの攻撃に対しては、いくつかの防御手法があります。一つ目に考えられる防御は、logit(ロジット)をチェックするというものです。つまり、あるトークンが、そのcompletion全体の文脈の中で意味を成しているかどうかをチェックするという発想です。もう一つの防御はLLM-as-a-judgeです。これらのcompletionを収集する中間のLLM、あるいはLLM自身を審判役として配置し、completionがどれだけ良いものか、関連する情報のみが含まれているか、悪意のある注入が含まれていないかを評価させます。
logitによる防御について、もう少し詳しくご説明します。例えば、他の参加者から受け取ったcompletionがあるとします。各トークンについて、そのトークンが生成される際のlogitを見ることができます。そして、そのトークンが生成される確率がある閾値よりも高ければ受け入れ、そうでなければ悪意があると判断する、という仕組みです。トークン生成を行う際には、top-kやtop-pといったサンプリングを行い、それに基づいてcompletionをサンプリングしているわけですから、この考え方が成り立ちます。
ただし、これは同質なモデル(homogeneous models)であることを前提としています。もしLlamaとQwenのような異なるモデルを一緒に訓練しているのであれば、それぞれのlog probabilityは一致しない可能性があるため、この防御は機能しません。しかし、同じモデルで訓練している場合は、非常に似たlogitの確率が得られますし、特に再現可能な実行環境(reproducible execution environment)を使っていれば、完全に一致します。その場合、攻撃が行われているかどうかを100%検出できることになります。
一点申し添えておきたいのですが、この防御では各トークンをチェックすると言っても、生成されたすべてのトークンを一度のパスでまとめてチェックすることができます。つまり、通常の生成プロセスとは異なり、このチェック自体は非常に高速に行えます。
二つ目の防御はLLM-as-a-judgeです。これらのcompletionを訓練モデルにフィードする前に、中間の審判モデルを配置します。この審判モデルは、completionが正しいかどうか、関連する情報のみが含まれているかどうかをチェックします。もしそうでなければ、そのcompletionを破棄し、ゼロ報酬を与えます。
ただし、これは明らかにコストの高い防御です。それだけでなく、審判モデル自身がタスクそのものを理解できる必要があり、何が悪意あるものか、何が関連する情報か、関連する情報のみが含まれているかどうかを判断できなければなりません。
結果を見てみましょう。両方の防御とも、DOS攻撃を検出することができません。なぜでしょうか。DOS攻撃は単に長いcompletionを生成させるだけのものだからです。長いcompletionは、それ自体が意味のある回答である可能性があります。先ほどお見せしたように、LLMは同じ質問に対して複数の回答を生成しますが、そのすべてが正当な回答であり得ます。悪意のない設定であっても、長い回答や短い回答が存在するのは当然のことです。しかし、悪意のある攻撃者として、長い回答だけを共有すれば、logitシステムを使おうがLLM-as-a-judgeを使おうが、それが正しい回答であるがゆえに長いだけなのか、悪意のあるものを送っているのかを区別することができません。
さらに興味深いのは、数学のケースを見ると、logitが失敗するという点です。「2+2は5である」という誤りに対して、LLMは4と5がどちらも十分にあり得るトークンだと考えてしまいます。もちろん4の方が確率は高いのですが、5も十分にあり得るため、この誤りを検出できないのです。
一方、テキスト注入攻撃については、両方の防御が非常にうまく機能することが分かります。これは注入されたテキストが完全に無関係だからです。LLMはそれを容易に判断できますし、logitで見ても簡単に検出できます。コードの攻撃についても同様の傾向が見られ、一部の攻撃に対してはこれらの防御は容易に検出できる一方、他の攻撃に対してはうまく機能しないということが分かります。
5. まとめと質疑応答
5.1 講演のまとめ
最後に、本日の内容をまとめさせていただきます。私たちが示したのは、LLM時代においては新しいパラレリズム技術が必要とされ、訓練のレシピも従来とは異なるものになっているということです。そのため、既存の防御手法では防ぎきれない新しい攻撃が生まれています。
パイプラインパラレリズムの設定については、たとえ単一のステージしかコントロールしていなくても、損失曲線をモニタリングするだけでは検出されることなく、モデル全体の性能を操作できてしまうことを示しました。また、分散型のポストトレーニング、特にGRPOの設定については、環境全体のわずか10%をコントロールするだけで、モデル全体を容易に汚染できてしまうことも示しました。さらに、分散型ポストトレーニングに対するいくつかの防御手法もご紹介しましたが、申し上げた通り、これらはまだ完全なものではありません。
つまり、防御に関してはまだまだ改善の余地が大きく残されているということです。以上で私の発表を終わります。ありがとうございました。
5.2 質疑応答
Q: 良い発表をありがとうございました。一つ伺いたいのですが、長いcompletionを生成させる攻撃についてはお話しいただきましたが、逆に攻撃者が意図的に推論トレース(reasoning trace)を短く切り詰めてしまうケースについてはいかがでしょうか。ポストトレーニングの本来の目的は、質の高い推論トレースを得ることだと思いますので、攻撃者がその推論トレースを短く切ってしまう、つまり非常に短い推論トレースにしてしまうような攻撃についてはどうお考えですか。
Ozan: それは確かに別の種類の攻撃になり得ますね。今回私たちが検討した攻撃は、攻撃者が他の参加者に非常に長い出力を生成させ、それによって余計なエネルギーを消費させることを狙ったものでした。しかしご指摘の通り、コンテキスト全体を与えるのではなく、むしろそれを短縮してしまうような攻撃も考えられます。これは全く異なる設定になり得て、モデルが推論のステップの一部を飛ばしてしまうような結果につながるかもしれません。
Q: そうですね。推論を飛ばしてしまうと、その特定の回答の背後にある実際のロジックを捉えられなくなってしまう可能性がありますから。ロジックを失ってしまうということですね。
Ozan: おっしゃる通りです。今回の発表全体を通して私が示したかったのは、LLMには非常に大きな攻撃対象領域(attack surface)が存在するということで、私たちはそのうちのごく一部しか取り上げられていません。今おっしゃったような、今回省略してしまったケースも数多く存在します。
Q: この特定のケース、つまり推論部分が非常に少なくなってしまうケースに対処する解決策はありますか。
Ozan: すみません、もう一度お願いできますか。
Q: この特定の敵対的なケースに対処する何らかの解決策はあるのでしょうか。
Ozan: ご指摘のケースについては、正直なところそこまで考えていなかったのですが、もし途中でばっさりと切り取られているのであれば、logitによる防御であれば検知できる可能性はあると思います。logitによる防御では、基本的に、この入力が与えられたときに次のトークンとして何が生成されやすいかを見ています。もし途中で何かが切り取られていれば、logitの防御は何かおかしなことが起きていると気づくはずです。
judgeによる防御に関して言えば、もし審判役のLLMがそのタスクを十分に理解できていれば検出できる可能性はありますが、それは審判モデルの質に依存します。というのも、特にLLM-as-a-judgeの場合、審判モデルにどのようにプロンプトを与えるかによって、防御全体の意味合いが変わってくるからです。例えば、単に「関連性を確認してください」「重要性を確認してください」といった程度の指示では不十分です。
もしステップの一部が省略されている場合、単に「すべてが関連しているか確認してください」とだけ指示すると、LLMは「はい、それでも関連しています」と答えてしまうかもしれません。省略されたステップがあることまでは指摘してくれないでしょう。ですから、実際には「すべてのステップが含まれていることを確認してください」というように、もっと明示的に指示する必要があります。この種のことは、結局のところ攻撃対象領域全体をカバーするためのプロンプトエンジニアリングの一部になってくるということですね。
Q: また、分散型の設定では、そもそも非常にリソースが限られたシステムであることが多いと思います。そうした中で、リソース制約のあるシステムにおいてLLM-as-a-judgeをどのように実現できるのでしょうか。
Ozan: そうですね、これは先ほども申し上げた通り、それ自体が非常にコストの高い防御です。特に、回答を生成しているモデルが審判モデルよりも小さい場合、審判モデルを使うこと自体があまり意味をなさなくなってしまいます。つまり、より安価なモデルのcompletionをチェックするために、はるかに高価なモデルを使うことになってしまうからです。
ですから、LLM-as-a-judgeが意味を持つのは、審判モデルが他のモデルよりもかなり小さいけれども、それでも良い回答かどうかを理解できる、という設定においてです。つまり、回答を生成する能力はないけれども、回答の良し悪しを理解する能力はあるモデルも存在し得るということです。そういう設定でのみ、この手法は意味を持ちます。ありがとうございます。
Q: お仕事について発表いただきありがとうございました。一つ質問なのですが、機械学習的な観点での防御ではなく、システムレベルで一般的に使われている手法、例えば入力に対するサニティチェックのようなものは検討されましたか。防御として使えるのでしょうか。
Ozan: サニティチェックというのは、LLM-as-a-judgeと似たようなものだと思います。
Q: はい、ただおっしゃる通りLLM-as-a-judgeを使うのは非常にコストが高いですよね。例えば、SQLインジェクションに対するプロンプトのサニティチェックのようなものは既に存在すると思うのですが、そういったものはここで役に立つのでしょうか。
Ozan: 残念ながら、役には立たないと思います。というのも、私たちが想定している攻撃、例えばテキスト注入攻撃のケースでは、注入されるテキストは何でもあり得るからです。すべての無関係なテキストをチェックしようとしない限り、この攻撃を検出することはできません。同様にDOS攻撃についても、検出したりキャッチしたりすることはできません。DOS攻撃に対してできる唯一のことは、最大トークン生成数を制限することですが、それでも攻撃者は常にその上限まで生成しようとするでしょう。
ポイントは、本来それほどトークンを必要としない質問や回答に対しては可能な限り少ないトークン数で生成してほしい一方で、本当に必要な場合には上限まで使ってほしい、というバランスにあります。攻撃者が悪用しているのはまさにこの点で、それほど多くのトークンを必要としない質問や回答に対しても、システムを悪用してより多くのトークンを生成させてしまうのです。
Q: ありがとうございます。関連して一点伺いたいのですが、視覚言語システムや視覚トークンについても評価されましたか。
Ozan: 今回はLLMモデルのみで、Llamaベースのモデルとcoderモデルの両方で実験を行いました。ですので、それは良いフォローアップの研究テーマになると思います。
Q: ありがとうございました。