NeoLDM — Large Data Models

A Segunda Onda das Decisões Orientadas por Dados

Batendo no Muro: Como o Deep Learning Estilhaça os Limites do Machine Learning Clássico

“Não descrevemos o mundo que vemos; vemos o mundo que conseguimos descrever.”

R. D. Laing

A era da transformação digital trouxe uma força inegável que levou as empresas a redesenhar a experiência de seus clientes. À medida que produtos e jornadas migraram para aplicativos, web e canais de atendimento automatizados, o negócio passou a produzir uma grande quantidade de dados de eventos: cada interação do cliente com a empresa – abrir o aplicativo, navegar por um produto, simular um empréstimo, fazer um investimento, reservar um voo, contratar um seguro, realizar uma compra, pagar uma conta, contatar o suporte ou alterar dados pessoais – passou a gerar registros nos bancos de dados da empresa.

Naturalmente, ao enxergar nesses dados informações cruciais para embasar previsões e inferências sobre o comportamento futuro dos clientes, as empresas começaram a investir em infraestrutura de dados escalável e em pipelines de ingestão, consolidando os dados em data lakes para criar uma base confiável na qual dados de diversos sistemas pudessem ser armazenados, padronizados e tornados utilizáveis. As principais linhas de pesquisa em Machine Learning, no entanto, costumavam ver os dados brutos como ruidosos e granulares demais para orientar decisões diretamente. Além disso, havia uma falta generalizada de poder computacional para processar fluxos de eventos em motores de predição. Assim, cientistas e engenheiros de dados começaram a transformar esses eventos brutos em “features”, que deveriam ser vistas como sinais compactos, mais “prontos para a decisão”, que resumem o comportamento do cliente.

Em vez dos dados brutos, as empresas passaram a se apoiar em agregações de dados como médias, desvios padrão, máximos, mínimos, frequência e recência dos dados. Dessa forma, as feature stores tornaram-se onipresentes, constituindo a camada operacional que organiza essas agregações de dados para que possam ser reutilizadas de forma consistente entre times e modelos, mantendo-as atualizadas na frequência adequada e garantindo que sejam aplicadas em produção da mesma maneira como foram definidas e aplicadas durante o treinamento.

Não raro, as organizações construíam um ecossistema inteiro de modelos especializados – às vezes, centenas deles – sob medida para produtos, canais, objetivos e segmentos específicos. A orquestração desses ecossistemas passou a depender de regras de parametrização, que se tornaram as camadas de decisão responsáveis por converter previsões em ações concretas, combinando as saídas de Machine Learning com regras de negócio, restrições de política, limites de orçamento e de exposição. Nascia um pipeline “industrial”: eventos viravam features, features alimentavam modelos, as saídas dos modelos encontravam regras de negócio para se tornarem ofertas e, por fim, mais recentemente, agentes de IA baseados em grandes modelos de linguagem, combinados com os aplicativos das empresas ou aplicativos de comunicação de uso geral, tornaram-se a camada final pela qual as ofertas finalmente chegam ao cliente.

No entanto, essa dependência de features projetadas por humanos, embora proporcione interpretabilidade e alinhamento com a lógica de negócio estabelecida, restringe inerentemente o potencial exploratório do modelo. Como essas features são projetadas com base em conhecimento prévio de negócio, elas efetivamente atuam como um filtro que reforça os paradigmas operacionais existentes, frequentemente impedindo o modelo de identificar fatores causais novos e não óbvios. Essa “impressão de conhecimento” (knowledge-imprinting) pode criar um viés de confirmação daquilo que já se sabe, potencialmente deixando passar conjuntos complexos de sinais causais fracos que, se analisados de forma holística, sem a restrição da engenharia manual de features, poderiam se aglutinar em insights acionáveis e de alto valor, antes escondidos no ruído dos dados.

Esse cenário de tomada de decisão orientada por dados ainda constitui o estado atual da maioria das empresas. Ele exige investimentos enormes e esforço especializado constante na definição de regras. Mesmo assim, esse pipeline é muito lento para reagir a mudanças estruturais de mercado, é muito menos hiperpersonalizado do que pareceria à primeira vista e está longe de ser tão preciso quanto permitiria a informação embutida nos dados brutos originais de eventos.

O que descrevemos até aqui é, essencialmente, o paradigma clássico de Machine Learning operando em escala industrial: eventos brutos são transformados em features agregadas, features são organizadas em feature stores, modelos consomem essas features e camadas de decisão orquestram as saídas por meio de regras e restrições. O Deep Learning moderno, no entanto, muda a abordagem padrão ao fazer do fluxo bruto de eventos – e não de suas agregações – o ativo central. Quando os modelos conseguem aprender diretamente de históricos transacionais, sequências comportamentais e interações não agregadas (incluindo texto), eles tendem a reagir mais rápido a mudanças estruturais de mercado, viabilizam previsões verdadeiramente em tempo real e alcançam melhor desempenho preditivo.

Deixe os dados falarem

“A descrição não é o descrito.”

– Jiddu Krishnamurti

Uma das maiores mudanças de perspectiva do Machine Learning clássico para o Deep Learning moderno diz respeito a quanto realmente precisamos “ensinar” o modelo ou, mais especificamente, o quanto os modelos se beneficiam do nosso conhecimento de domínio sobre um determinado campo versus aprendê-lo por conta própria.

Um exemplo revolucionário vem do AlphaZero, da DeepMind. Antes do AlphaZero, os motores de xadrez de melhor desempenho se pareciam muito com o pipeline “industrial” que descrevemos: primeiro construíam-se manualmente representações do que importava (equilíbrio material, estrutura de peões, segurança do rei, mobilidade e muitas outras heurísticas) e, em seguida, usavam-se procedimentos de busca (poda alfa-beta, lookahead extensivo) guiados por esses sinais. Mesmo com capacidade sobre-humana de força bruta, o motor ainda navegava pelo jogo por meio de uma descrição projetada por humanos do que seria um “bom xadrez”.¹

