Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
EC×生成AIのテーマ 〜ハピタスの生成AIの導入事例〜
Search
株式会社オズビジョン
September 05, 2024
0
130
EC×生成AIのテーマ 〜ハピタスの生成AIの導入事例〜
ECx生成AI活用の事例紹介として発表した資料です。
ハピタスにおける事例紹介、知識ゼロで2024年4月1日からスタートし、2024年9月3日時点までの状況を紹介しました。
株式会社オズビジョン
September 05, 2024
Tweet
Share
More Decks by 株式会社オズビジョン
See All by 株式会社オズビジョン
Amazon Bedrockのビジネスへの適用_ハピタスの事例共有
ozvision
0
100
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
510
110k
Building Your Own Lightsaber
phodgson
102
6k
Music & Morning Musume
bryan
46
6.1k
Code Review Best Practice
trishagee
64
17k
Imperfection Machines: The Place of Print at Facebook
scottboms
264
13k
GraphQLとの向き合い方2022年版
quramy
43
13k
Responsive Adventures: Dirty Tricks From The Dark Corners of Front-End
smashingmag
250
21k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
41
2.1k
Optimising Largest Contentful Paint
csswizardry
33
2.9k
YesSQL, Process and Tooling at Scale
rocio
167
14k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
46
2.1k
The Power of CSS Pseudo Elements
geoffreycrofte
72
5.3k
Transcript
© Copyright OZVISION inc. EC×⽣成AIのテーマ 〜ハピタスの⽣成AIの導⼊事例〜 2024.09.03 Ver.01 ハピタス事業部 開発G
卜部真一
© Copyright OZVISION inc. 事業∕プロダクト 01 AWSの⽣成AI活⽤プログラムにて 03 短納期ローンチが叶った要因 04
ローンチ後の軌跡 05 AI導⼊の意思決定までのエピソード 02
© Copyright OZVISION inc. 事業∕プロダクト 01
© Copyright OZVISION inc. 4 事業∕プロダクト 社名 設立 所在地 従業員数
株式会社オズビジョン 2006年5月(現在19期目) 東京都渋谷区神宮前 111名 会社紹介
© Copyright OZVISION inc. 5 事業∕プロダクト ポイントモール ECユーザーと EC事業者をマッチング どこで買ってもWで
ポイントが貯まる 買取サービス モノを捨てずに手放したい人と リユース事業者をマッチング 簡単・気軽にモノを手放せる ネット広告代理店 メディアやインフルエンサーと EC事業者をマッチング 成功報酬型でコスパ良く集客 事業概要 広告 B 広告 C 広告 D 広告 E 広告 F 広告A 広告B〜E 広告A 事業 1 事業 2 事業 3
© Copyright OZVISION inc. 6 事業∕プロダクト ECプラットフォーム (マッチング)
500万人超 EC利用者 モノを捨てない人 メディア/ インフルエンサー EC事業者 リユース事業者 EC事業者 サービス利用 サービス利用 サービス利用 流通取引総額 (GMV) 1,800 億円超 送客手数料/広告費 (TakeRate) 約4% 購買 中古買取 広告 3,500件超 ビジネスモデル 〜EC利⽤者とEC事業者のマッチングプラットフォーム〜
© Copyright OZVISION inc. 7 事業∕プロダクト 「いつものネットショッピング、旅行やレストランの予約、引っ越しや保険の見積もりまで、 どこを利用しても特典ポイントが貯まる」会員サービスです。 プロダクト紹介:ポイントモール「ハピタス」 広告B
広告A 広告C 広告D 広告E 広告F 広告A 広告B〜E
© Copyright OZVISION inc. 8 事業∕プロダクト 競争が激しい (成長市場×参入障壁低) EC利用者 (500万超/5,000万)
EC事業者 (3,500/400万) サイト経由 ポイントバック 送客 成功報酬 一時は競合他社が100社以上… 競合A社 競合B社 競合C社 ハピタスの事業環境(リボンモデル) 広告 B 広告A 広告 C 広告 D 広告 E 広告 F
© Copyright OZVISION inc. 9 ポイントビジネスは⼤きく伸びている →キャッシュレスや各種決済、ポイント経済圏など 事業∕プロダクト ポイント業界を取り巻く環境 ポイントサイトも成⻑を続けているが、その⼀⽅でコモディティ化が進⾏している
→ユーザーに選ばれる優位性を築けないと、利益を削ってパイを奪い合う消耗戦に突⼊ 01 02
© Copyright OZVISION inc. AI導⼊の意思決定までのエピソード 02
© Copyright OZVISION inc. オズビジョンが抱えていた課題 11 ⽣成AIを活⽤したいが それを推進できないもどかしさ 2024年 03⽉頃
開発主導での企画提案が強く求められていた ⼀案として「⽣成AIを活⽤したい」という意⾒はあったが、 それを実現するための ‧ビジネスアイデアを出す企画⼒ ‧スキルセットや⼈材 などが不⾜しており、 うまく推進できないもどかしさがあった 企画
© Copyright OZVISION inc. AWSの「⽣成AI活⽤開始プログラム」との出会い 12 転機が訪れた 2024年 04⽉ AWSの⽣成AI活⽤開始プログラムの案内をいただく
⽀援付きで⽣成AI導⼊に取り組める「渡りに船」の状況 導⼊費⽤や企画⽀援が受けられる点が経営層に刺さり 短期間で社内稟議決裁 ※費⽤が膨れ上がるリスクに対して、アーキテクチャ検討や費⽤シミュレー ションを⼊念に⾏うよう、経営層から強いオーダー 全社全⼒で取り組む機運が⽣まれており 各部署のキーマンを集めて、プログラムに参戦
© Copyright OZVISION inc. 13 全体スケジュール 4⽉ 5⽉ 6⽉ ワークショップ
ガントチャート 4⽉から着⼿して7/1に無事にローンチ🎉 プロトタイピング 検証 ‧プロトタイ プ検証 ‧精度チュー ニング 本実装 +動作確認 ‧ハピタス側 検索改修 ‧データ登録 処理⽤意 ローンチ ‧⼿順作成 ‧体制決め ‧ローンチ ★4/10 プログラムキックオフ 社内稟議 ★4/16 PoC作成ワークショップ ★4/11 ユースケース確定ワークショップ
© Copyright OZVISION inc. AWSの⽣成AI活⽤プログラムにて 03
© Copyright OZVISION inc. 15 「ANA」と検索した際に「Banana」を含む広告が上位表⽰されてしまうなど、 ユーザーが必要としていない検索結果が表⽰されてしまう →ユーザーが求めてない情報=ノイズが⼊ることでCVRが低下 プログラムでの検討 1/2 ビジネス課題
指名検索での利⽤がほとんど 01 02 ANA系 広告 ANA系 広告 ANA 系 広告 ANA系 広告 ANA系 広告 ANA系 広告 ANA 系 広告 ANA 系 広告 ANA 系 広告 非 ANA系 非 ANA系 非 ANA系
© Copyright OZVISION inc. 16 ⽂字列の単純な部分⼀致検索によるノイズの除去 例)【再掲】「ANA」と検索した際に「Banana」を含む広告が上位表⽰されないように プログラムでの検討 2/2 ビジネス課題解決の打ち⼿ 指名検索だけでなく、フリーワード‧短⽂でも適切な検索を実現
例)はじめての発⾏におすすめなクレジットカード 広告に紐づくアイコン情報や説明⽂など、案件名以外にも紐づいた検索結果の出⼒ キャンペーン対象‧無料などの情報も元に、ユーザーの求める広告を表⽰ 01 02 03
© Copyright OZVISION inc. 17 明確な意志を持たずに広告を探しているユーザーに対し フリー⼊⼒時の検索結果をより関連度が⾼いと考えられるものに改善 →検索利⽤者のCVRを向上 プログラムでの検討 まとめ ⽬的
全検索における CVR を数ポイント改善できると仮定 効果シミュレーション(CVRの改善による売上伸⻑) Amazon Bedrock, AWS Fargate, Aurora Serverless 等の利⽤分 ※当初トークンを多く⾒積もりすぎていたが、AWSの⽀援を受けながら検討を重ね、適切な⾒積もりへ補正 費⽤シミュレーション(運⽤時のAWS費⽤)
© Copyright OZVISION inc. 短納期ローンチが叶った要因 ※あくまで結果論にすぎませんが 04
© Copyright OZVISION inc. 19 全体スケジュール【再掲】 4⽉ 5⽉ 6⽉ ワークショップ
ガントチャート 4⽉から着⼿して7/1に無事にローンチ🎉 プロトタイピング 検証 ‧プロトタイ プ検証 ‧精度チュー ニング 本実装 +動作確認 ‧ハピタス側 検索改修 ‧データ登録 処理⽤意 ローンチ ‧⼿順作成 ‧体制決め ‧ローンチ ★4/10 プログラムキックオフ 社内稟議 生成AIの知見・経験ゼロの状況から、わずか 3ヶ月でローンチ その要因を考えてみた ★4/16 PoC作成ワークショップ ★4/11 ユースケース確定ワークショップ
© Copyright OZVISION inc. 20 短納期ローンチの成功要因① 4⽉ 5⽉ 6⽉ ワークショップ
ガントチャート ★4/16 PoC作成ワークショップ 上流から下流に⾄るまでの「AWSの⼿厚いサポート」が⼼強すぎた プロトタイピング 検証 ‧プロトタイ プ検証 ‧精度チュー ニング 本実装 +動作確認 ‧ハピタス側 検索改修 ‧データ登録 処理⽤意 ローンチ ‧⼿順作成 ‧体制決め ‧ローンチ ★4/11 ユースケース確定ワークショップ ★4/10 プログラムキックオフ 社内稟議 立ち上げから、コスト試算、実装に至るまで すべてのプロセスにおいて「 AWSの手厚いサポート」があったからやり遂げられた AWSの⼿厚いサポート 相談 Q&A 相談 Q&A 相談 Q&A 相談 Q&A
© Copyright OZVISION inc. 21 開発主導で「⽣成AIという新しい技術を⽤いたプロダクト改善」を起案 短納期ローンチの成功要因② 関係者の思惑が⼀致 事業責任者も「プロダクト起点でのグロース」に賛同 続々と発生する課題に対して、組織を超えて協力し合いながら取り組めたことが、大きな成功要因
01 02
© Copyright OZVISION inc. 22 意思決定の壁【体制】 └事業、データ、開発のキーマンを揃え、少数精鋭で素早い意思決定 短納期ローンチの成功要因③ 短納期を阻む「壁」を乗り越える⼯夫 開発⼯数と期間の壁【スコープ】
└壮⼤にせず、地に⾜のついた内容で、スコープも絞り込む └プロダクトの要となる画⾯‧機能をターゲットにする(→検索) └UIは変えない、作り込まない 稟議の壁【コストと効果】 └事業責任者を体制に組み込み、試算から稟議‧承認まで素早く進⾏させた └⽀出:⽣成AIの導⼊‧運⽤により発⽣するコスト(開発ボール) └収⼊:効果⾒⽴て(事業サイドボール) 事業責任者の後ろ盾もあり、各部署のキーマンを揃えて挑んだことで 「壁」を乗り越えやすくなったのは間違いない 01 02 03
© Copyright OZVISION inc. 23 関係者の思惑を⼀致させ、キーマンを巻き込んだ 短納期ローンチの成功要因‧まとめ 短納期を阻む「壁」を乗り越える⼯夫を⾏い、意思決定を⾼速化 AWSのサポートを最⼤限活⽤した 02
03 01
© Copyright OZVISION inc. ローンチ後の軌跡 05
© Copyright OZVISION inc. 25 出して終わりではなく、PDCA期間に突⼊ 7⽉ 8⽉ 9⽉ 初回ローンチ
PDCA期間 ローンチ後、継続的にPDCAサイクルを回しています ★ローンチ ABテスト① 振り返り →改修 ABテスト② 振り返り →⼿法検討‧改修 経過観察 振り返り →改修 検証期間〜
© Copyright OZVISION inc. 26 初回ローンチの結果 検索結果の精度が向上🎉 Before After ANA系
ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 非 ANA系 非 ANA系 非 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系
© Copyright OZVISION inc. 27 初回ローンチの結果 効果測定の結果(7/1〜11) 表示順 ソート項目 検索回数比率
1 人気順 ※デフォルト 97% 2 おすすめ (ベータ) ※ベクトル検索 0% 3 新着順 0% 4 高ポイント順 2% 5 高還元率順 0% デフォルトのソートが「人気順」のままで、ベクトル検索を仕込んだ「おすすめ (ベータ)」の利用は1%に満たない状況 ▼ 「認知すらされず使われていない、圧倒的に母数が足りない」 というファインディング
© Copyright OZVISION inc. 検索の半数は強制的にベクトル検索 (⽣成AI)になるので、利用された上での評価ができるはず 28 改善アクション① 【対策】デフォルトのソートを半々にしたABテストを実施 A.
⼈気順 ←これまでのデフォルト B. おすすめ (ベータ) ←ベクトル検索(⽣成AI) 2営業日で 実装完了 引き続き 高速PDCA 振り返り
© Copyright OZVISION inc. 29 その結果は...
© Copyright OZVISION inc. 30 その結果は... ⽣成AIの負け😢
© Copyright OZVISION inc. 31 成果指標に基づいた評価 ABテストを実施(分析の都合上、期間①と②で条件を反転させて実施) →全期間、全指標において「⽣成AIの負け」という、受け⼊れ難い現実 50%未満 ▼
⽣成AIの負け 50%未満 ▼ ⽣成AIの負け
© Copyright OZVISION inc. 32 敗因を探る...
© Copyright OZVISION inc. 33 初回ローンチの結果【再掲】 検索結果の精度が向上🎉 Before After ANA系
ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 非 ANA系 非 ANA系 非 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系 ANA系
© Copyright OZVISION inc. 34 改めて、しっかり観察してみる 別の検索ワードでも、検索結果の精度が向上 (「クレジットカード」で検索) ⼈気順 ※⽣成AIじゃない⽅
おすすめ(ベータ) ※⽣成AI 金券 クレカ 動画 サブスク クラウド サブスク 動画 サブスク 音楽 サブスク クレカ クレカ クレカ クレカ クレカ クレカ マッチング精度の向上は揺るがぬ事実
© Copyright OZVISION inc. 35 違う側⾯からの気づき ランキングと⽐較すると... ランキング クレカ 圏外
クレカ 67位 クレカ 圏外 クレカ 17位 クレカ 46位 クレカ 圏外 おすすめ(ベータ) ※⽣成AI クレカ 29位 クレカ 圏外 クレカ 42位 クレカ 61位 クレカ 圏外 クレカ 69位 クレカ 37位 クレカ 27位 クレカ 72位 クレカ 圏外 クレカ 圏外 クレカ 圏外 目隠し 目隠し ⼈気の観点が⽋けてた!
© Copyright OZVISION inc. 原因と対策の議論 36 検討内容のサマリー ⽣成AIの導⼊により、 キーワードとのマッチング精度の⾼い 検索結果が表⽰できるようになった👍
従来の「⼈気順」の⽅が、 ⽣成AIよりも⾼い成果が出ている😢 ⽣成AIに「⼈気順の要素」を加味することで ⾼い成果が期待できるのではないか? 01 02 03
© Copyright OZVISION inc. 37 改善アクション② 【対策】⽣成AIに「ランキング」のデータをMIXして、精度と成果の両⽴を狙う MIX手法検討 ▼ 実装
引き続き 高速PDCA 振り返り ノイズ除去と⼈気の反映を⾏うことで、より成果に繋げられるのではないかと期待
© Copyright OZVISION inc.
© Copyright OZVISION inc. AWSの⽣成AI活⽤プログラム 〜実装検討編〜 XX
© Copyright OZVISION inc. プログラムでの実装検討 40 既存画⾯へ組み込み UIを変えない、作り込まないことが 短期ローンチのためのカギ 組み込み候補何箇所かあり
‧サイト内共通検索窓 ‧新規会員オンボーディング⽤広告エリア ※短⽂での検索、アイコン対象などを 将来的には打ち出していきたい!
© Copyright OZVISION inc. 41 プログラムでの実装検討 実装案 広告データのベクトル化 ‧現状のデータ ‧追加/更新データ
これらを Amazon Aurora Serverless v2 に格納 検索クエリのベクトル化 ‧エンドユーザの⼊⼒内容を ベクトル化し Amazon Aurora Serverless v2 へ問い合わせ →広告 ID を取得することで 適切な検索結果を返すことを検討 初版の実装範囲は⾚枠の部分を想定
© Copyright OZVISION inc. 実際の成果物 XX
© Copyright OZVISION inc. 43 検索画⾯へ組み込み 「おすすめ(ベータ)」として既存検索画⾯へ組み込み
© Copyright OZVISION inc. 44 アーキテクチャ図
© Copyright OZVISION inc. 45 処理の流れ① 登録‧更新 1. ハピタス上広告データの差分 CSV
ファイルを S3 に定期送信 2. ECS から CSV ファイルを読み取り、 Bedrock (Amazon Titan Text Embeddings モデル v2) を⽤いてベクトルデータを⽣成 3. ⽣成データを PostgreSQL に登録 1 2 3
© Copyright OZVISION inc. 46 処理の流れ② 検索 1. 検索ワードを Bedrock
(Amazon Titan Text Embeddings モデル v2) を⽤いてベクトルデータに変換 (Lambda 経由) 2. PostgreSQL から、ベクトル値の類似度の⾼い順に広告IDの⼀覧を返却 3. Webサーバ側で、MySQL の最新情報を元に情報のフィルタリング‧補完を⾏い、結果をユーザに返却 1 2 3
© Copyright OZVISION inc. 47 アーキテクチャの⼯夫ポイント 1/5 【Q】なぜ、ハピタスは東京リージョン、新環境の⽣成AI側はバージニアリージョンなのか? • 【A】価格が割安であり、且つ新しいモデルが先⾏して使えるリージョンであるため ◦
懸念はレイテンシー遅延だったが、計測の結果許容範囲内 (0.3s) リージョン跨ぎによる レイテンシー遅延はわずか0.3s
© Copyright OZVISION inc. 48 アーキテクチャの⼯夫ポイント 2/5 【Q】ベクトルDBに OpenSearch ではなく Amazon
Aurora Serverless [PostgreSQL] を利⽤している理由は? • 【A】コスト削減のため コスト削減
© Copyright OZVISION inc. 49 アーキテクチャの⼯夫ポイント 3/5 【Q】ベクトルデータ登録処理に Lambda ではなく ECS
を使っている理由は? • 【A】ベクトルデータ登録処理に 30 分以上かかるため ◦ Lambda の制約:15分 ◦ コスト⾯では本来は Lambda のほうが優れている 処理に30分かかるため
© Copyright OZVISION inc. 50 アーキテクチャの⼯夫ポイント 4/5 【Q】API Gatewayを通さず、そのまま既存バッチサーバ、既存Webサーバから ベクトルDBの更新をしなかった理由は? •
【A】python の機械学習ライブラリを最⼤限活⽤するため ◦ 既存環境は PHP ◦ 役割を既存環境に持たせすぎない意図もある
© Copyright OZVISION inc. 51 アーキテクチャの⼯夫ポイント 5/5 【Q】Titan Text Embedding v2
(2024/4/30 リリース) を採⽤した理由は? • 【A】コスパが良かったため ◦ 当初想定は Cohere Embed Model v3 だが、本実装では Titan Text Embedding v2 でもほぼ同等の結果 ◦ 価格は 1/5 本ユースケースでは 期待結果に差異がなく 価格が1/5