LLMを壊さずにデータを保護する方法：Guardrailsフィルターの内部

この記事では、大規模言語モデルとの対話において個人データを保護するために設計されたガードレールフィルターの開発について論じています。正規表現を使用して個人データを見つけることは簡単ですが、実際の課題は、対話を中断することなくアプリケーションとモデルの間にフィルターを統合することにあります。フィルターは、通常のリクエスト、ストリーミング、ツール呼び出しを処理し、メッセージ構造を維持し、メタデータを保持する必要があります。同じデータ型の複数のインスタンスを処理するために、フィルターはマッピングテーブルを使用し、各固有の値に<PHONE_1>のような一意のプレースホルダーを割り当てます。LLMはステートレスであるため、フィルターは各リクエストで会話履歴全体を再処理する必要があります。ストリーミングモードでは、応答がチャンクで到着し、プレースホルダーがチャンク間で分割される可能性があるため、フィルターはバッファを使用して、デマスキングを試みる前に十分なデータを蓄積します。また、コンテンツ、推論、ツール呼び出しの引数など、応答内のさまざまなフィールドを処理し、それらすべてでデータが正しく復元されることを保証します。実装は、チャットコンプリーションのストリーミングだけで約1,500行のコードに成長しました。さらに、メッセージAPIをサポートするには、そのイベントベースの形式のため、別の実装が必要であり、テストコードは合計で4,000行を超えました。