1. 概要:LLMを使ったマスターデータマネジメント
NTTドコモ データプラットフォーム部の外山です。
NTTドコモでは、携帯回線事業の他、お客様の新たなライフスタイルを創出するスマートライフ事業を運営しており、 とりわけエンターテインメント領域では、書籍、映像サービスを提供しています。 豊富なコンテンツの中から、よりよいコンテンツをお客様に届けるうえで、コンテンツレコメンドを実施していますが、 その基本となる作品情報をレコメンド向けに整理・再構築することは属人性が高く、根気強い作業が必要なため、リードタイムがかかるものとなります。
こうしたマスターデータマネジメントにLLMを活用し、情報の整理・再構築の標準化をいかに実現するかを本記事ではご紹介します。
本記事の掲載の取り組みについては、AMBL株式会社の中山さん・田中さんの2名に詳細検討・実装を進めてもらっており、以下については、お二人に執筆いただいています。
2. ジャンルメタデータの課題と対策
Writer: AMBL株式会社 中山幸陽
作品情報の一つであるジャンルメタデータには大きく3つの課題がありました。
- 類義語がサービス内・サービス間で存在している
- コンテンツジャンルの代表性がない
- ジャンル総数が多く、分析上扱いにくい
これらの課題によって、ジャンルに基づくコンテンツの紐づけや、適切な粒度での分析が困難であること、 また、既存ジャンルメタデータの情報は約1,000項目近くあり、人力での整理・再構築は難しい状況でした。 そこで、整理・再構築のプロセスをLLMにも委ねることで、課題解決を図りました。
効果が見込めるか？をクイックに確かめるために、今回はGUI形式でLLMを要所要所で活用しつつ、人間の手も加えながら以下のフローで実装を行っています。LLM活用箇所の詳細については、次章で説明いたします。
- 既存ジャンルメタデータ抽出
- ジャンルの仕分け（メインジャンル・サブジャンル）
- 新旧ジャンル情報のエンベディング
- 近似最近傍探索を実施
- 探索結果を元にマスターデータへ反映
※Bold箇所でLLMを活用
3. ジャンル集約プロセスの詳細
Writer: AMBL株式会社 田中天
この章では、先述の実装フローの詳細を紹介します。 なお、LLMに関しては、GPT-4をドコモ社内のアプリを通して利用したため、同一プロンプトであっても、生成結果を保証するものではない点は留意ください。
3.1. 実行プロンプト
手順1. 各サービスのジャンルを抽出
まず現状のジャンルは ファンタジー ドラマ アクション のような複数単語で構成されているため、これらを一度分解して単語の状態にします。
その後、類似しているものやジャンルとは言えないものを集約するプロンプトにかけることで、アウトプットとして簡易的に集約されたジャンルを取得します。
プロンプト例
# 命令 抽出データの中からジャンルとは言えないものを削除してください。 また類似するものは代表を残して削除してください # 抽出データ ドラマ ロック アクション ヨーロッパ ファンタジー ハイキング 音楽 プラモデル 小説
アウトプット例
ドラマ ロック アクション ファンタジー ハイキング 音楽 プラモデル 小説
この後、ジャンルを更に体系的に集約するために、サービス範囲、他サービスジャンルを参考にメインジャンルを定義します。 LLMでも集約を試しましたが粒度感を揃えることが中々上手くいかず、ここは手作業となってしまいました。 映像系であれば音楽やアニメ、書籍系であれば文芸書や漫画といったメインジャンルを12個作成しました。
手順2. LLMによって集約したジャンルをメインジャンルに振り分け
手順1で作成したメインジャンルに対して、集約したジャンルを振り分けるプロンプトを用いてサブジャンルを作成します。 この時振り分けれなかったものを余りとして出力し、メインジャンルが足りないようであれば手順1に戻って再度検討します。 手順1の処理の際にジャンルでないものは削除していますが、残っている可能性もあるため余りとして出力しています。
プロンプト例
#命令 メインジャンルに対し、手順1で集約したジャンルをサブジャンルとして振り分けてください。 振り分けれないものは余りとして出してください。 サブジャンルが類似・重複しないようにしてください。 # 振り分け形式 メインジャンル/サブジャンル ドラマ/アクション # メインジャンル 音楽 ドラマ 文芸書 漫画 # 1で集約したジャンル ドラマ ロック アクション ファンタジー ハイキング 音楽 プラモデル 小説
アウトプット例
音楽/ロック ドラマ/アクション 文芸書/小説 漫画/ファンタジー 余り ハイキング プラモデル
手順3. 手動での最終調整
これまででメインジャンルとサブジャンルの作成はできました。 しかし、元々各サービスのジャンル内にないものがあったため手作業で追加しました。
追加例
TV番組に戦隊 TV番組にニュース
3.2. 工夫した点:2階層構造の採用とジャンルの粒度調整
レコメンド用に2層構造にしたこと
メインジャンル/サブジャンル1・サブジャンル2というようなメインに対して、サブジャンルをいくつか付与するという方式(例:ドラマ/アクション・ファンタジー)も考えました。 しかし、今回はレコメンドや分析・抽出をサービスで横断的に行うことを目的としていたため、あえて情報量を落とし2階層にしました。
メインジャンルに振り分ける形式にしたこと
最初は存在するジャンルをLLMで集約し続けて階層を作ろうとしていました。 しかし、サービスに存在するジャンルに偏ってしまうことや、この後記述する粒度感を合わせるということが非常に難しかったため、 作成したメインジャンルに振り分ける形に変更しました。そうすることで、メインジャンルに振り分けられるものと振り分け先がなく余るものを見て、足りないメインジャンルの検討を行うことができるようになりました。
3.3. はまった点:LLMが苦手とする領域での工夫
メインジャンルの粒度調整がLLMでは難しく分類などを参考に手作業で作成
映像系の映画、ドラマなどはみなさんも想像が付きやすいかと思います。 しかし、これが書籍系統となるとかなり難しくなります。本のジャンルは日本十進分類法だけで1,000種類以上あり、階層も深いため全てを今回の形式にあてはめることは不可能でした。 そのため、LLMによって何度かまとめる際のジャンル候補を出し、本のジャンルをWEBで調査して文芸書、実用書というような本の種類を今回メインジャンルとして採用しました。 こういったサービスや利用形態に合わせた人間的な感覚を持つ柔軟なジャンル形態の作成というところは、LLMでは難しく今後の課題と思っています。
4. 実施結果
Writer: AMBL株式会社 中山幸陽・田中天
手順1~3を実施することで、約1,000項あったジャンルを体系的に200ジャンル程度に整理することができました。 この結果をコンテンツレコメンドモデルに組み込むことで、最大3.8ptの精度改善も確認できています。
5. まとめ
Writer: AMBL株式会社 中山幸陽・田中天
今回の取組により、手動対応の部分は残しつつも、LLMを用いることで、無数にあるジャンル情報の整理・再構築にかかるリードタイムの短縮が実現できました。 一方で、実施した作業の自動化にはまだ至れておらず、今後以下を取り組んでいく予定です。
- APIを介したLLMの実行により、一連のプロセスの自動化
- LLMによって生成されたジャンル情報の採用基準*1を作成し、評価そのものをLLMに実施させるような仕組み
エンターテインメント領域のコンテンツは移り変わりが激しいため、今回取り組んだようなマスターデータマネジメント自動化を図っていくことで、 お客様に常に満足いただける仕組みをご提供していきたいと思います。
*1:既に、評価指標は作成しており、3つの指標を利用しています。①:情報損失（情報整理前後の、情報量の比較観点）、②:スパース性（情報整理前後の、情報の代表性観点）、③:サービス間オーバーラップ度（情報整理前後の、情報の利用範囲観点）。今後、これらの妥当性を運用しながら確認していく予定です。
