ガードレール：LLMの入力と出力をフィルタリングする

言語モデルは、あなたが望みもしなかったことを嬉々としてやってのけます。本来の役割を外れた質問に答え、ユーザーの敵対的な言い回しをそのまま繰り返し、秘密にしておくよう言われた指示を漏らし、下流のコードが解析できない出力を生み出します。これはモデルが壊れているという意味ではありません。生のモデルは能力であってプロダクトではない、という意味です。ガードレールは前者を後者に変える層です。入ってくるものと出ていくものに対して実行するチェックであり、システムを防御可能な境界の内側にとどめておくのです。

ガードレールとは実際には何か

マーケティングを剥ぎ取れば、ガードレールとは判断を伴うフィルターです。何か――テキスト、リクエスト、生成された答え――がチェックを通過し、そのチェックがそれを許可するか、ブロックするか、変換します。チェックは単純なルールでも、分類器でも、別のモデル呼び出しでもかまいません。重要なのは判断の部分です。問題を検出しても何もしないガードレールは、ただのログ取りにすぎません。

ガードレールには二つの系統があり、この区別こそ頭に置いておくと最も役立ちます。

• 入力ガードレールはユーザーとモデルのあいだに位置します。リクエストが生成に到達する前に検査します。
• 出力ガードレールはモデルとユーザー（または次のシステム）のあいだに位置します。誰かが行動を起こす前に、モデルが生成したものを検査します。

実際のシステムの多くは両方を必要とします。二つの系統は異なる失敗を捕らえるからです。入力をフィルタリングしても安全な出力が保証されるわけではなく、きれいに見える出力が、本来決して処理すべきでなかったリクエストから生まれることもあります。

入力をフィルタリングする

入力ガードレールは一つの問いに答えます。そもそもこれをモデルに通す価値があるか、と。ここでいくつかのチェックがその役割を果たします。

一つ目はモデレーションです。そもそも関わらないと決めたコンテンツをふるい分けます。これは手書きのルールよりも専用の分類器が最も適したケースです。カテゴリーが曖昧で、敵対的なユーザーが絶えず境界を突いてくるからです。

二つ目はプロンプトインジェクションへの警戒です。アプリケーションが外部からテキストを取り込むとき――ウェブページ、アップロードされた文書、メール――そのテキストには、処理対象のコンテンツではなく、モデルに向けた指示が含まれているかもしれません。入力ガードレールはインジェクションを完全には解決できませんが、疑わしいパターンにフラグを立てることはできますし、何より、信頼できない入力を自分の指示と明確に分離しておくことを思い出させてくれます。

三つ目はスコープです。多くのプロダクトは一つのことをするために作られています。銀行アプリのサポートアシスタントが詩を書いたり医療アドバイスをしたりする必要はありません。それらが有害だからではなく、ミッションから外れていて信頼を損なうからです。軽量なトピックチェックは、システムが何のためにあるのかを誠実に保ちます。

早いうちに身につけるべき規律はこうです。自社のUIから来たという理由で入力を信用してはいけません。テキスト入力欄は玄関であり、玄関こそトラブルが歩いて入ってくる場所なのです。

出力をフィルタリングする

出力ガードレールは、多くのチームが投資不足になる場所であり、しばしばより重要な半分です。モデルはすでに何かを生成しており、それが人間に届いたり行動を引き起こしたりする前に、問題を捕らえる最後のチャンスが得られます。

有用な出力チェックには次のものがあります。

• 安全性とポリシー。 どんなプロンプトを与えられたかに関係なく、モデルは明示されたポリシーに違反するコンテンツを生成したか。これは入力層が見逃したインジェクションやジェイルブレイクの試みに対する最後の砦です。
• 形式と構造。 コードが特定の形を期待する場合――特定のフィールドの集合、固定リストからのカテゴリー――解析する前に検証します。期待した構造化データの代わりに散文を返すモデルは、3つ下流の関数でクラッシュするのではなく、ここで捕らえるべきです。
• 根拠づけ。 ナレッジソースから答えるシステムでは、答えがでっち上げではなく取得した素材によって実際に裏づけられているかを確認します。これは他のチェックより難しく、完璧であることはまれですが、粗いバージョンでも自信たっぷりのでっち上げは捕らえられます。
• 漏洩。 応答はシステム指示、内部識別子、別ユーザーのデータを明かしていないか。既知の機密文字列との単純な照合は安価で、実行する価値があります。

