Join us at MongoDB.local London on 7 May to unlock new possibilities for your data. Use WEB50 to save 50%.
Register now >
Docs Menu
Docs Home
/

エージェント型 AI を活用した決済オーケストレーション

決済をエージェント型 AI、JSON ベースの標準型モデル、MongoDB Atlas で最新化して、ISO 20022、ISO 8583、Stablecoins をつなぎます。

ユースケース: 人工知能決済

業種: 金融サービス

製品およびツール: MongoDB AtlasMongoDB Atlas ベクトル検索MongoDB Atlas 検索

パートナー: Amazon BedrockLangChainLangGraph

今日の決済処理業者は、相互運用性の問題に直面しており、レガシーカードメッセージ(ISO 8583)、最新のリッチデータ標準(ISO20022)、進化する暗号決済レールに対応する必要があります。従来のシステムが依存する抽出、変換、ロード(ETL)パイプラインは柔軟性に欠けており、新しいフィールドが現れたり、地域の規制が変更されたりすると壊れてしまいます。

レガシーインフラと未来の金融をつなぐために、JSONネイティブの標準的な支払いモデルは、最新のオーケストレーションに不可欠な基盤として機能します。ISO 20022 以降の環境では、CBPR+ や FedNow などのさまざまな実装で見られる意味論的方言の断片化を解決します。拡大されたフィールドを保存するキャパシティーがなく、豊富な情報を含んだ ISO 20022 データを取り除くレガシー内部システム、SWIFTが特定するデータの切り捨てを防止します。このモデルは、柔軟な JSON 形式でメッセージの完全な深さを捉えるため、システムは翻訳中データを失うことはありません。

汎用 API 抽象化と組み合わせることで、プラットフォームは IT チームが不透明なバイナリビットマップと断片化された標準から離れ、開発者に優しい環境に移行するのを可能にします。この環境では、インドの UPI からステーブルコインまで、新しい支払いレールをコアコードのリライトではなくモジュラー式拡張機能として統合できるので、開発を再利用の加速化が可能になります。

開発速度に加えて、このモデルは一元化された支払いスキームとデータガバナンスを確立し、新しい規制フィールドを一度定義すると、すべての変換ロジックに継承されるという単一データの更新を可能にします。この厳格な SQL スキーマから柔軟なドキュメントモデルへの移行は、レガシーハブに特有の技術的負債とメンテナンスの負担を排除します。ライフサイクルの早い段階でデータを真に標準化されたコンシステントなデータモデルに正規化することで、このモデルは早期のコンプライアンスエンゲージメントと、稼働中の説教的な修復を促進します。最終的に、暗号資産市場規制(MiCA)などの新たな規制の下で絶えず進化するマルチレールの世界を乗り切るために欠かせない、明確な管理責任と運用上の俊敏性を得ることができます。

次のビデオは、ドイツから日本へのクロスボーダー決済の例で、エージェントを活用して債権者名を日本のカタカナに音訳しています。

このソリューションは、エージェント型AIを用いた標準的な決済モデルが、決済処理を再定義する方法を示しています。柔軟性に欠ける SQL スキーマから柔軟な JSON ベースの標準モデルに移行することで、金融機関は AI エージェントに、パブリックブロックチェーンで SWIFT 送金や USDC 送金などのペイメントレールのトランザクションを自律的に取り込み、正規化し、修復する権限を与えることができます。

JSON ベースのデータモデルは、以下のような理由で、このようなマルチペイメントレール処理システムにとって重要な基盤となります。

  • API ネイティブ: 特に暗号資産とフィンテックの現代的な決済方法では、本質的に JSON ベースの API 駆動型通信(REST/GraphQL/RPC)が使用されます。ネイティブ形式を使用することで、翻訳のレイテンシと複雑さを軽減できます。

  • 柔軟なスキーマ: JSON は、コアスキーマを中断することなく、一般的なフィールド(金額、送金者)を処理しながら、レール固有のフィールド(例: 暗号資産のガスリミット、日本の Zengin Code、ISO 20022の送金コード)に対応します。

  • AI 即応性: LLM はコードと JSON で学習します。エージェントはデータ構造を直接分析し、不透明なバイナリビットマップや厳格な SQL テーブルよりも効果的に異常を検出し、複雑なマッピングを実行します。

