Using AI To Transform Your Business Without The Headache Using Graft

Hello, and welcome to The Machine Learning Podcast. The podcast about going from idea to delivery with machine learning.

Building good ML models is hard, but testing them properly is even harder. At DeepChex, they built an open source testing framework that follows best practices, ensuring that your models behave as expected.

Get started quickly using their built in library of checks for testing and validating your model's behavior and performance and extend it to meet your specific needs as your model evolves.

Accelerate your machine learning projects by building trust in your models and automating the testing that you used to do manually.

Go to the machine learning podcast.com/deeptext

today to learn more and get started.

Your host is Tobias Macy. And today, I'm interviewing Brian Calvert and Adam Ollinger about Grapht, a cloud native platform designed to simplify the work of applying AI to business problems. So, Brian, can you start by introducing yourself?

Yeah. Hi. So Brian Calvert. I'm 1 of the cofounders,

Craft with Adam and 4 other

excellent folks. And, basically,

I've kind of been in the data ML space

in some fashion or another since my PhD where I worked on high high energy particle physics, analyzing bunch

of data from the Large Hadron Collider.

From there, moved to big data and various industry jobs with my most recent 1 being Cruise, the self driving car folks, where I was both a data scientist as well as the overall tech lead for their ML infrastructure.

Yeah. And from Cruise joined Graft, and I think that's pretty succinct.

And, Adam, how about yourself?

I am the CEO and founder at Graft. As Brian said, we have an amazing founding team.

Prior to Graft, I was the head of machine learning at Slack. And before that, helped to build and grow the engineering team for ML at Splunk.

And, you know, we can go further back, but I was originally kind of on an academic track. So I was fortunate enough to work with some amazing teams at MIT and Stanford and Berkeley.

And you both sort of given a bit of your background in machine learning. I don't know if there's anything more that you wanna go over as far as how you first got involved in the space or what it is about it that keeps you interested.

Being at MIT and then at Stanford at that particular time, which was, like, the early 2000, was just a really interesting time to be interacting with ML folks.

So MIT was still very much like old guard AI. So I took courses with Marvin Minsky and Patrick Henry Winston and folks like that where the goal was to understand the computational nature of human intelligence,

which is really appealing as a higher order goal and really exciting. But there wasn't much progress being made, and that was sort of the origin of the AI winter. And then when I went to Stanford,

I was fortunate enough early in my PhD

to work with Sebastian Thrun and the Stanford racing team. So I got to go to Nevada for the DARPA Grand Challenge, where they they got this self driving car to

actually drive for some distance, albeit through a desert. But it was kind of the first time that it happened.

And that was my introduction to what I would call the sort of more

current iteration of machine learning as a field, which is this notion of you throw math and statistics and compute power at these problems. And maybe you don't learn anything about the computational nature of human intelligence, but it's really effective.

And that's sort of where we are now, and then have made huge progress as a field. So that was kind of my foray into it. I'd say it kind of started in my PhD work at CERN.

It was this funny juxtaposition where there was, like, a lot of on a old guard of physics who were very keen to have very first principles understandings

and or analyzing petabytes and petabytes, you know, millions, millions, millions of events to find Higgs bosons,

signatures of supersymmetry,

what have you.

And

it's such

nonlinear relationships between all these variables and, like, the signals of interest that the people these postdocs, grad students who are, like, hearing about ML, this is 2010, so it's starting to make its resurrection,

are all very eager, chomping at the bit to try these techniques out. And then there's kind of this pushback of almost as, like, explainable AI kind of pushback of, like, how do we know

what's coming out of this? Like, we're already having to

simulate the supersymmetric

particle interactions in the detector

to get a sense of what this crazy multichannel thing is gonna show.

So,

like, long story short, I didn't necessarily work with it directly there, but got a lot of kind of exposure and context to seeing how people are trying to apply it to large data. And then in my first industry role at Intel, we have a bunch of large data, all these images of the wafers and the little, like,

sub

areas of transistors. Are there defects here? What kind of defects are there? This real time bit of it, can we get these algorithms to run fast enough to actually get reasonable throughput and quality control?

And just kind of dovetail from there, like, various flavors of large scale application of ML. And for me, personally, I think the most exciting bit of it is that force multiplier element of it. It lets you take

these baseline

model templates, these architecture templates, and just if you have a bunch of data, now that tends to be the part that separates folks out or used to be at least. If you have a bunch of data, you can get these super effective systems for parsing out

further streams of new data. And

all these applications come to mind for a very, like, prosocial

of course, there's also these challenges around

not so

fun applications of it too. So I think that's another interesting bit of it. It's such a nascent field

in terms of that large Go application side that I've just been super interested in in exploring that. Just in hearing the both of your introductions, I had ideas for at least 3 more episodes that we could all do together. So

I'll definitely be looking to follow-up on that given the time. But today, we're here to talk about Graft, which I think brings us nicely back to what you were just saying, Brian, about the

potential kind of differentiators

or the kind of

schism between the haves and have nots in the ML ecosystem. And I'm wondering if you can sort of, from that, talk a bit about what it is you and your team are building at Graft and some of the story behind how you hit upon this particular problem and the approach that you're taking to it. Adam is the originator of the idea for Graft, but I I think part of why what Adam presented resonated with me is that I'd also seen flavors of this too. What is this specifically? So I made mention that

data really was 1 of those key requirements.

For example, at Cruise, we were collecting all the simulation data and on road, all these sensors, all these derived things, like the car's perception of what objects were there, what were their kinematics,

and using that in this very,

like, self referential feedback loop to improve the car. But the operational bit of that was

1 of those secret sauces for Cruise. Like, they'd scaled out their fleet. They'd scaled out their simulation infrastructure.

I think

the kind of thesis origin idea of graft, and I think Adam can speak to that better in just a little bit when I hand it over to him, is this notion that there's these foundation models, these large very large, large, large, like, billions of parameters, sometimes

models that have been trained on such a rich,

wide, and varied corpus

of unstructured data. So a bunch of books and all of Wikipedia, or, you know, a bunch of images from these, like, very widely curated datasets. And from that, they've extracted out,

basically,

like, semantic

contextual

representations of that input.

So this, like, kind of canonical

baby version of this is you'll embed the word. You'll take king, for example, and you'll take man, and you'll take woman, and you'll take queen, and you'll embed all these words. And by embed, it means

you get this numerical vector representing it. I don't know. 20 dimension vector or something like that. And you can actually compare these vectors

in this 20 dimensional space. So you take, like, king and subtract the vector of man

and add the vector for woman,

and

