OS FATOS

Esta semana, a SAP celebra o TechEd, sua conferência anual de tecnologia.

Um dos anúncios foi a estreia da divisão de pesquisa da SAP no mundo da IA, com a publicação de um novo artigo na conferência NeurIPS chamado “ConTextTab”. O código está disponível em um repositório chamado sap-rpt-1-oss.

O CTO da SAP, Phillipp Herzig, anunciou a novidade em uma postagem no blog que vale a pena conferir. O objetivo da SAP é criar uma IA “com reconhecimento semântico” capaz de entender e fazer previsões a partir de dados tabulares. Justo.

O CENÁRIO

O principal desafio da IA ​​com dados tabulares é que os modelos atuais, que chamamos de Modelos de Linguagem Linguística (LLMs), foram criados a partir da inovação de 2017 do Google e seu “Mecanismo de Atenção”, ou seja, a construção de Redes Neurais baseadas nas relações entre as entidades. Isso funciona bem com dados linguísticos, como expressões idiomáticas ou linguagens de programação.

Nada disso se aplica a dados tabulares. Dados tabulares ainda são um domínio mais clássico de aprendizado de máquina, mas alguns avanços estão surgindo nessa área, e a SAP também está nessa onda. Essencialmente, com dados tabulares, você precisa decidir se vai se concentrar em:

1. Estrutura eficiente: Modelos como TabPFN ou TabICL são “nativos de tabelas”. Eles são construídos para processar com eficiência as linhas e colunas de uma tabela, mas geralmente são treinados com dados sintéticos. Eles veem números e padrões, mas não têm ideia do que esses números significam.

• Significado semântico: Modelos baseados em Grandes Modelos de Linguagem (LLMs) entendem a linguagem. Eles sabem que uma coluna chamada “Preço ($)” se refere a dinheiro ou que “Laptop” é um tipo de computador. Mas são ineficientes e têm dificuldade em analisar mais do que algumas dezenas de linhas por vez.

Então, a SAP surge e diz: vamos construir o ConTextTab e unificar os dois mundos, um modelo nativo de tabelas (portanto, eficiente), mas projetado especificamente para ser “compreensivo à semântica”. Ele usa incorporações especiais para entender o significado dos cabeçalhos das colunas e dos valores de texto nas células.

My TEST Results

SAP-RPT-1 Model Validation Report: API Endpoint: https://rpt.cloud.sap/api/predict

The model demonstrates significant limitations in pattern recognition, semantic understanding, and handling of edge cases.

Semantic Confusion — Confuses data types and feature relevance

Contradictory Data Handling — Poor behavior with conflicting information

Business Logic Limitations — Cannot handle complex SAP business rules

Test Results Overview

1. Problemas Fundamentais de Reconhecimento de Padrões

O modelo falha na correspondência básica de padrões tabulares

Não consegue aprender mapeamentos determinísticos de forma confiável

2. Deficiências na Compreensão Semântica

Não consegue distinguir tipos de dados (códigos vs. IDs)

Não compreende a relevância das características

Trata todas as colunas como igualmente importantes

3. Complexidade de Aprendizagem Limitada

Não consegue lidar com interações entre múltiplas características

Utiliza padrões simples e lineares por padrão

Insuficiente para a complexa lógica de negócios da SAP

Outros testes foram bem-sucedidos; foco apenas nas falhas, principalmente relacionadas à arquitetura do modelo.

MINHA OPINIÃO

Antes de abordarmos o novo modelo da SAP, precisamos entender por que os dados tabulares (pense em tabelas de banco de dados 2D) representam um desafio tão singular para a IA. Onde já tentamos isso e falhamos no passado.

Os dados tabulares são estruturados. Seu significado deriva da relação rígida entre linhas e colunas, mas frequentemente carecem da “estrutura inerente” da linguagem natural. Ter um “5” na linha da coluna “Product_Rating” significa algo completamente diferente do mesmo “5” na coluna “Quantity”, e os modelos de IA historicamente têm dificuldades com esse contexto. Sem mencionar que a linha abaixo pode ser idêntica, mas com um dígito diferente, o que torna a chave única diferente.

