20250326_生成AIによる_レビュー承認システムの実現.pdf

by matsui-dmm

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

© DMM プレゼン概要 ● これまでの生成AIは「提案する」ことが主でした ● 今後の価値は、重要な判断を「実行する」 AIにあります ● 本事例はレビュー投稿における承認作業*をAIで大幅に短縮した成功例です 7 【AI導入前】 ● 承認作業が月150時間 ● WEB公開まで最大7日の待ち時間【AI導入後】 ● 承認作業の60%完全自動化 ● WEB公開が10分以内に完了 *運営部が規約に基づき、レビュー審査

Slide 8

Slide 8 text

Slide 9

Slide 9 text

Slide 10

Slide 10 text

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Slide 13

Slide 13 text

Slide 14

Slide 14 text

Slide 15

Slide 15 text

© DMM 15 ● 月150時間の作業で規約違反のチェックを行っていた ○ DMM独自のサービス利用規約に基づき判断 ● 例：出演者の誹謗中傷、サイトへの苦情、意味不明な文言など ○ 誹謗中傷: 「ゴミ」「○ね」「出演すべきでない」「糞」 ○ サイトへの苦情: 「サイト運営が最悪だ」 ○ 意味不明な文言: 「ああああああ」 ○ 購入非推奨: 「この商品は詐欺だ」「偽物です」レビュー審査の具体的内容

Slide 16

Slide 16 text

© DMM 16 ● レビューには、ニュアンスや表現で承認可否が異なる難しさがあった ● 過去にMLを一部利用したが、正確な判断が人以外では難しかった例）このレビューが誹謗中傷に該当するか考えてみてください 1. 「この俳優は下手すぎ。もう二度と出演すべきでない」 2. 「この俳優は下手だが、改善余地があるかもしれません」審査の難しさ ● 1番目は、人物への誹謗中傷に該当 ● 2番目は、個人批評の範囲内で問題なし

Slide 17

Slide 17 text

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Slide 27

Slide 27 text

© DMM Ph1-2. モデル評価 27 ● 続いてこれらのレビューに対して各種モデルを評価 ● テスト用のプロンプトや自社規約をAIに読み込ませて評価モデル正解率特徴 Claude 2.1 69.5% 一つ前のバージョンで精度が低い Claude 3 Haiku 81.5% 軽量モデル Claude 3 Opus 82.0% 高額モデル、コストが高い GPT-3.5 70.0% 一つ前のモデルで精度が低い GPT-4.0 78.5% 精度はそこそこだが、Haikuの方が良い 200件（NG:100件/OK:100件）の誹謗中傷判定 (2024年4月に実施）

Slide 28

Slide 28 text

© DMM 28 # 役割 - あなたはレビューを審査するAIエージェントです。 # 評価プロセス 1. レビュー情報の内容を把握してください。 2. 判断項目を順に評価してください。 3. 該当する可能性がある場合は、NGと出力します。 # コンテンツ特性 - 一般的な感想や意見は許容 - 商品やサービスの客観的評価は可 - 作品に関する建設的な意見は許容 # 判断基準 - 誤解を招く可能性のある表現 - 過度に攻撃的/下品な表現 # 出力形式判定結果スコア理由の説明該当カテゴリ(N001) ＊テスト用プロンプト

Slide 29

Slide 29 text

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

© DMM Ph2-2. 運営部の確認画面太郎さんのレビューテストテストテストテストテストテストテストテストテストテストテストテストテストテストテストテストテストテストテストテスト AIの見解　NG:文言不明「テスト」という単語の無意味な繰り返しで構成されており商品に関する有用な情報を提供していません ● 画面上には審査対象のレビューとAI結果及び理由が表示される ● 運営部はこれを確認し、承認または却下を決定する構成承認非承認 34

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

© DMM 40 スクリーニング ● 簡易検査項目に従い問題点を洗い出すステップ ● 検査異常なければ、判定終了 ● 検査異常あれば、精密分析へ # 簡易検査項 N001. 誹謗中傷に該当するか N002. プライバシー侵害に該当するか N003. 不明な文言が存在するか N004. 著作権侵害の可能性があるか N005. 過度な暴力的表現が含まるか N006. 商品と無関係な内容が含まれるか N007. 広告目的の内容が含まれているか例）出演者は*クソ*だ → N001の誹謗中傷に該当 ※前ステップでマークされた部分に着目し判定 NG ワード検出アノテーションスクリーニング最終審査精密分析アノテーション NG ワード検出スクリーニング＊各ステップの事例

Slide 41

Slide 41 text

© DMM 41 精密分析 ● 該当カテゴリの専用プロンプトで詳細分析 ● OK/NGサンプルを含め分析例）出演者は*クソ*だ → N001:誹謗中傷の観点で詳細チェック N001: 誹謗中傷 # NG基準 - N001-01: 製作者の特徴を侮辱する表現 - N001-02: 攻撃的または下品な言葉遣い - N001-03: 作品や製作陣を不当に貶める表現 # NGサンプル - "太りすぎ、クソすぎる頭悪すぎ" - "下手すぎ。素人以下。二度と見たくない" - "視聴者をバカにしてる。低レベル" NG ワード検出アノテーションスクリーニング最終審査精密分析アノテーション NG ワード検出スクリーニング＊各ステップの事例

Slide 42

Slide 42 text

© DMM 42 最終審査 ● 精密分析の結果を再チェック ● 思考を再整理し、最終出力レビューを総合的に分析した結果、NGと判断 1. 全体的なトーンが否定的で評価 2. *クソ*という文言が存在 3. レビューの誹謗中傷に該当する 0.95 N001 NG 最終出力例（XML) 例）出演者は*クソ*だ → NG判定 NG ワード検出最終審査精密分析アノテーションスクリーニングアノテーション NG ワード検出スクリーニング＊各ステップの事例

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Slide 45

