Comparação de Foundation Models Relacionais

Comparamos por benchmark SAP-RPT-1-OSS com gradient boosting (LightGBM, CatBoost) em 17 datasets tabulares que abrangem o espectro semântico-numérico, tabelas pequenas/altamente semânticas, datasets empresariais mistos e grandes datasets numéricos de baixa semântica.

Nosso objetivo é medir onde os priores semânticos pré-treinados de um LLM relacional podem oferecer vantagens sobre os modelos de árvore tradicionais e onde eles enfrentam desafios sob escala ou estrutura de baixa semântica.

SAP-RPT-1-OSS vs. Gradient Boosting: Resultados de benchmark

• Taxa de sucesso: Representa a pontuação média normalizada (0.0 a 1.0). Uma barra mais alta indica que o model está consistentemente mais próximo do melhor desempenho possível para os datasets dessa categoria.
• 100 – 500 linhas (3 Datasets):
  • Incluído: wine (178), sonar (208), vote (435).
  • Resultado: O SAP tem melhor desempenho em 2 de 3 datasets. Ele alcança as maiores pontuações em wine e sonar, sugerindo que os priores de LLM podem ser benéficos quando os dados de treinamento são escassos. No entanto, o CatBoost conquistou uma vitória apertada no dataset vote (dentro de 0,1%), indicando que os modelos de árvore permanecem altamente competitivos mesmo em escalas pequenas.
• 501 – 1.000 linhas (3 Datasets):
  • Incluído: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Resultado: O SAP tem melhor desempenho em todos os 3 datasets. Em cylinder_bands, o SAP superou o LightGBM por uma margem de 5,5%, potencialmente devido a um melhor tratamento das descrições semânticas de defeitos industriais, embora estudos adicionais de ablação sejam necessários para confirmar esse mecanismo.
• 1.000 – 10.000 linhas (5 Datasets):
  • Incluído: titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
  • Resultado: O SAP alcança os melhores resultados em 4 de 5 datasets, com desempenho particularmente bom em tarefas com muito texto, como spambase e titanic. No entanto, o CatBoost supera significativamente o SAP em compas por 10,4%, indicando características específicas do dataset que favorecem os modelos de árvore mesmo nessa faixa de tamanho.
• 10.000+ linhas (6 Datasets):
  • Incluído: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Resultado: À medida que o volume de dados cresce, a potencial vantagem de “conhecimento prévio” do LLM diminui. O LightGBM e o CatBoost alcançam os melhores resultados em 5 de 6 datasets, oferecendo melhor precisão a uma fração do custo computacional. A única exceção, california_housing, mostra uma vantagem modesta de 1,7% para o SAP.

1. Tabela de datasets de resultados do benchmark

Abaixo está o detalhamento completo do desempenho do model em todos os 17 datasets.

2. Análise de custo e eficiência

Calculamos o custo computacional direto de cada model com base no preço da instância RunPod H200 de $3,59/hora.

O SAP-RPT-1-OSS incorre em custos significativamente mais altos devido ao tempo necessário para o pré-processamento de text embeddings e à pesada sobrecarga de memória da arquitetura do LLM. Em contraste, o LightGBM e o CatBoost concluem as tarefas quase instantaneamente nesse hardware. Os custos abaixo refletem o tempo total de execução (pré-processamento + treinamento) para uma execução de validação cruzada de 3 dobras.

Custo médio por dataset (17 Dataset Avg)

Detalhamento de custo por tamanho de dataset

• Datasets pequenos (<1K linhas): O SAP é relativamente barato (≈ $0,03 por execução). A alta taxa de vitória aqui torna o custo desprezível.
• Datasets grandes (>20K linhas): O SAP fica caro.
  • Exemplo: Treinar em adult_income (48k linhas) leva cerca de 12 minutos no total para 3 dobras.
  • Custo: 12 min X $0,06/min = $0,72 por experimento.
  • Comparação: O LightGBM conclui a mesma tarefa por $0,01.

Conclusão: Embora $0,22 por dataset não seja caro em termos absolutos, o SAP é 22x mais caro que o baseline. Esse diferencial de custo pode ser justificado para datasets pequenos e ricos em semântica, onde o SAP mostra melhorias de precisão significativas (por exemplo, cylinder_bands com ganho de +5,5%), mas fica mais difícil de justificar para datasets grandes, onde os modelos de árvore alcançam desempenho igual ou melhor a uma fração do custo.

