As decisões de subscrição, reivindicações e serviços em seguros dependem do contexto que, em geral, é distribuído em muitos sistemas diferentes, incluindo sistemas de administração de políticas, plataformas de reivindicações, telemática e dados de risco de terceiros, entre outros. A montagem desse contexto manualmente sempre é lenta, inconsistente e difícil de auditar.
Essa arquitetura descreve uma camada de contexto no MongoDB Atlas, que é uma camada de dados operacionais em tempo real que monta o contexto de objeto de negócios em um único objeto ativo no qual agentes e aplicativos podem ler, escrever e agir.
A camada de contexto fica entre os sistemas existentes de registro e os fluxos de trabalho de subscrição, declarações e serviços orientados por IA, para que as operadoras não precisem substituir esses sistemas para torná-los utilizáveis pelos agentes. Ele combina um modelo de documento flexível, recuperação nativa de IA, propagação de alterações em tempo real e administração de campo para atender aos requisitos de baixa latência e auditabilidade exigidos pelos loops de decisão regulamentados e aumentados por agentes.
Gráfico 1. Arquitetura da camada de contexto & Fluxo de dados do agente de IA
Fluxo de dados
As etapas a seguir rastreiam um único envio ou reivindicação à medida que ela passa pela camada de contexto, desde a ingestão até uma decisão auditável com gravação.
Envio ou ingestão de reivindicação
Uma nova apresentação ou reivindicação chega e o serviço de ingestão captura identificadores principais e campos estruturados iniciais. Depois que essas informações são identificadas, o serviço de ingestão as grava em uma coleção
business_objectsno MongoDB Atlas como um único documento.Enriquecimento e montagem de contexto
Um agente de enriquecimento especializado reúne o contexto restante de que o subscritor ou manipulador de declarações precisa, como limites de cobertura, endors, descrições de perdas, notas de ajuste e muito mais. O agente reúne dados do sistema de registros para criar um único registro ativo. Agora, um único documento MongoDB contém tudo o que um subscritor ou agente de declarações precisa para reunir conhecimento, tomar uma decisão e ação.
Memória do agente e recuperação de estado
Ao mesmo tempo em que enriquece o contexto, o serviço também recupera a memória anterior para esse envio ou reivindicação, pois a memória do agente contém o histórico de conversas, rastreamentos de decisões, histórico de auditar e relacionamentos para esse caso específico. Isso permite que um agente de subscrição ou reivindicação retome o trabalho com memória completa de mudanças anteriores, recomendações e substituições humanos.
Recuperação nativa de IA sobre conteúdo estruturado e não estruturado
O serviço emite queries híbridas
$vectorSearche$searchem relação ao objeto de negócios e artefatos não estruturados vinculados, como notas de ajuste, escritas de perda ou metadados de imagens. Para fazer isso, incorporações ajustadas ao domínio e reclassificação podem ser usadas, para que o agente veja primeiro o histórico e o precedente mais relevantes, em vez de uma lista bruta de correspondências.Decisão do agente, oHuman-In-The-Loop e o write-back
O agente analisa o contexto montado e executa uma ação, como emitir uma cotação ou solicitar mais informações. Em muitas situações, essa ação precisará ser revisada pelo ser humano, mantendo a revisão final sempre sob o controle do ser humano. Finalmente, a decisão, juntamente com seu rastreamento completo, é escrita de volta pelo agente em sua própria coleção de rastreamentos de decisão no MongoDB como uma entrada de auditar imutável para garantir a total conformidade, rastreabilidade e Transparência das ações do agente.
Propagação em tempo real com Change Streams
O MongoDB Change Streams transmite a atualização para cada agente, painel e sistema downstream que observa o envio ou a reivindicação. Além disso, novos sinais podem ser introduzidos pelo usuário humano a qualquer ponto, para que possam ser usados para acionar agentes diretamente, como um novo indicador de fraude em uma reivindicação que aciona o agente imediatamente, sem um ciclo em lote .
Componentes
Sistemas de registro
Um sistema de registro (SoR), também conhecido como sistema único de registro (SSoR), é um sistema de computador único que serve como fonte de dados oficial para um elemento de dados crítico ou objeto de dados. O SoR mantém o "verdadeiro estado" dos dados, o que significa que é a versão mais atualizada, precisa e compatível disponível para essa fonte de dados específica .
Nessa arquitetura, os sistemas de registro continuam sendo a fonte das transações comerciais. Eles continuam a possuir suas responsabilidades originais enquanto a camada de contexto monta um contexto de decisão utilizável através deles.
Objetos de negócios e memória do agente
Os objetos de negócios mantêm a entidade operacional, seja um envio, uma reclamação ou um registro de cliente , como um documento único e continuamente enriquecido. Isso garante que cada consumidor trabalhe com a mesma visão atualizada, em vez de ter que coletar informações de fontes dispersas. O MongoDB armazena a memória do agente ao lado desse registro para que os agentes retenham o contexto e o histórico de auditar em uma decisão de várias etapas.
Recuperação de IA nativa
O MongoDB Vector Search combinado com a pesquisa de texto completo e a reclassificação permitem que os agentes recuperem o histórico de perdas, os precedentes ou as diretrizes mais relevantes de campos estruturados e artefatos não estruturados em uma única query, em vez de orquestrar em um armazenamento de vetores separado.
Propagação em tempo real
O MongoDB Change Streams e o processamento de fluxo nativo mantêm todos os agente e sistemas downstream sincronizados com o estado atual de um envio ou reivindicação e permitem que novos sinais ou eventos acionem diretamente um agente , em vez de esperar por uma sondagem ou ciclo de lote .
Trilha de auditoria
A camada de contexto mantém uma faixa de auditar imutável para cada leitura e escrita, para que todas as decisões assistidas por IA permaneçam transparentes e rastreáveis o tempo todo. Uma collection reúne todas as informações sobre cada decisão, desde a identidade do usuário/ agente que toma a decisão até as etapas para chegar à conclusão, contexto, metadados de IA, resultado da decisão e muito mais.
Limitações
Esse padrão introduz complexidade e deve ser aceito intencionalmente.
A camada operacional nem sempre é a melhor para fins analíticos: essa arquitetura não é adequada para volumes de trabalho somente analíticos, repositórios de arquivamento ou casos de uso em que as decisões não exigem montagem, gravações ou auditoria de contexto em tempo real. Se a principal necessidade for relatórios ou análise orientada em lote, as plataformas analíticas podem ser suficientes sem adicionar uma camada de contexto operacional.
A flexibilidade do esquema requer sua própria disci Uma camada de contexto pode acumular objetos grandes e complexos e esquemas em desenvolvimento, portanto, as equipes devem definir os limites dos objeto , as expectativas e os padrões de atualização o quanto antes.
A complexidade do sistema upstream não será eliminada: ela reduz a fragmentação do tempo de decisão, mas ainda depende do acesso confiável aos dados upstream e da qualidade dos dados. A baixa qualidade da fonte ou o design ruim do evento surgirão dentro da camada de contexto em vez de desaparecer.
A arquitetura funciona melhor quando personalizada para um caso de uso específico com um modelo de dados predefinido e, em seguida, expandida a partir de um fluxo de trabalho de referência testado.
Saiba mais
Explore as outras arquiteturas de referência: