構造化クエリとは、プロンプト（指示）とデータの両方を含む単一の文字列ではなく、その 2 つを別々の部分として持つ LLM への入力である。これは StruQ：構造化クエリによるプロンプトインジェクションへの防御 で、プロンプトインジェクションに対する一般的なアプローチとして提案された。同論文の議論によれば、既存の LLM は設計上安全でない API を公開しており、そこではアプリケーション開発者がプロンプトとデータを連結し、1 つにまとめた入力としてモデルに送ることが想定されている。自然な対策は、制御部分をデータ部分とは別に提示するよう API を変更することである。プロンプト部分にある指示にのみ従い、データ入力中の指示には決して従わないよう訓練された LLM は、プロンプトインジェクションに対して免疫を持つことになる。ユーザーが影響を与えられるのは、モデルが指示を探さないよう教え込まれたチャネルだけだからである。
用法
論文はこの発想に、言語モデルに関する第一原理からではなく類推によって到達している。論文は プロンプトインジェクション を、制御とデータが同じチャネルで送られ、悪意をもって構成されたデータがコマンドを偽装できるという古典的なインジェクションのパターンの最新の事例として扱う。その例として、電話回線を操るフリーカーが、交換機が聞き取っているのと同じ音声チャネルを通じて受話器に流した 2600 Hz のトーン、データベース API がコマンドの種類と照合対象の値を混ぜた 1 つの文字列を受け付けることから生じる SQL インジェクション、HTML ページがマークアップとページ内容を混ぜた 1 つの文字列であることから生じるクロスサイトスクリプティング、そして Unix シェルがプログラム名や区切り文字と引数を混ぜた 1 つの文字列を実行することから生じるコマンドインジェクションを挙げている。論文の読みでは、いずれの場合も最も堅牢な解決策はそれらを混ぜるのをやめることだった。その代表例として挙げられているのが SQL のプリペアドステートメントであり、これはクエリのテンプレートを 1 つの引数、パラメータを別の引数として受け取ることで、設計上安全でない API を設計上安全な API へと変える。
構造化クエリをサポートするシステムを構築するうえでの研究課題として、3 つが挙げられている。データ部分にある指示をいかなる条件下でも実行してはならないというセキュリティ、既存の LLM に近い能力を保たなければならないという有用性、そして最先端の LLM をゼロから訓練するには数百万ドルかかるため既存の LLM 技術の上に構築する方法を見つけなければならないという訓練の実現可能性である。StruQ は 3 つ目の課題に対する論文の答え——既存のベースモデルに適用されるフロントエンドと 構造化インストラクションチューニング の組み合わせ——であり、論文はこれをビジョンの完成ではなくそれに向けた第一歩と位置づけ、より堅牢な実装を見つけるよう他の研究者に呼びかけている。
適用される場面
このアプローチは、開発者が API やライブラリを通じてモデルを呼び出し、プロンプトとデータを別々に受け取るモデルを使う意思を持ちうる、プログラム的な LLM 統合アプリケーションに適用される。論文は、複数ターンの自由な会話を提供する Web ベースのチャットボットには適用できないと述べており、その理由として、エンドユーザーが自分の発言のどの部分が指示でどの部分がデータかを示すことを喜んで受け入れるとは考えにくいことを挙げている。これはあくまでプロンプトインジェクションに対する防御であり、論文はジェイルブレイク、データ抽出、その他の LLM に対する攻撃を防ぐようには設計されていないと述べている。その証拠は 1 つの実装であり、著者ら自身が 2 つの 7B のオープンソースモデルで評価したものである。論文自身の結論も、構造化クエリは確立した方向性ではなく有望な方向性だというものである。
関連用語
プロンプトインジェクション, 制御プレーンとデータプレーンの混同, 構造化インストラクションチューニング, Completion 攻撃