A IA por trás do Uplift

20 de agosto, 2025
 ·  10 minutos

Após o lançamento do para utilização do público, depois de um piloto bem-sucedido, achamos que seria interessante aprofundar a engenharia por trás do Uplift.

Esta nota vem na sequência do artigo “How Adyen does AI”, onde explicamos como a Adyen entende a IA e o progresso geral, bem como a direção que estamos a tomar. Este artigo expande o papel que a IA desempenha na otimização de cada transação que flui através da plataforma.

A IA é o único caminho a seguir

À semelhança do conceito da Adyen, de fornecer capacidades de ponta a ponta numa única plataforma, o mesmo se aplica a uma única transação.  

Todas as etapas do fluxo de pagamentos estão interconectadas. Cada etapa do processo de pagamento está condicionada à anterior, criando uma complexa rede de dependências. Por exemplo, a experiência de pagamento oferecida a um cliente depende do risco previsto, que, por sua vez, é influenciado pelo resultado da autenticação e da escolha dos canais de pagamento, que, por sua vez, afeta os custos. Também determina a estratégia da nova tentativa se o pagamento falhar. 

Para navegar neste processo mais complexo, investimos no desenvolvimento de um sistema que toma decisões globalmente ótimas ao longo de todo o percurso do pagamento. Porém, ao mesmo tempo, os seres humanos gostam de controlo e compreensão, mesmo que isso possa levar a muitos erros. Para dar resposta a esta necessidade, sistemas como o Revenue Protect (antigo) expunham um menu interminável de condições que formavam regras (“se isto, então aquilo”). Embora a sensação de estar, aparentemente, em controlo, seja bem-vinda, o que realmente importa são os dados. De facto, a qualidade de qualquer sistema não é determinada pela forma como foi concebido, mas sim pelo seu desempenho. 

Reunir estas duas premissas em harmonia é a única resposta para escalar tanto em complexidade como em volume, ao mesmo tempo que se proporciona o máximo desempenho global, e não local, é delegar a decisão na máquina. Inerentemente, dada a complexidade dos padrões, a única forma de avançar é permitir que a máquina os aprenda a partir dos dados (nota: não se vê todos os dados, teaser para baixo).

Como em qualquer aplicação de IA, o papel dos humanos não é o de competir com a máquina pelas suas decisões ou conteúdos, mas sim supervisionar o seu comportamento. 

Esta publicação apresenta em pormenor algumas das decisões, engenharia e ciência por trás da IA do Uplift.

Parte 1: Conceito

No passado, implementámos modelos de ML para otimizar localmente cada passo de uma transação de forma isolada. Por exemplo, um modelo de deteção de fraude preveria a probabilidade de um chargeback e bloquearia uma transação se a probabilidade prevista fosse superior a um determinado limite.

A IA subjacente ao Uplift altera este paradigma. Foi concebida em torno do contexto de um processo de tomada de decisão e consiste numa coleção de modelos de aprendizagem automática de várias naturezas que partilham consciência e conhecimento. Estes modelos são otimizados globalmente através da Aprendizagem por Reforço e partilham o mesmo objetivo: equilibrar a fraude, o curso e a conversão em harmonia.

Parte 2: Engenharia

Vamos rever alguns dos números da Plataforma da Adyen de 2023:

  • Volume processado de 1 trilhão de dólares através da plataforma

  • Crescimento de 26% ano a ano

  • SLA para processamento de transações: 1 segundo, incluindo as comunicações com o adquirente, que consomem cerca de 600 ms.

Agora, vamos considerar os números da plataforma da Adyen durante a Black Friday/Cyber Monday em 2024 (4 dias)

  • Número de transações: 670 milhões

  • Taxa de pico de transações: 163 mil por minuto (2.7 mil transações por segundo)

  • Pico de solicitações de API: 25 mil por segundo

  • Tempo de atividade da API: 99.9999%

Embora os números sejam impressionantes, tornam-se ainda mais surpreendentes quando consideramos que todas estas transações foram impulsionadas por IA ao longo do seu percurso na plataforma da Adyen. Cada transação passou por entre 2 a 5 pontos de contacto com IA, onde um modelo de machine learning tomava decisões, com uma latência atribuída de 20 ms (mediana).

