LinkedIn spent five years on graph neural nets. She wants any company to see value in four weeks

Hema Raghavan joins Sequoia’s Training Data as co-founder and head of engineering at Kumo AI. Hosts Sonya Huang and Konstantine Buhler introduce a career that started in NLP before BERT existed and then spent nearly eight years inside LinkedIn. She is credited with People You May Know, a feature that is graph learning in all but the modern branding, and she later owned notifications while sitting on sessions and monthly active users — the growth KPIs that actually paid the bills.

Kumo’s pitch is narrower than “AI for everything.” The company runs automated machine learning with graph neural networks on the platforms enterprises already bought, from Snowflake to Databricks. Raghavan and her co-founders, who include Stanford professor Jure Leskovec, are trying to make that stack usable without a graph-learning PhD or a standing army to maintain feature pipelines. The product’s claim is that you go straight to business value instead of spending a year wiring the graph by hand.

That promise is set against a number she knows from the inside. Getting graph neural networks into LinkedIn’s ads, feed, and jobs took four to five years and a large engineering team after she left. Kumo’s commercial unit of time is four weeks: a proof of concept on the customer’s own warehouse data. The rest of the conversation is about why she thinks those two clocks can finally diverge.

Konstantine opens with the obvious objection. AutoML was a major trend five or six years ago, then slid into a trough of disillusionment; many of those vendors receded and companies started parking features in feature stores instead. Why build another AutoML company now? Raghavan’s answer is blunt: there is AutoML, and then there is AutoML on GPUs, and she thinks that is the entire difference.

She illustrates with her own early-2000s NLP work. To answer “When did Marco Polo land in Asia?” her team encoded features by hand: Marco Polo is the subject of the sentence, so the answer is likely to appear as a subject too. You had to know linguistic structure or the machine would not work. After the GPU revolution, nobody writes those features. Intermediate layers of a neural network learn parts of speech and named entities on their own. She says the last AutoML wave made the opposite bet: CPU models such as logistic regression, XGBoost, and SVMs, with AutoML merely parallelizing the hand-computed features a data scientist would have written. The machine was being asked to think like a human.

Kumo’s models are graph neural networks, which she describes as a superset of CNNs for images and sequence models for language. GNNs allow arbitrary structure and learn the features you would otherwise engineer for a predictive problem. In her framing, Kumo sits in predictive AI and is bringing transformer-era technique to that workload, not resurrecting the old AutoML category with a new logo.

Konstantine pushes the claim further. In the Kaggle era — which is how he first met co-founder Jure Leskovec — ensembles always won, including the Netflix Prize: lots of little algorithms chained together. A neural network, he says, is billions of sigmoids chained together; a GNN can discover both the features and the ensemble. Graphs, in that view, are the most general data type, and a GNN is the most general learner, with transformers as a subset. Raghavan adds a production footnote: she has watched one frontend engineer change how view data was logged and break N feature pipelines at once. Graphs, she says, give you a simpler frame for the same outcome.

Sonya asks her to explain graph neural networks as if to a five-year-old. Raghavan uses the episode they are recording. A user logs into YouTube; the system has the content of this podcast and a views table of everything that person has watched. Collaborative filtering looks only at views. Graph learning treats the whole network as nodes and edges: users, episodes, Sequoia Capital’s channel, metadata, plus clicks and other behavioral signals as links. The network might learn that Sonya likes AI and Baby Shark, that Konstantine likes AI and history, and that the overlap is AI — so the next Baby Shark watch should not be recommended to him.

You do not have to be a social network to have a graph. Fintech companies have customers and transactions; a delivery service has inventory, suppliers, and modes of transport. Those records sit as tables, which are entities linked to one another. Konstantine floats a brain analogy: brains form and prune connections more like a graph than like a grid or a sequence. Raghavan takes half of it. GNNs learn embeddings, so Sonya’s vector sits near both AI content and other Baby Shark households. The part she likes is that GNNs allow arbitrary structure, and the human brain is neither a linear sequence nor an image grid.

Then comes the mapping she calls the actual insight. People think in relational data because the analytics revolution preceded the AI revolution. Relational data and graphs have a one-to-one mapping: a primary key is a node, and primary-key/foreign-key relationships are edges. Automatic construction from tables to a graph is one of Kumo’s core tricks. The other is a predictive query language that looks like SQL with a predict clause, so an analyst who already writes warehouse queries can specify a machine learning problem in a few lines. The graph is abstracted away unless a data scientist wants to tweak neural network parameters — “we’ll give you the self-driving car, but if you want to drive stick, we’ll let you.”

Konstantine names the shift: querying how many people watched AI videos is querying the past; asking how many will watch in the next few weeks, whether a user will churn, or which video will retain them is querying the future. Customers already span healthcare demand forecasting for emergency rooms, fintech fraud (“is this user’s behavior suspicious?”), and consumer recommendations. Raghavan buckets the questions as how much, whether an event will happen, and what the next best action is from an action space.

Sonya asks the political question. Fraud and demand forecasting already have five-person and fifteen-person teams. What do those people think when Kumo shows up, and can an out-of-the-box model beat them? Raghavan says most data scientists are excited, because writing feature pipelines comes with a maintenance job they do not want. They are incentivized on direct business impact: did this quarter’s click-through model drive X percent of revenue? Customers arrive saying they signed up for X percent and are only one-third of the way there.