この支払い処理のデモには、形式のオンボーディングから実行および修復まで、トランザクションの完全なライフサイクルを処理する支払いプロセシングプラットフォームが含まれています。このアーキテクチャは、専用コンポーネントに特定の責任を委任します。

  • コンフィギュレーションビルダ: 開発中の形式オンボーディングを高速化します。集計パイプラインは既存の構成からフィールドマッピングを抽出しますが、LLM は未知のフィールドのマッピングを提案します。以前は統合に数か月かかっていた形式が、数週間で構成できます。構成が設定されると、プラットフォームはライブのトランザクション処理に対処します。

  • メッセージ翻訳サービス: 受信するメッセージは、構成に基づいた処理システムを経由します。ほとんどのフィールドは、前述のビルドプロセスで構成され、MongoDB に保存されている決定論的ルールに従います。送金情報などの複雑な非構造化フィールドは、Claude を活用する AI レーンにルーティングされます。

  • エージェント型問題解決サービス: 検証に失敗したトランザクションを修復するマルチエージェントシステム。スーパーバイザーはタスクを専門のエージェントにルーティングします。問題解決エージェントは欠落したフィールドまたは無効なフィールドの正しい値を(データベース検索、Atlas Search、または AI 推論を使用して)探し、実行エージェントは承認された変更を適用し、監査証跡を記録します。

MongoDB Atlas を使用したメッセージ変換、標準 JSON ルーティング、エージェント型解決を示す支払い処理プラットフォームのアーキテクチャ

図 1. MongoDB Atlas を使用したメッセージ変換、標準 JSON ルーティング、エージェント型解決を示す支払い処理プラットフォームのアーキテクチャ

このアーキテクチャ図に示すように、 MongoDB はオペレーションデータレイヤー(ODL)として機能します。システムは、各トランザクションを、正規化された標準 JSONと、エージェントの決定の完全な監査証跡を含む単一のドキュメントとして保存します。変換構成は別のコレクションに存在し、形式の変更はデータに基づいて行われます。この構造は、規制コンプライアンスに必要な監査可能性を提供します。

このデモは、 MongoDB の柔軟なスキーマとエージェント型 AI が支払い操作を変換する4つのコア機能を示しています。

レガシーシステムでは多くの場合、翻訳ロジックがハードコーディングされています(例: 「フィールド 4 をフィールド 32A にマッピング」)。このソリューションは、翻訳ルールとメタデータをデータと一緒に MongoDB に保存して翻訳ロジックをデータ主導型にします。

コードを再度コンパイルしてマッピングを変更する代わりに、MongoDB の構成ドキュメントを更新します。コンバーターサービスは、これらのルールを動的に読み取り、パターン、フィールドマッピング、出力パスを抽出して、受信した ISO 8583 または SWIFT MT メッセージを標準的な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"]})

一部のフィールドは、SWIFT フィールド70 (送金情報) のように、自由記述の支払い目的、請求書参照、複数行に及ぶ指示などを含むことができる正規表現パターンに抵抗します。この構成はAIプロセシング(「ai」: 「remittance」)向けのこれらのフィールドをマークし、LLM は非構造化テキストから構造化データを抽出します。このアプローチで、ほとんどのフィールドの決定論的ルールを維持しますが、残りの複雑なフィールドは推論を使って処理します。

新しいメッセージ形式はドキュメント挿入を通じて有効になります。変換コードは変更されず、翻訳ロジックは配置サイクルから除外されます。

データベースに保存されているルールと履歴メタデータを使用して、生成系AI(LLMs)で新しい支払い形式のオンボーディングを加速できます。

新しいメッセージタイプのサポートを追加するには、サンプルメッセージを提供します。アダプティブラーニングサービスは、既存の変換構成をすべて MongoDB から読み取り、形式固有の解析を使用してフィールドを抽出します。検出されたフィールド ID を、既存の構成からのマッピングと照合します。たとえば、フィールド「32A」が MT103_to_JSON に存在する場合、そのマッピングをそのまま再利用します。

フィールドが既存の構成に存在しない場合、LLM はレビューまたは調整が必要なマッピングを提案します。これにより、人間によるレビューと配置に対応できる構成の下書きが生成されます。これで、統合に数か月かかっていた決済レールを、より迅速に導入できます。

集計とLLMを用いた適応型学習:

# 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つのクエリですべての構成のフィールドからマッピング検索をビルドします。既知のフィールドは即座にマッチングされます。未知のフィールドは、対象の形式のサポートされているフィールドによって制約された LLM の提案を取得します。