Isto é possível graças a um conjunto de componentes cuidadosamente concebidos e desenvolvidos.

Nota: todos os fluxos críticos da Adyen funcionam em infraestruturas próprias (on-premise). Isto significa que todos os componentes aqui mencionados, incluindo o hardware de computação, são concebidos, desenvolvidos, implementados, testados e operados pela própria Adyen. Dependemos fortemente de software open source, como se pode concluir pela tecnologia stack  referida. Uma vez instalada a infraestrutura, a propriedade e o controlo total de toda a vertical permitem-nos implementar alterações de forma rápida, sem dependências de terceiros no que toca à fiabilidade.

Plataforma de Features

A IA está ligada a uma Plataforma de Features que fornece vetores de entrada com baixa latência, elevada cardinalidade, grande volume e abrangência geográfica tanto para os serviços de treino como de inferência. Para features mais lentas e complexas, utilizamos computação distribuída através do Spark, e para features rápidas recorremos ao Apache Flink, armazenando e disponibilizando os dados numa base de dados Cassandra, implementada em diferentes data centers espalhados pelo mundo, de forma a responder aos requisitos de localidade e latência.

A Plataforma de Features permite disponibilizar features com uma cardinalidade na ordem das dezenas de milhares de milhões e uma latência de resposta de apenas alguns milissegundos. Abordamos o design e as decisões associadas a esta arquitetura nesta apresentação na Codemotion 2023 e neste

Serviço de Inferência

Depois de um modelo ser treinado, o seu artefacto é registado, armazenado e disponibilizado. O serviço de inferência (que chamamos de “Alfred”) permite aos cientistas criarem uma experiência, selecionarem um modelo, definirem uma baseline e implementarem o modelo com uma divisão de tráfego definida pela própria cientista.

O Alfred cria um endpoint de API interno que se liga ao fluxo de pagamentos (relembrando que este é um fluxo altamente crítico) e assume a responsabilidade de responder a cada pedido com um p50 de 20 ms e um p99 de 100 ms. O tamanho do artefacto e a arquitetura de disponibilização são fundamentais para alcançar este desempenho. Como nota adicional, tornamo-nos bastante experientes na remoção de qualquer indexação, metadados ou caminhos auxiliares em ficheiros pickle do numpy ou pandas. Diretos ao essencial!

O serviço de inferência também é responsável pela gestão dos modelos. Seguimos um modelo de principal–challenger para cada implementação (sendo que uma implementação é considerada uma experiência, como explicado abaixo). O Alfred rotula um — e apenas um — modelo como “principal”, ou seja, o modelo que é utilizado na grande maioria do tráfego e que apresenta o melhor desempenho entre todas as versões. Novos modelos são lançados como parte de experiências e passam por diferentes fases: (1) "Ghost", onde apenas registamos telemetria e estatísticas, sem qualquer influência nos resultados; (2) "Challenger", onde o modelo começa a influenciar os resultados para uma determinada percentagem de tráfego — e continuamos a registar telemetria. Quando um modelo desafiante demonstra um desempenho superior ao modelo principal com confiança estatística, o modelo principal é descontinuado (passa a "retired") e o desafiante é promovido a novo modelo “principal”.

Serviço de Experimentação

Todas as implementações de modelos funcionam sobre um serviço de experimentação que é utilizado para quantificar o desempenho de cada modelo (seja principal, fantasma ou desafiante) com rigor científico, enquadrado como uma experiência (ou seja, uma hipótese a testar). Fazemo-lo através de testes A/B/n e da comparação das estatísticas de cada modelo com um grupo de controlo unificado, garantindo que a experiência é disponibilizada com rollouts graduais, de forma a tirar partido da experiência.

O grupo de controlo unificado é uma divisão do tráfego que se mantém consistente em todos os elementos de uma transação e onde os modelos não atuam. É, de facto, utilizado para rastrear transações e servir de base de comparação para todos os modelos. Note-se que continuamos a atuar sobre o grupo de controlo, uma vez que definimos a base como uma “base de mercado” – ou seja, um nível de qualidade na experiência de pagamento que qualquer prestador de serviços de pagamento competente deveria oferecer. Para nós, esta base inclui bloquear cartões que sabemos terem sido roubados, aplicar isenção de SCA (autenticação forte do cliente), forçar um token de rede e repetir com um desafio se a autenticação falhar. Isto resulta num cálculo de melhoria inferior, mas mais honesto, para o nosso sistema.

