Durante a maior parte da última década, se você precisava de um modelo de aprendizado de máquina para detecção de fraudes, PLD (AML) ou crédito que funcionasse bem em produção, você treinava uma árvore com gradient boosting. O XGBoost não venceu porque a pesquisa acadêmica não tinha nada melhor, ele venceu porque nada se comparava ao seu custo, sua velocidade e à facilidade de explicá-lo. Já o deep learning significava treinamento caro em GPUs para cada cliente, inferência mais lenta e um modelo que as equipes de risco teriam que defender como uma caixa-preta. 

A Oscilar também funcionava assim. Criávamos um modelo dedicado para cada cliente e tipo de risco, com um cientista de dados fazendo ajustes e retreinando à medida que novos dados rotulados chegavam. Funciona. Mas também é lento para construir, fica desatualizado entre os retreinamentos e cada novo cliente gera outro modelo para manter. Nenhum desses modelos aprende nada com os outros.

Então, nossa equipe de ciência de dados fez uma pergunta diferente:

Seria possível um único modelo atender a todos os clientes e tipos de risco, manter-se atualizado a cada resultado confirmado e ainda ser tão explicável quanto o XGBoost?

Esse é o modelo de fundação tabular que construímos. Este post explica nosso raciocínio, incluindo o que é um modelo de fundação tabular, as três maneiras pelas quais o setor aplica modelos de fundação ao risco e por que escolhemos esta abordagem.

O que é um modelo de fundação tabular?

Um modelo de fundação tabular é pré-treinado com grandes volumes de dados estruturados em linhas e colunas. Com isso, ele pode fazer previsões em uma nova tabela sem nunca ter visto esses dados antes ou ter sido treinado neles. Em vez de ser retreinado com os dados de cada cliente, ele lê os exemplos rotulados e a transação recebida como contexto no momento da decisão, retornando uma pontuação diretamente.

"Modelo de fundação" virou sinônimo de chatbots, mas os grandes modelos de linguagem (LLMs) são apenas uma vertente. A ideia por trás disso é mais ampla, assim como a arquitetura. A maioria dos modelos de fundação, incluindo os LLMs, baseia-se em transformers, e eles existem em diferentes formatos. O nosso é um transformer feito para tabelas. Em vez de ler palavras em uma frase, ele lê linhas e colunas, usando mecanismos de atenção para avaliar quais exemplos anteriores e variáveis importam mais para a transação em análise. Você pré-treina o modelo uma vez em um conjunto amplo e variado de dados para que ele aprenda padrões gerais e, a partir daí, ele pode lidar com novas tarefas sem precisar ser treinado do zero.

Quando você faz uma pergunta a um LLM, ele não passa por um retreinamento para responder. Ele lê seu comando e responde. Um modelo de fundação tabular faz o mesmo com linhas e colunas. O "comando" é o histórico rotulado do cliente: transações, propostas, contas e os resultados confirmados para elas. A resposta é uma pontuação de risco.

A entrada não contém texto livre, portanto o modelo não corre o risco de alucinar. Ele lê os mesmos dados estruturados que nossos modelos já utilizam. Além disso, é um modelo diferente dos LLMs usados em nosso AI Copilot e agentes. Nós mesmos hospedamos o modelo de risco, sem nenhuma API de terceiros no processo de decisão.

Três maneiras de aplicar modelos de fundação a decisões de fraude e risco

O mercado tem adotado basicamente três abordagens.

1. Embeddings enviados para outro modelo. Esse é o caminho escolhido pelas arquiteturas TabBert, FATA-Trans e TransTab. Cada transação se transforma em um vetor de alta dimensão, que é enviado para um classificador, como o XGBoost, ao lado dos atributos existentes. Isso pode trazer melhorias, mas também adiciona um segundo modelo. A decisão passa a depender de centenas de dimensões inexplicáveis, e gerar esses vetores em tempo real tem um custo alto. 

