NeoLDM — Large Data Models

La segunda ola de decisiones basadas en datos

Chocando contra el muro: cómo el deep learning rompe los límites del machine learning clásico

«No describimos el mundo que vemos; vemos el mundo que podemos describir.»

R. D. Laing

La era de la transformación digital trajo una fuerza innegable que impulsó a las empresas a rediseñar la experiencia de sus clientes. A medida que los productos y los recorridos migraron a apps, web y canales de atención automatizados, el negocio comenzó a producir una gran cantidad de datos de eventos: cada interacción del cliente con una empresa —abrir la app, explorar un producto, simular un préstamo, hacer una inversión, reservar un vuelo, contratar un seguro, realizar una compra, pagar una factura, contactar a soporte o modificar datos personales— comenzó a generar registros en las bases de datos de la empresa.

Naturalmente, al ver en esos datos información crucial para respaldar predicciones e inferencias sobre el comportamiento futuro de los clientes, las empresas comenzaron a invertir en infraestructura de datos escalable y pipelines de ingesta, consolidando los datos en data lakes con el fin de crear una base confiable donde los datos de varios sistemas pudieran almacenarse, estandarizarse y volverse utilizables. Las principales líneas de investigación en Machine Learning, sin embargo, solían considerar los datos crudos demasiado ruidosos y demasiado granulares para orientar decisiones de manera directa. Además, existía una falta generalizada de poder computacional para procesar flujos de eventos en motores de predicción. Así, los científicos e ingenieros de datos comenzaron a transformar esos eventos crudos en «features», concebidas como señales compactas, más «listas para la decisión», que resumen el comportamiento del cliente.

En lugar de los datos crudos, las empresas empezaron a apoyarse en agregaciones de datos como promedios, desviaciones estándar, máximos, mínimos, frecuencia y recencia de los datos. De este modo, los feature stores se volvieron ubicuos, constituyendo la capa operativa que organiza esas agregaciones de datos para que pudieran reutilizarse de manera consistente entre equipos y modelos, manteniéndolas actualizadas con la frecuencia adecuada y garantizando que se aplicaran en producción de la misma forma en que fueron definidas y aplicadas durante el entrenamiento.

No era raro que las organizaciones construyeran todo un ecosistema de modelos especializados —a veces, incluso cientos de ellos— adaptados a productos, canales, objetivos y segmentos específicos. La orquestación de tales ecosistemas comenzó a apoyarse en reglas de parametrización que se convirtieron en las capas de decisión que transformaban las predicciones en acciones concretas al combinar las salidas del Machine Learning con reglas de negocio, restricciones de política y límites de presupuesto y de exposición. Nació un pipeline «industrial»: los eventos se convertían en features, las features alimentaban los modelos, las salidas de los modelos se encontraban con las reglas de negocio para convertirse en ofertas y, finalmente, más recientemente, agentes de IA basados en large language models, combinados con las apps de las empresas o con apps de comunicación de uso general, se convirtieron en la capa final a través de la cual las ofertas finalmente llegan al cliente.

Sin embargo, esta dependencia de features diseñadas por humanos, si bien aporta interpretabilidad y alineación con la lógica de negocio establecida, restringe inherentemente el potencial exploratorio del modelo. Dado que estas features se diseñan a partir de conocimiento de negocio previo, actúan en la práctica como un filtro que refuerza los paradigmas operativos existentes, a menudo impidiendo que el modelo identifique impulsores causales novedosos y no obvios. Esta «impronta de conocimiento» (knowledge-imprinting) puede crear un sesgo hacia la confirmación de lo ya conocido, pasando por alto potencialmente conjuntos complejos de señales causales débiles que, si se analizaran de manera holística sin la restricción de la ingeniería manual de features, podrían coalescer en insights accionables y de alto valor que antes permanecían ocultos en el ruido de los datos.

Este panorama de toma de decisiones basada en datos todavía constituye el estado actual de la mayoría de las empresas. Exige inversiones enormes y un esfuerzo especializado constante en la definición de reglas. Aun así, este pipeline es muy lento para reaccionar a cambios estructurales del mercado, es mucho menos hiperpersonalizado de lo que parecería a primera vista y está lejos de ser tan preciso como lo permitiría la información contenida en los datos de eventos originales y crudos.

Lo que hemos descrito hasta ahora es, en esencia, el paradigma clásico del Machine Learning operando a escala industrial: los eventos crudos se transforman en features agregadas, las features se organizan en feature stores, los modelos consumen esas features y las capas de decisión orquestan las salidas mediante reglas y restricciones. El Deep Learning moderno, sin embargo, cambia el enfoque por defecto al convertir el flujo de eventos crudos —y no sus agregaciones— en el activo central. Cuando los modelos pueden aprender directamente de historiales transaccionales, secuencias de comportamiento e interacciones no agregadas (incluido texto), tienden a reaccionar más rápido a los cambios estructurales del mercado, habilitan predicciones verdaderamente en tiempo real y logran un mejor desempeño predictivo.

Dejar que los datos hablen

«La descripción no es lo descrito.»

– Jiddu Krishnamurti

Uno de los mayores cambios de perspectiva del Machine Learning clásico al Deep Learning moderno tiene que ver con cuánto necesitamos realmente «enseñarle» al modelo o, más específicamente, cuánto se benefician los modelos de nuestro conocimiento de un campo determinado frente a aprenderlo por sí mismos.

Un ejemplo revolucionario proviene de AlphaZero, de DeepMind. Antes de AlphaZero, los motores de ajedrez de mejor desempeño se parecían mucho al pipeline «industrial» que describimos: primero se construían a mano representaciones de lo que importaba (balance de material, estructura de peones, seguridad del rey, movilidad y muchas otras heurísticas) y luego se usaban procedimientos de búsqueda (poda alfa-beta, exploración anticipada extensiva) guiados por esas señales. Incluso con una capacidad de fuerza bruta sobrehumana, el motor seguía navegando el juego a través de una descripción diseñada por humanos de cómo luce el «buen ajedrez».¹

AlphaZero fue un contrapunto. Se construyó sobre una premisa engañosamente simple: no le digas al modelo qué es una «buena posición». No codifiques de forma fija siglos de comprensión del ajedrez. No construyas un catálogo de features de «lo que importa». Dale al sistema solamente las reglas del juego, el objetivo (ganar, y qué significa ganar) y la capacidad de generar experiencia jugando contra sí mismo. Lo que ocurrió es que AlphaZero aprendió dos cosas a la vez:

