O momento GPT-3 do Google para bancos de dados e planilhas (TabFM)

Autoria: Prompt Engineering · Assistir no YouTube

Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.

Idioma original: inglês

Vídeo original: Google’s GPT-3 Moment for Databases & Spreadsheets (TabFM) · Canal: Prompt Engineering · 10:45 · Assistir no YouTube

Tópicos: Agentes de IA, Avaliação e benchmarks de IA, Dados, bancos de dados e embeddings, Modelos de IA

Resumo

O vídeo apresenta o TabFM, um modelo de fundação do Google Research para dados tabulares que prevê rótulos usando exemplos rotulados, sem precisar ser treinado nos dados específicos de cada empresa. O apresentador demonstra um fluxo de previsão de churn com dados no Postgres, usando TabFM e um agent para interpretar colunas e preparar o pipeline. Ele destaca limitações do modelo, como a falta de compreensão semântica das colunas, e riscos de vazamento de dados. A demonstração usa branches isoladas do Neon para testar previsões com segurança e evitar que dados de produção sejam alterados.

Pontos-chave

O TabFM usa linhas rotuladas como contexto para prever rótulos de linhas sem rótulo, sem treinamento específico no conjunto de dados.
O modelo foi treinado com dados sintéticos gerados a partir de grafos causais, aprendendo a identificar padrões em tabelas.
Em uma demonstração de previsão de churn, o TabFM superou um modelo de árvores ajustado, sem engenharia de atributos, embora tenha obtido uma pontuação de 0,60.
O TabFM não compreende por si só o significado das colunas nem a semântica de valores codificados.
Um LLM pode ajudar um agent a interpretar nomes e descrições de colunas, transformar dados e calibrar previsões.
O apresentador criou uma implementação própria inspirada no TabFusion Auto, usando Opus 5.5 e Gemini como orquestrador.
Branches isoladas do Neon permitem que o agent experimente sem modificar o banco de produção.
É essencial controlar o vazamento de dados e reconstruir o estado do banco no momento em que a previsão teria sido feita.
O TabFM é disponibilizado apenas para pesquisa não comercial, segundo o vídeo.

Capítulos

Início	Capítulo	Resumo
00:00	Por que dados tabulares precisam de outra abordagem	O vídeo contrasta o uso de LLMs em texto com os métodos tradicionais usados para prever resultados em tabelas e apresenta o TabFM.
02:06	Como o TabFM aprende com dados sintéticos	O apresentador explica o treinamento com tabelas sintéticas, a restrição de uso não comercial e a demonstração de previsão de churn.
04:47	Limitações semânticas e o papel do LLM	O TabFM trata valores como números sem compreender o significado das colunas, enquanto um LLM pode ajudar a preparar e calibrar o pipeline.
06:25	Branches isoladas e prevenção de vazamento	A demonstração usa branches do Neon para proteger a produção e reconstruir o estado dos dados anterior ao período de previsão.
09:06	Execução recorrente e principais conclusões	O apresentador mostra como agendar previsões de churn e resume a importância dos dados como contexto, da semântica e de um backend seguro.

Citações

Tabelas nunca tiveram esse momento até agora. — 01:33

Seu conjunto de dados é literalmente o prompt agora. — 02:06

Não há treinamento envolvido. — 04:15

Se você vai deixar um agent fazer ciência de dados, dê a ele um backend real para trabalhar. — 10:15

Conceitos e entidades

TabFM (modelo): Modelo de fundação apresentado no vídeo para fazer previsões em dados tabulares a partir de exemplos rotulados.
TabFusion Auto (modelo): Arquitetura mencionada que combina um modelo tabular congelado com um LLM que coordena o pipeline.
Google Research (empresa): Grupo de pesquisa que apresentou o TabFM.
Neon (ferramenta): Serviço de Postgres usado na demonstração para armazenar dados e criar branches isoladas para experimentos.
PostgreSQL (ferramenta): Banco de dados usado para armazenar os dados tabulares e os resultados das previsões.
Gemini (modelo): Modelo usado como orquestrador na implementação criada pelo apresentador.
Opus 5.5 (modelo): Modelo que o apresentador usou para criar uma implementação própria da arquitetura.
DGX Spark (ferramenta): Equipamento local no qual o apresentador executa o TabFM e processa tarefas da demonstração.
vazamento de dados (conceito): Uso inadvertido de informações que só estariam disponíveis depois do período em que a previsão deveria ser feita.

Tradução completa (pt-BR)