O AlphaZero foi um contraponto. Ele foi construído sobre uma premissa enganosamente simples: não diga ao modelo o que é uma “boa posição”. Não codifique séculos de entendimento sobre xadrez. Não construa um catálogo de features do “que importa”. Dê ao sistema apenas as regras do jogo, o objetivo (vencer e o que vencer significa) e a capacidade de gerar experiência jogando contra si mesmo. O que aconteceu foi que o AlphaZero aprendeu duas coisas ao mesmo tempo:

1. Uma representação rica do estado (quais aspectos da posição do tabuleiro são importantes e como eles se combinam), e
2. Uma política de decisão (quais lances considerar e priorizar), guiada pelo feedback dos resultados.

Em outras palavras, ele aprendeu a descrever o mundo de uma maneira que torna a vitória possível – em vez de herdar uma descrição humana.

O AlphaZero derrotou de forma convincente o Stockfish (à época, o sistema de xadrez mais avançado) em um confronto de 100 partidas, com 28 vitórias, 72 empates e 0 derrotas. Desde então, o Stockfish evoluiu ao incorporar componentes (por exemplo, NNUE) para reduzir a complexidade da busca por meio do aprendizado de representações significativas.

A mesma mudança se aplica além dos jogos de tabuleiro. Um modelo clássico de credit scoring, por exemplo, seria treinado sobre diversas agregações de dados, como médias, desvios padrão, máximos/mínimos, contagens, frequência/recência, janelas móveis, razões escolhidas a dedo e assim por diante. Mas é dos dados que deram origem a essas agregações que um modelo profundo mais se beneficiaria. Em vez de ficar restrito às estatísticas que escolhemos, o modelo pode buscar estruturas mais ricas em sequências e interações: não apenas com que frequência algo aconteceu, mas em que ordem, sob qual contexto, como os padrões evoluem e quais combinações importam – incluindo combinações que ninguém jamais pensaria em construir manualmente.

Há várias maneiras pelas quais a agregação pode prejudicar o aprendizado:

1. Perda de informação (irreversibilidade). Em geral, é impossível recuperar os dados originais a partir de suas agregações.
2. Inexpressividade para certas modalidades. Alguns insumos são inerentemente difíceis de agregar de forma significativa, como texto bruto. Ainda assim, eles podem ser decisivos para uma tarefa (pense no papel da interação de um cliente com a empresa via WhatsApp na predição da propensão desse cliente a comprar um determinado produto).
3. Sub-representação da esparsidade. Quando os dados são agregados ao longo do tempo ou de eventos, dados esparsos (como, no exemplo acima do modelo de credit scoring, os eventos de um cliente com poucas transações) tendem a ser “lavados” do conjunto de dados, levando a um desempenho muito ruim do modelo nesses casos.
4. Viés injetado. Mais sutil é o fato de que, ao escolher como os dados são agregados, estamos impondo ao modelo um viés, isto é, uma certa visão de mundo que reflete o que geralmente se chama de “conhecimento de domínio”. Embora isso possa parecer algo bom, pode bloquear exatamente o que queremos de um modelo preditivo: uma maneira genuinamente nova de olhar para os dados.
5. Custo e manutenção das feature stores. Construir e manter uma feature store é um trabalho caro e especializado, exigindo uma equipe que entenda tanto as técnicas de modelagem quanto o domínio de conhecimento relevante. Isso é especialmente verdadeiro quando uma nova fonte de dados precisa ser introduzida, já que ela precisa ser profundamente avaliada e estudada antes que novas agregações significativas sejam adicionadas à store.
6. Especificidades de domínio. Escolhas e estratégias de agregação que funcionam para um determinado domínio não funcionam para outros (por exemplo, janelas de agregação típicas de um modelo de credit scoring, em geral, não terão bom desempenho em um modelo de CTR²).
7. Mudanças estruturais do mercado. Não é incomum que agregações de dados funcionem bem durante um certo período de tempo, mas se tornem menos eficazes (ou até totalmente ineficazes) em outros períodos, devido a novidades relevantes que podem causar uma mudança estrutural em uma tarefa de predição.
8. Rigidez temporal e estrutural. A agregação tradicional depende de janelas temporais fixas (por exemplo, médias móveis de 30 dias), que implicitamente assumem uma relação estática entre a feature e o target. Isso cria um modelo “frágil”, que tem dificuldade em se adaptar a mudanças rápidas no comportamento do consumidor ou a deslocamentos de mercado. Quando a dinâmica de mercado subjacente muda, essas agregações codificadas de forma rígida frequentemente falham, pois carecem da flexibilidade para redefinir seu próprio escopo preditivo em tempo real.
9. Perda da volatilidade comportamental (a “tirania da média”). Métodos de agregação como médias ou medianas inerentemente suavizam os dados, priorizando estabilidade em detrimento de precisão. Em muitos domínios — como detecção de fraude ou credit scoring — o sinal mais preditivo não é o comportamento “típico”, mas sim o desvio súbito e acentuado, ou o “pico” isolado de atividade. Ao condensar esses eventos em resumos estatísticos, efetivamente “lavamos” justamente as assinaturas comportamentais que sinalizam uma mudança iminente de risco ou de propensão, tornando o modelo insensível a anomalias críticas de alto impacto.
10. Impressão de conhecimento (knowledge-imprinting) e cegueira causal. Ao forçar os dados a entrar em categorias de features predefinidas, essencialmente restringimos o modelo a “confirmar” hipóteses de negócio existentes, em vez de permitir que ele descubra padrões fundamentais nos dados. Essa “impressão de conhecimento” atua como um filtro que reforça paradigmas operacionais estabelecidos, impedindo o modelo de identificar fatores causais novos e não óbvios. Consequentemente, podemos deixar passar conjuntos complexos de sinais causais fracos e fragmentados que, se analisados de forma holística, sem a restrição da engenharia manual de features, poderiam se aglutinar em insights novos e de alto valor.

Ilustrações interessantes deste último ponto são a introdução, no Brasil, das transações via Pix (transações interbancárias instantâneas que se tornaram o método de pagamento dominante, capturando aproximadamente 50% de todas as transações e movimentando um volume total de quase US$ 7 trilhões ao longo de 2025) e a recente e acentuada ascensão dos aplicativos de apostas online. Essas novidades remodelaram completamente o cenário da predição de inadimplência de crédito no país.