1. Una representación rica del estado (qué aspectos de la posición del tablero son importantes y cómo se combinan), y
2. Una política de decisión (qué movimientos considerar y priorizar), guiada por la retroalimentación de los resultados.

En otras palabras, aprendió a describir el mundo de una manera que hace posible ganar, en lugar de heredar una descripción humana.

AlphaZero derrotó de manera contundente a Stockfish (en ese momento, el sistema de ajedrez más avanzado) en un encuentro a 100 partidas con un marcador de 28 victorias, 72 empates y 0 derrotas. Desde entonces, Stockfish evolucionó incorporando componentes (por ejemplo, NNUE) para reducir la complejidad de búsqueda mediante el aprendizaje de representaciones significativas.

El mismo cambio aplica más allá de los juegos de tablero. Un modelo clásico de credit scoring, por ejemplo, se entrenaría con varias agregaciones de datos como promedios, desviaciones estándar, máximos/mínimos, conteos, frecuencia/recencia, ventanas móviles, ratios seleccionados a mano, etcétera. Pero son los datos que dieron origen a esas agregaciones aquello de lo que un modelo profundo más se beneficiaría. En lugar de quedar restringido a las estadísticas que elegimos, el modelo puede buscar una estructura más rica en secuencias e interacciones: no solo con qué frecuencia ocurrió algo, sino en qué orden, bajo qué contexto, cómo evolucionan los patrones y qué combinaciones importan, incluidas combinaciones que a nadie se le ocurriría diseñar a mano.

Hay varias maneras en que la agregación puede perjudicar el aprendizaje:

1. Pérdida de información (irreversibilidad). En general, es imposible recuperar los datos originales a partir de sus agregaciones.
2. Inexpresividad para ciertas modalidades. Algunos insumos son inherentemente difíciles de agregar de manera significativa, como el texto crudo. Sin embargo, pueden ser decisivos para una tarea (piense en el papel de la interacción por WhatsApp de un cliente con una empresa al predecir la propensión de ese cliente a comprar cierto producto).
3. Subrepresentación de la dispersión (sparsity). Cuando los datos se agregan a lo largo del tiempo o de los eventos, los datos dispersos (como, en el ejemplo anterior del modelo de credit scoring, los eventos de un cliente con pocas transacciones) tienden a ser «diluidos» del conjunto de datos, lo que conduce a un desempeño muy pobre del modelo en esos casos.
4. Sesgo inyectado. Más sutil es el hecho de que, al elegir cómo se agregan los datos, estamos imponiendo al modelo un sesgo, es decir, una cierta visión del mundo que refleja lo que generalmente se denomina «conocimiento del dominio». Aunque esto pueda parecer algo bueno, podría bloquear exactamente lo que queremos de un modelo predictivo: una manera genuinamente nueva de mirar los datos.
5. Costo y mantenimiento de los feature stores. Construir y mantener un feature store es un trabajo costoso y especializado, que requiere un equipo que entienda tanto las técnicas de modelado como el dominio de conocimiento relevante. Esto es especialmente cierto cuando se debe introducir una nueva fuente de datos, ya que necesita ser evaluada y estudiada a fondo antes de que se agreguen al store nuevas agregaciones significativas.
6. Especificidades del dominio. Las elecciones y estrategias de agregación que funcionan para un dominio determinado no funcionan para otros (por ejemplo, las ventanas de agregación típicas de un modelo de credit scoring, en general, no tendrán buen desempeño para un modelo de CTR²).
7. Cambios estructurales del mercado. No es raro que las agregaciones de datos funcionen bien durante un cierto período de tiempo pero se vuelvan menos efectivas (o incluso totalmente inefectivas) en otros períodos debido a novedades relevantes que pueden causar un cambio estructural en una tarea de predicción.
8. Rigidez temporal y estructural. La agregación tradicional se apoya en ventanas temporales fijas (por ejemplo, promedios móviles de 30 días), que asumen implícitamente una relación estática entre la feature y el target. Esto crea un modelo «frágil» que tiene dificultades para adaptarse a cambios rápidos en el comportamiento del consumidor o a virajes del mercado. Cuando la dinámica subyacente del mercado cambia, estas agregaciones codificadas de forma fija a menudo fallan, ya que carecen de la flexibilidad para redefinir su propio alcance predictivo en tiempo real.
9. Pérdida de la volatilidad conductual (la «tiranía de la media»). Los métodos de agregación como promedios o medianas suavizan inherentemente los datos, priorizando la estabilidad por sobre la precisión. En muchos dominios —como la detección de fraude o el credit scoring— la señal más predictiva no es el comportamiento «típico», sino la desviación repentina y abrupta o el «pico» aislado de actividad. Al condensar estos eventos en resúmenes estadísticos, en la práctica «diluimos» justamente las firmas conductuales que señalan un cambio inminente en el riesgo o la propensión, volviendo al modelo insensible a anomalías críticas de alto impacto.
10. Impronta de conocimiento (knowledge-imprinting) y ceguera causal. Al forzar los datos dentro de categorías de features predefinidas, esencialmente restringimos al modelo a «confirmar» hipótesis de negocio existentes en lugar de permitirle descubrir los patrones reales presentes en los datos. Esta «impronta de conocimiento» actúa como un filtro que refuerza los paradigmas operativos establecidos, impidiendo que el modelo identifique impulsores causales novedosos y no obvios. En consecuencia, podemos pasar por alto conjuntos complejos de señales causales débiles y fragmentadas que, si se analizaran de manera holística sin la restricción de la ingeniería manual de features, podrían coalescer en insights nuevos y de alto valor.

Ilustraciones interesantes de este último punto son la introducción, en Brasil, de las transacciones Pix (transferencias interbancarias instantáneas que se han convertido en el método de pago dominante, capturando aproximadamente el 50% de todas las transacciones y facilitando un volumen total de casi US$ 7 billones —7 trillones en la escala numérica anglosajona— a lo largo de 2025) y el reciente y marcado auge de las apps de apuestas en línea. Tales novedades reconfiguraron por completo el panorama de la predicción de incumplimiento crediticio en el país.

