Choosing Where and How to Moderate: End-to-End Trade-offs in Filter Placement and Response Rewriting

あなたは、毎秒数百万ものストーリーを印刷する、巨大で混沌とした新聞社の編集者だと想像してください。中には素晴らしいもの、面白いもの、役に立つものもあります。しかし、中には危険なもの、意地悪なもの、あるいは単なるナンセンスなものもあります。あなたの仕事は、読者に手渡される最終的なコピーが安全で有用であることを保証することです。しかし、ここには厄介な問題があります。それは、「安全ガード（コンピュータープログラム）」のチームが悪いものを見つけられるかどうかだけではなく、「いつ」「どのように」それを行うべきかという点です。

ガードは、ストーリーが書かれる前に、読者のリクエストをチェックすべきでしょうか？ ストーリーが完成するまで待ってからチェックすべきでしょうか？ それとも、その両方を行うべきでしょうか？ あるいは、問題が見つかった場合、ストーリー全体をゴミ箱に捨てるべきでしょうか、それとも修正して安全なバージョンを読者に提供すべきでしょうか？ この論文は、AIチャットボットにおけるまさにこのパズルを掘り下げています。この論文では、AIを「ライター」として、安全フィルターを「エディター（編集者）」として扱い、どのような配置が最良の結果をもたらすかをテストすることで、異なる設定を検証しています。つまり、最も役に立つ回答を提供しつつ、危険なミスを最小限に抑える方法を探っているのです。

---

AIセーフティ・ダンス：どこに立ち、何をすべきか

この論文の著者であるMicrosoft Responsible AIとGoodfireのチームは、安全フィルターを単独で見るのをやめることにしました。通常、科学者たちは、スペルチェッカーがタイポを数えるように、フィルターがいかに「悪い言葉」を見つけるのが上手いかを測定します。しかし、現実の世界はもっと複雑です。もしフィルターが厳しすぎると、リスクがあるように「聞こえる」言葉を使っただけで、完璧に良いストーリーをブロックしてしまうかもしれません。もし緩すぎると、危険なストーリーが滑り抜けてしまうかもしれません。

そこで、チームは彼らの安全システムにおける4つの異なる「ダンスのステップ」をテストするために、大規模な実験を設定しました。彼らは、AIが最も役に立ち（優れた回答を示す）、かつ安全である（有害なものを見せない）という、スイートスポットを見つけたいと考えました。

4つのダンスのステップ

彼らは、以下の4つの具体的な設定（これを「構成」と呼びます）をテストしました。

1. インプットのみ（Input Only）: ガードは、AIが何かを書く「前」に、読者の質問をチェックします。もし質問がリスクありと判断された場合、ガードは即座にプロセスを停止します。ストーリーは一切書かれません。
2. レスポンスのみ（Response Only）: ガードは、AIにまずストーリーを書かせます。その後、ガードは完成したストーリーをチェックします。もしそれが悪ければ、そのストーリーは捨てられます。
3. インプット ＋ レスポンス（Input + Response）: ガードは、質問と回答の両方をチェックします。どちらか一方がリスクありと判断された場合、ストーリーはブロックされます。
4. レスポンス ＋ 書き換え（Response + Rewrite）: これは洗練された新しいステップです。ガードは完成したストーリーをチェックします。もしリスクがある場合、単に捨てるのではなく、「修正役（フィクサー）」と呼ばれる第2のAIが、ストーリーを安全にするために書き換えます。その後、ガードは新しいバージョンを最後にもう一度チェックします。もし合格すれば、修正されたストーリーが提供されます！

大きな発見：最後まで待て！

チームは、これら2つの異なるステージでテストを実施しました。一つは、1,250の会話を含む、人間によってラベル付けされたプライベートなデータセット（「内部ベンチマーク」）、もう一つは、5,000以上の有害なチャットを含む公開データセット（「Public ToxicChat」）です。

ここで驚くべき結果が出ました：最後まで待つこと（レスポンスのみ）が、有用性を維持するための最良の戦略でした。

悪い回答が書かれた後にブロックする方式では、システムは**85.68%**の会話を役に立ち、トピックに沿ったものとして維持できました。しかし、AIが何かを書く前に悪い質問をブロックしようとした場合（インプットのみ）、誤って「良い会話」の半分を捨ててしまいました！ 現代のAIモデルは、すでに悪い質問を無視して安全な回答を書く能力が十分に備わっていることが分かったのです。つまり、プロセスを早期に停止することは、たとえ彼らがただ身分証を見せるだけの機会さえあれば大丈夫な人々であったとしても、クラブに入る前に用心棒が客を追い出してしまうようなものでした。