then ask, how does this compare to the vector for queen? And you find if you've constructed your embedding generation correctly, those 2 will be very close. So there's this

semantic space that these vectors are living in that actually is capturing

semantics, like, emphasis on that semantic wall. Right? Like,

it's baking in these human language notions of how we choose to represent. And you see similar flavors of this on the image side, like notions of what is a dog or a cat or a bulldozer or an airplane.

And earlier on, there's various flavors of folks

seeing this power of this. So you'd hear these things like transfer learning for ImageNet trained models,

where they wanted to take models trained on ImageNet. ImageNet is really large,

1, 500, 000 images,

very large data set. It was used as a benchmark for a lot of computer vision challenges. They take these really fat models from Facebook, Google, whoever trained on that,

where the final layers of that model is like a class prediction, and it's very much tied to the dataset of ImageNet, like, what classes are represent there.

Chop off that last layer. So they're effectively saying, like, I don't want you to predict these classes.

Strap on a new layer

with

10 new classes that weren't in the original ImageNet dataset,

and basically train that model to essentially take all of its existing

representations it's learned

from all those n minus 1 layers and just learn this final bit of connection of given I see blobs here and this particular stuff in the red channel and the green channel and the blue channel of the image, let me learn how to translate that into

I'm not trying to predict

dog, cat, schnauzer,

bulldozer, whatever anymore. I'm trying to predict,

I don't know, balls or something. It's like some new class that wasn't represented in the original data. And they found

was very effective. So I think the 1 trend of AI recently has been like further

crystallization

and expansion of that idea of like, can these foundational models give you these models

give you these very generalizable representations,

and can you take that out at scale?

And companies like Facebook, Google, etcetera, are already taking it up to scale. They've put their money behind that hypothesis, and it's bearing a lot of fruit for them. And I think Graph is

maybe I can hand it over to Adam at this point, and you can speak to Graph. Yeah. Thanks, Brian. I think you covered some of the core technology shifts that kind of underlie

why now is a great time for us to be starting Graph. I can give a little bit of historical narrative flavor on top of that, which is to say, you know, if you look back 5 years

at how people were doing machine learning,

the workflow looked like you go and collect a ton of labeled data.

You start trying to train a model from scratch where you have to decide, like, what kind of model should I use? What hyperparameters

should I experiment with? Maybe I have to do a lot of manual feature engineering, and you kind of iterate

on that process going back to previous steps over and over again until you get something that's good enough. But over the last 5 years, some of the companies that Brian has mentioned

have started to converge around a very different technology stack where a lot of those steps are just no longer necessary.

And a lot of the machinery, the infrastructure for performing those steps at scale in production are also no longer necessary.

And so when I was head of machine learning at Slack, we said, hey. Can we leverage some of these technologies

like foundation models or embeddings

to drive some of the features that we were building there, like search and recommendations?

And so we did that. We downloaded a trunk model off of the Internet or a foundation model off of the Internet. We threw Slack's data through it, and we looked for nearest neighbors in this embedding space. And it worked great. We, you know, drove up search performance by something like 13%,

which was more than the aggregate improvements of the entire search team over several prior years.

And we didn't do any additional pretraining on that foundation model. We didn't train any downstream models.

And so, you know, here was this most impactful machine learning project ever at Slack, and it involved training no machine learning models.

And that was both gratifying in the sense that, you know, hey. These technologies really do work if you have the infrastructure for them. And it gave us the confidence then to say, alright. I'm gonna quit my job. I'm gonna leave slides in the notes, start this company.

Because what it meant was that this sort of now relatively narrow workflow compared with that old iterative sort of, you know, feature engineering and hyperparameter tuning kind of world,

that there was a fairly narrow path through the workflow now. And if we can take the infrastructure from Google and Meta, distill it down to its essence, and wrap it up in a usable UI.

Now any company can just come to graft and be able to do AI the way that these top AI companies do it, the sort of modern AI approach without having any prerequisites. So we're trying to build it so you don't need to be a machine learning expert or have 1 on your team, and you don't have any infrastructural prerequisites.

Given that set of capabilities that you're targeting, I'm wondering what are the

core personas that you are focused on addressing in the initial iterations of the product that you're building and how that

influences and informs the ways that you think about the user experience and the interaction patterns and the feature set that you want to prioritize as you're building this out, going through your initial beta phase, and starting to ramp up towards general availability?

I think they're broadly speaking 2 classes of customers that have found themselves attracted to graft.

So 1 class are the leaders in data or ML or engineering organizations.

And the appeal of graph for them is that if they don't already have this talent on their team, like ML engineering experts,

then they don't have to hire them. They can just use graph. And if they do have those teams, those teams can focus on sort of business differentiating

functionality

rather than the kind of plumbing and machinery

of AI. And so they can kind of skip ahead to the part where they take their data and solve a use case instead of saying, all right, we'll get this prototype out the door in 9 to 12 months. We just have to wire up these 20 different components together and make sure that it's working correctly. And then we'll try the thing. And so they get to kinda skip ahead and get more value out of the team that they already have. And then the other broad class of personas

are the sort of practitioners

for the use cases themselves. So not, like, necessarily ML practitioners or data science practitioners,

but, like, a product manager who just wants to understand, like, what issues with the product are being reported most frequently in Zendesk or whatever, or a BI analyst who just wants to understand the sentiment with which customers are talking about them on social media, or any number of other examples where you're a domain expert. Like, you know the problem you're trying to solve, and you maybe understand your data.

And it's really attractive to be able to wield these modern AI techniques at scale

without needing to understand that machinery.

And so those are, broadly speaking, the the 2 groups that seem to find graft attractive.

As a brief aside, 1 thing that I'm interested in addressing is so far, we've been using the terms ML and AI somewhat interchangeably, and I know that different people have different ideas about what the semantics of those terms mean, you know, which 1 is the superset of the other 1. And I'm wondering if you can just give your framing for why you choose the term AI and a lot of the material that you have on your website and how you think about that differentiation between what constitutes AI and when does it branch into ML?

I think we definitely use AI as the broader term.

Machine learning was more recently used to mean a more restricted subset of activities and sort of has more of an academic meaning to it, where AI is more broadly speaking just we wanna do smart things as a business or in a product or whatever.

And often that's driven by data. And it doesn't have to feel like

machine learning in the sense that, for for example, you might not train any machine learning models and have a really effective system that you could probably call AI. And so in that sense, it's a nice term to use both because it's broader and because it's less technical and a little bit more vague in a sense. And so you can capture a little bit more of the space when you use that term. Either 1 is fraught with peril as far as,

born meaning goes. TLDR,