クロスボーダー決済が頻繁に失敗するのは、コードの欠落、間違ったスクリプト、不完全な組織データなど、各国の当局が定める決済要件が原因です。従来のシステムでは、このような例外は手動レビューのキューに入れられ、解決に数日かかることがよくあります。

問題解決エージェントは、LLM がドキュメント文字列とシステムプロンプトに基づいて自律的に選択するツールを使用して、これらの例外を処理します。このパターンは、LLM をまずより安価で高速な選択肢へと誘導します。

問題解決エージェントのツール選択:

from langchain_core.tools import tool
from langgraph.prebuilt import create_react_agent
@tool
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}
@tool
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])

LLM は、どのツールを呼び出すかを決定するために、ツールのドキュメント文字列とシステムプロンプトを読み取ります。Atlas Search は、完全一致の検索と誤字に強いマッチングを処理します。ベクトル検索は、キーワードが一致せず意味が一致するセマンティック分類を処理します。これらの機能を実際に示すために、次の支払いシナリオを検討します。

  • 日本(カタカナ音訳): 東京への支払いでは、受取人名のカタカナ表記が必要ですが、受信するメッセージにはラテン文字が含まれています(例: Heinrich Mueller)。エージェントはまず、bank_details コレクションに既知の翻訳があるかを確認します。見つからない場合は、Atlas Search でファジーマッチングを実行します。フォールバックとして、LLM を呼び出し、名前をカタカナに音訳します(「ハインリッヒ・ミュラー」)。

  • インド(IFSCコード検索): インドへの支払いには、正しい支店にルーティングするための IFSC コードが必要ですが、送金者が提供するのは銀行名と都市名のみです。エージェントは完全に一致させるために、ifsc_codes コレクションをクエリします。入力に誤字が含まれている場合(例: 「HDFC Connaught」ではなく「Connaught Place」)、Atlas Search はファジーマッチングを照合して正しいコードを見つけます。

銀行は、自律的な変更に対して監視が必要な高リスクの環境で運営されています。修復が適用される前に、LangGraph ワークフローは interrupt() メカニズムを使用して一時停止し、変更の提案を提示して人間の承認を受けます。

ユーザーには以下が表示されます。

  • 元の値: 受信時のフィールド(例: 「Heinrich Mueller」)。

  • 提案された値: エージェントが発見したもの (「ハイン リッヒ・ミュラー」)。

  • 理由: 使用されたツールとその理由。

その後、ユーザーは次のことが可能になります。

  • 承認: 実行エージェントは変更を適用し、監査証跡にそれを記録します。

  • 拒否:ワークフローは終了し、元の値は保持されます。

  • 変更: ユーザーが正しい値を入力し、システムがそれを適用します。

このプロセスは完全な監査可能性を保証します。ユーザは実行前にすべてのエージェントの決定をレビューし、システムは変更前と変更後のすべての値とタイムスタンプを記録します。

LangGraph 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 の多様なドキュメントモデルを使用すると、レール固有の実行詳細やメタデータは、別途スキーマやデータモデルを必要とすることなく、正規のフィールドと一緒に保管されます。これにより、プロトコルの複雑さを上流および下流のシステムから排除するとともに、異なるレールが同じ表現を用いることができます。

このデモでは、Solana 統合を使用したアクションのこのパターンが示されています。クリプト決済フィールドを含む支払いは、DevNet で実際に送金を行う 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 が返され、ユーザーはトランザクションのオンチェーン送金者、受取人、金額、タイムスタンプ、確認ステータスを検証できます。この透明性は、決済の証明にバックオフィスの調整が必要な SWIFT やカードネットワークでは利用できません。

デモは、メインネットと同じプロトコルを使用する Solana evnet で実行されます。トランザクションは暗号技術を用いて署名され、検証者に伝達され、永続的に記録されます。

MongoDB は支払い処理プラットフォーム全体の統合データプラットフォームを提供し、開発(形式構成)とランタイム(トランザクション処理、エージェントの決定、監査証跡)の両方を単一のシステムでサポートします。