Un modelo profundo adecuadamente diseñado y entrenado debería eliminar por completo ese tipo de preocupaciones. Los cambios estructurales en el problema de predicción se incorporan y manejan de forma natural, porque el comportamiento estructural cambiante se captura en tiempo real a través de los propios datos crudos. La ausencia de períodos de agregación conduce a predicciones en tiempo real (una única transacción con tarjeta de crédito puede desencadenar instantáneamente una reevaluación de su límite de crédito disponible, por ejemplo).

Hasta ahora hemos estado mirando solamente las entradas del modelo, pero un cambio de perspectiva similar también aplica a las salidas. De hecho, en el paradigma clásico, en realidad estamos usando proxies dos veces: una, cuando las features se toman en lugar de los datos crudos; y otra, cuando las decisiones a nivel de cliente se colapsan en scores proxy que requieren una capa de reglas separada para convertirse en acción. En otras palabras, el modelo no solo debería aprender directamente del flujo de eventos crudos, sino que también debería producir como salida decisiones estructuradas y específicas para cada cliente.

Dejar que el modelo actúe

«Bien hecho es mejor que bien dicho.»

– Benjamin Franklin

Si vamos a dejar que los datos hablen, también tenemos que dejar que el modelo responda en el lenguaje de la acción. En el esquema clásico, la salida del modelo sigue siendo una abstracción: scores que deben interpretarse, traducirse en umbrales, tablas de política y reglas manuales. Pero esa capa de traducción es, en realidad, un segundo modelo que está siendo alimentado con datos agregados, porque los scores no son más que una versión muy comprimida y simplificada de las ricas representaciones del modelo que fueron aprendidas del flujo de eventos crudos. Así que, más allá de los scores, debemos dejar que el modelo traduzca esas representaciones en acciones hiperpersonalizadas.

En una arquitectura de crédito moderna, el modelo ya no debería responder a una pregunta predictiva estrecha como «¿cuál es la probabilidad de incumplimiento de este cliente en los próximos 12 meses?» para luego depender de reglas posteriores, tablas de política y parametrización manual que conviertan esa estimación en acción. En cambio, el sistema debería resolver directamente un problema de decisión con restricciones y producir un objeto de acción: una salida estructurada y auditable que especifica qué debe hacerse para este cliente específico, dados los objetivos económicos de la institución, sus restricciones de capital y sus fronteras regulatorias.

En este contexto, el modelo no está simplemente prediciendo riesgo; está optimizando una decisión a nivel de cliente bajo objetivos explícitos —por ejemplo, maximizar el retorno esperado ajustado por riesgo o el MFL menos el costo de capital— sujeto a restricciones de portafolio, regulatorias y de equidad (fairness).

Concretamente, en lugar de un único score de crédito, el sistema produciría:

• Una línea de crédito recomendada (o un ajuste de línea), acompañada de estimaciones de incertidumbre e implicaciones de consumo de capital.
• Términos de pricing seleccionados para optimizar el margen esperado neto de riesgo y costos de fondeo, consistentes con el apetito de riesgo de la institución y con consideraciones de valor de vida del cliente (customer lifetime value).
• Selección de producto y canal: si la siguiente mejor acción es un aumento de límite, una transferencia de saldo, una migración a un producto con garantía, una propuesta de reestructuración o ninguna oferta en absoluto, y si debe entregarse digitalmente, mediante notificación push, correo electrónico o a través de un agente humano.
• Momento y cadencia: cuándo desencadenar la intervención, tomando en cuenta señales de comportamiento (por ejemplo, la entrada de fondos posterior al salario, patrones transaccionales, interacciones de servicio) y condiciones dinámicas del portafolio.
• Restricciones conscientes de los guardrails: salidas que ya respetan límites de exposición, umbrales de concentración, requisitos regulatorios, métricas de equidad, límites de capital en escenarios de estrés y topes de presupuesto comercial.

Fundamentalmente, este objeto de acción no debe ser estático. Debe estar inserto en un ciclo de aprendizaje continuo, en el que los resultados observados —aceptación, comportamiento de pago, deserción (attrition) y rentabilidad— retroalimentan al motor de políticas. El sistema debe distinguir entre el comportamiento natural del cliente y el comportamiento inducido por la intervención, incorporando mecanismos causales o de uplift para asegurar que las acciones recomendadas generen valor incremental en lugar de meramente predecirlo.

Bajo este paradigma, el modelado de crédito evoluciona de la estimación de scores a la optimización de políticas. La salida ya no es un número que requiere traducción en acción; es un marco de decisión que integra riesgo, retorno, experiencia del cliente y coherencia del portafolio en un único objeto ejecutable.

En otras palabras, la salida del modelo se parece más a una política de crédito hiperpersonalizada que a un score. Para un cliente, la mejor decisión podría ser «reducir la exposición pero mejorar la retención»: proponer un aumento de límite menor (o ninguno), ofrecer un plan de reestructuración y elegir mensajes empáticos para proteger el NPS³. Para otro, podría ser «aumentar la exposición agresivamente»: un límite más alto con una tasa más baja, porque el modelo ve alta estabilidad, patrones sólidos de flujo de caja (cashflow) y un fuerte valor a largo plazo. El punto es que estos no son «segmentos», sino políticas individuales generadas a partir de la trayectoria del cliente.

Si el sistema se entrena solo para predecir el incumplimiento, puede optimizar para evitar pérdidas, pero muchas veces al costo de rechazar clientes rentables y/o perjudicar la experiencia. Pero si el objetivo se define en el nivel correcto —digamos, «maximizar la contribución esperada durante la vida del cliente» (ingresos menos pérdidas y costos) manteniendo el NPS y la retención de largo plazo—, el modelo puede aprender decisiones que ponderan directamente riesgo, margen y calidad de la relación. El score puede verse como una señal latente interna, pero no es el producto. El producto es la acción: el límite, los términos, la oferta, el momento y el mensaje correctos para este cliente, bajo restricciones explícitas de gobernanza.

Un modelo con tales capacidades puede verse como el cerebro de IA fundacional de la empresa moderna. Lo llamamos Large Data Model.

Large Data Model – LDM

Un cerebro de IA fundacional