Parte 3: Escala

Resolução de Entidades

Uma das maiores bases de dados da Adyen é um gráfico que liga entre si os atributos das transações, com o objetivo de reconhecer entidades. Este gráfico representa uma poderosa fonte de informação que podemos modelar para extrair características, bem como utilizar em processos de treino (de modelos).

Sob diretrizes rigorosas do PCI, do RGPD (Regulamento Geral sobre a Proteção de Dados) e orientados também pelos nossos elevados padrões éticos, podemos utilizar esta informação para decisões baseadas no risco e para análises de diligência devida. Estimamos que já tenhamos observado mais de mil milhões de indivíduos em todo o mundo a transacionar através da plataforma da Adyen. Como o gráfico contém todos os atributos das transações, atualmente é composto por mais de 100 mil milhões de nós e 300 mil milhões de ligações (arestas).

Historicamente, temos armazenado estes dados em bases de dados Postgres, que oferecem uma excelente solução em termos de tempo de resposta, mas são limitadas na complexidade do processamento (lógica de ligação) e no volume de dados. Para ultrapassar estas limitações, estamos a migrar o sistema para uma arquitectura-lambda com uma abordagem híbrida: um fluxo online baseado na Cassandra, que realiza as ligações de forma mais eficiente e permite um nível adicional de complexidade; e um fluxo offline, que executa cálculos complexos e corrige, a cada hora, a base de dados online — seja criando novas ligações, seja desfazendo ligações erradas. Chamamos a este sistema CELL (Customer Event Linking Logic).

Capacidade de Processamento e Armazenamento

Implementar Inteligência Artificial à nossa escala implica, inevitavelmente, tirar partido dos dados que a suportam. Para isso, investimos na infraestrutura e nos frameworks necessários para gerir este processo de forma eficaz. Eis alguns números gerais da plataforma de dados da Adyen atualmente (Janeiro de 2025):

  • + 1500 nós

  • 600 TB de RAM

  • 60.000 núcleos de CPU

  • 70 PB de armazenamento

  • 96 GPUs NVidia A100 Tensor Core com NVLink Bridge

  • + 1000 DAGs executados diariamente ou sob pedido na plataforma (dependemos fortemente do Airflow e do Spark)

Investimos continuamente na modernização e na garantia de capacidade para o futuro. E quando dizemos "continuamente", referimo-nos ao facto de termos os processos, o talento e a cultura necessários para operar a nossa própria cloud, assegurando que está sempre disponível e atualizada.

Regulação, Autenticação e Cofres de Tokens

A escala não diz apenas respeito ao volume de dados, à latência ou ao tempo de atividade. Está também relacionada com as responsabilidades que assumimos à medida que cada vez mais clientes confiam na Adyen para processar os seus pagamentos e serviços financeiros. Isto exige que forneçamos soluções técnicas que cumpram, de forma intrínseca, as regulamentações — ao mesmo tempo que respondem às necessidades de escalabilidade do nosso negócio.

Neste sentido, temos vindo a implementar as diretivas de Autenticação Forte do Cliente (Strong Customer Authentication) no âmbito da PSDx, e a ultrapassar os limites de como estar em conformidade com os regulamentos, enquanto lançamos produtos que ajudam os nossos comerciantes a aumentar as taxas de conversão. O Uplift utiliza mecanismos de decisão para escolher o melhor “caminho” de autenticação, equilibrando fraude, conversão e custo. Pode optar entre várias ações disponíveis, como uma isenção, uma versão do 3DS ou uma passkey.

Da mesma forma, escalamos o nosso cofre de tokens e atualmente alojamos mais de 2 mil milhões de tokens, que protegem dados altamente sensíveis em conformidade com os regulamentos do PCI. Por exemplo, a inteligência artificial do Uplift pode decidir tokenizar, utilizar um token ou substituir um token por um PAN, com base em objetivos globais de otimização.

