生成AIを使用したインベントリの分類

ジェネレーティブAIとMongoDB Atlas Vector Search を使用して、非構造化データを在庫分類に組み込むことで、より適切な決定を行うことができます。

ユースケース: 人工知能、カタログ

業種: 製造とモバイル、小売、ヘルスケア

製品およびツール: MongoDB Atlas Database 、 MongoDB Atlas Vector Search、 MongoDB Node.jsドライバー

ソリューション概要

グローバルな自動化操作は複合的な中断に遭遇します。変動する地理的条件と料金の返却により、モデル年の移行が遅延し、重大な在庫不足が発生しました。 2025 年 6 月日現在、次のモデルエンジンは米国在庫の 3% のみで構成されています。この制約された需要を運用し、マージを保護するには、単純な財務メトリクスを超えるツールが必要です。

従来、組織は BC 分析に依存して在庫をセグメント化します。この方法では、ドル使用量のみに基づいて商品アイテムを優先します。ここでは、「カテゴリ A」が最も収益、「カテゴリC」が最も少ない階層です。単純ではありますが、このアプローチでは読み取り時間、耐久性、または廃止予定などの重要な変数は無視されます。

図の 1。在庫分類の BC 分析。

多基準インベントリ分類（MICC）では、量的データポイントを追加することでこれは改善されますが、依然として最適化カスタマーレビュー、メンテナンスログ、ソーシャルログはグローバルデータの 80% を構成していますが、従来のモデルではそれらを処理できません。このソリューションはそのギャップを埋めます。ジェネレーティブAIとMongoDB Atlas Vector Search を組み合わせることで、定性的なフィードバックを実行可能なスコアリング機能に変換します。

図の 2。非構造化データを機械学習モデルの機能に変換する。

このソリューションにより、リアクティブな在庫追跡から、予測的かつカスタマーセンターの決定行うへの移行が可能になります。 MongoDB は、次の 4 ステップのメソッドを通じて、次の生成をAIによる在庫分類を強化します。

非構造化データからベクトル埋め込みを作成して保存します。
ビジネス目的に関連する評価基準を設計して保存します。
これらの条件に基づいてデータ変換を実行するためのエージェント的なアプリケーションを作成します。
新機能を追加して在庫分類モデルを再実行します。

図の 3。生成AIを使用した在庫分類の方法論と要件。

定性基準の手動評価を自動化するだけでなく、このソリューションはデータ戦略全体を運用します。ベクトル埋め込み、メタデータ、運用データを単一のプラットフォームで統合することで、不連続なバッチする分析パイプラインのレイテンシを排除します。新しい SKU は、リリース時に処理できるため、リアルタイムの精度と増やすで大規模な製品カタログを管理できます。

参照アーキテクチャ

このアーキテクチャでは、4 ステップの方法を運用します。このソリューションは、MongoDB Atlas がデータのバックグラウンドとして機能する動的でエージェント的なワークフローに依存しています。

ベクトル埋め込みの作成と保存

製品レビュー、プロバイダーノート、サポートトランスクリプトなどの非構造化データをMongoDB Atlasに取り込みます。このテキストをベクトル化するには、埋め込みモデル（Voyage AI など）を使用します。その後、結果の埋め込みをMongoDBドキュメント内の元のソーステキストと合わせて保存します。この統合アプローチにより、インフラストラクチャの複雑さが軽減され、単一のAPIで低レイテンシのセマンティック検索を実行できるようになります。

図の 4。製品レビューは、 MongoDB Atlasにベクトル埋め込みとして保存できます。

評価基準の設計と保存

コスト削減、在庫の最小化、カスタマーエクスペリエンスの向上など、特定のビジネス目的に基づいて分類ルールを定義します。以前は、これらの目的をデータにマッピングするために大量の手動作業と深い専門知識が必要でした。現在、 AIエージェントがこのプロセスを自動化およびスケーリングしています。

エージェントは利用可能なデータとコンテキストを分析し、目的を満たす最適なパラメーターとデータソースの組み合わせを提案します。これらの動的な定義は、 MongoDBでは柔軟なJSONドキュメントとして保存されます。これにより、大規模な在庫全体に対して一貫した情報に基づいた決定を適用し、ビジネス要件の変化に即座に対応できるようになります。