3. Framework de análise: o espectro semântico

Para interpretar esses resultados, é crucial entender como selecionamos os dados. Não escolhemos datasets aleatoriamente; curamos um conjunto de 17 datasets especificamente selecionados para abranger o Espectro Semântico-Numérico.

Nossa hipótese central era que o SAP (baseado em LLM) se destacaria onde os dados têm significado linguístico, enquanto os modelos de árvore dominariam no cálculo numérico bruto. Categorizamos nossos datasets em três clusters distintos:

Cluster A: Datasets de alta semântica (6 datasets)

Características: Os atributos contêm descrições de texto ricas, rótulos categóricos com significado do mundo real (por exemplo, “congelamento de honorários médicos”) ou terminologia específica de domínio.

• Datasets:
  • cylinder_bands: Defeitos de impressão industrial.
  • titanic: Nomes e títulos de passageiros.
  • vote: Registros de votação do Congresso (categórico “Sim/Não” em políticas).
  • breast_cancer: Descrições médicas de tumores.
  • spambase: Frequências de palavras em e-mails.
  • wine: Origens químicas.

Cluster B: Dados empresariais mistos (6 datasets)

Características: O formato tabular padrão encontrado na maioria dos bancos de dados corporativos, uma mistura de valores numéricos (salário, idade) e strings categóricas (cargo, raça, departamento).

• Datasets:
  • employee_salaries: Cargos vs. salário.
  • compas: Histórico criminal e dados demográficos (atributos sensíveis).
  • adult_income: Dados demográficos do censo.
  • credit_g: Perfis de risco de crédito alemães.
  • default_credit: Dados de inadimplência de crédito de Taiwan.
  • car_evaluation: Parâmetros de compra de veículos.

Cluster C: Dados de baixa semântica/puramente numéricos (5 datasets)

Características: Os atributos são medições abstratas, leituras de sensores ou coordenadas físicas. Os nomes das colunas muitas vezes não importam; as relações matemáticas importam.

• Datasets:
  • higgs_100k: Cinemática de partículas físicas.
  • diamonds: Dimensões físicas e preço.
  • sonar: Saltos de energia de frequência.
  • california_housing: Coordenadas de latitude/longitude e estatísticas do censo.
  • house_sales: Imóveis do Condado de King (principalmente atributos numéricos).

4. Análise aprofundada: onde o SAP vence e onde falha

A aplicação do framework de análise aos nossos resultados revela quatro padrões de desempenho distintos. A tabela abaixo resume exatamente onde o SAP se destaca e onde ele falha.

Fundamentos conceituais dos relational foundation models

O principal objetivo de um relational foundation model é fazer previsões precisas e executar tarefas diversas em tabelas estruturadas. Esses models devem entender como as informações são representadas em diferentes tabelas, como as entidades são vinculadas por meio de relações e como as informações temporais influenciam os resultados.

As principais capacidades desses models incluem:

• Generalização de esquema: A capacidade de se adaptar a novos esquemas relacionais sem retreinar do zero.
• Representação de entrada unificada: Lidar com diferentes tipos de colunas, como atributos numéricos, categóricos e textuais.
• Integração de contexto temporal e estrutural: Capturar dependências ao longo do tempo e entre entidades ligadas por chaves primárias e estrangeiras.
• Transferibilidade: Realizar tarefas preditivas em novos datasets por meio de pré-treinamento e zero-shot learning.

Griffin

O Griffin é uma das primeiras tentativas em larga escala de construir um relational foundation model unificado. Ele representa dados relacionais como um grafo temporal e heterogêneo, onde cada linha se torna um nó e as arestas correspondem a relações de chave estrangeira. Os principais recursos incluem:

Codificador de atributos unificado

• Atributos categóricos e de texto são codificados com um codificador de texto pré-treinado, enquanto valores numéricos usam um codificador float aprendido.
• Metadados como nomes de tabelas, nomes de colunas e tipos de arestas são incorporados para ajudar o model a reconhecer o esquema relacional.
• Embeddings de tarefa permitem que um único model execute tarefas de regressão e classificação com decodificadores compartilhados.

Passagem de mensagem e atenção

