Vinte anos fazendo a mesma conta do zero
Existe um tipo de dado que quase nunca aparece nas notícias de inteligência artificial, mas que sustenta praticamente tudo o que uma empresa faz: a tabela. É a planilha de clientes, o extrato de transações, o histórico de pedidos, a lista de chamados do suporte, o cadastro de inadimplentes. Quando alguém pergunta "quem vai cancelar o plano no mês que vem?" ou "qual cliente vai atrasar o pagamento?", a resposta quase sempre mora numa tabela.
Durante uns vinte anos, o jeito de responder isso foi sempre o mesmo: pegar os dados, escolher as colunas que importam, criar variáveis novas na mão, testar dezenas de combinações de parâmetros, validar e só então colocar o modelo no ar. Uma ferramenta chamada árvore de decisão com reforço por gradiente — nomes como XGBoost e LightGBM — faz esse trabalho muito bem e continua sendo o padrão da indústria. O problema não é o resultado: é o processo. Cada pergunta nova exige começar tudo de novo, porque o modelo que você treinou ontem não sabe absolutamente nada sobre tabela nenhuma. Ele aprendeu aquela tarefa específica, do zero, e só ela.
Em 29 de setembro de 2026, a NVIDIA publicou uma alternativa a esse ciclo. Chama-se Kumo Tabular e a proposta é desconfortavelmente simples: em vez de treinar um modelo para cada pergunta, você entrega uma tabela com exemplos já respondidos e as linhas que quer prever. O modelo lê tudo numa passada só e devolve a resposta.
A ideia: mostrar o gabarito em vez de treinar
Quem acompanha a área já viu esse movimento nos modelos de texto. Você não treina um modelo de linguagem para cada tarefa: escreve alguns exemplos no próprio pedido e o modelo resolve, sem alterar um único peso. Isso tem nome — aprendizado no contexto — e a NVIDIA aposta que vale igualmente para tabelas.
Na prática, funciona assim: você separa uma parte da sua planilha que já tem a resposta (por exemplo, 300 clientes que você sabe que cancelaram) e manda junto com as linhas que ainda não têm resposta. O modelo usa as primeiras como referência e preenche as segundas. Sem treinar. Sem ajustar parâmetros. Sem criar variável nenhuma. Do ponto de vista de quem usa, a diferença é comparável a trocar "contratar um estagiário para montar o modelo" por "colar um pedaço da planilha num programa".
A família vem em três tamanhos, e o que chama atenção é o tamanho deles para o que entregam:
| Versão | Parâmetros | Tabelas artificiais usadas no treino |
|---|---|---|
| Kumo Tabular-Small | 28 milhões | ~35 milhões |
| Kumo Tabular-Medium | — | ~71 milhões |
| Kumo Tabular-Large | 215 milhões | ~137 milhões |
Para efeito de comparação: os grandes modelos de linguagem que a gente comenta aqui normalmente passeiam entre centenas de bilhões e trilhões de parâmetros. O Kumo Tabular-Large inteiro é 215 milhões. É um modelo que cabe com folga numa única placa de vídeo profissional — e, segundo a NVIDIA, foi exatamente assim que ela mediu os resultados, com uma única RTX 6000 Pro.
Ele foi treinado só com tabelas que nunca existiram
Aqui está a parte que eu acho mais interessante — e que costuma gerar confusão.
O Kumo Tabular nunca viu uma tabela real de empresa nenhuma. Ele foi treinado inteiramente com tabelas artificiais, geradas por um programa. E não é dado aleatório jogado junto: cada tabela é construída a partir de um modelo causal estrutural, uma receita que desenha variáveis escondidas, liga uma na outra com funções sorteadas (retas, redes neurais pequenas, árvores, processos gaussianos), escolhe qual delas vira a coluna que se quer prever e deixa as outras ocultas — exatamente como as causas não medidas por trás de dados reais. Depois, o gerador estraga de propósito o que ia ficar limpo demais: cria valores faltando, embaralha categorias, engrossa as caudas, arredonda números e descarta qualquer tabela em que não haja sinal aprendível.
Como é um gerador de receitas, e não um banco de dados fixo, ele produz tabelas novas para sempre, cada uma com um grafo e um mecanismo diferentes. O modelo viu cerca de 137 milhões delas na maior versão.
Isso muda a natureza do produto. Um modelo treinado em tabelas reais de bancos e seguradoras americanas carrega os vícios dessas tabelas: as colunas que elas têm, a distribuição que elas têm, o tipo de cliente que elas descrevem. Um modelo treinado em tabelas artificiais foi treinado no formato da tabela, não no conteúdo. Ele não sabe o que é "renda mensal" — sabe o que é "coluna numérica que se comporta assim". É uma diferença conceitual grande, e é a razão pela qual ele consegue encostar numa planilha de qualquer setor sem nunca ter visto uma.
Como ele lê uma linha
Por dentro, o Kumo Tabular é um Transformer — a mesma família de arquitetura que está por trás dos modelos de texto —, mas construído em volta da estrutura de uma tabela. Ele faz três perguntas ao mesmo tempo:
- O que este valor significa dentro da coluna dele? Se a coluna é "idade" e o valor é 42, isso é normal ou extremo? Ele descobre olhando para baixo, na coluna inteira.
- Como as colunas de uma mesma linha conversam entre si? Uma linha vira um "resumo" depois de várias rodadas alternando entre olhar para a coluna e olhar para a linha.
- Como as linhas com resposta se relacionam com as linhas sem resposta? Aqui entra o aprendizado no contexto: as linhas que você já conhece servem de referência para as que faltam.
Tem um detalhe técnico bonito aqui. Atenção em modelos desse tipo tende a "se dissolver" quando a tabela cresce: o que era nítido com 200 linhas fica difuso com 50 mil. A NVIDIA resolveu isso com um truque chamado temperatura de atenção sensível ao comprimento: a cada previsão, o modelo reajusta a nitidez da atenção conforme o logaritmo do número de linhas na mesa. Traduzindo: ele continua enxergando bem tanto numa planilha de vendas de um mês quanto num histórico de anos.
Outro detalhe que importa para quem já sofreu com isso: valores faltando não precisam de remendo. O modelo foi treinado para aceitar buracos e tratá-los como informação, em vez de obrigar alguém a inventar uma média para preencher a célula.
O placar
Segundo a NVIDIA, o Kumo Tabular ficou em primeiro lugar em quatro comparações públicas de modelos tabulares — TabArena, BeyondArena, TALENT e ScoringBench. No TabArena, com as configurações de fábrica, ele somou ELO 1950 rodando 17 vezes mais rápido que o LimiX-2 nas mesmas condições. No BeyondArena, ELO 1418. No TALENT, liderou acurácia de classificação, perda logarítmica e erro de regressão. No ScoringBench, que mede a qualidade das distribuições de previsão, as versões Large e Medium ficaram em primeiro e segundo lugar.
Como sempre, vale o ceticismo padrão deste blog: esses números são da NVIDIA, no benchmark da própria NVIDIA, com uma única configuração de hardware. E "primeiro lugar no leaderboard" não é a mesma coisa que "melhor na sua planilha".
O que ele não é
A própria NVIDIA lista os limites, e isso merece ficar no post porque é o tipo de detalhe que some das manchetes:
- Só entende colunas numéricas e categóricas. Texto, imagem e data/hora não são compreendidos — precisam virar número antes, por receitas de pré-processamento.
- Numa única passada, ele cobre até 10 classes. A biblioteca resolve o resto com uma técnica de código corretor de erro, mas é bom saber que existe esse teto.
- A precisão pode cair se a tabela for muito maior do que as vistas no treino (a faixa vai até ~60 mil linhas e 100 colunas) ou se as linhas que você quer prever vierem de uma realidade diferente das linhas de exemplo.
- E a recomendação explícita: valide no seu próprio dado antes de colocar em produção. Vale como aviso — e vale como princípio.
Como usar
O modelo de pesos está no Hugging Face e funciona pela biblioteca structured-data-models, de código aberto sob licença Apache 2.0. Os pesos seguem a licença OpenMDW 1.1, que permite uso comercial. Precisa de Python 3.11 ou mais novo e PyTorch 2.7 ou mais novo; na prática roda em GPU, e a NVIDIA recomenda colocar o cuDF junto para não ficar passeando de dado entre placa e memória.
Da planilha à resposta são poucas linhas:
pip install structured-data-models
import sdm
table = sdm.TableTensor.from_pandas(df, stypes=sdm.infer_stypes(df, overrides={"target": "categorical"}), device="cuda")
model = sdm.models.KumoTabular(task="classification", device="cuda")
probs = model(x_context=table[:300].drop_columns("target"), y_context=table[:300, "target"], x_query=table[300:].drop_columns("target"), num_estimators=8)
Vale olhar a família inteira do repositório: além do Kumo Tabular, ele reúne o TabICLv2, o TabFM (do Google Research) e o KumoRelational, que trabalha com dados relacionais — várias tabelas ligadas por chave, que é como os dados vivem de verdade dentro de uma empresa. Isso é o mais perto que a área chegou de "o mesmo modelo genérico, mas para banco de dados".
Por que isso conversa direto com o Brasil
Se tem uma coisa que o tecido empresarial brasileiro tem de sobra, é tabela. Meio milhão de pequenos e médios negócios operando em cima de uma planilha, um ERP apertado e um caderno. Churn, inadimplência, propensão de compra, previsão de demanda, risco de crédito, fila de cobrança — tudo isso é o mesmo tipo de problema, e nenhum deles é um problema de texto.
Só que montar um modelo desses sempre exigiu uma pessoa que soubesse fazer isso, e essa pessoa custa caro e está empregada em outro lugar. A promessa do Kumo Tabular é justamente encurtar essa etapa: em vez de "precisamos de um cientista de dados para o projeto", você fica com "precisamos validar se isso funciona com o nosso histórico". A primeira pergunta é sobre contratação. A segunda é sobre planilha — e quase toda empresa consegue responder a segunda.
Há ainda o argumento que interessa a quem lida com dados de gente: o modelo pode ser baixado e rodado dentro da sua própria infraestrutura. Não é obrigatório mandar o cadastro dos seus clientes para a nuvem de outra empresa para descobrir quem tende a cancelar. Depois do que aconteceu em setembro — agentes escapando de sandbox, imagens derrubando sistemas internos —, poder dizer "esse dado nunca saiu daqui" deixou de ser um detalhe técnico e virou argumento comercial.
A parte que fica
O Kumo Tabular não é um modelo melhor de conversar nem de programar. Ele resolve algo bem menos glamouroso e muito mais presente: prever uma coluna de uma tabela. Mas é justamente aí que está a maior parte do trabalho não feito no mundo. Setores inteiros — seguros, saúde, varejo, crédito, logística — rodam sobre planilhas que ninguém nunca conseguiu transformar em previsão, porque o custo de montar o modelo era maior do que o valor da resposta.
Quando esse custo cai de "projeto de três meses com especialista" para "colar um trecho da planilha", muda o que passa a ser economicamente razoável perguntar. E é assim que tecnologia deixa de ser novidade e começa a virar rotina — que é exatamente quando ela fica interessante.