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
140
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
110
Featured
See All Featured
Large-scale JavaScript Application Architecture
addyosmani
510
110k
How To Stay Up To Date on Web Technology
chriscoyier
788
250k
KATA
mclloyd
29
14k
Embracing the Ebb and Flow
colly
84
4.5k
Navigating Team Friction
lara
183
14k
jQuery: Nuts, Bolts and Bling
dougneiner
61
7.5k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
47
2.1k
Why You Should Never Use an ORM
jnunemaker
PRO
54
9.1k
Testing 201, or: Great Expectations
jmmastey
38
7.1k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
6.8k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
226
22k
StorybookのUI Testing Handbookを読んだ
zakiyama
27
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