00:00 Certo, todo mundo está obcecado com LLMs agora, mas quase todo esse burburinho é sobre agents de programação e chatbots. E os LLMs são realmente ótimos para isso, mas, se você olhar para o que as empresas de verdade usam, não são textos. São tabelas tradicionais. Isso inclui coisas como transações, cancelamentos de clientes, registros de sensores, reclamações de fraude e talvez dados relacionados a estoque. E, sempre que você precisa prever algo a partir de uma tabela, não pode simplesmente usar um LLM. Hoje, as pessoas ainda recorrem a métodos tradicionais e

00:32 clássicos de machine learning. Mas o problema é que cada novo problema exige treinar um modelo totalmente novo do zero. Hoje, vou mostrar um modelo que pode acabar completamente com esse fluxo de trabalho. Depois, vou mostrar como integrá-lo a um agent autônomo de ciência de dados que está funcionando em um backend ativo. Pessoalmente, passei anos criando modelos preditivos para dados tabulares e séries temporais. A receita geralmente

01:02 é mais ou menos assim: você precisa limpar os dados, depois passar muito tempo criando recursos manualmente, então treina um modelo clássico de machine learning, especialmente modelos do tipo árvores impulsionadas por gradiente, ajusta os hiperparâmetros e, depois, repete todo esse trabalho do zero para o próximo conjunto de dados. Antes, trabalhar com texto era igualmente complicado. Você treinava um modelo para análise de sentimento, depois precisava de outro modelo para classificação de spam e ainda de outro modelo

01:33 para tradução. Mas então o GPT-3 foi lançado e, de repente, você não precisava mais treinar modelos separados. Bastava mostrar alguns exemplos a um modelo de fundação no prompt, e ele descobria tudo magicamente. As tabelas nunca tiveram esse momento, até agora. Recentemente, o Google Research lançou o TabFM, um modelo de fundação criado exclusivamente para dados tabulares. Mas aqui vem a parte incrível: você não precisa treinar esse modelo com o seu próprio conjunto de dados. A ideia é simplesmente passar as linhas

02:06 cujos rótulos você já conhece e, em seguida, acrescentar as linhas sem rótulo cujos valores quer prever. Então, ele usa os dados rotulados e infere a resposta em uma única passagem sobre os dados sem rótulo. Ou seja, seu conjunto de dados agora é literalmente o prompt. Essencialmente, isso se torna um modelo de fundação geral para dados tabulares. Mas como, exatamente, o Google fez isso? A equipe de pesquisa por trás do modelo o treinou inteiramente com um fluxo interminável de dados sintéticos, que eram essencialmente tabelas sintéticas. Para cada uma, eles amostram uma

02:38 tag causal aleatória, geram linhas a partir dela e forçam o modelo a prever células ocultadas. O interessante é que ele não consegue memorizar um conjunto de dados específico. Na verdade, ele aprende o meta-algoritmo de como aprender com tabelas. Se você já trabalhou em qualquer tipo de empresa, sabe que os dados tabulares são essenciais em toda organização, e foi por isso que quis criar este vídeo. Um aviso rápido: os pesos do Tab FM atualmente só podem ser usados em pesquisas não comerciais. Então, considere isto um projeto de arquitetura, e não um código pronto para produção que você possa usar.

03:11 Certo, vou mostrar alguns exemplos ao vivo, mas o modelo de fundação é só metade da história. A outra metade é onde estão seus dados ativos. E precisamos dar a um agent um ambiente que ele possa realmente processar e usar. É aí que entra a patrocinadora de hoje, Neon. A Neon oferece Postgres serverless com ramificações instantâneas, autenticação, armazenamento e funções em um só lugar. Nessa arquitetura, os

03:45 dados ficam no Postgres da Neon. O Tab FM roda localmente no meu DGX Spark, e nosso agent vai executar consultas diretamente no mecanismo do banco de dados. Certo, antes de entrar nos detalhes, vamos ver um exemplo simples. Aqui estão dados sintéticos de uma empresa SaaS que eu produzi. Eles incluem informações como perfil do cliente, uso do produto, faturas e tíquetes de suporte. O objetivo é prever quais clientes vão cancelar.

04:15 Nesse caso, buscamos a tabela bruta de clientes da Neon. Alimentamos o Tab FM com o histórico dos rótulos. Vou mostrar como fazer isso mais adiante no vídeo, e pedimos que ele atribua pontuações aos usuários restantes. Portanto, não há nenhum treinamento envolvido. O modelo nos dá uma pontuação inferida de risco de cancelamento para cada cliente, e esses dados são gravados de volta na tabela do Postgres. E aqui vem a melhor parte: sem nenhuma engenharia de recursos e usando uma única tabela, ele já superava um modelo ajustado

