NVIDIA Kumo Relational supera ML supervisionado em 41 tarefas sem treinamento

A NVIDIA publicou o Kumo Relational, um modelo foundation relacional pré-treinado que faz previsões diretamente sobre o banco de dados corporativo. O usuário descreve o que quer prever e recebe o resultado em uma única passada direta, sem treinamento específico para a tarefa, sem agregados manuais e sem achatar as tabelas. Em 41 tarefas de 15 bancos de dados, o modelo superou modelos supervisionados e gradient boosting com features de especialistas. No SAP SALT, ele fica 8% à frente dos grandes ensembles do AutoGluon em mean reciprocal rank. Entre os autores estão Jure Leskovec e Matthias Fey, e o trabalho foi feito em conjunto com a equipe da Kumo.

Previsão como consulta, e não como projeto

O caminho habitual para uma tarefa como churn de clientes leva semanas. Os engenheiros calculam o "ticket médio dos últimos 30 dias", juntam users, orders e products em uma única linha, configuram o XGBoost e mantêm o pipeline. O Kumo Relational funciona de outro jeito: ele lê tabelas, chaves estrangeiras e timestamps como estão. A tarefa é formulada em Predictive Query Language, por exemplo `PREDICT COUNT(orders.*, 0, 30, days) FOR EACH users.user_id`.

O próprio sistema monta o contexto. Ele pega exemplos históricos, recorta em torno de cada entidade um subgrafo local no momento de referência e anexa o desfecho conhecido, como "o usuário saiu" ou "o produto vendeu 142 unidades". Nas tarefas temporais, o banco é reproduzido a partir dos estados históricos: o modelo enxerga apenas os dados anteriores ao timestamp-âncora, e o alvo é calculado a partir dos eventos posteriores a ele. O vazamento de dados do futuro é impossível por construção.

A arquitetura tem dois estágios. Uma rede leve processa cada tabela separadamente, com column attention e row attention, e filtra o ruído. Em seguida, uma rede maior propaga os embeddings das linhas pela estrutura do banco por meio de graph attention sobre as relações de chaves primárias e estrangeiras, e depois aplica cross-sample attention entre os exemplos de contexto. Como o segundo estágio opera sobre embeddings de linhas, e não sobre cada célula, não há custo quadrático, e contextos com subgrafos profundos continuam viáveis.

Dados sintéticos no lugar de bancos fechados

Quase não há bancos relacionais diversos em acesso aberto para pré-treinamento, por isso o modelo foi treinado inteiramente com dados sintéticos. O gerador se baseia no PluRel (Kothapalli et al., ICML 2026) e constrói o banco em três etapas: esquema, relações entre linhas com agrupamento realista e valores de colunas a partir de modelos causais estruturais, com tendências temporais e dependências entre tabelas. A geração é barata, então a quantidade de dados para pré-treinamento é praticamente ilimitada. A loss cai segundo uma lei de potência à medida que mais bancos são adicionados, e o ganho se transfere para dados reais. O treinamento é feito em etapas: de tabelas isoladas a estruturas relacionais complexas.

A avaliação usou conjuntos de dados que o modelo nunca viu: RelBench V1 e V2, SAP SALT e 4DBInfer. Eles cobrem e-commerce, saúde, dados corporativos, redes sociais e dados acadêmicos.

• 41 tarefas em 15 bancos de dados relacionais.
• RelBench V1, classificação: cerca de 4 pontos de AUROC acima do gradient boosting com features de especialistas.
• SAP SALT: 7 pontos de MRR acima do XGBoost com features de engenharia prontas para uso (out of the box) e 13 pontos após ajuste fino.
• SAP SALT contra os grandes ensembles do AutoGluon: mais 8% de MRR, e mais 16% após fine-tuning.
• RelArena-α (leaderboard em 21.09.2026): o modelo está na fronteira de Pareto entre precisão e velocidade, cerca de 430 vezes mais rápido que o rtl-plurel com precisão comparável.
• Robustez: funciona com 0,2% dos dados de treinamento no contexto, se mantém mesmo com a remoção de até 75% das relações por chave estrangeira e quase não se degrada com a adição de colunas de ruído.
• Escala: o kumo-engine processa bancos com mais de 500 bilhões de linhas por meio de memory-mapped I/O, a até 5 GB/s.

Os próprios autores apontam as limitações. O modelo funciona melhor onde há relações significativas e dinâmica temporal, como no comportamento de usuários. Em tarefas com amostras de treinamento muito grandes, modelos supervisionados especializados podem levar vantagem. O sinal preditivo precisa estar dentro de um número limitado de saltos pelas relações.

Como executar e onde economizar

A principal economia aqui está nas horas de engenharia, e não nos tokens. Em vez de um pipeline separado para cada tarefa, há um único modelo e um conjunto de consultas. Uma nova previsão vira uma linha de PQL, e as equipes podem encarar cenários que antes não pagavam o custo de desenvolvimento. Para agentes, o PQL funciona como uma interface simples: o LLM lê e raciocina, e o Kumo Relational entrega a previsão, por exemplo qual cliente vai abandonar o serviço.

Há três formas de executar. A primeira é a biblioteca aberta nativa para GPU structured-data-models (`pip install structured-data-models`), em que `sdm.models.KumoRelational(device="cuda")` recebe tabelas de contexto, tabelas de consulta e tabelas relacionadas. Os pesos são baixados do Hugging Face Hub no primeiro uso. A segunda é o deploy como NVIDIA NIM com o cliente structured-data-models-client, em que a consulta PQL e o pandas DataFrame viram contexto automaticamente. O repositório traz notebooks para NIM local e para Databricks. A terceira é o kumo-engine, com conectores para bancos de dados e data warehouses em grandes volumes.

O código está publicado sob Apache 2.0, e os pesos, sob a OpenMDW License Agreement 1.1. O teste prático é simples: pegue uma tarefa de produção rodando em XGBoost, como churn ou demanda, execute-a no Kumo Relational e compare as métricas e o tempo de desenvolvimento. Se o sinal nos dados está a alguns saltos de chaves de distância, é provável que dê para substituir o pipeline.