このプラットフォームは、MongoDB のいくつかのコア機能を使用してこれらの複雑な金融ワークフローを合理化します。

  • スキーマの柔軟性: MongoDB の document model は、標準的な支払い形式に自然に適合します。開発者は、移行を行わずにデータモデルを進化させ、関連データ(標準的な JSON、メタデータ、監査証跡)を1つのドキュメントに保存し、スキーマの競合を起こさずに多様なメッセージ構造を処理できます。

  • Atlas Search for Typo-Tolerant Resolution: 問題解決エージェントは、正確な検索が失敗した場合に Atlas Search を使用します。Atlas Search は編集距離が最大2のタイプミスを許容し、複数フィールドにわたる複合クエリを生成し、外部の検索インフラが不要です。

  • Atlas Vector Search for Semantic Matching: 正確なテキストを超えた分類。意味的類似で支払い説明(例: 「給与の支払い」は目的コード SALA にマップされます)を分類し、個別のベクトルデータベースを使用せずに Atlas にビルドされます。

  • アダプティブラーニング向け集計パイプライン: アダプティブラーニングサービスは、$objectToArray$unwind を使用して、パターンを即座に再利用するためにデータベースレベルで処理する1つのクエリで、すべての構成からフィールドからマッピング検索をビルドします。

  • ドキュメントの自動更新: 単一ドキュメントのアトミック性は、実行エージェントが1回の操作で支払いフィールドを更新し監査証跡をログするのを確実にします。これは、高リスクの金融サービスの規制遵守において非常に重要です。

これらの機能により、 MongoDB はAI活用型支払い処理向けの ODL となり、現代のマルチレール金融の需要をサポートします。

MongoDB は、支払い処理パイプラインを強化する2種類のドキュメントを保存しています。

1
{
"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": {...}
}

この平面構造は、以下のマッピングを含むユニバーサルブリッジとして機能します。

  • MT103 は JSON にマッピングされ、JSON は pacs.008 にマッピングされます。

  • MT202 は JSON にマッピングされ、JSON は pacs.009 にマッピングされます。

1つのセマンティック概念は1つのフィールド名と等しく、すべての形式で同じマッピングを持ちます。各ドキュメントには、プロセシングの詳細を含む metadata オブジェクトと、すべてのエージェントの決定(古い値、新しい値、使用されたツール、タイムスタンプ)を記録する audit_trail ログも含まれています。

2

システムは、 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つのセクションです。

  1. extract: 正規表現を使用してフィールドを取得します。

  2. map: それらを変換します(複合データの分割、日付の書式設定、AIへのルーティング)。

  3. output: ターゲット形式に値を配置します。

ドキュメント挿入により、新しいメッセージ形式が有効になり、配置サイクルから翻訳ロジックが削除されます。新しい支払いレールの場合、標準モデルは汎用 JSON 統合ポイントとして機能することで接続性を高速化し、拡張してもコアビジネスロジックが変更されないことを保証します。

完全な実装については、GitHub リポジトリの指示に従います。

支払い処理プラットフォームは、次の2つのマイクロサービスで構成されています。メッセージ翻訳サービスは開発-時間形式オンボーディング向けの構成ビルダを含む、3レーンのパイプラインを介した形式変換を処理します。支払いエージェントは、LangGraphマルチエージェントワークフローを使用して、無効なトランザクションを修復します。どちらのサービスも MongoDB Atlas をODL として共有します。

1

コンバーターは、ハードコーディングされたロジックではなく、MongoDB に保存された設定を使用すして形式間(MT103、ISO 20022、ISO 8583)のメッセージを変換します。

  1. 変換パイプラインの設定: トランザクション参照や金額など、構造化されたフィールドの決定的な整数パターンや、送金情報などの非構造化フィールドのAWS Bedrock を介した LLM 呼出しなど、複雑さに基づいてフィールドをルーティングするようエクストラクターを構成します。

  2. 変換構成を MongoDB に保存: 各構成ドキュメントには、次の3つのセクションがあります。extract (正規表現パターン)、map (フィールド変換)、output (ターゲット形式パス) 。コンバーターは実行時にこれらを読み取るため、新しい形式用にコードを変更する必要はありません。

  3. 出力生成器をビルドする: ビルダは変換されたフィールドを受け取り、ターゲット形式をビルドします。ISO 20022 の場合、ビルダは適切な名前空間を持つ有効な XML を生成します。JSON ターゲットの場合、フラットな標準構造を出力します。

2