«Es el patrón [...] lo que constituye la piedra de toque de nuestra identidad personal. [...] No somos más que remolinos en un río de agua que fluye sin cesar. No somos materia que perdura, sino patrones que se perpetúan a sí mismos. Un patrón es un mensaje, y puede ser transmitido como un mensaje.»

– Norbert Wiener

Un Large Data Model (LDM) es una arquitectura profunda basada en transformers, preentrenada desde cero con los datos operativos crudos de un sistema de negocio. Aquí, «sistema de negocio» se usa en un sentido amplio: puede referirse a un banco, un hospital, un operador de telecomunicaciones, una compañía de seguros, un estudio jurídico, una empresa de energía, una organización deportiva, una universidad o cualquier ecosistema de entidades que interactúan cuyas actividades generan datos estructurados de eventos.

A diferencia de los modelos tradicionales de machine learning entrenados con tablas de features curadas, un LDM se entrena directamente sobre los sistemas de registro (systems-of-record) y los logs de interacción: actualizaciones de perfil de clientes, compras, transacciones, sesiones digitales, reclamos, tickets, interacciones de CRM, eventos operativos y otras transiciones de estado. El modelo ingiere estas señales heterogéneas y ordenadas en el tiempo, y aprende la dinámica conjunta de clientes, productos, operaciones y decisiones organizacionales. En la práctica, el preentrenamiento es típicamente autosupervisado, lo que permite al modelo aprender una representación comprimida del estado cambiante de la empresa sin requerir etiquetas específicas de tarea.

Un LDM no es un modelo de lenguaje. Su propósito no es la generación de texto ni la comunicación humana. Es, más bien, un modelo de fundación (foundation model) para la empresa misma. Mediante el preentrenamiento a gran escala con datos de negocio crudos, adquiere una representación generalizada de cómo se comportan la compañía y su ecosistema a lo largo del tiempo. Tras el post-training o la adaptación a tareas específicas, esta representación puede aprovecharse para potenciar predicciones y tareas de apoyo a la decisión, como evaluación de riesgo, pronóstico de demanda, predicción de churn, pricing, detección de fraude, asignación de capital y políticas de siguiente mejor acción (next best action).

En este sentido, un LDM funciona como la capa de inteligencia fundacional de la compañía: un modelo unificado de su memoria operativa y su dinámica conductual.

Impacto operativo

Con todos nuestros clientes hasta la fecha, el paradigma del Large Data Model demuestra de manera consistente mejoras sustanciales de desempeño frente a los enfoques tradicionales de machine learning construidos sobre features diseñadas manualmente. En más de 12 tareas predictivas y de apoyo a la decisión sobre conjuntos de datos empresariales a gran escala —particularmente en sectores intensivos en datos como los servicios financieros—, los modelos entrenados directamente sobre flujos de eventos crudos lograron ganancias de desempeño típicamente en el rango del 15% al 60% de mejora relativa en comparación con pipelines convencionales de machine learning basados en árboles o con modelos específicos de tarea con fine-tuning estrecho.

Estas mejoras aparecen de manera consistente en tareas que involucran dinámicas conductuales complejas, donde las dependencias temporales de largo alcance, las señales dispersas y las modalidades de datos heterogéneas juegan un papel decisivo. Experimentos tempranos realizados en otros dominios con datos operativos igualmente ricos muestran resultados prometedores que siguen patrones similares.

Es importante destacar que estas ganancias no se limitan únicamente a la precisión predictiva. Dado que los LDM aprenden representaciones unificadas del comportamiento operativo, con frecuencia reducen la necesidad de mantener grandes ecosistemas de modelos especializados y features hechas a mano. Esto conduce no solo a señales predictivas más fuertes, sino también a una infraestructura de modelado más simple y adaptable, particularmente en entornos donde el comportamiento del cliente, las condiciones del mercado o la dinámica de los productos evolucionan rápidamente.

Pre-train: construyendo comprensión y percepción

Durante la fase de pre-train del LDM, el modelo aprende interconexiones profundas entre los datos de la compañía. Se espera que estas interconexiones sean bastante intrincadas, y la matemática detrás de ellas muestra que, en efecto, suelen ser de «alto orden», bastante «implícitas», o depender de transformaciones geométricas complejas para ser expuestas (ver la sección «Capas de fusión local»). También es importante notar que, antes del pre-train, los pesos del modelo son aleatorios; es decir, no existe un entrenamiento previo del modelo sobre datos tabulares genéricos y los únicos datos que el modelo ve son los datos de la compañía.

Para comprender mejor el preentrenamiento, trabajemos con un ejemplo concreto. Nuestra «compañía» será una Telecom tier-1 ficticia cuyas bases de datos centrales incluyen, entre otras, datos sobre sesiones y desempeño de red, registros detallados de llamadas (CDRs), mediciones de radio y KPIs a nivel de celda, inventario de dispositivos y SIMs, activaciones y cambios de plan, eventos de facturación, eventos de pago y morosidad, interacciones de atención al cliente (IVR, chat, tickets, reclamos), visitas de técnicos de campo, eventos de roaming, contactos de marketing e historial de churn/reactivación. Así, dado un cliente (o un hogar / una cuenta) y un cierto rango de tiempo, el modelo vería una secuencia de eventos como la que se muestra abajo (con fines ilustrativos, las entradas del conjunto de datos se muestran en forma simplificada):

Ahora bien, el modelo debe entrenarse para entender la historia de cada cliente de modo que, más adelante, podamos enseñarle cómo intervenir en ellas. El preentrenamiento es una fase autosupervisada, lo que significa que no se requieren etiquetas humanas. En cambio, el objetivo del modelo es aprender a predecir eventos futuros a partir de los pasados. Más precisamente, al alimentar el LDM con los eventos que ocurrieron en instantes anteriores, esperamos que el LDM sea capaz de predecir al menos el siguiente evento del cliente (idealmente, el LDM debería entrenarse para predecir los siguientes eventos del cliente). Así, si el modelo ve la trayectoria anterior

[...] → latencia alta → caída de llamada de voz → caídas de red repetidas → ?