100% echo what what Adam says. I think especially the fraught with peril 1, the latest flavor of that being this, like, Lambda model from Google that folks are claiming as sentient. And

there's a lot of, you know, fine

dicing of lines to do there. And and I think

some of those distinctions aren't necessarily that important. And instead, it's like, can you deliver

business impact and also to that prosocial bit? Can you really empower

these companies

who

would otherwise have this large barrier to entry? Can you really empower them to, like, get access to all that data and get to work extracting those business specific insights from all that data. Yeah. I wanna plus 1 to something that Brian said, which is I I think AI brings the focus a little closer to the problems that you're trying to solve

rather than the particular techniques you're applying to solve them, which I think ML as a term just sort of does naturally.

And that's certainly the graph philosophy is that you should care about your data, and you should care about the problem you're trying to solve. You shouldn't care too much about the stuff that sits in between.

So what I'm getting out of this is that if you're choosing which term to use, if you're talking to an engineer, call it machine learning. If you're talking to a business person, then call it AI.

I think it's not a bad year.

Alright. Well, maybe I need to rethink the name of the podcast if I wanna get a bigger audience.

Alright. Well so that diversion aside,

as far as the kind of capabilities

that you see as being unlocked by the potential of bringing

AI into an organization as part of the kind of list of tools that are at their disposal without necessarily having to go and invest in a team of PhDs and tens of 1, 000 of dollars in infrastructure and months or years of, you know, person hours.

What are some of those capabilities that you see as being unlocked by having AI in their toolkit?

There are sort of countless use cases that Graf enables.

I think by taking this position that if you build the right representations,

a lot of those use cases become trivial.

So, you know, we can point to things like search and recommendations

where you're broadly speaking just looking for nearest neighbors in an embedding space,

things like content moderation or predictive analytics or customer analytics, where you're broadly speaking predicting some property of the underlying data often from those same embeddings.

And so all these use cases kinda fall out if you get the representation. Right? But I 1 of the things that graft enables that a lot of organizations

don't have now because they don't have this infrastructure is the ability to do this rapid prototyping.

It's a really daunting

ask for a leader of any organization

to say, you know, here are these 5

AI initiatives that we might undertake

as a company.

And we don't know which ones will work and which ones won't, but you have to pick now. And then we're gonna go and build a bunch of infrastructure to support 1 of them, the 1 that you picked, and then we'll try it out and see if it works. So in 9 to 12 months, you'll get feedback as to whether you made the right choice. And so a lot of organizations just can't stomach that at all. So this is another kind of organizational barrier to entry for AI. And so in Graph, we say a lot that we're trying to make the first 80%

simple

and the last 20% easy.

So it's like the first 80%,

I should be able to articulate a use case and get that working end to end on the same day. So getting an immediate sense of whether or not this is worth investing more time in

by polishing the data or collecting more data or whatever that looks like. But you should know that

right now instead of having to wait until you are able to test it out next year. I would say 2 things I'd like to add to that. 1 of them on this prototyping bit

is

sort of the

tail end. The opening is the prototyping.

They're, like, kind of landing the plane part is all the production things,

monitoring for feature drift, like retraining models continuously as features drift, for example,

all that provenance management. So understanding what, when, where, why, when. So if you start getting, like, totally weird predictions

in production,

you can back trace to figure out all that. And that's actually another barrier to entry to folks too

and why a lot of ML infrastructure tooling is putting that very much front and center in their documentation. Because

initially, it was, can we even do this at scale period to get those prototypes? And now there's this, like, second wave of it. It's just like, okay. We have models that are deployed.

Can they work at scale continuously

in a sort of software maintenance perspective, that tail end of the software development life cycle. And graft isn't just focusing on the prototyping bit. We're also care a lot about the secondary bit too, this, like, continuous monitoring

and continuous updates to models.

The second thing I want to mention on the prototyping side is part of the feedback loop for model development

is very much a focus on that iteration speed. Like, it's not just that you prototype. Did I

improve x y z sales

or improve churn, you know, reduce churn by x y z amount or or whatever. It was also a thing of, like, even if you didn't buy a sufficient amount, you usually learn from that and know where to go next or

approximately where to go next in that sort of rough solution space.

So there's a lot of this saw this especially at Cruise. Like, we don't know what the best

self driving car architectures

and, like, dataset compositions, etcetera, etcetera, look like.

But by being able to quickly iterate

and figure out and test and validate hypotheses or not from a business perspective, Cruise is able to iterate very quickly and improve their models to the degree that they have. So I think graft also

to your question of, like, what do you get unlocked with this upfront investment? 1 of them is just, like, faster learning as a company

on your business problems, on your business domains.

Both of our answers to to your question, like, what are the capabilities that can be unlocked, have a kind of funny flavor.

It's, like, almost a reference to the things that, as an organization, you no longer have to do. You don't have to build a bunch of upfront infrastructure.

You don't have to manage and maintain that infrastructure in perpetuity.

But all of that enables you to then go and do all the other things that you as a business ought to be doing, which is learning and iterating and trying things out quickly and all of that stuff. Sort of funny way to answer the question, but I think that is a core value.

Going back to 1 of the things that you mentioned earlier on of the fact that a lot of the kind of ecosystem around machine learning and how to build these models, how to think about deploying them and training them and retraining them and monitoring them

is starting to converge around some maybe fuzzy set of best practices. You know, it's definitely still

evolving,

still kind of being explored and understood. But I'm wondering if you can talk to what you see as the

common themes across the industry of people who are

building and running machine learning at scale in production

and how that has changed from 5 or 10 years ago where maybe it was still very early, everybody was still at the frontier if they were doing it at all, and how the fact that there is this new kind of set of baseline

common

learning and

kind of package it up and hand it over to an organization so that they don't have to understand what those lessons were and how we got to where we are today?

We've been sort of casually trying to coin the term modern AI, and I and I think that encapsulates

a lot of the kind of hallmarks of this new way of doing ML that we've observed to be so effective at certain companies.

And I'll name 3 of them. So 1 is just a use of all of the data.

So, historically,

if you had unstructured data, like text or images or graphs or video, you would turn it into structured data first and then try to use it that way. And often that was ineffective and time consuming.

And now we have really good ways of working with unstructured data at scale. And so you see companies that basically use all available data.

And to be clear, this is not a small shift. Like, night something like 90% of all data is unstructured.

So being able to make use of that is a huge win.

The second is that these organizations

that are really successful with AI are not starting from scratch.

We've talked about foundation models, these sort of large pretrained models, you know, in the the text or language space. You've probably heard of things like BERT and others of these large language models.

