保险中的承保、理赔和服务决策取决于通常分散在许多不同系统中的上下文，包括保单管理系统、理赔平台、远程信息处理和第三方风险数据等。每次都手动组装上下文，速度慢、不一致，而且难以Atlas 审核。
此架构描述了MongoDB Atlas上的上下文层，这是一个实时操作数据层级，它将业务对象上下文组装成代理和应用程序可以读取、写入和操作的单个活动对象。
上下文层位于现有记录系统与AI驱动的承保、理赔和服务工作流程之间，因此承运人无需替换这些系统即可供代理使用。它结合了灵活的文档模型、 AI原生检索、实时变更传播和字段级管理，以满足受监管的代理增强决策循环所需的低延迟和可审核性要求。
图 1。上下文层架构和AI助手数据流
数据流
以下步骤跟踪单个提交或声明通过上下文层，从接收到写回的可审核决策。
提交或声明接收
新的提交或声明到达，接收服务捕获核心标识符和初始结构化字段。识别这些信息后，接收服务会将其作为单个文档写入MongoDB Atlas中的
business_objects集合。上下文丰富和组装
专门的丰富代理会收集承保人或理赔处理人所需的其余上下文，例如承保限额、背书、损失描述、理算员注释等。该代理会收集记录系统中的数据以创建单个实时记录。现在，单个MongoDB文档包含承保人或理赔代理收集信息、做出决策和采取动作所需的所有信息。
代理内存和状态检索
在丰富上下文的同时，该服务还会检索此提交或声明的先前记忆，因为代理内存保存此特定案例的对话历史记录、决策跟踪、Atlas 审核历史记录和情绪。这样，承保或理赔代理就能在完整记忆之前的回合、建议和人工覆盖的情况下恢复工作。
针对结构化和非结构化内容的AI原生检索
该服务针对业务对象和链接的非结构化工件（例如理算员注释、损失描述或图像元元数据）发出混合
$vectorSearch和$search查询。为此，可以使用经过领域调整的嵌入和重新排名，以便代理首先看到最相关的历史记录和先例，而不是原始的匹配列表。助手决策、Human-In-The-Loop 和回写
代理会查看组合的上下文并采取动作，例如发布报价或请求更多信息。在许多情况下，此动作需要人工审核，使最终版本始终处于人工控制之下。最后，决策及其完整的推理跟踪由代理写回MongoDB中自己的决策跟踪集合，作为不可变的Atlas 审核条目，以确保代理操作的完全合规、可追溯性和透明度。
使用 Change Streams 进行实时传播
MongoDB Change Streams将更新广播到监视提交或声明的每个代理、仪表盘和下游系统。此外，人类用户可以点引入新信号，以便直接触发代理，例如索赔上的新欺诈指示器会立即触发理赔代理，而无需批处理周期。
组件
记录系统
记录系统 (SoR) 也称为单一记录系统 (SSoR)，是作为关键数据元素或数据对象的权威数据源的单一计算机系统。该 SoR 保持“真实状态”。 ，这意味着它是可用于该特定数据源的最新、准确且合规的版本。
在此架构中，记录系统仍然是业务事务的来源。他们继续承担原来的职责，而上下文层在他们之间组装可用的决策上下文。
业务对象和代理内存
业务对象将操作实体（提交、声明或客户记录）作为单个且不断丰富的文档进行保存。这可确保每个使用者都从相同的最新视图工作，而不必从分散的来源收集信息。 MongoDB将代理内存与此记录一起存储，以便助手在多步骤决策中保留上下文和Atlas 审核历史记录。
AI原生检索
MongoDB Vector Search 与全文搜索和重新排名相结合，可让代理在单个查询中从结构化字段和非结构化工件中检索最相关的损失历史记录、先例或指南，而不是在单独的向量存储中进行协调。
实时传播
MongoDB Change Streams和原生流处理使每个代理和下游系统与提交或声明的当前状态保持同步，并允许新信号或事件直接触发代理，而不是等待轮询或批处理周期。
审核追踪
上下文层为每次读取和写入保留不可变的Atlas 审核跟踪，以便所有AI辅助决策始终保持透明和可追踪。其中一个集合收集每个决策的完整信息，从做出决策的用户/代理的身份到得出结论的步骤、上下文、 AI元数据、决策结果等。
限制
这种模式引入了复杂性，应有意采用。
操作层并不总是最适合分析目的：此架构不太适合仅分析的工作负载、存档存储库或决策不需要实时上下文组装、写入或可审核性的使用案例。如果主节点 (primary node in the replica set)需求是报告或面向批处理的分析，分析平台可能就足够了，而无需添加操作上下文层。
模式灵活性需要自己的规则：这种方法还需要数据建模、身份解析、管理和生命周期管理方面的规则。上下文层可以累积大型、复杂的对象和不断发展的模式，因此团队必须尽早定义对象边界、期望和更新模式。
上游系统的复杂性不会消除：它减少了决策时间碎片，但仍然依赖于可靠的上游数据访问和数据质量。源质量差或事件设计薄弱将在上下文层内浮现，而不是消失。
当使用预定义的数据模型针对特定使用案例进行定制，然后从经过验证的参考工作流程进行扩展时，该架构效果最佳。
了解详情
探索其他参考架构：