se supone que debe predecir cuál es probablemente el siguiente evento: ¿una llamada a soporte? ¿Un downgrade de plan? ¿Una solicitud de portabilidad (port-out)? ¿Un cambio de dispositivo? También debe predecir cada aspecto específico del siguiente evento. Así, en este ejemplo, el modelo debería predecir que el siguiente evento es, con mayor probabilidad, un reclamo por «chat» de «mala cobertura en interiores», a través del canal «app», en el idioma «pt-BR». Esto obliga al modelo a entender, entre muchas otras cosas, los patrones de degradación de la calidad del servicio, el comportamiento del cliente bajo fricción y la interacción entre la experiencia de red y los resultados comerciales.

Además de la predicción del siguiente evento (o eventos), existen otros objetivos que ayudan al modelo a crear representaciones expresivas de los conjuntos de datos. Con el modelado de eventos enmascarados (masked event modeling), por ejemplo, se espera que el modelo prediga una parte faltante de un evento. Por ejemplo, al pedirle al modelo que infiera el valor de throughput faltante en el evento

[Network | data_session | cell 21A |RSRP -112 | SINR 3 | DL ____ | latency 180ms | home]

debe aprender a entender las condiciones de radio, los patrones de congestión, las restricciones de capacidad del dispositivo, los efectos de ubicación/tiempo y los rangos típicos para clientes y celdas similares.

Después de ver millones de trayectorias de clientes, el modelo se encontrará con incidentes raros, casos límite, particularidades de roaming, regresiones de firmware de dispositivos, congestión estacional, cambios de protocolo a lo largo de los años, campañas de mercado, diferencias en las prácticas del personal… aprende patrones que ningún analista podría observar en toda una vida. Más aún, es capaz de encontrar interconexiones entre tales patrones que están mucho más allá de la capacidad humana. La percepción emerge a medida que el modelo comprende arquetipos de uso, patrones de comportamiento del cliente a largo plazo, desviaciones inusuales de trayectoria, qué firmas de red se agrupan entre sí, cómo evoluciona la calidad del servicio por geografía y tiempo, cómo las intervenciones cambian las trayectorias, qué patrones preceden al churn, a la morosidad o a los reclamos reiterados, etc. El modelo ha aprendido ahora en profundidad la estructura de la experiencia del cliente y de la prestación del servicio dentro de esa telco.

A diferencia del preentrenamiento, la fase de post-training de un LDM requiere crear targets particularmente adecuados a la tarea que esperamos que el modelo realice. Dividimos el post-training en dos categorías: el Post-train Predictivo y el Post-train Prescriptivo.

Post-train predictivo: construyendo poder de pronóstico

El post-training predictivo convierte las representaciones preentrenadas en medidas: scores, rankings, embeddings, pronósticos, segmentos, resultados financieros y otras salidas no ejecutoras. Por diseño, un LDM con post-training predictivo no decide qué hacer: resume y anticipa lo que probablemente sucederá y, por lo tanto, todavía requiere una capa de política externa (umbrales, reglas de capacidad, tablas de elegibilidad) para convertir las predicciones en acciones.

Operacionalmente, el post-training predictivo requiere etiquetar el flujo de eventos. Para cada entidad (cliente / cuenta / hogar) y cada marca de tiempo t, creamos targets definidos sobre una ventana futura [t, t + Δ]. Ejemplos en un contexto de Telecom incluyen:

• churn/portabilidad (port-out) dentro de 30/60/90 días,
• morosidad en el siguiente ciclo de facturación,
• contacto reiterado con atención al cliente dentro de 7 días,
• escalamiento de un reclamo dentro de 14 días,
• degradación persistente de la QoE durante la semana siguiente.

Cada target se construye recorriendo los logs crudos hacia adelante a partir de t y marcando si el evento (o eventos) de interés ocurre en el horizonte elegido. Luego, el modelo se entrena para mapear la trayectoria histórica hasta t en estas etiquetas (a menudo muchas a la vez, en una configuración multi-target). Dado que esta fase se apoya en representaciones preentrenadas sólidas, una única pasada de post-training puede cubrir múltiples horizontes y resultados sin requerir un modelo dedicado por target.

Post-train prescriptivo: construyendo juicio

El post-training prescriptivo va un paso más allá: en lugar de producir mediciones que una capa de política separada debe traducir en decisiones, el modelo se entrena para producir la decisión misma (como se describió en «Dejar que el modelo actúe»). «Absorbe» la capa de política dentro del modelo al optimizar directamente el objetivo final de la organización (ganancia, retención, NPS, costo de servicio) bajo restricciones explícitas.

Habilitar este tipo de entrenamiento requiere un tipo diferente de supervisión. En lugar de etiquetas como «churn en 60 días», construimos ejemplos de entrenamiento de la forma:

Contexto: la trayectoria del cliente hasta el instante t
Acción: lo que la compañía hizo en t (digamos, oferta / términos / canal / momento / mensaje / «nada»)
Resultado: lo que sucedió después de esa acción sobre un horizonte [t, t + Δ] (margen, pérdida, churn evitado, reclamos, proxies de NPS, etc.)

A partir de estos resultados definimos una recompensa/utilidad que se corresponde con el objetivo de negocio (por ejemplo, contribución esperada = ingresos − pérdidas − costo de servicio, con penalizaciones por violaciones de política y por daño a la experiencia). Luego, el modelo se entrena para producir acciones que maximicen esta utilidad sujeta a guardrails (presupuesto, exposición, elegibilidad, restricciones regulatorias). En la práctica, esto puede implementarse como aprendizaje de políticas offline (offline policy learning): aprender de decisiones registradas y de sus resultados posteriores, con técnicas que corrigen el hecho de que las acciones históricas fueron elegidas por una política existente (para que el modelo no se limite a imitar las reglas de ayer).

Así, mientras el post-training predictivo aprende a pronosticar el futuro, el post-training prescriptivo aprende la política que actúa sobre el futuro. La capa de política externa ya no es un sistema separado, sino un componente aprendido del modelo.

Arquitectura e interfaz de datos

Un LDM está diseñado para transformar registros empresariales heterogéneos —transacciones, interacciones, logs operativos y texto— en estados latentes unificados que soportan la predicción y la toma de decisiones. El objeto central de modelado es un flujo de eventos: para cada entidad (es decir, cliente, cuenta, hogar, dispositivo), observamos una secuencia de eventos ordenada en el tiempo, generada por múltiples sistemas de origen.