That's just 1 example of not starting from scratch, though. You know, graph is certainly example of not starting from scratch from an infrastructure perspective,

but we also have something that we call enrichment models.

And these you can think of as predictive properties of the underlying data, like sentiment on text as a canonical example of an enrichment model.

And there have been probably millions of sentiment models

trained independently

over the years, not just by people learning to do ML, but in production,

someone who says, like, I really just wish I had the sentiment on these tweets. And so they go and they try to find this labeled dataset. They start from scratch and start to build this from nothing. But for common enrichments like that, those are just included in graphs, and so you just apply them to your data. Just a quick anecdote here. I took a course with Marvin Minsky way back in the day, and

he is prone to hyperbole.

And once said that

robotics

PhDs

who are sort of doing AI in the robotics space,

who would spend maybe the first 5 years of their PhD

building the robot.

And then the last, you know, year or 2

thinking through, like, the algorithms and the mechanics of it. He said that that was sort of tantamount to murder. Like, if you looked over all of the robotics PhDs and you added up all the years that they had wasted, figuring out, like, what servo do I connect to the whatever,

that it was, like, you know, human life wasted.

I think something similar going on here with someone training a sentiment model from scratch. Like, it's been done a 1000000 times before. There's no reason you should waste your time doing that when there are real business problems unique to your business that you should be focused on. And that's maybe the last 1 that I'll mention. The hallmarks of modern AI is this focus on the business specific pieces instead of the plumbing.

So think about the data, and this is an example of data centric AI for sure. Focus on the use cases,

like get the the UX right, things like that.

More in the weeds details I can add on top of that.

To this data centric AI part in particular, the initial

treatments of ML, like, people

recognize just by sheer virtue of, like, the syntax of training these models that you had to have training datasets.

But this kind of treatment of datasets as first class citizens

as well as the models themselves

And this understanding is, like, they're inextricably

linked. Like, you literally cannot have models without the other. Like, it's not just standard software where the source code by itself

is sufficient to describe the resulting

binary application,

you know, given compiler flags or whatever. That bit of it is this kind of

continued understanding and growth of support of datasets and management of that and their semantic relationships to the models derived from them.

Speaking of data, the other bit of it is this continuous

orchestration and updates to models, features drift.

You know, COVID

tanked, I'm sure, a bunch of people's models, and they certainly, like, screwed with our models that cruise, for example, like, oh, pedestrian density is completely different now.

So

the understanding and, like, continued improvements on this orchestrator

is basically you saw this.

Sure. I'm forgetting

proper product history, but, like, Airflow is this kind of initial Lynch, and then there's been a lot of evolution in that space from there. Things like DAGSTER,

prefix built on top of DASK initially.

You know, I don't wanna turn this into just like a product rap sheet of orchestration engines, but there's all these orchestration engines coming out there. And a lot of them, like, targeting that exact thing of, like, continuous ML, continuous updates,

recognizing that that's an integral part of the solution too is these models have to

evolve to continue to meet the business requirements.

Yeah. Those are definitely all very useful

aspects of, you know, thinking about how do I approach this problem, what are the things that I can build on top of now, and thank you for giving me a list of products that I can link back to my other podcast for people who wanna find discover it in the other direction.

But

in all seriousness,

in terms of the actual

kind of

execution

of being able to provide these models as a service to the business, give them access to saying, okay. You have all of this data that is inherent to the way that you do business. Now you can actually gain some additional value from it without having to, you know, have, you know, a dozen interns spend their summer labeling information that maybe will be useful to you in 6 months. Wondering if you can talk to some of the actual

implementation

and design of the product and how you think about building these interfaces in a way that is accessible to

the cohorts that you mentioned at the beginning of, you know, data leads who don't wanna spend their high valued ML engineers' time on prototyping

or

business users who just want to be able to get the product out the door, but they wanna be able to use their data to actually add some additional intelligence to it? So I think 1 of the first bits is

aggregating and collecting all that data, not aggregating in, like, a SQL sense, but really just bringing all that data into 1 spot. So that's sort of the entry point of graph is

flexible

notion of a connector, and this can be connecting to

databases, MySQL, Postgres, or even data warehouse, like Snowflake, Redshift, etcetera.

But it can also be more to the unstructured bit, like

more arbitrary, yes, if not already business owned things like buckets in s 3,

the public Internet, like,

to Adam's mention of predicting sentiment of tweets, like crawling through Twitter and and getting the latest tweets that mention at Nike or at x y z company.

So this sort of funnel, this data intake funnel to let us bring all the data that the user's interested in into 1 spot,

views of that data so we can sort of give them that picture.

To the bit about a persona being like a data engineering or the business practitioners where they already have that domain expertise on their data.

We can't automagically

understand

what all the data means for someone. So there is, like, a little bit of, you know, are these 2 streams related to each other? What's a foreign key relationship to join them together

from our side if we need to process both of them at once and ensure they're synchronized with 1 another? So there's a little bit of configuration there,

And then you enter into this ML magic part based on these foundation models generating these embeddings, potentially

already pretrained enrichments.

A lot of that is basically focused on under the hood from our side to give us the flexibility we need. Notions like a generalized job scheduler,

generalized

farming out to compute on Kubernetes.

So

kind of a set of various microservices deployed on Kubernetes

where we can go, okay.

These embeddings are ready. Our job schedule has a notion of this dependency graph. We've ingested the data. That was our first job. We now know based off what the user has given us that it's text data, and we need to use BERT versus its image data. Let's use the latest ResNet flavor.

So there's a lot of

this dynamic dispatching

in that job dependency graph, dynamic dispatching.

And, of course, speaking to models being

models and often expensive, wanting GPUs for inference, there's also dynamic dispatching in the

hardware and, like, heterogeneous

compute cluster sense,

too. So relying on these tools like Kubernetes, which have this flexibility

very natively baked into it Dask is another technology we're using a very flexible distributed job scheduler.

And, you know, not to give them too much of a plug. I mean, they're great. But, you know, it's this key bit of, like, using underlying technologies that give us flexibility to ultimately

do what we need to do,

and not even just for the use cases we know about. Like, we have these

ideas from talking with customers, from our own experiences of use case involving beddings, a particular

computational graphs workflows to do, but also giving that flexibility to iterate. I'm sure there's gonna be things that surprise

us a lot. Like, once we actually get this out there in GA,

oh, someone's using it to do x, y, z thing? Like, woah, that's interesting. Like, let's harden the support for that a little bit. So let's iterate a little bit on the underlying infra.

But, yeah, I mean, Kubernetes, DaaS, these kind of key technologies, open source technologies especially,

that let us build out those components,

