Comparação de Modelos de Fundação Relacionais

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

O 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 enfrentam desafios sob escala ou estrutura de baixa semântica.

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

• Taxa de Sucesso: Representa a pontuação normalizada média (0.0 a 1.0). Uma barra mais alta indica que o modelo está consistentemente mais próximo do melhor desempenho possível para datasets nessa categoria.
• 100 – 500 linhas (3 Datasets):
  • Incluídos: wine (178), sonar (208), vote (435).
  • Resultado: O SAP tem o melhor desempenho em 2 dos 3 datasets. Alcança as pontuações mais altas no wine e no sonar, sugerindo que os priores do LLM podem ser benéficos quando os dados de treino são escassos. No entanto, o CatBoost garantiu uma vitória apertada no dataset vote (dentro de 0.1%), indicando que os modelos de árvore permanecem altamente competitivos mesmo em pequenas escalas.
• 501 – 1.000 linhas (3 Datasets):
  • Incluídos: cylinder_bands (540), breast_cancer (569), credit_g (1.000).
  • Resultado: O SAP tem o melhor desempenho em todos os 3 datasets. No 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 sejam necessários estudos de ablação adicionais para confirmar este mecanismo.
• 1.000 – 10.000 linhas (5 Datasets):
  • Incluídos: 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 dos 5 datasets, tendo um desempenho particularmente bom em tarefas com muitos textos como spambase e titanic. No entanto, o CatBoost supera significativamente o SAP no compas por 10.4%, indicando características específicas do dataset que favorecem os modelos de árvore mesmo nesta faixa de tamanho.
• 10.000+ linhas (6 Datasets):
  • Incluídos: california_housing (20K), house_sales (21K), default_credit (30K), adult_income (48K), diamonds (53K), higgs_100k (98K).
  • Resultado: À medida que o volume de dados aumenta, a potencial vantagem de "conhecimento prévio" do LLM diminui. O LightGBM e o CatBoost alcançam os melhores resultados em 5 dos 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 dos resultados do benchmark

Abaixo está a discriminação completa do desempenho dos modelos em todos os 17 datasets.

2. Análise de custo e eficiência

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

O SAP-RPT-1-OSS incorre em custos significativamente mais elevados devido ao tempo necessário para o pré-processamento de embeddings de texto e à elevada sobrecarga de memória da arquitetura do LLM. Em contrapartida, o LightGBM e o CatBoost concluem as tarefas quase instantaneamente neste hardware. Os custos abaixo refletem o tempo total de relógio de parede (pré-processamento + treino) para uma execução de validação cruzada de 3 partições.

Custo médio por dataset (Média de 17 Datasets)

Discriminação de custos por tamanho do dataset

• Datasets Pequenos (<1K linhas): O SAP é relativamente barato (≈ $0,03 por execução). A elevada taxa de vitórias aqui torna o custo insignificante.
• Datasets Grandes (>20K linhas): O SAP torna-se caro.
  • Exemplo: Treinar no adult_income (48k linhas) demora ≈ 12 minutos no total para 3 partições.
  • Custo: 12 min X $0,06/min = $0,72 por experiência.
  • 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 do que a linha de base. Este 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 um ganho de +5.5%), mas torna-se mais difícil de justificar para grandes datasets onde os modelos de árvore alcançam desempenho igual ou superior a uma fração do custo.

3. Quadro de análise: O Espectro Semântico

Para interpretar estes resultados, é crucial compreender como selecionámos os dados. Não escolhemos datasets aleatoriamente; reunimos um conjunto de 17 datasets especificamente escolhidos para abranger o Espectro Semântico-Numérico.

