Nos últimos anos, seguradoras e empresas que fornecem produtos semelhantes seguros testemunharam o surgimento de diversas novas regulamentações. Essas novas regulamentações têm exigido uma modelagem financeira mais ampla das seguradoras. A União Europeia promulgou a Solvência II. Essa lei exige que as seguradoras demonstrem que realizaram suas próprias análises para validar que estarão solventes no final do ano. Seguradoras que fornecem anuidades variáveis precisam seguir a Diretriz Atuarial XLIII, com uma análise abrangente de fluxos de caixa ativo e passivo. Todos os tipos de seguradoras, incluindo empresas que distribuem produtos semelhantes a seguros, precisarão implementar o IFRS 17 (Padrão Internacional para Relatórios Financeiros 17) até 2021. (IFRS significa International Financing Reporting Standards (Normas internacionais de relatórios de financiamento). Existem outras regulamentações, dependendo das jurisdições em que as seguradoras operam. Essas normas e padrões exigem que atuários usem técnicas com uso intensivo de computação ao modelar ativos e passivos. Grande parte da análise usa dados de cenários gerados de forma estocástica por meio de entradas seriais de coisas como ativos e passivos. Além das necessidades regulatórias, os atuários fazem uma boa quantidade de modelagem financeira e de computação. Eles criam as tabelas de entrada para os modelos que geram os relatórios regulatórios. Grades internas não atendem às necessidades computacionais e, portanto, os atuários estão constantemente se mudando para a nuvem.
Os atuários se mudam para a nuvem para ter mais tempo para examinar, avaliar e validar os resultados. Quando os órgãos reguladores auditam as seguradoras, os atuários precisam ser capazes de explicar seus resultados. A mudança para a nuvem fornece acesso a recursos de computação para executar 20.000 horas de análise em 24 a 120 horas usando o poder da paralelização. Para ajudar com essa necessidade de escala, muitas das empresas que criam software atuarial fornecem soluções que permitem que os cálculos sejam executados no Azure. Algumas dessas soluções são criadas em tecnologias que são executadas no local e no Azure, como a solução PowerShell de computação de alto desempenho, HPC Pack. Outras soluções são nativas do Azure e usam o Lote do Azure, conjuntos de dimensionamento de máquinas virtuais ou uma solução de dimensionamento personalizada.
Neste artigo, veremos como os desenvolvedores atuariais podem usar o Azure, juntamente com pacotes de modelagem, para analisar o risco. O artigo explica algumas das tecnologias do Azure que os pacotes de modelagem usam para serem executados em escala no Azure. Você pode usar a mesma tecnologia para fazer mais análises de seus dados. Nós examinamos os seguintes aspectos:
- Executar modelos maiores em menos tempo no Azure.
- Relatar os resultados.
- Gerenciar a retenção de dados.
Se você atende seguros de vida, de propriedade e de acidentes, de saúde ou outros, você precisa criar modelos financeiros e de risco de seus ativos e passivos. Você pode então ajustar seus investimentos e prêmios para que você permaneça solvente como seguradora. A criação de relatórios em conformidade com o IFRS 17 adiciona alterações aos modelos criados pelos atuários, como o cálculo da CSM (margem de serviço contratual), que altera como as seguradoras gerenciam seus lucros ao longo do tempo.
Executar mais em menos tempo no Azure
Você acredita na promessa da nuvem: ela pode executar seus modelos financeiros e de risco com mais rapidez e facilidade. Para muitas seguradoras, um cálculo muito simples evidencia o problema: elas precisam de anos ou até mesmo de décadas de tempo sequencial para executar esses cálculos do início ao fim. Você precisa de tecnologia para resolver o problema de runtime. As estratégias são:
- Preparação de dados: alguns dados mudam lentamente. Depois que uma apólice ou contrato de serviço está em vigor, os sinistros se movem em um ritmo previsível. Você pode preparar os dados necessários para as execuções do modelo conforme eles chegam, eliminando a necessidade de dedicar muito tempo à preparação e à limpeza de dados. Você também pode usar clustering para criar substitutos para dados seriais por meio de representações ponderadas. Menos registros geralmente resultam em um tempo de computação reduzido.
- Paralelização: se precisar fazer a mesma análise de dois ou mais itens, você poderá executar a análise simultaneamente.
Vamos examinar esses itens individualmente.
Preparação de dados
Os dados são provenientes de várias fontes diferentes. Você tem dados de apólice semiestruturados em seus livros de negócios. Você também tem informações sobre pessoas seguradas, empresas e itens que aparecem em vários formulários de solicitação. ESGs (geradores de cenário econômico) produzem dados em uma variedade de formatos, que podem necessitar de tradução para um formato que seu modelo pode usar. Dados atuais sobre valores de ativos também precisam de normalização. Dados do mercado de ações, dados de fluxo de caixa de imóveis alugados, informações sobre hipotecas, entre outros dados de ativos, precisam de alguma preparação quando são movidos da origem para o modelo. Por fim, você precisa atualizar suposições com base em dados provenientes da experiência recente. Para acelerar a execução de um modelo, você prepara os dados antecipadamente. Quando o tempo de execução ocorre, você faz as atualizações necessárias para adicionar alterações desde a última atualização agendada.
E então, como você prepara os dados? Primeiro, vamos examinar os aspectos comuns e, depois, veremos como trabalhar com as diferentes formas como os dados aparecerão. Primeiro, você quer ter um mecanismo para capturar todas as alterações desde a última sincronização. Esse mecanismo deve incluir um valor classificável. Para alterações recentes, esse valor deve ser maior do que qualquer alteração anterior. Os dois mecanismos mais comuns são um campo de ID crescente ou um carimbo de data/hora. Se um registro tiver uma chave de ID crescente, mas o restante do registro contiver campos que podem ser atualizados, você precisará usar algo como um carimbo de data/hora "modificado pela última vez" para encontrar as alterações. Após os registros terem sido processados, registre o valor classificável do último item atualizado. Esse valor, provavelmente um carimbo de data/hora em um campo chamado lastModified, torna-se sua marca-d'água, usada em consultas posteriores no armazenamento de dados. Alterações de dados podem ser processadas de várias maneiras. Estes são dois mecanismos comuns que usam o mínimo de recursos:
- Se você tiver centenas ou milhares de alterações para processar, faça upload dos dados no armazenamento de blobs. Usar um gatilho de evento no Azure Data Factory para processar o conjunto de alterações.
- Se você tiver pequenos conjuntos de alterações para processar ou quiser atualizar seus dados assim que uma alteração ocorrer, coloque cada alteração em uma mensagem de fila hospedada pelo barramento de serviço ou pelas filas de armazenamento. Este artigo tem uma ótima explicação sobre as compensações entre as duas tecnologias de enfileiramento. Depois que uma mensagem estiver em uma fila, você pode usar um gatilho no Azure Functions ou no Azure Data Factory para processá-la.
A figura a seguir ilustra o cenário típico. Primeiro, um trabalho agendado coleta um conjunto de dados e coloca o arquivo no armazenamento. O trabalho agendado pode ser um trabalho CRON em execução local, uma Tarefa do agendador, um Aplicativo Lógico ou qualquer coisa que é executada com um temporizador. Depois que o arquivo é carregado, uma instância de Função do Azure ou do Data Factory pode ser disparada para processar os dados. Se o arquivo puder ser processado em um período curto, use uma Função. Se o processamento for complexo, exigir inteligência artificial ou outros scripts complexos, você poderá concluir que o HDInsight, o Azure Databricks ou algo personalizado funciona melhor. No final do processo, o arquivo acaba em um formato utilizável como um novo arquivo ou como registros em um banco de dados.
Depois que os dados estão no Azure, você precisa torná-los utilizáveis pelo aplicativo de modelagem. Você pode escrever código para fazer transformações personalizadas, passar os itens pelo HDInsight ou pelo Azure Databricks para ingestão de itens maiores ou copiar os dados para os conjuntos de dados corretos. O uso de ferramentas de Big Data também pode ajudar a fazer coisas como transformar dados não estruturados em dados estruturados, além de executar qualquer tipo IA e aprendizado de máquina nos dados recebidos. Você também pode hospedar máquinas virtuais, fazer upload de dados diretamente para fontes de dados do local, chamar o Azure Functions diretamente e assim por diante.
Posteriormente, os dados precisam ser consumidos por seus modelos. A maneira de fazer isso depende em grande parte de como os cálculos precisam acessar os dados. Alguns sistemas de modelagem exigem que todos os arquivos de dados residam no nó que executa o cálculo. Outras pessoas podem usar bancos de dados como Banco de Dados SQL do Azure, MySQL ou PostgreSQL. Você pode usar uma versão de baixo custo de qualquer um desses itens e, em seguida, escalar verticalmente o desempenho durante uma execução de modelagem. Isso lhe dá o preço de que você precisa para o trabalho diário. Além disso, oferece também a velocidade extra apenas quando milhares de núcleos estão solicitando dados. Normalmente, esses dados serão somente leitura durante uma execução de modelagem. Se os cálculos ocorrerem em várias regiões, considere usar o Azure Cosmos DB ou a replicação geográfica do Azure SQL. Ambos fornecem mecanismos para replicar automaticamente dados entre regiões com baixa latência. Sua escolha depende das ferramentas que seus desenvolvedores conhecem, de como você modelou seus dados e do número de regiões usadas para a execução da modelagem.
Dedique algum tempo para pensar sobre o local em que seus dados devem ser armazenados. Saiba quantas solicitações simultâneas haverá para os mesmos dados. Pense em como você distribuirá as informações:
- Cada nó de computação terá sua própria cópia?
- A cópia é compartilhada em uma localização com grande largura de banda?
Se mantiver os dados centralizados usando o Azure SQL, você provavelmente manterá o banco de dados em uma camada de preço mais baixa a maior parte do tempo. Se os dados forem usados somente durante uma execução de modelagem e não atualizados com frequência, os clientes do Azure poderão até mesmo fazer backup dos dados e desligar suas instâncias de banco de dados entre as execuções. O potencial de economia é enorme. Os clientes também podem usar Pools Elásticos do Azure SQL. Elas foram criadas para controlar os custos dos bancos de dados, especialmente quando você não sabe quais bancos de dados estarão sob uma carga muito grande em momentos diferentes. Os pools elásticos permitem que uma coleção de bancos de dados use toda a capacidade de que precisarem e, em seguida, sejam redimensionados quando a demanda passa para outro lugar do sistema.
Talvez você precise desabilitar a sincronização de dados durante uma modelagem para que cálculos feitos posteriormente no processo usem os mesmos dados de modelagem. Se usar o enfileiramento, desabilite os processadores de mensagens, mas permita que as filas recebam dados.
Você também pode usar o tempo antes da execução para gerar cenários econômicos, atualizar pressuposições atuariais e atualizar outros dados estáticos de modo geral. Vamos examinar a ESG (geração de cenário econômico). A Society of Actuaries fornece o AIRG (Gerador da taxa de juros acadêmicos), um ESG que modela rendimentos, um ESG que modela os rendimentos do Tesouro americano. O AIRG é indicado para uso com itens como cálculos do VM-20 (Valuation Manual 20). Outros ESGs podem modelar o mercado de ações, hipotecas, preços de commodities e assim por diante.
Como seu ambiente pré-processa os dados, você também pode executar outras partes primeiro. Por exemplo, você pode ter coisas modeladas por você que usam registros para representar populações maiores. Normalmente, isso é feito por meio do clustering de registros. Se o conjunto de dados for atualizado esporadicamente, como uma vez por dia, será possível reduzir o conjunto de registros a que será usado no modelo como parte do processo de ingestão.
Vamos examinar um exemplo prático. Com o IFRS-17, você precisa agrupar seus contratos, para que a distância máxima entre as datas iniciais de quaisquer dois contratos seja de menos de um ano. Vamos supor que você faça isso da maneira mais fácil e use o ano do contrato como mecanismo de agrupamento. Essa segmentação pode ser feita enquanto os dados são carregados no Azure, lendo o arquivo e movendo os registros para os agrupamentos de anos apropriados.
Concentrar-se na preparação de dados reduz o tempo necessário para executar os componentes do modelo. Obtendo os dados no início, você pode economizar tempo para a execução de seus modelos.
Paralelização
A paralelização adequada das etapas pode reduzir drasticamente o tempo de execução. Esse aumento de velocidade acontece simplificando as partes que você implementa e sabendo como expressar seu modelo de maneira que permita que duas ou mais atividades sejam executadas simultaneamente. O truque é encontrar o equilíbrio entre o tamanho da solicitação de trabalho e a produtividade de um nó individual. Se a tarefa gasta mais tempo na instalação e na limpeza do que na avaliação, você escolheu um tamanho muito pequeno. Se a tarefa for muito grande, o tempo de execução não melhorará. Você deseja que a atividade seja pequena o suficiente para ser distribuída entre vários nós e fazer uma diferença positiva no tempo de execução decorrido.
Para tirar o máximo proveito do seu sistema, você precisa entender o fluxo de trabalho do seu modelo e como os cálculos interagem com a capacidade de expansão. Seu software pode ter uma noção de trabalhos, de tarefas ou algo semelhante. Use esse conhecimento para criar algo que possa dividir o trabalho. Se você tiver algumas etapas personalizadas em seu modelo, elabore-as de forma a permitir que as entradas sejam divididas em grupos menores para processamento. Geralmente, esse design é conhecido como padrão de dispersão e coleta.
- Dispersão: dividir as entradas em linhas naturais e permitir que tarefas separadas sejam executadas.
- Coleta: conforme as tarefas forem concluídas, colete os resultados.
Ao dividir as coisas, saiba também onde o processo precisa ser sincronizado antes de prosseguir. Há alguns locais comuns em que as pessoas dividem as coisas. Para execuções estocásticas aninhadas, você pode ter mil loops externos com um conjunto de pontos de inflexão que executam loops internos de uma centena de cenários. Cada loop externo pode ser executado simultaneamente. Você para em um ponto de inflexão, executa os loops internos simultaneamente, retoma as informações para ajustar os dados para o loop externo e, em seguida, prossegue novamente. A figura a seguir ilustra o fluxo de trabalho. Com computação suficiente, você pode executar os 100.000 loops internos em 100.000 núcleos, reduzindo o tempo de processamento à soma dos seguintes tempos:
A distribuição vai aumentar um pouco, dependendo de como isso for feito. Pode ser tão simples quanto construir um pequeno trabalho com os parâmetros certos, ou tão complexo quanto copiar arquivos de 100.000 para os lugares certos. O processamento dos resultados poderá, até mesmo, ser acelerado, se você puder distribuir a agregação dos resultados usando o Apache Spark do Azure HDInsight, o Azure Databricks ou sua própria implantação. Por exemplo, a computação de médias é uma simples questão de se lembrar o número de itens vistos até agora e a soma. Outros cálculos podem funcionar melhor em um único computador com milhares de núcleos. Para eles, você pode fazer uso de computadores habilitados para GPU no Azure.
A maioria das equipes atuariais começa essa jornada movendo seus modelos para o Azure. Em seguida, eles coletam dados de tempo nas diversas etapas no processo. Depois, eles classificam o tempo para cada etapa, da mais longa para a mais curta. Eles não irão avaliar o tempo de execução total, pois algo pode consumir milhares de horas de núcleo, mas somente 20 minutos de tempo decorrido. Para cada uma das etapas de trabalho de execução mais longa, os desenvolvedores atuariais buscam formas de diminuir o tempo decorrido, enquanto obtêm os resultados certos. Esse processo é repetido regularmente. Algumas equipes atuariais definem uma meta de tempo de execução, digamos que uma análise de hedge da noite para o dia tenha o objetivo de ser executada em menos de 8 horas. Assim que o tempo passar de 8,25 horas, alguma parte da equipe atuarial entrará em ação para melhorar o tempo da parte mais longa na análise. Após reduzirem o tempo de volta para 7,5 horas, eles retornarão para o desenvolvimento. A heurística de voltar e otimizar varia entre os atuários.
Para executar tudo isso, você tem várias opções. A maioria dos softwares atuariais funciona com grades de computação. Grades que funcionam localmente e no Azure usam o Pacote de HPC, um pacote de parceiro ou algo personalizado. Grades otimizadas para o Azure usam Conjuntos de Dimensionamento de Máquinas Virtuais, Lote ou algo personalizado. Se você optar por usar conjuntos de dimensionamento ou o Lote, certifique-se de examinar o suporte deles para VMs de baixa prioridade (Documentos de baixa prioridade nos Conjuntos de Dimensionamento, Documentos de baixa prioridade no Lote). Uma VM de baixa prioridade é uma VM em execução em hardware que você pode alugar por uma fração do preço normal. O preço mais baixo está disponível porque VMs de baixa prioridade podem sofrer preempção quando a capacidade exigir isso. Quando você tem alguma flexibilidade em seu tempo, as VMs de baixa prioridade são uma ótima maneira de reduzir o preço de uma execução de modelagem.
Se precisar coordenar a execução e a implantação em vários computadores, talvez com alguns em execução em diferentes regiões, você poderá tirar proveito do CycleCloud. O CycleCloud não custa nada a mais. Ele coordena a movimentação de dados quando necessário. Isso inclui a alocação, o monitoramento e o desligamento de computadores. Ele pode lidar até mesmo com computadores de baixa prioridade, certificando-se de que as despesas serão contidas. Você pode até mesmo descrever a mistura de computadores de que precisa. Por exemplo, talvez você precise de uma classe de computador, mas possa executar bem em qualquer versão que tenha dois ou mais núcleos. O Cycle pode alocar núcleos entre esses tipos de computadores.
Relatar os resultados
Após os pacotes atuariais terem sido executados e produzirem os resultados, você terá vários relatórios prontos para as agências regulatórias. Você também terá uma montanha de novos dados que talvez seja importante analisar para gerar insights que não são exigidos por reguladores nem auditores. Talvez você queira entender o perfil de seus melhores clientes. Usando insights, você pode informar ao setor de marketing como é o cliente de baixo custo, de modo que as equipes de marketing e vendas possam encontrá-lo com mais rapidez. Da mesma forma, você pode usar os dados para descobrir quais grupos se beneficiam mais do seguro. Por exemplo, você pode descobrir que pessoas que fazem um exame físico anual descobriram problemas de saúde no estágio inicial. Isso economiza tempo e dinheiro da seguradora. Você pode usar esses dados para mudar o comportamento de sua base de clientes.
Para fazer isso, é importante você ter acesso a muitas ferramentas de ciência de dados, além de algumas ferramentas de visualização. Dependendo do quanto deseja investigar, você pode começar com uma VM de Ciência de Dados que pode ser provisionada no Azure Marketplace. Essas VMs têm versões para Windows e Linux. Instalado, você encontrará o Microsoft R Open, o Microsoft Machine Learning Server, o Anaconda, o Jupyter e outras ferramentas prontas para uso. Use um R ou Python para visualizar os dados e compartilhar informações com seus colegas.
Se precisar fazer mais análises, você poderá usar ferramentas de ciência de dados Apache como Spark, Hadoop e outras por meio do HDInsight ou do Databricks. Use-as quando precisar realizar análises regularmente e quiser automatizar o fluxo de trabalho. Essas ferramentas também são úteis para análise em tempo real de grandes conjuntos de dados.
Depois de ter encontrado algo interessante, você precisa apresentar os resultados. Muitos atuários começam utilizando os resultados do exemplo e jogando-os no Excel para criar gráficos, tabelas e outras visualizações. Se quiser algo que também tenha uma bela interface para avaliar os dados, dê uma olhada no Power BI. O Power BI pode fazer algumas visualizações interessantes, exibir os dados de origem e permitir explicar os dados para o leitor por meio do acréscimo de indicadores ordenados e anotados.
Retenção de dados
Muitos dos dados trazidos para o sistema precisam ser preservados para auditorias futuras. Requisitos de retenção de dados normalmente vão de 7 a 10 anos, mas variam. A retenção mínima envolve:
- Um instantâneo das entradas originais do modelo. Inclui ativos, passivos, suposições, ESGs e outras entradas.
- Um instantâneo dos resultados finais. Inclui todos os dados usados para criar relatórios apresentados aos órgãos reguladores.
- Outros resultados intermediários importantes. Um auditor perguntará por que seu modelo chegou a um resultado. Você precisa reter evidências sobre por que o modelo fez determinadas escolhas ou chegou a números específicos. Muitas seguradoras optam por manter os binários usados para produzir as saídas finais das entradas originais. Depois, quando questionadas, elas executam novamente o modelo para obter uma cópia atualizada dos resultados intermediários. Se as saídas corresponderem, os arquivos intermediários também deverão conter as explicações necessárias.
Durante a execução do modelo, os atuários usam mecanismos de entrega de dados que podem lidar com a carga de solicitação da execução. Quando a execução é concluída e os dados não são mais necessários, eles preservam alguns dos dados. No mínimo, uma seguradora deve preservar as entradas e a configuração de runtime para atender aos requisitos de capacidade de reprodução. Bancos de dados são preservados em backups no Armazenamento de Blobs do Azure e servidores são desligados. Dados em armazenamento de alta velocidade também são movidos para o Armazenamento de Blobs do Azure, que é mais barato. No Armazenamento de Blobs, você pode escolher a camada de dados usada para cada blob: frequente, esporádica ou de arquivos. O armazenamento frequente funciona bem para arquivos acessados com frequência. O armazenamento esporádico é otimizado para acesso a dados pouco frequente. O armazenamento de arquivos é melhor para manter arquivos auditáveis, mas as economias de preço têm uma custo de latência: a latência de dados arquivados é medida em horas. Leia Armazenamento de Blobs do Azure: camadas de armazenamento frequente, esporádico e de arquivos para compreender totalmente as diferentes camadas de armazenamento. Você pode gerenciar os dados desde a criação até a exclusão com o gerenciamento de ciclo de vida. Os URIs para os blobs permanecem estáticos, mas o local em que o blob é armazenado fica mais barato ao longo do tempo. Esse recurso economiza muito dinheiro e dor de cabeça para muitos usuários do Armazenamento do Azure. Você pode conhecer as vantagens e desvantagens consultando Gerenciando o Ciclo de Vida do Armazenamento de Blobs do Azure. O fato de você poder excluir automaticamente os arquivos é fantástico: isso significa que você não expande acidentalmente uma auditoria fazendo referência a um arquivo fora do escopo, pois o arquivo em si pode ser removido automaticamente.
Considerações
Se o sistema atuarial que executar tiver uma implementação de grade local, essa implementação de grade provavelmente também será executada no Azure. Alguns fornecedores têm implementações especializadas do Azure que são executadas em hiperescala. Como parte da mudança para o Azure, mude também suas ferramentas internas. Atuários de toda parte têm percebido que suas habilidades de ciência de dados funcionam bem em seu laptop ou com um ambiente grande. Procure as coisas que sua equipe já faz: talvez você tenha algo que usa aprendizado profundo, mas leva horas ou dias para ser executado em uma GPU. Tente executar a mesma carga de trabalho em uma máquina com quatro GPUs high-end e observe os tempos de execução. As chances são boas de você ver acelerações significativas para coisas que você já tem.
Conforme as coisas melhorarem, não deixe de usar a sincronização de dados para alimentar os dados de modelagem. Uma execução de modelo não pode ser iniciada, até que os dados estejam prontos. Isso pode envolver o acréscimo de algum esforço para que você envie apenas dados que foram alterados. A abordagem real depende do tamanho dos dados. Atualizar alguns MB talvez não seja um grande problema, mas reduzir o número de uploads de gigabytes acelera muito as coisas.
Colaboradores
Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.
Autor principal:
- Scott Seely | Arquiteto de software
Próximas etapas
- Desenvolvedores do R: Executar uma simulação de R paralela com o Lote do Azure
- ETL com Databricks: Extrair, transformar e carregar dados usando o Azure Databricks
- ETL com HDInsight: Extrair, transformar e carregar dados usando o Apache Hive no Azure HDInsight
- Instruções para a VM da ciência de dados (Linux)
- Instruções para a VM de ciência de dados (Windows)