speaking to Adam's mention of focus on business specific

pieces. Like, we wanna focus on our business specific pieces too. We don't wanna

build out another

generalized resource manager or

generalized job scheduler or generalized database tool. Postgres is amazing for, you know, what it is. It's become this tremendous

place in the database ecosystem. So all these things where we just basically build on top of technologies and let ourselves focus on that critical iteration of developing the product and giving customers the flexibility they need.

1 thing I'll note that's interesting about Brian's answer, I think if you step back and you ask someone, like, what pieces do you need? What components do you need to do modern AI?

It's like, well, I need, you know, an inference service to compute the embeddings from the raw data, and I need a place to store those embeddings. And they would list out maybe half a dozen components.

But a lot of what Brian was describing, I would refer to more as like glue code

or sort of overlaying

systemic kind of code

that cares about the aggregation of all of those different components and the ways that they interact with 1 another.

I think it's really easy to underestimate,

first of all, how much work it is to get all that glue code and overarching functionality in place,

but also how important that is

to be able to do this in production and trust what it's doing.

So, you know, having a place to stick an embedding is fine, but you need to know where that embedding came from and what you're gonna do with it downstream. And often there are dependencies that go end to end through this entire system

that you need to care about. 1 example I always use is if you're trying to be GDPR compliant

and someone says, hey. Delete my data. Well, if that data was used to train the model that computed the embeddings and the embedding space updates, which means any models you train from that embedding space have to update. And so it propagates through the entire system,

and none of those individual components

have any knowledge of the rest of the system that would enable them to do that for you. So you still need to understand all of these subtleties and implications if you're trying to build this for yourself.

The thesis of Grafth is that for almost no company, is it a worthwhile investment to be building this infrastructure themselves.

Predabase is a low code ML platform without low code limits.

Built on top of their open source foundations of Ludwig and Horovod, their platform allows you to train state of the art ML and deep learning models on your datasets at scale. The prediabase platform works on text, images,

tabular, audio, and multimodal data using their novel compositional model architecture.

They allow users to operationalize models on top of the modern data stack through REST and PQL,

an extension of SQL that puts predictive power in the hands of data practitioners.

Go to the machine learning podcast.com/predabase

today to learn more. That's predi

b a s e.

Another interesting element

of what you're doing is the fact that the machine learning space is still in a very rapidly evolving cycle where it seems like every week, there's a new large language model or a new large image model or, you know, now we're starting to move into other types of data

and more communities are starting to see, oh, you know, this deep learning thing might actually solve my problem that I've had. So let me see what happens when I throw all of my data from the Large Hadron Collider at it, to go back to your example, Brian. And because of the fact that it is such a rapidly evolving space, it is a moving target

for you as a company to be able to say, okay. We support x approach to machine learning so that you can do y with that model to be able to solve your business problems.

And I'm curious how you think about the balance of

we want to be able to use these new capabilities that are coming about as researchers

push the boundaries of what machine learning can do, but we also wanna make sure that it doesn't crash at 2 in the morning so that all my engineers have to wake up in firefighting mode.

Yeah. I can give a kind of high level answer, then maybe Brian can dig into some of the lower level technical strategies. But I I think we are solving it the way that many people solve many problems in computer science, which is a layer of indirection.

So we are building graph from the thesis that you're trying to build a good representation.

And in graph, that representation is something we call the call an entity.

And an entity is a reusable,

dynamic,

multimodal,

sort of bucket concept for whatever is important for your business. For example, it could be a product or a customer or an employee.

And a lot of the mechanisms for how you stitch together

disparate unstructured data from a variety of sources

and turn that into a single representation for a customer or product.

That's what's going to evolve and what we'll be continuing to support.

But, conceptually, you're still trying to get to the same thing, which is to have this

entity that you can ask questions about in an efficient way. As these models continue to evolve as the particular inputs and outputs shift and whatnot,

the flexibility on the infra side, like, things like modularity and composability of of the individual components

is very, like, paramount to giving the engineering team the flexibility

it needs.

But it also gives customers some amount of flexibility too. Like, there will be some customers who are interested in particular

versions of Bert that they further pretrained on a bunch of scientific papers, you know, COVID papers because they're trying to study something about

long term COVID.

So this is work to kind of give these

modular components also on the ML side and the ability ultimately to have this funnel into a notion of an entity, which is capturing that domain focused representation,

collation of data,

getting into a bit more details on the infrared of that, you know, paying homage again to Kubernetes, giving us that flexibility for very heterogeneous

cluster setups from

hardware and and other resources, memory, etcetera.

I think there's also

internal to graphs, the notion of, like, a flexible representation

of what we're trying to do and, like, notions of the semantics of each of those steps. So, like, what does an ingest

step look like? What are the semantics of it? What are the requirements of it?

And these hierarchical

layers of that. So it's like, if you want

this model, like, we the customer has asked for

this x y z enrichment model that is not pretrained, so we can't just pull 1 off the shelf.

Okay. Well, they've pointed us to the training data. We know what embeddings it came from. So we can kinda turn this into, like, a data flow graph of, like, the actual

corresponding computational graph you have to resolve

to supply that given what the customer has asked. Enrichment was going a bit further. I mean, that, of course, would apply to these entities to this entity. The customers told us is built off of this data,

some images from s 3, some table of metadata from a MySQL database.

We know this, like, dependency chain of how to resolve that.

And,

you know, I'm gonna kind of be a broken record here. The flexibility of how we resolve that being open to us too

is another bit of it. Like, the data is a thing that is gonna be very business specific, very use case specific.

Those entities as a sort of

user configured,

again, collation of that data, also domain specific, user specific, etcetera,

our representation

intermediate representation we have, like, in a literal computational graph, and sometimes

can ultimately be executed

and optimized, etcetera, etcetera,

with whatever the latest trends are, latest,

greatest

version. You know, Kubernetes

2.0 or whatever new

flavor of resource manager, distributed job scheduler,

database technology, etcetera, comes out,

we'll have, within reason, some amount of flexibility

to pivot to that if it makes sense.

We're certainly trying to skate where we think the puck is going. So Yeah. Yeah. Predicting that we'll see more multimodal models, and we'll see more multitask models, and more real time use cases, and so on. It's a difficult field

to do a lot of prognostication in given how quickly it's moving, but that has certainly been our goal. You know, of course, this applies to anyone looking to build this infrastructure in house as well. You can say, no. We're gonna go it alone and spend tens of 1, 000, 000 of dollars building it out internally only to find out that your prediction was wrong. And so now if you wanna solve it using really modern technology, you have to start from scratch again.