Um modelo profundo adequadamente projetado e treinado deve eliminar completamente esse tipo de preocupação. Mudanças estruturais no problema de predição passam a ser naturalmente incorporadas e tratadas, porque o deslocamento do comportamento estrutural é capturado em tempo real por meio dos próprios dados brutos. A ausência de períodos de agregação leva a previsões em tempo real (uma única transação de cartão de crédito pode disparar instantaneamente uma reavaliação do limite de crédito disponível, por exemplo).

Até aqui, olhamos apenas para as entradas do modelo, mas uma mudança de perspectiva semelhante também se aplica às saídas. De fato, no paradigma clássico, estamos na verdade usando proxies duas vezes: uma quando features tomam o lugar dos dados brutos; e outra quando decisões no nível do cliente são colapsadas em scores-proxy que exigem uma camada separada de regras para se tornarem uma ação. Em outras palavras, o modelo não deve apenas aprender diretamente do fluxo bruto de eventos; ele deve também produzir decisões estruturadas e específicas para cada cliente.

Deixe o modelo agir

“Bem feito é melhor que bem dito.”

– Benjamin Franklin

Se vamos deixar os dados falarem, também temos que deixar o modelo responder na linguagem da ação. Na configuração clássica, a saída do modelo ainda é uma abstração: scores que precisam ser interpretados, traduzidos em limiares, tabelas de política e regras manuais. Mas essa camada de tradução é, na verdade, um segundo modelo sendo alimentado com dados agregados, porque os scores nada mais são do que uma versão muito comprimida e simplificada das ricas representações do modelo, aprendidas a partir do fluxo bruto de eventos. Portanto, para além dos scores, devemos deixar o modelo traduzir essas representações em ações hiperpersonalizadas.

Em uma arquitetura moderna de crédito, o modelo não deve mais responder a uma pergunta preditiva estreita como “Qual é a probabilidade de inadimplência deste cliente nos próximos 12 meses?” para então depender de regras a jusante, tabelas de política e parametrização manual para converter essa estimativa em ação. Em vez disso, o sistema deve resolver diretamente um problema de decisão com restrições e produzir um objeto de ação: uma saída estruturada e auditável que especifica o que deve ser feito para este cliente específico, dados os objetivos econômicos da instituição, suas restrições de capital e seus limites regulatórios.

Nesse cenário, o modelo não está meramente prevendo risco; está otimizando uma decisão no nível do cliente sob objetivos explícitos — por exemplo, maximizar o retorno esperado ajustado ao risco ou o MFL menos o custo de capital — sujeito a restrições de portfólio, regulatórias e de justiça (fairness).

Concretamente, em vez de um único score de crédito, o sistema produziria:

• Uma linha de crédito recomendada (ou um ajuste de linha), acompanhada de estimativas de incerteza e das implicações de consumo de capital.
• Condições de precificação selecionadas para otimizar a margem esperada líquida de risco e de custos de captação (funding), de forma consistente com o apetite de risco da instituição e com considerações de valor do cliente ao longo do tempo (customer lifetime value).
• Seleção de produto e canal: se a próxima melhor ação é um aumento de limite, uma transferência de saldo, uma migração para produto com garantia, uma proposta de reestruturação ou nenhuma oferta — e se ela deve ser entregue digitalmente, por push notification, e-mail ou por meio de um agente humano.
• Timing e cadência: quando disparar a intervenção, levando em conta sinais comportamentais (por exemplo, entradas pós-salário, padrões de transação, interações de atendimento) e condições dinâmicas do portfólio.
• Restrições com guardrails embutidos: saídas que já respeitam limites de exposição, limiares de concentração, exigências regulatórias, métricas de justiça (fairness), limites de capital em cenários de estresse e tetos de orçamento comercial.

Crucialmente, esse objeto de ação não deve ser estático. Ele deve estar inserido em um ciclo de aprendizado contínuo, no qual os resultados realizados — aceitação, comportamento de pagamento, evasão de clientes (attrition) e lucratividade — retroalimentam o motor de política. O sistema deve distinguir entre o comportamento natural do cliente e o comportamento induzido pela intervenção, incorporando mecanismos causais ou de uplift para garantir que as ações recomendadas gerem valor incremental, em vez de meramente prevê-lo.

Sob esse paradigma, a modelagem de crédito evolui da estimação de scores para a otimização de políticas. A saída não é mais um número que precisa ser traduzido em ação; é um framework de decisão que integra risco, retorno, experiência do cliente e coerência de portfólio em um único objeto executável.

Em outras palavras, a saída do modelo está mais próxima de uma política de crédito hiperpersonalizada do que de um score. Para um cliente, a melhor decisão pode ser “reduzir a exposição, mas melhorar a retenção”: propor um aumento de limite menor (ou nenhum), oferecer um plano de reestruturação e escolher uma comunicação empática para proteger o NPS³. Para outro, pode ser “aumentar a exposição agressivamente”: um limite maior com uma taxa menor, porque o modelo enxerga alta estabilidade, padrões fortes de fluxo de caixa e forte valor de longo prazo. A questão é que isso não são “segmentos”, mas políticas individuais geradas a partir da trajetória do cliente.

Se o sistema é treinado apenas para prever inadimplência, ele pode otimizar para evitar perdas, mas frequentemente ao custo de recusar clientes lucrativos e/ou prejudicar a experiência. Mas se o objetivo é definido no nível certo — digamos, “maximizar a contribuição esperada ao longo da vida do cliente” (receita menos perdas e custos), mantendo o NPS e a retenção de longo prazo —, o modelo pode aprender decisões que equilibram diretamente risco, margem e qualidade do relacionamento. O score pode ser visto como um sinal latente interno, mas não é o produto. O produto é a ação: o limite, as condições, a oferta, o timing e a mensagem certos para este cliente, sob restrições explícitas de governança.

Um modelo com tais capacidades pode ser visto como o cérebro de IA fundacional da empresa moderna. Nós o chamamos de Large Data Model.

Large Data Model – LDM

Um Cérebro de IA Fundacional