04:47 baseado em árvores que eu havia treinado. A pontuação é 0,60, o que não é muito bom. E isso expõe um dos maiores problemas do Tab FM. O Tab FM é treinado exclusivamente com grafos causais gerados sinteticamente. Isso também significa que, durante o treinamento, ele não viu nenhum cabeçalho de coluna nem rótulo. Portanto, ele nem sabe a diferença entre colunas diferentes. Uma coluna pode representar o gasto mensal,

05:21 enquanto outra pode ser simplesmente a temperatura. Ele trata tudo como um número. No entanto, suas tabelas podem conter significado semântico. Por exemplo, você pode ter uma coluna que usa os números 1, 2 e 3 como rótulos para diferentes eventos ocorridos. Talvez zero signifique “não medido”, ou valores ausentes possam ser representados por uma tag especial. Mas o Tab FM não consegue levar essas diferenças semânticas em conta. É aí que um LLM

05:52 entra no processo, porque compreender o contexto semântico é o que os LLMs fazem de melhor. Os pesquisadores combinaram um LLM com uma nova arquitetura chamada TabFusion Auto. Nela, eles mantêm o TabFusion congelado como mecanismo de inference e colocam o LLM que dá suporte a um agent no comando de todo o pipeline. Nesse caso, o agent inspeciona os nomes das colunas, escreve a lógica de transformação, talvez selecione linhas de contexto e, então, calibra a previsão. E os

06:25 pesquisadores mostram que essa configuração pode alcançar o primeiro lugar no benchmark Tab Arena. Infelizmente, o código do TabFusion Auto não está disponível publicamente. Então, usei o Opus 5.5 para basicamente criar nossa própria implementação, que usa Gemini como orquestrador. Se você quiser usar isso, acho fundamental entender a necessidade de uma arquitetura de banco de dados robusta para dar suporte a um modelo como o TabFusion Auto.

06:58 Deixe-me explicar. Primeiro, o agent precisa de contexto semântico. No Postgres, você pode armazenar dicionários de dados diretamente como comentários das colunas. Assim, o agent pode usar o schema junto com os comentários embutidos para decidir que tipo de código escrever. Segundo, o agent precisa de um sandbox. Você não pode deixar um LLM autônomo alterar dados de produção. Então, para cada experimento, o agent cria uma branch isolada da Neon, que é um clone completo do banco de dados com cópia na gravação, pronto em

07:28 cerca de um segundo. Ele cria tabelas de recursos, testa junções, remove colunas e armazena a execução. Se algo der errado, simplesmente excluímos a branch. E o melhor da Neon é que ela mantém a produção completamente intocada. Terceiro, e mais importante, o agent precisa de proteção contra vazamento de dados. No meu conjunto de dados, há uma coluna de retenção que só é preenchida depois que um cliente inicia o cancelamento.

08:02 Isso vai parecer um recurso milagroso para qualquer agent que esteja em execução, se você estiver olhando para o estado atual do banco de dados. Mas esse recurso não está realmente disponível naquele momento, porque revela um resultado passado. Portanto, o agent não deveria usá-lo. Na verdade, em metade das minhas execuções de teste, o agent percebeu a correlação, ignorou completamente o risco temporal e incorporou essa coluna ao pipeline. Para corrigir isso, fiz o agent treinar usando uma branch isolada restaurada para

08:33 o instante exato anterior à janela de previsão. Durante os testes, quando comparei as previsões com o que os clientes fizeram no mês seguinte, o modelo que parecia perfeito era o pior, porque usava aquela coluna com vazamento. Já o modelo sem essa coluna teve um ótimo desempenho. Em um sistema real de produção, isso não seria uma previsão única. Por exemplo, se você administra uma empresa e quer saber quais clientes poderiam cancelar, basta salvar o pipeline do agent

09:06 no banco de dados, e uma função da Neon o executa em uma programação definida. No meu caso, por exemplo, todas as noites ela cria os recursos diretamente do Postgres e, depois, coloca um trabalho na fila. O DGX Spark pega esse trabalho e grava no banco de dados uma pontuação para cada cliente. Em seguida, a lista de clientes em risco vai para o armazenamento de objetos, logo ao lado. Para fazer os testes, basicamente avancei o relógio em um mês, carreguei o que realmente aconteceu e criei a lista. A maioria dos clientes no topo, de fato, havia pedido para cancelar, o que

