LLMツールを開発してレビューパトロール時間を67.7%削減した話

AI 機械学習 技術選定

LLMツールを開発してレビューパトロール時間を67.7%削減した話

はじめに

こんにちは、データサイエンス部データサイエンス2ブロックのNishiyamaです。我々のチームでは、AIやデータサイエンスを活用したプロダクトの開発ために、研究開発に取り組んでいます。我々のチームの具体的な業務については、以下の記事を参考にしてください。

techblog.zozo.com

本記事では、レビューパトロールの業務時間を67.7％削減したガイドライン違反検出ツールの開発について述べます。社内で特定の部署が抱える課題を解決し、業務効率を上げるツールを開発する方の一助になると幸いです。

目次

ガイドライン違反検出ツール

開発したガイドライン違反検出ツールは、LLMを用いてZOZOTOWN上のレビューをパトロールし、違反を検出します。具体的には、以下に示すパイプラインを開発しました。

ガイドライン違反検出ツールのパイプライン図

パイプラインは、バッチ処理として実行されます。以下は詳細なステップです。

  1. Cloud SchedulerはCloud Functionsをトリガーする
  2. Cloud FunctionsはVertex AI Pipelinesをキックする
  3. BigQueryから対象期間のレビューを抽出する
  4. Cloud Storageからガイドラインを取得する
  5. 3と4で得られたレビューとガイドラインをガイドライン違反検出ロジックへ入力する
  6. 違反検出ロジックは、違反可能性が高いレビューと違反理由を出力する
  7. 違反可能性が高いレビューと違反レビューをGoogle スプレッドシート（以下、シートと呼ぶ）に書き出す
  8. シートのURLを取得し、Slackへ通知する

以降は、ガイドライン違反検出ツールを作成した理由と、技術選定について述べていきます。

背景

2023年にZOZOTOWNはレビュー機能を実装し、ユーザーは、ZOZOTOWNで購入した商品へレビューを投稿することやレビューを閲覧できるようになりました。また、健全なサイト運営のためのレビュー投稿ルールとしてレビューガイドラインを導入しパトロール業務が発生しました。パトロール業務は、投稿されたレビューに対して、レビューガイドライン違反の有無を判定する業務です。パトロールでレビューガイドライン違反と判断されたレビューは、ガイドラインに従ってZOZOTOWN上から取り下げる対応をします。

ZOZOTOWN上のレビュー例

作成した理由

ガイドライン違反検出ツールは、パトロール業務を担当する部署が抱えていた、次の2つの課題を解決する価値が高いため開発しました。

  1. 現在、パトロール業務にかける時間や担当者が多い
  2. 将来、パトロール業務にかける時間や担当者が増加する

上記の課題を解決することで、パトロール担当部署は、これまでパトロール業務にかけていた時間や担当者を将来的にも別の業務に割り当てることができます。よって、解決する価値が高いと判断しました。

課題の原因

まず、パトロール業務にかける時間や担当者が多い理由は、一件ずつ目視で確認していたからです。以下にパトロール業務のフローを示します。

  1. 対象の期間のレビューを集計しシートに書き出す
  2. レビューのタイトルと内容がガイドラインに違反しているか目視で照らし合わせて確認する
  3. ガイドライン違反の有無と理由をシートに記載する

特に、パトロール業務のフロー2で照らし合わせるガイドラインは、30項目以上あります。そのため、パトロール業務の時間や担当者数の増加につながっています。

次に、将来パトロール業務にかける時間と人数が増える理由は、投稿されるレビュー数の増加が考えられるからです。要因として以下が考えられます。

  • レビュー機能の認知向上
  • 商品数の増加
  • キャンペーンの実施

パトロール業務フローを見ると、投稿されるレビュー数の増加は、そのままパトロール対象のレビュー数の増加につながることがわかります。

課題の特定方法

上記の課題と原因を特定した方法は、関係者へのヒアリングです。以下のようなヒアリングをして、パトロール担当者の業務を理解し課題の深掘りをしました。

  • パトロール業務の目的と内容
  • パトロール業務に時間と人がかかる理由