“É o padrão [...] que é a pedra de toque da nossa identidade pessoal. [...] Não somos mais que redemoinhos em um rio de água que flui sem cessar. Não somos matéria que permanece, mas padrões que se perpetuam. Um padrão é uma mensagem, e pode ser transmitido como uma mensagem.”

– Norbert Wiener

Um Large Data Model (LDM) é uma arquitetura profunda baseada em transformers, pré-treinada do zero sobre os dados operacionais brutos de um sistema de negócio. Aqui, “sistema de negócio” é usado em sentido amplo: pode se referir a um banco, hospital, operadora de telecomunicações, seguradora, escritório de advocacia, empresa de energia, organização esportiva, universidade ou qualquer ecossistema de entidades em interação cujas atividades gerem dados estruturados de eventos.

Diferentemente dos modelos tradicionais de machine learning treinados em tabelas de features curadas, um LDM é treinado diretamente sobre sistemas de registro (systems-of-record) e logs de interação: atualizações de perfil de clientes, compras, transações, sessões digitais, sinistros, tickets, interações de CRM, eventos operacionais e outras transições de estado. O modelo ingere esses sinais heterogêneos, ordenados no tempo, e aprende a dinâmica conjunta de clientes, produtos, operações e decisões organizacionais. Na prática, o pré-treinamento é tipicamente autossupervisionado, permitindo que o modelo aprenda uma representação comprimida do estado em evolução da empresa sem exigir rótulos específicos de tarefa.

Um LDM não é um modelo de linguagem. Seu propósito não é a geração de texto nem a comunicação humana. Ele é, antes, um modelo de fundação (foundation model) para a própria empresa. Por meio de pré-treinamento em larga escala sobre dados brutos de negócio, ele adquire uma representação generalizada de como a empresa e seu ecossistema se comportam ao longo do tempo. Após o pós-treinamento ou a adaptação a tarefas específicas, essa representação pode ser aproveitada para alimentar previsões e tarefas de apoio à decisão, como avaliação de risco, previsão de demanda, predição de churn, precificação, detecção de fraude, alocação de capital e políticas de next-best-action.

Nesse sentido, um LDM funciona como a camada de inteligência fundacional da empresa: um modelo unificado de sua memória operacional e de sua dinâmica comportamental.

Impacto operacional

Com todos os nossos clientes até agora, o paradigma do Large Data Model demonstra consistentemente melhorias substanciais de desempenho em relação às abordagens tradicionais de machine learning construídas sobre features projetadas manualmente. Em mais de 12 tarefas preditivas e de apoio à decisão em conjuntos de dados corporativos de larga escala — particularmente em setores intensivos em dados, como serviços financeiros —, modelos treinados diretamente sobre fluxos brutos de eventos alcançaram ganhos de desempenho tipicamente entre 15% e 60% de melhoria relativa em comparação com pipelines convencionais de machine learning baseados em árvores ou com modelos específicos de tarefa ajustados de forma restrita via fine-tuning.

Essas melhorias aparecem de forma consistente em tarefas que envolvem dinâmicas comportamentais complexas, nas quais dependências temporais de longo alcance, sinais esparsos e modalidades de dados heterogêneas desempenham papel decisivo. Experimentos iniciais conduzidos em outros domínios com dados operacionais igualmente ricos mostram resultados promissores que seguem padrões semelhantes.

É importante notar que esses ganhos não se limitam apenas à acurácia preditiva. Como os LDMs aprendem representações unificadas do comportamento operacional, eles frequentemente reduzem a necessidade de manter grandes ecossistemas de modelos especializados e de features construídas à mão. Isso leva não apenas a sinais preditivos mais fortes, mas também a uma infraestrutura de modelagem mais simples e adaptável, particularmente em ambientes nos quais o comportamento do cliente, as condições de mercado ou a dinâmica dos produtos evoluem rapidamente.

Pré-treino: construindo entendimento e percepção

Durante a fase de pré-treino do LDM, o modelo aprende interconexões profundas entre os dados da empresa. Espera-se que essas interconexões sejam bastante intrincadas, e a matemática por trás delas mostra que, de fato, elas normalmente têm “ordem alta”, são bastante “implícitas” ou dependem de transformações geométricas complexas para serem expostas (ver a seção “Camadas de fusão local”). Também é importante notar que, antes do pré-treino, os pesos do modelo são aleatórios, isto é, não há treinamento prévio do modelo em dados tabulares genéricos, e os únicos dados que o modelo vê são os dados da empresa.

Para compreender melhor o pré-treinamento, tratemos de um exemplo concreto. Nossa “empresa” será uma operadora de telecomunicações tier-1 fictícia, cujos bancos de dados centrais incluem, entre outros, dados sobre sessões e desempenho de rede, registros detalhados de chamadas (CDRs), medições de rádio e KPIs por célula, inventário de dispositivos e SIMs, ativações e mudanças de plano, eventos de faturamento e cobrança, eventos de pagamento e inadimplência, interações de atendimento ao cliente (IVR, chat, tickets, reclamações), visitas de técnicos de campo, eventos de roaming, contatos de marketing e histórico de churn/reativação. Assim, dado um cliente (ou domicílio / conta) e um determinado intervalo de tempo, o modelo veria uma sequência de eventos como a mostrada abaixo (para fins de ilustração, os registros do conjunto de dados são exibidos de forma simplificada):

Agora, o modelo deve ser treinado para entender a história de cada cliente para que, mais tarde, possamos ensiná-lo a intervir nelas. O pré-treinamento é uma fase autossupervisionada, o que significa que nenhum rótulo humano é necessário. Em vez disso, o objetivo do modelo é aprender a prever eventos futuros a partir dos passados. Mais precisamente, ao alimentar o LDM com os eventos que aconteceram nos instantes anteriores, esperamos que o LDM seja capaz de prever pelo menos o próximo evento do cliente (idealmente, o LDM deve ser treinado para prever alguns dos próximos eventos do cliente). Assim, se o modelo vê a trajetória acima

[...] → latência alta → queda de chamada de voz → quedas repetidas de rede → ?

