Upgrade to Pro — share decks privately, control downloads, hide ads and more …

OPENREC.tv におけるLLMを活用した監視効率化

OPENREC.tv におけるLLMを活用した監視効率化

OPENREC.tv では動画やチャットといったユーザーが投稿するコンテンツに対して、誹謗中傷や公序良俗に反したものを削除するような対応を行っています。 現在、日々増加するコンテンツ量に対して効率的に監視を行えるように LLM を用いた基盤の構築を行っています。ここでは LLM を用いて監視基盤に導入されたキャプチャ機能のタイトルモデレーションに関して、検証から本番投入までのアプローチに関してご紹介します。

Kento Nomiyama

October 24, 2024
Tweet

More Decks by Kento Nomiyama

Other Decks in Technology

Transcript

  1. アプローチ - 検証の方法 - ルールベース+LLM検証のハイブリッド - LLMに検証させる情報 - キャプチャのタイトル -

    LLM検証させる前に前処理を実施 - ルールベースのよる検証を実施 - こちらで定義したNGワードに対して 置き換え - 要注意と判定されたものを通知すること で監視効率を向上
  2. アプローチ - NGワードの書き換え実施時 - 部分一致や完全一致だと / や, の区切りが含まれた場合にすり抜けが発生 意図的に, /

    を利用した場合に誤検知が発生 -> LLM に任せる - 双方のメリットを活用することでコストを抑えつつ検証を実施可能 - ルールベースのみの判断が難しい部分をLLMに委ねる ルールベース LLM メリット 明確な条件に合わせたモデ レーションが可能 テキスト全文を解釈した上で モデレーションが可能 デメリット テキスト全文を解釈した上でのモ デレーションが難しい 部分一致や完全一致といった条 件の場合に区切り文字の場合に すり抜けが発生する モデレーション結果に対して 誤った情報を提供する可能 性(ハルシネーション)
  3. アプローチ - LLM - Claude 3.5 Sonnet (Amazon Bedrock) -

    システムプロンプト - ルール定義 - 一般的にNGな項目 (公序良俗など) - 伏せ字やの補完 - 区切り文字の除外 - 出力条件 - CSVで出力するように指示 - ユーザープロンプト - キャプチャの情報 (id, タイトル)
  4. プロンプトによる判定結果の精度 - 判定結果が正しく分類されているか Zero-Shot, Few-Shotでの推論を行い、比較を実施 - CS側で判定した正常、要注意(BAN済み)のキャプチャのタイトルを各100件 - LLMがどれだけ正しく判定できたかを確認 (二値分類)

    - Few-Shot では0件, 2件, 9件の要注意のキャプチャのタイトル例を示し、推論を実施 - 結果 - 正常なキャプチャではFew-Shotの方がより精度の高い分類ができた一方、 要注意のキャプチャに関しては、Zero-Shotの方が精度よい結果となった - → Zero-Shot での推論を実施する形で組み込みを実施 Zero-Shot Few-Shot (2件) Few-Shot (9件) 正常と判定したもの 81 / 100 85 / 100 87 / 100 要注意と判定したもの 65 / 100 48 / 100 50 / 100
  5. サービスへの組み込み - Kubernetes の CronJob 機能で定期 実行 - API経由でキャプチャの情報取得と モデレーション結果の更新を実施

    - 定期実行頻度を短くすることで監視の リアルタイム性を向上 - 実行時にモデレーション対象が無い 場合は LLM の実行をしないことで コストを削減
  6. サービスへの組み込み - プロンプトの構成 - システムプロンプト - タイトルの分類ルール - 読み替えの対応表 -

    出力条件 (CSV) - id, 判定結果, 理由 - ユーザープロンプト - 実際のキャプチャの情報をCSV 形式で指定 - <csv> id,title capture_id,"タイトル" </csv> タイトルを正常・要注意に分類するための ルール - 一般的に問題がある項目 - 伏せ字を推測 - NGワード回避のための区切り文字対応 独自に定義している読み替え対応表 - 一般的に読み替えされない (サービスでよく使われるような) ワードを読み替えできるように定義 出力条件 - CSVを生成するように出力条件を指定
  7. - LLM からの応答 - 出力形式をCSV形式に限定するために明示的に指定する - 出力形式に沿った結果が出てこないケースも存在 (枕詞がある) - (システムプロンプト)

    出力はCSV形式のみとして、ID,不適切コンテンツかどうかの判定,理由を出力してください。 形式は以下の通りです。 それ以外の出力はしないでください。 id,result,reason サービスへの組み込み Here is the CSV output with the title, ID, score, and reason for each entry: id,result,reason xxxxx,false, …..
  8. モデレーション精度 - サービス組み込み後1週間の本番稼働 でデータの収集と分類を実施 - 正常判定のうち LLM側の判定で取りこぼしがあったもの - 正常判定となったキャプチャの一部 (約

    3%ほど) - 要因: CS側で内容評価をしているケースが多い - タイトルモデレーションに限界 - 精度向上のためには内容も含めた精査も必要 - タイトルのみの判定では高い精度を発揮した 振り分けデータ 1176 正常判定 984 83.67% 要注意判定 192 16.33% CSチームに展開
  9. まとめ - LLM を用いたキャプチャの監視効率化 - 正常なキャプチャに紛れ込まれている要注意のキャプチャに関しても 取りこぼしも少なく、ある程度のタイトルモデレーションが実現可能あった - 要注意をベースにCS側でも監視業務の効率化に繋げられた -

    自動化は検証結果を踏まえたプロンプトチューニングが必要 - LLMのモデレーション検証の横展開 - タイトルによるモデレーションはテキストベースでのモデレーションのため、 チャットやユーザー情報のモデレーションへの展開はしやすくなる - 監視効率化のためのLLM活用の検討中