A IA será tão eficaz quanto o conjunto de ações que pode escolher. Dentro do Uplift, criámos todas essas ações, sempre respeitando as regulamentações, que, em grande escala, permitem libertar o verdadeiro desempenho da IA.

Parte 4: Ciência

Decisão Holística Conectada

Uma das decisões mais desafiantes é ligar um conjunto de modelos de machine learning independentes a um objetivo comum. A versão atual do Uplift utiliza a passagem de mensagens, que oferece uma abordagem simples, mas eficiente, para criar uma consciência sobre a qual os modelos podem condicionar as suas estimativas, aproximando-se assim de um ótimo global.

Já experimentamos utilizar artefactos maiores e modelos complexos de deep learning capazes de combinar múltiplas decisões, mas verificámos que frequentemente comprometem os requisitos de engenharia (latência, tempo de atividade) das implementações online em fluxos críticos. No entanto, continuamos a investigar esta abordagem, bem como a ultrapassar os limites do que é possível em termos de engenharia, e esperamos migrar toda a pipeline para arquiteturas de deep learning num futuro próximo (ver abaixo).

Estamos a desenvolver uma investigação ativa nesta área: financiámos uma posição completa de doutoramento no AMLAB da UVA para nos ajudar a resolver este problema a partir da perspetiva de Aprendizagem por Reforço (Reinforcement Learning). Já partilhamos algum trabalho com a comunidade nesta área, numa apresentação feita nesta conferência. 

Avaliação Off-policy

Realizar testes A/B é dispendioso em termos de tempo e dinheiro. Se implementar um mau variante, isso acarreta custos, e a quantidade de tráfego necessária para atingir significância estatística pode demorar bastante tempo. Além disso, existe um limite máximo do número de experiências que pode executar num ano, o que pode atrasar a descoberta de uma variante vencedora e resultar em perda de receitas. Adicionalmente, estes testes implicam uma carga operacional e cognitiva, além de “sacrificar” uma parte do tráfego para testar uma hipótese. Em organizações de produto mais maduras, os testes A/B frequentemente apresentam resultados neutros ou insignificantes, o que representa tempo perdido.

Para esse efeito, temos vindo a desenvolver uma investigação em Avaliação Off-Policy, que nos permite, essencialmente, realizar testes A/B offline. Novas variantes podem ser testadas instantaneamente, com uma alta correlação (+80%) com as estimativas On-Policy (testes A/B reais). Isto permitiu poupar-nos, estimadamente, 20 semanas por ano de tempo perdido em testes A/B sem resultados significativos, bem como um aumento de 9 para 54 milhões de transações num período de seis meses.

Esta investigação foi submetida ao RecSys ’25, e um preprint encontra-se disponível no arXiv.

Contrafactual e Inferência Causal

À nossa escala, compreender as causas que determinam os resultados de uma experiência é mais uma necessidade do que um interesse, uma vez que isso permitiria detetar fontes sistémicas de entropia que poderíamos evitar no futuro.

Na mesma linha de pensamento, se aplicássemos uma decisão numa transação (por exemplo, bloqueando-a devido à possibilidade de fraude), não teríamos acesso ao resultado caso não tivéssemos agido. Em termos estatísticos, isto chama-se um contrafactual. Para aprender a distribuição completa do tráfego, seria necessário não agir sobre o tráfego, o que invalidaria o propósito do sistema.

Grupos de controlo, randomização e tráfego de exploração ajudam a mitigar este problema, mas aprofundar disciplinas como a Inferência Causal permite-nos compreender melhor as razões subjacentes aos resultados das experiências, bem como ultrapassar as limitações dos contrafactuais.

Estamos também a investir em investigação nesta área, financiando outra posição de doutoramento no AMLAB da UVA para trabalhar em inferência causal aplicada a conjuntos de dados como os nossos e na nossa escala. Os investigadores que realizam o seu doutoramento têm o objetivo de alargar os limites da investigação e publicar artigos, enquanto podem colaborar com a equipa de engenharia da Adyen para implementar e testar hipóteses. Como exemplo, estamos a desenvolver um simulador de transações com Inteligência Artificial Generativa, que generaliza distribuições, contrafactuais e informação pessoal identificável (PII), permitindo-nos avaliar algoritmos e técnicas antes de executar experiências com divisões reais de tráfego.