ele deve prever qual evento é provavelmente o próximo: uma ligação para o suporte? Um downgrade de plano? Um pedido de portabilidade (port-out)? Uma troca de aparelho? Ele também deve prever cada aspecto específico do próximo evento. Assim, neste exemplo, o modelo deve prever que o próximo evento é mais provavelmente uma reclamação via “chat” sobre “má cobertura em ambientes internos”, pelo canal “app”, no idioma “pt-BR”. Isso força o modelo a entender, entre muitas outras coisas, padrões de degradação da qualidade de serviço, o comportamento do cliente sob atrito e a interação entre a experiência de rede e os resultados comerciais.

Além da predição do(s) próximo(s) evento(s), há outros objetivos que ajudam o modelo a criar representações expressivas dos conjuntos de dados. Com a modelagem de eventos mascarados (masked event modeling), por exemplo, o modelo deve prever uma parte faltante de um evento. Por exemplo, ao pedir que o modelo infira o valor de throughput ausente no evento

[Rede | sessão_de_dados | célula 21A | RSRP -112 | SINR 3 | DL ____ | latência 180ms | casa]

ele precisa aprender a entender condições de rádio, padrões de congestionamento, restrições de capacidade dos dispositivos, efeitos de localização/horário e faixas típicas para clientes e células semelhantes.

Depois de ver as jornadas de milhões de clientes, o modelo encontrará incidentes raros, casos extremos, peculiaridades de roaming, regressões de firmware de dispositivos, congestionamentos sazonais, mudanças de protocolo ao longo dos anos, campanhas de mercado, diferenças de práticas entre equipes… ele aprende padrões que nenhum analista sozinho conseguiria observar ao longo de uma vida. Mais ainda: ele é capaz de encontrar interconexões entre esses padrões que estão muito além da capacidade humana. A percepção emerge à medida que o modelo compreende arquétipos de uso, padrões de comportamento de longo prazo dos clientes, desvios incomuns de trajetória, quais assinaturas de rede se agrupam, como a qualidade de serviço evolui por geografia e tempo, como as intervenções mudam trajetórias, quais padrões precedem churn, inadimplência ou reclamações repetidas etc. O modelo agora aprendeu profundamente a estrutura da experiência do cliente e da entrega de serviço dentro daquela operadora.

Diferentemente do pré-treinamento, a fase de pós-treinamento de um LDM exige a criação de targets particularmente adequados à tarefa que esperamos que o modelo desempenhe. Dividimos o pós-treinamento em duas categorias: o Pós-Treinamento Preditivo e o Pós-Treinamento Prescritivo.

Pós-treino Preditivo: construindo poder de previsão

O pós-treinamento preditivo transforma as representações pré-treinadas em medidas: scores, rankings, embeddings, previsões, segmentos, resultados financeiros e outras saídas não executórias. Por definição, um LDM com pós-treinamento preditivo não decide o que fazer — ele resume e antecipa o que provavelmente vai acontecer e, portanto, ainda requer uma camada externa de política (limiares, regras de capacidade, tabelas de elegibilidade) para converter previsões em ações.

Operacionalmente, o pós-treinamento preditivo exige rotular o fluxo de eventos. Para cada entidade (cliente / conta / domicílio) e instante t, criamos targets definidos sobre uma janela futura [t, t + Δ]. Exemplos em um contexto de Telecom incluem:

• churn/portabilidade em 30/60/90 dias,
• inadimplência no próximo ciclo de faturamento,
• novo contato com o atendimento em 7 dias,
• escalonamento de reclamação em 14 dias,
• degradação persistente de QoE ao longo da próxima semana.

Cada target é construído varrendo os logs brutos para a frente a partir de t e marcando se o(s) evento(s) de interesse ocorre(m) no horizonte escolhido. O modelo é então treinado para mapear a trajetória histórica até t nesses rótulos (frequentemente vários de uma vez, em uma configuração multi-target). Como essa fase se apoia em representações pré-treinadas fortes, uma única passada de pós-treinamento pode cobrir múltiplos horizontes e desfechos sem exigir um modelo dedicado por target.

Pós-treino Prescritivo: construindo julgamento

O pós-treinamento prescritivo vai um passo além: em vez de produzir medições que uma camada de política separada precisa traduzir em decisões, o modelo é treinado para produzir a própria decisão (como descrito em “Deixe o modelo agir”). Ele “absorve” a camada de política para dentro do modelo, otimizando diretamente o objetivo final da organização (lucro, retenção, NPS, custo de atendimento) sob restrições explícitas.

Viabilizar esse tipo de treinamento exige uma supervisão de natureza diferente. Em vez de rótulos como “churn em 60 dias”, construímos exemplos de treinamento da forma:

Contexto: a trajetória do cliente até o instante t
Ação: o que a empresa fez em t (digamos, oferta / condições / canal / timing / mensagem / “nada”)
Resultado: o que aconteceu após essa ação em um horizonte [t, t + Δ] (margem, perda, churn evitado, reclamações, proxies de NPS etc.)

A partir desses resultados, definimos uma recompensa/utilidade que corresponde ao objetivo de negócio (por exemplo, contribuição esperada = receita − perda − custo de atendimento, com penalidades para violações de política e danos à experiência). O modelo é então treinado para produzir ações que maximizem essa utilidade sujeitas a guardrails (orçamento, exposição, elegibilidade, restrições regulatórias). Na prática, isso pode ser implementado como aprendizado de política offline (offline policy learning): aprender a partir de decisões registradas e de seus resultados subsequentes, com técnicas que corrigem o fato de que as ações históricas foram escolhidas por uma política já existente (para que o modelo não se limite a imitar as regras de ontem).

Assim, enquanto o pós-treinamento preditivo aprende a prever o futuro, o pós-treinamento prescritivo aprende a política que age sobre o futuro. A camada externa de política deixa de ser um sistema separado e passa a ser um componente aprendido do modelo.

Arquitetura e Interface de Dados

Um LDM é projetado para transformar registros corporativos heterogêneos – transações, interações, logs operacionais e texto – em estados latentes unificados que suportam predição e tomada de decisão. O objeto central de modelagem é um fluxo de eventos: para cada entidade (isto é, cliente, conta, domicílio, dispositivo), observamos uma sequência de eventos ordenada no tempo, gerada por múltiplos sistemas de origem.

