Esta semana, nossa equipe participou do SAP TechEd em Berlim, onde a SAP apresentou seu mais recente modelo fundamental, o SAP-RPT-1 (pronuncia-se “Rapid-1”). Mais informações sobre este anúncio podem ser encontradas em “Um Novo Paradigma para IA Empresarial: Aprendizado Contextual para Dados Relacionais”, bem como no artigo oficial publicado na conferência NeurIPS deste ano, “ConTextTab: Um Aprendizado Tabular Contextual com Consciência Semântica”. O modelo está disponível para exploração no SAP-RPT-1 Playground.

Começaremos com um breve contexto: IA “estreita” é o termo usado pela SAP para modelos de Machine Learning (ML) treinados com dados específicos do cliente para realizar uma tarefa específica (“prever minhas vendas para o próximo trimestre com base na evolução histórica”), em contraste com os modelos fundamentais, que oferecem aprendizado por transferência pronto para uso e, portanto, são aplicáveis ​​a uma ampla gama de tarefas. Assim, a introdução do RPT-1 se encaixa perfeitamente na visão da SAP de introduzir soluções de baixo código para permitir que usuários de negócios ou não especialistas em ciência de dados se familiarizem rapidamente com soluções de negócios baseadas em IA que vão além das capacidades de modelos de aprendizado de máquina de baixo código.

A mensagem estratégica é clara: modelos de IA personalizados ou específicos não são mais necessários, pois os modelos básicos podem desempenhar a função tão bem ou melhor. Mas será que isso é realmente verdade?

Neste post do blog, tentaremos fornecer um contexto importante sobre esse anúncio, com base em nossa vasta experiência com SAP e IA. Na próxima seção, abordaremos três questões-chave:

Quais são as implicações estratégicas para os clientes SAP e cientistas de dados?

Quais são algumas das principais deficiências dessa abordagem que as empresas e os cientistas de dados precisam conhecer?

O que o SAP-RPT-1 significa para mim como cientista de dados e quando devo (ou não) usá-lo?

Modelos Básicos para Dados Textuais vs. Dados Relacionais/Tabulares

Vamos começar com alguns conceitos básicos. Assim como os Modelos de Linguagem de Grande Porte (LLMs) são “modelos de base” pré-treinados para gerar texto com base em blocos de texto anteriores (“prompts”) em terabytes de dados textuais, o RPT-1 é um “modelo de base” pré-treinado em milhões de conjuntos de dados relacionais diferentes para gerar valores para uma ou mais células, dadas as células circundantes.

A ideia não é nova, visto que bibliotecas como o TabPFN têm atraído cada vez mais atenção no último ano, apresentando resultados promissores. De fato, o RPT-1 parece ser uma versão aprimorada da arquitetura TabPFN, especialmente expandida com recursos que permitem (a) compreender nomes de colunas e (b) aprender com valores de texto dentro das células do conjunto de dados. Coincidentemente, o TabPFN anunciou ontem a versão 2.5, alegando ser o estado da arte (SOTA) em alguns benchmarks também – infelizmente, o relatório técnico não permite uma comparação direta entre os dois.

Uma breve comparação entre IA restrita, IA generativa (LLMs) e modelos de fundação tabular.

A vantagem inerente disso é clara: da mesma forma que um LLM aprende regras básicas da linguagem natural e conhecimento comum a partir de suas vastas quantidades de dados (textuais) durante o treinamento, o RPT-1 aprende conceitos importantes de dados tabulares: dependências entre diferentes colunas e valores de células, a importância dos nomes das colunas e, mais importante, provavelmente também já entendeu o que é um pedido de venda ou de serviço, e que o preço geralmente depende da quantidade e dos tipos de itens. A ideia é simples: podemos mascarar qualquer célula em uma tabela e fazer com que o RPT-1 preveja seu valor, exigindo apenas algumas linhas de exemplo como contexto.

Dessa forma, o RPT-1 pode ser entendido de maneira semelhante a uma abordagem de instrução “com poucos exemplos” para LLM. Se você pedir a um LLM para atribuir tarefas aos destinatários corretos com base em seus conteúdos textuais, você incluiria alguns exemplos do mundo real e seus destinatários desejados como exemplos com poucos exemplos. Isso “ensinaria” ao LLM quais pessoas existem e qual pessoa é responsável por quê – tudo dentro de um único exemplo, sem exigir nenhuma etapa de treinamento.

Para o RPT-1, as poucas linhas de “contexto” que você fornece assumem o papel dos exemplos acima, dando ao RPT-1 uma ideia de como seus dados tabulares se parecem e estabelecendo limites para sua tarefa. Em seguida, você pede que ele preveja resultados (por exemplo, o tempo que um cliente levará para pagar sua fatura, a categoria de um ticket, etc.).