2. Modelos de fundação relacionais. O KumoRFM é o exemplo mais conhecido dessa abordagem. A vantagem é a capacidade de ler várias tabelas ao mesmo tempo, eliminando a engenharia de atributos. No entanto, há grandes desvantagens: custos computacionais elevados, necessidade de retreinamento diário e uso de um modelo destilado para cumprir os requisitos de latência. Eles também geram embeddings em vez de pontuações diretas — o que significa que um modelo secundário ainda toma a decisão — e qualquer mudança de esquema afeta todo o processo. As alterações levam pelo menos um dia para entrar em vigor, tornando o modelo pouco ágil, principalmente contra fraudes que mudam em questão de 15 minutos. Por fim, não oferecem explicabilidade, o que é essencial em casos de fraude e crédito.

3. Modelos de fundação tabulares. Operam sobre uma única tabela e geram a pontuação diretamente. O aprendizado acontece durante a própria inferência. Exemplos conhecidos dessa abordagem são o TabPFN e o TabICL. 

Optamos pela terceira abordagem, cientes dos desafios envolvidos. Um modelo tabular não elimina a engenharia de atributos, por isso automatizamos essa etapa. Ele também não atende nativamente à latência em tempo real exigida na detecção de fraudes, e trazê-lo para menos de 100 milissegundos exigiu um grande esforço de engenharia. Decidimos encarar o trabalho pelo retorno que essa arquitetura proporciona.

Benefícios da abordagem com modelo de fundação tabular

Há cinco vantagens principais em usar um modelo de fundação tabular em comparação com as outras alternativas: 

• O aprendizado ocorre na inferência. Cada novo dado confirmado orienta a próxima decisão, sem rotinas noturnas de retreinamento e sem esperar pelo próximo ciclo do modelo. Isso muda completamente a rotina operacional das equipes de risco.

• Pontuação direta. Um único modelo toma a decisão, sem depender de um segundo classificador de apoio.

• Explicabilidade idêntica à atual. As atribuições por valores SHAP e os códigos de motivo funcionam como no XGBoost, permitindo que auditores e reguladores analisem os mesmos relatórios com que já estão acostumados. Se um processo de compliance exigir o formato tradicional, podemos converter a lógica em um modelo XGBoost padrão.

• Ajuste de variáveis em segundos. Adicionar, remover ou modificar uma variável não exige reconstruir o modelo. Assim que os novos dados chegam, ele já está pronto para operar.

• Um único modelo para fraude, PLD, crédito e risco comportamental/dispositivo. Aprimoramos e mantemos um único sistema em vez de uma frota crescente de modelos isolados. O tempo de desenvolvimento cai de semanas para dias.

Desempenho

Os resultados variam conforme o conjunto de dados e o caso de uso. Em nossos testes, o modelo de fundação tabular aumentou a taxa de detecção (recall) entre 35% e 65% mantendo o mesmo impacto operacional em algumas bases: ele captura mais fraudes sem gerar atrito para bons clientes. Em outros cenários, teve desempenho equivalente ao XGBoost. Mesmo nesses casos, você obtém essa precisão a partir de um único modelo compartilhado que atualiza seu contexto em segundos, sem depender de retreinamentos.

A vantagem fica ainda mais evidente quando há poucos dados históricos disponíveis. Um modelo XGBoost individual precisa de um histórico extenso para ser confiável. Já o modelo de fundação tabular parte do conhecimento adquirido no pré-treinamento, aproveitando muito melhor um volume menor de casos confirmados.

Como o modelo é treinado

O modelo passa por um pré-treinamento prévio com padrões de fraude do setor e cenários de ataque sintéticos, preparados inclusive para identificar padrões inéditos. No momento da decisão, os casos confirmados do próprio cliente entram apenas como contexto.

Os dados e resultados de cada cliente são usados estritamente nas previsões dele mesmo, sem jamais interferir nos resultados de outros clientes.

O modelo ainda depende de dados rotulados. Para alguns casos de uso comuns (como transferências bancárias, PLD, depósitos via cartão e sinais de dispositivo/comportamento), disponibilizamos versões ajustadas prontas para uso imediato. Para os demais cenários, o valor gerado cresce conforme os resultados confirmados são alimentados. Equipes com poucos dados históricos também se beneficiam rapidamente, pois é justamente aí que a vantagem sobre o XGBoost é maior.

Modelos de fundação tabulares versus modelos de consórcio