O Griffin integra redes neurais de passagem de mensagem com um módulo de cross-attention. O componente de passagem de mensagem agrega informações dentro e entre relações, enquanto a cross-attention se concentra nas células relevantes dentro de cada linha. Esse design ajuda o model a lidar com dados diversos e a manter o contexto entre entidades conectadas.

Pré-treinamento e fine-tuning

O model é pré-treinado em datasets de tabela única por meio de uma tarefa de conclusão de célula mascarada e, em seguida, fine-tuned em bancos de dados relacionais para tarefas específicas. Experimentos em benchmarks relacionais grandes mostram que o Griffin supera as baselines GNN tradicionais e os models de tabela única tanto em precisão quanto em eficiência de aprendizado por transferência.

Figura 1: Gráfico mostrando o Griffin Model Framework.¹

Relational transformer

Enquanto o Griffin se concentra na agregação de grafos, o Relational Transformer (RT) aplica arquiteturas transformer diretamente a bancos de dados relacionais. Ele trata cada célula como um token enriquecido com seu valor, nome de coluna e nome de tabela.

Representação de entrada

Cada token combina:

• Um embedding de valor que depende do seu tipo de dado (numérico, texto ou datetime).
• Um embedding de esquema é gerado a partir do texto da tabela e da coluna.
• Um mask token é usado quando o valor fica oculto durante o pré-treinamento.

Essa estrutura permite que o RT processe bancos de dados relacionais com esquemas diferentes, mantendo um formato de entrada consistente.

Atenção relacional

O RT introduz um mecanismo de atenção relacional que opera no nível da célula. Ele inclui:

• Atenção de coluna para aprender distribuições de valor dentro das colunas.
• Atenção de atributo para combinar atributos na mesma linha ou em linhas pai vinculadas.
• Atenção de vizinhança para agregar informações de linhas filhas conectadas.

Together, essas camadas de atenção formam um relational graph transformer que modela dependências entre linhas, colunas e tabelas.

Resultados de treinamento e transferência

O RT é pré-treinado em bancos de dados relacionais do RelBench. Em experimentos, o model pré-treinado alcançou até 94% do desempenho de models totalmente supervisionados em configurações de zero-shot. Ele também aprendeu mais rápido durante o fine-tuning, exigindo menos etapas de treinamento para alcançar alta precisão.²

Essa abordagem sugere que bancos de dados relacionais compartilham padrões transferíveis entre domínios e que a tokenização no nível da célula fornece uma base prática para tarefas preditivas em dados estruturados.

RelBench

O RelBench foi projetado para avançar o relational deep learning, que se concentra no aprendizado de ponta a ponta a partir de dados distribuídos em várias tabelas relacionadas em bancos de dados relacionais.

Como os bancos de dados relacionais continuam sendo o sistema dominante de gerenciamento de dados na indústria e na ciência, o RelBench fornece um framework padronizado e reproduzível para avaliar models que operam diretamente em estruturas relacionais, em vez de depender de flattening manual de atributos.

As versões anteriores do RelBench introduziram 11 bancos de dados relacionais abrangendo domínios como saúde, redes sociais, e-commerce e esportes, com 70 tarefas preditivas projetadas para serem desafiadoras e relevantes ao domínio.³

Em janeiro de 2026, o RelBench v2 foi lançado, adicionando quatro novos bancos de dados (SALT, RateBeer, arXiv e MIMIC-IV) e 40 tarefas preditivas adicionais, incluindo uma nova classe de tarefas de Autocomplete que avaliam a capacidade de um model de prever colunas existentes em um banco de dados relacional.

O lançamento também expandiu o acesso a dados por meio da integração com CTU, permitindo acesso a mais de 70 datasets relacionais via ReDeLEx; adicionou conectividade direta com banco de dados SQL; e incorporou sete datasets do repositório 4DBInfer no formato RelBench.

Além de datasets e tarefas, o RelBench fornece uma implementação de referência de código aberto para relational deep learning baseada em redes neurais de grafos, usando PyTorch Geometric para construção de grafos e PyTorch Frame para tabular modeling, juntamente com um leaderboard público para acompanhar o progresso.

O lançamento da v2 também introduziu várias melhorias de usabilidade e desempenho, incluindo rótulos opcionais censurados no tempo, suporte à métrica NDCG em predição de links, geração mais rápida de sentence embeddings e gerenciamento de cache configurável.⁴