Kumo’s answer is a four-week proof of concept. She tries to remember a case where they did not show value in that window and cannot. Sonya calls that converting people into believers. Hands on keyboard, some still protest that feature engineering is where they spend all their time. Raghavan walks them through the NLP history, then points out that Kumo does not erase business judgment. A data scientist still decides whether churn is a 30-day, 90-day, or 365-day window of activity. Those are query parameters. One customer wrote five such queries and discovered that 365-day behavior was the best churn predictor — something they had never checked, because their time was spent elsewhere.

That is why she thinks feature engineering as a discipline goes away, and that this is not a bad thing. At LinkedIn she watched data scientists who wanted to find business value spend their hours keeping pipelines alive. The better use of that talent, she argues, is trying N models on N parts of the product. Analysts can stay in predictive queries; experts who want to go all in get a Python interface. The self-driving-car line is the product strategy in one image: automation for people who want it, a stick shift for people who do not.

Kumo started as a pure SaaS company, modeling itself on Snowflake’s architecture. The problem was that data scientists only credit value on their own KPIs; a win on a Kaggle dataset does not count. Connecting a SaaS tool to production data meant a security review that, in some companies, took a couple of months. They partnered with the warehouses instead, putting compute closer to the data. On Snowflake, Kumo deploys via Snowpark Container Services into Snowflake’s compute pool and installs as a native app — “like an app on your iPhone.” Security teams usually accept it because no data leaves the ecosystem.

Databricks is a similar pattern: Kumo manages the GPU compute, but data residency stays entirely inside Databricks. The side effect, Raghavan says, is that Kumo no longer has to rebuild security, compliance, and governance. Those tools already live in the warehouse. The remaining hard problem is the graph itself. Databases can be partitioned; a graph is entangled. Splitting it across machines with limited memory is why only a handful of companies have ever run this at scale, and they usually staffed a huge infrastructure team to do it.

Kumo’s answer is a unified graph schema inferred from the relational one — video ID, user ID, channel ID as primary keys in the YouTube example — then Spark-like code that converts tables into graph format. Edges are stored in a proprietary compressed format in what they call the graph engine. Nodes are distributed onto CPU machines so the system can horizontally scale without being memory-bound. Features sit in a column store. GPUs are reserved for training and message passing. That split, she says, is why customers are surprised they can run graph learning at this scale at this cost.

Sonya asks about the connection to large language models. Raghavan offers two. First, the LLM as a feature factory: this podcast will be transcribed and summarized, and those semantic representations can sit as node features while the GNN learns interaction patterns across the graph. Second, Kumo as a personalization layer for the LLM. A logged-out shopper searching for “yellow summer dresses” can get a decent LLM result. A logged-in shopper has a behavioral history; Kumo’s predictions can feed a RAG pipeline so the model is grounded in personalized facts instead of a generic catalog.

Konstantine asks about Graph RAG, which is having a moment. She separates it cleanly. Graph RAG retrieves from knowledge graphs — insurance codes linked to symptoms in a medical domain, for example — to ground LLM output. RAG’s source can be a search index, a knowledge graph, or a recommender like Kumo; the shared goal is that the LLM hallucinate less. She sees the two worlds as complementary: the LLM does not consider the behavioral data sitting in the app, and that is the gap Kumo fills. People are already plumbing Kumo into LangChain and Pinecone to build agents that recommend those yellow dresses. That application layer is the part of Kumo’s future she sounds most excited about.

Explainability was not a research flourish. Insurance and healthcare customers need to know why a recommendation was made, including confirmation that the model did not over-rotate on race, color, or ethnicity. It became table stakes, so Kumo built an algorithm that, after training, walks the graph and the gradients down to the table and column level. Early results go further, to the instance: Sonya was recommended this video, at this score, because of these specific features. For the domains they sell into, she says, they had no choice but to solve it.

Raghavan joined LinkedIn a couple of years after the IPO, when membership was around 400 million and climbing. She came in as an AI researcher on the growth team and first led People You May Know, then notifications. Because PYMK sits on a social graph, it was tied directly to sessions and monthly active users. Before MLOps had a name, the team had to measure, A/B test, and maintain models in production. Models degraded even when the graph was not losing nodes, because behavior drifted: people use LinkedIn differently at New Year than during summer break. Auto-retraining pipelines were not optional. CPU algorithms also stopped being something you could just scale horizontally. Graph neural networks, carried forward by a team after she left, took four to five years and many engineers; they now power ads, feed, and jobs, and the team recently published a paper on the work.

Konstantine asks whether this is a champagne problem. The three founders came from LinkedIn, Airbnb, and Pinterest; smaller companies hear “hundreds of millions of users” and flinch. That intimidation, she says, is why they invented predictive query language. Many firms have few data scientists and many places they want AI. They would love to be a LinkedIn or an Airbnb and cannot put that many people on it. An easy interface plus managed infrastructure at scale is the answer she offers them. Kumo is a bad fit when the data landscape is not ready: customers who cannot measure the value of AI, or who are still in spreadsheets on the way to a warehouse. She uses a city metaphor — roads and foundations first, then vehicles — and tells those companies to come back in a year.

The filter is data sophistication, not industry or problem type. You do not have to be Airbnb. You do need KPIs an algorithm can optimize and data sitting in a warehouse. Her evolution curve for a company is product-market fit, then a data ecosystem built for analytics so you can measure behavior, then AI: you already know how to query the past and now need models to drive the change you want. For young engineers she skips frameworks entirely. Tools and languages come and go; do not skip probability and linear algebra, because decades of methods keep collapsing back to those two. As for when graph neural networks go mainstream, she had just been to KDD, one of the large data-mining conferences, where more than half the papers were on graph neural networks. She thinks the field is sitting at the explosion.