3,857 文字
ありがとうございます。ケビンさん、温かい紹介をいただき感謝します。私たちはAmperityのジョイスとカムデンです。Amperityはカスタマーデータクラウドです。世界の大手ブランドのカスタマーデータを統合し、一元化しています。本日は、OpenAIのモデルを基盤として、ブランドが複雑な顧客データを理解するためのサポートをどのように構築してきたかについてお話しします。
まず、Acme Retailのマーケター、ローレンさんのケースからご紹介します。これから年末商戦を迎えます。この時期、ブランドは顧客維持に特に注力します。ローレンさんには単純な疑問がありました。「ハイバリューな顧客は何人いるのか？」という質問です。しかし、この質問への回答は一見簡単そうに見えて、実は非常に難しいのです。
なぜこれほど難しいのでしょうか？いくつか理由があります。まず一つ目は、データが分断されているということです。Acme RetailにはPOSシステム、レガシーPOSシステム、Eコマースシステムがあります。それぞれのシステムには異なる顧客IDが存在します。顧客は異なるメールアドレスや名前、住所を使用している可能性があります。
Acme Retailでの顧客の支出額を把握することさえ非常に困難です。これはAmperityが支援できる部分です。しかし、データが統合された後でも、Acme Retailには何百もの異なるデータベーステーブルが存在する可能性があります。ロイヤルティデータベーステーブル、予測値テーブル、取引テーブルなどです。
ローレンさんが日々このデータに触れていない限り、どこから始めればよいのかを知ることは非常に困難です。さらに、データを有意義に操作するにはSQLの知識が必要です。この課題を解決するため、私たちはAmpAIを構築しました。AmpAIは非技術者向けに特化した自然言語からSQLへの変換ツールです。
このツールにより、ブランドは可視化を構築し、また顧客に関する独自のルールをエンコードしてアウトプットをカスタマイズすることができます。この点については今日はあまり時間を割きませんが、詳しく知りたい方は後ほどお声がけください。もしAmpAIをAcme Retailだけのために構築していたとしたら、それほど難しくなかったかもしれません。
コンテキストウィンドウは次第に大きくなってきています。スキーマ情報全体を取り込み、テーブルのサンプルを取り込み、質問例と返された結果を取り込むことができると想像できます。そして、コンテキストウィンドウのサイズが増加したことで、比較的単純な方法でこれを簡単に作成できるかもしれません。
しかし、AmpAIが住宅ローンの申し込み者を理解したい金融機関のために機能しなければならない場合、クレジットカードの申し込みトレンドを知りたい航空会社のために機能しなければならない場合、広告パフォーマンスについて知りたいB2Cブランドのために機能しなければならない場合、これは非常に困難な問題となります。
結局のところ、AmpAIはAmperityが対応する数百のブランドと5つ以上の業種で機能する必要があります。ここで私たちが直面する主な課題はコンテキストに関するものです。AmpAIがユーザーの質問に答え、自然言語からSQLを作成するためには、データベーステーブル、フィールド、そのフィールド内の値に関する情報が必要です。
何百もの異なる種類の非標準スキーマでAmpAIが動作しなければならないことを考えると、これは非常に困難です。さらにデータは日々変化する可能性があります。ここでカムデンに引き継ぎ、コンテキスト管理へのアプローチと、その過程での考慮事項について掘り下げてもらいます。
ありがとう、ジョイス。AmpAIの構築を始めた時、私たちは異なるブランドや業種にまたがる多様なスキーマに対して回復力を持つ必要があることを知っていました。そのため、これを機能させるにはRAGアプローチが必要だと分かっていました。しかし、ベクターDBや埋め込みを使用する代わりに、実際のSQL生成ステップの前に2つの調査ステップを追加することを選択しました。
ローレンさんの質問「ハイバリューな顧客は何人いるか？」を例に、私たちのアプローチがどのように進化したかを説明します。最初のステップは、いわば単純なアプローチでした。ユーザーの質問とデータベーススキーマを取り、GPT-4oでSQLを生成するステップに渡し、そのSQLをAmperityの内部クエリエンジンで実行します。
しかし、このユーザーの質問「ハイバリューな顧客は何人いるか？」に対しては、良い回答は得られません。なぜならGPT-4oは、あなたのビジネスやブランドにおける「ハイバリュー」の意味のコンテキストを持っていないからです。そこで、さらに何かが必要だと分かりました。最初のアプローチとして、GPT-4oを使って上位5つのテーブルをランク付けし、それらのテーブルのサンプルを取得する中間ステップを設けることにしました。
このアプローチでは、ユーザーの質問とデータベーススキーマを取り、GPT-4oに上位5つのテーブルをランク付けさせます。この場合、Customer360テーブルとUnified Loyaltyテーブルが含まれます。次に、これらをAmperityの内部クエリエンジンに渡してテーブルの行サンプルを取得し、そのすべてのコンテキストを以前のSQLの生成と実行ステップに渡します。
しかし、この場合、正しい答えは得られません。なぜなら、私たちはプラチナムとゴールドを求めていますが、上記のサンプルにはブロンズとゴールドしか含まれていないからです。そのため、これだけでは質問に答えるのに十分ではありません。
さらに何かが必要だと分かりました。そこで、最も重要なフィールドの異なる値を取得する別の調査ステップを追加しました。ユーザーの質問とデータベーススキーマを別の中間GPT-4oステップに渡し、データベーススキーマ全体で最も重要なフィールドを取得するよう依頼します。
このフィールドはCustomer360テーブルの「pclv tier」であるはずです。これをAmperityの内部クエリエンジンに渡し、そのフィールドのすべての異なる値を取得してサンプリングします。そして、それを前の調査ステップと共にSQLの生成と実行ステップに渡します。最終的なSQLの生成と実行ステップに渡される異なる値の中にプラチナムとゴールドの両方が含まれるようになったので、最終的な答えが得られます。
それは、予測顧客生涯価値層がゴールドおよび/またはプラチナムであるべきということです。そしてこれが正しい答えです。ここで、私たちの完全なアーキテクチャをまとめてみましょう。ユーザーの質問とデータベーススキーマを渡す2つの調査ステップがあります。まず、上位5つのテーブルをランク付けし、それらのテーブルから行サンプルを取得します。
次に、最も重要なフィールドを取得し、そのフィールドから異なる値をサンプリングします。そして、そのすべてのコンテキストをSQLの生成ステップに渡し、AmperityでそのSQLを実行します。では、ジョイスが製品内でのデモを行います。はい。UIと名前を結び付けてみましょう。AmpAIに2つの質問をします。
1つ目は、「ハイバリューな顧客は何人いるか？」です。2つ目は、「彼らは年末商戦時期にどんな商品を買う傾向があるか？」です。ここでは裏で2つのツール呼び出しが実行されています。異なる値のツール呼び出しと、行サンプルを取得するツール呼び出しです。予測顧客生涯価値層からプラチナムとゴールドを正しく取得しています。
そして、これらの顧客が約414,000人いることが分かります。次に、商品の売上高について質問しました。これは難しい質問です。なぜならAcme Retailには10の異なる商品分類体系があるからです。裏では行サンプルのツール呼び出しを実行しており、商品サブカテゴリを正しく取得していることが分かります。
これらの結果を解析するのは少し難しいので、今から別の質問をします。これは裏で結果をグラフ化するための別のツール呼び出しを実行します。そうすると、これらのハイバリューな顧客は年末商戦時期に靴、トップス、Tシャツ、ジーンズを購入する傾向があることがすぐに分かります。
AmpAIが私たちの顧客とAmperityの製品に与えた影響を見るのは、本当に素晴らしい経験でした。製品の使用状況を理解する方法の1つは、顧客がAmperityでデータに対して実行するクエリの数を見ることです。ここで、黄色の線はAmpAIを使用しているユーザーを表しています。
青い線は使用していないユーザーを表しています。過去3ヶ月間で、AmpAIによってAmperityで実行されるクエリの数が130%増加しました。顧客への影響は本当に劇的でした。今日は、AmpAIで直面した技術的な課題の1つを取り上げ、コンテキスト管理と、どのようにGPT-4oに適切なコンテキストを供給するかに焦点を当てました。
他にも多くの課題に直面しました。評価に関すること、カスタマイズに関することなどです。より詳しく知りたい方は、後ほどお声がけください。ありがとうございました。
コメント