Modelos de consórcio reúnem dados de diversos participantes para treinar um modelo voltado a um único caso de uso. A grande vantagem é que vêm prontos para uso. Por outro lado, demoram para atualizar, tendem a priorizar participantes maiores, exigem novos ciclos de treinamento para qualquer alteração de variáveis e só reconhecem padrões já vivenciados pelos membros da rede.

Uma boa forma de entender a relação: um modelo de consórcio é como um modelo de fundação cujo contexto você não pode alterar. Os dados que alimentam um consórcio são o mesmo tipo de informação que o modelo tabular lê como contexto. Altere o contexto e você terá um modelo customizado para outro caso de uso, atualizado a cada novo resultado confirmado, e não em ciclos anuais.

O diferencial não está no modelo em si

Não pretendemos competir em escala bruta de treinamento com os grandes laboratórios de IA, nem precisamos disso. A pesquisa sobre modelos tabulares é aberta. O que define se um modelo funciona no ambiente real de risco é tudo o que está ao seu redor: os dados fornecidos, o tempo de resposta, a clareza das justificativas, o monitoramento e a implementação em produção.

É nisso que nossa equipe de ciência de dados se concentra agora. Sem a necessidade de treinar modelos específicos para cada cliente, o foco principal de otimização passa a ser o que chamamos de engenharia contínua de contexto tabular — ou seja, definir exatamente quais dados o modelo deve ver em cada decisão. É uma frente nova, e é nela que continuaremos inovando.

O que isso muda para as equipes de risco

• Modelos mais rápidos. A criação de um modelo, que antes levava meses, hoje leva semanas — e estamos trabalhando para disponibilizar um endpoint ativo para produção em até uma semana.

• Decisões sempre atualizadas. O modelo aprende com as fraudes confirmadas no próprio dia, sem esperar pelo próximo ciclo de retreinamento. Atualizamos o contexto em segundos (5,8 segundos, exatamente) sem interromper a operação.

• A mesma trilha de auditoria. Você mantém os mesmos códigos de motivo e atribuições de variáveis, preservando os padrões exigidos pelos reguladores.

• Uma base mais sólida para agentes de IA. Os agentes investigam casos, redigem relatórios e sugerem regras, enquanto o modelo e suas políticas automatizadas tomam as decisões. Como o modelo fornece códigos de motivo claros, tanto analistas quanto agentes conseguem justificar o que aconteceu.

Em que estágio estamos

O modelo já está em operação com nosso primeiro cliente piloto, e divulgaremos os resultados assim que estiverem consolidados. Fique atento também ao nosso próximo webinar, no qual Saurabh Bajaj e Eddy Fathi demonstrarão a abordagem ao vivo, incluindo uma análise prática de como o modelo toma suas decisões.

Perguntas frequentes

O que é um modelo de fundação tabular?

É um modelo pré-treinado com grandes volumes de dados estruturados em linhas e colunas, capaz de fazer previsões em tabelas inéditas sem precisar de treinamento específico. Ele analisa o histórico rotulado do cliente como contexto no momento da decisão e fornece a pontuação de risco diretamente.

Qual é a diferença entre um modelo de fundação tabular e o XGBoost?

O XGBoost geralmente é treinado para atender a um único cliente e tipo de risco, precisando ser retreinado sempre que chegam novos dados. Já o modelo de fundação tabular atende a múltiplos clientes e cenários de risco, incorporando cada resultado confirmado na decisão seguinte sem novo treinamento. A forma de explicação permanece a mesma: atribuições por SHAP e códigos de motivo.

Reguladores e auditores conseguem avaliar as decisões?

Sim. O modelo fornece os mesmos códigos de motivo e métricas SHAP que o XGBoost. Caso um processo regulatório exija o padrão anterior, o sistema pode ser convertido para um formato XGBoost tradicional.

Um modelo de fundação tabular é um grande modelo de linguagem (LLM)?

Não. Ele processa apenas dados estruturados, sem texto livre, eliminando o risco de alucinações. O modelo é hospedado diretamente pela Oscilar, sem dependência de APIs externas no processo de decisão.

Os dados de um cliente afetam as pontuações de outro?

Não. As informações e os resultados de cada cliente são aplicados exclusivamente nas suas próprias decisões.