A lo largo de esta sección, asumimos que los datos pueden representarse (o convertirse) en un formato basado en eventos. Concretamente, cada evento contiene: (i) uno o más identificadores de entidad (las claves de unión —join keys— que definen «a quién» pertenece el evento), (ii) un tiempo de evento (la clave de ordenamiento que define «cuándo» ocurrió) y (iii) un conjunto de campos tipados (numéricos, categóricos, marcas de tiempo, texto libre e incluso imágenes u otras modalidades). Los conjuntos de datos no basados en eventos (por ejemplo, dimensiones de cambio lento o snapshots) pueden incorporarse proyectándolos como actualizaciones de eventos o adjuntándolos como información contextual complementaria.

A alto nivel, la arquitectura tiene cinco bloques funcionales:

1. Codificadores de campo (field encoders) que mapean cada campo crudo a vectores en espacios de representación;
2. Capas de fusión local que modelan las interacciones entre campos dentro del mismo evento;
3. Un backbone temporal que modela dependencias de largo alcance a lo largo de la secuencia de eventos;
4. Un backbone espacial que captura dependencias entre entidades (por ejemplo, hogares, comercios, dispositivos, celdas);
5. Un procesador de estado latente que convierte el estado resultante de la entidad en salidas de tarea (scores, pronósticos u objetos de acción estructurados), haciendo cumplir restricciones de gobernanza mediante objetivos de entrenamiento y/o decodificación restringida (constrained decoding).

Capas de embedding

Hacer embedding de los datos es el proceso de tomar datos en su tipo original (digamos, un float, un entero o un string) y representarlos geométricamente como un punto en una variedad riemanniana. Esta estructura riemanniana desempeñará más adelante un papel en el entrenamiento del modelo, donde estructuras geométricas como ángulos, distancias, geodésicas, etc., pueden explorarse para minimizar la función objetivo del entrenamiento. Típicamente, la variedad riemanniana se toma como un espacio vectorial euclidiano de dimensión n con una base ortonormal elegida arbitrariamente⁴; por simplicidad, en lo que sigue nos limitaremos a ese caso. Así, a grandes rasgos, podemos pensar en el embedding de datos como el proceso que convierte cada campo de datos del evento de un cliente en un vector que representa ese campo de datos.

Si dejamos de lado el problema de elegir una geometría significativa, hacer embedding de features categóricas de cardinalidad baja/media es muy simple: basta con asociar a cada categoría un vector inicializado aleatoriamente. Durante el entrenamiento, el modelo debe determinar —o aprender— cada uno de esos valores de tal manera que el papel de la categoría correspondiente en la(s) tarea(s) realizada(s) por el modelo pueda expresarse significativamente mediante su representación. Esto se denomina típicamente «learned embedding tables» (tablas de embedding aprendidas).

Hacer embedding de texto libre es quizás uno de los tipos de embedding mejor explorados, gracias al éxito de los Large Language Models. La forma estándar de hacer embedding de texto es crear primero un tokenizador (es decir, un algoritmo que convierte fragmentos de texto en enteros, de tal manera que el texto se convierte en una lista de enteros de forma determinista) y luego asociar un vector (con valores elegidos aleatoriamente al comienzo del entrenamiento) a cada uno de esos enteros. En un LLM, esta lista de vectores pasa a través de una arquitectura de Transformers

donde una predicción del siguiente token (next token prediction) se usará para entrenar el modelo. En un LDM, queremos convertir una entrada textual dada en un único vector que represente el texto completo. Eso puede lograrse usando también un modelo de tipo Transformers, pero con alguna técnica de pooling al final: podemos, por ejemplo, tomar la media de todos los siguientes tokens predichos o, en cambio, tomar el último token predicho.

Hacer embedding de valores escalares continuos sigue siendo sustancialmente más desafiante que el embedding de tokens y todavía está comparativamente poco explorado. En los datos empresariales, sin embargo, las cantidades escalares no son periféricas: definen el estado del sistema — saldos, exposiciones, precios, límites, volúmenes, probabilidades, latencias. Un modelo que no logra representar fielmente la estructura numérica no puede construir una representación coherente de la dinámica del sistema.

Los Large Language Models ilustran claramente esta limitación. Dado que operan sobre tokens discretizados y no están entrenados explícitamente para la consistencia algorítmica, con frecuencia tienen dificultades con la aritmética exacta, la extrapolación de escalas y la sensibilidad a la magnitud. Sus embeddings no hacen cumplir invariantes numéricos como la preservación del orden, la monotonicidad o la estabilidad ante transformaciones afines. En el modelado de lenguaje esto puede ser tolerable; en el modelado empresarial, no lo es.

Una codificación numérica robusta debe, por lo tanto, exponer la estructura intrínseca de las variables continuas —signo, orden, distancia relativa y relaciones algebraicas básicas— sin dejar de permitir que el modelo capture regularidades específicas del conjunto de datos, como distribuciones de colas pesadas, escalas características, cambios de régimen, estacionalidad y componentes periódicos de múltiples frecuencias. En nuestros experimentos, una codificación híbrida que combina representaciones en el dominio del valor con embeddings espectrales (Fourier features) tiene un desempeño consistentemente bueno, proporcionando sensibilidad a la magnitud absoluta y preservando a la vez la resolución a través de múltiples escalas temporales y de frecuencia. El mismo principio se extiende naturalmente a las features de marcas de tiempo, donde la estructura temporal periódica y jerárquica debe hacerse explícita.

En los LDM, la representación numérica no es una elección de diseño auxiliar; es un requisito estructural para modelar las transiciones de estado de la empresa.

Capas de fusión local

«— Se trata de cómo las entidades se manifiestan unas a otras. Se trata de relaciones.»

— Carlo Rovelli

Hasta este punto, hemos tratado un evento como una colección de campos independientes. Pero un registro empresarial real solo se vuelve significativo a través de las interacciones dentro del evento: los números condicionan cómo interpretamos el texto; el contexto categórico cambia lo que una métrica «significa»; las marcas de tiempo definen qué regímenes son comparables; los metadatos operativos alteran la semántica de una observación.

Formalmente, consideremos un evento Et de una entidad en el instante t, con campos numéricos {ni}, campos categóricos {cj}, marcas de tiempo {tk} y campos no estructurados {sl} (texto, imágenes, etc.). Después de la capa de embedding, obtenemos un conjunto de vectores embebidos {Ni}, {Cj}, {Tk}, {Sl}.