Ao longo desta seção, assumimos que os dados podem ser representados (ou convertidos) em um formato baseado em eventos. Concretamente, cada evento contém: (i) um ou mais identificadores de entidade (as chaves de junção que definem a “quem” o evento pertence), (ii) um instante do evento (a chave de ordenação que define “quando” ele aconteceu) e (iii) um conjunto de campos tipados (numéricos, categóricos, timestamps, texto livre e até imagens ou outras modalidades). Conjuntos de dados não baseados em eventos (por exemplo, dimensões de mudança lenta ou snapshots) podem ser incorporados projetando-os em atualizações de eventos ou anexando-os como informação lateral de contexto.

Em alto nível, a arquitetura tem cinco blocos funcionais:

1. Codificadores de campo (field encoders), que mapeiam cada campo bruto em vetores em espaços de representação;
2. Camadas de fusão local, que modelam interações entre campos dentro do mesmo evento;
3. Backbone temporal, que modela dependências de longo alcance ao longo da sequência de eventos;
4. Backbone espacial, que captura dependências entre entidades (por exemplo, domicílios, estabelecimentos comerciais, dispositivos, células);
5. Processador de estado latente, que converte o estado resultante da entidade em saídas de tarefa (scores, previsões ou objetos de ação estruturados), ao mesmo tempo em que impõe restrições de governança por meio de objetivos de treinamento e/ou decodificação restrita (constrained decoding).

Camadas de Embedding

Fazer o embedding de dados é o processo de tomar dados em seu tipo original (digamos, um float, um inteiro ou uma string) e representá-los geometricamente como um ponto em uma variedade riemanniana. Essa estrutura riemanniana desempenhará mais tarde um papel no treinamento do modelo, no qual estruturas geométricas como ângulos, distâncias, geodésicas etc. podem ser exploradas para minimizar a função objetivo do treinamento. Tipicamente, a variedade riemanniana é tomada como um espaço vetorial euclidiano n-dimensional com uma base ortonormal arbitrariamente escolhida⁴; por simplicidade, no que segue, vamos nos ater a esse caso. Assim, grosso modo, podemos pensar no embedding de dados como o processo que transforma cada campo de dados do evento de um cliente em um vetor que representa esse campo de dados.

Se deixarmos de lado o problema de escolher uma geometria significativa, fazer o embedding de features categóricas de baixa/média cardinalidade é muito simples: basta associar a cada categoria um vetor inicializado aleatoriamente. Durante o treinamento, o modelo deve determinar — ou aprender — cada um desses valores de tal forma que o papel da categoria correspondente na(s) tarefa(s) desempenhada(s) pelo modelo possa ser significativamente expresso por sua representação. Isso é o que tipicamente se chama de “tabelas de embeddings aprendidas” (learned embedding tables).

O embedding de texto livre é talvez um dos tipos de embedding mais bem explorados, graças ao sucesso dos Large Language Models. A maneira padrão de fazer o embedding de texto é primeiro criar um tokenizador (isto é, um algoritmo que converte trechos de texto em inteiros, de tal forma que o texto se torna uma lista de inteiros de maneira determinística) e, em seguida, associar um vetor (com valores escolhidos aleatoriamente no início do treinamento) a cada um desses inteiros. Em um LLM, essa lista de vetores passa por uma arquitetura de Transformers

na qual uma predição de próximo token será usada para treinar o modelo. Em um LDM, queremos transformar uma determinada entrada textual em um único vetor que represente o texto inteiro. Isso também pode ser alcançado usando um modelo do tipo Transformers, mas com alguma técnica de pooling ao final: podemos, por exemplo, tomar a média de todos os próximos tokens preditos ou, em vez disso, tomar o último token predito.

O embedding de valores escalares contínuos continua sendo substancialmente mais desafiador do que o embedding de tokens e ainda é comparativamente pouco explorado. Em dados corporativos, no entanto, as quantidades escalares não são periféricas — elas definem o estado do sistema: saldos, exposições, preços, limites, volumes, probabilidades, latências. Um modelo que não consegue representar fielmente a estrutura numérica não pode construir uma representação coerente da dinâmica do sistema.

Os Large Language Models ilustram claramente essa limitação. Por operarem sobre tokens discretizados e não serem explicitamente treinados para consistência algorítmica, eles frequentemente têm dificuldade com aritmética exata, extrapolação de escala e sensibilidade a magnitudes. Seus embeddings não impõem invariantes numéricos como preservação de ordem, monotonicidade ou estabilidade sob transformações afins. Na modelagem de linguagem, isso pode ser tolerável; na modelagem corporativa, não é.

Uma codificação numérica robusta deve, portanto, expor a estrutura intrínseca das variáveis contínuas — sinal, ordenação, distância relativa e relações algébricas básicas — enquanto ainda permite que o modelo capture regularidades específicas do conjunto de dados, como distribuições de cauda pesada, escalas características, mudanças de regime, sazonalidade e componentes periódicos multifrequência. Em nossos experimentos, uma codificação híbrida que combina representações no domínio do valor com embeddings espectrais (Fourier features) apresenta desempenho consistentemente bom, proporcionando sensibilidade à magnitude absoluta e, ao mesmo tempo, preservando resolução em múltiplas escalas temporais e de frequência. O mesmo princípio se estende naturalmente às features de timestamp, nas quais a estrutura temporal periódica e hierárquica deve ser explicitada.

Nos LDMs, a representação numérica não é uma escolha auxiliar de design; é um requisito estrutural para a modelagem das transições de estado da empresa.

Camadas de fusão local

“— Trata-se de como as entidades se manifestam umas às outras. Trata-se de relações.”

— Carlo Rovelli

Até este ponto, tratamos um evento como uma coleção de campos independentes. Mas um registro corporativo real só se torna significativo por meio das interações internas ao evento: números condicionam como interpretamos o texto; o contexto categórico muda o que uma métrica “significa”; timestamps definem quais regimes são comparáveis; metadados operacionais alteram a semântica de uma observação.

Formalmente, considere um evento Et de uma entidade no instante t, com campos numéricos {ni}, campos categóricos {cj}, timestamps {tk} e campos não estruturados {sl} (texto, imagens etc.). Após a camada de embedding, obtemos um conjunto de vetores de embedding {Ni}, {Cj}, {Tk}, {Sl}.