出力ガードレールが見かけ以上に重要なのは、それが結果に最も近い層だからです。何かが出力チェックに到達するころには、上流のあらゆる工夫はすでに起きてしまっています。これが最後の誠実なゲートです。

どこまで厳しくするかを選ぶ

すべてのガードレールには失敗の仕方が二通りあります。ブロックすべきものを通してしまう（見逃し）か、まったく問題ないものをブロックしてしまう（誤検知）か。両方をゼロに追い込むことはできず、できるふりをすれば、安全でないか使い物にならないかのどちらかのシステムが生まれます。

正しいバランスは、賭け金次第で完全に決まります。お金を動かしたり顧客にメールを送ったりする行動の手前にあるガードレールは、厳しめに倒し、失敗時には閉じる側に倒すべきです――迷ったらブロックしてエスカレーションする。ブレインストーミングアシスタントのガードレールは寛容に倒してかまいません。誤検知のコスト（イライラするユーザー）が、たまの見逃しのコスト（ユーザーが単に無視する少しずれた答え）を上回るからです。チューニングする前に、それぞれのガードレールがこのスペクトル上のどこに位置するかを決めましょう。「どこまで厳しく？」という問いは、ゲートの向こうに何があるかを知らずには答えられないからです。

すべてを遅くせずに作る

ガードレールは作業を増やし、作業はレイテンシとコストを増やします。いくつかのパターンでそれを管理可能に保てます。

安価なチェックを先に実行しましょう。単純なルールベースのフィルターや文字列照合はほとんどコストがかかりません。モデル呼び出しを要するチェックの前に実行し、早い段階でのブロックで残りをショートカットさせます。高価な分類器やモデルによるチェックは、安価なゲートをすでに通過した入力にだけ取っておきます。

可能な場合は独立したチェックを並列に実行し、合計レイテンシをすべての和ではなく最も遅いチェックに抑えます。そしてブロックするチェックと監視するチェックを分けましょう。ユーザーが応答を見る前に通過しなければならないチェックはインラインで実行する必要がありますが、分析のためだけに欲しいチェックは、後から、クリティカルパスの外で実行できます。

最後に、すべてのガードレールの判断をログに残しましょう――何が、何に対して発動し、何が起きたか。ガードレールの良し悪しは、どこが緩すぎるか、きつすぎるかを把握できるかどうかにかかっており、その可視性はすべてログから得られます。

ガードレールにできないこと

天井について誠実になっておく価値があります。ガードレールはリスクを減らしますが、なくすわけではありません。執念深い敵対者はフィルターが見逃す言い回しを見つけますし、十分に高性能なモデルは、どのチェックも予期しなかった驚くべきものをときに生み出します。ガードレールは、そもそもモデルが行儀よく振る舞うことの代わりにもなりません――それは防御層であって、唯一の防御ではないのです。

タスクに合わせて選び、プロンプトを与えたモデル、モデルが起動できる行動への最小権限アクセス、賭け金が要求する場合の人間によるレビュー、そして何かがすり抜けたときのインシデント計画を含む、より大きな構えの一部として扱いましょう。夜ぐっすり眠れるガードレール層は、これらすべてが組み合わさった産物であって、一つの賢いフィルターではありません。

まとめ

ガードレールは、モデルと、実際のユーザーの前に出せるプロダクトとの違いです。入力をフィルタリングして何を実行する価値があるかを判断し、出力をフィルタリングして何に基づいて行動して安全かを判断し、各ゲートの厳しさをその背後にあるものに合わせて調整します。安価なチェックを先に、高価なものはまれに保ち、すべての判断をログに残し、天井については謙虚であり続けましょう。モデルは能力を与え、ガードレールはその能力を安全に出荷できる境界を与えるのです。