Comparar modelos de fundamentos relacionais
Comparamos o desempenho do SAP-RPT-1-OSS com o de algoritmos de gradient boosting (LightGBM, CatBoost) em 17 conjuntos de dados tabulares que abrangem o espectro semântico-numérico, incluindo tabelas pequenas/com alta semântica, conjuntos de dados comerciais mistos e grandes conjuntos de dados numéricos com baixa semântica.
Nosso objetivo é avaliar em que situações os conhecimentos prévios semânticos pré-treinados de um modelo de árvore de decisão relacional podem oferecer vantagens em relação aos modelos de árvore tradicionais e em que situações enfrentam desafios em escala ou com baixa estrutura semântica.
SAP-RPT-1-OSS vs. Gradient Boosting: Resultados de benchmark
- Taxa de sucesso: Representa a pontuação média normalizada (de 0,0 a 1,0). Uma barra mais alta indica que o modelo está consistentemente mais próximo do melhor desempenho possível para conjuntos de dados nessa categoria.
- 100 a 500 linhas (3 conjuntos de dados):
- Incluído: vinho (178), sonar (208), voto (435).
- Resultado: O SAP apresentou o melhor desempenho em 2 dos 3 conjuntos de dados. Obteve as pontuações mais altas nos conjuntos de dados wine e sonar, sugerindo que as distribuições a priori LLM podem ser benéficas quando os dados de treinamento são escassos. No entanto, o CatBoost obteve uma vitória apertada no conjunto de dados vote (com diferença de até 0,1%), indicando que os modelos de árvore permanecem altamente competitivos mesmo em pequena escala.
- 501 a 1.000 linhas (3 conjuntos de dados):
- Incluído: faixas_cilindro (540), câncer_de_mama (569), crédito_g (1.000).
- Resultado: O SAP apresentou o melhor desempenho em todos os 3 conjuntos de dados. No conjunto de dados cylinder_bands, o SAP superou o LightGBM em 5,5%, possivelmente devido a um melhor tratamento das descrições semânticas de defeitos industriais, embora sejam necessários mais estudos de ablação para confirmar esse mecanismo.
- 1.000 a 10.000 linhas (5 conjuntos de dados):
- Incluído: titanic (1,3 mil), avaliação de carros (1,7 mil), base de spam (4,6 mil), bússola (5,2 mil), salários de funcionários (9,2 mil).
- Resultado: O SAP obteve os melhores resultados em 4 dos 5 conjuntos de dados, apresentando um desempenho particularmente bom em tarefas com grande volume de texto, como Spambase e Titanic. No entanto, o CatBoost superou significativamente o SAP no conjunto de dados Compas em 10,4%, indicando características específicas desse conjunto de dados que favorecem modelos de árvore mesmo nessa faixa de tamanho.
- Mais de 10.000 linhas (6 conjuntos de dados):
- Incluído: california_housing (20 mil), house_sales (21 mil), default_credit (30 mil), adult_income (48 mil), diamonds (53 mil), higgs_100k (98 mil).
- Resultado: À medida que o volume de dados aumenta, a potencial vantagem do "conhecimento prévio" do LLM diminui. O LightGBM e o CatBoost obtiveram os melhores resultados em 5 dos 6 conjuntos de dados, oferecendo maior precisão a uma fração do custo computacional. A única exceção, california_housing, mostrou apenas uma modesta vantagem de 1,7% para o SAP.
1. Tabela de conjuntos de dados de resultados de benchmark
A seguir, apresentamos a análise completa do desempenho do modelo em todos os 17 conjuntos de dados.
2. Análise de custos e eficiência
Calculamos o custo computacional direto para cada modelo com base no preço da instância RunPod H200 de US$ 3,59/hora .
O SAP-RPT-1-OSS incorre em custos significativamente maiores devido ao tempo necessário para o pré-processamento da incorporação de texto e à alta sobrecarga de memória da arquitetura LLM. Em contraste, o LightGBM e o CatBoost concluem as tarefas quase instantaneamente neste hardware. Os custos abaixo refletem o tempo total (pré-processamento + treinamento) para uma execução de validação cruzada de 3 vias.
Custo médio por conjunto de dados (média de 17 conjuntos de dados)
Detalhamento de custos por tamanho do conjunto de dados
- Conjuntos de dados pequenos (menos de 1.000 linhas): o SAP é relativamente barato (aproximadamente US$ 0,03 por execução). A alta taxa de sucesso torna o custo insignificante.
- Conjuntos de dados grandes (mais de 20 mil linhas): o SAP torna-se caro.
- Exemplo: O treinamento com adult_income (48 mil linhas) leva aproximadamente 12 minutos no total para 3 folds.
- Custo: 12 minutos x US$ 0,06/min = US$ 0,72 por experimento.
- Comparação: o LightGBM realiza a mesma tarefa por US$ 0,01 .
Conclusão: Embora US$ 0,22 por conjunto de dados não seja caro em termos absolutos, o SAP é 22 vezes mais caro que a linha de base. Essa diferença de custo pode ser justificada para conjuntos de dados pequenos e semanticamente ricos, nos quais o SAP demonstra melhorias significativas na precisão (por exemplo, cylinder_bands com aumento de 5,5%), mas torna-se mais difícil de justificar para conjuntos de dados grandes, nos quais os modelos de árvore alcançam desempenho igual ou superior a uma fração do custo.
3. Estrutura de análise: O Espectro Semântico
Para interpretar esses resultados, é crucial entender como selecionamos os dados. Não escolhemos os conjuntos de dados aleatoriamente; selecionamos um conjunto de 17 conjuntos de dados especificamente escolhidos para abranger o Espectro Semântico-Numérico .
Nossa hipótese principal era que o SAP (por ser baseado em LLM) se destacaria em casos onde os dados possuem significado linguístico, enquanto os modelos de árvore dominariam em cálculos numéricos brutos. Categorizamos nossos conjuntos de dados em três grupos distintos:
Cluster A: Conjuntos de dados com alta semântica (6 conjuntos de dados)
Características: Os recursos contêm descrições textuais detalhadas, rótulos categóricos com significado no mundo real (por exemplo, "congelamento de honorários médicos") ou terminologia específica do domínio.
- Conjuntos de dados:
- faixas_cilindro: Defeitos de impressão industrial.
- Titanic: Nomes e títulos dos passageiros.
- Votação: Registros de votação no Congresso (respostas categóricas "Sim/Não" sobre políticas).
- câncer_de_mama: Descrições médicas de tumores.
- spambase: Frequência de palavras em e-mails.
- Vinho: Origens químicas.
Cluster B: Dados empresariais mistos (6 conjuntos de dados)
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).
- Conjuntos de dados:
- salários_dos_funcionários: Cargos versus salários.
- compass: Histórico criminal e dados demográficos (Atributos sensíveis).
- renda_de_adultos: 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.
- avaliação_de_carros: Parâmetros de compra de veículos.
Cluster C: Dados numéricos puros/de baixa semântica (5 conjuntos de dados)
Características: Os atributos são medições abstratas, leituras de sensores ou coordenadas físicas. Os nomes das colunas geralmente não importam; apenas as relações matemáticas são relevantes.
- Conjuntos de dados:
- higgs_100k: Física - cinemática de partículas.
- Diamantes: Dimensões físicas e preço.
- Sonar: Reflexos de energia de frequência.
- Habitação na Califórnia: Coordenadas de latitude/longitude e estatísticas do censo.
- vendas_de_casas: Imóveis no Condado de King (principalmente dados numéricos).
4. Análise detalhada: Onde a SAP se destaca e onde falha
A aplicação da estrutura de análise aos nossos resultados revela quatro padrões de desempenho distintos. A tabela abaixo resume exatamente onde a SAP se destaca e onde apresenta deficiências.
Fundamentos conceituais dos modelos de fundamentação relacional
O principal objetivo de um modelo relacional é fazer previsões precisas e executar diversas tarefas em tabelas estruturadas. Esses modelos devem compreender como a informação é representada em diferentes tabelas, como as entidades estão ligadas por meio de relacionamentos e como a informação temporal influencia os resultados.
As principais funcionalidades desses modelos incluem:
- Generalização de esquemas: a capacidade de se adaptar a novos esquemas relacionais sem precisar recomeçar do zero.
- Representação unificada de entrada: tratamento de diferentes tipos de colunas, como recursos numéricos, categóricos e textuais.
- Integração do contexto temporal e estrutural: Captura de dependências ao longo do tempo e entre entidades ligadas por chaves primárias e estrangeiras.
- Transferibilidade: Executar tarefas preditivas em novos conjuntos de dados por meio de pré-treinamento e aprendizado zero-shot.
Griffin
Griffin é uma das primeiras tentativas em larga escala de construir um modelo unificado de fundamentos relacionais. Ele representa dados relacionais como um grafo temporal e heterogêneo, onde cada linha se torna um nó e as arestas correspondem a relacionamentos de chave estrangeira. Os principais recursos incluem:
Codificador de recursos unificado
- As características categóricas e textuais são codificadas com um codificador de texto pré-treinado, enquanto os valores numéricos utilizam um codificador de ponto flutuante aprendido.
- Dados 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 tarefas permitem que um único modelo execute tarefas de regressão e classificação com decodificadores compartilhados.
Transmissão de mensagens e atenção
Griffin integra redes neurais de passagem de mensagens com um módulo de atenção cruzada. O componente de passagem de mensagens agrega informações dentro e entre relações, enquanto a atenção cruzada se concentra em células relevantes dentro de cada linha. Esse design ajuda o modelo a lidar com dados diversos e a manter o contexto entre entidades conectadas.
Pré-treinamento e ajustes finais
O modelo é pré-treinado em conjuntos de dados de tabela única por meio de uma tarefa de preenchimento de células mascaradas e, em seguida, ajustado em bancos de dados relacionais para tarefas específicas. Experimentos em grandes benchmarks relacionais mostram que o Griffin supera as linhas de base tradicionais de GNN e os modelos de tabela única tanto em precisão quanto em eficiência de aprendizado por transferência.
Figura 1: Gráfico que mostra a estrutura do Modelo de Griffin. 1
Transformador relacional
Enquanto Griffin se concentra na agregação de grafos, o Relational Transformer (RT) aplica arquiteturas de transformadores diretamente a bancos de dados relacionais. Ele trata cada célula como um token enriquecido com seu valor, nome da coluna e nome da tabela.
Representação de entrada
Cada token combina:
- Um valor incorporado que depende do seu tipo de dados (numérico, texto ou data e hora).
- Um esquema incorporado é gerado a partir do texto da tabela e da coluna.
- Um token de máscara é usado quando o valor é ocultado 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
A RT introduz um mecanismo de atenção relacional que opera ao nível celular. Inclui:
- Atenção às colunas para aprendizado da distribuição de valores dentro das colunas.
- Funcionalidade que destaca a capacidade de combinar atributos na mesma linha ou em linhas pai vinculadas.
- Atenção aos vizinhos para agregar informações de linhas filhas conectadas.
Em conjunto, essas camadas de atenção formam um transformador de grafo relacional que modela as 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 modelo pré-treinado alcançou até 94% do desempenho de modelos totalmente supervisionados em cenários de aprendizado zero-shot. Ele também aprendeu mais rápido durante o ajuste fino, exigindo menos etapas de treinamento para atingir alta precisão. 2
Essa abordagem sugere que os bancos de dados relacionais compartilham padrões transferíveis entre domínios e que a tokenização em nível de célula fornece uma base prática para tarefas preditivas em dados estruturados.
RelBench
O RelBench foi projetado para aprimorar o aprendizado profundo relacional, 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 de gerenciamento de dados dominante na indústria e na ciência, o RelBench fornece uma estrutura padronizada e reproduzível para avaliar modelos que operam diretamente em estruturas relacionais, em vez de depender do achatamento manual de recursos.
As versões anteriores do RelBench introduziram 11 bancos de dados relacionais abrangendo domínios como saúde, redes sociais , comércio eletrônico e esportes, com 70 tarefas preditivas projetadas para serem desafiadoras e relevantes para cada domínio. 3
Em janeiro de 2026, foi lançado o RelBench v2, adicionando quatro novos bancos de dados (SALT, RateBeer, arXiv e MIMIC-IV) e 40 tarefas preditivas adicionais, incluindo uma nova classe de tarefas de autocompletar que avaliam a capacidade de um modelo de prever colunas existentes em um banco de dados relacional.
A versão também expandiu o acesso a dados por meio da integração com o CTU, permitindo o acesso a mais de 70 conjuntos de dados relacionais via ReDeLEx; adicionou conectividade direta com bancos de dados SQL; e incorporou sete conjuntos de dados do repositório 4DBInfer no formato RelBench.
Além de conjuntos de dados e tarefas, o RelBench fornece uma implementação de referência de código aberto para aprendizado profundo relacional baseado em redes neurais gráficas, usando PyTorch Geometric para construção de grafos e PyTorch Frame para modelagem tabular , juntamente com um ranking público para acompanhar o progresso.
A versão 2 também introduziu diversas melhorias de usabilidade e desempenho, incluindo rótulos opcionais com censura temporal, suporte à métrica NDCG na previsão de links, geração mais rápida de incorporação de sentenças e gerenciamento de cache configurável. 4
VIEIRA
VIEIRA adota uma abordagem diferente, focando na programação com modelos de base em vez de construir um único mecanismo preditivo. Ele estende o compilador de lógica probabilística SCALLOP com uma linguagem declarativa que integra grandes modelos de linguagem , modelos de visão e outros componentes pré-treinados como predicados externos . 5
Paradigma relacional
Em VIEIRA, os modelos de base são tratados como funções sem estado com entradas e saídas relacionais. Isso permite compor modelos como GPT, CLIP ou SAM de acordo com regras lógicas. Por exemplo:
- Um programa pode usar GPT para extrair conhecimento de um texto e armazená-lo como relações estruturadas.
- O CLIP consegue classificar imagens e associá-las a rótulos textuais em uma tabela.
Aplicações
A estrutura suporta:
- Raciocínio lógico e matemático usando GPT.
- Raciocínio de parentesco usando extração de texto e inferência lógica.
- Respostas a perguntas que combinam recuperação de informações e raciocínio.
- Respostas visuais a perguntas e edição de imagens por meio de composição multimodal.
Ao unificar a lógica simbólica e a inferência neural, o VIEIRA permite que analistas de dados e desenvolvedores criem sistemas interpretáveis que utilizam modelos básicos pré-treinados para responder a consultas preditivas sobre dados estruturados e imagens.
Estudos de caso
SAP Hana Cloud
O SAP HANA Cloud é um banco de dados nativo da nuvem, totalmente gerenciado e oferecido como serviço (DBaaS), projetado 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 um banco de dados relacional de propósito único, o SAP HANA Cloud se posiciona como uma plataforma multimodelos que permite às organizações criar "aplicações de dados inteligentes" com base em dados operacionais de negócios.
O SAP HANA Cloud combina processamento em memória com armazenamento em disco e integração com data lakes para atender a diferentes requisitos de desempenho e custo. Esse design flexível suporta cargas de trabalho em tempo real, escalando dinamicamente conforme os volumes de dados e o uso flutuam.
Um diferencial fundamental é seu mecanismo nativo multimodelos, que suporta dados relacionais, JSON/documentos, grafos, dados espaciais e vetores em um único banco de dados. Isso permite que os aplicativos combinem consultas SQL, relacionamentos em grafos e buscas por similaridade vetorial sem precisar mover dados entre sistemas separados, simplificando a arquitetura e reduzindo a latência.
Como parte da plataforma SAP Business Technology Platform, o SAP HANA Cloud integra-se diretamente com fontes de dados SAP e não SAP, incluindo acesso em tempo real sem replicação, e fornece segurança, disponibilidade e conformidade de nível empresarial por padrão.
Em resumo, o SAP HANA Cloud é uma plataforma de dados centrada em relacionamentos e nativa de IA, na qual o banco de dados relacional serve como camada fundamental para análises, dados multimodelos e aplicações de IA corporativas.
Figura 2: Imagem mostrando o banco de dados unificado de Hana e
Processamento de dados multimodelos. 6
sap-rpt-1 da SAP
O sap-rpt-1 introduz um modelo relacional único que executa uma ampla gama de tarefas preditivas por meio de aprendizado contextual. Em vez de treinar um novo modelo para cada caso de uso, os usuários fornecem alguns exemplos do padrão desejado, como "clientes que pagaram em dia" e "clientes que pagaram com atraso". O modelo então reconhece o padrão e produz imediatamente previsões precisas para novos dados.
O modelo foi projetado com um mecanismo de atenção bidimensional que captura relações entre linhas e colunas, incorporando também metadados, como nomes de tabelas e colunas, em vetores de incorporação. Esse design permite que ele compreenda a semântica de esquemas relacionais e as informações temporais dentro das tabelas de negócios.
A abordagem da SAP traz diversas vantagens para analistas de dados e usuários de negócios:
- Um modelo único que funciona em várias tabelas e domínios.
- Não há necessidade de ajustes finos repetidos ou desenvolvimento personalizado.
- Acesso a informações preditivas em minutos, em vez de semanas.
- Integração com data warehouses e sistemas SAP existentes.
Ao integrar o sap-rpt-1 ao ecossistema SAP, os 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 dos dados estruturados para decisões práticas, sem a necessidade de engenharia manual de recursos.
Figura 3: Fator de redução de erros das linhas de base sap-rpt-1-large versus narrow-AI em todos os domínios SAP.
No final de 2025, a SAP confirmou que o SAP-RPT-1 está disponível ao público em geral por meio do hub de IA generativa no SAP AI Foundation (SAP AI Core).
O modelo é oferecido em duas variantes de produção:
- SAP-RPT-1-small, otimizado para previsões de baixa latência e alto rendimento,
- SAP-RPT-1-large, projetado para priorizar a precisão preditiva.
Esta versão formaliza o papel do SAP-RPT-1 como um modelo básico implementável dentro da plataforma de IA empresarial da SAP, em vez de uma capacidade exclusiva para pesquisa.
Além disso, a SAP oferece o SAP-RPT Playground, um ambiente baseado na web e sem código , onde os usuários podem testar o aprendizado contextual usando seus próprios dados de amostra ou dados de amostra fornecidos pela SAP.
SAP-ABAP-1
O SAP-ABAP-1 é um modelo básico projetado para dar suporte a casos de uso de produtividade de desenvolvedores baseados em IA para clientes e parceiros da SAP.
Está disponível através do hub de IA generativa da SAP e foi treinado com 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 entender e explicar o código ABAP, destacar as melhores práticas e fornecer acesso a conhecimento atualizado sobre desenvolvimento SAP.
A SAP oferece acesso experimental gratuito ao SAP-ABAP-1 por meio do hub de IA generativa, com recursos adicionais planejados para lançamento em 2026. 7
KumoRFM da Kumo.AI: um transformador de grafos relacionais para análise preditiva.
A Kumo.AI, fundada pelo professor de Stanford Jure Leskovec, criou o KumoRFM, um modelo de fundamentos relacionais que utiliza um transformador de grafos relacionais 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 as tabelas.
Essa abordagem baseada em grafos permite que o KumoRFM aprenda com várias tabelas simultaneamente e se adapte a novos esquemas relacionais. O modelo é pré-treinado em diversas fontes de dados e pode generalizar para novos conjuntos de dados sem a necessidade de construir modelos separados para cada tarefa preditiva.
O KumoRFM pode ser utilizado através 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 em linguagem natural: Para usuários não técnicos, as entradas em linguagem natural são traduzidas automaticamente em consultas PQL.
- SDK Python: Permite que os desenvolvedores integrem o modelo em fluxos de trabalho e aplicativos de IA corporativos.
A arquitetura KumoRFM realiza amostragem dinâmica do banco de dados para criar subgrafos de contexto e subgrafos de previsão. Esses subgrafos são processados pelo transformador de grafos relacionais, que captura dependências e informações temporais entre entidades relacionadas. Por meio do aprendizado contextual, o modelo fornece previsões precisas e consegue explicar seu processo de raciocínio.
O Kumo oferece duas opções de implantação adequadas para ambientes corporativos:
- Plataforma SaaS: Um serviço baseado em nuvem, construído sobre o Apache Spark, para fácil acesso e escalabilidade.
- Nativo do data warehouse: Permite que as organizações usem seus próprios dados em Snowflake ou Databricks sem precisar movê-los para fora de seu ambiente seguro.
Ao contrário dos grafos de conhecimento tradicionais que exigem a definição manual de esquemas, o KumoRFM constrói automaticamente seu grafo relacional a partir de fontes estruturadas. Isso o torna ideal para comércio eletrônico, finanças e saúde , onde relacionamentos, padrões temporais e contexto em constante evolução são essenciais para previsões confiáveis.
As principais funcionalidades do KumoRFM incluem:
- Flexibilidade em diferentes tabelas e estruturas de esquema.
- Compatibilidade com diversos 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 Fundamentos Relacionais (RFMs) funcionam em múltiplos domínios, como comércio eletrônico, finanças e saúde, para fazer previsões, fornecer explicações e avaliar resultados. 8
Metodologia de referência
Configuração e ambiente de referência
Para garantir comparações justas entre árvores de decisão com uso intensivo de CPU e modelos acelerados por GPU, utilizamos um ambiente de alto desempenho capaz de lidar com ambos de forma eficiente.
- Hardware: Instância RunPod com uma GPU NVIDIA H200 de 140 GB .
- Software: Python 3.12 com bibliotecas fixadas para fins de 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: o parâmetro random_state=42 foi usado de forma consistente em todas as divisões, inicializações e modelos.
Conjuntos de dados: O espectro semântico
Avaliamos os modelos em 17 conjuntos de dados de aprendizado supervisionado provenientes do OpenML e do Scikit-Learn. Em vez de uma seleção aleatória, selecionamos esse conjunto para abranger o "Espectro Semântico-Numérico", testando a hipótese de que os Modelos de Aprendizado Linguístico (LLMs) se destacam quando os recursos contêm significado linguístico em vez de apenas estatísticas brutas.
O inventário:
- Pequeno e semântico (<1K linhas):
- vinho (178), sonar (208), voto (435), faixas_cilíndricas (540), câncer_de_mama (569).
- Nível médio/misto (1.000 a 10.000 carreiras):
- credit_g (1K), titanic (1,3K), car_evaluation (1,7K), spambase (4,6K), compas (5,2K), employee_salaries (9,2K).
- Grandes/numéricos (mais de 10 mil linhas):
- habitação_californiana (20 mil), vendas_de_casas (21 mil), crédito_inadimplente (30 mil), renda_adulta (48 mil), diamantes (53 mil), higgs (amostrado para 100 mil).
Tarefas incluídas:
- 11 tarefas de classificação binária
- 2 tarefas de classificação multiclasse
- 4 Tarefas de regressão
Configurações e pré-processamento do modelo
Nosso objetivo era uma "comparação prática" realista, utilizando configurações padrão robustas em vez de um ajuste exaustivo de hiperparâmetros.
LightGBM e CatBoost
Para garantir uma comparação justa com o modelo SAP, que exige alto poder computacional, aumentamos os estimadores de inadimplência robustos.
- LightGBM: n_estimators=500, learning_rate=0.05, num_leaves=31. Executa na CPU (n_jobs=-1).
- CatBoost: iterações=500, taxa_de_aprendizado=0,05, profundidade=6. Executado na GPU (tipo_de_tarefa=”GPU”).
- Pré-processamento: Codificação simples de rótulos para variáveis categóricas; sem escalonamento para variáveis numéricas; imputação por 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: Os testes com adult_income mostraram que o aumento do contexto de 4096 para 8192 triplicou o tempo de execução (de 4 min para 12 min) com um ganho de precisão insignificante (0,917 vs 0,917 ROC-AUC).
- Ensacamento: Aumentar o ensacamento de 4 para 8 (configuração padrão da SAP usada no artigo). 9 ) 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
Utilizamos validação cruzada de 3 vias com embaralhamento.
- Reduzimos a multiplicação padrão de 5 para 3 vezes para acomodar os tempos de inferência lentos do SAP (economia de tempo de 40%), 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ário), Precisão Balanceada (Multiclasse), R² (Regressão).
- Diagnóstico secundário: Monitoramos o coeficiente de correlação de Matthews (MCC) e a perda logarítmica para garantir que os resultados positivos não fossem artefatos de desequilíbrio de classes, e o MAPE para calibração do erro de regressão.
- Cálculo de custos: Baseado no tempo total de execução (pré-processamento + treinamento + inferência) na instância RunPod H200 (US$ 3,59/hora).
Significância estatística
Aplicamos o teste de Wilcoxon com sinais ordenados (p<0,05) às comparações de pares de modelos 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 limitações em nossa metodologia:
- Configurações padronizadas versus otimização: Utilizamos configurações padrão fixas e robustas para todos os modelos, em vez de realizar uma otimização exaustiva de hiperparâmetros (por exemplo, validação cruzada aninhada ou varreduras do Optuna). Embora isso garanta uma base de referência consistente, vale ressaltar que os modelos de árvore geralmente apresentam ganhos de desempenho com a otimização específica para cada conjunto de dados, o que pode reduzir as margens no cluster "Competitivo".
- Limitações de escala de dados: Nossa análise se concentrou em conjuntos de dados com menos de 100 mil linhas para simular cenários típicos de empresas de médio porte. Observamos que a vantagem do LLM diminuiu à medida que o volume de dados aumentou, mas não estendemos os testes para escalas de milhões de linhas, onde a latência e o custo da inferência provavelmente se tornariam as principais restrições.
- Uniformidade da infraestrutura: Para manter um ambiente de teste consistente, executamos todos os modelos no mesmo hardware 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, a diferença de custo provavelmente seria maior.
- Generalização além da semântica: Nossa hipótese de "Espectro Semântico" previu com sucesso muitos resultados, mas o excelente desempenho do LLM em conjuntos de dados abstratos como sonar e california_housing sugere capacidades que vão além da compreensão linguística. Isso indica que o modelo também pode estar utilizando padrões de regularização de alta dimensão, um fenômeno que justifica uma investigação mais aprofundada além do escopo deste estudo inicial.
Links de referência
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios.