Pular para o conteúdo
Caramel.
← Todos os produtos

Produto · Foundation models · Bancos

Aprender o cliente uma vez, responder muitas perguntas

Uma representação do cliente, aprendida uma vez e compartilhada por churn, adoção, fraude e recomendação.

Origem
Um banco líder da Argentina
Setor
Bancos e serviços financeiros
Estágio
Estudo de viabilidade, com demos executáveis

O problema

Num banco, cada pergunta sobre o cliente é resolvida com um pipeline diferente. Uma equipe monta features para churn, outra para fraude, outra para adoção de produtos. Cada uma recomeça pelas mesmas fontes, pelos mesmos joins e pelas mesmas contagens com outro nome, e o caso seguinte leva semanas ou um trimestre para sair.

O que se perde no caminho é a ordem. Um cliente que consulta o saldo e depois transfere não é o mesmo que faz o inverso, mas uma contagem mensal registra os dois igual. O sinal está na sequência, e a sequência é justamente o que as contagens achatam.

A resposta

Um modelo fundacional do cliente inverte a ordem do trabalho. Em vez de construir features para uma pergunta, pré-treina-se um backbone sobre os eventos crus — tipo, valor e tempo — sem rótulos e sem decidir de antemão para que serve. O que ele aprende é uma representação de propósito geral: um vetor por cliente que resume a sua história.

Desse vetor saem as respostas. Churn, adoção de produtos, propensão a operar dólares, fraude, recomendação: cada caso é uma cabeça linear sobre a mesma representação, e não um pipeline novo. A economia muda de lugar. O custo está no backbone e se paga uma vez; cada caso seguinte é marginal, e o que fica é capacidade instalada que se conecta ao resto do ecossistema.

A referência é o PRAGMA, o modelo fundacional que o Revolut e a NVIDIA treinaram sobre 24 bilhões de eventos. O Pragma Criollo avalia se esse mecanismo é viável com os dados e a escala de um banco da região, e o que seria preciso para levá-lo a produção.

O que construímos

Um centro de demos interativo, construído para responder a uma pergunta concreta de um banco líder da Argentina: é viável treinar um modelo fundacional próprio sobre o comportamento transacional dos seus clientes? Não é um mockup. O backbone está treinado e rodando, o motor de machine learning executa no navegador e o plano de viabilidade pode ser percorrido inteiro.

O que demonstramos

3
Níveis do encoderPerfil, evento e história, com atenção temporal
96
Dimensões por clienteO vetor do qual sai cada caso de uso
76 %
Masked accuracyO acaso está em 0,8 %
<1 s
Adaptar um caso novoUma cabeça linear sobre o embedding congelado
AUC em holdout sobre dados sintéticos.
TarefaBaseline de 20 featuresBackbone
Churn0,7070,677
Adoção de produtos0,7430,710
Propensão a operar dólares0,6930,687
Ordem dos eventos0,5340,993

Nas três tarefas lineares o backbone empata com um baseline de 20 features manuais, e essa paridade é o teto esperável: os rótulos sintéticos nascem das mesmas features que o baseline recebe de graça.

A diferença aparece na quarta, desenhada para que as contagens fiquem no acaso. São os mesmos eventos e a única coisa que muda é a precedência temporal: o baseline fica em 0,534 e o backbone chega a 0,993. O mecanismo captura uma estrutura que o feature engineering manual não consegue enxergar. Com apenas 50 rótulos, um probe sobre o embedding congelado já lê esse padrão, então a representação transfere.

A superfície técnica

O contrato de integração é um único vetor por cliente. Cada caso de uso novo é uma cabeça linear sobre esse vetor, e não um pipeline novo. Estas são as três superfícies, e o limite entre o que roda hoje e o que está planejado não é borrado.

Implementado

O motor ao vivo

pragma-lab.js, no navegador e sem backend

generate(n, seed) → Usuario[]
Gera n clientes sintéticos reproduzíveis.
trainAll(users, seed) → {models, aucs, rates}
Treina churn, adoção e dólares com holdout de 25 %.
predict(model, feats) → [0, 1]
Probabilidade sobre um vetor de 20 features.
drivers(model, feats, k) → {f, dir}[]
Os k fatores mais influentes, para explicabilidade.
pca2(rows) → [x, y][]
Projeção 2D para visualizar embeddings.
save() / load() → bool / obj
Persiste o modelo: a ponte do laboratório ao assistente.
Implementado

O repositório do backbone

PyTorch, por linha de comando

synthetic_generator.py
Corpus JSONL tipo–valor–tempo, sem PII.
train.py
Pré-treinamento do backbone com masked modelling.
evaluate.py
Probe sobre embeddings congelados contra o baseline.
predict.py
O vetor de 96 dimensões e as cabeças de decisão.

Checks M1–M3 no verde, tokenizer com teste de round-trip e uma pasta runs/ com checkpoints e métricas versionados.

Roadmap

Como o banco consome

Planejado no roadmap, ainda não entregue

Serviço de inferência e embeddings, batch e online.
Model registry com versionamento do backbone e de cada cabeça.
CI/CD para fine-tuning e deploy de cabeças downstream.
Monitoramento de drift por caso de uso.
Propagação de mudanças: uma mudança de dados afeta N casos.

Honestidade por design

Tudo roda sobre dados sintéticos, sem um único dado real nem informação pessoal. Isso define o que os números provam: o mecanismo de ponta a ponta — gerar, treinar, prever, explicar — e não performance de negócio. O uplift diferencial é o que a fase seguinte procura, com dados reais do banco.

Os resultados publicados do PRAGMA — +130 % em credit scoring, +79 % em engajamento, +67 % em recall de fraude, +41 % em recomendação — são do Revolut. Não são nossos nem do banco: servem como referência de magnitude, não como projeção comprometida. A prevenção à lavagem de dinheiro fica explicitamente fora do escopo, porque exige olhar relações entre clientes e não apenas a história de cada um.

Dizer tudo isso não enfraquece o argumento; é o que permite decidir. Um comitê que sabe o que está provado e o que não está pode aprovar a fase seguinte de olhos abertos.

Como fazemos isso na Caramel

  • Advise

    O estudo de viabilidade e os seus gates: 97 tarefas em quatro fases, três decisões Go/No-Go e um veredito que se sustenta em evidência, não em entusiasmo.

  • Build

    A tokenização, os encoders, o backbone, o corpus sintético, o baseline honesto e o centro de demos. Viabilidade como código: o plano, os dados, o modelo e os entregáveis executivos saem do mesmo repositório e são regenerados a partir dele.

  • Run

    O que é preciso para viver em produção: model risk management, MLOps, retreinamento e monitoramento de drift caso a caso.

Architect-led · Engineer-built · Production-proven

Stack

Vamos avaliar com os seus dados?

Pedir uma demo