09:42 mostra mais ou menos o poder do Tab FM, especialmente se você o inserir no loop agentic. Certo, então qual deve ser a conclusão disso? Primeiro, uma previsão razoável sobre tabelas: o modelo não precisa mais ser treinado com os seus dados. Seus dados podem simplesmente ser o prompt. Segundo, o LLM ainda é muito útil aqui, mas não apenas como preditor. Ele pode ser extremamente útil na parte que lê os nomes das colunas e traz o conhecimento do domínio. E, terceiro, se você vai deixar um agent fazer ciência de dados

10:15 dê a ele um backend real para trabalhar, especialmente sua própria ramificação para cada experimento, o significado de cada coluna junto aos dados e uma maneira de ver os dados exatamente como estavam quando a previsão teria sido feita. Agora, Neon é um backend que usei para tudo isso. E recomendo muito que você confira. Vou deixar um link para o artigo e para o repo no GitHub. É um projeto muito interessante. Os direitos são não comerciais,

10:45 mas você pode tratá-lo como um padrão sobre o qual pode construir. Enfim, espero que este vídeo tenha sido útil. Obrigado por assistir e, como sempre, até a próxima.

Transcrição original

[00:00] Okay, so everybody’s obsessing over large language models right now, but almost all of this noise is about coding agents and chatbots. And LLMs are genuinely great for that, but if you look at what real businesses actually run on, it’s not text. It’s traditional tables. These include things like transactions, customer churns, sensor logs, fraud claims, and maybe inventory-related data. And whenever you need to predict something from a table, you can’t just use an LLM. People today still reach for traditional and

[00:32] classical machine learning methods. But the problem with that is that every single new problem is going to need to train a whole new model from scratch. But today, I’m going to show you a model that might kill that workflow entirely. And then, I’ll show you how to wrap it around an autonomous data science agent that is running on a live back end. Now, personally, I have spent years building predictive models for tabular data and time series. Now, the recipe usually

[01:02] looks something like this. You need to clean your data, then spend a lot of time hand engineering your features, then you train a classical machine learning model, especially gradient boosted trees type of models, tune hyperparameters, and then you repeat the exact groundwork for the next data set. Now, text used to be just as painful. You train one model for sentiment, then you would need another model for spam classification, and yet another model

[01:33] for translation. But then, GPT-3 dropped, and suddenly, you didn’t train separate models anymore. You just showed a foundation model a few examples in the prompt, and it magically figured out everything. Tables never had that moment until now. Google Research recently dropped TabFM, a foundation model built purely for tabular data. But, here’s the crazy part. You do not need to train this model on your own data set. The idea is that you simply pass on rows

[02:06] where you already know labels, and then tag on the unlabeled rows you want predicted. And then, it uses the labeled data and infers the answer in a single pass on those unlabeled data. So, your data set is literally the prompt now. Essentially, this becomes a general foundation model for tabular data. But, how exactly Google did this? The research team behind this trained it entirely on endless stream of synthetic data, which [clears throat] were essentially synthetic tables. Now, for each they sample a random

[02:38] causal tag, then generate rows from it, and force the model to predict held-out cells. The beauty is that it is not able to memorize a specific data set. It actually learns the meta algorithm on how to learn from tables. Now, especially if you have worked in any business setup, tabular data is an essential part of every organization, and that’s why I wanted to create this video. Now, a quick heads-up, Tab FM weights are currently non-commercial research only. So, treat this as an

[03:11] architectural blueprint rather than a drop-in production code that you can use. Okay, so I’m going to show you some live examples of this, but the foundation model is only half the part of the story. The other half is where your live data is. And then, we need to give an agent that environment which it can actually process and work on. So, this is where today’s sponsor, Neon, comes into play. Neon gives you serverless Postgres with instant branching, auth, storage, and function in one spot. For this architecture, the

[03:45] data lives in Postgres on Neon. Tab FM runs locally on my DGX Spark, and our agent is going to execute directly against the database engine. Okay, before going into details, let’s look at a simple example. Uh so, here’s a synthetic SaaS company uh data that I produced. It includes things like customer profile, product usage, invoices, and support tickets. And the goal is that we want to predict which customers are going to churn.