Uma camada de fusão local mapeia esse conjunto heterogêneo em uma única representação do evento {Zt} — que chamaremos de token da entidade no instante t — que captura como os campos definem conjuntamente o estado do evento. Este é o primeiro lugar em que o modelo pode expressar afirmações como: “este valor de throughput é alarmante dada esta capacidade de dispositivo, este congestionamento de célula e este contexto de localização” — não como uma regra, mas como uma interação aprendida.

Um exemplo concreto torna a necessidade óbvia. Suponha que um evento seja o registro de um exame de radiologia: a queixa do paciente e o histórico clínico (texto), o protocolo do exame (categórico + numérico), o uso de contraste (categórico), os cortes de imagem (modalidade de visão) e o laudo do radiologista (texto). Interpretar as imagens sem condicionar ao protocolo e ao contexto é fundamentalmente mal-posto: o mesmo padrão de pixels pode significar coisas diferentes dependendo das configurações de aquisição e dos priors clínicos. A camada de fusão é onde o modelo aprende essas dependências condicionais, alinhando as modalidades em um significado coerente no nível do evento.

Em domínios como a modelagem de CTR (e, de forma mais geral, a tomada de decisão tabular de alta dimensionalidade), é comum descrever a modelagem de interações como explícita ou implícita. Camadas de interação explícita (por exemplo, cross layers / cruzamentos polinomiais de features) constroem deliberadamente combinações de campos (geralmente de ordem baixa a média). Elas são baselines fortes porque capturam com eficiência padrões do tipo “se A e B, então…” e frequentemente melhoram a eficiência amostral em dados tabulares esparsos.

Embora os cruzamentos explícitos sejam eficazes, eles escondem uma limitação importante: tipicamente assumem que multiplicar coordenadas em uma base arbitrária é uma noção fiel de “interação”. Mas embeddings não são medições brutas; eles vivem em espaços de representação cuja geometria é aprendida e cujas coordenadas não são semanticamente privilegiadas. Duas consequências decorrem disso:

1. Sensibilidade à base. Um cruzamento polinomial não é invariante a reparametrizações do espaço de embedding. A mesma configuração semântica pode parecer diferente sob uma rotação/escala equivalente das coordenadas e, ainda assim, a camada de cruzamento responderá de forma diferente.
2. Incompatibilidade de modalidades. Os campos de um evento vêm de codificadores fundamentalmente diferentes (numérico, categórico, texto, imagem). Combiná-los ingenuamente por meio de álgebra coordenada a coordenada pode dar peso excessivo ao codificador que produzir ativações de maior variância, a menos que o mecanismo de fusão aprenda um alinhamento ciente da métrica.

Por essa razão, um bloco robusto de fusão local deve ser entendido como o aprendizado de uma geometria para a interação, e não como o mero empilhamento de produtos algébricos de features. Em nossa configuração, espaços quaterniônicos e girovetoriais (gyrovector spaces) são usados para que o operador de fusão trate as representações como vivendo em um espaço latente no qual a combinação significativa corresponde a uma “reorientação estruturada”: os sinais são transformados de uma maneira que separa “quão forte” um componente é de “para qual direção” ele aponta. Dessa forma, as interações emergem como rotações aprendidas (isometrias) e reescalonamentos controlados que alinham fatores compatíveis e descorrelacionam os conflitantes.

Intuitivamente, em vez de pedir ao modelo que descubra estrutura por meio de multiplicações coordenada a coordenada em uma base arbitrária, deixamos que ele aprenda como a informação do evento deve ser rigidamente movida pelo espaço de representação, de modo que ângulos relativos, relações do tipo fase e misturas que preservam a norma se tornem as primitivas da fusão, antes da projeção de volta para a dimensão de trabalho do modelo. Isso torna o mecanismo de interação muito menos dependente da escolha acidental de coordenadas e mais fiel à ideia de que o que importa na fusão é alinhamento, orientação e estrutura invariante: uma geometria aprendida para a interação.

Backbones

O backbone temporal é o componente que transforma um fluxo de eventos fundidos, ordenado no tempo, em uma trajetória contextualizada e em um estado latente atual para cada entidade. Seu trabalho não é meramente “lembrar” o que aconteceu, mas aprender como as interações passadas condicionam o significado do presente.

O backbone temporal consome uma sequência de tokens de eventos {Z1, Z2, …, Zn}, em que cada token já representa um evento com suas interações intra-evento resolvidas (via camadas de fusão). Ele produz um vetor de estado atual que representa tudo o que o modelo “sabe” sobre a entidade no instante t. Essa representação deve suportar predição sob causalidade: no instante t, o estado latente deve depender apenas de eventos que aconteceram em instantes anteriores.

Muitas dinâmicas corporativas não são puramente temporais: elas também são relacionais. Clientes compartilham domicílios, dispositivos, estabelecimentos comerciais, empregadores, localização etc. O backbone espacial captura essa estrutura modelando como a trajetória de uma entidade é moldada por sua vizinhança em um sistema mais amplo.

Embora seja tentador definir uma vizinhança de forma puramente topológica, criando manualmente regras sobre quais entidades são “relacionadas” (mesmo segmento, mesma região, perfil semelhante), isso rapidamente reintroduz exatamente o viés que estamos tentando evitar: codificamos de forma rígida o que a similaridade deve significar. Uma abordagem mais robusta é tratar a seleção de vizinhança como um problema geométrico aprendido. O estado de cada entidade no instante t vive no espaço latente do modelo; a proximidade nesse espaço define uma noção de “contexto de pares” que pode mudar ao longo do tempo, conforme o comportamento muda. Na prática, o backbone espacial opera como um mecanismo limitado de recuperação e atenção (retrieval-and-attend): dado o estado atual, ele recupera um pequeno conjunto de estados próximos e aplica atenção cruzada sobre eles para produzir um estado enriquecido por contexto. Isso faz com que “quem influencia quem” seja uma propriedade emergente do treinamento, e não uma decisão externa de design, ao mesmo tempo em que permite impor restrições operacionais, como consistência temporal e orçamentos de computação. A saída é um único estado latente fundido, que carrega tanto a história pessoal (backbone temporal) quanto a posição no sistema (backbone espacial), e esse estado se torna a interface pela qual o modelo produz previsões ou decisões a jusante.