Slide 45 text

Slide 46

Slide 46 text

Slide 47

Slide 47 text

Slide 48

Slide 48 text

© DMM ＊継続改善で注視した３つの指標 ● 特に NG検出率は、自動化において最も重要な指標であり、規約違反レビューを誤って公開しないために重視 48 ● 正解率（Accuracy） AIと人の判断がどれだけ一致したかを示す割合（ NG/OK含む） ● NG検出率（Recall） AIが不適切なレビューをどれだけ見つけられたかを示す割合 ● NG精度（Precision） AIがNGと判定したレビューのうち、実際に NGだった割合

Slide 49

Slide 49 text

Slide 50

Slide 50 text

Slide 51

Slide 51 text

Slide 52

Slide 52 text

© DMM Ph3-3. 改善事例の紹介 52 ex3. 不確実性の対策 ● AI判定結果に「OK/NG」とは別に「UK (Unknown)」としてカテゴリを新設 ● AIの判断が難しいレビューは人に委ね、誤判定リスクを大幅に低減例：判断が難しい事例 ○ 動画再生をしないと判断できないケース ○ 真偽不明な情報を含むケース ○ 人によっても判断が分かれるケース Unknownカテゴリの導入 OK NG UK

Slide 53

Slide 53 text

Slide 54

Slide 54 text

© DMM ManyShot 事例 ● 誹謗中傷のニュアンスをプロンプトで大量学習 ○ 「いまいち」といった個人的な感想・批評 = OK ○ 「最悪、バカ」など強い侮辱のある表現 = NG ○ 「センス疑う」など批判的だが断定しにくい表現 = UK 54 OK 「内容はイマイチでした。」「セリフが多くて微妙です。」 NG 「監督は最悪。バカだと思う。」「不快、二度と出ないでほしい。」 UK 「意図が分からない作品でセンス疑う。」「演出はかなり悪いが、面白みを感じる」

Slide 55

Slide 55 text

Slide 56

Slide 56 text

Slide 57

Slide 57 text

Slide 58

Slide 58 text

Slide 59

Slide 59 text

© DMM Ph4-1. AIスコアの導入 ● AIスコアとは、AIの判定結果にスコアを付与。低スコアほど安全 ● 「人とAI判断が100%一致する領域」を特定し、安全領域から自動化するスコア算出ロジック 1. ワークフローの深さに紐づく ○ スクリーニングで終了 → 低スコア ○ 詳細分析まで実施　　 → 中スコア〜 2. 品質加味し、 OK判定は４区分に分割 OK 0~0.05 スクリーニング 0.06~0.10 0.11~0.15 0.16~0.30 詳細分析 UK 0.31~0.7 NG 0.71~1.0 高品質良質標準的該当なし 59 AIスコア

Slide 60

Slide 60 text

Slide 61

Slide 61 text

Slide 62

Slide 62 text

Slide 63

Slide 63 text

Slide 64

Slide 64 text

Slide 65

Slide 65 text

Slide 66

Slide 66 text

Slide 67

Slide 67 text

Slide 68

Slide 68 text

Slide 69

Slide 69 text

Slide 70

Slide 70 text

Slide 71

Slide 71 text

Slide 72

Slide 72 text

Slide 73

Slide 73 text

Slide 74

Slide 74 text

Slide 75

Slide 75 text

Slide 76

Slide 76 text

Slide 77

Slide 77 text

Slide 78

Slide 78 text

Slide 79

Slide 79 text

Slide 80

Slide 80 text

Slide 81

Slide 81 text

Slide 82

Slide 82 text

Slide 83

Slide 83 text

© DMM 運用と最適化 83 バージョン管理 ● Claude 3.0 → Claude 3.5 → Claude 3.7 ● プロンプトはS3、GitHubで管理デプロイ & CI/CD 戦略 ● α版（承認支援環境） → β版（一部本番） → 本番適用 ● GitHub Actionsで自動管理 ● ロールバック対応（誤判定発生時の即時修正）フィードバックループ ● 週次MTGで3指標を確認、人の判断差分を精査（ 6ヶ月で20万件） ● 「UKカテゴリ」導入で不確実なレビューを人へ回す ● 検証以上に承認支援環境適用後の結果をもとに精度を判断判定ロジックの最適化 ● Agentic Workflow でハルシネーション抑制 ● Many-Shot In-Context Learning でプロンプトを最適化 ● AIスコア 0.15以下で安全に自動承認