Speaking now to a, you know, concrete workflow of,

I have my source data. I want to build some intelligent use case around it. I am going to go to graft. Just walk me through

maybe the canonical example is the kind of customer churn prediction model. I don't know if it's more interesting to talk through kind of a off the wall example that I'm considering for myself. Let's maybe say I I don't know if you're familiar with the card game Magic the Gathering, but it's a trading card game, lots of different cards, lots of different sort of rule bending specifics about each card, lots of different ways to compose the decks. I found out recently that it's actually in the Guinness Book of World Records for the most complex game in the world, recently surpassing Go.

So I want to take a list of all of the winning decks from the most recent tournaments for the past, let's say, 2 years,

build a model around that to then say, okay. Here are the list of cards that I possess. Tell me what deck to build.

Well, I'll talk about the customer churn, use case first. Although, I'm really interested in this Magic the Gathering use case, so we should we should talk more later. Maybe I'll I'll think about that in the background.

So so broadly speaking, the workflow in graft is that you configure some number of connectors to point to your data wherever it is. In this customer churn example,

you might be pulling the audio of customer service calls from something like Intercom

or s 3. You might be pulling notes from your sales team out of HubSpot or Salesforce,

maybe

trouble tickets that customers have submitted via Zendesk.

And then you define a customer entity, and you say that it includes all of that data, all of that unstructured

multimodal data.

Optionally now, and in this example, you would want to apply an enrichment to it, specifically churn prediction.

Now this is business specific enough that it's unlikely that we're gonna have a prebuilt enrichment

for customer churn. But the way that you define 1 of these enrichments in graft is that you just give a table of examples.

So you would just say, here are the IDs of 20 customers.

These 10

are solid customers. They're not going to churn, and these 10 did churn or will churn.

And Graph will then build that enrichment for you and will apply it to any future customer entities

that get ingested.

So you can now it's another column associated with these customer entities

that you can then ask questions about.

And that's kind of the last step after you've configured the connectors, stitch it together into entities, and applied enrichments

as you ask questions or answer questions with it. And there are generally 3 ways that you can do that in graft.

The first, which is great for more kind of interactive use cases, is that you can use SQL with some moderate extensions to allow for nearest neighbor search and that sort of thing. There are APIs for production use cases. So if you wanna wire it up to a web front end or something, an internal tool for sales or what have you, then you would use those APIs.

Then there's an alerting framework. So if you want to take automated action of some kind based on a prediction,

like, if a big account is predicted suddenly to churn where it was not last week, you wanna get an email or or maybe more than that.

I'd love to speak to the Magic example. I've been thinking of it. I've played Magic for, like, 20 years, so this actually immediately got my head's

gears turning and whatnot.

Let me frame a particular

problem or, like, sub flavor of the magic problem.

Given I have these cards available to me let's actually first not talk about that. Let's say I have any cards. I can choose to build any deck.

Thing that pros regularly go through in the game is what deck should they bring to pro tour x x y z or some world championship.

And it's very much dependent on the meta game that they're gonna encounter. So it's like, if a bunch of

low to the ground

red decks

where they play a lot of small creatures and try and burn their opponent out by flinging fireballs and lightning bolts at them, If a bunch of those decks are gonna be there, maybe you wanna be this other kind of deck that sets up a lot of barriers and

gains a lot of life to counteract the damage.

Hopefully, it's not too much magic jargon.

But, of course, like, if a different type of deck is gonna be heavily represented at that tournament, a different other deck would be better as, like, a metagame killer. So with that kind of idea in mind,

I don't know exactly how I do this because this is more on the ML science side, but assume I can get a notion of embeddings for individual cards.

So given I have this card called lightning bolt that deals some damage to an opponent, I can turn that into an embedding

and assume as well that I can then combine those embeddings from all the cards to get a notion of an embedding for a deck. So I can give you the single number that represents a deck. I can take a bunch of historical data, so I could crawl through all the Wizards of the Coast data. They actually don't release that much of it, unfortunately,

but there's some third party sites. I could crawl through all that data,

get the actual mass histories for individual decks. So I can directly turn this into, like, a regression model

probability

through graph. I I know I could do this. If I have embeddings for a deck and I have that historical data, I can essentially label

individual match records who won, which won, and learn an overall probability,

basically.

Given I have this deck and I'm facing this other deck, what's the probability of winning? So given I have a notion of this deck embedding and I can take, like, a red deck and assume that, you know, 1 or 2 card differences, it's gonna be similar enough in that embedding space to another red deck,

and I know what these learned probabilities of winning from 1 deck to another are,

then the final piece of the puzzle is, like, some notion of, like, an expected meta game. And that's, like, another thing you could learn, like, what the statistical composition

of a metagame will look like. Here's a target deck I wanna

bring to this.

What's my

overall, like, EV of winning the whole tournament?

It all kinda gets predicated on this notion of the deck embedding part of it. Like, can I build a reasonable semantic representation of a magic deck in this embedding space? But assuming you can do that, the rest of it kind of falls into place. It's just various flavors of connect to some

public Internet data of, like, match win histories of individual decks,

connect to some

or feed it yourself some expected meta game. Like, this is my what I guess other pros will be playing in rough,

you know, distributional sense.

And you could get graph to say, okay. Given all this, like, your best deck is x y z thing.

So there's your alpha MTG.

You just need the datasets, and we're good to go. Yep. It's definitely a problem that I've been thinking about because I've been getting more and more back into magic now that my kids are old enough to be able to play along with me. And so that was something I was thinking about is, like, this might be an interesting summer project. And then as I thought about it more, realizing this is actually really complicated, and maybe I should wait a few years before I try to introduce this problem.

Yeah. There's been some fun stuff in AI generated magic text where they did, like, language modeling on this corpus of the actual rules text of magic cards

and then ask this AI to,

hey. Give me a valid

creature, blue creature, and it comes up with some totally off the wall things. I think I came across the same thing you did recently. I poked at it a little bit, and I was like, this is very weird.

It's definitely interesting, the types of things that you can conceive of once you start to think about, okay. Well, if I have the data, what are the things that I can do with it? Which brings me to the question of

as you are bringing this tool of graft to

end users, whether it's in business or in sciences or whatever the specific industry vertical that they might be in,

it's often challenging to understand

what are the things that are possible with machine learning and what are the things that are actually still impractical,

and how do I understand the differences between them and when I go, you know, sometimes very quickly from this is eminently possible to this will take until the heat death of the universe to figure out and how you think about educating

end users about what types

of use cases they can actually power with machine learning and with what you're building at Graph?

Yeah. I think it's a really interesting question with a ton of nuance.