エージェントは、IFSCコードの欠落、不正なスクリプト、不完全な受取人データなど、検証に失敗したトランザクションをマルチエージェントワークフローを使用して修復します。

  1. スーパーバイザーエージェントの作成: このエージェントは修復タスク(例: 「日本の場合、creditor_nameにはカタカナが必要」を受け取り、問題解決エージェントを調査にルーティングするか、解決策が知られている場合は直接「実行」にルーティングするかを判断します。

  2. ツールで問題解決エージェントをビルドする: 次の3つのツールで準備します。atlas_search (完全またはファジーマッチングによるデータベース検索)、 vector_search (分類のための意味類似性)、transliterate_text (LLMベースのスクリプト変換)。エージェントは問題の文脈に基づいて使用するツールを決定します。

  3. Human Review チェックポイントの追加: LangGraph の interrupt() 機能を使用して、変更を適用する前にワークフローを一時停止します。ユーザーは、元の値、修正案、信頼度スコア、理由を確認し、ワークフローが再開する前に、承認、却下、または修正できます。

  4. 実行エージェントの実装: 承認されると、このエージェントは修正された値を正規 JSON に書き込み、古い値、新しい値、使用されたツール、タイムスタンプを含むエントリを監査証跡に追加します。

3

新しい支払い形式をオンボードすると、システムは既存のパターンを学習して構成を自動生成します。

  1. 既存の構成を読み込む: アダプティブラーニングサービスはすべての変換構成を MongoDB にクエリし、フィールド ID のマップを標準的なマッピングに構築(例: フィールド「32A」はvalue_datecurrency、およびamountにマッピングされます)します。

  2. サンプルメッセージの解析: SWIFT タグパターン、ISO 8583フィールド位置、XML パスなどの形式固有の抽出プログラムを使用することで、サービスは新しい形式に存在するすべてのフィールドを識別します。

  3. 既知のパターンに一致させ、不明なフィールドを推論する: 他の構成に存在するフィールドの場合、システムは正確なマッピングを再利用します。どこにも存在しないフィールドの場合、サービスは形式タイプに関するコンテキストを持つ LLM を呼び出してマッピングを提案します。

  4. 構成の生成とレビュー: このサービスは、すべてのマッピングを含むドラフト構成ドキュメントを出力します。システムは、人間によるレビューの信頼度しきい値を下回るフィールドにフラグを立てます。承認されると、ドキュメントを MongoDB に挿入し、コンバーターが即座に処理を開始します。

  • 適応学習のための集計パイプライン: $objectToArray$unwind を使用して、1つのクエリで既存のすべての構成からフィールドからマッピングへのルックアップをビルドします。既知のフィールドには自動マッピングが適用され、未知のフィールドは形式の仕様に制約された LLM の提案を受け取ります。

  • Atlas Search for typo tolerance: 正確なデータベース検索が失敗した場合、より低速な AI 推測にフォールバックすることなく、編集距離が設定されたファジー検索でスペルミスを処理します(例: 「HDFC Connaught」を「HDFC Connaught Place」にマップ)。

  • 構成主導型の変換: 抽出パターン、フィールドマッピング、出力パスをアプリケーションコードではなく MongoDB ドキュメントに保存します。新しい支払い形式の追加は、配置ではなく、データベースの挿入になります。

  • Human-in-the-loop コンプライアンス: LgGraph interrupt() メカニズムを使用して、エージェントが変更を適用する前にワークフローを一時停止し、ユーザーに修復の提案を提示し、明示的な承認があった場合にのみ作業を再開します。

  • スーパーバイザー マルチエージェント パターン: IFSC 検索や音訳などのリサーチタスクは、データベースツールを持つ問題解決エージェントにルーティングされ、フィールド更新などの実行タスクは、実行エージェントにルーティングされます。これにより、焦点を当てた専門知識とより整理された監査証跡を確保できます。

  • 統合運用データレイヤー: 標準のJSON、変換構成、監査証跡を MongoDB Atlas に保存します。この一元化により、支払いレール間のデータサイロが排除され、エージェントが必要とする完全なトランザクションコンテキストが提供されます。

  • Wei You Pan、MongoDB

  • Kiran Tulsulkar, MongoDB

  • Ainhoa Múgica, MongoDB

  • MongoDB、 MongoDB

  • RAG アプリケーション向けの統合インターフェース

  • MongoDB Atlas を活用した金融犯罪対策

  • AI駆動型インタラクティブバンキング

戻る

RAG アプリケーション向けの統合インターフェース

項目一覧