図の 5。非構造化データと構造化データは、機能生成の基準を作成するためにAIエージェントによって使用されます。

エージェントアプリケーションによるデータの変換

このステップでは、2 番目のAIエージェントが在庫の実際のスコアを計算します。エージェントは製品カタログを反復処理し、 MongoDB Atlas Vector Searchを使用して、ステップ 2 で定義された基準に関連する特定のカスタマーレビューを検索します。

エージェントはこの検索セットを分析し、数値機能スコアを計算し、この新しいデータで元の製品ドキュメントをアップデートします。この機能により、データセットは量的メトリクスと数学的に同等になる定性的なインサイトでデータセットが強化されます。

図の 6。 AIエージェントがベクトル化されたレビューデータで製品の機能を強化し、新しい機能を生成します。

在庫分類モデルを再実行します

これらの新機能を MCM モデルに組み込みます。ドメインの専門家は、これらの新しいAIが生成したシグナルに重みを割り当てて、従来の財務メトリクスとバランスにすることができます。分類アルゴリズムを再実行して、在庫を、経済的値と実際のカスタマー価値の両方を反映する情報付きカテゴリに分割します。

図の 7。ドメインエクスペリエンスは重みを分散した後に分類を再実行できます。

データモデルアプローチ

MongoDBドキュメントモデルは、厳格なスキーマ制約なしにさまざまなデータ型を統合します。この機能により、増やすの複雑なデータを表現する方法が簡素化されます。次の例は、このエージェントワークフローに必要なデータ構造を示しています。

量的メトリクス

通常、orders などの在庫トランザクションには、年間ドル使用量、平均ユニットコスト、年間合計使用量、読み取り時間などの標準 MIC メトリクスを計算するために必要な未加工データが含まれています。

リレーショナルシステムでは、注文データは多くの場合、ヘッダー、明細項目、ロジックに関する複数のテーブルにフラグメント化されます。読み取りパフォーマンスを最適化し、アプリケーションロジックを簡素化するには、このデータを単一の注文コレクションに保存できます。

拡張参照パターンを使用して、注文時の商品リスト内に製品情報を埋め込みます。このアプローチでは、1 回のデータベース操作でトランザクションの完全なコンテキストを取得できます。

{
  "_id": "order_55021",
  "status": "delivered",
  "purchaseTimestamp": { "$date": "2024-05-08T16:05:31.000Z" },
  "items": [
    {
      "price": 85.00,
      "productId": "part_9921_brake_pad",
      "productName": "Ceramic Brake Pads - Front Pair"
    }
  ],
  "reviews": [
    {
      "reviewId": "rev_7721",
      "score": 5,
      "commentTitle": "Great fit",
      "commentMessage": "Arrived on time and fit perfectly on my 2020 Sedan."
    }
  ]
}

非構造化ソースから取得されたメトリクス

重要なインベントリシグナルは、メンテナンスログ、サポートチケット、カスタマーフィードバックなどの非構造化テキストに多く存在します。この例では、レビューを使用して、タイトルとメッセージ内容のベクトル埋め込みを生成し、セマンティック分析を実行することができます。

MongoDB Atlas Vector Searchを使用したハイブリッド検索を可能にするには、元のテキストフィールドと一緒にベクトル埋め込み（ embedded ）を保存します。さらに、レビュースコアなどのメタデータを使用すると、構造化フィルター（例: 、"score": 5）とセマンティッククエリ（例、「信頼性」に関するレビューを検索するなど）を組み合わせることができます。

{
  "_id": "rev_99812",
  "productId": "part_9921_brake_pad",
  "score": 5,
  "title": "Excellent durability",
  "message": "I've put 20k miles on these pads and they still look new. Much better than OEM.",
  "emb": [0.02, -0.15, 0.44, 0.12, ... ]
}

基準の定義

このソリューションにおける重要なステップは、柔軟でデータに基づく分類基準を定義することです。ハードコードされたルールに依存する代わりに、基準を基準コレクションに「知識オブジェクト」として保存します。 AIエージェントは、ビジネス目的（例）と利用可能なデータに基づいてこれらの定義を生成します。

