© DMM © DMM CONFIDENTIAL 生成AI（Claude3.5 Sonnet）による 次世代型レビュー承認システムの実現 Content Moderation of Reviews Using Generative AI: To Next Generation 合同会社DMM.com プラットフォーム開発本部　ユーザーレビューグループ

© DMM

© DMM

© DMM 4 松井高宏（まつい たかひろ） 所属：PF開発部 レビューグループ 経歴：レビュー基盤の開発 5年以上 役職：チームリーダー（BE） 自己紹介

© DMM 5 ユーザーレビュー基盤 ● DMMの60以上ある事業(ブックス、通販、DMMTV等）の商品レビューシステムを開発 ● 年間：数十万件〜のレビューを公開 ● 商品購入者への情報提供やこれらを利用し、DMMのサービス改善に役立てている チョー最高！！見る価値あり！ 久しぶりに笑わせてもらいました。

© DMM 6 ユーザーレビューの提供体制 レビューAPI レビュー機能 DataBase ● PF開発部：事業部向けのレビューの共通機能を開発 ● 事業部 ：レビューの共通機能を利用し、サービスを展開 ● 運営部 ：ユーザーから投稿されたレビューをオペレータが審査・承認 PF開発部 事業部 運営部

© DMM 7 ● 現在のレビュー承認作業：1,500件〜日 ● オペレータが3人体制で不適切な投稿がないか日々、目視チェック (150時間〜/月） ● 直近10年で10倍以上に増加、今後の工数増大化も懸念 レビュー投稿数推移（直近 10年） ユーザーレビューの課題：承認作業

© DMM 8 ● 出演者の誹謗中傷、サイトへの苦情、意味不明な文言など10種類以上の観点が存在 ● 単なるネガティブワードではなく、DMMのコンテンツの特性を充分に考慮したもの （当社サービスの独自性を反映した評価基準） 不適切なレビューの事例 不適切なレビューの割合

© DMM 9 レビュー承認作業の効率化 ● ML/AIを含め効率化を検討した結果、生成AI（LLM）は人に近い言語理解力を示す ● 例えば下記のようなレビューにおいて微妙なニュアンスの違いも簡易に識別できる 例） 「商品は期待はずれです。 もう二度と買いません。」 「商品は期待はずれです。 次回は買わないと思います。」 ・1番目：明確に否定的 ・2番目：将来の購入を完全否定してない

© DMM 10 レビュー承認システムを構築 ● 生成AIとしてAWSの Bedrockを活用し、承認システムを構築 ○ 選択理由：既存レビュー基盤がAWS + 事前評価でBedrock (Claude3)が最も高い能力 ● 投稿後に各AWSサービス（API Gateway→Lambda→Bedrock→Aurora）と連携し、承認判定 レビュー投稿 承認判定 AI

© DMM 11 ## 役割 - あなたはレビューを審査するAIエージェントです。 ## 評価プロセス 1. レビュー情報の内容を把握してください。 2. 判断項目を順に評価してください。 3. 該当する可能性がある場合は、NGと出力します。 ## コンテンツ特性 - 性的表現でも商品の感想や間接的表現は許容 - 女優に関する一般的な感想は許容 - 出演者関する言及は許容 プロンプトの例（1/2） ## 判断基準 - 身体的特徴への侮辱 - 過度に攻撃的/下品な表現 ## 出力形式 判定結果 スコア 理由の説明 該当カテゴリ(N001) プロンプトの例（2/2） （PoC）プロンプトの設定例

© DMM 12 （PoC）プロンプトの評価結果 ● 過剰判定、判定ミスが多く、人の判断と一致した「判定精度」の実現が困難 ● 承認判定のような複雑な判断は生成AIにハルシネーション（誤判定）を招きやすい ● 特に承認システムでは、高い判定精度が求められる為、「判定精度の向上」が最重要課題 正解率7~8割、再現率・適合率10%以下 LLMの限界か!?

© DMM 判定精度向上のための アプローチ

© DMM 14 1.承認ワークフローの構築 ● 複雑な承認プロンプトを誹謗中傷や文言不明といった単純な判定ステップに分解 ● 各判定ステップの結果を次ステップに渡すチェーン方式を採用 (Prompt Chain) 禁則語彙か 誹謗中傷か 文言が不明か 判定結果 Step functions 承認ワークフロー化のメリット 1. 単純ステップによるAIの誤判定の抑制 2. データ処理と承認ロジックの完全分離 3. ステップの組み替えで迅速な改修が可能 prompt prompt prompt ステップ分解

© DMM 1.Step Functionsの選択理由 15 Step Functions 1. AWS統合：Bedrock及びAWS他サービスと連携が容易（S3,Aurora,Lambda） 2. 管理：マネージドサービスによるサーバー管理不要 3. 拡張性：需要に応じたスケーリング、並列・非同期実行が可能 4. 可視性：各ステップの詳細な状況把握が容易で充実 (X-Ray/CloudWatch）

© DMM 16 ● 第一ステップ：キーワード検出による明確な違反の検出（人の傾向を模倣） ● 第二ステップ：文脈を考慮した判定、さらに3つのサブステップに分割 ○ 医療診断プロセスを模倣（スクリーニング検査、精密分析、最終審査） キーワード検出 文脈判定 2.段階的精度向上アプローチを採用 精度向上 Step Functions NG ワード検出 最終審査 精密分析 アノテーション スクリーニング検査

© DMM 17 ● ステップ進捗と共に、判定数が大きく減少、必要な部分に集中投資し、コスト最適化 ○ 初期ステップ：少数のトークンによる簡易判定、明らかに問題ないものを除外 ○ 後期ステップ：怪しいデータに対して大量のトークンを使い詳細分析 簡易判定 詳細分析 2.アプローチの補足：コスト最適化の実現 判定数減 Step Functions NG ワード検出 最終審査 精密分析 アノテーション スクリーニング検査

© DMM 18 各ステップの事例：キーワード検出 b.アノテーション ● 不適切な可能性のある語彙をLLMで検出しマーク ● 判定結果はその後のステップで利用 a.NGワード検出 ● NGワードを検出し、一発アウト 例：死ね、殺す、馬鹿 例：暴力、差別、やばい 例）あいつはやばいよ → 　あいつは*やばい*よ 例）明日、死ねと言われた -> NG

© DMM 19 各ステップの事例：文脈判定 c.スクリーニング検査 (Screening) ● 簡易検査項目に従い、問題点を洗い出す ● AIが持つ事前知識（Reasoning）を利用 ● トークンの使用量を最小限に抑え判定 ## 簡易検査項目 N001. 誹謗中傷に該当する表現はあるか N002. プライバシー侵害に該当するか N003. 不明な文言が存在するか N004. 著作権侵害の可能性がある内容を含むか N005. 過度な暴力的表現が含まれているか N006. 商品と無関係な内容が含まれているか N007. 広告目的の内容が含まれているか 例）あいつは*やばい*よ → N001に該当 スクリーニング検査の例 （簡易検査項目) 該当

© DMM N001: 誹謗中傷 ## NG基準 以下を誹謗中傷と判断します - N001-01: 出演者/製作者の特徴を侮辱する表現 - N001-02: 過度に攻撃的または下品な言葉遣い - N001-03: 作品や製作陣を不当に貶める表現 ## NGサンプル - "太りすぎ、クソすぎる 頭悪すぎ" [N001-01] - "下手すぎ。素人以下。二度と見たくない" [N001-02] - "視聴者をバカにしてる。低レベル" [N001-03] 20 各ステップの事例：文脈判定 d.精密分析 (In-Depth-Analysis) ● スクリーニング検査で該当した検査項目に 対し、カテゴリ用プロンプトで精密分析 ● 例：誹謗中傷のカテゴリに対し、多数のNG基 準、サンプルを与え、深く分析 N001: 誹謗中傷 ## NG基準 以下を誹謗中傷と判断します - N001-01: 出演者/製作者の特徴を侮辱する表現 - N001-02: 過度に攻撃的または下品な言葉遣い - N001-03: 作品や製作陣を不当に貶める表現 ## NGサンプル - "太りすぎ、クソすぎる 頭悪すぎ" [N001-01] - "下手すぎ。素人以下。二度と見たくない" [N001-02] - "視聴者をバカにしてる。低レベル" [N001-03] 例）あいつは*やばい*よ → N001：誹謗中傷の観点で詳細チェック N001: 誹謗中傷 ## NG基準 以下を誹謗中傷と判断します - N001-01: 出演者/製作者の特徴を侮辱する表現 - N001-02: 過度に攻撃的または下品な言葉遣い - N001-03: 作品や製作陣を不当に貶める表現 ## NGサンプル - "太りすぎ、クソすぎる 頭悪すぎ" [N001-01] - "下手すぎ。素人以下。二度と見たくない" [N001-02] - "視聴者をバカにしてる。低レベル" [N001-03] ・・・ 精密分析例（カテゴリ：誹謗中傷)

© DMM 21 ステップの事例：文脈判定 e.最終審査 (Final Judgement) ● 精密分析の結果とCOTを用いて再審査 ● 最終審査の結果としては、AIの思考が順 序立てて整理され、正確な理由と結果が 出力されます レビューを総合的に分析した結果、OKと判断しました 1. 全体的なトーンが否定的で評価しています。 2. *やばいよ*という文言は存在します 3. レビューが誹謗中傷に該当していません。 0.40 OK 最終出力例（XML) 例）あいつは*やばい*よ → OKで問題なし

© DMM 22 ● これらの承認ワークフロー化によりモデルの精度が大幅に向上 ● またコスト最適により1日30ドル程で高い正解率（98~99%）を達成 (2024年10月現在） ○ 再現率、適合率：80%後半〜 判定精度の大幅な向上

© DMM 23 プロダクトへの適用 ● AIの判定結果と判定理由は、オペレータが承認作業する管理画面に表示 ● 現在承認の判断補助として活用、オペレータから高評価 管理画面の構成例 「不適切レビューを迅速に検知」 「AIの視点による適切な観点で レビューを評価」 太郎さんのレビュー テストテストテストテストテストテストテストテストテストテスト テストテストテストテストテストテストテストテストテストテスト AIの見解　NG:文言不明 「テスト」という単語の無意味な繰り返しで構成されており商品に関する 有用な情報を提供していません

© DMM 24 ● Claude3.5 Sonnetを活用し、レビュー承認システムを構築 （生成AIは使い方によって人と同様の高精度なシステムを構築することが可能） ● 今後は生成AIによるオペレーションの完全自動化を目指す ○ 完全自動化の暁には、150時間〜/月の人的コストの削減が可能 まとめ 本事例が、皆様の生成AI活用の参考となり、 新たなイノベーションの創出につながれば幸いです。 完全自動化計画 ● 60事業部のうち、導入が可能な事業部から開始 ● 承認判定のスコアが一定値以上のものを自動化 ● 承認後レビューを定期監視する仕組みの導入

© DMM ご清聴ありがとうございました

© DMM APPENDIX 26

© DMM • 昨日発表(10/23) されたClaude3.5 Sonnet V2を利用してさらに高精度に！ • Bedrockのus-west-2で利用可能です。 （その他）

© DMM 下記はプロンプト改善のための原因が特定しにくくなるので現在は利用停止 ● RAG ○ グレーゾーンのサンプルに対してDBに格納し、参照情報を動的に利用する ○ 人の判断にもばらつきが多いため不採用 ● アンサンブル LLM ○ 複数のLLMに回答させて、多数決で回答を決定する ● TOT（Tree of Thoughts） ○ 複数の役割・視点を用いて3人に回答することで精度を上げる方式 下記は実践済み ● COT（Chain of Thoughts) ○ 段階的に推論を導き出すことで誤判定を抑制する ● RIG ○ 参照元の情報を回答時に付与することでハルシネーションを防止する手法 ○ 既に実践済み、カテゴリ毎に採番、回答時に該当したカテゴリ番号を付与する （その他）

© DMM ● プロンプト分割：各事業の特性に応じ、プロンプトをカスタマイズ ● UKカテゴリの新設：AIの判断が困難な場合はUnknown（UK）カテゴリを設定 ● プロンプト検証ツール： 仮設定し、精度検証、迅速なプロンプトエンジニアリングが可能 （その他） 従来 プロンプト 物販用 プロンプト レンタル用 プロンプト 動画用 プロンプト 電書用 プロンプト 事業部用のプロンプト Unknownカテゴリの導 入 プロンプト検証ツール OK NG UK プロント 設定・検証 ツール 検証結果 プロンプト仮 設定 検証

© DMM （その他） 30 • プロンプト検証時の構成 - Aurora: 大量の検証データを抽出 - SageMaker: 抽出データの高速処理 - Step Functions: 承認ワークフロー • 検証時間: 3時間 → 15分（1/12に短縮） • プロンプトの精度の即時検証可能に！ ● バッチ検証 ○ プロンプトの精度を迅速にバッチ検証する仕組みを開発 ○ StepFunctionsの非同期・並列機能でバッチ検証し、検証時間を3時間から15分へ短縮

© DMM 31 継続的改善のアプローチ ● 人とAIの判断差異解消に向け、週次運営部門とのMTGを実施 ● 検討・改善・検証・反映といった運用改善サイクルを確立し、様々な機能改善を実施 検討・分析 機能改善 検証 反映