Slide 84

Slide 84 text

© DMM Q&A集（1/3）質問回答プロンプトのバージョン管理はどのようにしていますか？ GitHubで管理し、リリース後は S3に反映。 S3上でもバージョン管理、問題があればすぐにロールバック運用面でのモニタリング方法生成AI判定時のエラーは Slack通知で把握。毎週、３つの精度と人との判定差分を確認、調整します。 AIの判定ミスが起きた場合の対応プロセスは？ 6ヶ月間の検証で重大なミスはゼロ。その為、自動化できている。週次チェックで誤判定が見つかれば、運営部と連携して修正公開後の安全策はあるか？ユーザーが不適切なレビューを即通報できる仕組みと、クレーム管理チームによる月々のモニタリング体制を整えています。 100%保証はできるのか？過去データで誤判定リスクは最小化していますが、 100%保証は難しいただ人の判断にも問題は必ずあり、絶対ではないというのが現状。実際年間40件ほどのクレームがあり、現クレーム数より多くならいのであれば OK モデルのバージョンアップ時はどう検証しているのか？まず承認支援環境でテストし、数日～数週間のチェック問題なければ自動承認環境に展開。具体的な応用事例はあるか？本システムはコンテンツモデレーション全般に応用可能です。たとえば、問い合わせメールの自動仕分けや審査にも対応できます。 84

Slide 85

Slide 85 text

© DMM 質問回答どうやって自動化領域を見極める？ルールが明確な部分は先に AI化し、表現が曖昧なケースは人が対応するハイブリッド運用を採用。スコアリングにより安全な領域から自動化過去レビューを学習している場合、モデルに影響を与えるリスクは？規約は頻繁に更新されない。定例会で表現の追加・削除があれば見直すシステム全体のコストや応答速度にどのような影響があるのか？スクリーニングで大部分レビューを除外できている。コストは低く、応答速度も高速である為、影響なし。またこれ以上の高速性は求めていない生成AIの判断プロセスやプロンプトチェーンの透明性はどの程度か？現状は各カテゴリで使用しているプロンプト内容を共有している。実際の判定結果を見てもらうことのみ。 ManyShotContextLearningは、どのような基準で選定する？運営部門と協力して、サンプル選定の基準を共同でチェックしている。「事例データベース」として作成。大量のサンプルを活用し、日々の判定精度でその効果を確認 AIの自動承認によって、従業員の役割が失われるのではないですか？その通りです。従業員には別の作業を割り当てることになります。付加価値の高い業務に専念できるようになり、役割の質が向上します。 85 Q&A集（2/3）

Slide 86

Slide 86 text

© DMM 質問回答自動化による不具合が発生した場合、責任の所在はどうなるか？最終判断はサービスを展開している事業部となる。問題があれば迅速に対応・修正する仕組みになっています。 AIスコアの分類は、どのように決定してきたか？まず、レビューを規約やノウハウに基づき NG、OK、UKに分類するその後、例えばOK判定の場合は、標準的、良質、高品質、該当なしの 4区分に分類、それがどのようなレビューに該当するかを明確化する。そして各区分に対してスコアと紐づける形です。システムのスケールアップやセキュリティ対策についてはどう対処していますか？ StepFunctionsはクラウド環境上では同時に 5000まで並列化を可能。社内のセキュリティ診断を実施。加えてレスポンスには XMLフォーマットの厳格な検証により、不正な入力が適切にブロックされることは確認。最終的には、クレーム管理で 4000万人の集合知を利用している。 86 Q&A集（3/3）

Slide 87

Slide 87 text

© DMM 87 RAGの内部実装プロンプト内に判断基準となる事例を事例データベースとして多数組み込む本来RAGとして実装しても良い部分今回、事例がそこまで多くならないのでプロンプトの内部実装でカバー Chain of thoght AIに段階的に考える手順を示して判断精度を向上させる技術なぜNGと判断したかをStep By Stepで考えさせる RIG（参照情報生成）判定結果と対応する基準番号を紐づけて回答させ、誤判断を防止例：「NG [N006-N4]：容姿への不適切コメント」自己リライト方式 AIが一度出した回答を自分自身で見直し、改善する技術 AIは初回回答を批判的に分析し、より精度の高い判断を行う Temperature最適化一貫性のある厳格な判断を優先、値を0.7など低めに設定し、精度向上 Step Functions 非同期・並列処理非同期の同時並列実行で評価時間を大幅短縮過去データのバッチ処理により一括で数百のレビューを評価できるクロスリージョンインターフェースリージョン障害時に自動フェイルオーバーが可能となる対応サービス継続性の確保により AI判定の停止リスクを軽減採用技術アンサンブルLLM 複数AI回答の多数決方式、精度は多少向上するが AIの判定ばらつきによりプロンプトの原因と改善が難しくなるため却下 TOT （Tree of Thoughts） 1モデルに複数役割を演じさせ、回答させる 1個あたりの回答精度が低下するため却下不採用

Slide 88

Slide 88 text

Slide 89

Slide 89 text