Video · 2026-05-21 · 1h 6m · 30 moments

Foundation Models Are Coming for Enterprise Databases [Jure Leskovec] - 768

✦ AI generated

timeline · colored by role

Claim◆

A pre-trained relational foundation model can make accurate predictions on any database and any predictive task without any task-specific model training.

Jure introduces Kumo's relational foundation model (RFM), a pre-trained model that reasons over structured relational databases and can generate accurate predictions for arbitrary predictive tasks with zero task-specific training.

transcript

Jure Leskovec: The recent breakthrough uh that we had and we just released um in the second version uh is our what we call a relational foundation model. Um and that's a pre-trained foundation model uh that can reason over structured relational data. Um and it's crazy what this model can do. It can make accurate predictions on any database and any predictive task without any model training.

explains mechanism · 1gives example · 1

Claim◆

A pre-trained relational foundation model can make accurate predictions on any database and any predictive task without any model training.

Kumo's newly released relational foundation model (RFM2) reasons over structured relational data and produces accurate predictions on arbitrary databases and tasks with zero training.

transcript

Jure Leskovec: Um and it's crazy what this model can do. It can make accurate predictions on any database and any predictive task without any model training.

explains mechanism · 2gives example · 1

Claim◆

A pre-trained relational foundation model can make accurate predictions on any database and any predictive task without any model training.

Jure Leskovec describes Kumo's newly released relational foundation model (RFM), which can generate accurate predictions on arbitrary databases and tasks with zero additional training.

transcript

Jure Leskovec: That's a pre-trained foundation model uh that can reason over structured relational data. Um and it's crazy what this model can do. So what this model can do, it can make accurate predictions on any database and any predictive task without any model training.

explains mechanism · 2provides context · 1

Mechanism

Biology, including cell types and cell states, emerges purely from self-supervised training on raw molecular data, without any human-inserted biological knowledge or bias.

Leskovec explains that Stanford's AI virtual cell models learn cell types, states, and relationships in a fully unsupervised way, with no human biological knowledge injected into the model.

transcript

Jure Leskovec: So you don't need to insert any human bias any human knowledge of biology. The biology emerges from the data itself, right? Like cell types, cell states, relationships between them. Um that kind of human biology, how we describe it, actually emerges directly from the data.

Claim◆

AI has not fundamentally transformed structured/tabular data the way it transformed computer vision and NLP, because practitioners still hand-engineer features into a single table instead of letting a neural network learn directly on raw data.

Leskovec argues machine learning on structured data has been stuck for 30 years in a feature-engineering paradigm, unlike the raw-data deep learning revolution seen in vision and language.

transcript

Jure Leskovec: maybe this predictive model, you know, it's a it's a deep model we would call, but um it's a neuronet network. But what I would argue is it that AI has not transformed this structured data space in the same way as uh computer vision or natural language understanding have been fundamentally transformed by AI.

gives example · 1

Claim◆

AI has not transformed structured/tabular data the way it transformed computer vision and NLP, because practitioners still hand-engineer features via SQL and ETL instead of learning directly from raw data.

Leskovec argues machine learning on tabular/structured data has been stagnant for 30 years, still relying on manual feature engineering, unlike the raw-data breakthroughs seen in vision and language.

transcript

Jure Leskovec: What I would argue is it that AI has not transformed this structured data space in the same way as uh computer vision or natural language understanding have been fundamentally transformed by AI... the same thing is actually not happening on structured tabular data right there we don't learn on raw data we run all these SQL queries all this ETL all this feature engineering.

Claim◆

Unlike computer vision and NLP, structured/tabular data has never been transformed by deep learning because practitioners still rely on manual feature engineering (SQL/ETL) rather than learning directly on raw data.

Leskovec argues that while vision and NLP were revolutionized by neural networks learning directly on raw pixels/tokens, tabular ML is still stuck doing manual feature engineering on a single flattened table.

transcript