Sem mencionar que as tabelas são atualizadas e os dados também, enquanto os Modelos de Aprendizagem Baseados em Lógica (LLMs) foram treinados com livros, textos ou imagens estáticas.

Dito isso, se você quiser resolver esse problema, pode categorizar os modelos tabulares, também chamados de Modelos de Aprendizagem Baseados em Lógica (LTMs), em dois blocos;

1. Árvores de Decisão com Gradiente Impulsionado

Esses não são modelos de aprendizado profundo, mas as Árvores de Decisão com Gradiente Impulsionado, como os modelos XGBoost ou CatBoost, são modelos tradicionais de aprendizado de máquina. Por tradicional, quero dizer que exigem treinamento separado para cada conjunto de dados.

Você precisa de dados altamente selecionados, muita capacidade computacional e uma excelente equipe de engenheiros de aprendizado de máquina para que funcionem.

2. Usar Modelos de Aprendizado de Máquina Llama (LLMs)

A outra categoria é usar um LLM de propósito geral, como o Llama, que é Open Weights, e simplesmente alimentar as tabelas. Os resultados são ruins porque:

Janelas de Contexto Limitadas: Os LLMs têm um limite rígido de quanto texto podem ler de uma vez (a “janela de contexto”). Isso significa que eles podem analisar apenas 32 ou 64 linhas dos seus dados, o que é inútil para uma tabela com milhares de entradas.

A Arquitetura Inadequada: Os LLMs são projetados para texto sequencial, não para a estrutura 2D de uma tabela. Eles não são eficazes no processamento de valores numéricos.

O que a pesquisa está tentando agora: Modelos de base “nativos de tabela”

Devido às limitações dos GBDTs (ausência de pré-treinamento) e LLMs (arquitetura inadequada), a pesquisa tem se voltado para os “modelos de base nativos de tabela”.

Esses modelos são projetados para aprender com diversas tabelas e, em seguida, aplicar esse conhecimento a novas tabelas não vistas, usando aprendizado contextual (ICL). Essencialmente, é o seguinte:

O que a Snowflake e a Databricks tentaram (e que poucos se importam).

Isso foi tentado e explicado nesta postagem do blog.

É aqui que entram os novos modelos, incluindo o da SAP, com o ConTextTab.

Repito: o problema com os modelos sintéticos é que eles ignoram o significado rico dos nossos dados.

O ConTextTab da SAP busca solucionar esse problema; é um modelo “nativo de tabela”, como o TabICL (portanto, eficiente), mas adiciona um novo ingrediente crucial:

1. compreensão semântica. Em vez de dados sintéticos, ele é treinado em um grande conjunto de dados (público). ÓTIMO!

• Ele usa codificadores especializados para entender diferentes tipos de dados, incluindo texto, datas e números. FANTÁSTICO!

• ALÉM DISSO, ele lê os nomes das colunas para entender o contexto, EXCELENTE!

Esta é a nova fronteira: criar modelos que sejam tão eficientes quanto os GBDTs e tão “inteligentes” em relação à linguagem quanto os LLMs, tudo isso construído especificamente para a estrutura de uma tabela. Acho que isso pode funcionar!

MAS

É aqui que entro com a crítica, especialmente porque tentamos e falhamos aqui, e já faz um ano desde que soubemos que a SAP estava seguindo nessa direção, removendo a narrativa de marketing.

1. Não foi treinado com dados da SAP: O artigo deixa bem claro que o ConTextTab foi pré-treinado no conjunto de dados T4. Este é um grande conjunto de dados público de tabelas coletadas da internet, não um conjunto de dados específico da SAP. Isso é ruim, porque a primeira coisa em que falhamos quando queríamos fazer algo real foi descobrir que os conjuntos de dados da SAP não existem, e eu me perguntava: “Espero que a SAP, em algum momento, crie um modelo de IA e publique os conjuntos de dados nos quais ele foi treinado”, o que inclui o S/4HANA ou mesmo o ECC. Bem, presumo que não hoje.

• Foi avaliado em outros benchmarks públicos, como CARTE e OpenML. Não há indicação de que quaisquer dados corporativos valiosos da SAP tenham sido usados ​​para a avaliação.