Fraca supervisão

As etiquetas são difíceis por duas razões: quantidade e qualidade. Dada a dimensão dos nossos dados, temos etiquetas suficientes para treinar modelos e, assim, podemos usar técnicas de balanceamento, como o downsampling, e ainda obter dados suficientes para treinar os nossos modelos. No entanto, não estamos a tirar proveito de todo o poder preditivo, porque as etiquetas normalmente chegam tarde, ou não chegam ou chegam incompletas. Para resolver isto, temos vindo a desenvolver uma investigação na área da Weak Supervision. O princípio da Weak Supervision é que o processo de modelação beneficia mais de uma maior quantidade de dados, mesmo que estes sejam ruidosos, ao invés de uma menor quantidade de dados de alta qualidade. Mais precisamente, para uma quantidade fixa de dados de alta qualidade, adicionar dados ruidosos pode ser mais benéfico.

A Weak Supervision alimenta o “Ciclo Virtuoso dos Dados da Adyen”, que combina esforços no aumento da qualidade e quantidade de etiquetas juntamente com a Aprendizagem Ativa (trabalho futuro, ver abaixo). Utilizando a Weak Supervision em produção, aumentámos a recall em +22%, reduzimos a perda na taxa de autorização em -46% e alcançámos um ganho de +13% na taxa de recusa do emissor, melhorando a eficiência na deteção de fraude.

Exploração aleatória não uniforme para contextual bandits

Ao executar uma experiência em tempo real, com tráfego real, num sistema de Aprendizagem por Reforço (RL), enfrenta-se o dilema entre executar a ação que proporciona a melhor recompensa, com base no conhecimento acumulado até ao momento (exploração), e garantir que esse conhecimento continua válido, evitando agir cegamente com base numa verdade desatualizada (exploração).

A técnica mais simples que se pode adotar chama-se epsilon-greedy, onde uma percentagem aleatória do tráfego, epsilon, é reservada para explorar (normalmente escolhendo uma ação subótima dentro do espaço de ações disponível). Existem várias linhas de investigação para escolher a melhor próxima ação que permita continuar a explorar, mantendo simultaneamente uma linha base subótima, mas competitiva, durante a exploração. Temos investigado e implementado experiências em toda a plataforma com várias técnicas e encontramos resultados significativos em técnicas relacionadas com Regression Oracles.

Esta investigação foi submetida ao WWW ’25, e um preprint está disponível no arxiv: .

Deep Learning & Ensembling

Um dos nossos princípios culturais é o de procurar simplicidade e criar soluções para problemas, e não problemas para as soluções que queremos utilizar. Por isso, algoritmos clássicos de machine learning, como as árvores de decisão com boosting, continuam a fornecer uma base sólida para a maioria dos problemas de classificação e regressão cujo input é um dado estruturado, e têm constituído — e por vezes ainda constituem — as nossas principais referências. Temos realizado, e continuamos a realizar, experiências (ver motor de experimentação) onde implementamos conjuntos heterogéneos complexos de redes neurais para scoring online no fluxo de pagamentos, e não só alcançámos um desempenho ao nível dos boosting, como o superamos, com melhorias de performance que justificam o aumento da carga operacional e da complexidade.

Nota: na verdade, utilizar Inteligência Artificial Generativa (ou seja, um LLM) não é uma tecnologia que resolva diretamente este problema. No entanto, inspirámo-nos no trabalho de empresas como a Hyperplane (excelente produto, excelente equipa), que criaram modelos offline através de redes maiores baseadas na arquitetura Transformer, eliminando a necessidade de conceção explícita de features (ver ponto seguinte).

Arquitetura Transformer

Estamos a experimentar o uso do Pré-treino Não Supervisionado e Transformers para explorar todo o potencial da nossa base de dados e incorporar os enviesamentos indutivos adequados no nosso processo de modelação.