VIEIRA

O VIEIRA adota uma abordagem diferente, concentrando-se na programação com foundation models em vez de construir um único mecanismo preditivo. Ele estende o compilador de lógica probabilística SCALLOP com uma linguagem declarativa que integra large language models, vision models e outros componentes pré-treinados como predicados estrangeiros.⁵

Paradigma relacional

No VIEIRA, foundation models são tratados como funções sem estado com entradas e saídas relacionais. Isso permite compor models como GPT, CLIP ou SAM de acordo com regras lógicas. Por exemplo:

• Um programa pode usar o GPT para extrair conhecimento de texto e armazená-lo como relações estruturadas.
• O CLIP pode classificar imagens e vinculá-las a rótulos textuais em uma tabela.

Aplicações

O framework suporta:

• Raciocínio de data e matemática usando GPT.
• Raciocínio de parentesco usando extração de texto e inferência lógica.
• Respostas a perguntas que combinam recuperação e raciocínio.
• Resposta visual a perguntas e edição de imagens por meio de composição multimodal.

Ao unificar lógica simbólica e inferência neural, o VIEIRA permite que analistas de dados e desenvolvedores construam sistemas interpretáveis que usam foundation models pré-treinados para responder a consultas preditivas sobre dados estruturados e imagens.

Não perca os nossos benchmarks e insights baseados em dados. O botão abre o Google; selecionar a AIMultiple confirma que deseja ver a AIMultiple com mais frequência nos resultados de pesquisa do Google.

Adicionar como fonte preferencial

Estudos de caso

SAP Hana Cloud

O SAP HANA Cloud é um database-as-a-service totalmente gerenciado e nativo da nuvem, projetado para atuar como uma base de dados unificada para aplicações empresariais que combinam transações, analytics e IA. Em vez de servir como um banco de dados relacional de propósito único, o SAP HANA Cloud é posicionado como uma plataforma multimodelo que permite às organizações construir “aplicações de dados inteligentes” sobre dados de negócios operacionais.

O SAP HANA Cloud combina processamento em memória com armazenamento baseado em disco e integração de data lake para dar suporte a diferentes requisitos de desempenho e custo. Esse design flexível suporta workloads em tempo real enquanto escala dinamicamente à medida que os volumes de dados e o uso flutuam.

Um diferencial importante é seu mecanismo multimodelo nativo, que suporta dados relacionais, JSON/documento, grafo, espaciais e vetoriais em um único banco de dados. Isso permite que as aplicações combinem consultas SQL, relações de grafo e busca por similaridade vetorial sem mover dados entre sistemas separados, simplificando a arquitetura e reduzindo a latência.

Como parte da SAP Business Technology Platform, o SAP HANA Cloud integra-se diretamente a fontes de dados SAP e não SAP, incluindo acesso ao vivo sem replicação, e fornece segurança, disponibilidade e conformidade de nível corporativo por padrão.

No geral, o SAP HANA Cloud é uma plataforma de dados relacional-cêntrica e nativa de IA, na qual o banco de dados relacional serve como camada fundamental para analytics, dados multimodelo e aplicações empresariais de IA.

Figura 2: Imagem mostrando o banco de dados unificado do Hana e
o processamento de dados multimodelo.⁶

SAP’s sap-rpt-1

O sap-rpt-1 apresenta um único relational foundation model que executa uma ampla gama de tarefas preditivas por meio de in-context learning. Em vez de retreinar um novo model para cada caso de uso, os usuários fornecem alguns exemplos do seu padrão-alvo, como “clientes que pagaram em dia” e “clientes que pagaram com atraso”. O model então reconhece o padrão e produz imediatamente previsões precisas para novos dados.

O model é projetado com um mecanismo de atenção bidimensional que captura relações entre linhas e colunas, ao mesmo tempo em que incorpora metadados, como nomes de tabelas e colunas, em vector embeddings. Esse design permite que ele entenda a semântica de esquemas relacionais e as informações temporais em tabelas de negócios.

A abordagem da SAP traz várias vantagens para analistas de dados e usuários de negócios:

• Um único model que funciona em várias tabelas e domínios.
• Não necessidade de fine-tuning repetido ou desenvolvimento personalizado.
• Acesso a insights preditivos em minutos, não semanas.
• Integração com data warehouses existentes e sistemas SAP.

