← Todos los productosProducto · Foundation models · Banca
Aprender al cliente una vez, responder muchas preguntas
Una representación del cliente, aprendida una vez y compartida por churn, adopción, fraude y recomendación.
- Origen
- Un banco líder de Argentina
- Industria
- Banca y servicios financieros
- Estado
- Estudio de viabilidad, con demos ejecutables
El problema
En un banco, cada pregunta sobre el cliente se resuelve con un pipeline distinto. Un equipo arma features para churn, otro para fraude, otro para adopción de productos. Cada uno vuelve a empezar por las mismas fuentes, los mismos joins y los mismos conteos con otro nombre, y el caso siguiente tarda semanas o un trimestre en salir.
Lo que se pierde en el camino es el orden. Un cliente que consulta el saldo y después transfiere no es el mismo que hace lo inverso, pero un conteo mensual los registra igual. La señal está en la secuencia, y la secuencia es justamente lo que los conteos aplanan.
La respuesta
Un modelo fundacional del cliente invierte el orden del trabajo. En lugar de construir features para una pregunta, se pre-entrena un backbone sobre los eventos crudos —tipo, valor y tiempo— sin etiquetas y sin decidir de antemano para qué sirve. Lo que aprende es una representación de propósito general: un vector por cliente que resume su historia.
De ese vector salen las respuestas. Churn, adopción de productos, propensión a operar en dólares, fraude, recomendación: cada caso es una cabeza lineal sobre la misma representación, no un pipeline nuevo. La economía cambia de lugar. El costo está en el backbone y se paga una vez; cada caso siguiente es marginal, y lo que queda es capacidad instalada que se enchufa al resto del ecosistema.
La referencia es PRAGMA, el modelo fundacional que Revolut y NVIDIA entrenaron sobre 24.000 millones de eventos. Pragma Criollo evalúa si ese mecanismo es viable con los datos y la escala de un banco de la región, y qué haría falta para llevarlo a producción.
Qué construimos
Un centro de demos interactivo, construido para responder una pregunta concreta de un banco líder de Argentina: ¿es viable entrenar un modelo fundacional propio sobre el comportamiento transaccional de sus clientes? No es un mockup. El backbone está entrenado y corre, el motor de machine learning se ejecuta en el navegador y el plan de viabilidad se navega entero.
El backbone real
Tokenizer tipo–valor–tiempo y tres encoders —perfil, evento e historia— con atención temporal RoPE, pre-entrenados con masked modelling sobre un corpus sintético de 2.000 clientes. Trae el replay del log de entrenamiento y un mapa interactivo de embeddings.
Curva de loss de 22,3 a 0,33
Laboratorio de datos y modelo
Generar clientes sintéticos reproducibles por semilla, entrenar tres modelos con partición train/test y cargarlos al asistente para probarlos con clientes nuevos. Todo en el navegador, sin backend.
3 modelos, AUC en holdout
Asistente conversacional
Responde sobre un cliente concreto y sobre el proyecto: qué datos hacen falta, por qué importa la explicabilidad. Las predicciones salen del backbone, o del modelo que el visitante acaba de entrenar.
Declara con qué modelo responde
Demo del resultado
Cada tarea contra su baseline, el argumento de time-to-market y un inspector por usuario con su actividad mensual, su mezcla de eventos y sus predicciones.
De semanas a minutos por caso
Academia
Siete capítulos interactivos y sin jerga, para explicarle el mecanismo a un comité de dirección: datos sucios, el pipeline de punta a punta, el entrenamiento en vivo y los riesgos sin maquillar.
7 capítulos y un quiz de cierre
Roadmap interactivo
Mapa de viabilidad navegable, con prerequisitos, camino crítico, simulación de avance y veredicto. Cubre once épicas, de gobierno y datos a model risk management y MLOps.
97 tareas, 4 fases, 3 gates
Arquitectura y API
Las cinco capas del sistema como viabilidad como código: el plan, los datos, el modelo, las demos y los entregables ejecutivos salen del mismo repositorio y se regeneran.
5 capas versionadas
Lo que demostramos
- 3
- Niveles del encoderPerfil, evento e historia, con atención temporal
- 96
- Dimensiones por clienteEl vector del que sale cada caso de uso
- 76 %
- Masked accuracyEl azar está en 0,8 %
- <1 s
- Adaptar un caso nuevoUna cabeza lineal sobre el embedding congelado
AUC en holdout sobre datos sintéticos.| Tarea | Baseline de 20 features | Backbone |
|---|
| Churn | 0,707 | 0,677 |
|---|
| Adopción de productos | 0,743 | 0,710 |
|---|
| Propensión a operar en dólares | 0,693 | 0,687 |
|---|
| Orden de los eventos | 0,534 | 0,993 |
|---|
En las tres tareas lineales el backbone empata con un baseline de 20 features manuales, y esa paridad es el techo esperable: las etiquetas sintéticas nacen de las mismas features que el baseline ve gratis.
La diferencia aparece en la cuarta, diseñada para que los conteos queden en azar. Son los mismos eventos y lo único que cambia es la precedencia temporal: el baseline queda en 0,534 y el backbone llega a 0,993. El mecanismo captura una estructura que el feature engineering manual no puede ver. Con sólo 50 etiquetas, un probe sobre el embedding congelado ya lee ese patrón, así que la representación transfiere.
La superficie técnica
El contrato de integración es un solo vector por cliente. Cada caso de uso nuevo es una cabeza lineal sobre ese vector, no un pipeline nuevo. Estas son las tres superficies, y el límite entre lo que corre hoy y lo que está planificado no se difumina.
ImplementadoEl motor en vivo
pragma-lab.js, en el navegador y sin backend
- generate(n, seed) → Usuario[]
- Genera n clientes sintéticos reproducibles.
- trainAll(users, seed) → {models, aucs, rates}
- Entrena churn, adopción y dólares con holdout del 25 %.
- predict(model, feats) → [0, 1]
- Probabilidad sobre un vector de 20 features.
- drivers(model, feats, k) → {f, dir}[]
- Los k factores más influyentes, para explicabilidad.
- pca2(rows) → [x, y][]
- Proyección 2D para visualizar embeddings.
- save() / load() → bool / obj
- Persiste el modelo: el puente del laboratorio al asistente.
ImplementadoEl repositorio del backbone
PyTorch, por línea de comandos
- synthetic_generator.py
- Corpus JSONL tipo–valor–tiempo, sin PII.
- train.py
- Pre-entrenamiento del backbone con masked modelling.
- evaluate.py
- Probe sobre embeddings congelados contra el baseline.
- predict.py
- El vector de 96 dimensiones y las cabezas de decisión.
Checks M1–M3 en verde, tokenizer con test de round-trip y una carpeta runs/ con checkpoints y métricas versionados.
RoadmapCómo lo consume el banco
Planificado en el roadmap, todavía no entregado
- Servicio de inferencia y embeddings, batch y online.
- Model registry con versionado del backbone y de cada cabeza.
- CI/CD para fine-tuning y despliegue de cabezas downstream.
- Monitoreo de drift por caso de uso.
- Propagación de cambios: un cambio de datos afecta N casos.
Honestidad por diseño
Todo corre sobre datos sintéticos, sin un solo dato real ni información personal. Eso fija qué prueban los números: el mecanismo de punta a punta —generar, entrenar, predecir, explicar— y no performance de negocio. El uplift diferencial se busca en la fase siguiente, con datos reales del banco.
Los resultados publicados de PRAGMA —+130 % en credit scoring, +79 % en engagement, +67 % en recall de fraude, +41 % en recomendación— son de Revolut. No son nuestros ni del banco: sirven como referencia de magnitud, no como proyección comprometida. La prevención de lavado queda explícitamente fuera del alcance, porque exige mirar relaciones entre clientes y no sólo la historia de cada uno.
Decir todo esto no debilita el argumento; es lo que permite decidir. Un comité que sabe qué está probado y qué no puede aprobar la fase siguiente con los ojos abiertos.
Cómo lo hacemos en Caramel
Advise
El estudio de viabilidad y sus puertas: 97 tareas en cuatro fases, tres decisiones Go/No-Go y un veredicto que se sostiene con evidencia y no con entusiasmo.
Build
La tokenización, los encoders, el backbone, el corpus sintético, el baseline honesto y el centro de demos. Viabilidad como código: el plan, los datos, el modelo y los entregables ejecutivos salen del mismo repositorio y se regeneran.
Run
Lo que hace falta para que viva en producción: model risk management, MLOps, reentrenamiento y monitoreo de drift caso por caso.
Architect-led · Engineer-built · Production-proven
Stack
- PyTorch
- Python
- Transformers
- Masked modelling
- RoPE
- Embeddings
- Synthetic data
¿Lo evaluamos con tus datos?
Pedir una demo