保証における引数、請求、サービスの決定は、通常、ポリシー管理システム、請求プラットフォーム、テレマ、サードパーティのリスクデータなど、多くの異なるシステムに分散されているコンテキストによって異なります。毎回そのコンテキストを手動で集約するのは遅く、一貫性がなく、監査するが困難です。
このアーキテクチャでは、 MongoDB Atlasの コンテキストレイヤーについて説明します。これは、エージェントとアプリケーションが読み取り、書込み (write)、操作が可能な単一のライブオブジェクトにビジネスオブジェクトのコンテキストをアセンブルするリアルタイム運用データ階層です。
コンテキストレイヤーは、既存のレコードシステムとAIによる書込み (write)、クレーム、サービス ワークフローの下にあるため、オペレーターで使用できるようにするためにこれらのシステムを置き換える必要はありません。柔軟なドキュメントモデル、 AIネイティブの取得、リアルタイム変更の伝達、フィールドレベルのガバナンスを組み合わせて、エージェントが承認した決定ループの需要を調整する低レイテンシと監査可能性の要件を満たします。
図の 1。コンテキスト層のアーキテクチャの変更AIエージェント データフロー
データフロー
次の手順では、1 つのリクエストまたはクレームがコンテキストレイヤーを通過して、取り込みから書き込みが行われる監査可能な決定に移動する経過を追跡します。
送信またはクレームの取り込み
新しい送信またはクレームが受信され、取り込みサービスがコア識別子と初期構造化フィールドをキャプチャします。その情報が識別されると、取り込みサービスはそれらを単一のドキュメントとしてMongoDB Atlasの
business_objectsコレクションに書込みます。コンテキストの強化と組み立て
専用エンティティエージェントは、カバレッジ制限、エンドポイント、損失の説明、調整ノートなど、アンダーライターまたはクレーム ハンドラーが必要とする残りのコンテキストを収集します。エージェントは、レコードのシステムからデータを収集し、単一の ライブレコードを作成します。現在、単一のMongoDBドキュメントには、アンダーライターまたはクレームエージェントが情報を収集し、決定を行い、アクション を実行するために必要なものがすべて含まれています。
エージェント メモリと状態取得
コンテキストの強化と同時に、サービスはこの送信またはクレームの以前のメモリも検索します。エージェント的メモリにはこの特定のケースのやり取り履歴、決定トレース、監査する履歴、コメントが保持されているためです。これにより、書込み (write) エージェントまたはクレームエージェントは、以前のビュー、推奨、人間によるオーバーライドの完全なメモリを使用して動作を再開できます。
構造化コンテンツと非構造化コンテンツに対するAIネイティブ検索
$vectorSearch$searchこのサービスは、ビジネスオブジェクトやリンクされた非構造化メタデータ。そのために、ドメイン調整された埋め込みと再ランク付けを使用できるため、エージェントは一致の未加工リストではなく、最も関連性の高い履歴と先行例を最初に参照します。エージェントの決定、人間が挿入したループ、書込みバック
エージェントは結合されたコンテキストを確認し、引用符の発行や詳細情報のリクエストなど、アクションを実行します。多くの状況において、このアクションは人間によって確認される必要があり、最終的な改訂版は常に人間の管理下にあります。最後に、決定は、完全なリージョンのトレースとともに、エージェントによってMongoDBの決定トレースの独自のコレクションに不変の監査するエントリとして書込まれ、エージェントアクションに対する完全なコンプライアンスと追跡可能性と透過性が確保されます。
Change Streams によるリアルタイム伝達
MongoDB Change Streams は、送信またはクレームを監視しているすべてのエージェント、ダッシュボード、およびダウンストリーム システムに更新をブロードキャストします。さらに、新しいシグナルは人間のユーザーによって任意の点で導入される可能性があるため、バッチするサイクルを使用せずにクレームエージェントを直ちに起動するクレームの新しい不正インジケーターなど、エージェントを直接トリガーするために使用できます。
コンポーネント
システムレコード
レコードのシステム（SoR）は、単一のレコードシステム（SSoR）とも呼ばれますが、重要なデータ要素または データオブジェクトの認可データソースとして機能する単一のコンピューター システムです。 SoR は "true 状態" を保持しますデータの は、その特定のデータソースで使用可能な最新、正確、および準拠したバージョンであることを意味します。
このアーキテクチャでは、レコードのシステムは引き続きトランザクションのソースとなります。コンテキストレイヤーは使用可能な決定コンテキストをアセンブルする間も、彼らは元の責任を所有し続けます。
ビジネス オブジェクトとエージェントメモリ
ビジネス オブジェクトは、サブスクリプション、クレーム、またはカスタマーレコード のいずれかの運用エンティティを、単一の 継続的に豊富 化するドキュメントとして保持します。これにより、分散したソースから情報を収集する必要なく、すべてのコンシューマーが同じ最新ビューで動作するようになります。 MongoDB はこのレコードと一緒にエージェントのメモリを保存するため、エージェントは複数のステップの決定全体でコンテキストと監査する履歴を保持できます。
AIネイティブ検索
MongoDB ベクトル検索 を全文検索と再ランク付けと組み合わせると、エージェントは別個のベクトルストアを統合するのではなく、1 つのクエリで構造化フィールドと非構造化アーティファクトの両方から最も関連性の高い損失履歴、先行例、またはガイドラインを検索できます。
リアルタイム伝達
MongoDB Change Streams とネイティブストリーム処理、すべてのエージェントと下流のシステムが送信またはクレームの現在の状態と同期され、ポーリングやバッチするサイクルを待つ代わりに新しいシグナルまたはイベントによってエージェントを直接トリガーできるようになります。
監査続行
コンテキストレイヤーは、すべての読み取りと書込み (write) の不変の監査する追跡を保持するため、すべてのAIによる決定を常に透過的で追跡可能にします。 1 つのコレクションには、結果、コンテキスト、 AIメタデータ、決定の結果などに到達するための手順に決定を行ったユーザーまたはエージェントの ID から、各決定に関する完全な情報が収集されます。
制限
このパターンは複雑さを導入するため、意図的に採用する必要があります。
運用層は分析目的に必ずしも最適ではありません。このアーキテクチャは、分析専用のワークロード、アーカイブ リポジトリ、または決定にリアルタイムコンテキストの組み立て、書込み、または監査可能性を必要としないユースケースには適していません。レポート作成やバッチ指向の分析が主なニーズである場合は、 運用コンテキストレイヤーを追加せずに分析プラットフォームで十分な場合があります。
スキーマの柔軟性には独自の規則が必要です。このアプローチでは、データ モデリング、ID 解決、ガバナンス、ライフサイクル管理においても独自の規則が必要です。コンテキストレイヤーは、大規模で複雑なオブジェクトと展開するスキーマを蓄積することができるため、チームはオブジェクト境界、期待、更新パターンを早期に定義する必要があります。
上流へのシステムの複雑さは排除されません。決定時間の断片化は軽減されますが、確実に上流のデータアクセスとデータ品質に依存します。ソース品質が不十分な場合やイベント設計が脆弱な場合は、消えてコンテキストレイヤー内に表示されます。
このアーキテクチャは、事前定義されたデータモデルを使用して特定のユースケースに合わせてカスタマイズされ、その後、証明済みの参照ワークフローから拡張される場合に最高の機能を発揮します。
詳細
その他の参照アーキテクチャを調べます。