Jure Leskovec: AI has not transformed this structured data space in the same way as uh computer vision or natural language understanding have been fundamentally transformed by AI... the transformers they just learn over tokens, no grammar, no syntax... the same thing is actually not happening on structured tabular data. There we don't learn on raw data, we run all these SQL queries, all this ETL, all this feature engineering to then come up with a set of signal.

Claim

Machine learning on structured/tabular data has never been fundamentally transformed by deep learning the way computer vision and NLP were, because practitioners still hand-engineer features into a single table instead of learning directly on raw data.

Jure argues that unlike vision and language, structured/tabular ML still relies on manual SQL/ETL feature engineering rather than neural networks learning directly on raw data, so it has missed the deep-learning transformation.

transcript

Jure Leskovec: AI has not transformed this structured data space in the same way as computer vision or natural language understanding have been fundamentally transformed by AI... the same thing is actually not happening on structured tabular data. There we don't learn on raw data, we run all these SQL queries, all this ETL, all this feature engineering to then come up with a set of signal.

explains mechanism · 1

Mechanism

A relational database can be represented as a graph of entities and relationships, allowing graph neural networks to learn directly over multi-table data instead of flattening it into a single feature table.

Relational deep learning treats database rows and tables as nodes and edges in a graph, letting graph neural networks learn directly from raw multi-table data.

transcript

Jure Leskovec: Just think of the database, think of these tables as a graph of relationships between the entities in the database... the connections are just saying this user ID was part of this transaction that was part of that product... now that we have a graph, we can basically apply graph deep learning like graph neural networks.

Mechanism◆

Machine learning on structured/tabular data can be transformed the same way computer vision and NLP were, by having a neural network learn directly on raw multi-table relational data represented as a graph, instead of manually feature-engineering a single flattened table.

Jure explains the core idea behind relational deep learning: treat a database's tables and foreign-key links as a graph of entities and relationships, then apply graph neural networks directly to the raw data instead of hand-engineering features into a single table.

transcript

Jure Leskovec: So our question was how could just how could I just learn directly with a neural network over this multitabular data? Um and the answer is you know kind of surprisingly simple is to say just think of the database think of these tables as a graph of relationships between the entities in the database.

gives example · 1provides context · 1

Mechanism

By representing a multi-table database as a graph of entities and relationships, a graph neural network can learn directly on raw relational data, eliminating manual feature engineering and producing double-digit accuracy gains.

The core idea of relational deep learning: think of database tables as nodes and foreign-key relations as edges, then apply graph neural networks to skip manual feature engineering and boost accuracy.

transcript

Jure Leskovec: Just think of the database, think of these tables as a graph of relationships between the entities in the database... now that we have a graph, we can basically apply graph deep learning like graph neural networks... The first thing that happens is you don't have to do manual feature engineering... The second thing that happens is your models are more accurate... we see this double-digit increases in model accuracy.

provides context · 1

Mechanism

Representing a relational database as a graph and applying graph neural networks eliminates manual feature engineering and produces double-digit accuracy gains over hand-engineered features.

By modeling tables as nodes and foreign-key links as edges, graph neural networks can learn directly on raw relational data, removing manual feature engineering and boosting accuracy by double digits.

transcript

Jure Leskovec: The first thing that happens is you don't have to do manual feature engineering, right, so it's much faster... the second thing that happens is your models are more accurate... a neural network that trains with gradient descent is able to do so much more nuanced almost like feature discovery by basically attending over this graph to extract much more signal. So we see this double-digit increases in model accuracy.

provides context · 2

Claim

Single-table tabular machine learning is essentially a solved problem where methods perform about equally well; the real unsolved frontier is multi-table relational data, since flattening a database into one table discards the signal-rich relational structure.

Jure argues that no real organization keeps all its data in a single table, and that the real hard, unsolved machine learning problem lies in the multi-table relational setting, not in the already-well-studied single-table tabular ML space.

transcript

Jure Leskovec: I don't know any organization that has all their data in a single table, right? So the hard part and where the information gets lost is when you go from this rich relational structure into the single table and once you are in a single table you know then we are you know then we are kind of talking almost like second order effects.

Example