Para além dos nossos esforços em utilizar mais dados — como a weak supervision ou a aprendizagem ativa — estamos também a explorar abordagens que nos permitam mudar completamente o paradigma supervisionado e, assim, libertar todo o potencial dos nossos dados. Inspirados pelos avanços recentes na auto-supervisão aplicada à modelação de linguagem, estamos a aplicar os mesmos padrões de pré-treino não supervisionado a dados de pagamentos. Ao inferir etiquetas a partir da própria estrutura dos dados, conseguimos uma supervisão sem intervenção humana, desbloqueando assim o verdadeiro valor dos nossos conjuntos de dados.

Tal como as frases são sequências de palavras, os compradores são sequências de transações — esta é a estrutura de dados central da Adyen: sequências de transações por comprador. As abordagens tradicionais de modelação tendem a ignorar esta premissa, modelando as sequências de forma independente ou recorrendo a soluções alternativas como agregações por comprador em momentos específicos (point-in-time). No entanto, a arquitetura Transformer permite-nos adotar uma abordagem diferente para explorar o poder preditivo destas estruturas.

Assim, os Transformers e a auto-supervisão estão a permitir-nos construir um modelo fundamental para pagamentos, treinado com milhares de milhões de transações, o que nos permite iniciar qualquer processo de modelação com uma escala sem precedentes. Através de fine-tuning downstream e de embeddings de entidades, estamos a melhorar os insights sobre os compradores, a reforçar a deteção de fraude e a abrir novas oportunidades de investigação — como, por exemplo, a geração de dados sintéticos.

Observabilidade

Depois de os modelos serem implementados e quantificados através de uma experiência, executamos constantemente diagnósticos para garantir que o desempenho se mantém estável. Executamos a deteção de drift clássica (normalmente enquadrada no âmbito de MLOps) bem como algoritmos mais complexos para detetar desvios no desempenho do negócio e enviesamentos, como por exemplo, combinações de algoritmos MIST (Decomposição de Múltiplas Sazonalidades Irregulares e Tendências) e DTW (Dynamic Time Warping). Abordámos estes aspetos na PyData 2024.

Equidade e explicabilidade

A delegação de decisões às máquinas traz, inevitavelmente, desafios relacionados com a garantia de que essas decisões não apresentam enviesamentos que possam segmentar demografias ou ser consideradas injustas do ponto de vista humano.

Para isso, estabelecemos um grupo de trabalho interno composto por especialistas técnicos e legais, com o objetivo de acompanhar a regulamentação, incluindo o RGPD e o AI Act. Implementámos também alterações procedimentais para garantir que a Adyen se mantém fiel à sua cultura: uma empresa altamente ética. Todos os produtos e modelos precisam de ser avaliados quanto a enviesamentos e analisados no sentido de identificar potenciais violações dos regulamentos e manuais internos. Uma vez aprovados pelo grupo de trabalho, monitorizamos os modelos através de ferramentas de observabilidade para garantir que certas características sensíveis não conduzem a sobreajuste.

Todas as decisões tomadas por inteligência artificial devem ser explicáveis. Para tal, cada chamada de inferência é registada, e os algoritmos que fundamentam essas decisões são avaliados (por exemplo, através de valores SHAP). A interface do Adyen Uplift apresenta uma explicação para cada decisão tomada por transação.

Linhas de trabalho futuras

Embora este texto ofereça uma visão geral do funcionamento interno, dos desafios e das lições aprendidas no desenvolvimento e implementação do Adyen Uplift, é evidente que ainda só alcançamos uma parte do caminho que pretendemos percorrer.

Estamos ativamente a investigar os domínios mencionados acima, bem como outras áreas que apresentam resultados promissores em fases iniciais, como Agentic Flows, Alignment, Weak Supervision + Active Learning Flywheel e Identity Representation Learning com Privacidade Diferencial.

Neste artigo, oferecemos uma visão transparente e factual sobre a tecnologia por trás do Adyen Uplift. Estamos sempre à procura de talento excecional para integrar a nossa equipa excecional. Se o conteúdo desta publicação fizer sentido para si, convidamos-lhe a visitar a nossa página de carreiras!

Novidades frescas diretamente na sua caixa de entrada

Mande sua solicitação