Em resumo, o backbone temporal aprende o que aconteceu e o que isso significa agora; o backbone espacial aprende quem é relevante agora. Ambos são aprendidos, não prescritos.

Processador de Espaço Latente

O processador de estado latente é o estágio de “leitura e controle”: ele toma o estado latente produzido pelos backbones e o converte em saídas operacionais, que são medições (previsões) ou ações estruturadas (intervenções). É aqui que a arquitetura se volta para o negócio: o processador define o que o modelo pode dizer e, crucialmente, quão diretamente ele pode agir.

No instante t, o processador recebe o estado atual da entidade e, opcionalmente, um conjunto de contexto relacional vindo do backbone espacial. Ele também pode receber contexto de objetivo (metas de campanha, restrições de produto, tetos de orçamento, regime regulatório), de modo que as saídas sejam condicionadas ao modo de operação, em vez de codificadas de forma rígida.

Para o pós-treinamento preditivo, o processador mapeia o estado latente em saídas como probabilidades/riscos em múltiplos horizontes, previsões (contagens, valores, uso), rankings (próximo melhor produto, provável tópico de reclamação) e embeddings para recuperação/segmentação. Uma propriedade-chave de um bom processador é a consistência multitarefa: um único estado latente deve suportar muitas saídas sem exigir um modelo separado por target. Isso geralmente é implementado como um tronco compartilhado (os backbones) com múltiplos heads de tarefa leves (heads de classificação/regressão/ranking) que podem ser estendidas à medida que novos targets são adicionados.

Para o uso prescritivo, o processador produz um objeto de ação em vez de scores escalares. O objeto é estruturado (campos tipados, escolhas discretas, parâmetros numéricos) e projetado para ser diretamente consumível por sistemas a jusante, inclusive um Large Language Model (LLM). As saídas devem otimizar a utilidade da organização (margem, retenção, custo de atendimento, experiência), e não um proxy como a probabilidade de inadimplência isoladamente. Além disso, o processador deve impor guardrails no momento da geração. Na prática, isso pode ser feito por decodificação restrita (constrained decoding), na qual somente ações válidas podem ser produzidas, por termos de penalidade no treinamento e por um módulo de viabilidade que projeta as ações sugeridas sobre o conjunto de políticas permitidas.

Orquestrando Decisões com Interfaces de LLM

Embora um LDM produza decisões estruturadas, essas decisões ainda precisam ser comunicadas e executadas por meio das interfaces pelas quais as empresas interagem com seus clientes. Na prática, essa camada de interface é cada vez mais mediada por Large Language Models (LLMs). Nessa arquitetura, o LDM atua como o motor de decisão do sistema, gerando objetos de ação estruturados que codificam o que deve ser feito para um cliente específico sob os objetivos econômicos e as restrições de política da organização. O LLM, por sua vez, atua como a camada de interação que traduz essas decisões em comunicação contextualizada e orquestra sua entrega pelos canais voltados ao cliente, como aplicativos, plataformas de mensagens, ferramentas de call center ou agentes digitais.

Nessa divisão de papéis, o LDM é responsável por raciocinar sobre o estado operacional da empresa e produzir a intervenção ótima, enquanto o LLM funciona como o veículo que operacionaliza a ação. O LLM interpreta o objeto de ação estruturado, incluindo produtos recomendados, precificação, timing e restrições de mensagem, e gera a comunicação legível por humanos ou a execução de workflow apropriada. Como a decisão em si se origina no LDM, o LLM não determina qual ação deve ser tomada; ele simplesmente garante que a decisão chegue ao cliente de forma coerente, personalizada e adequada ao canal. Essa separação preserva a governança e a auditabilidade, ao mesmo tempo em que viabiliza a flexibilidade das interfaces conversacionais.

Na prática, essa arquitetura se assemelha à separação entre um sistema de controle e uma camada de comunicação: o LDM governa a política de ação, enquanto o LLM governa como essa política é expressa e entregue. O resultado é um sistema unificado no qual inteligência preditiva, otimização de decisões e interação com o cliente operam como camadas coordenadas, e não como subsistemas independentes.

---

Footnotes

1. Curiosamente, o xadrez humano não se baseia, na verdade, em enormes capacidades de lookahead; obviamente, alguma capacidade de antevisão está envolvida, mas os enxadristas de elite não são tanto calculadores de força bruta quanto reconhecedores rápidos. O campeão mundial Vladimir Kramnik diz que, para além do jogo “de livro”, no nível de grande mestre, “às vezes você não precisa pensar tanto” – o lance pode chegar quase automaticamente. A pesquisa cognitiva clássica corrobora esse testemunho: os estudos de protocolo de de Groot não encontraram grandes diferenças nas estatísticas de profundidade de busca, e Chase & Simon resumem que os mestres frequentemente consideram “aproximadamente o mesmo número de possibilidades – talvez, até menos” do que jogadores mais fracos, mas são dramaticamente melhores em gerar os lances candidatos certos para analisar. No entanto, sendo incapazes de ensinar diretamente essas representações internas no nível do tabuleiro (os motivos tácitos e as impressões posicionais que os mestres adquirem ao longo de anos), temos que aproximá-las. E isso leva a funções de avaliação construídas à mão, como pesos de material, termos de segurança do rei, penalidades de estrutura de peões, bônus de mobilidade e incontáveis outras heurísticas projetadas por humanos. Assim, os motores clássicos tentam compensar limitações representacionais com computação de força bruta. ↩

2. Modelos de Click-Through Rate (taxa de cliques), projetados para prever a probabilidade de um usuário clicar em um determinado link. ↩

3. Net Promoter Score, uma pontuação de lealdade do cliente que é um indicador-chave de satisfação do cliente e defesa da marca. ↩

4. Embora, dependendo da estrutura dos dados, seja mais adequado usar um produto de espaços de curvatura negativa (como o espaço hiperbólico), espaços de curvatura positiva (como os espaços projetivos) e espaços lorentzianos (como os espaços de de Sitter e anti-de Sitter). ↩