First of all, answer the question and then talk about some of that nuance. So 1 thing that we try to do in GraphTIS is the have the UI kind of guide users

to get to this

representation,

this entity.

Because from there, they have kind of maximally

broad choice

as far as what sorts of problems they can solve with that representation.

We try to get them to that point so that they can then go off and do search and recommendations

or content moderation or customer service analytics or whatever it is. There are other challenges, though. For example,

when trying to talk about what is possible,

which is there are things that are possible or not in general, and then there are things that are possible or not for a particular customer with their particular data.

And that's sort of a variation of a question that machine learning folks get all the time and that there's never a satisfying answer for, which is, you know, how much data do I need for this to work well? And there's never gonna be a good answer to that question. It's always gonna be it depends. But what we can do for customers is help them just try

it much faster. So that's usually the way that you get an actual answer to that question is you just try it and see how well it does. And that's that first 80% that we talk about. You should be able to wire it up, see whether it's working okay, and have that answer instead of someone being, like, I don't know, 20 examples? 2000? I'm not sure. Throughout the draft UI, we also try to give contextual hints as far as what things can happen next.

So, oh, you've embedded this field. You can do semantic search now.

Here's a button that if you click it, it will bring you to the SQL tab and auto generate SQL that will give you that semantic search.

So things like that, I think, are kind of locally helpful.

But this is, I think, a really a great question and and really difficult to answer in any sort of completeness.

It's definitely an interesting problem because if you don't know enough about what a tool does, then you don't know what you might be able to do with it. And so a lot of times, it can be interesting to see businesses

who, you know, on the 1 hand might say, oh, machine learning can do anything. So I can obviously use a machine learning model to predict what my sales are going to be next quarter.

Whereas somebody else might come to machine learning and say, I don't understand enough about what it does. I don't even know what I might use it for. And so just trying to figure out, like, how do you find kind of middle ground for both of those people to be able to say, okay. Here's your data. These are some things that you can do with it, and then helping them explore that space of possibility.

1 thing that we're building

are sort of this notion of guided flows, which is identifying these

common classes of use cases that we can really hold users' hands through from beginning to

end. And I think we will continue to build those as we identify these classes of use cases that we find customers applying it to. You know, on the other hand, I think there is a fat long tail of use cases

that as Graph goes out into the market, we will find customers doing that would never have anticipated.

And it's hard to know how to have told them ahead of time

what sort of things to look for in their problem that would suggest that it would be a great fit for graft. We found it to be hugely versatile as a technology, and I think companies

like Google and Meta have found this as well. They use it for personalization and

recommendations and so on and so forth. So I think you can get a lot of them, but, yeah, it's always possible that someone comes up with some new use case that we just haven't thought of that requires some fundamentally different underlying mechanics.

I think Adam's answer is great for capturing those kind of

this semantic space of use cases that we're not necessarily

aware of, like unknown unknown

use cases.

I think even within a particular use case, there's gonna be a flavor of, like, can I get a model that gets a 100% accuracy?

Probably not. So there's, like, gonna be an element

that still tricky to convey to users. Like, no. You can't get a model that gets a 100% accuracy or, well, you could in theory, but it's very dataset

dependent, very composition dependent.

So I think there'll be a lot of iteration for us to do. This is kind of a smaller set of that problem space of what is practical to do with ML. But there'll be a iteration on this even at that lower level of, like, okay. Given the label distribution, given the decision boundaries we're seeing between these labels, we're not necessarily gonna communicate that level of gory detail back to a user,

but we can

guide them on what's realistic with their data, for example. Like, they might say, I'd like to get a model that has

per class average precision of 95%

or something like that. And you could

both, 1, give them realistic expectations for where they are, and then it's very data centric AI flavor. You could also point them to, like, these are parts of your sample space, or these are actual unlabeled examples that you should best,

like, spend all your labeling ops effort if you wanna push the needle in this particular direction.

So there's a lot of this active learning and and other flavors of

very much a data centric AI approach

that you can bring as, like, a subset of tools to help people understand what's actually

doable

and guide them to that goals that they have. Not just at the high level guided flow stuff Adam mentioned, but, like, within a particular workflow,

moving the quantitative needle on some key metrics that they have have interest.

Now given the fact that you are still very early in your product journey, you haven't released to the general public yet, but you have had some opportunity to work with some of your early design partners and beta users. I'm curious. What are some of the most interesting or innovative or unexpected ways that you're seeing the

ways that you're seeing the Graph platform used?

I I think there are a lot of bread and butter use cases that I think are still interesting despite being kind of bread and butter.

So, for example, 1 of our design partners does document intelligence in the health care space.

And so to do that well, they need to do, for example, additional pretraining

on the foundation model to learn the vernacular of that particular domain.

And then they have

a variety of interesting types of questions that they then want to ask about those resulting documents that are really specific to their business.

I find that interesting because there are all sorts of questions around,

technically, how do you do that additional pretraining in a way that is going to to satisfy those downstream queries without necessarily knowing them ahead of time? But, again, I think the long tail 1 off use cases

is where I'm most excited to see people use Graph. As you said, we're very early,

but that is sort of exactly the cohort for which no 1 is ever gonna go and build a vertical solution because there just aren't enough customers that have that use case.

And they often are small enough that they're not going to hire a machine learning team build this infrastructure.

It's a use case that exists.

It's extent in the world,

but it will never be satisfied unless they can get something like graft in house. And so those are the things that I'm excited about. That's a little bit vague, but I

I'm excited for what's to come. In terms of your experience of

launching the Graph platform and building it and starting to work with some of your early customers and exploring the space of how do we

condense

this space of machine learning into something that is usable and accessible to a broader audience, what are some of the most interesting or unexpected or challenging lessons that you've learned in the process?

UX and and UI

are hard

in in this space,

partly because there are not a lot of great

predecessors

from whom we can crib.

So,

you know, figuring out the UX for doing this modern AI workflow would just there's not a lot of examples we can point to where we could say, hey. This was a really good paradigm. Let's, you know, lift that and and use that in graft. And so I think there is a ton of challenges related to how to embody that workflow in a UI

and even down to some of the terminology

like foundation is it a foundation model, or is it a trunk model, or is it a large language model, or is it a pretrained model, etcetera, that even just deciding how to name things in a UX, it's gonna be

understandable to ML practitioners,

but also

intelligible to those who are not. Yeah. So as I say, big plus 1 to the UX UI challenges. I think the building this

mutually understandable shared vernacular

using existing ones when it makes sense, but sometimes having to coin things ourselves if we need to reach this broad enough audience

