生成AIモデル：マーチャンダイジング分析のユーザーエクスペリエンス向上
AIモデルを生成して、マーチャンダイジング分析のユーザーエクスペリエンスを向上させます
この記事では、新しい生成型AIモデル（LLM）を使用することで、ビジネスユーザーの分析プラットフォーム上での体験を向上させる方法について説明します。たとえば、小売りのマーチャンダイジングマネージャーに、自然言語を使用してリアルタイムで売上や在庫の動向を分析できるウェブアプリケーションやモバイルアプリケーションを提供するとします。
これらのアプリケーションは通常、主に一般的なタイプの分析を表示し、ユーザーがいくつかのフィルタに基づいてフィルタリングやセグメント化を行い、以下の情報を提供します：
- 売上動向
- 売り切れ率
- 在庫切れ
- 在庫の動向
これらのデータは、より詳細または粗い粒度で、ある人が事前に決定した質問に答えるものです。問題は、すべてのユーザーが同じ質問を持っているわけではないことです。また、カスタマイズレベルが非常に高くなると、解決策が巨大なものになってしまうこともあります。ほとんどの場合、情報は利用可能ですが、ウェブアプリケーションに含める時間がないのです。
過去数年間、このタイプのユーザーのニーズにできるだけ迅速に対応するために、市場には低コードのソリューションがあります。これらのプラットフォームは、いくつかの技術的な知識を必要とします。LLMモデルを使用すると、ユーザーと自然言語で対話し、彼らの質問をコードやAPIの呼び出しに翻訳することができます。これにより、迅速に価値ある情報を提供することができます。
生成型AIマーチャンダイジングプラットフォームのユースケース
マーチャンダイジングプラットフォームを強化するために、2つのユースケースを含めることができます：
1. イテレーション型ビジネス分析の質問
ビジネスユーザーがデータプラットフォーム内のデータについて反復的な質問をすることを許可し、以下の機能を備えます：
- 自然言語で質問できること。
- 対話形式であることだけでなく、ユーザーが個別に質問を保存できること。
- 回答は最新のデータに基づいていること。
2. ストーリーテリング
売上の共有に関するデータをビジネスユーザーに提供する際、ストーリーテリングは重要な要素です。これにより、理解が深まり、データが価値ある情報に変換されます。ユーザーがメトリックを解釈する必要がなく、自然言語でこの説明を得ることができれば素晴らしいです。
具体例：チャットマーチャンダイジングの設計
概要
実装は非常にシンプルなアイデアであり、ユーザーに質問を与え、どのデータサービスが情報を提供するかを知るためのLLMモデルをトレーニングします。これを行うために、アーキテクチャは以下の3つの要件を満たす必要があります：
- すべてのデータはAPIを介して公開されていること。
- すべてのデータエンティティが定義および文書化されていること。
- 標準化されたAPIレイヤーを持っていること。
次の図は、この高レベルなソリューションのアーキテクチャを示しています：
- マーチャンダイジングAIウェブプラットフォーム：チャットマーチャンダイジングを使用するユーザーを通じてVueに基づくWebチャネル。
- データサービス：データプラットフォームで利用可能なビジネスデータエンティティを消費するためのAPIレストを提供します。
- チャットマーチャンダイジングエンジン：フロントエンドとLLMサービスの間の統合を行うPythonバックエンドサービス。この場合、Open AI APIを使用しています。
- Open AI：生成型AIモデルにアクセスするためのAPIレストを提供します。
- ビジネスデータドメインとデータリポジトリ：ビジネスエンティティが利用可能なデータドメインにモデル化された、Snowflakeなどの新世代のデータウェアハウス。
このPoCでは、OpenAIサービスを使用しましたが、他のSaaSを使用することも、独自のLLMを展開することもできます。また、このユースケースでは、ビジネスデータはOpenAIサービスに送信されないため、LLMモデルが行うのは、ユーザーが自然言語で行ったリクエストをデータサービスへのリクエストに変換するだけです。
マーチャンダイジングAIウェブプラットフォーム
LLMと生成型UIを使用すると、フロントエンドの重要性が高まり、ユーザーのインタラクション方法やフロントエンドの応答方法が変わります。これにより、新たな要素である生成型AIが登場し、フロントエンドとのインタラクションを管理するために必要になります。
フロントエンドはユーザーメッセージにコンテキストを提供し、ユーザーが望む方法で応答を表示できる必要があります。このPoCでは、モデルからさまざまなタイプの応答を取得します：
テーブルに表示するデータの配列。
チャートに表示するデータの配列。
フロントエンドは、応答でモデルがどのようなものであるか、またはユーザーが何を表示したいかを知る必要があります。たとえば、ユーザーがチャートを要求した場合、フロントエンドはチャートを描画する必要があります。テーブルを要求した場合は、フロントエンドはテーブルを描画する必要があります。テストの場合はテキストを表示します（エラーが発生した場合でも、異なる方法で表示する必要があります）。
Chat Merchandise Engineの応答（バックエンドおよびフロントエンドの両方）を入力します：
これがどのコンポーネントを表示するかを決定する方法です。
このアプローチにより、フロントエンドはメッセージを構造化された形式で受け取り、データをテキスト、テーブル、チャート、または思いつくもののどれで表示するかを知ることができます。また、バックエンドにとっても非常に便利です。バックエンドはサイドチャネルのデータを取得できます。
チャートに関しては、チャートに関連するすべての設定をJsオブジェクトで構成します（どの種類のチャートでも）。したがって、PoCの次のイテレーションでは、このオブジェクトをモデルに要求し、チャートをどのように描画するか、データに最適なチャートタイプなどを教えてもらうことができます。
Chat Merchandising Engine
エンジンには非常にシンプルなロジックがあります。その責任は、フロントエンド、Open AIサービス、およびデータサービスの間のゲートウェイとして機能することです。これは、Open AIモデルがサービスのコンテキストでトレーニングされていないため、必要です。モデルがトレーニングされている場合、このエンジンに含まれるわずかなロジックは、フロントエンドサービスレイヤーに含まれるでしょう。
Open AIは、APIとの統合を容易にするためのライブラリを提供しているため、このサービスはPythonを使用して実装しました。私たちはチャット補完API（モデルgpt-3.5-turbo）を使用していますが、新機能の関数呼び出し（モデルgpt-3.5-turbo-0613）を使用することもできます。
私たちは、いくつかの例、API仕様、およびAPIの定義を含む自然言語記述でコンテキストを構成しました。
私たちはレスポンスを解析し、生成されたURLを正規表現を使用して取得しますが、他の戦略を採用することもできます。
また、モデルにURLにフラグメント（たとえば、＃chart）を追加するように要求しました。これにより、フロントエンドでユーザーが表示を期待しているものを知ることができます。
この解決策は、ユーザーがチャートという言葉を使用せずにチャートを要求する可能性があるため、ユーザーの入力内の文字列を検索するよりも優れています。モデルは、チャートの表現を使用するかどうかを決定するユーザーの質問を「理解」するからです。
最後に、データサービスへの呼び出しはフロントエンド自体から行われるため、この回答をフロントに送信します。これにより、ユーザー固有のJWTトークンを使用してデータサービスを消費することができます。
結論
過去数年間、多くの組織やチームが、アジャイルなアーキテクチャ、良好なデータガバナンス、および変化に対応するためのAPI戦略を持つことに取り組んできました。生成型AIモデルは大きなビジネス価値を提供することができ、その価値を提供するためにはほとんど努力が必要です。
私たちは、Vue3、Quasar Ui（基本コンポーネントとテーブル用）、およびEcharts（チャートの描画）を使用して、このビデオでご覧いただけるPoCを数時間で開発しました。アルゴリズムは確かに新しいトレンドであり、データ駆動型戦略の鍵でもあります。標準化されたアジャイルなアーキテクチャから始める組織は、この課題に対して先行することができます。
We will continue to update VoAGI; if you have any questions or suggestions, please contact us!
Was this article helpful?
93 out of 132 found this helpful
Related articles