Ao incorporar o sap-rpt-1 no ecossistema SAP, especialistas de negócios podem interagir diretamente com seus próprios dados e receber previsões por meio de interfaces intuitivas. O resultado é um caminho mais rápido de dados estruturados para decisões acionáveis sem engenharia manual de atributos.

Figura 3: Fator de redução de erro do sap-rpt-1-large versus baselines de IA estreita nos domínios SAP.

No final de 2025, a SAP confirmou que o SAP-RPT-1 está disponível por meio do generative IA hub no SAP IA Foundation (SAP IA Core).

O model é oferecido em duas variantes de produção:

• SAP-RPT-1-small, otimizado para previsões de baixa latência e alta taxa de transferência,
• SAP-RPT-1-large, projetado para priorizar a precisão preditiva.

Este lançamento formaliza o papel do SAP-RPT-1 como um foundation model implementável na pilha de IA empresarial da SAP, em vez de uma capacidade apenas de pesquisa.

Além disso, a SAP oferece o SAP-RPT Playground, um ambiente no-code baseado na web onde os usuários podem testar in-context learning usando seus próprios dados ou dados de amostra fornecidos pela SAP.

SAP-ABAP-1

O SAP-ABAP-1 é um foundation model projetado para apoiar casos de uso de produtividade de desenvolvedores baseados em IA para clientes e parceiros SAP.

Ele está disponível por meio do generative IA hub da SAP e é treinado em mais de 250 milhões de linhas de código ABAP, 30 milhões de linhas de código CDS e extensa documentação técnica. O model é otimizado para entender e explicar código ABAP, apresentar melhores práticas e fornecer acesso a conhecimento atualizado de desenvolvimento SAP.

A SAP oferece acesso de gratuito trial ao SAP-ABAP-1 por meio do generative IA hub, com capacidades adicionais planejadas para lançamento em 2026.⁷

KumoRFM da Kumo.IA: um relational graph transformer para análise preditiva

A Kumo.IA, fundada pelo professor de Stanford Jure Leskovec, criou o KumoRFM, um relational foundation model que usa um relational graph transformer para analisar bancos de dados relacionais e data warehouses. Ele representa dados relacionais como um grafo temporal e heterogêneo, onde cada entidade é um nó e as chaves primárias e estrangeiras formam arestas entre tabelas.

Essa abordagem baseada em grafo permite que o KumoRFM aprenda com várias tabelas simultaneamente e se adapte a novos esquemas relacionais. O model é pré-treinado em fontes de dados diversas e pode generalizar para novos datasets sem construir models separados para cada tarefa preditiva.

O KumoRFM pode ser usado por meio de diferentes interfaces, dependendo da experiência do usuário:

• PQL (Predictive Query Language): Uma linguagem de consulta especializada para definir consultas preditivas em dados estruturados.
• Interface de linguagem natural: Para usuários não técnicos, entradas em linguagem natural são automaticamente traduzidas em consultas PQL.
• SDK em Python: Permite que desenvolvedores integrem o model em pipelines e aplicações de IA empresariais.

A arquitetura do KumoRFM amostra dinamicamente o banco de dados para criar subgrafos de contexto e subgrafos de previsão. Esses subgrafos são processados pelo relational graph transformer, que captura dependências e informações temporais entre entidades relacionadas. Por meio de in-context learning, o model fornece previsões precisas e pode explicar seu processo de raciocínio.

A Kumo oferece duas opções de deployment adequadas a ambientes empresariais:

• Plataforma SaaS: Um serviço baseado em nuvem construído sobre Apache Spark para fácil acesso e escalabilidade
• Nativo do data warehouse: Permite que as organizações usem seus próprios dados no Snowflake ou no Databricks sem movê-los para fora de seu ambiente seguro

Diferente dos knowledge graphs tradicionais que exigem definição manual de esquema, o KumoRFM constrói automaticamente seu grafo relacional a partir de fontes estruturadas. Isso o torna adequado para eCommerce, finanças e saúde, onde relações, padrões temporais e contexto em evolução são essenciais para previsões confiáveis.

As principais capacidades do KumoRFM incluem:

• Flexibilidade entre diferentes tabelas e estruturas de esquema.
• Compatibilidade com uma variedade de tipos de colunas e identificadores personalizados.
• Adaptação a tarefas específicas durante o tempo de inferência.
• Alta precisão e interpretabilidade em tarefas preditivas.

Figura 4: A imagem mostra como os Relational Foundation Models (RFMs) funcionam em vários domínios, como eCommerce, finanças e saúde, para fazer previsões, fornecer explicações e avaliar resultados.⁸

Metodologia de benchmark

Configuração e ambiente do benchmark

Para garantir comparações justas entre árvores limitadas por CPU e models acelerados por GPU, utilizamos um ambiente de alto desempenho capaz de lidar com ambos de forma eficiente.

• Hardware: Instância RunPod com uma NVIDIA H200 140GB GPU.
• Software: Python 3.12 com bibliotecas fixadas para reprodutibilidade:
  • scikit-learn 1.5.2, lightgbm 4.5.0, catboost 1.2.7
  • torch 2.5.1, pandas 2.2.3, numpy 2.1.3
  • sap-rpt-oss (Fonte: GitHub oficial)
• Reprodutibilidade: random_state=42 foi usado de forma consistente em todas as divisões, inicializações e models.

Datasets: o espectro semântico

Avaliamos os models em 17 datasets de aprendizado supervisionado provenientes do OpenML e do Scikit-Learn. Em vez de seleção aleatória, curamos esse conjunto para abranger o “Espectro Semântico-Numérico”, testando a hipótese de que os LLMs se destacam onde os atributos contêm significado linguístico, e não estatísticas brutas.

O inventário:

• Pequenos e semânticos (<1K linhas):
  • wine (178), sonar (208), vote (435), cylinder_bands (540), breast_cancer (569).
• Médios/mistos (1K – 10K linhas):
  • credit_g (1K), titanic (1.3K), car_evaluation (1.7K), spambase (4.6K), compas (5.2K), employee_salaries (9.2K).
• Grandes/numéricos (10K+ linhas):
  • california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs (amostrado para 100K).

Tarefas cobertas:

• 11 tarefas de classificação binária
• 2 tarefas de classificação multiclasse
• 4 tarefas de regressão

Configurações de model e pré-processamento

Buscamos uma “comparação de praticantes” realista, usando defaults fortes em vez de ajuste exaustivo de hiperparâmetros.

LightGBM & CatBoost

Para garantir uma comparação justa com o model SAP computacionalmente pesado, aumentamos os robustos default estimators.

• LightGBM: n_estimators=500, learning_rate=0.05, num_leaves=31. Executa na CPU (n_jobs=-1).
• CatBoost: iterations=500, learning_rate=0.05, depth=6. Executa na GPU (task_type=”GPU”).
• Pré-processamento: Label Encoding simples para categóricos; sem escalonamento para numéricos; imputação de mediana/moda para valores ausentes.

SAP-RPT-1-OSS

Configuramos o SAP para equilibrar desempenho e custo com base em nossos experimentos preliminares de configuração.

• Configuração: max_context_size=4096, bagging=4.
• Observação:
  • Contexto: Testes em adult_income mostraram que aumentar o contexto de 4096 para 8192 triplicou o tempo de execução (4 min para 12 min) com ganho de precisão desprezível (0.917 vs 0.917 ROC-AUC).
  • Bagging: Aumentar o bagging de 4 para 8 (configuração padrão da SAP usada no artigo⁹) ofereceu retornos decrescentes.
• Pré-processamento: Nenhum. O DataFrame bruto do pandas é passado diretamente. O model codifica usando text embeddings (sentence-transformers/all-MiniLM-L6-v2).

Protocolo de avaliação

Estratégia de validação cruzada

Utilizamos validação cruzada com 3 dobras com embaralhamento.

• Reduzimos o padrão de 5 dobras para 3 dobras para acomodar os tempos lentos de inferência do SAP (40% de economia de tempo), mantendo a validade estatística.
• Divisão: StratifiedKFold para classificação; K-Fold padrão para regressão.

Métricas e diagnósticos

Fomos além da simples accuracy para capturar uma visão holística do desempenho do model:

• Métricas primárias de ranqueamento: ROC-AUC (Binária), Balanced Accuracy (Multiclasse), R² (Regressão).
• Diagnósticos secundários: Acompanhamos o coeficiente de correlação de Matthews (MCC) e a log loss para garantir que as vitórias não fossem artefatos de desequilíbrio de classe, e o MAPE para calibração de erro de regressão.
• Cálculo de custo: Baseado no tempo total de execução (pré-processamento + treinamento + inferência) na instância RunPod H200 ($3,59/h).

Significância estatística

Aplicamos um teste de Wilcoxon signed-rank (p<0.05) às comparações pareadas de models para determinar se as diferenças de desempenho foram estatisticamente significativas ou ruído aleatório.

Limitações e validade interna

Reconhecemos explicitamente as seguintes restrições em nossa metodologia:

1. Configurações padronizadas vs. tuning: Utilizamos configurações fixas e fortes como padrão para todos os models, em vez de realizar otimização exaustiva de hiperparâmetros (por exemplo, CV aninhado ou buscas com Optuna). Embora isso garanta uma baseline consistente, vale notar que os modelos de árvore geralmente apresentam ganhos de desempenho com tuning específico do dataset, o que poderia reduzir as margens no cluster “Competitivo”.
2. Limites de escala de dados: Nossa análise se concentrou em datasets com menos de 100k linhas para simular cenários empresariais típicos de médio porte. Observamos que a vantagem do LLM diminui à medida que o volume de dados cresce, mas não estendemos os testes a escalas de milhões de linhas, onde a latência de inferência e o custo provavelmente se tornariam as principais restrições.
3. Uniformidade de infraestrutura: Para manter um ambiente de teste consistente, executamos todos os models no mesmo hardware NVIDIA H200. O LightGBM e o CatBoost são altamente otimizados para CPUs comuns; portanto, em um ambiente de produção dedicado exclusivamente a modelos de árvore, o diferencial de custo provavelmente seria maior.
4. Generalização além da semântica: Nossa hipótese do “Espectro Semântico” previu com sucesso muitos resultados, mas o forte desempenho do LLM em datasets abstratos como sonar e california_housing sugere capacidades além da compreensão linguística. Isso indica que o model também pode estar aproveitando padrões de regularização de alta dimensionalidade, um fenômeno que merece investigação adicional além do escopo deste estudo inicial.

Cite este benchmark

Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.

@misc{ermut2026,
  author = {Ermut, Sıla and Sarı, Ekrem},
  title  = {{Comparação de Foundation Models Relacionais}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Acessado em 15 setembro 2026}
}

Registro de alterações

2 atualizações

2026

1. 4 fev

   Adicionado SAP HANA Cloud à seção Estudos de Caso.

2. 21 jan

   Removida a seção "Modelos de fundação para dados relacionais e estruturados".

Links de referência

1.

Griffin: Towards a Graph-Centric Relational Database Foundation Model

2.

RELATIONAL TRANSFORMER: TOWARD ZERO-SHOT FOUNDATION MODELS FOR RELATIONAL DATA

3.

RELBENCH: A Benchmark for Deep Learning on Relational Databases

4.

GitHub - stanford-star/relbench: RelBench: Relational Deep Learning Benchmark · GitHub

5.

Relational Programming with Foundation Models

6.

SAP HANA Cloud

7.

SAP Business AI: Release Highlights Q4 2025 | SAP News Center

SAP

8.

Kumo.AI trains foundation model for relational databases

blocksandfiles

9.

[2506.10707] ConTextTab: A Semantics-Aware Tabular In-Context Learner

Sıla Ermut

Analista do Setor

Siga-nos

Sıla Ermut é analista do setor na AIMultiple, cobrindo models de IA, infraestrutura de IA, governança de IA e aplicações empresariais de IA. Sua pesquisa se concentra principalmente no uso de IA em marketing, saúde, cadeias de suprimentos e sustentabilidade.
Ela trabalhou anteriormente como recrutadora em empresas de gerenciamento de projetos e consultoria. Sıla possui mestrado em Psicologia Social e bacharelado em Relações Internacionais.

Ver perfil completo

Pesquisado por

Ekrem Sarı

Pesquisador de IA

Siga-nos

Ekrem é Pesquisador de IA e Cientista de Dados na AIMultiple. Ele projeta e executa benchmarks práticos para sistemas de IA e LLM.

Ver perfil completo

Seja o primeiro a comentar

Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.

Nome

Endereço de email

Comentário

0/450

Postar comentário