Denormalizing multi-table data into a single wide table only works for one-to-one relations; any one-to-many relation forces aggregation, which irreversibly discards information (as illustrated by the arbitrary, endlessly-debated aggregation choices in a customer churn feature pipeline).

Leskovec explains why you can't just flatten a database into one table for existing tabular benchmarks: any many-to-one relationship requires aggregation, and aggregation choices (mean vs. median vs. min vs. max) are arbitrary and lossy, as shown by his churn-modeling example.

transcript

Jure Leskovec: As soon as you have many to one, you have to aggregate. And that's the key. Once you aggregate, you lose... I'll count how many purchases you made last month and then I'll maybe take the median price... and then somebody says no it's the average... you see how kind of ridiculous this gets? Just attend over the transactions and let the attention figure out what predict.

Example

Denormalizing multi-table relational data into a single wide table necessarily loses information, because any many-to-one relationship forces an arbitrary, lossy aggregation choice.

Using a churn-prediction example, Jure explains that aggregating a customer's transaction history into single-table features (mean, median, min price, etc.) is arbitrary and loses signal that a model attending directly over raw transactions can recover.

transcript

Jure Leskovec: Imagine you are doing a churn model... I have a customer and here are historic transactions of the customer. I need to aggregate them. So first I say I'll count how many purchases you made last month and then I'll maybe take the median price... and then somebody says no, it's the average... you see how kind of ridiculous this gets? Just attend over the transactions and let the attention figure out what's predictive.

Example

Manually choosing aggregation statistics (count, median, cheapest, most expensive, etc.) to summarize a customer's transactions into a single feature for churn prediction is an arbitrary, unprincipled process that a neural network attending over raw transactions can replace.

Using a churn-model example, Leskovec shows how feature engineering over relational data devolves into endless, arbitrary debates about which aggregation statistic to use, which relational deep learning avoids entirely.

transcript

Jure Leskovec: I have a customer and here are historic transactions of the customer. I need to aggregate them. So first I say I'll count how many purchases you made last month and then I'll maybe take the median price of those purchases and then you know some other data scientist says no no let's take the cheapest price of everything you bought right and then somebody says no no you should take the most expensive one

explains mechanism · 1supports · 1

Claim◆

Kumo's second-generation relational foundation model (RFM2) can make accurate predictions on any database and any predictive task without any model training.

Jure Leskovec describes Kumo's newly released relational foundation model, which reasons over structured relational data and requires no per-task training to make predictions on a new database.

transcript

Jure Leskovec: we just released um the second version uh is our what we call a relational foundation model. Um, and that's a pre-trained foundation model uh that can reason over structured relational data. Um, and it's crazy what this model can do. So what this model can do, it can make accurate predictions on any database and any predictive task without any model training.

explains mechanism · 2supports · 1

Claim◆

A pre-trained relational foundation model can make accurate predictions on any database and any predictive task without any model training.

Kumo's RFM2 is a pre-trained foundation model that reasons over structured relational (database) data and produces accurate predictions on new databases and tasks with zero training.

transcript

Jure Leskovec: That's a pre-trained foundation model that can reason over structured relational data. And it's crazy what this model can do. So what this model can do, it can make accurate predictions on any database and any predictive task without any model training.

explains mechanism · 1provides context · 2supports · 1

Mechanism

The relational foundation model produces predictions via a single forward pass of a pretrained, frozen neural network, with no agentic loop, memory, or scratchpad reasoning involved.

Leskovec clarifies that RFM2 is not an agent: it answers via a single, fast forward pass through a transformer-like network with no iterative reasoning, memory, or tool calls.

transcript

Jure Leskovec: No no no this is not this is not an agent. This is a single forward pass of a transformer-l like neural network. Right? So this is purely inside the neural network. There is no agent. There is no memory. There is no scratch pad. There is no let me do this, let me do that. Right? The answer is truly a single forward pass of a neural network.

Mechanism◆

The relational foundation model produces predictions via a single forward pass over in-context examples, with no training, backpropagation, gradients, agent loop, or memory involved.