Una capa de fusión local mapea este conjunto heterogéneo a una única representación del evento {Zt} —que llamaremos el token de la entidad en el instante t— que captura cómo los campos definen conjuntamente el estado del evento. Este es el primer lugar donde el modelo puede expresar afirmaciones como: «este valor de throughput es alarmante dada esta capacidad del dispositivo, esta congestión de la celda y este contexto de ubicación», no como una regla, sino como una interacción aprendida.

Un ejemplo concreto hace evidente la necesidad. Supongamos que un evento es el registro de un examen radiológico: la queja del paciente y su historia clínica (texto), el protocolo de escaneo (categórico + numérico), el uso de contraste (categórico), los cortes de imagen (modalidad de visión) y el informe del radiólogo (texto). Interpretar las imágenes sin condicionar por protocolo y contexto es un problema fundamentalmente mal planteado: el mismo patrón de píxeles puede significar cosas distintas según la configuración de adquisición y los antecedentes clínicos (priors). La capa de fusión es donde el modelo aprende estas dependencias condicionales, alineando las modalidades en un significado coherente a nivel de evento.

En dominios como el modelado de CTR (y, más generalmente, la toma de decisiones tabular de alta dimensión), es común describir el modelado de interacciones como explícito o implícito. Las capas de interacción explícita (por ejemplo, cross layers / cruces polinomiales de features) construyen deliberadamente combinaciones de campos (usualmente, de orden bajo a medio). Son líneas base (baselines) sólidas porque capturan eficientemente patrones del tipo «si A y B, entonces…» y a menudo mejoran la eficiencia muestral en datos tabulares dispersos.

Si bien los cruces explícitos son efectivos, esconden una limitación importante: típicamente asumen que multiplicar coordenadas en una base arbitraria es una noción fiel de «interacción». Pero los embeddings no son mediciones crudas; viven en espacios de representación cuya geometría es aprendida y cuyas coordenadas no son semánticamente privilegiadas. De ello se siguen dos consecuencias:

1. Sensibilidad a la base. Un cruce polinomial no es invariante ante reparametrizaciones del espacio de embedding. La misma configuración semántica puede verse diferente bajo una rotación/escalado equivalente de las coordenadas y, sin embargo, la capa de cruce responderá de manera diferente.
2. Desajuste de modalidades. Los campos de un evento provienen de codificadores fundamentalmente distintos (numérico, categórico, texto, imagen). Combinarlos ingenuamente mediante álgebra coordenada a coordenada puede sobreponderar al codificador que produzca activaciones de mayor varianza, a menos que el mecanismo de fusión aprenda una alineación consciente de la métrica.

Por esta razón, un bloque robusto de fusión local debe entenderse como el aprendizaje de una geometría para la interacción, y no meramente como el apilamiento de productos algebraicos de features. En nuestra configuración, se usan espacios cuaterniónicos y de girovectores (gyrovector spaces) para que el operador de fusión trate las representaciones como si vivieran en un espacio latente donde la combinación significativa corresponde a una «reorientación estructurada»: las señales se transforman de una manera que separa «cuán fuerte» es un componente de «hacia qué dirección» apunta. De esta forma, las interacciones emergen como rotaciones aprendidas (isometrías) y reescalados controlados que alinean los factores compatibles y decorrelacionan los conflictivos.

Intuitivamente, en lugar de pedirle al modelo que descubra estructura mediante multiplicaciones coordenada a coordenada en una base arbitraria, le permitimos aprender cómo la información del evento debe moverse rígidamente a través del espacio de representación, de modo que los ángulos relativos, las relaciones de tipo fase y la mezcla que preserva la norma se conviertan en las primitivas de la fusión antes de proyectar de vuelta a la dimensión de trabajo del modelo. Esto hace que el mecanismo de interacción sea mucho menos dependiente de la elección accidental de coordenadas y más fiel a la idea de que lo que importa en la fusión es la alineación, la orientación y la estructura invariante: una geometría aprendida para la interacción.

Backbones

El backbone temporal es el componente que convierte un flujo de eventos fusionados y ordenados en el tiempo en una trayectoria contextualizada y un estado latente actual para cada entidad. Su trabajo no es meramente «recordar» lo que sucedió, sino aprender cómo las interacciones pasadas condicionan el significado del presente.

El backbone temporal consume una secuencia de tokens de eventos {Z1, Z2, …, Zn}, donde cada token ya representa un evento con sus interacciones intra-evento resueltas (a través de las capas de fusión). Produce como salida un vector de estado actual que representa todo lo que el modelo «sabe» sobre la entidad en el instante t. Esta representación debe soportar la predicción bajo causalidad: en el instante t, el estado latente debe depender únicamente de eventos que ocurrieron en instantes anteriores.

Muchas dinámicas empresariales no son puramente temporales: también son relacionales. Los clientes comparten hogares, dispositivos, comercios, empleadores, ubicación, etc. El backbone espacial captura esta estructura modelando cómo la trayectoria de una entidad es moldeada por su vecindario dentro de un sistema más amplio.

Aunque es tentador definir un vecindario de manera puramente topológica, elaborando a mano reglas sobre qué entidades están «relacionadas» (mismo segmento, misma región, perfil similar), esto reintroduce rápidamente el mismo sesgo que intentamos evitar: codificamos de forma fija lo que la similitud debería significar. Un enfoque más robusto es tratar la selección del vecindario como un problema geométrico aprendido. El estado de cada entidad en el instante t vive en el espacio latente del modelo; la proximidad en ese espacio define una noción de «contexto de pares» que puede cambiar con el tiempo a medida que cambia el comportamiento. En la práctica, el backbone espacial opera como un mecanismo acotado de recuperación y atención (retrieval-and-attend): dado el estado actual, recupera un pequeño conjunto de estados cercanos y les aplica atención cruzada (cross-attention) para producir un estado enriquecido con contexto. Esto hace que «quién influye sobre quién» sea una propiedad emergente del entrenamiento y no una decisión de diseño externa, permitiendo a la vez que se hagan cumplir restricciones operativas como la consistencia temporal y los presupuestos de cómputo. La salida es un único estado latente fusionado que porta tanto la historia personal (backbone temporal) como la posición en el sistema (backbone espacial), y ese estado se convierte en la interfaz a través de la cual el modelo produce pronósticos o decisiones aguas abajo.