ヒアリング内容から、課題の解決された状態を想定して、リリース基準を作成しました。

課題の解決方法

パトロール業務の品質を担保した上で課題を解決するために、半自動化の運用を採りました。半自動化は、ガイドライン違反検出ツールの出力を、パトロール担当者が目視確認する運用です。半自動化の運用にした理由は、ガイドライン違反検出ツールのみで、違反を確定させることが難しかったからです。具体的には、商品画像を参照しなければ分からない商品不良や人間の判断に委ねるべき曖昧なレビューが該当します。下記にガイドライン違反ツールを用いたパトロール業務のフローを示します。

  1. ガイドライン違反検出ツールが対象の期間のレビューを入力として違反可能性が高いレビューと違反理由をシートに書き出す
  2. パトロール担当者は違反可能性の高いレビューがガイドラインに違反しているか目視で照らし合わせて確認する
  3. ガイドライン違反の有無と理由をシートに記載する

ガイドライン違反検出ツールは、対象期間のレビューを入力として、違反可能性が高いレビューを出力します。違反可能性が高いレビュー数は、対象期間のレビュー数と比較して、68.5％少ない量になります。したがって、パトロール業務を担当する部署が抱えていた課題を以下の2点において解決していると言えます。

  1. 現在、対象期間のすべてのレビューと比較して68.5％少ない違反可能性が高いレビューの目視確認で済むため、パトロールにかける時間や担当者を削減できる
  2. 将来、投稿されるレビューが増加した際も、違反可能性が高いレビューのみ目視確認するため、時間と担当者の増加を抑えることができる

技術選定

ガイドライン違反可能性の高いレビューを検出するために、LLMのモデルとしてOpenAI APIのgpt-4-1106-previewを採用しました。OpenAIのGPT-4 APIを採用した理由は2点あります。1点目は、少量のデータセットに対してIn-Context Learningすることである程度の検出力が見込めたからです。2点目は、In-Contex Learningによりガイドライン違反基準を素早く柔軟に変更できるためです。素早く柔軟な違反基準の変更がメリットになる理由は、違反基準に主観を含む言語化の難しい曖昧なレビューが存在しているためです。技術選定時に比較・検討した手法は以下です。

  • LLM
  • ナイーブなテキストフィルタリング
  • モデルのフルスクラッチ・ファインチューニング

比較・検討結果について述べます。ナイーブなテキストフィルタリングは、違反可能性の高いレビュー検出の精度が低くなりました。なぜなら、同様のテキストが含まれる文章であっても、使用される文脈によって、ガイドライン違反の有無が異なるためです。次に、モデルのフルスクラッチ・ファインチューニングは、大きなデータセットをアノテーション段階から構築する必要があったため見送りました。

LLMを用いたガイドライン違反検出ツール開発

LLMを用いたツール開発の戦略は、Optimizing LLM Accuracyに従いました。promptの書き方については、Best practices for prompt engineering with the OpenAI APIを参考にしました。特に参考にした点は以下です。

  1. stepを明示的に示す
  2. Few-shot promptingを与える
  3. 期待する出力を明示する

各項目について、具体例を交えて、説明します。

1点目の「stepを明示的に示す」では、細かくstepを分け明示的に推論過程を与えました。加えて、Zero-shot Chain-of-Thoughtも使用しました。具体的な例を以下に示します。

prompt: str = f"""
        step1: ガイドライン項目をよく読んで、理解します。
        step2: レビュー内容をガイドラインと1つ1つ照らし合わせて違反を検出します。
        step3: 違反の有無と理由をあなたの考えも合わせて出力してください。
        Let's think step by step
"""

2点目の「Few-shot promptingを与える」では、ガイドライン違反検出の精度が低い項目に絞って使用しました。Few-shot promptingは、LLMに少数の例を明示的に与える方法です。具体的な例を以下に示します。

