MongoDB Atlas のリアルタイムプロバイダー リスクを評価します。 Vyage AIを基盤としたマルチモーダル検索を使用して、代替プロバイダーを見つけます。
ユースケース: 人工知能、インテリジェント検索
業種: 小売
製品: MongoDB Atlas、 投票AI、 MongoDB自動埋め込み、 MongoDB ベクトル検索、 MongoDB Atlas Charts
ソリューション概要
グローバル サブスクライブは継続的な影響につながります。地理的条件、気象イベント、論理のボトルネックは、一意の運用継続を妨げます。
レガシー リソース プランニング(ERP)システムは、これらの迅速な変更に対応できません。彼らは重要なプロバイダー情報を厳密なリレーショナルテーブル、静的スプレッドシート、クエリ不可の PDF 契約とメール内にラップします。中断が発生すると、調達チームは 時間または 日間、切断された サイロ全体でデータを手動で収集します。この遅延は、在庫アウト、予期しないコスト、消費者信頼の損失につながります。
MongoDB Atlasで最新化された統合インテリジェンスレイヤーを構築し、レガシーERN コアからプロバイダー マネジメントを分離します。
このソリューションでは、MongoDB Atlas を集約データストア として扱います。これは、演算ストア、ベクトルストア、検索エンジン、エージェントメモリとして同時に機能する 1 つのプラットフォームです。オートメーションエージェントがライブ中断を説明する必要があるコンテキストのすべての部分(プロバイダーのロケーション、オープン購入注文、証明書、先行履歴)は、同じコレクション内で同じアクセス制御の下に 1 つのクエリを実行します。
インテリジェンス データレイヤーの上部にある次のバックエンドモジュールは、未加工の中断シグナルを検証済みの人間が承認した決定に変換します。
ingestion_engine: LM、エージェント、またはリージョン ループを使用しない決定的な正規化レイヤー。未加工の外部シグナル(地理的データ、気象、地理的データなど)を一貫した内部形式に変換し、Atlas に書込みます。これにより、すべての下流のプロセスが依存するクリーンな開始点が提供されます。risk_evaluator: ライブ プロバイダーと購入注文のデータに対してこれらのシグナルを読み取り、地理空間で露出を照合し、動的リスク優先度数(RBN)と に保存されている過去の先例を超える []エージェントは、プレーン言語リスクの概要をagent_memoryに書き戻すAtlas。
MongoDB Atlasで運用データとAI機能を統合することで、外部条件にほぼリアルタイムで対応し、ビジネスを円滑化します。
参照アーキテクチャ
エージェントがコンテキストウィンドウに達する理由を持ち、すべてを認識している理由ではありません。すべてのエージェントの決定は、事前のデータフィルタリングによって異なります。データレイヤーは、情報を最初に表示、フィルタリング、ランク付けします。 MongoDB Atlas をこの コンテキストレイヤーとして扱います。 Atlas は、エージェントが理由を説明する前に、どの証明がトークンに値するかを決定します。
ライブの中断を想定するエージェントは、地理空間一致、ベクトル検索、全文検索、再ランク付け、メモリ検索を実行します。個別のデータベース、ベクトルストア、検索エンジン間のラウンドトリップは、エージェントを遅くします。 MongoDB Atlas集計パイプライン内ですべてのクエリを実行します。 1 つのAPI がスタック全体を置き換えます。
コンテキスト制御はコスト制御でもあります。マルチエージェント システムは、単一のチャットよりも最大15 x 多くのトークンを消費します。冗長な取得により、コストが増加します。予算を管理するためにモデル コンテキストを制御します。
プロバイダー、中断シグナル、コンプライアンス証明書は常に変化します。柔軟なドキュメントモデルを使用して、このバリエーションを 1 つのコレクションに保存します。
グローバル サブスクライブ チェーンは多くの言語でエビクションを生成します。投票AI は多言語の証明を 1 つの共有ベクトル空間にマッピングし、Atlas 自動埋め込みはこれらのベクトルを同期させます。多言語検索は、外部サービスではなくネイティブのデータベースプロパティになります。
次のアーキテクチャ図と手順は、エンドツーエンドのワークフローと主要なデータベース機能の概要をまとめたものです。承認された代替プロバイダーへの未加工の外部フィードからシグナルを追跡します。
図の 1。大まかな概要
ステップ 0: 非構造化ドキュメントの取り込み
PDF、メール、契約、監査するレポートなどの未加工の非構造化ビジネス ドキュメントを、クラウドストレージからMongoDB Atlasに直接ストレージ。 MongoDB AIマルチモーダル埋め込みモデルは、任意の言語の チャンク ドキュメントを自動的に埋め込み、安全なデータベース内のマルチモーダルおよび多言語検索を可能にします。
ステップ 1: ERN からの解放
ERN はビジネス ルールを強制し、トランザクション ワークフローを所有します。これらのルールは ERI に残ります。変更データキャプチャ(CDC)を通じてプロバイダーと注文データを Atlas にストリーミングし、ERP を直接クエリするのではなく、エージェントがそのコピーから読み取れるようにします。
切り離により、新しい機能が独自のタイムラインで ERN を超えて起動することができます。
ステップ 2 — 3: 外部リスクシグナルの取り込み
実稼働データを 運用データレイヤーに取り込みます。この外部リスク データは、MongoDB Server が提供するデータベース、API データベース、ノードを認証する認証局(NOOA)、グローバル ニュース フィードなどのソースから収集されています。このソリューションでは、取り込みエンジンはフローを初期化するためにセッションごとに 3 つのデモトリガーシグナルを生成します。
取り込みエンジンを通じて未加工の外部シグナルを処理します。このエンジンは、外部での中断イベントを正規化された内部ビジネス言語に変換し、構造化されたシグナルをMongoDB Atlasに書き込みます。
ステップ 4: プロバイダーのリスク評価(リスク評価エージェント)
正規化された シグナルがMongoDB Atlasに配置されたときに、リスク評価エージェントをトリガーします。エージェントは運用データとagent_memory を読み取り、地理空間マッチング($geoWithin )を実行し、動的 RBN を計算し、評価をデータベースに書き込みます。
ステップ 5: 代替プロバイダーの検出(代替オプションのプロバイダー検索エージェント)
マネージャーが影響を受けるプロバイダーを選択したときに、 advanced_findエージェントをアクティブ化します。エージェントは、マルチモーダルベクトル検索、ハイブリッド検索($rankFusion )、およびネイティブ 再ランク付け( $rerank )を使用してドキュメントチャンクをクエリして、準拠する代替プロバイダーを見つけ、候補オプションをMongoDB Atlasに書き込みます。
ステップ 6: メモリを増やす
risk_evaluator は、各中断を 動的リスク優先度数(RBN) でスコア付けします。エージェントがスコアを確定する前に、メモリがそのスコアに直接フィードされます。
評価ごとに agent_memory を 2 回クエリします。1 回はプロバイダー自体の履歴を、1 回はリスクタイプの前のクロスプロバイダーに対して 1 回です。 alternative_finder は、ソース側で同じロジックに従います。候補者の追跡レコードを確認し、候補者をランク付けする前に類似プロバイダーからセマンティック プレ例をプルします。
Atlas は両方のメモリ構造をネイティブに処理します。メモリには、構造化ファセット(「これが正確に発生した」)とセマンティック類似性(「このようなことが発生しました」)の 2 つの形式があります。ほとんどのアーキテクチャでは、これらを 2 つのシステムに分裂。1 つはファセット のデータベースで、1 つの類似性をベクトルストアします。 Atlas では、1 つのコレクションに両方が保持されます。構造化フィールドと埋め込みテキストは並行して存在するため、正確な find クエリと $vectorSearch クエリは同じドキュメントにヒットします。
インテリジェント アイテム ハブ ワークフロー
次のスキームの図は、中断中にシステム レイヤー全体で制御がどのように移動されるかを示しています。
図の 2。連鎖リスク分析ワークフロー
外部リスク シグナルが到達すると、ingestion_engine はそれらをMongoDB Atlasに正規化し、risk_evaluatorエージェントをトリガーしてプロバイダー リスク スコアを自動的に計算します。その後ワークフローは 最初の人間による決定点で一時停止されます。ここで、調達マネージャーはフラグ付きのリスク スコアを確認し、影響を受けるプロバイダーを選択します。これにより、alternative_finderエージェントが有効になり、 MongoDB Atlasから置換候補を検索、監査する、再ランク付けします。最後に、2 番目の 人間の決定点で、マネージャーは事前に表示され、代替のプロバイダーを承認するために提供されたコンプライアンスドキュメントをレビューします。これにより、サイジングされたシステム、ファイル形式、外部言語にわたる手動検索が排除されます。
インデータベース マルチモーダルと多言語インテリジェンス
グローバル サブスクライブ チェーン マネジメントでは、複数言語で記述された PDF 契約、トランザクション、コンプライアンス証明書、監査するレポートなどの非構造化されたマルチ形式のビジネス ドキュメントを検索する必要があります。
MongoDB Atlas は、 Voyage AIマルチモーダルベクトル埋め込みを運用データと直接保存することで、この複雑さを処理し、検索できないドキュメントサイロに残る重要なコンプライアンスに関するインサイトを表示します。
Atlas の自動埋め込み
PDF 契約、スキャンされた監査するレポート、トランザクション契約などの非構造化プロバイダーコンプライアンスレコードと契約を、 MongoDB Atlasに保存します。
autoEmbedドキュメントチャンクへの自動埋め込みを有効にするには、 タイプのベクトル検索インデックスを作成します。これにより、構成された MongoDB AIモデルを使用して、データの挿入または更新時にベクトル埋め込みが自動的に生成されるようになります。
db.suppliers.createSearchIndex( "suppliers_autoembed_index", "vectorSearch", { fields: [ { type: "autoEmbed", modality: "text", path: "auto_embed_text", model: "voyage-4" }, { type: "filter", path: "region" }, { type: "filter", path: "product_categories" }, { type: "filter", path: "status" } ] } );
自動埋め込みにより、外部埋め込みサービスと複雑なETLパイプラインが排除されると同時に、 MongoDB Atlasセキュリティ境界内にデータを安全に保持できます。
図の 3。リスク評価エージェント
集計パイプライン、検索機能、柔軟なドキュメントモデルを活用して、これらのチャンクに対して高度なクエリを実行し、取り込まれたデータのコンプライアンス検証を実行します。
マルチモーダル埋め込み検索と取得
MongoDB Atlasに保存されているドキュメントチャンクで、ハイブリッド検索を使用して非構造化データをクエリします。中断中に代替パートナーを見つけるために、 動的検索クエリーを作成します。リージョン プレフィルター を 詳細なセマンティッククエリ文字列と組み合わせます。例、有効な品質認証と緊急デリバリー コミットメントを持つ、明確に表示されない表示条件
この検索は、単一のMongoDB Atlas集計パイプラインで実行します。 $rankFusion ハイブリッド検索を使用して、ベクトル類似性と全文検索の関連性をマージします。このハイブリッド クエリは、セマンティック 概念と正確なキーワードを同時に一致させます。
取得の精度を向上させるために、Voyage AI再ランク付けモデルを使用して統合後にネイティブ再ランクステージ($rerank )をチェーンします。インデータベース クロスエンコードは、クエリとともに候補チャンクを評価し、関連性スコアを正確に計算します。パイプライン内で機密プロバイダーのレコードをデータベース境界内に安全に保持します。
図の 4。代替検索プロバイダー エージェント
多言語インテリジェンス
カスタム翻訳パイプラインを構築せずに、グローバルプロバイダーのドキュメントを任意の言語で検索および分析できます。 MongoDB AI多言語モデルは、異なる言語のテキストを共有ベクトル空間にマッピングします。
アラビア語、スペイン語、中国語、またはベトナム語で記述された関連する契約や証明書を取得するには、データベースを英語でクエリします。これらの多言語埋め込みをMongoDB Atlasにネイティブに保存すると、ほぼゼロのレイテンシで複数言語のセマンティック検索が実行されます。
グローバル プロバイダーのドキュメントを単一の多言語検索インデックスに統合すると、国際コンプライアンスワークフローが簡素化され、翻訳オーバーヘッドが排除されます。
データモデルアプローチ
厳密なデータベースでは、互換性のないデータ形式を強制的に平面テーブルにします。実稼働環境のサブスクライブ チェーン エンティティは常に変化し、不規則に進化する構造をしています。柔軟なドキュメントネイティブスキーマにより、データモデルをビジネス 速度で変化させることができます。操作レコード、ベクトル埋め込み、座標を単一のAPIの下にネイティブに保存します。厳密なデータベース移行の開発ダウンタイムを回避します。
このソリューションでは、8 つのコレクションを使用してリスクと代替ソースを管理します。
コレクション名 | 目的 |
|---|---|
| は、TTL 期限切れのライブ外部リスク シグナルをキャプチャします。 |
| 静的障害モードと影響分析(FSEA)リスク スコアとしきい値をエンコードします。 |
| GeoJSON ロケーションとともにマスター プロバイダー レコードを保存します。 |
| アクティブな注文を追跡して、財務エクスペリエンスを定量化します。 |
| チャンク化された自動埋め込みプロバイダーと証明書を保持します。 |
| コンテキストに応じた学習のために履歴エラーを保存します。 |
| 動的な RBN スコアと自然言語のリスク サマリーを格納します。 |
| 人間の承認を保存するまで、ランク付けされた候補者のショートカットを永続化します。 |
ドキュメントモデルの完全な概要については、 ソリューションのバックエンドREADME を参照してください。 コレクションとexternal_conditions supplier_documentsコレクションを調べて、ドキュメントモデルの利点を調べます。
external_条件
external_conditionsコレクションは、正規化された中断を保存する実際のリスク アラートのエントリ点として機能します。固定のスキーマを強制することなく、異なるリスクタイプが同じコレクション内に共存します。
以下は、すべてのリスク アラートで共有されるドキュメントのフィールドです。
{ "condition_id": "COND-20260505-0941", "risk_type_triggered": "logistics_disruption", "condition_score": 0.76, "has_physical_location": true, "detected_at": "2026-05-05T09:41:00Z", "valid_until": "2026-05-08T09:41:00Z" }
クライアントとログのアラートは、物理的な場所の正確な座標を保存し、半径に影響。データに対して地理空間クエリを実行するには、座標が GeoJSON ポイントオブジェクトである必要があります。 $GeoWithin を使用して、指定された影響を受けるエリア内に完全に存在するプロバイダーを検索します。
{ // other shared fields "epicentre": { "type": "Point", "coordinates": [114.1095, 22.5229] }, "impact_radius_km": 80, "has_physical_location": true, }
地理的アラートは、影響を受けるリージョンの配列を持つリージョン境界を追跡します。影響を受けるリージョン内のプロバイダーをクエリするには、 $in 演算子を使用します。
{ // other shared fields "affected_regions": ["CN", "HK"], "has_physical_location": false, }
ingestion_engine は、さまざまな受信APIペイロードを、前述のコード例に示すクリーンなドキュメント構造に正規化します。
多形データを使用すると、両方のシグナル タイプを同時にクエリできます。単一のデータベース呼び出しで $geoWithin と $in を使用して統合地理一致クエリを実行この統合により、アプリケーションロジックが簡素化され、パフォーマンスを低下させるクエリの分割が発生するのを防ぎます。
provider_documents
supplier_documentsコレクションには、検索可能な非構造化ビジネス ドキュメントが保存されています。次のドキュメントサンプルは、このコレクションのレイアウトを示しています。
{ "supplier_id": "SUP-882", "doc_type": "quality_certification", "filename": "certificado_SUP882_2024.pdf", "chunk_index": 2, "chunk_total": 4, "chunk_text": "ISO 9001:2015 and IATF 16949:2016. Valid 2024-11-01 to 2027-10-31...", "page_ref": 1, "valid_until": "2027-10-31T00:00:00Z", "embedding": [/* 1024 dimensions */] }
chunk_text: 未加工の PDF ファイルから 400 から 600 トークンのテキスト セグメントを保存します。この 高忠実度の チャンク化 では、大規模な契約が重複するセグメントに分割され、重要な句が保持されます。運用データベースのレコードと一緒にネイティブに保存された非構造化ドキュメントコンテンツを保持します。embedding: Boyage AIによって生成された 1024 次元ベクトルを保存します。多言語モデルは、複数の言語を単一の共有ベクトル空間にマッピングします。この整合性により、英語の検索文字列を使用してスペイン語またはドイツ語のドキュメントをクエリできます。valid_until:コンプライアンス認証の有効期限を追跡して、古いプロバイダー レコードを自動的に期限切れにします。
ソリューションのビルド
エージェントとしてのプライマリ チェーンのリスク ソリューションを配置します。
前提条件
開始する前に、次のアカウント、キー、ソフトウェアがあることを確認してください。
MongoDB Atlasアカウント: Atlas クラスター(M10 階層 以上)。
アナライザAPIキー: LM の理由付けとプランニングを強化するためのアクティブなAPIキー。
Docker Desktop:フロントエンドサービスとバックエンドサービスを実行するために必要なアプリケーション。
データベースの構成とシード
データベースを設定し 、シードファイルをインポートし、デモを実行するために必要なインデックスをビルドします。
MongoDB Atlasにログインし、Atlas retail-supply-chain-riskクラスターに という名前のデータベースを作成します。
dos/setup/collections フォルダーから 5 つのシードJSONファイルをインポートします。
Collections 画面で新しいデータベースを選択します。
プラス(+)アイコンをクリックするか、Create Collection をクリックして 5 つのコレクションをそれぞれ追加します。
各コレクションを選択し、Import Data をクリックして、それぞれのJSONファイルをアップロードします。
ベクトル検索、ハイブリッド検索、地理空間クエリの実行に必要な地理空間インデックスと検索インデックスを作成します。インデックス構成は、docs/setup/indexs フォルダーにあります。各インデックスを作成するには、次の手順を実行します。
mongosh "<your-connection-string>" --file suppliers-location-2dsphere.js mongosh "<your-connection-string>" --file external_conditions-epicentre-2dsphere.js mongosh "<your-connection-string>" --file suppliers_autoembed_index.js mongosh "<your-connection-string>" --file agent_memory_autoembed_index.js mongosh "<your-connection-string>" --file supplier_documents_vector_index.js mongosh "<your-connection-string>" --file supplier_documents_fulltext_index.js
リポジトリのクローンと環境変数の構成
GitHub からプロジェクトリポジトリをクローンします。
git clone https://github.com/mongodb-industry-solutions/retail-supply-chain-management.git
フロントエンドとバックエンドの環境変数を設定します。
サンプルフロントエンド/EXAMPLE.env を、同じディレクトリ内の新しい
.envファイルにコピーします。プレースホルダー値を構成の詳細で置き換えます。 を に設定します。BACKEND_URLhttp://127.0.0.1:8000サンプルバックエンド/.env をコピーします。 (例: 同じディレクトリ内の新しい
.envファイル)プレースホルダー値を構成の詳細で置き換えます。 App Services APIキーをLLM_API_KEYとして追加します。
アプリケーションのビルドと起動
Docker Compose を使用するか、バックエンドとフロントエンドを個別に実行中てマルチサービス環境をコンパイルして起動します。
Docker Compose を使用してアプリケーションを起動するには、次のコマンドを実行します。
make build
サービスを手動で実行するには、まずフロントエンドを起動します。
cd frontend npm i npm run dev
次に、ルートディレクトリに移動し、バックエンドを起動します。
make uv_init make uv_sync source backend/.venv/bin/activate cd backend uvicorn main:app --reload
ブラウザでフロントエンドダッシュボードをhttp://localhost:3000 で開きます。インタラクティブAPIドキュメントについては 、 http://localhost:8000 /docs を参照してください。
図の 5。インテリジェント プロバイダー ハブ システム
キーポイント
このソリューションは、 AI駆動型のサブライ アプリケーションを構築するためのいくつかの重要なアーキテクチャ パターンを示しています。
コストを制御するための統合インテリジェンスレイヤーの構築: MongoDB Atlasで 統合インテリジェンスレイヤー を作成し 、厳格なレガシーシステムからプロバイダー マネジメントを排除します。 CDC を使用して EHP からのデータを同期することで、運用データ、ベクトル埋め込み、およびエージェントメモリを 1 つのプラットフォームに統合します。この構造により、エージェントは ERI を直接クエリせずに現在の状態を読み取ることができます。操作チェックと取得のために同じドキュメントを読み取り、LM がデータを受信する前に地理空間フィルター、ハイブリッド検索、再ランク付けを使用してデータを決定的に絞り込みます。モデルに到達するものを制御すると、理由付けパフォーマンスが最適化され、実行コストが削減されます。
複数言語の非構造化データを統合: PDF 契約、メール、スキャンされた監査するレポートなどの非構造化ドキュメントを、構造化プロバイダー レコードと一緒に保存します。投票AIを使用して、これらのさまざまな形式を単一のMongoDBコレクションに埋め込みます。この統合により、テキストとイメージに対するセマンティック クエリが可能になり、別個のデータベースシステムを維持することなく検索アーキテクチャが簡素化されます。さらに、マルチモーダル埋め込みモデルにより、翻訳オーバーヘッドのない複数言語クエリが可能になります。
Atlas 内で検索と再ランク付けを行う:ベクトル検索、全文検索、ネイティブの再ランク付けを 1 つのデータベースクエリに統合します。
$rankFusion$rerankを使用してハイブリッド検索を実行し、集計パイプライン内で直接 MongoDB AIとネイティブ をチェーンします。これにより、余計なネットワーク コスト、 APIレイテンシ、カスタム認証情報管理が排除されます。
作成者
Florencia Arin, MongoDB
Angie Guemes, MongoDB
MongoDB 、ロナン コンロール
MongoDB、 MongoDB