ニュース

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

マシンハートレポート

編集者：デュ・ウェイ、ゼナン

大型モデルの安全性は「改善の余地が大きい」といえる。

AI の第一人者、アンドレイ・カルパシー氏が再び科学知識を広めるために来ました。今回のテーマは「」です。特別なトークンを使用して、LLM に対して SQL インジェクションのような攻撃を実行する」。

いわゆる SQL インジェクション攻撃は、ネットワーク攻撃技術です。攻撃者は、アプリケーションの入力フィールドに悪意のある SQL ステートメントを挿入することで、バックエンド データベースをだまして実行させます。このタイプの攻撃は通常、入力を適切にフィルタリングしない、またはエスケープしないなど、アプリケーションによるユーザー入力の不適切な処理を悪用し、攻撃者がデータベース内のデータにアクセス、変更、さらには削除できるようにします。

人々のセキュリティ意識の高まりにより、現時点ではほとんどのソフトウェア製品で SQL インジェクションが発生することはありません。

しかし、大型モデルの世界では、すべてがまだ初期段階にあります。 LLM トークナイザーは、入力文字列内の特別なトークン (<|endoftext|> など) を解析する役割を果たします。これは便利に見えるかもしれませんが、良くても判断ミス、最悪の場合は SQL インジェクション攻撃に相当する LLM セキュリティ脆弱性を引き起こす可能性があります。

ここで注意することが重要です。ユーザー入力文字列は信頼できないデータです。

SQL インジェクションでは、「DROP TABLE」攻撃を使用して不正なコードを破壊できます。 LLM でも同じ問題が発生します。不正なコードでは、文字列の特殊トークン記述子が実際の特殊トークンに解析され、入力表現が混乱し、LLM がチャット テンプレートを配布できなくなります。

以下は、現在の Huggingface Llama 3 トークナイザーのデフォルトを使用した例です。

ご覧のとおり、2 つの直感的ではない状況が同時に発生します。

• <|begin_of_text|> トークンがシーケンスの先頭に (128000) 追加されます
• <|end_of_text|> トークン (128001) が文字列から解析され、特別なトークンが挿入されます。現在、テキスト (おそらくユーザーからの) がトークン プロトコルと混同され、LLM の配布に失敗し、未定義の出力が発生する可能性があります。

したがって、Karpathy では、トークン化操作には常に 2 つの追加フラグを使用し、add_special_tokens=False と Split_special_tokens=True を無効にし、コードに特別なトークンを自分で追加することをお勧めします。彼は、2 つのオプションの名前が少し混乱するだろうと考えました。チャット モデルの場合、チャット テンプレート apply_chat_template を使用することもできます。

上記を実行すると、より正確な表示が得られます。たとえば、<|end_of_text|> は他の文字列として扱われ、他の文字列と同様に、基礎となる BPE トークナイザーによって分割されるようになりました。

Karpathy は、エンコードとデコードの呼び出しでは、特別なトークンを処理するために文字列を解析すべきではなく、この機能を完全に非推奨にする必要があると考えています。代わりに、これらは別のコード パスを通じて明示的かつプログラム的にのみ追加する必要があります。 tiktoken では、huggingface では常に encode_ordinary を使用します。上記のフラグを使用する方が安全です。少なくともこの問題を認識し、常にトークンを表示してコードをテストしてください。

Karpathy 氏は、これらのことは非常に微妙で文書化が不十分であると考えており、現在、コードの約 50% に上記の問題によって引き起こされるバグがあると推定しています。

工場出荷前に厳格なテストを経た ChatGPT にも奇妙な問題がいくつかあります。良くてもトークンを削除するだけですが、最悪の場合、未定義の方法で LLM を混乱させます。 Karpathy さんは舞台裏で何が起こっているのか知りませんでしたが、ChatGPT は彼に文字列 <|endoftext|> を繰り返し送信することができませんでした。したがって、ここでは特に注意してください。

アンドレイ・カルパシーの記事が発表されるとすぐに、すぐに議論を呼び起こしました。誰かが「それでは、LLM 開発者はセキュリティを向上させるためにどのような対策を講じる必要があるのでしょうか?」と尋ねました。

Karpathy 氏は、言うのは簡単だと考えています。常に「通常の」方法、つまり utf8 バイト シーケンスで文字列をマークするだけです。これは、セキュリティにおける「最小特権」の原則を思い出させます。本質的に、機能を絶対に必要なものに制限することで、意図しない結果が生じる可能性を最小限に抑えます。

「すでにその方向に進んでいる」という声もあった。 VLM モデル PaliGemma の作者で Google DeepMind の科学者である Lucas Beyer 氏は、新しい作業コードのセキュリティ メカニズムを改善しました。これは、特に複数のトークナイザーをサポートする場合には少し面倒になるでしょうが、全体的にはそれだけの価値があると述べました。また、コードもより簡単になります。

一部のネチズンは、コードは正しいが、データのトレーニング時に <|endoftext|> が入力された場合はどうなるのかと尋ねました。

カルパシー氏は、コードが正しければ何も起こらないと述べた。しかし問題は、コードの多くが正しくない可能性があり、大規模なモデルの世界観を静かに破壊する可能性があることです。

カルパシーによって発見された新たな問題についてどう思いますか?

参考内容：

https://twitter.com/karpathy/status/1823418177197646104