A Visão Estratégica do SAP-RPT-1

As vantagens são óbvias. Em um cenário ideal, não precisaríamos mais criar modelos complexos de IA manualmente, gastando semanas iterando diferentes abordagens, executando varreduras de hiperparâmetros e assim por diante. Isso significaria também que não precisaríamos mais de cientistas de dados trabalhando em Python para empacotar seus modelos em APIs REST, apenas para que possam ser consumidos por nossos aplicativos de negócios executados no CAP no Cloud Foundry. Em vez disso, os “novos” cientistas de dados se concentrariam em entender a demanda das partes interessadas, preparar conjuntos de dados e recursos-chave e, em seguida, implementar o pipeline de previsão no CAP, simplesmente acessando o modelo RPT-1 disponível por meio do SAP Generative AI Hub.

Além disso, isso possibilitaria cenários de previsão sem uma grande quantidade de dados de treinamento – algo que antes era impossível, pois a rotulagem manual de dados é demorada e cara.

No entanto, um fator crucial permanece: os cenários de IA precisarão de uma justificativa de negócios, o que exige compreender a confiabilidade das previsões de IA, o valor que elas criam e os custos associados. Na nossa visão, ainda precisamos de Cientistas de Dados que consigam traduzir requisitos de negócios e conhecimento do domínio em entradas para modelos fundamentais e, mais importante, avaliar/testar o desempenho desses modelos para um determinado caso de uso, traduzindo-os em KPIs que as partes interessadas do negócio possam entender. Se as partes interessadas estiverem satisfeitas com a precisão medida, não precisamos mais gastar meses desenvolvendo manualmente um modelo de IA específico. Mas, se por algum motivo o modelo não funcionar bem, precisamos conhecer suas limitações antes de implementá-lo em produção. Da mesma forma que as soluções de IA generativa para texto exigem uma estratégia de avaliação para medir sua eficácia, o RPT-1 requer um conjunto de dados de exemplo para garantir que atenda às demandas do negócio.

Quais são as limitações e peculiaridades dos modelos de base tabular?

No entanto, é importante entender que isso também traz consigo algumas das falhas inerentes a outros modelos de base (como os LLMs). É importante notar que algumas dessas “falhas” não são um problema específico do RPT-1, mas sim resultado do paradigma de aprendizado contextual que também afetou modelos relacionados, como o TabPFN.

Em primeiro lugar, a falta de explicabilidade. Com a Lei de IA da UE impondo regras rígidas para áreas de alto risco – como classificações de crédito em um contexto financeiro ou bancário – até mesmo modelos tradicionais de IA restritos (Gradient Boosting) eram frequentemente chamados de “caixa preta” ou “impossíveis de explicar”. Sim, seria possível usar pacotes como o SHAP para calcular os impactos de recursos locais, mas estes forneceriam apenas uma aproximação. Com modelos de base relacionais como o RPT-1, isso se torna ainda mais inviável: não temos como entender como uma previsão específica é gerada. Isso provavelmente inviabilizará qualquer aplicação em áreas onde IA explicável, resultados probabilísticos calibrados ou modelagem bayesiana são atualmente utilizados. Felizmente, a SAP já incluiu esses itens em seu planejamento estratégico, e estamos curiosos para saber como etapas de pós-processamento e outras podem ser usadas para solucionar essas preocupações.

Em segundo lugar, a falta de reprodutibilidade e a sensibilidade à ordem dos dados. Sim, o RPT-1 fornecerá as mesmas saídas duas vezes se o contexto e a tarefa forem exatamente os mesmos. No entanto, devido ao seu design baseado em atenção espacial, alterar a ordem das colunas geralmente — mantendo-se tudo o mais constante — altera a previsão! O mesmo se aplica às linhas: de repente, faz diferença se eu classificar meus dados de contexto por data ou pelo ID do usuário associado. Como efeito colateral disso, ter duas amostras com todos os recursos equivalentes não garante mais que suas previsões serão as mesmas. Veja um exemplo abaixo.

Previsão com amostras em ordem cronológica

Previsão ligeiramente alterada após pequena reorganização das mesmas linhas.

What’s even more important to note – The column names have a huge impact on the forecasted values, as their name and description is a direct input to RPT-1. While this allows transfer learning and capturing concepts about what a “price” column means, it also requires Data Scientists to accurately name their columns, ideally similar to the description used by SAP systems. In that sense, Data Scientists will also need to do “prompt engineering” on column names to find what delivers best results. In our experiences, it was not possible to inject domain knowledge (“less scooters will be rented at night”) into the forecast (yet). Maybe in the future we will get some type of system prompt for relational transformers in the future?

Grandes mudanças apenas com a mudança dos nomes das colunas.