このドキュメント構造には、重み、明示的なスコアリングスケール、データソースが含まれます。このドキュメント構造は、エージェントが在庫全体で製品を一貫して評価するために使用できるスキーマを提供します。

{
  "criteriaName": "Durability",
  "criteriaDefinition": "Measures how customers perceive the product’s durability relative to their expectations.",
  "elements": [
    {
      "name": "Expected Durability",
      "weight": 0.30,
      "description": "The level of durability customers believe the product should have based on price and category."
    },
    {
      "name": "Perceived Durability",
      "weight": 0.40,
      "description": "How customers describe the actual durability, build quality, and sturdiness after usage."
    }
  ],
  "scoringScale": [
    {
      "description": "Highly durable item that meets or exceeds expectations, strongly positive sentiment",
      "score": 1
    },
    {
      "description": "Low durability item that fails to meet expectations, negative sentiment",
      "score": 0.01
    }
  ],
  "dataSources": ["inventory", "reviews"]
}

ソリューションのビルド

この方法をアクションで示すために、チームは前述の手順で提示された概念を実行する簡単なアプリケーションをビルドしました。このデモでは、エージェント的ワークフローが運用され、従来の MIC からAI拡張分類への移行を経験できます。

GitHub リポジトリ内の完全なソースコードとドキュメントにアクセスできます。

図の 8。デモアプリケーションの高レベルのアーキテクチャ。

アプリケーションを設定し、エージェント的なワークフローを調べるには、次の手順に従います。

データベースを初期化します : MongoDB Atlasクラスターを作成し、提供されたインベントリとレビューデータをデータベースにシードします。
環境を設定する:リポジトリをクローンし、 .env.localMongoDB AtlasとAWS Red の認証情報を使用してファイルを構成し、npm run dev を使用してアプリを起動します。
従来の分析を実行する: 左側のパネルで 年間ドル使用量などの標準の量的条件を選択し、[ Run Analytics を実行 ] をクリックしてベースラインクラスを確立します。
新しい条件を定義: [ 新しい条件の追加 ] をクリックし、「カスタマーユーティリティの高い製品を特定する」などのビジネス目的を説明します。エージェントは構造化された定義とデータソースを提案します。
スコアを生成する: [ 生成 ] をクリックします。エージェントは在庫を反復処理し、非構造化データを分析し、各製品にスコアを割り当てます。
分類を微調整する: 新しい基準を選択に含め、重みを調整し、[ Run analyzer ] を再度クリックして、定性インサイトによって在庫カテゴリがどのように変化するかを確認します。

次のセクションでは、デモアプリケーションのアクションを参照してください。

図の 9。生成系AIを使用した在庫の分類

キーポイント

このソリューションは、生成系AIとドキュメントモデルの柔軟性を組み合わせて、在庫分類を最新化する方法を示します。このアーキテクチャを実装する際には、次の主要な利点を考慮してください。

非表示のインベントリ値のロックを解除します: 従来の財務メトリクスでは、テキストに含まれる重要なインサイトが欠落します。カスタマーレビューやメンテナンスログなどの非構造化データをベクトル化することで、定性的なフィードバックを定量化する機能に変換し、分類の精度を向上させます。
基準生成の自動化: 手動ルール設定は遅くて厳密ではありません。エージェント的ワークフローを使用すると、高レベルのビジネス目的に基づいて評価基準を動的に生成し、スコアを付けることができます。これにより、大規模な製品カタログ全体で専門家による決定が必要になります。
データアーキテクチャの簡素化: 不連続なシステムではレイテンシが発生します。運用データ、メタデータ、およびベクトル埋め込みを単一のMongoDBドキュメントモデルに保存することで、複雑な抽出、変換、ロード（ETL）パイプラインを排除し、新しい在庫アイテムのリアルタイム分析を可能にします。
決定の品質を強化: 金融メトリクスだけでインサイトの差が生じます。カスタマーケアと製品の信頼性スコアを統合すると、在庫値の全体的なビューが作成され、従来の BC 分析では無視される影響の高いアイテムを優先できます。

作成者

Humza Akhtar、MongoDB
Rami Pinto Prieto, MongoDB
MongoDB 、Device Jmirror

詳細

戻る

データベース操作のためのエージェントキーエージェント

自動車診断