• Não foi treinado em um supercomputador, a amostra é pequena! Quando a Databricks e a Snowflake anunciaram seus modelos e a Meta já estava investindo bilhões, a DBX e a SNOW anunciaram: “Não nos custou uma fortuna, apenas uma dúzia de milhões de dólares”. A SAP é muito mais barata que isso. Os autores afirmam que o modelo “base” foi treinado em uma “única GPU H100 entre 4 e 12 dias” (ou seja, aproximadamente US$ 1.000), uma escala mais condizente com um projeto universitário. Pessoalmente, gasto quase US$ 1.000 por mês com o SageMaker, e infelizmente não faço muita coisa.

• Não é escalável. Não apenas porque somos limitados pela Janela de Contexto, 2.073 linhas × 50 colunas, mas qualquer tentativa empresarial de pré-treinar um modelo com tabelas reais e uma janela de contexto extremamente grande que não existe hoje, estará sujeita às leis da escalabilidade.

• A contribuição da SAP para a pesquisa é razoavelmente pequena — eles estão essencialmente ajustando arquiteturas existentes em dados públicos com recursos computacionais mínimos. Para uma empresa do porte da SAP e com seu vasto acervo de dados corporativos, isso é surpreendentemente decepcionante.

Um pouco de ESPERANÇA

O que Phillipp Herzig não mencionou em sua postagem no blog é que a SAP está explorando outro domínio, chamado RELATE (Relational Encoder for Latent Aggregation of Typed Entities), que se concentra em redes neurais gráficas em bancos de dados relacionais, e não em dados tabulares tradicionais.

Em outras palavras, trata-se de um problema completamente diferente daquele abordado pelo ConTextTab.

O ConTextTab trabalha com tabelas individuais (dados tabulares tradicionais) usando classificação e regressão em linhas.

O RELATE trabalha com bancos de dados relacionais com múltiplas tabelas convertidas em grafos. Grafos são MUITO mais valiosos para chatbots de IA do que tabelas. Isso é mais útil e uma tecnologia comprovada.

O RELATE também não é exatamente inovador em sua melhor versão; ele usa atenção cruzada no estilo Perceiver para criar embeddings de nós para GNNs, uma tecnologia que existe há muitos anos, MAS é extremamente útil se você controla o domínio dos dados, o que a SAP faz, e isso faz toda a diferença, porque a codificação agnóstica ao esquema funciona em diferentes esquemas de banco de dados. Aqui, a SAP agrega valor; nas linhas da tabela, a SAP NÃO agrega valor.

Pense no RELATE como um especialista em estruturas relacionais complexas com múltiplas tabelas, capaz de lidar com desafios empresariais mais realistas (já que bancos de dados com múltiplas tabelas são essenciais para os sistemas SAP).

Ainda assim, gostaria de ver no RELATE se eles usam dados da SAP para construir sua GNN.

Minha lista de tarefas para a SAP

Espero que alguém na SAP me leia. Aqui estão algumas sugestões e melhorias técnicas que eu espero da pesquisa em IA da SAP para a próxima geração de modelos:

1. Pré-treinamento específico do domínio

Projetar tarefas de pré-treinamento que espelhem os fluxos de trabalho reais do ERP — como prever fechamentos de períodos financeiros, detectar lançamentos contábeis anômalos, etc. Essas tarefas devem codificar restrições de lógica de negócios (por exemplo, regras de contabilidade de partidas dobradas, dependências de cadastro de materiais).

1. Camadas de integração de regras de negócios

Crie arquiteturas neurais com módulos explícitos para incorporar restrições de negócios rígidas — como regras de conversão de moeda, cálculos de impostos ou regulamentações específicas do setor — como componentes diferenciáveis.

2. Arquiteturas escaláveis ​​para múltiplos clientes

Desenvolva modelos que possam lidar com cenários de múltiplos clientes de forma eficiente — compartilhando representações aprendidas entre clientes, mantendo o isolamento de dados estrito. Isso inclui técnicas como adaptações de aprendizado federado ou ajuste fino eficiente de parâmetros por cliente.

O artigo do ConTextTab admite que seu modelo (e outros semelhantes) “não conseguem escalar seu desempenho para conjuntos de dados muito grandes”. Isso é inviável para uso corporativo. Devemos esperar que a SAP desenvolva arquiteturas que resolvam esse problema. Outros mecanismos de “atenção coluna-linha”, como o TabICL, já lidam com até 500.000 amostras.