Leskovec clarifies RFM2 is not an agent with memory or scratchpad reasoning — it's purely a single forward pass of a frozen pre-trained transformer-like network using in-context examples.

transcript

Jure Leskovec: No, this is not this is not an agent. This is a single forward pass of a transformer-like neural network. Right? So this is purely inside the neural network. There is no agent. There is no memory. There is no scratch pad... The answer is truly a single forward pass of a neural network. There is no loop.

Mechanism◆

The relational foundation model produces predictions via a single frozen forward pass of a transformer-like neural network using in-context learning, with no training, gradients, agent loop, memory, or scratchpad involved.

Jure clarifies that Kumo's relational foundation model is not an agent: it makes predictions through a single forward pass of a pre-trained, frozen transformer-like network with in-context examples, with no backpropagation, memory, or iterative reasoning steps.

transcript

Mechanism◆

The relational foundation model makes predictions through a single frozen forward pass using in-context learning over extracted labeled subgraphs — there is no training, no agent, no memory, and no iterative reasoning loop involved.

Leskovec clarifies the mechanics of RFM: it pulls historical labeled subgraphs as in-context examples and produces a prediction via a single forward pass of a frozen transformer-like network, with no agent, memory, or backpropagation involved.

transcript

Jure Leskovec: No, this is not this is not an agent. This is a single forward pass of a transformer-like neural network. There is no agent. There is no memory. There is no scratch pad... The answer is truly a single forward pass of a neural network. There is no loop, nothing like that.

Data◆

In benchmark tests the RFM foundation model improves on the best-ever published supervised models by about 5% out-of-the-box, and by 12% when fine-tuned, translating into large real-world business impact at companies like Reddit and DoorDash.

Jure cites benchmark results showing the foundation model beats all previously published supervised models by ~5% (12% after fine-tuning), and describes real production wins at Reddit (near double-digit CTR increase) and DoorDash (hundreds of millions in revenue impact).

transcript

Jure Leskovec: The foundation model by itself improves state-of-the-art over all supervised models ever published on this benchmark... the foundation model improves that I think for about 5% relative accuracy, and then if you further tune the model, meaning if you would fine-tune it, do some gradient-based updates, then the performance goes to 12% over the state-of-the-art.

explains mechanism · 1

Data◆

Kumo's relational foundation model beats the best supervised models on benchmark tasks by about 5% relative accuracy out of the box, rising to a 12% improvement after fine-tuning, gains large enough to translate into tens of millions of dollars of business impact in production systems.

Leskovec cites benchmark results showing RFM2 beats state-of-the-art supervised models by 5% zero-shot and 12% after fine-tuning, with real deployments at Reddit, DoorDash, and Coinbase showing large revenue and accuracy gains.

transcript

Jure Leskovec: what we see is that the foundation model um by itself improves uh state-of-the-art uh over all supervised models ever published on this on this benchmark. Right? So so the baseline is very high. It's like just build the best model you can and see how high you can get. um uh uh the foundation model improves that I think for about 5% relative uh the accuracy um and then if you further tune the model meaning if you would fine-tune it do some grain and base updates then the performance goes to 12% uh over the state-of-the-art

Data

Adding Kumo's relational foundation model embeddings on top of Reddit's already heavily optimized manual feature engineering pipeline produced a near double-digit increase in ad click-through rate.

At Reddit, where an already sophisticated team had heavily hand-engineered features, appending Kumo's graph embeddings still drove a near double-digit lift in click-through rate, far beyond typical yearly gains.

transcript

Jure Leskovec: Another great client we work with is Reddit. So the advertising models on Reddit are built on top of or are built with Kumo... and it was nearly a double digit increase in clickthrough rates. So basically... usually an entire team increases maybe 1% that accuracy year over year.

Data

In production deployments at Reddit and DoorDash, Kumo's graph-embedding-based predictions delivered gains (near double-digit click-through rate increases at Reddit) on top of teams' already highly-optimized, years-refined manual feature engineering pipelines.

Leskovec cites real-world production results — Reddit's ad click-through rate and DoorDash's recommendation/notification systems — where Kumo's learned embeddings added significant lift even atop sophisticated, long-standing hand-engineered feature systems.

