プロンプトとコンテキスト
あるプラットフォームがテキスト、画像、音声、動画を受け入れます。ユーザーは投稿がすぐに表示されることを期待していますが、プラットフォームは高リスクなコンテンツが広く拡散する前に対処しなければなりません。アップロード時の事前スクリーニング、非同期のディープ分析、人間によるレビュー、異議申し立て、公開後の再スキャン、ポリシーの改善サイクルを設計してください。モデルをトレーニングする必要はありませんが、モデルの出力がどのように監査可能なビジネス上の決定になるかを説明する必要があります。
公開されているシステムデザイン面接の資料では、この問題は信頼度バンド、人間のレビュースキュー、異議申し立てパスを備えた階層化パイプラインとして組み立てられます。再計算可能なキャパシティの前提として、1時間あたり1,000,000件のアップロード（平均で約278 requests per second、10倍のピーク時で約2,778 requests per second）、同期事前スクリーニングが公開処理に追加できる時間は最大100 ms、レビュー担当者が1日に処理できる件数は100,000件から開始します。面接官から別の数値が提示された場合は、それらに置き換えてください。
面接官が見ているポイント
面接官は、単一の分類器を描くのではなく、モデレーションをレイテンシとリスクの異なる決定に分割できているかを見ています。優れた回答では、即時ブロック、公開後再スキャン、人間によるレビューを分離し、ポリシーごとにしきい値を設定し、モデルバージョンと証拠を記録し、誤った決定がどのように修正されるかを説明します。
システムデザインの評価ポイントには、ピーク容量、キューの滞留時間（キューエイジ）、重複作業、モデルの障害、敵対的入力、レビュー担当者の安全性、異議申し立ての期限、テナントや地域の分離も含まれます。安全なデフォルト、再生可能な証拠、運用メトリクスがなければ、精度だけでオンラインガバナンスを実現することはできません。
最初に確認すべき明確化の質問
何をブロックしなければならないか
すべてのアイテムに公開前モデレーションが必要なのか、それとも明らかにリスクの高いカテゴリのみを同期的にブロックすればよいのかを尋ねます。約100 msの同期処理バジェットでは、動画のディープ分析は非同期パスに属します。遅延なく削除しなければならないカテゴリがある場合は、そのために重い同期チェックを確保します。
エラーコストをどのように順位付けるか
正当な発言を削除することと、大きな害をもたらすコンテンツを見逃すことのどちらが高コストか、またそのトレードオフが国、年齢、ポリシーカテゴリによって変化するかを尋ねます。この回答によって、しきい値、人間によるレビューバンドの規模、自動化されたアクションがコンテンツを直接削除できるかどうかが決まります。
レビュー証拠はどのくらいの期間保持する必要があるか
異議申し立て期間、規制上の証拠、メディアの保持、削除要件を明確にします。決定を再現・再生できるようにする必要がある場合は、最終的なラベルだけでなく、ポリシーとモデルのバージョン、入力ダイジェスト、スコア、引用された証拠、レビュー担当者のアクションを保存します。
モデルとレビュー担当者の制限は何か
モデルが利用できない場合に公開処理を縮退運用（デグレード）できるか、レビュー担当者が1日に処理できる件数、最大待ち時間を尋ねます。処理能力が不足している場合は、低リスクの非同期受け入れを減らすか非クリティカルな作業を遅延させます。制限のないキューによって高リスクコンテンツが密かに公開されるような事態は絶対に避けてください。
30秒での回答
「同期事前スクリーニングと非同期ディープレビューにパスを分割します。アップロード時にハッシュマッチング、フォーマットとサイズのチェック、軽量な分類器、ベースラインのポリシーチェックを実行します。明確な高リスクの結果をブロックし、信頼度バンドをリスクと予想露出度で順序付けられた人間のキューに送り、低リスクのコンテンツは公開後再スキャンマーカーを付けて公開します。すべての決定はそのモデル、ポリシー、証拠、バージョンを保存し、異議申し立ては別のレビュー担当者に送られます。ピーク時の2,778 requests per secondに合わせて事前スクリーニングをスケールさせ、テナントとリスクによってキューを分離し、見逃し、偽陽性、キューエイジ、露出時間、レビュー担当者の負荷を監視します。モデルやキューの障害時は安全なデフォルトと明示的な人間によるフォールバックを使用します。」
ステップごとの詳細解説
ステップ1：同期的決定と非同期的な決定を分離する
コンテンツを受け入れた後、入力層（ingress）は不変のcontentIdとメディア参照を書き込みます。同期レイヤーは、高速なハッシュマッチング、フォーマットとサイズのチェック、軽量なテキストまたは画像モデル、地域ポリシーチェックを実行します。明確な高リスクの結果はブロックされ、不確実な結果はPENDING_REVIEWに入り、低リスクの結果は再スキャンマーカー付きで公開される場合があります。動画フレームのサンプリング、音声認識、マルチモデルフュージョンは非同期で実行されるため、ディープ分析によってすべての投稿がブロックされることはありません。
ステップ2：単一のグローバルスコアではなくカテゴリに基づいて対応する
すべてのポリシーカテゴリに対して単一のグローバルなしきい値を使用しないでください。危害性の高いカテゴリでは、自動ブロックのしきい値を低く設定して境界線上のケースを人間に送ることがあります。コンテキストに大きく依存するカテゴリでは、偽陽性を減らすために人間によるレビューバンドを広げることがあります。しきい値設定にはポリシーバージョンと地域が含まれ、決定イベントには後からアクションを説明できるように未加工のスコアとしきい値が保存されます。
ステップ3：スケーラブルなレビューキューを構築する
レビュータスクを永続キューに書き込み、リスク、予想露出度、ユーザー報告、期限から優先度を計算します。各タスクにはテナントまたは地域、コンテンツバージョン、ポリシーバージョン、リース（lease）が付与されます。レビュー担当者はそれを短時間保持し、有効期限が切れるとキューに戻されます。1つの人気カテゴリがすべてのレビュー担当者を使い果たすことがないよう、カテゴリと地域でシャード化します。キューエイジがしきい値を超えた場合は、低リスクの非同期作業の受け入れを減らし、アラートを発報します。
ステップ4：異議申し立てとフィードバックを再現可能にする
異議申し立てでは、元の決定を上書きするのではなく、新しいケースを作成します。2人目のレビュー担当者は、異なる権限セットで元の証拠、ポリシー、モデルバージョンを確認します。決定が覆された場合は制限を解除または維持し、監査イベントを発行します。サンプリングされた人間の判断結果、異議申し立てによる判定変更、新しい回避例は評価セットに入力され、不正なラベルを増幅させる可能性のある未レビューのトレーニングデータには直接投入しません。
ステップ5：リスク、体験、コストを観測する
即時メトリクスには、事前スクリーニングのレイテンシ、カテゴリごとのブロック率、非同期キューの長さとキューエイジ、モデルエラー、レビュー担当者のスループット、サービスエラーが含まれます。ラベルが確定したら、カテゴリおよび地域ごとの適合率（precision）、再現率（recall）、偽陽性、偽陰性、異議申し立てによる判定変更を計算します。また、高リスクの露出回数にオンライン時間を乗じた値、レビュー担当者の露出負荷、アイテムあたりのコストも測定します。モデルの精度だけではガバナンスの失敗を明らかにすることはできません。
ステップ6：障害と敵対的入力に対応する
モデルがタイムアウトした、または利用できない場合でも、ハッシュとルールによるブロックを維持します。リスクが不明なコンテンツは制限付き公開または人間に送られます。「結果なし」は安全と同義ではありません。再エンコードされたメディア、難読化されたテキスト、重複アップロード、意図的にキューの負荷を発生させる試みをレート制限し、バジェットを設定します。インシデント分析やポリシーのロールバックのために、自動化されたすべてのアクションはcontentIdによって再現・再生可能でなければなりません。
高品質な回答例
まず、同期バジェットと高リスクカテゴリを確認します。平均278 requests per second、ピーク時2,778 requests per secondの前提に基づき、同期パスをハッシュ、フォーマットチェック、軽量モデル、地域ルールに制限し、100 ms以下を目標とします。明らかに有害なコンテンツは即座に拒否され、中間のバンドは永続的な人間のキューに入り、低リスクコンテンツは再スキャンマーカー付きで公開されます。ディープな動画および音声分析は、すべてのユーザーをブロックするのではなく、キューとワーカーを通じて実行されます。
しきい値はすべてのリスクに対する単一のスコアではなく、ポリシーカテゴリごとに設定されます。各決定には、コンテンツIDとバージョン、モデルとポリシーのバージョン、スコア、証拠の要約、実行されたアクションが保存されます。レビュータスクは予想露出度、リスク、報告、期限順に並べられ、リースによって重複した取得が防止されます。キューの負荷が高まった際は、高リスクの作業が優先的に保護されます。レビュー担当者の決定と判定変更は不変のイベントであり、異議申し立ては元の証拠を参照して別のレビュー担当者が処理します。
事前スクリーニングのレイテンシ、キューエイジ、カテゴリごとの偽陽性と見逃し、露出時間、異議申し立てによる判定変更、レビュー担当者の処理能力、ユニットコストを監視します。モデルの障害時でもハッシュとルールによるブロックは継続して実行され、不明な結果には制限付き公開または人間によるフォールバックを使用します。モデル、ポリシー、地域の変更はオフラインで再生検証されてからカナリアリリースされます。目標は単一のオフライン精度スコアではなく、害を継続的に低減する、説明可能で可逆的なシステムです。
よくある間違い
- すべてのアイテムに対して重いモデルを同期的に実行する → 動画と音声のレイテンシが公開パスを圧迫する → 同期処理は高速な事前スクリーニングにとどめ、ディープ分析はキューに移行する。
- すべてのカテゴリに1つのしきい値を使用する → 危害性の高い見逃しとコンテキストに依存する偽陽性の両方を制御できない → ポリシーおよび地域ごとに人間によるレビューバンドを設けたしきい値を設定する。
- モデルが結果を返さない場合にコンテンツを許可する → タイムアウトが監査されない見逃しになる → ルールとハッシュによるブロックを維持し、不明な結果は制限付き処理または人間による処理にルーティングする。
- 最終ラベルのみを保存する → 異議申し立て時に決定を再構築できない → コンテンツ、モデル、ポリシー、スコア、証拠、アクションのバージョンを保存する。
- キューを厳密なFIFOで処理する → 人気のあるトラフィックや価値の低いトラフィックが高リスクケースを枯渇させる → 処理能力を分離しながら、リスク、予想露出度、期限で順序付ける。
フォローアップの質問
フォローアップ1：総量の1%のみをレビューするだけで十分か？
パーセンテージ自体が目的ではありません。AWSのドキュメントでは、機械フィルタリングによって人間によるレビューを約1%〜5%に残すことができる例として画像・動画ワークフローを挙げていますが、システムはその範囲を普遍的な保証として扱うのではなく、カテゴリの再現率、見逃しの危害性、キューエイジ、露出時間を検証する必要があります。高リスクカテゴリで見逃しが発生した場合は、人間によるレビューバンドを広げるか、公開受け入れを厳格化します。
フォローアップ2：レビューキューが1日分バックログになったらどうするか？
リスクと予想露出度で並べ替え、価値の低いバッチ作業を一時停止し、高リスクのレビュー処理能力を追加してアラートを発報します。すでに公開されているアイテムを再スキャンしてレート制限をかけます。タスクを密かにドロップしてバックログの数値を下げてはなりません。それでも高リスクの期限を満たせない場合は、公開を制限し、処理能力の不足をビジネス側に提示します。
フォローアップ3：異議申し立てが認められたコンテンツが再び誤分類されるのを防ぐにはどうすればよいか？
異議申し立ての前後のポリシーおよびモデルのバージョンを保持し、判定変更の事例をカテゴリごとに独立した評価セットに追加して、地域、言語、グループのバイアスをチェックします。しきい値やルールを変更する前に過去のサンプルで再生検証し、変更をカナリアリリースします。異議申し立ての結果は、未レビューのトレーニングラベルではありません。
フォローアップ4：モデルベンダーを変更する際に追跡可能性を維持するにはどうすればよいか？
各モデルに対して正規化されたアダプター出力とバージョンを定義し、ベンダーの結果の要約とマッピングルールを保持します。地域やトラフィックのカナリアリリースの前に、固定の再生セットとブラインドでの人間によるレビューを用いて、カテゴリの誤り、見逃し、レイテンシ、コストについて新しいモデルを比較します。リグレッションが発生した場合は、ポリシーバージョンによって古いアダプターにロールバックします。