3. Modelos de processos de negócios

Crie arquiteturas que compreendam sequências de processos de negócios.

Pedidos -> Entregas -> Faturas -> Pagamentos

Isso significa modelar dependências temporais de longo prazo ao longo de meses/anos, e não apenas características de registro de data e hora.

4. Aprendizado de Representação entre Módulos

Construa modelos que aprendam representações unificadas entre os módulos SAP (FI/CO, MM, SD, RH). Uma compra em MM deve informar as previsões em FI. Isso requer o tratamento simultâneo de esquemas heterogêneos e objetos de negócios.

Os dados corporativos quase nunca são uma única tabela simples. Trata-se de um banco de dados relacional complexo, com várias tabelas. O próprio artigo RELATE da SAP apresenta um codificador para “grafos relacionais multimodais”. Devemos esperar que qualquer modelo de ponta integre isso, passando da previsão de tabela única para o aprendizado baseado em grafos com várias tabelas.

4.1 Camadas de Integração de Regras de Negócio

Crie arquiteturas neurais com módulos explícitos para incorporar restrições de negócios rígidas — como regras de conversão de moeda, cálculos de impostos ou regulamentações específicas do setor — como componentes diferenciáveis.

4.2 Intermodalidade

Os modelos da SAP afirmam ser “multimodais”, mas isso se limita a texto, números, datas e categorias. A verdadeira multimodalidade empresarial envolve muito mais. Devemos esperar ver codificadores para imagens de processos, faturas em PDF digitalizadas e talvez até mesmo dados de séries temporais de sensores de IoT, todos integrados em um único modelo “relacional”.

5. Inferência de Streaming

Projete modelos otimizados para inferência em tempo real em fluxos transacionais — lidando com milhões de itens de linha por segundo com requisitos de latência abaixo de um milissegundo, típicos em sistemas de produção SAP.

5.1 Treinamento com Consciência de Captura de Dados de Alteração (CDC)

Implemente procedimentos de treinamento que funcionem com fluxos de CDC da SAP, compreendendo a diferença entre inserções, atualizações e exclusões, e aprendendo com a evolução dos registros ao longo do tempo.

6. Modelagem Hierárquica de Organizações

Desenvolver ou lançar arquiteturas de grafos que representem naturalmente hierarquias organizacionais

códigos de empresas -> fábricas -> locais de armazenamento

e seu impacto nos padrões de dados, incluindo o tratamento adequado da lógica de consolidação.

7. E muito importante. Nada de ICL, vamos fazer algo diferente.

Nada contra o Aprendizado In-Context (ICL), mas não podemos projetar um modelo empresarial com base nesse recurso. Essa sempre será sua limitação enquanto trabalharmos com a tecnologia existente. Não faz sentido prosseguir até que os Transformers atuais evoluam ou usemos uma arquitetura diferente.

Há alguns meses, outra arquitetura gerou muita expectativa, chamada Mamba.

A Mamba surgiu para resolver um problema dos Transformers: para descobrir qual deve ser a próxima palavra, o modelo precisa analisar e calcular uma pontuação para cada palavra anterior.

Para um prompt de 1000 palavras, são realizados aproximadamente 1000 x 1000 cálculos. Para um prompt de 100.000 palavras, isso se torna 100.000 x 100.000 — um enorme gargalo computacional. É por isso que as janelas de contexto (a quantidade de texto que um modelo consegue “lembrar”) foram uma grande limitação por muito tempo; essa é a limitação.

O Mamba funciona mais como uma Rede Neural Recorrente (RNN). Ele processa a sequência um token por vez, comprimindo todas as informações relevantes do passado em um “estado” compacto. O principal avanço é seu mecanismo seletivo: ele aprendeu quais informações manter em seu estado e quais descartar, com base na entrada atual. Nessa arquitetura, o pré-treinamento contínuo é uma possibilidade real.

Não estou dizendo qual arquitetura salvará o dia para a SAP, mas para nós, a comunidade, não há muito que possamos fazer com o sap-rpt-1, por enquanto. Esse modelo terá um lugar na minha memória próximo aos do Snowflake ou do Databricks.