prompt: str = f"""
        違反の有無と理由をあなたの考えも合わせて出力してください。
        {guidelines[i]}の違反例:
                {violation_examples}
"""
# guideline[i]: 違反検出精度が低いガイドラインの本文
# violation_example: 違反例

3点目の「期待する出力を明示する」では、JSON formatを明示的に与えました。理由は2点あります。1点目は、出力を通し番号にすることで、input tokensより3倍高いoutput tokensの料金を抑える狙いがあったからです。2点目は、response_format={"type": "json_object"} とした場合でも期待するJSON formatではない場合があったからです。

prompt: str = f"""
        あなたの出力は以下の出力フォーマット例に従ったjson formatです。
        出力フォーマット例:
        1. 違反がある場合:
                {{"違反あり" : "通し番号"}}
        2. 違反が複数ある場合:
                {{"違反あり" : "通し番号,通し番号")}}
        3. 違反が無い場合:
                {{"違反なし" : ""}}
"""

実験

定量評価のための実験は、学習データセットに対してPrompt Engineeringを行いprecision, recall, f1-scoreを確認し、エラー分析をしました。データセットは、パトロール業務担当者にアノテーションを依頼し少量ずつ構築しました。

定性評価のための実験は、2つあります。1つ目は下記のようにグループを分け、ガイドライン違反を目視確認する実験です。この実験の目的は、ガイドライン違反ツールの出力が、目視確認とどの程度異なるか検証することです。2つ目は、False Negativeの質に対する実験です。この実験の目的は、ガイドライン違反検出ツールが許容できない見逃しをしていないかの確認です。なぜなら、半自動化の運用上、False Negativeのレビューは、担当者による目視確認がされないままZOZOTOWN上に掲載されるためです。

グループ タスク
Aグループ 全てのレビューを目視確認する
Bグループ ガイドライン違反可能性の高いレビューのみ目視確認する

評価

リリース基準を超えた時点での定量評価と定性評価について述べます。定量的な評価は以下のようになりました。precisionがやや低いため、目視確認する量が増えています。一方recallは高いツールとなっていることが分かります。

手法 / 評価指標 precision recall f1-score
ガイドライン違反ツール 0.75 0.934 0.8319

定性的な評価は、AグループとBグループで出力の差異がほとんどない結果になりました。また、False Negativeの質についても、問題がない範囲であることを確認しました。

コスト

ガイドライン違反検出ツールにかかる費用は、2つあります。1つ目がgpt-4-1106-previewの料金で$0.022/1レビューです。2つ目がGoogle Cloudの料金で、dev, stg, prd環境を合わせて$4.11/月です。

開発で徹底したこと

ガイドライン違反検出ツールの開発で徹底したことは、パトロール担当部署の課題を解決することです。そのために、パトロール担当部署と連携を取りました。具体的には、定例ミーティングへの参加と定性評価と実験です。定例ミーティングへ参加することで、以下のメリットがありました。

  • 開発着手時から後のユーザーとなる現場の声をツールに反映できる
  • 現場の課題の優先度を鑑みて、開発する機能の優先度を揃えたスケジュール管理ができる
  • 開発者がパトロール担当者から直接良い/悪いフィードバックを受けられる
  • 認識の齟齬によるプロジェクトの手戻りが無い

定性評価と実験では、実験の設計段階から双方向に会話をして取り決めることができました。加えて、普段からコミュニケーションを取っていたため、実験が終わり次第評価・フィードバックというサイクルを早めることができました。私とパトロール担当部署を含めた関係者の間で課題を解決することを共有し、同じ方向を向けていたことは、ガイドライン違反検出ツールの質を高めたと感じます。

さいごに

本記事では、ガイドライン違反検出ツールの開発を紹介しました。ガイドライン違反検出ツールの導入により、業務時間を67.7％削減、チェック件数を68.5％削減しました。課題解決のためのツール作成を検討している方がいれば、ぜひ参考にしてみてください。

ZOZOでは、一緒にサービスを作り上げてくれる方を募集中です。ご興味のある方は、以下のリンクからぜひご応募ください。

corp.zozo.com

カテゴリー