エージェント的AI、 JSONベースの標準モデル、 MongoDB Atlasを使用して支払いをモダナイゼーションし、ISO 20022、ISO 8583、Stablecoin をブリッジします。
業種: 金融サービス
製品およびツール: MongoDB Atlas、 MongoDB Atlas Vector Search、 MongoDB Atlas Search
パートナー: Amazon Bears が
ソリューション概要
現在、支払いプロセッサは相互運用性の問題に遭遇しています。レガシーカード メッセージ(ISO 8583)、最新の豊富なデータ標準(ISO 20022)、進化する暗号化支払いフィールドを処理する必要があります。従来のシステムは、新しいフィールドの表示やローカルレプリケーションの変更時に中断される厳密な抽出、変換、ロード( ETL )パイプラインに依存しています。
レガシーストラクチャと金融の将来を接続するために、 JSONネイティブの標準支払いモデルは、最新のオーケストレーションの重要な基盤となります。 ISO20022 以降の 環境では、CVR+ や Fed コマンド などのさまざまな実装で発生するセマンティックダイアレクトのフラグメント化を解決します。これにより、SUIFT で識別されるデータ切り捨てのリスクを防止できます。この場合、レガシー内部システムでは豊富な ISO20022 データが削減され、拡張フィールドを保存するためのキャパシティーが不足します。モデルは柔軟なJSON形式で完全なメッセージ深度をキャプチャするため、変換中にシステムはデータを失うことはありません。
ユニバーサルAPI抽象化と組み合わせると、このプラットフォームは不正確なバイナリ ビットマップや断片化された標準から、開発者向けの環境に移行することができます。この環境により、開発と再利用が迅速化します。インドの UPI からtablecoin までの新しい支払いフィールドは、コア コードの書き換えではなく、モジュール型の拡張機能として統合できます。
開発速度を超え、このモデルは中央化された支払いスキームと データガバナンスを確立し、新しい規制フィールドが一度定義され、すべての変換ロジックにわたって継承されるシングルポイント更新を可能にします。この移行により、厳密なSQLスキーマから柔軟なドキュメントモデルへの移行により、レガシーハブに固有の技術的耐久性とメンテナンスの負荷が排除されます。ライフサイクルの早い段階で完全に標準化された一貫性のあるデータモデルにデータを正規化することで、このモデルは早期コンプライアンスへのコミットと、移動中の修復を積極的に行います。最終的には、 暗号アセットのマーケットプレイス(MiCA) などの新しいルールの下で常に変化するマルチファイルの世界をガイドします。
次のビデオでは、クレジットプロバイダー名のエージェントによる日本語の書き換えを使用した、DB から J へのクロスフィールドの支払いの例を示します。
このソリューションは、エージェントAIを使用した標準支払いモデルが支払い処理を再定義する方法を示しています。固定的なSQLスキーマから柔軟なJSONベースの標準モデルに移行することで、金融機関はAIエージェントを強化して、匿名のトランザクションの取り込み、正規化、ルーティング、修復を行うことができます。ブロックチェーン。
JSON基礎
JSONベースのデータモデルは、次のプロパティがあるため、このようなマルチ支払いレイテンシの重要な基盤となります。
APIネイティブ: 特に MongoDB と fintex の支払い操作では、本質的にJSONベースのAPI駆動型通信(REST/ GraphQL /RPC)が使用されます。ネイティブ形式、翻訳のレイテンシと複雑さが軽減されます。
スキーマの柔軟性: JSON は、コアスキーマを中断することなく、一般的なフィールド(量、送信者)を処理すると同時に、ルール固有のフィールド(例、 、暗号化のログ制限、MongoDB の zen コード、ISO20022 のリミット情報)を調整します。
AI準備性: LM はコードとJSONで学習します。エージェントはデータ構造を直接分析できるため、異常を検出し、複雑なマッピングを
参照アーキテクチャ
この支払い処理デモには、形式ボードから実行および修復までの完全なトランザクション ライフサイクルを処理する Payment Processing プラットフォームが含まれています。アーキテクチャでは、専用コンポーネントに特定の責任を委任します。
ビルド
コンフィギュレーションビルダ: 開発中に形式のオンボードを迅速化します。集計パイプラインは既存の構成からフィールドマッピングを抽出しますが、LVM は不明なフィールドのマッピングを提案します。統合に数か月かかった新しい形式は、数週間で構成できます。構成が設定されると、プラットフォームはライブのトランザクション処理を取り扱います。
を実行する
メッセージ変換サービス: 受信メッセージは、構成ベースの処理システムを通過します。ほとんどのフィールドは、前述のビルド プロセスで構築されたMongoDBに保存されている決定的なルールに従います。リミット情報などの複雑な非構造化フィールドは、Clade によって強化されたAIプレーンにルーティングされます。
エージェント的解決サービス: トランザクションの検証に失敗したトランザクションを修復するマルチエージェント システム。スーパーバイザーはタスクを専用エージェントにルーティングします。解決エージェントは、欠落フィールドまたは無効フィールドの正しい値を検索し(データベース検索、Atlas Search、またはAI推論を使用)、実行エージェントは承認された変更を適用し、監査するログに記録します。
図の 1。 MongoDB Atlasでのメッセージ変換、標準JSONルーティング、エージェントによる解決を示す Payment Processing プラットフォームのアーキテクチャ
アーキテクチャ図に示すように、 MongoDB は操作データ層(ODL)として機能します。システムは、各トランザクションを、 正規化された標準JSONと、エージェントの決定の完全な監査する追跡を含む単一のドキュメントとして保存します。変換構成は別のコレクションに存在するため、形式の変更はデータに基づいて行われます。この構造は、 規制コンプライアンスに必要な監査可能性を提供します。
中心的機能
このデモでは、 MongoDB の柔軟なスキーマとエージェント的なAI が支払い操作を変換する 4 つの主要機能を紹介します。
データに基づくメッセージの変換
レガシー システムでは、変換ロジックがハードコードされていることがよくあります(例、「フィールド4 がフィールド32A" にマップされます)。このソリューションは、変換ルールとメタデータをデータとともにMongoDBに保存し、変換ロジックをデータ駆動型にします。
マッピングを変更するためにコードを再コンパイルする代わりに、 MongoDB内の構成ドキュメントを更新します。変換サービスはこれらのルール(パターン、フィールドマッピング、出力パスを抽出)を動的に読み取り、受信 ISO 8583 または SUIFT FT メッセージを標準のJSON形式に正規化します。
コンフィギュレーションベースの変換:
# Load config from MongoDB config = db.conversion_configs.find_one({"_id": "MT103_to_JSON"}) # Extract fields using patterns from config["extract"] for field_id, pattern in config["extract"].items(): extracted[field_id] = re.search(pattern, message).group(1) # Transform using rules from config["map"] for mapping in config["map"]: value = extracted[mapping["from"]] if "ai" not in mapping: # RULES lane output[mapping["to"]] = value else: # AI lane ai_fields.append({"value": value, "field_type": mapping["ai"]})
一部のフィールドは正規表現パターンに耐性があり、SUIFT フィールド 70 (リミット情報)など、フリーテキスト支払い目的、請求書参照、複数行にわたる指示を含めることができます。構成はこれらのフィールドをAI処理の対象とします("AI": "remitance")。また、LDM は非構造化テキストから構造化データを抽出します。このアプローチは、ほとんどのフィールドに対して決定的なルールを保持しますが、推論を通じて複雑な残りの部分を処理します。
ドキュメント挿入を通じて新しいメッセージ形式が有効になります。変換ロジックは変更されず、変換ロジックは配置サイクルから除外されます。
生成AI駆動型 適応型変換
データベースに保存されているルールと履歴メタデータでは、ジェネレーティブAI (llm)を使用して新しい支払い形式のオンボードを迅速化できます
新しいメッセージ タイプのサポートを追加するには、サンプルメッセージを提供します。アダプティブ ラーニング サービスは、 MongoDBから既存のすべての変換構成をロードし、形式固有の解析を使用してフィールドを抽出します。検出されたフィールドID を既存の構成のマッピングと照合します。例、フィールド"32A" が MD103_to_JSON に存在する場合、その正確なマッピングは再利用されます。
既存の設定にないフィールドの場合、LVM は確認して調整するマッピングを提案します。これにより、人間によるレビューや配置にすぐに対応できる配置案構成が生成されます。統合に数か月かかった支払いフィールドが、より速く使用できるようになりました。
集計と LVM によるアダプティブ ラーニング:
# Aggregation pipeline: extract field mappings from ALL existing configs pipeline = [ {"$addFields": {"extract_array": {"$objectToArray": "$extract"}}}, {"$unwind": "$map"}, {"$project": {"field_id": "$map.from", "mapping": "$map", "source_config": "$_id"}}, {"$group": {"_id": "$field_id", "mapping": {"$first": "$mapping"}}} ] field_lookup = {doc["_id"]: doc for doc in db.conversion_configs.aggregate(pipeline)} # Match detected fields against learned patterns for field_id in detected_fields: if field_id in field_lookup: matched[field_id] = field_lookup[field_id]["mapping"] else: unknown.append(field_id) # For unknown fields: LLM suggests mappings constrained by format spec suggestions = bedrock.invoke_claude(f"Map {unknown} to {target_format} fields")
集計パイプラインは、1 回のクエリですべての構成からフィールドからマッピングへの検索を構築します。既知のフィールドは即座に一致します。不明なフィールドの場合、ターゲット形式のサポートされているフィールドによって制約された LM の提案が与えられます。
エージェント的支払い修復
クロスフィールド支払いは、コードの欠落、スクリプトの誤り、組織データの不完全な作成など、ローカルのクリアリング要件により頻繁に失敗します。従来のシステムではこれらの例外は手動レビューのためにキューに入れられ、解決には 日数がかかることが多いです。
解決エージェントは、ドキュメント文字列とシステムプロンプトに基づいて LM が自律的に選択したツールを使用して、これらの例外を処理します。パターンは、LM を最初に低く、高速なオプションにガイドします。
解決エージェント ツールの選択:
from langchain_core.tools import tool from langgraph.prebuilt import create_react_agent def atlas_search(collection: str, query: str, search_fields: list, fuzzy: bool = True) -> dict: """Search MongoDB using Atlas Search. Use fuzzy=False for exact match first.""" pipeline = [{"$search": { "index": f"{collection}_search", "text": {"query": query, "path": search_fields, "fuzzy": {"maxEdits": 2} if fuzzy else {}} }}] results = list(db[collection].aggregate(pipeline)) return {"found": bool(results), "top_result": results[0] if results else None} def vector_search(collection: str, query: str) -> dict: """Semantic search using Atlas Vector Search - matches by meaning, not keywords.""" embedding = voyage_client.embed([query], model="voyage-3").embeddings[0] pipeline = [{"$vectorSearch": { "index": f"{collection}_vector", "path": "embedding", "queryVector": embedding, "numCandidates": 100, "limit": 3 }}] results = list(db[collection].aggregate(pipeline)) return {"found": bool(results), "top_result": results[0] if results else None} agent = create_react_agent(model=llm, tools=[atlas_search, vector_search])
LM は、ツールの docstring とシステムのプロンプトを読み取り、呼び出すツールを決定します。 Atlas Search は完全検索と type を許容する一致を処理します。ベクトル検索は、キーワードは一致しないが意味は一致するセマンティック分類を処理します。これらの機能を実際に説明するには、次の支払いシナリオを検討してください。
書込み保証(write concern): Atlas への支払いには 、タイプスクリプトの受信者名が必要ですが、受信メッセージにラテン文字が含まれています(例: 、ハイフン ミューラー)。エージェントは最初に
bank_detailsコレクションで既知の翻訳を確認します。見つからない場合は、Atlas Search がファジー一致を使用します。フォールバックとして、LM を呼び出して名前をカタ的な名前("HNSW」)に変換します。インド( IFSC コード検索): インドへの支払いには正しいブランチにルーティングするための IFSC コードが必要ですが、送信元は金融名と都市のみを提供します。エージェントは、完全一致を検索するために
ifsc_codesコレクションをクエリします。入力に誤字が含まれている場合(例、「Connatchplace」ではなく「SDFC Connector」)、Atlas Search はファジー一致を処理して正しいコードを検索します。
人間が実行するレビュー
単独の変更の監視が必要なリスクの高い環境で動作します。修復が適用される前に、LingGraph ワークフローは interrupt() メカニズムを使用して一時停止し、人間が承認するために変更の提案を提示します。
ユーザーには次の内容が表示されます。
元の値: 入力されたときのフィールド(例: 、"Hin ページ ミューラー")。
推奨値:エージェントが見つけた値(例、"hain リッスン、コレクション、コレクション)
理由: 使用されたツールとその理由。
その後、ユーザーは次のことが可能になります。
承認: 実行エージェントは変更を適用し、監査するログに記録します。
拒否: ワークフローは終了し、元の値は保持されます。
変更: ユーザーは修正された値を指定し、システムはその値を適用します。
このプロセスにより、完全な監査可能性が確保されます。ユーザーは実行前にすべてのエージェントの決定をレビューし、システムはすべての変更を変更前と変更後の値とタイムスタンプでログに記録します。
LingGraph HITL 実装:
from langgraph.types import interrupt def human_review_node(state: dict) -> dict: """Pause workflow for human approval.""" # interrupt() halts execution, returns data to caller, waits for resume review_decision = interrupt({ "original_value": state.get("original_value"), "proposed_value": state.get("solution", {}).get("proposed_value"), "confidence": state.get("solution", {}).get("confidence") }) # When resumed: {"approved": True/False, "modified_value": "..."} return {"approved": review_decision.get("approved"), "human_review": review_decision} # Workflow: resolution → human_review → execution workflow.add_edge("resolution", "human_review") # Always review before execution app = workflow.compile(checkpointer=MemorySaver()) # Checkpointer persists state
interrupt() 関数は のキー メカニズムです。ワークフローがこのノードに達すると、現在の状態をシリアル化し、レビュー データをAPI呼び出しラーに返し、待機します。フロントエンドはこのデータをユーザーに表示します。ユーザーが決定を送信すると、 API は決定を interrupt() の戻り値として挿入されたワークフローを再開します。
マルチファイルの拡張性: ブロックチェーン設定の例
標準のJSONモデルは、両者、アセット、金額、指示などの主要な支払い意向を単一の一貫した構造に正規化することで、複数の支払い可能性を統合するための安定した内部抽象化を提供します。 MongoDB多形ドキュメントモデルを使用すると、レイテンシ固有の実行詳細とメタデータが標準フィールドと一緒に保存され、別のスキーマやデータモデルは必要ありません。これにより、上流と下流のシステムのプロトコルの複雑さを排除すると同時に、異なる Rail で同じ支払い表現を消費できるようにします。
このパターンでは、Solana 統合によるこのパターンのアクションが示されています。暗号化解決フィールドを含む支払いは、evnet で実際の転送を実行する Solana サービスにルーティングされます。
Solana サービスの統合:
# Step 1: Convert incoming message to canonical JSON hop1_result = await converter.convert( source_format="pacs.008", # or MT103, ISO8583, etc. target_format="JSON", message=raw_message ) # Step 2: Parse the canonical JSON from conversion result canonical_json = json.loads(hop1_result['converted_message']) # Step 3: Check canonical JSON for crypto settlement fields if canonical_json.get('crypto_blockchain') and canonical_json.get('crypto_receiver_wallet'): # Route to Solana solana_service.transfer( to_pubkey=canonical_json['crypto_receiver_wallet'], amount_sol=50000 ) # step 4: Solana Service Class class SolanaService: def transfer(self, to_pubkey: str, amount_sol: float) -> dict: response = self.client.send_raw_transaction(bytes(tx)) self.client.confirm_transaction(response.value) return { "signature": str(response.value), "explorer_url": f"https://explorer.solana.com/tx/{response.value}?cluster=devnet" }
従来の支払いフィールドと違い、ブロックチェーンには支払いの組み込みの証明が用意されています。すべての転送については Solana Explorer URL が返され、ユーザーはトランザクション上のトランザクションの送信元、受信者、金額、タイムスタンプ、確認ステータスを確認します。この透過性は、支払い証明にバックオフィスの調整が必要な SUIFT またはカード ネットワークでは使用できません。
デモは、メインネットと同じプロトコルを使用する Solana evnet で実行されます。トランザクションは暗号化で署名され、検証に伝達され、永続的に記録されます。
MongoDB を選ぶ理由
MongoDB はPayment Processing Platform 全体の統合データ プラットフォームを提供し、開発(形式構成)とランタイム(トランザクション処理、エージェントの決定、監査するログ)の両方を単一のシステムでサポートします。
このプラットフォームは、いくつかの主要MongoDB機能を使用して、これらの複雑な金融ワークフローを効率化します。
スキーマの柔軟性: MongoDBドキュメントモデルは、標準の支払い形式と自然に整合します。開発者は、移行せずにデータモデルを進化させ、関連データ(標準のJSON、メタデータ、監査するログ)を 1 つのドキュメントに保存し、スキーマ競合なしでさまざまなメッセージ構造を処理できます。
型に耐性のある解決を提供するための Atlas Search:2 解決エージェントは、正確な検索が失敗した場合に Atlas Search を使用します:
セマンティック一致のための Atlas ベクトル検索 : 支払い説明を分類するためのセマンティック類似性 (例、「給与の支払い」は目的コード SALA にマップされます)は、別のベクトルデータベースなしで Atlas に構築されます。
アダプティブ ラーニングのための集計パイプライン: アダプティブ ラーニング サービスは、
$objectToArrayと$unwindを使用して、1 つのクエリですべての構成からフィールドとマッピングする検索を構築します。これにより、インスタント パターン再利用のためのデータベースレベルの処理が行われます。自動ドキュメント更新: 単一ドキュメントのアトミック性により、実行エージェントは支払いフィールドを更新し、1 回の操作で監査するログを記録できます。これは、高リスクの金融サービスにおける規制コンプライアンスのために重要です。
これらの機能により、 MongoDB はAI駆動型支払い処理用の ODL となり、最新のマルチファイル 金融の需要をサポートします。
データモデルアプローチ
MongoDB は、 支払い処理パイプラインを強化する 2 種類のドキュメントを保存します。
標準JSON (支払いドキュメント)
{ "transaction_ref": "MED-CH-ZA-2024-001", "value_date": "2024-12-15", "amount": "180000.00", "currency": "CHF", "debtor_name": "SWISS PHARMA INTERNATIONAL AG", "debtor_account": "CH9300762011623852957", "debtor_bank": "UBSWCHZH80A", "creditor_name": "SOUTH AFRICAN HEALTH SUPPLIES PTY LTD", "creditor_account": "ZA123456789012345678901", "creditor_bank": "ABSAZAJJXXX", "remittance_info": "INVOICE MED-ZA-2024-5678", "charge_bearer": "SHA" "metadata": {...} }
この平面構造は、次のマッピングを含む ユニバーサル ブリッジ として機能します。
MD103 はJSONにマッピングされ、これは cake .008 にマッピングされます。
MD202 はJSONにマッピングされ、これは cake .009 にマッピングされます。
1 つのセマンティック概念は 1 つのフィールド名と等しく、すべての形式で同じマッピングを持ちます。各ドキュメントには、処理の詳細を含む metadataオブジェクトと、すべてのエージェントの決定をログに記録する audit_trail(古い値、新しい値、使用されるツール、タイムスタンプ)も含まれています。
変換構成
システムは、 JSONによるマルチホスト変換と共通パスの直接変換の両方をサポートしています。次の例は、直接変換の構成を示しています。
{ "_id": "MT103_to_pacs.008", "extract": { "20": ":20:([^\\n:]+)", "32A": ":32A:([^\\n:]+)", "50K": ":50K:([\\s\\S]*?)(?=:[0-9])" }, "map": [ {"from": "20", "to": ["transaction_ref"]}, {"from": "32A", "to": ["value_date", "currency", "amount"], "split": [6, 9]}, {"from": "50K", "to": ["debtor_account", "debtor_name"], "multiline": true}, {"from": "70", "to": "remittance_info", "ai": "remittance"} ], "output": { "transaction_ref": "Document.FIToFICstmrCdtTrf.CdtTrfTxInf.PmtId.InstrId", "amount": "Document.FIToFICstmrCdtTrf.CdtTrfTxInf.IntrBkSttlmAmt.#text" } }
変換を定義する 3 つのセクション。
extract: 正規表現を使用してフィールドを取得します。map: それらを変換します(複合の分割、日付の形式、 AIへのルーティング)。output: ターゲット形式に値を配置します。
ドキュメント挿入により、新しいメッセージ形式が有効になり、配置サイクルから翻訳ロジックが削除されます。新しい支払い Rails では、標準モデルは ユニバーサルJSON統合点として機能することで接続を迅速化し、 の増やすを拡大しても主要ビジネス ロジックには影響しないようにします。
ソリューションのビルド
完全な実装については、 GitHubリポジトリの手順に従ってください。
支払い処理プラットフォームは、2 つのマイクロサービスで構成されています。1 つは 3 リージョンのパイプライン(開発時形式オンボード用の形式ビルダ を含む)と、LingGraph マルチエージェント ワークフローを使用して無効なトランザクションを修復する 支払いエージェント です。どちらのサービスもMongoDB Atlas をODL として共有します。
支払い変換サービスの実装
変換演算子は、ハードコードされたロジックではなくMongoDBに保存されている構成を使用して、形式間のメッセージを変換します(MD103、ISO 20022、ISO 8583)。
変換パイプラインを設定する: 複雑さ(トランザクション参照や金額などの構造化フィールドの決定的な正規表現パターン)に基づいてフィールドをルーティングするように抽出プログラムを構成します。また、リミット情報などの非構造化フィールドの場合は、 AWS Red を介した LM 呼び出しを実行します。
変換構成をMongoDBに保存します。各構成ドキュメントには、
extractmap(正規表現パターン)、 (フィールド変換)、output(ターゲット形式パス)の 3 つのセクションが含まれています。変換子は実行時にこれらを読み取ります。新しい形式の場合、コードの変更は必要ありません。出力ジェネレーターをビルドします。ビルダは変換されたフィールドを受け取り、ターゲット形式を構築します。 ISO20022 に対して、ビルダは適切な名前空間を持つ有効な XML を生成します。 JSONターゲットの場合、平面標準構造を出力します。
LongGraph で支払いエージェントを実装する
エージェントは、マルチエージェント ワークフローを使用して、 IFSC コードの欠落、誤ったスクリプト、不完全なメリット データなど、検証に失敗したトランザクションを修復します。
スーパーバイザーエージェントを作成する: このエージェントは修復タスク(例、「cridor_name)では、ポイントを検索するために解決エージェントにルーティングするか、修正が既知の場合は実行に直接ルーティングするかを決定します。
ツールを使用して解決エージェントを構築します。次の 3 つのツールを使用します。
atlas_search(完全一致またはファジー一致のデータベース検索)、vector_search(分類のセマンティック類似性)、transliterate_text(LVM ベースのスクリプト変換)。エージェントは、問題のコンテキストに基づいて使用するツールを決定します。人間のレビューチェックポイントを追加します。変更を適用する前にワークフローを一時停止するには、LearGraph の
interrupt()関数を使用します。ユーザーは、元の値、修正の提案、コンフィギュレーション スコア、理由を表示します。ワークフローが再開する前に、承認、拒否、または変更することができます。実行エージェントを実装する: 承認時に、このエージェントは修正された値を標準JSONに書込み、古い値、新しい値、使用されるツール、タイムスタンプを持つエントリを監査するログに追加します。
新しい形式のアダプティブラーニングの有効化
新しい 支払い形式をオンボードすると、システムは既存のパターンを学習して構成を自動生成します。
既存の構成をロードする: アダプティブ ラーニング サービスは、 MongoDB をすべての変換構成でクエリし、フィールドID とその標準マッピングへのマップを構築します(例、フィールド"32 A" は
value_date、 、currencyamountにマップされます)。サンプルメッセージを解析します。SUIFT8583 タグ パターン、ISO フィールド位置、XML パスなどの形式固有の抽出プログラムを使用することで、サービスは新しい形式のすべてのフィールドを識別します。
既知のパターンに一致させ、不明なフィールドを推論します。他の構成に存在するフィールドの場合、システムは正確なマッピングを再利用します。どこにも見つからないフィールドの場合、サービスは形式タイプに関するコンテキストを持つ LM を呼び出してマッピングを提案します。
構成を生成して確認します: このサービスは、すべてのマッピングを含むドラフト構成ドキュメントを出力します。システム フラグは、人間によるレビューのために信頼しきい値未満のフィールドに表示されます。承認されると、ドキュメントはMongoDBに挿入されます - 変換はそれをすぐに処理します。
キーポイント
適応型学習のための集計パイプライン:
$objectToArrayと を使用して、既存のすべての構成から 1$unwindつのクエリでフィールドをマッピングする検索を構築します。既知のフィールドは自動マッピングを受け取ります。不明なフィールドは、形式指定によって制約された LM の提案を受け取ります。タイプを許容するための Atlas Search : 正確なデータベース検索が失敗した場合、編集距離を使用したファジー検索はスペルの違いを処理します(例、「FDFC Connort」は「オプションの場所」にマップされます)は、低速のAI推論にフォールバックすることなく、エラーを処理します。
構成駆動型変換: 抽出パターン、フィールドマッピング、出力パスをアプリケーションコードではなくMongoDBドキュメントに保存します。新しい支払い形式を追加すると、配置ではなくデータベースの挿入になります。
ループ内でのコンプライアンス: LgGraph
interrupt()メカニズムを使用して、変更を適用する前にエージェントのワークフローを一時停止し、ユーザーに修正の提案を提示して、明示的な承認の後にのみ再開します。スーパーバイザー マルチエージェント パターン: IFSC ルックアップや変換などの検索タスクは、データベースツール付きの解決エージェントにルーティングされ、フィールドの更新などの実行タスクは実行エージェントにルーティングされます。これにより、焦点を当てた専門知識とよりクリーンな監査する基準が確保されます。
統合運用データレイヤー: 標準のJSON、変換構成、および監査するログをMongoDB Atlasに保存します。この一元化により、支払いフィールド間のデータサイロが排除され、エージェントが必要とする完全なトランザクション コンテキストが提供されます。
作成者
Wei You Pan、MongoDB
Kiran Tulsulkar, MongoDB
Ainhoa Múgica, MongoDB
MongoDB、 MongoDB