日本一のポイントモールへとグロースさせるための「生成 AI を用いた検索体験向上」チャレンジ

ハピタスには数多くの広告が掲載されていますが、検索ワードによってはユーザーにとって望ましい広告が表示されにくいという課題がありました。

例えば、「ワイン」と検索した場合、「ワインダー（時計の自動巻き上げ機）」が上位に表示されてしまうケースです。

加えて、特定の広告を検索する「指名検索」がほとんどを占め、関連度の高い広告を表示させづらい状況がありました。

これらの課題を解決するため、意味的な検索ができるセマンティックサーチ機能の導入を検討しました。セマンティックサーチ機能は Amazon Bedrock と Amazon Aurora を使用したベクトル検索で実現しました。

1. 2 時間に一回の頻度でハピタスの広告データの差分の CSV ファイルを Amazon S3 に送信
2. Amazon ECS on AWS Fargate から CSV ファイルを読み取り、Amazon Bedrock ※ からベクトルデータを生成
3. 生成したデータを Amazon Aurora PostgreSQL に登録
   

1. 検索ワードを AWS Lambda から Amazon Bedrock ※ でベクトルデータに変換
2. Amazon Aurora PostgreSQL からベクトル値の類似度の高い順に広告 ID の一覧を返す
3. 広告 ID 一覧を Web サーバーが受け取り、Amazon Aurora MySQL の最新情報を元に不要な広告をフィルタ、必要なデータを付加し、結果をユーザーに返す

^{※ Amazon Titan Text Embeddings モデル v2を利用}

ハピタスは東京リージョンで運用されていますが、新たな生成 AI 環境はバージニアリージョンを選択しました。その理由は、レイテンシーの遅延が懸念されたものの、実際には許容範囲内の速度 (約 0.3 秒) であり、価格が割安であること、そして新しいモデルを試したかったためです。

既存の検索における通信レイテンシーは、東京リージョン内で完結しているため 0 秒であり、ブラウザへの応答時間は約 1.3 秒です。一方、ベクトル検索では通信レイテンシーが約 0.3 秒と見込まれています。ベクトル検索全体のブラウザへの応答時間は約 2.5 秒で、その内訳はベクトル検索 API の内部処理が 1.8 秒、 Web サーバーの内部処理が 0.4 秒となっています。

ベクトル DB として OpenSearch ではなく、 Amazon Aurora Serverless v2 [PostgreSQL] を採用した理由は、コストを抑えるためです。一般的に OpenSearch が多く使われますが、 Amazon Aurora Serverless v2 を利用することで費用面でのメリットが得られました。

ベクトル DB の登録処理には AWS Lambda ではなく Amazon ECS を利用しました。 Lambda は低コストですが、実行時間が 15 分という上限があり、今回の処理には 30 分以上を要するため、 ECS を選択しました。

Amazon API Gateway を介さずに、既存のバッチサーバーや Web サーバーから直接ベクトル DB を更新しなかった理由は、既存環境に過度な役割を持たせないためです。また、既存環境では PHP を使用していますが、機械学習に関連するライブラリが豊富な Python を使いたかったため、新環境で Python を用いてベクトル DB の更新を行うことにしました。

最後に、Amazon Titan Text Embedding v2 (2024 年 4 月 30 日リリース) を使用している理由は、当初予定していた Cohere Embed Model v3 Mutilingual と比較して、弊社のユースケースでは結果にほとんど差がなかったためです。さらに、 Titan Text Embedding v2 は価格が 5 分の 1 で済むというコスト面での大きな利点があります。バージニアリージョンを使用することで得られる追加のメリット (特に新機能のリリースやアップデートが多い生成 AI において最新をいち早く利用検討できる点、東京リージョンより比較的安価にサービスを利用できる点) も享受できることから、Titan Text Embedding v2 を採用しました。

生成 AI を使ってみたいという漠然としたイメージしかない状況から、AWS さんのワークショップを通じて、 Amazon Bedrock を自社プロダクトにどのように取り入れるか、アーキテクチャの検討やコスト試算に至るまで、幅広いサポートを受けることができました。

特に AWS さんに提供いただいた Python の Streamlit のアセット を活用することで、事業責任者を含めた関係者全員が、生成 AI の可能性や特性を理解しやすい環境を整えることができました。

これにより、自社プロダクトでの活用イメージが具体化し、生成 AI を用いたハピタスの課題解決策の提案が進み、議論が活発化しました。

新たな活用方法が提案された際には、 AWS さんには即座に対応する アセット を提供いただき、その場で試すことができました。

プロトタイピングから検証、本実装・動作確認、ローンチに至るまでタイムリーかつスピーディーな AWS さんのサポートがあり、おかげで短期間でのローンチを成し遂げることができました。

ベクトル検索を用いたセマンティックサーチ機能の導入により、キーワードとのマッチング精度の高い広告表示が可能となりました。

ところが、まだデータ的には期待通りの成果には繋がっていない状況です。

キーワードとのマッチング精度を追求することがゴールではなく、ユーザーが求めている結果を表示することが真のゴールなので、引き続き「検索精度の向上」を目指して、PDCA を回していきます。

本記事では、ポイントモール「ハピタス」の検索体験を向上させるために、生成 AI を活用したセマンティックサーチ機能の導入について紹介しました。従来のキーワード検索では、ユーザーが意図する広告が表示されにくいという課題がありました。これを解決するために、 Amazon Bedrock と Amazon Aurora を活用したベクトル検索を導入し、検索ワードの意味を理解して、関連性の高い広告を表示できるようになりました。

導入に際しては、 AWS さんの手厚いサポートを受け、生成 AI の可能性を関係者全員が理解できる環境を整えました。これにより、具体的な活用イメージを持つことができ、プロトタイピングからローンチまでのプロセスを迅速に進めることができました。

セマンティックサーチ機能の導入後、キーワードとのマッチング精度は向上したものの、まだデータ上では期待通りの成果には至っていません。今後も「検索精度の向上」を目指して PDCA サイクルを回し、ユーザーにとって最適な検索結果を提供することを目指していきます。