A nossa hipótese central era que o SAP (sendo 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. Categorizámos os nossos datasets em três grupos distintos:

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

Características: As features contêm descrições de texto ricas, rótulos categóricos com significado do mundo real (por exemplo, "physician fee freeze"), ou terminologia específica do domínio.

• Datasets:
  • cylinder_bands: Defeitos de impressão industrial.
  • titanic: Nomes e títulos dos passageiros.
  • vote: Registos de votação do Congresso (Categórico "Sim/Não" em políticas).
  • breast_cancer: Descrições de tumores médicos.
  • spambase: Frequências de palavras em emails.
  • wine: Origens químicas.

Grupo B: Dados empresariais mistos (6 datasets)

Características: O formato tabular padrão encontrado na maioria das bases de dados empresariais, 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 demografia (Atributos sensíveis).
  • adult_income: Demografia do censo.
  • credit_g: Perfis de risco de crédito alemães.
  • default_credit: Dados de incumprimento de crédito de Taiwan.
  • car_evaluation: Parâmetros de compra de veículos.

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

Características: As features 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 sim.

• Datasets:
  • higgs_100k: Cinemática de partículas físicas.
  • diamonds: Dimensões físicas e preço.
  • sonar: Ressonâncias de energia de frequência.
  • california_housing: Coordenadas Lat/Long e estatísticas do censo.
  • house_sales: Imobiliário do King County (maioritariamente features numéricas).

4. Análise aprofundada: Onde o SAP vence vs. falha

Aplicando o quadro de análise aos nossos resultados, revelam-se quatro padrões de desempenho distintos. A tabela abaixo resume exatamente onde o SAP se destaca e onde falha.

Fundamentos conceptuais dos modelos de fundação relacionais

O principal objetivo de um modelo de fundação relacional é fazer previsões precisas e realizar diversas tarefas sobre tabelas estruturadas. Estes modelos devem compreender como a informação é representada em diferentes tabelas, como as entidades estão ligadas através de relações e como a informação temporal influencia os resultados.

As principais capacidades de tais modelos incluem:

• Generalização de esquema: A capacidade de se adaptar a novos esquemas relacionais sem retreino a partir do zero.
• Representação de entrada unificada: Lidar com diferentes tipos de colunas, como features numéricas, categóricas 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 através de pré-treino e aprendizagem zero-shot.

Griffin

O Griffin é uma das primeiras tentativas em grande escala de construir um modelo de fundação relacional unificado. 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. As principais características incluem:

Codificador de features unificado

• As features categóricas e de texto são codificadas com um codificador de texto pré-treinado, enquanto os valores numéricos usam um codificador de float aprendido.
• Metadados como nomes de tabelas, nomes de colunas e tipos de arestas são incorporados para ajudar o modelo a reconhecer o esquema relacional.
• Os embeddings de tarefa permitem que um único modelo realize tarefas de regressão e classificação com descodificadores partilhados.

Passagem de mensagens e atenção

O Griffin integra redes neuronais de passagem de mensagens com um módulo de atenção cruzada. O componente de passagem de mensagens agrega informação dentro e entre relações, enquanto a atenção cruzada se foca em células relevantes dentro de cada linha. Este design ajuda o modelo a lidar com dados diversos e a manter o contexto entre entidades conectadas.

Pré-treino e fine-tuning

O modelo é pré-treinado em datasets de tabela única através de uma tarefa de conclusão de células mascaradas e depois sofre fine-tuning em bases de dados relacionais para tarefas específicas. Experiências em grandes benchmarks relacionais mostram que o Griffin supera as linhas de base GNN tradicionais e os modelos de tabela única, tanto em precisão como em eficiência de aprendizagem por transferência.

Figura 1: Diagrama mostrando o Griffin Model Framework.¹

Relational Transformer

Enquanto o Griffin se foca na agregação de grafos, o Relational Transformer (RT) aplica arquiteturas de transformer diretamente a bases de dados relacionais. Trata cada célula como um token enriquecido com o 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 dados (numérico, texto ou datetime).
• Um embedding de esquema gerado a partir do texto da tabela e coluna.
• Um token de máscara é usado quando o valor está oculto durante o pré-treino.

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

Atenção relacional

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

• Atenção de coluna para aprender distribuições de valores dentro das colunas.
• Atenção de feature para combinar atributos dentro da mesma linha ou linhas pai ligadas.
• Atenção de vizinhança para agregar informação de linhas filhas conectadas.

Together, estas camadas de atenção formam um transformer de grafo relacional que modela dependências entre linhas, colunas e tabelas.

Resultados de treino e transferência

O RT é pré-treinado em bases de dados relacionais do RelBench. Em experiências, o modelo pré-treinado alcançou até 94% do desempenho de modelos totalmente supervisionados em configurações zero-shot. Também aprendeu mais rapidamente durante o fine-tuning, exigindo menos passos de treino para atingir alta precisão.²

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

RelBench

O RelBench foi concebido para avançar a aprendizagem profunda relacional, que se foca na aprendizagem ponta a ponta a partir de dados distribuídos por múltiplas tabelas relacionadas em bases de dados relacionais.

Uma vez que as bases de dados relacionais permanecem o sistema de gestão de dados dominante na indústria e na ciência, o RelBench fornece uma framework padronizada e reproduzível para avaliar modelos que operam diretamente em estruturas relacionais, em vez de dependerem de achatamento manual de features.

As versões anteriores do RelBench introduziram 11 bases de dados relacionais abrangendo domínios como saúde, redes sociais, e-commerce e desporto, com 70 tarefas preditivas concebidas para serem simultaneamente desafiantes e relevantes para o domínio.³

Em janeiro de 2026, foi lançado o RelBench v2, adicionando quatro novas bases 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 modelo prever colunas existentes dentro de uma base de dados relacional.

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

Além de datasets e tarefas, o RelBench fornece uma implementação de referência open-source para aprendizagem profunda relacional baseada em redes neuronais de grafos, usando PyTorch Geometric para construção de grafos e PyTorch Frame para modelação tabular, juntamente com um leaderboard público para acompanhar o progresso.

O lançamento v2 também introduziu várias melhorias de usabilidade e desempenho, incluindo rótulos opcionais com censura temporal, suporte para a métrica NDCG na previsão de ligações, geração mais rápida de embeddings de frases e gestão de cache configurável.⁴

VIEIRA

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

Paradigma relacional

No VIEIRA, os modelos de fundação são tratados como funções sem estado com entradas e saídas relacionais. Isto permite compor modelos 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 ligá-las a rótulos textuais numa tabela.

Aplicações

A framework suporta:

• Raciocínio de datas e matemática usando GPT.
• Raciocínio de parentesco usando extração de texto e inferência lógica.
• Resposta a perguntas que combina recuperação e raciocínio.
• Resposta a perguntas visuais e edição de imagens através de composição multimodal.

Ao unificar lógica simbólica e inferência neural, o VIEIRA permite que analistas de dados e programadores construam sistemas interpretáveis que usam modelos de fundação 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

Casos de estudo

SAP HANA Cloud

O SAP HANA Cloud é uma base de dados como serviço totalmente gerida e nativa da cloud, concebida para atuar como uma base de dados unificada para aplicações empresariais que combinam transações, análises e IA. Em vez de servir como uma base de dados relacional de propósito único, o SAP HANA Cloud posiciona-se como uma plataforma multi-modelo que permite às organizações construir "aplicações de dados inteligentes" sobre dados empresariais operacionais.

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

Um diferenciador chave é o seu motor multi-modelo nativo, que suporta dados relacionais, JSON/documento, grafo, espaciais e vetoriais dentro de uma única base de dados. Isto permite que as aplicações combinem consultas SQL, relações de grafo e pesquisa de similaridade vetorial sem mover dados entre sistemas separados, simplificando assim a arquitetura e reduzindo a latência.

Como parte da SAP Business Technology Platform, o SAP HANA Cloud integra-se diretamente com 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 empresarial por padrão.

No geral, o SAP HANA Cloud é uma plataforma de dados centrada no relacional e nativa de IA, na qual a base de dados relacional serve como a camada fundamental para análises, dados multi-modelo e aplicações empresariais de IA.

Figura 2: Imagem mostrando a base de dados unificada do Hana e
o processamento de dados multi-modelo.⁶

SAP-RPT-1 da SAP

O sap-rpt-1 introduz um único modelo de fundação relacional que realiza uma ampla gama de tarefas preditivas através de aprendizagem em contexto. Em vez de retreinar um novo modelo para cada caso de uso, os utilizadores fornecem alguns exemplos do seu padrão alvo, como "clientes que pagaram a tempo" e "clientes que pagaram com atraso". O modelo reconhece então o padrão e produz imediatamente previsões precisas para novos dados.

O modelo é concebido com um mecanismo de atenção bidimensional que captura relações entre linhas e colunas, ao mesmo tempo que incorpora metadados, como nomes de tabelas e colunas, em embeddings vetoriais. Este design permite-lhe compreender a semântica dos esquemas relacionais e a informação temporal dentro das tabelas empresariais.

A abordagem da SAP traz várias vantagens para analistas de dados e utilizadores empresariais:

• Um único modelo que funciona em múltiplas tabelas e domínios.
• Sem necessidade de fine-tuning repetido ou desenvolvimento personalizado.
• Acesso a insights preditivos em minutos em vez de semanas.
• Integração com data warehouses existentes e sistemas SAP.

Ao incorporar o sap-rpt-1 dentro do ecossistema SAP, os especialistas empresariais podem interagir diretamente com os seus próprios dados e receber previsões através de interfaces intuitivas. O resultado é um caminho mais rápido dos dados estruturados para decisões acionáveis, sem engenharia manual de features.

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

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

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

• SAP-RPT-1-small, otimizado para previsões de baixa latência e alto débito,
• SAP-RPT-1-large, concebido para priorizar a precisão preditiva.

Este lançamento formaliza o papel do SAP-RPT-1 como um modelo de fundação implementável dentro da stack de IA empresarial da SAP, em vez de uma capacidade apenas de investigação.

Além disso, a SAP oferece o SAP-RPT Playground, um ambiente no-code baseado na web onde os utilizadores podem testar a aprendizagem em contexto usando os seus próprios dados ou dados de amostra fornecidos pela SAP.

SAP-ABAP-1

O SAP-ABAP-1 é um modelo de fundação concebido para suportar casos de uso de produtividade de programadores baseados em IA para clientes e parceiros SAP.

Está disponível através 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 modelo é otimizado para compreender e explicar código ABAP, evidenciar melhores práticas e fornecer acesso a conhecimento de desenvolvimento SAP atualizado.

A SAP oferece acesso de teste gratuito ao SAP-ABAP-1 via o generative IA hub, com capacidades adicionais planeadas para lançamento em 2026.⁷

KumoRFM da Kumo.IA: um transformer de grafo relacional para análises preditivas

A Kumo.IA, fundada pelo professor de Stanford Jure Leskovec, criou o KumoRFM, um modelo de fundação relacional que usa um transformer de grafo relacional para analisar bases de dados relacionais e data warehouses. 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.

Esta abordagem baseada em grafos permite que o KumoRFM aprenda a partir de múltiplas tabelas simultaneamente e se adapte a novos esquemas relacionais. O modelo é pré-treinado em diversas fontes de dados e pode generalizar para novos datasets sem construir modelos separados para cada tarefa preditiva.

O KumoRFM pode ser usado através de diferentes interfaces, dependendo da experiência do utilizador:

• PQL (Predictive Query Language): Uma linguagem de consulta especializada para definir consultas preditivas em dados estruturados.
• Interface de linguagem natural: Para utilizadores não técnicos, as entradas em linguagem natural são automaticamente traduzidas em consultas PQL.
• Python SDK: Permite que os programadores integrem o modelo em pipelines e aplicações de IA empresarial.

A arquitetura do KumoRFM amostra dinamicamente a base de dados para criar subgrafos de contexto e subgrafos de previsão. Estes subgrafos são processados pelo transformer de grafo relacional, que captura dependências e informação temporal entre entidades relacionadas. Através da aprendizagem em contexto, o modelo fornece previsões precisas e pode explicar o seu processo de raciocínio.

A Kumo oferece duas opções de implementação adequadas a ambientes empresariais:

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

Ao contrário dos grafos de conhecimento tradicionais que exigem definição manual de esquema, o KumoRFM constrói automaticamente o seu grafo relacional a partir de fontes estruturadas. Isto torna-o 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 fiá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 Modelos de Fundação Relacionais (RFMs) funcionam em múltiplos domínios, como eCommerce, finanças e saúde, para fazer previsões, fornecer explicações e avaliar resultados.⁸

Metodologia do benchmark

Configuração e ambiente do benchmark

Para garantir comparações justas entre árvores limitadas por CPU e modelos acelerados por GPU, utilizámos 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 modelos.

Datasets: O espectro semântico

Avaliámos os modelos em 17 datasets de aprendizagem supervisionada provenientes do OpenML e Scikit-Learn. Em vez de uma seleção aleatória, reunimos este conjunto para abranger o "Espectro Semântico-Numérico", testando a hipótese de que os LLMs se destacam onde as features contêm significado linguístico em vez de 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 abrangidas:

• 11 tarefas de Classificação Binária
• 2 tarefas de Classificação Multiclasse
• 4 tarefas de Regressão

Configurações dos modelos e pré-processamento

Procurámos uma "comparação de profissional" realista, usando valores padrão fortes em vez de otimização exaustiva de hiperparâmetros.

LightGBM e CatBoost

Para garantir uma comparação justa contra o modelo SAP computacionalmente pesado, aumentámos os estimadores padrão robustos.

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

SAP-RPT-1-OSS

Configurámos o SAP para equilibrar desempenho e custo com base nas nossas experiências preliminares de configuração.

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

Protocolo de avaliação

Estratégia de validação cruzada

Utilizámos Validação Cruzada de 3 Partições com baralhamento.

• Reduzimos o padrão de 5 partições para 3 partições para acomodar os tempos lentos de inferência do SAP (poupança de 40% 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 precisão para capturar uma visão holística do desempenho do modelo:

• Métricas primárias de classificação: ROC-AUC (Binária), Acurácia Balanceada (Multiclasse), R² (Regressão).
• Diagnósticos secundários: Acompanhámos o coeficiente de correlação de Matthews (MCC) e a log loss para garantir que as vitórias não eram artefactos de desequilíbrio de classes, e o MAPE para calibração de erro de regressão.
• Cálculo de custo: Baseado no tempo total de relógio de parede (pré-processamento + treino + inferência) na instância RunPod H200 ($3,59/hr).

Significância estatística

Aplicámos um teste de Wilcoxon signed-rank (p<0.05) a comparações de modelos aos pares para determinar se as diferenças de desempenho eram estatisticamente significativas ou ruído aleatório.

Limitações e validade interna

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

1. Configurações padronizadas vs. otimização: Utilizámos configurações padrão fixas e fortes para todos os modelos, em vez de realizar otimização exaustiva de hiperparâmetros (por exemplo, CV aninhado ou pesquisas Optuna). Embora isto garanta uma linha de base consistente, vale a pena notar que os modelos de Árvore frequentemente veem ganhos de desempenho com otimização específica do dataset, o que poderia reduzir as margens no grupo "Competitivo".
2. Limites de escala de dados: A nossa análise focou-se em datasets com menos de 100k linhas para simular cenários empresariais típicos de média dimensão. Observámos que a vantagem do LLM diminuía à medida que o volume de dados aumentava, 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, executámos todos os modelos no mesmo hardware NVIDIA H200. O LightGBM e o CatBoost são altamente otimizados para CPUs comuns; portanto, num ambiente de produção dedicado exclusivamente a modelos de Árvore, o diferencial de custo seria provavelmente maior.
4. Generalização além da semântica: A 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. Isto indica que o modelo também pode estar a aproveitar padrões de regularização de alta dimensão, um fenómeno que merece investigação adicional além do âmbito 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 Modelos de Fundação Relacionais}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/relational-foundation-model}},
  note   = {AIMultiple. Acessado em 2 Setembro 2026}
}

Registro de alterações

2 atualizações

1. 20264 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.

https://arxiv.org/pdf/2505.05568

2.

https://arxiv.org/pdf/2510.06377

3.

https://arxiv.org/pdf/2407.20060

4.

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

5.

https://arxiv.org/pdf/2412.14515

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