Mais importante ainda, o RPT-1 incorpora valores em colunas categóricas e textuais. Isso significa que ele deve ser capaz de capturar a “semântica” por trás dos valores das células, melhorando, espera-se, a precisão em tarefas que dependem (em parte) de dados textuais. No entanto, isso significa que os cientistas de dados agora também precisam experimentar com a forma como os valores categóricos são nomeados – mesmo que os valores de ID sejam os mesmos, o mapeamento dos valores categóricos alterará o resultado da previsão. Essa é outra peculiaridade que não se aplica às abordagens tradicionais de IA restrita.

Renomear valores categóricos de IDs para nomes “expressivos” altera a previsão – às vezes para melhor, às vezes para pior.

Mais ainda, uma falha crítica (que também afeta modelos semelhantes ao TabPFN) é a janela de contexto limitada (aproximadamente 2.000 linhas, conforme mencionado no artigo e disponível no ambiente de testes). Em muitos casos, esse número é muito menor do que os dados de treinamento disponíveis, o que torna um desafio inicial decidir quais linhas/amostras do conjunto de dados completo precisam ser usadas como contexto para a tarefa de previsão atual. Isso pode ser especialmente limitante para tarefas de classificação de alta cardinalidade: não é mais possível usar exemplos de cada um dos 15.000 grupos de materiais como contexto, por exemplo.

Além disso, o RPT-1 é um “modelo de tabela única”, o que significa que os cientistas de dados (por enquanto) ainda precisam garantir que essa tabela contenha todos os campos relevantes, incluindo, por exemplo, a junção/agregação de dados de tabelas vinculadas. Dessa forma, a engenharia de recursos em várias tabelas ainda é uma tarefa manual e requer um bom conhecimento do domínio. A SAP reconheceu isso e está pesquisando para incluir dados de tabelas vinculadas automaticamente.

Juntamente com a questão mencionada acima (a ordem das linhas importa), o Cientista de Dados agora precisa derivar uma heurística sobre quais amostras de dados históricos devem ser passadas como contexto para cada amostra a ser prevista! Assim, transferimos a responsabilidade dos Cientistas de Dados da otimização de modelos para a otimização de dados, recursos e gerenciamento de contexto – de forma semelhante à seleção cuidadosa do prompt e do contexto para Modelos de Aprendizagem Baseados em Lógica (LLMs), utilizando abordagens como a Geração Aumentada por Recuperação (RAG). Talvez possamos até mesmo adaptar a mesma abordagem da RAG para dados tabulares e chamá-la de TRAG, abreviação de Geração Aumentada por Recuperação Tabular. As amostras existentes são incorporadas com um modelo de incorporação relacional especializado e, ao prever novas amostras, selecionamos primeiro as 100 amostras conhecidas mais semelhantes e as passamos para o RPT-1 como contexto.

Além disso, as células são “preenchidas” uma a uma, portanto, prever muitos valores ainda levará um tempo considerável, inviabilizando o uso em dispositivos de borda ou tarefas ad hoc que exigem decisões rápidas. Principalmente no ambiente de testes, existe um limite rígido para o número máximo de células previstas, bem como um limite de taxa bastante rigoroso.

De acordo com a SAP (e coincidindo com os resultados da nossa primeira avaliação), o SAP-RPT-1 também suporta atualmente apenas classificação e regressão, não sendo compatível com tarefas de correspondência, recomendação ou regressão de séries temporais. Embora esses recursos estejam no roadmap da SAP, pode levar algum tempo para que sejam totalmente aproveitados em toda a gama de tarefas que os modelos de IA específicos atualmente abrangem com sucesso. Um exemplo curioso: ao ser solicitado a prever um carimbo de data/hora entre duas amostras, o modelo sugeriu o carimbo de data/hora com um ano de antecedência.

Exagero vs. Realidade: Uma visão (ligeiramente) crítica das alegações de desempenho da SAP

A SAP sugeriu que seu modelo relacional fundamental pode reduzir as taxas de erro em até duas vezes, por exemplo, em previsões relacionadas a materiais, mesmo quando comparado a modelos de IA específicos e ajustados, treinados com seus dados de clientes. Infelizmente, o artigo em questão não corrobora essas afirmações diretamente, portanto, consideramos necessário algum contexto.

Em seu artigo, os autores comparam tarefas de classificação e regressão com alguns modelos desenvolvidos manualmente (LGBM, XGBoost, CatBoost e soluções de aprendizado de máquina automatizado, como o AutoGluon) em diversas coleções de conjuntos de dados disponíveis publicamente (Apêndice A.2, Tabela 3). Observe que o artigo se refere ao RPT-1 por seu nome anterior, “ConTextTab”.

Esses conjuntos de dados são:

CARTE “tem a particularidade de ser composto por tabelas com strings de alta cardinalidade”, ou seja, exatamente o tipo de conjunto de dados “semântico” no qual o RPT-1 se destaca.

OML-CC18 “um conjunto de benchmarks de aprendizado de máquina com 72 conjuntos de dados de classificação cuidadosamente selecionados dentre os milhares de conjuntos de dados disponíveis no OpenML”

OML-CTR23, “uma coleção selecionada de 35 problemas de regressão disponíveis no OpenML”

TabReD, “um novo benchmark de conjuntos de dados tabulares de nível industrial com conjuntos de dados do mundo real ricos em recursos e em constante evolução temporal”

TALENT, “uma extensa coleção de conjuntos de dados: equipada com 300 conjuntos de dados, abrangendo uma ampla gama de tipos de tarefas, distribuições de tamanho e domínios de conjuntos de dados”. O sufixo “Tiny” significa focar em um subconjunto contendo 45 conjuntos de dados que são representativos do desempenho geral das linhas de base investigadas nos trabalhos originais.

Nessa comparação, podemos observar que, em todos os conjuntos de dados, o RPT-1 apresenta uma classificação média de 4,7 a 5,42 (dependendo dos hiperparâmetros utilizados). Sua habilidade parece ser mais evidente no benchmark semântico CARTE, onde fica apenas ligeiramente atrás do AutoGluon. Nos demais conjuntos de dados, o RPT-1 geralmente se encontra na faixa intermediária de pontuação. Considerando apenas esses benchmarks, as abordagens tradicionais de IA específica, bem como as soluções modernas de AutoML, mesmo sem pré-treinamento, ainda superam o RPT-1 com frequência. A única questão que permanece é: qual a habilidade, o tempo e o poder computacional necessários para desenvolver um modelo de IA específica que supere a linha de base definida pelo RPT-1?

Nesse contexto, também é importante verificar como essas classificações evoluem em função da quantidade de dados de treinamento específicos da tarefa disponíveis. Felizmente, os autores realizaram essa análise em seu artigo, conforme mostrado abaixo.

Como podemos ver, para um conjunto limitado de dados de treinamento (<5 mil amostras), os modelos contextuais pré-treinados (como RPT-1/ConTextTab, TabPFN) são os principais concorrentes devido ao seu conhecimento “geral” que impacta as previsões. Se os dados de treinamento disponíveis forem limitados, esses modelos quase sempre superarão os modelos de IA específicos criados manualmente. Acima de 5 mil amostras, as soluções de AutoML, como o AutoGluon, ou os algoritmos de aprendizado tabular baseados em redes neurais, como o RealMLP, são os melhores modelos, com os algoritmos de gradient boosting, como o LightGBM, ganhando terreno à medida que mais dados se tornam disponíveis.

Quando devo (ou não) usar o SAP-RPT-1?

Nossa recomendação geral: Sempre avalie o SAP-RPT-1 em relação aos rótulos de verdade conhecidos e aos modelos de linha de base ingênuos. Para uma orientação rápida, aqui estão alguns casos em que recomendamos seu uso – e outros em que não recomendamos.

Use o SAP-RPT-1 se:

os dados de treinamento forem limitados (menos de 3 a 5 mil amostras)

a tarefa se basear em colunas que são comumente disponíveis em sistemas SAP existentes e os dados de treinamento ainda forem um tanto limitados (menos de 10 mil amostras)

a tarefa depender fortemente de recursos semânticos, como valores/descrições de texto, juntamente com dados categóricos

você não se importar com o melhor modelo e atingir 80% do resultado desejado com menos esforço for suficiente para você

Não use o SAP-RPT-1 se:

você estiver tentando realizar previsões de séries temporais, correspondência, recomendações e similares

você tiver dados de treinamento suficientes

a reprodutibilidade e a explicabilidade forem uma preocupação

você precisar executar sem acesso à internet/em dispositivos de borda ou fazer previsões em tempo real em conjuntos de dados maiores

Em geral, estamos extremamente satisfeitos em ver a SAP aproveitar sua experiência e a vasta quantidade de dados de treinamento relacionais disponíveis para fornecer à comunidade uma nova e promissora maneira de pensar sobre IA em dados relacionais. Muitas das deficiências que observamos atualmente (e que, portanto, reduzem os cenários em que o SAP-RPT-1 pode ser usado prontamente hoje) estão em nosso planejamento e estamos ansiosos para ver como elas serão abordadas e integradas em uma solução completa e de uso geral. A longo prazo, isso tem o potencial de permitir que cientistas de dados com menos formação técnica entreguem valor comercial aos stakeholders rapidamente.

Nesse sentido, não, a IA “estreita” não está (ainda?) morta, mas os modelos relacionais fundamentais mudarão significativamente a forma como criamos valor comercial com IA nos próximos dois anos.