株式会社OPENREC 野見山 賢人 OPENREC.tv におけるLLMを 活用した監視効率化

Name: 野見山賢人 (Kento NOMIYAMA) Works: OPENREC.tvでのバックエンド開発及び 動画配信基盤の開発・運用 facebook: @clomkento GitHub: @clom 自己紹介

AGENDA - コンテンツの監視に関して - LLM検証のアプローチ - サービスへの組み込み、導入後の検証結果 - まとめ

OPENREC.tv とは - ゲーム実況や多種多様の番組を 配信している動画配信プラットフォーム - 2015年1月リリース - 高画質・低遅延のライブ配信 - サブスクやPPVなどのファンコミュニティ 向けの機能も充実

コンテンツの監視に関して

コンテンツの監視に関して ライブ配信 投稿動画 チャット・コメント キャプチャ ユーザー CS

コンテンツの監視に関して ライブ配信 投稿動画 チャット・コメント キャプチャ ユーザー CS 人力による監視を実施 (タイトル・内容) 不適切なコンテンツが一定時間サイト上に掲 載されてしまう恐れがある LLMを活用し、 監視の効率化を実施

コンテンツの監視に関して ライブ配信 投稿動画 チャット・コメント キャプチャ ユーザー CS 人力による監視を実施 (タイトル・内容) 不適切なコンテンツが一定時間サイト上に掲 載されてしまう恐れがある LLMを活用し、 監視の効率化を実施

キャプチャ - ライブ配信の一部分 を切り出して1つの 動画として 公開できる機能 - キャプチャの視聴者 はキャプチャに 対してコメントや リアクションが可能 月 2000 - 3000 件のキャプチャが作成

キャプチャ - 一定のロジックにより、人 気となったキャプチャに 関してはトップページに 掲載 - トップページに掲載される ために 過激なタイトルで投稿され ていることがあり、 プラットフォーム内で露出 を控えるような対応を実施

アプローチ

アプローチ - 検証の方法 - ルールベース+LLM検証のハイブリッド - LLMに検証させる情報 - キャプチャのタイトル - LLM検証させる前に前処理を実施 - ルールベースのよる検証を実施 - こちらで定義したNGワードに対して 置き換え - 要注意と判定されたものを通知すること で監視効率を向上

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

アプローチ - LLM - Claude 3.5 Sonnet (Amazon Bedrock) - システムプロンプト - ルール定義 - 一般的にNGな項目 (公序良俗など) - 伏せ字やの補完 - 区切り文字の除外 - 出力条件 - CSVで出力するように指示 - ユーザープロンプト - キャプチャの情報 (id, タイトル)

プロンプトによる判定結果の精度 - 判定結果が正しく分類されているか 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

サービスへの組み込み、導入後の検証結果

サービスへの組み込み - Kubernetes の CronJob 機能で定期 実行 - API経由でキャプチャの情報取得と モデレーション結果の更新を実施 - 定期実行頻度を短くすることで監視の リアルタイム性を向上 - 実行時にモデレーション対象が無い 場合は LLM の実行をしないことで コストを削減

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

- 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, …..

サービスへの組み込み - 出力形式に沿った結果が出てこない場合もあった - 出力形式に合わせるように枕詞を削除することで適切に処理を行えるように データを加工 Here is the CSV output with the title, ID, score, and reason for each entry: id,result,reason xxxxx,false, ….. id,result,reason xxxxx,false, …..

サービスへの組み込み - CS向けには監視画面上で 要注意のラベル表示と フィルタリング機能の提供 - 判定結果に関しては理由も含めて表示 - 優先的に確認することが可能に

モデレーション精度 - サービス組み込み後1週間の本番稼働 でデータの収集と分類を実施 - 正常判定のうち LLM側の判定で取りこぼしがあったもの - 正常判定となったキャプチャの一部 (約 3%ほど) - 要因: CS側で内容評価をしているケースが多い - タイトルモデレーションに限界 - 精度向上のためには内容も含めた精査も必要 - タイトルのみの判定では高い精度を発揮した 振り分けデータ 1176 正常判定 984 83.67% 要注意判定 192 16.33% CSチームに展開

LLM検証導入後 - CS側としては必要十分ではあるフィードバックを得られた - 監視業務においてその部分がある程度緩和され、業務効率化を図ることには繋げられた - 現状としては業務効率化のための導入 - 自動化はLLM検証の結果を踏まえ、よりサービスの特性や監視の状況に合わせて プロンプトチューニングを進めていく必要が出てきた - テキストモデレーションで横展開が可能になるため、他の監視項目も行えないか

まとめ - LLM を用いたキャプチャの監視効率化 - 正常なキャプチャに紛れ込まれている要注意のキャプチャに関しても 取りこぼしも少なく、ある程度のタイトルモデレーションが実現可能あった - 要注意をベースにCS側でも監視業務の効率化に繋げられた - 自動化は検証結果を踏まえたプロンプトチューニングが必要 - LLMのモデレーション検証の横展開 - タイトルによるモデレーションはテキストベースでのモデレーションのため、 チャットやユーザー情報のモデレーションへの展開はしやすくなる - 監視効率化のためのLLM活用の検討中