and have everybody on the same page,

Totally, totally a big challenge. I think from the engineering side, there's just scalability

challenges that come into play. Like, you try and operate at very large scale on very large datasets. You're always just there's plenty of vagaries to distributed compute.

I wouldn't say it's unexpected, though. Like, yeah, I saw it. Cruise, we had massive amounts of data there, and

I saw flavors in which even GCS could fail sometimes, you know, for a particular region. So

it's like a known known

versus like an unknown unknown.

There is an known unknown bit of it of, like, you don't know the specific way in which a large scale distributed compute system is gonna fail on you. So it's a lot of

foregrounding

of tolerance and resiliency

and all these, like,

flavors of

best practices

when building out large scale distributed systems that were very much

have top of mind

in addition to all the things, the challenges, the very product specific challenges,

the UX UI, the supporting back end that gives us a reasonable data model between back end and front end to be able to iterate on the front end from the UX UI perspective.

And so for people who are interested in exploring the possibilities

of adding machine learning to their set of capabilities,

what are the cases where Graft is the wrong choice and maybe they are better suited building it in house or using some other, you know, purpose built machine learning as a service, like something that's dedicated to audio transcription, for instance.

Graph is a cloud native

managed service.

So, you know, the first class of use cases for which it's not appropriate is any context in which, you know, using a third party cloud service is not appropriate.

So, for example, real time use cases with very tight latency requirements,

like, I probably wouldn't, you know, build a self driving car that's, like, calling out to the cloud to decide whether to hit the brakes or not. That's certainly 1 class of them.

Or in cases where sending data in any form to a third party, especially your sort of business data, is not appropriate.

We don't offer a self hosted option at the moment. And so if you're not okay

sending stuff up to AWS or similar, then you're probably not gonna be okay with Graph either.

With a distinction between the 2 of, like, we'd be hard pressed to solve the first 1. I mean, even then it's an engineering challenge. You could imagine just deploying a flavor of graft in an embedded device to do these to, like, use embeddings to make real time decisions.

And it certainly would have a very elevated level of requirements.

So, you know, okay.

Put that on a shelf. We probably won't even touch that ever.

Certainly not for the foreseeable future. I think the self hosted thing

is a lot more tangible as a

okay. This is a bridge we might readily cross need to cross in the near future. I can't give you an exact quantitative timeline, but I think there is a semantic distinction between those 2 as well of, like, probably will never ever do,

reasonably might do. And then there's maybe 1 other,

class of AI applications, which are ones that you have sort of no future in production.

Like, it's just a 1 off question on a very small dataset. Maybe it's all tabular. You just do it on your laptop, And you just want to know, like, is it 0 or 1? And often, you can do that without needing any of the production infrastructure that the graph is bringing to the table. Doesn't necessarily mean you can't solve it in graph. It just means that graph is probably overkill for that.

And as you continue to build out the product and going through your beta phase as you approach general availability, what are some of the things you have planned for the near to medium term or any particular problem areas or projects that you're excited to dig into?

I think there's a lot of active research right now on multimodal

models,

very commonly focusing on, you know, audio and text

or images and text or and see sort of canonical

natural data

modalities.

I think the flexibility of graph though to do more arbitrary

combinations of modalities, like a notion of

customer data that's feeding in text in Zendesk with

other

flavors, cut literal transcripts from customer service calls or tweets from this customer

or more general sentiment from customers.

The exact

ways in which you best build that multimodal

representation,

actually going back to that magic example, like, not magic specifically, but this more general notion of, like, how do I take

semantically

distinct unstructured data, even, like, sub cohorts within the same higher level modality, like, different kinds of image data, different kinds of text data,

and

build a, like, cogent,

concise,

generalized

representation.

There's a lot of ML science bits of there that I'm personally excited to either

contribute to directly or at least osmose from as we work with excellent ML scientists at the company to figure

out. Because this is also, like, this active area of research at Meta, at Google, at at these big modern AI companies.

Are there any other aspects of the graft product or the overall space of making ML and AI accessible to end users and organizations that we didn't discuss yet that you'd like to cover before we close out the show? I'll just say that this vision of making the AI of the 1% accessible to the 99%,

I feel comfortable saying is fairly ambitious.

So there is a long way to go from where we are to realizing

that vision. So I think there are a lot of interesting challenges that we'll encounter along the way. I'm really proud of the progress that we've made in such a short time for sure, but there's certainly a lot to do. Big plus 1. Alright. Well, for anybody who wants to get in touch with you folks and follow along with the work that you're doing, I'll have you add your preferred contact information to the show notes. And as a final question, I'd like to get your perspectives on what you see as being the biggest barrier to adoption for machine learning today. I know that we talked about that a little bit, but I'm curious if you have any more context or flavor or specific examples to call out. I think talent and infrastructure

are the most common barriers to entry. Especially if you're trying to do modern AI, you almost certainly don't already have that infrastructure.

In order to get it, you would need to hire a team to build it. And so that is sufficient as a barrier to entry for most organizations, and those are the 2 that we are most focused on in in building craft.

In addition to that, just kind of a note, this isn't a currently existing barrier, but to go back to this foundation models, trunk models, whatever you wanna call them,

availability of data

used to be like this

oft insurmountable

barrier. Like, you needed 1, 000, 000, billions of examples to get to these training these really large models and also the corresponding compute to process all that. There's still

flavors of that, like, a much smaller scale version of that. So there is still an element of, like, people should care. Like, businesses,

business leaders

should care about the data that they're collecting and how do they think about the data model of it.

And it's very much a

barrier you can easily traverse if you, like, put some work upfront to think about it. But if you don't, then you end up with a kind of big ball of mud of data, and it gets very messy. And it's very hard to work back from.

So, yeah, that's kind of like a warning in a way and another barrier to entry.

Alright. Well, thank you both very much for taking the time today to join me and share the work that you've been doing at Graft and your overall vision for

its progress and future. It's definitely an exciting platform and exciting problem space that I'm excited to see where you go with it and, how far you're able to take it. So thank you for taking the time today to join me, and I hope you each enjoy the rest of your day. Thank you so much. Thank you so much for having us. This was a lot

of

fun. Thank you for listening. And don't forget to check out our other shows, the Data Engineering podcast, which covers the latest in modern data management,

and podcast.init,

which covers the Python language, its community, and the innovative ways it is being used. You can visit the site at the machine learning podcast.com

to subscribe to the show, sign up for the mailing list, and read the show notes. And if you've learned something or tried out a project from the show, then tell us about it. Email hosts at themachinelearningpodcast.com

with your story. To help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.

AI Engineering Podcast