[04:15] Now, in this case, we pull the raw customer table uh from Neon. We feed the label history into Tab FM. I’ll show you how to do that later in the video and ask it to score the remaining users. So, there’s no training involved at all. Now, the model gives us inferred churn score for every customer and then that data is written back into the Postgres table. Now, here’s the best part. With zero feature engineering on a single table, it was already beating a tuned

[04:47] tree-based model that I had trained. Now, the score is uh 0.60, which is not great. And this kind of exposes one of the biggest problem with Tab FM. Now, Tab FM is trained purely on causal graphs, which are synthetically generated. This also means that it hasn’t seen a column header or label at all during its training process. So, it doesn’t even know the difference between uh different columns. Like, one column might represent uh monthly spend,

[05:21] the other might be simply temperature. Now, it treats everything as a number. However, uh your tables can contain semantic meaning. So, for example, you might have a column which uses number 1 2 3 as labels for different events that have happened. Maybe zero means not measured or missing values could be represented by a special tag. But, Tab FM cannot take those semantic gaps into account. So, this is where a large language model

[05:52] enters the loop. Because understanding semantic context is what large language models do best. Now, the researcher paired a large language model in a new architecture called TabFusion Auto. So, here they keep TabFusion frozen as the inference engine and put language model that is powering an agent in charge of the whole pipeline. In this case, the agent inspects column names, writes transformation logic, maybe select context rows, and then calibrates the prediction. And actually, the

[06:25] researchers show that this setup can hit top rank in the Tab Arena benchmark. Now, unfortunately, TabFusion Auto’s code is not publicly available. So, I used Opus 5.5 to basically create our own implementation that is using Gemini as the orchestrator. Now, if you want to use this, I think it’s very critical to understand the need for a robust database architecture in order to support a model like TabFusion Auto.

[06:58] So, let me explain. Okay, first, the agent needs semantic grounding. In Postgres, you can store data dictionaries directly as column comments. So, the agent can use the schema plus the inline comments to actually decide what type of code to write. Second, the agent needs a sandbox. You can’t let an autonomous LLM mutate production data. So, for every experiment, the agent spins up an isolated Neon branch, which is a full copy-on-write database clone ready in

[07:28] just about a second. It creates feature tables, then test joins, and drops columns, and stores the run. Now, if something fails, we simply delete the branch. And the beauty of Neon is that it will still keep the production completely untouched. Okay, third and the most critical pieces that the agent needs protection against uh data leakage. In my data set, there is a retention of a column that only gets populated after a customer initiates cancellation.

[08:02] Now, this is going to look like a silver bullet feature uh for any agent that is running. If you’re looking at today’s snapshot of the database, but that’s not a feature that is actually available because it shows previous past outcome. So, an agent should not be using it. In fact, in half my test runs, the agent noticed the correlation and completely ignored the temporal risk and baked it into the pipeline. Now, to fix that, I had the agent train against an isolated branch restored to

[08:33] the exact timestamp before the prediction window. Now, during testing, when I checked both against what customers had treated next month, uh the one that looked perfect on uh was the worst model cuz it was using that leaky column. And the one without that leaky column actually did great. Now, for a real production system, this is not going to be a one-off prediction. For example, if you’re actually running a business and you want to look at which customers could potentially churn, you can simply save the agent’s pipeline

[09:06] into the database, and a Neon function runs it on a schedule. So, for example, in my case, every night it builds the feature straight from Postgres, then queues a job where DGX Spark picks the job up and writes a score for every customer back into the database. And then, the at-risk list lands in the object storage right next to it. So, for the experimentation, I basically moved the clock forward a month, loaded what actually happened, and created the list. Most of the customer at the top had, in fact, asked to cancel, which

[09:42] kind of shows you the power of Tab FM, especially if you wrap it around into the agentic loop. Okay, so what exactly should be the takeaway from this? First, a fair prediction on tables, the model doesn’t have to be trained on your data anymore. Your data can just be the prompt. Second, LLM is still really useful here, but not just as a predictor. It can be extremely useful for the part that reads the column names and brings in the domain knowledge. And third, if you’re going to let an agent do data

[10:15] science, give it a real back end to work in, especially its own branch off for every experiment, and meaning of every column right next to the data, and a way to see the data exactly as it looked when the prediction would have been made. Now, Neon is a back end that I used for all of it. And I highly recommend to check it out. I’ll put a link to the paper and the GitHub repo. It’s a very interesting project. The rights are non-commercial,

[10:45] but you can treat it as a pattern you can build on. Anyways, I hope you found this video useful. Thanks for watching, and as always, see you in the next one.