En síntesis, el backbone temporal aprende qué sucedió y qué significa ahora; el backbone espacial aprende quién es relevante en este momento. Ambos se aprenden, no se prescriben.

Procesador del espacio latente

El procesador de estado latente es la etapa de «lectura y control»: toma el estado latente producido por los backbones y lo convierte en salidas operativas que son o bien mediciones (predicciones) o bien acciones estructuradas (intervenciones). Aquí es donde la arquitectura se vuelve de cara al negocio: el procesador define qué puede decir el modelo y, crucialmente, cuán directamente puede actuar.

En el instante t, el procesador recibe el estado actual de la entidad y, opcionalmente, un conjunto de contexto relacional proveniente del backbone espacial. También puede recibir contexto de objetivos (metas de campaña, restricciones de producto, topes de presupuesto, régimen regulatorio) para que las salidas estén condicionadas al modo de operación en lugar de estar codificadas de forma fija.

Para el post-training predictivo, el procesador mapea el estado latente a salidas tales como probabilidades/riesgos sobre múltiples horizontes, pronósticos (conteos, montos, uso), rankings (siguiente mejor producto, probable tema de reclamo) y embeddings para recuperación/segmentación. Una propiedad clave de un buen procesador es la consistencia multitarea: un único estado latente debe soportar muchas salidas sin requerir un modelo separado por target. Esto usualmente se implementa como un tronco compartido (los backbones) con múltiples heads de tarea livianos (heads de clasificación/regresión/ranking) que pueden extenderse a medida que se agregan nuevos targets.

Para el uso prescriptivo, el procesador produce un objeto de acción en lugar de scores escalares. El objeto es estructurado (campos tipados, elecciones discretas, parámetros numéricos) y está diseñado para ser directamente consumible por sistemas aguas abajo, incluso por un Large Language Model (LLM). Las salidas deben optimizar la utilidad de la organización (margen, retención, costo de servicio, experiencia) en lugar de un proxy como la probabilidad de incumplimiento por sí sola. Además, el procesador debe hacer cumplir guardrails en el momento de la generación. En la práctica, esto puede hacerse mediante decodificación restringida (solo se pueden producir acciones válidas), mediante términos de penalización en el entrenamiento y mediante un módulo de factibilidad que proyecta las acciones sugeridas sobre el conjunto de políticas permitidas.

Orquestando decisiones con interfaces LLM

Si bien un LDM produce decisiones estructuradas, esas decisiones aún deben comunicarse y ejecutarse a través de las interfaces mediante las cuales las compañías interactúan con sus clientes. En la práctica, esta capa de interfaz está cada vez más mediada por Large Language Models (LLMs). En esta arquitectura, el LDM actúa como el motor de decisión del sistema, generando objetos de acción estructurados que codifican qué debe hacerse para un cliente específico bajo los objetivos económicos y las restricciones de política de la organización. El LLM, a su vez, actúa como la capa de interacción que traduce esas decisiones en comunicación contextualizada y orquesta su entrega a través de canales de cara al cliente, como apps, plataformas de mensajería, herramientas de call center o agentes digitales.

En esta división de roles, el LDM es responsable de razonar sobre el estado operativo de la compañía y producir la intervención óptima, mientras que el LLM funciona como el vehículo que operacionaliza la acción. El LLM interpreta el objeto de acción estructurado —incluyendo productos recomendados, pricing, momento oportuno y restricciones de mensajería— y genera la comunicación legible por humanos o la ejecución del flujo de trabajo apropiadas. Dado que la decisión misma se origina en el LDM, el LLM no determina qué acción debe tomarse; simplemente asegura que la decisión llegue al cliente de una forma coherente, personalizada y adecuada al canal. Esta separación preserva la gobernanza y la auditabilidad, a la vez que habilita la flexibilidad de las interfaces conversacionales.

En la práctica, esta arquitectura se asemeja a la separación entre un sistema de control y una capa de comunicación: el LDM gobierna la política de acción, mientras que el LLM gobierna cómo esa política se expresa y se entrega. El resultado es un sistema unificado en el que la inteligencia predictiva, la optimización de decisiones y la interacción con el cliente operan como capas coordinadas y no como subsistemas independientes.

---

Footnotes

1. Curiosamente, el juego de ajedrez humano no se basa en realidad en enormes capacidades de cálculo anticipado; obviamente, algo de capacidad de anticipación está involucrada, pero los ajedrecistas de élite no son tanto calculadores de fuerza bruta como reconocedores veloces. El campeón mundial Vladimir Kramnik dice que, más allá del juego «de libro», a nivel de gran maestro, «a veces no tienes que pensar tanto»: la jugada puede llegar casi automáticamente. La investigación cognitiva clásica coincide con este testimonio: los estudios de protocolo de de Groot no encontraron grandes diferencias en las estadísticas de profundidad de búsqueda, y Chase y Simon resumen que los maestros a menudo consideran «aproximadamente el mismo número de posibilidades —quizás, incluso menos—» que jugadores más débiles, pero son dramáticamente mejores para generar las jugadas candidatas correctas a analizar. Sin embargo, al no poder enseñar directamente esas representaciones internas a nivel de tablero (los motivos tácitos y las impresiones posicionales que los maestros adquieren a lo largo de los años), tenemos que aproximarlas. Y esto conduce a funciones de evaluación construidas a mano, como pesos de material, términos de seguridad del rey, penalizaciones por estructura de peones, bonificaciones por movilidad e incontables otras heurísticas diseñadas por humanos. Así, los motores clásicos intentan compensar sus limitaciones representacionales con computación bruta. ↩

2. Modelos de Click-Through Rate (tasa de clics), diseñados para predecir la probabilidad de que un usuario haga clic en un enlace determinado. ↩

3. Net Promoter Score, un puntaje de lealtad del cliente que es un indicador clave de la satisfacción del cliente y la recomendación de marca. ↩

4. Aunque, dependiendo de la estructura de los datos, es más adecuado usar un producto de espacios de curvatura negativa (como el espacio hiperbólico), espacios de curvatura positiva (como los espacios proyectivos) y espacios lorentzianos (como los espacios de de Sitter y anti-de Sitter). ↩