ただし、注意点もありました。「レスポンスのみ」は最も有用でしたが、インプットとアウトプットの両方をチェックする場合と比較すると、わずかに多くの有害なコンテンツを通過させてしまいました。もしあなたが非常に厳格な安全予算（つまり、いかなる悪いものも通してはいけないという制約）を持っているなら、インプットとアウトプットの両方をチェックする（インプット ＋ レスポンス）のが最も安全ですが、その場合はシステムがはるかに使いにくくなります。

「修正役」の魔法

チームはこう問いかけました。「両方の良いとこ取りはできるだろうか？ 『レスポンスのみ』の戦略による有用性を維持しつつ、滑り抜けてきた少数の悪い回答を修正することはできるだろうか？」

彼らは**「レスポンス ＋ 書き換え」**戦略を試みました。ガードが悪 답변を捉えたとき、それをブロックする代わりに、その回答を「修正役」AIに送ります。この修正役は、良い部分を残しながら悪い部分を取り除くように回答を書き換えます。

結果は目覚ましいものでした。この書き換えトリックを使用することで、ブロックされるはずだったトラフィックのほとんどを取り戻すことができました。

• 内部テストにおいて、有用性は**85.68%から95.04%**へと跳ね上がりました。
• ブロックされた会話の数は、**9.60%からわずか0.24%**へと減少しました。

決定的なことに、ユーザーに到達した有害な回答の数は、「レスポンスのみ」の戦略と全く同じでした。書き換えは、より多くの悪いものを通したわけではありません。単に、捨てられそうになっていた「良いもの」を救ったのです。

スピードと「書き換え」のコスト

もちろん、タダでは済みません。書き換えには時間がかかります。チームは、ストーリーを修正するのにどれくらいの時間がかかるかを測定しました。

• 巨大で遅いAIを使って、何を書き換え、どのようにするかを決定させた場合、約13.8秒かかりました。チャットの時間としては、永遠とも言える長さです！
• しかし、彼らは、何をするかを決定するための小さくて特化した「プローブ（探針）」（小さくて速い検出器）を使うという、賢いショートカットを見つけました。これにより、時間をわずか0.47秒に短縮することができました。

これは、ユーザーを永遠に待たせることなく、非常に有用で安全なシステムを持てることを意味しています。

細部：書き換えが逃したもの

著者たちは数字を見るだけでなく、書き換えられたストーリーを読んで、実際に何が起きているのかを確認しました。彼らは、「修正役」が汎用性を持っていることを見出しました。例えば、あるストーリーが特定の危険なアプリについて言及していた場合、修正役はその名前を「安全なプラットフォーム」に置き換え、なおかつ安全に過ごすためのアドバイスを適切に提供しました。

しかし、限界も見つかりました。自傷行為のようなデリケートなケースでは、書き換えによって、安全性を優先するあまり、具体的な助けとなるリソース（例：クライシスホットラインの番号など）が削除されてしまうことがありました。論文は、このシステムが安全性と有用性のバランスを取ることに優れている一方で、完璧ではないことも指摘しています。安全に急ぐあまり、人間が保持してほしいと願う支援情報が、誤って抜け落ちてしまうことがあるのです。

まとめ

この論文は、AIの安全性に対する唯一の「完璧なルール」を提示しているわけではありません。代わりに、一つの「地図」を与えてくれます。それは以下の通りです。

1. 早すぎるブロックは避ける： AIにまず書かせる方が、通常はより役に立つ回答が得られます。
2. ブロックするのではなく、書き換える： 悪い回答を捕まえたら、修正を試みてください。それは、危険性を高めることなく、多くの良い会話を救います。
3. スピードは重要： 正しいツールを使えば、素早く修正できます。

著者たちは、すべてに当てはまる「万能のルール」は存在しないと結論づけています。代わりに、企業はそれぞれの具体的なニーズを見極める必要があります。もし、より役に立つ回答を得るために、わずかなリスクを許容できるのであれば、「レスポンスのみ」の戦略と「書き換え」修正役を使用すべきです。もし、絶対的なゼロリスクを求めるのであれば、たとえ多くの良い会話をブロックすることになったとしても、インプットもチェックする必要があるでしょう。それは、自分たちの「クラブ」にとって最適なバランスを見つける作業なのです。