transcript

Jure Leskovec: The advertising models on Reddit are built on top of or are built with Kumo. And it was nearly a double digit increase in clickthrough rates... even with that there was a huge increase in the click-through rate because this signal that the neural network learned was kind of complementary to what the human feature engineering already had.

Data

Kumo's relational graph embeddings, appended to Reddit's already highly-optimized hand-engineered advertising features, produced a nearly double-digit increase in click-through rate, a gain far beyond the typical ~1% annual improvement from manual feature engineering.

Jure describes Kumo's production deployment at Reddit, where graph embeddings for users, subreddits, and ads were combined with Reddit's existing hand-engineered features and yielded a nearly double-digit click-through-rate lift, dramatically outpacing typical incremental gains.

transcript

Jure Leskovec: Another another great client we work with is Reddit. So the advertising models on on Reddit are built on top of or are built with Kuma. Um and it was um nearly a double digit uh increase in at uh clickthrough rates. So basically the the revenue the yeah it's like unbelievable right usually an entire team you know like increases maybe 1% that accuracy year over year right because clickthrough rate

Anecdote

Coding agents given open-ended tasks like PyTorch make subtle but serious data-science mistakes such as information leakage, but with a proper high-level API (like Kumo's) they can accomplish the same task correctly in far fewer steps, showing agents need agent-friendly APIs to be effective.

Jure describes an internal test where an agent asked to build a fraud model from scratch made a subtle information-leakage bug (aggregating data 'till midnight' instead of the current time), but the same task took only ~50 correct lines when done through Kumo's higher-level API, illustrating that agents need agent-friendly abstractions to avoid multi-step failures.

transcript

Jure Leskovec: These models write thousands of lines of code but there are these super subtle data-sciency mistakes. So for example, we've done this together with Expedia, and the mistake the agent made was that when it created features for that given account it aggregated the transactions till midnight, not till the current time... that's information leakage. But if you give it a higher-level Kumo-like API then it's able to do the same work in about 50 lines of code, no mistakes.

Anecdote

Coding agents given only general-purpose tools make subtle but serious data-science errors, such as introducing information leakage by aggregating transactions up to midnight instead of the actual current time, whereas a higher-level, task-specific API prevents such mistakes and requires far less code.

Drawing on work with Expedia, Leskovec explains that agents writing thousands of lines of raw PyTorch/XGBoost code introduce subtle bugs like time-travel leakage, but the same task takes only ~50 error-free lines using a proper domain-specific API like Kumo's.

transcript

Jure Leskovec: these models write thousands of lines of code but there are this like super subtle data sciency mistakes. So for example, we we've done this uh together uh together uh with Expedia um and uh you know when when it was a account level fraud and uh mistakes for example the agent make was that when it created features for that given account it created it aggregated the transactions till midnight not till the current time

Anecdote

When coding agents like Claude Code are given a raw task to build a model from scratch, they write thousands of lines of code but introduce subtle data-science bugs like information leakage; giving them a higher-level, purpose-built API instead lets them do the same work correctly in far fewer steps.

Jure recounts an internal test with Expedia where a coding agent building an account-level fraud model from scratch made a subtle information-leakage bug (aggregating transactions to midnight instead of the current time), arguing agents need agent-friendly, higher-level APIs to avoid such mistakes.

transcript

Jure Leskovec: When we do that what we see we've run this internally is that these models write thousands of lines of code but there are this like super subtle data sciency mistakes. So for example, we we've done this uh together uh together uh with Expedia um and uh you know when when it was a account level fraud and uh mistakes for example the agent make was that when it created features for that given account it created it aggregated the transactions till midnight not till the current time.

Highlight slides

Related episodes

Video · a16z Podcast

Software in the Age of Agents | The a16z Show

→

Video · The Cognitive Revolution

Intelligence on the Edge: Liquid AI's Ramin Hasani on the Search for Device-Native Foundation Models

→

Video · The Cognitive Revolution

Fable's Back, AI Engineer Recap, & SambaNova

→