Há cerca de seis meses venho criando um sistema de combate à fraude (atividade fraudulenta, fraude, etc.) sem nenhuma infraestrutura inicial para isso. As ideias atuais que encontramos e implementamos em nosso sistema nos ajudam a detectar e analisar muitas atividades fraudulentas. Neste artigo gostaria de falar sobre os princípios que seguimos e o que fizemos para chegar ao estado atual do nosso sistema, sem entrar na parte técnica.
Princípios do nosso sistema
Ao ouvir termos como “automático” e “fraude”, provavelmente você começará a pensar em aprendizado de máquina, Apache Spark, Hadoop, Python, Airflow e outras tecnologias do ecossistema da Fundação Apache e do campo de ciência de dados. Acho que há um aspecto do uso dessas ferramentas que normalmente não é mencionado: elas exigem certos pré-requisitos em seu sistema corporativo antes que você possa começar a usá-las. Resumindo, você precisa de uma plataforma de dados corporativos que inclua um data lake e um warehouse. Mas e se você não tiver essa plataforma e ainda precisar desenvolver essa prática? Os seguintes princípios que compartilho abaixo nos ajudaram a chegar a um ponto em que podemos nos concentrar em melhorar nossas ideias, em vez de encontrar uma que funcione. No entanto, este não é um patamar de projeto. Ainda há muita coisa no plano do ponto de vista tecnológico e de produto.
Princípio 1: Valor comercial em primeiro lugar
Colocamos o “valor comercial” na vanguarda de todos os nossos esforços. Em geral, qualquer sistema de análise automática pertence ao grupo dos sistemas complexos com alto nível de automação e complexidade técnica. Criar uma solução completa levará muito tempo se você criá-la do zero. Decidimos colocar o valor comercial em primeiro lugar e a integridade tecnológica em segundo. Na vida real, isto significa que não aceitamos a tecnologia avançada como dogma. Escolhemos a tecnologia que funciona melhor para nós no momento. Com o tempo, pode parecer que teremos que reimplementar alguns módulos. Este é o compromisso que aceitámos.
Princípio 2: Inteligência Aumentada
Aposto que a maioria das pessoas que não estão profundamente envolvidas no desenvolvimento de soluções de aprendizado de máquina podem pensar que o objetivo é substituir os humanos. Na verdade, as soluções de aprendizagem automática estão longe de ser perfeitas e apenas em determinadas áreas a substituição é possível. Rejeitamos essa ideia desde o início por vários motivos: dados desequilibrados sobre atividades fraudulentas e a incapacidade de fornecer uma lista abrangente de recursos para modelos de aprendizado de máquina. Em contraste, escolhemos a opção de inteligência aprimorada. Este é um conceito alternativo de inteligência artificial que se centra no papel de apoio da IA, enfatizando o facto de que as tecnologias cognitivas se destinam a melhorar a inteligência humana em vez de a substituir. [1]
Diante disso, desenvolver uma solução completa de machine learning desde o início exigiria um esforço enorme, o que atrasaria a criação de valor para o nosso negócio. Decidimos construir um sistema com um aspecto de aprendizado de máquina de crescimento iterativo sob a orientação de nossos especialistas no domínio. A parte desafiadora do desenvolvimento de tal sistema é que ele deve fornecer aos nossos analistas casos não apenas em termos de se tratar de atividade fraudulenta ou não. Em geral, qualquer anomalia no comportamento do cliente é um caso suspeito que os especialistas precisam investigar e responder de alguma forma. Apenas uma fração destes casos relatados pode realmente ser classificada como fraude.
Princípio 3: Plataforma de análise rica
A parte mais desafiadora do nosso sistema é a verificação ponta a ponta do fluxo de trabalho do sistema. Analistas e desenvolvedores devem obter facilmente conjuntos de dados históricos com todas as métricas usadas para análise. Além disso, a plataforma de dados deve fornecer uma maneira fácil de complementar um conjunto existente de métricas com novos. Os processos que criamos, e estes não são apenas processos de software, devem permitir-nos recalcular facilmente períodos anteriores, adicionar novas métricas e alterar a previsão dos dados. Poderíamos conseguir isso acumulando todos os dados que nosso sistema de produção gera. Nesse caso, os dados gradualmente se tornariam um incômodo. Precisaríamos armazenar uma quantidade crescente de dados que não usamos e protegê-los. Num tal cenário, os dados tornar-se-ão cada vez mais irrelevantes ao longo do tempo, mas ainda requerem os nossos esforços para os gerir. Para nós, o acúmulo de dados não fazia sentido, então decidimos adotar uma abordagem diferente. Decidimos organizar armazenamentos de dados em tempo real em torno das entidades alvo que pretendemos classificar, e armazenar apenas os dados que nos permitam verificar os períodos mais recentes e relevantes. O desafio desse esforço é que nosso sistema é heterogêneo, com vários armazenamentos de dados e módulos de software que exigem um planejamento cuidadoso para operar de maneira consistente.
Conceitos de design do nosso sistema
Temos quatro componentes principais em nosso sistema: sistema de ingestão, computacional, análise de BI e sistema de rastreamento. Eles servem a propósitos específicos e isolados, e nós os mantemos isolados seguindo abordagens de design específicas.
Design baseado em contrato
Em primeiro lugar, concordamos que os componentes deveriam depender apenas de determinadas estruturas de dados (contratos) que são passadas entre eles. Isso facilita a integração entre eles e não impõe uma composição (e ordem) específica de componentes. Por exemplo, em alguns casos isto permite-nos integrar diretamente o sistema de admissão com o sistema de rastreamento de alertas. Nesse caso, isso será feito de acordo com o contrato de alerta acordado. Isso significa que ambos os componentes serão integrados por meio de um contrato que qualquer outro componente pode utilizar. Não adicionaremos um contrato adicional para adicionar alertas ao sistema de rastreamento a partir do sistema de entrada. Esta abordagem requer a utilização de um número mínimo pré-determinado de contratos e simplifica o sistema e as comunicações. Essencialmente, adotamos uma abordagem chamada “Contract First Design” e a aplicamos a contratos de streaming. [2]
Transmitindo em qualquer lugar
Salvar e gerenciar o estado de um sistema levará inevitavelmente a complicações na sua implementação. Em geral, o estado deve ser acessível a partir de qualquer componente, deve ser consistente e fornecer o valor mais atual em todos os componentes e deve ser confiável com os valores corretos. Além disso, ter chamadas para armazenamento persistente para recuperar o estado mais recente aumentará o número de operações de E/S e a complexidade dos algoritmos usados em nossos pipelines em tempo real. Por causa disso, decidimos remover completamente o armazenamento de estado do nosso sistema, se possível. Esta abordagem requer que todos os dados necessários sejam incluídos no bloco de dados transmitido (mensagem). Por exemplo, se precisarmos calcular o número total de algumas observações (o número de operações ou casos com determinadas características), calculamos na memória e geramos um fluxo de tais valores. Os módulos dependentes usarão partição e lote para dividir o fluxo em entidades e operar com os valores mais recentes. Essa abordagem eliminou a necessidade de armazenamento em disco persistente para esses dados. Nosso sistema usa Kafka como corretor de mensagens e pode ser usado como banco de dados com KSQL. [3] Mas usá-lo teria vinculado fortemente nossa solução ao Kafka, e decidimos não usá-lo. A abordagem que escolhemos nos permite substituir o Kafka por outro corretor de mensagens sem grandes alterações internas no sistema.
Este conceito não significa que não utilizemos armazenamento em disco e bancos de dados. Para testar e analisar o desempenho do sistema, precisamos armazenar uma quantidade significativa de dados em disco que represente várias métricas e estados. O ponto importante aqui é que os algoritmos em tempo real não dependem de tais dados. Na maioria dos casos, usamos os dados armazenados para análise off-line, depuração e rastreamento de casos e resultados específicos que o sistema produz.
Problemas do nosso sistema
Existem certos problemas que resolvemos até certo nível, mas exigem soluções mais ponderadas. Agora gostaria apenas de mencioná-los aqui porque cada ponto vale seu próprio artigo.
- Ainda precisamos definir processos e políticas que apoiem a acumulação de dados significativos e relevantes para a nossa análise, descoberta e exploração automatizada de dados.
- Incorporação dos resultados da análise humana no processo de configuração automática do sistema para atualizá-lo com os dados mais recentes. Isto não está apenas atualizando nosso modelo, mas também atualizando nossos processos e melhorando nossa compreensão de nossos dados.
- Encontrar um equilíbrio entre a abordagem determinística de IF-ELSE e ML. Alguém disse: “ML é uma ferramenta para os desesperados”. Isso significa que você desejará usar o ML quando não entender mais como otimizar e melhorar seus algoritmos. Por outro lado, a abordagem determinística não permite a detecção de anomalias que não foram previstas.
- Precisamos de uma maneira simples de testar nossas hipóteses ou correlações entre as métricas dos dados.
- O sistema deve ter vários níveis de resultados verdadeiramente positivos. Os casos de fraude representam apenas uma fração de todos os casos que podem ser considerados positivos para o sistema. Por exemplo, os analistas querem receber todos os casos suspeitos para verificação, e apenas uma pequena parte deles são fraudes. O sistema deve apresentar todos os casos aos analistas de forma eficiente, independentemente de se tratar de fraude real ou apenas de comportamento suspeito.
- A plataforma de dados deve ser capaz de recuperar conjuntos de dados históricos com cálculos gerados e calculados dinamicamente.
- Implante de forma fácil e automática qualquer um dos componentes do sistema em pelo menos três ambientes diferentes: produção, experimental (beta) e para desenvolvedores.
- E por último mas não menos importante. Precisamos construir uma plataforma rica de testes de desempenho na qual possamos analisar nossos modelos. [4]
referências
Fonte: habr.com