Build A Full Stack ML Powered App In An Afternoon With Baseten

WEBVTT
NOTE
Transcription provided by Podhome.fm
Created: 7/6/2024 5:34:47 PM
Duration: 2722.451
Channels: 1
1
00:00:13.264 --> 00:00:24.580
Hello, and welcome to podcast dot in it, the podcast about Python and the people who make it great. When you're ready to launch your next app or want to try a project you hear about on the show, you'll need somewhere to deploy it. So check out our friends over at Linode.
2
00:00:25.175 --> 00:00:32.475
With their managed Kubernetes platform, it's easy to get started with the next generation of deployment and scaling powered by the battle tested Linode platform,
3
00:00:32.870 --> 00:00:38.890
including simple pricing, node balancers, 40 gigabit networking, and dedicated CPU and GPU instances.
4
00:00:39.670 --> 00:00:48.695
And now you can launch a managed MySQL, Postgres, or Mongo database cluster in minutes to keep your critical data safe with automated backups and failover. Go to python podcast.com/
5
00:00:49.650 --> 00:01:01.965
linode today to get a $100 credit to try out their new database service. And don't forget to thank them for their continued support of this show. Your host as usual is Tobias Macy, and this month, I'm running a series about Python's use in machine learning.
6
00:01:02.345 --> 00:01:09.470
If you enjoy this episode, you can explore further on my new show, The Machine Learning Podcast, that helps you go from idea to production with machine learning.
7
00:01:09.850 --> 00:01:12.670
To find out more, you can go to the machine learning podcast.com.
8
00:01:13.814 --> 00:01:17.435
Your host is Tobias Macy, and today, I'm interviewing Tuohin Srivastava
9
00:01:17.814 --> 00:01:24.140
about Base 10, an ML application builder for data science and machine learning teams. So, Tuheen, can you start by introducing yourself?
10
00:01:24.680 --> 00:01:31.884
Yeah. Hey. I'm Tuheen. I'm the CEO and 1 of the cofounders of Base 10. I have a background in machine learning, have been
11
00:01:32.424 --> 00:01:35.645
founded a couple of companies. I've been working on Base 10 since 2019.
12
00:01:36.104 --> 00:01:39.450
And do you remember how you first got started working in the space of machine learning?
13
00:01:39.930 --> 00:01:40.909
In 2012?
14
00:01:41.289 --> 00:01:46.909
No. 2011, actually, I was working in finance, pretty unhappy in my job. I studied electrical engineering
15
00:01:47.815 --> 00:01:49.915
in college and done a bunch of information theory.
16
00:01:50.534 --> 00:01:57.275
I was looking to figure out how to get out of finance, and I came across this opportunity to go do research with a neurologist in
17
00:01:57.640 --> 00:02:03.180
Boston who was trying to figure out how they can use noninvasive biomarker to track the prog progression of
18
00:02:03.560 --> 00:02:04.780
neuromuscular disease.
19
00:02:05.165 --> 00:02:11.265
So I went over there, joined this lab company, and, you know, we end up doing a bunch of really cool stuff and around predicting
20
00:02:11.885 --> 00:02:19.640
onset of disease and how that disease progressed. He published a bunch of papers, worked on a small company with regards to and, you know, I was off to the races.
21
00:02:20.260 --> 00:02:38.340
And so in terms of what you're building at base 10, can you give a bit of an overview about what you're focused on and some of the story behind how it came to be and why you decided that that was a problem that you wanted to spend your time and energy on? Based on the machine learning application builder for data science and machine learning teams, I think the best way for users to think about
22
00:02:38.720 --> 00:02:40.500
base 10 is kinda like a toolkit
23
00:02:40.975 --> 00:02:43.795
to get your models out of notebooks and into value.
24
00:02:44.335 --> 00:02:45.635
We started base 10
25
00:02:46.095 --> 00:02:47.155
really out of,
26
00:02:47.455 --> 00:02:51.459
you know, a pain point that we saw for ourselves that, you know, we were working
27
00:02:52.000 --> 00:02:54.500
in machine learning teams at very, very small companies
28
00:02:55.120 --> 00:02:56.660
where we didn't,
29
00:02:57.305 --> 00:03:01.165
you know, necessarily have all the resources we needed
30
00:03:01.465 --> 00:03:07.085
to bring those models to market. So, you know, as to make it a bit more concrete, you know, we're working at a start up called Gumroad
31
00:03:07.450 --> 00:03:10.750
that was working on fraud detection and content moderation.
32
00:03:11.290 --> 00:03:28.430
And as a machine learning engineer myself, you know, it took me about, you know, 3 or 4 weeks to, you know, get this great dataset together and come up with my first model. I realized really, really quickly after that was that I'd have to become a full stack engineer to be able to actually get this model to value for the business
33
00:03:28.810 --> 00:03:39.625
because we just didn't have the resources to figure out how to pull that model, how to build the back end to support that model, how to build the internal tools that operate off the output of the model. And so, you know, I think
34
00:03:39.925 --> 00:03:40.665
back in,
35
00:03:40.965 --> 00:03:42.665
you know, 2012 to 2015,
36
00:03:43.550 --> 00:03:51.665
I and our team went and basically learned that skill set. So in the absence of those resources, and that was great for me frankly,
37
00:03:52.045 --> 00:03:55.025
but pretty horrible as a investment for the company.
38
00:03:55.565 --> 00:03:57.105
And, you know, fast forward
39
00:03:57.485 --> 00:04:08.530
to 2018 and 2019, and we're talking to a bunch of our friends who, you know, run machine learning team that do machine learning at larger companies or at, you know, midsized companies. And what we realized was that the results
40
00:04:09.325 --> 00:04:12.305
from machine learning efforts and initiatives haven't really
41
00:04:12.845 --> 00:04:15.265
lived up to all the hype. We went pretty deep
42
00:04:15.645 --> 00:04:20.580
on what we found at least was that there's, like, all these great tools and machine learning operations,
43
00:04:21.280 --> 00:04:22.180
like the MLOps
44
00:04:22.480 --> 00:04:23.460
space where
45
00:04:24.264 --> 00:04:28.925
they make it really easy to, 1, train your model, experiment with your models, and figure out how to get
46
00:04:29.305 --> 00:04:35.790
those models, you know, behind some sort of API. What we found was missing was that once that model is behind some API,
47
00:04:36.169 --> 00:04:41.150
you'd still need a whole full stack team, which is exactly a problem we ran into. And so, you know, we kind of
48
00:04:41.574 --> 00:04:54.460
conditioned upon the set of use cases and tried to see if we could abstract out that toolkit, that kind of product had that skill set that I went and learned or our team went and learned back in the day. And that's really, you know, what base 10 is today.
49
00:04:55.000 --> 00:04:56.139
In terms of the
50
00:04:56.759 --> 00:05:07.375
problems that you're solving, you made it pretty clear that, you know, there's the initial step of, I've got a model and I can put an API in front of it, but then how do you actually build the whole application around it? And so
51
00:05:07.819 --> 00:05:14.720
in terms of the solution for that problem, I'm wondering if you could speak to the type of user that you're focused on addressing
52
00:05:15.180 --> 00:05:18.645
to fill that requirement and some of the types of organizations
53
00:05:19.185 --> 00:05:19.685
that
54
00:05:20.065 --> 00:05:25.690
might rely on that capability rather than maybe having their own in house team to productionize
55
00:05:26.070 --> 00:05:39.485
these applications around these models or sort of what the typical flow is from, I've got a model and I've got a prototype built with this, you know, full stack app builder in the form of base 10, and then now I actually want to, you know, bring the feature set even further.
56
00:05:39.920 --> 00:05:42.100
You know, the target users for base 10
57
00:05:42.560 --> 00:05:44.500
are data scientists and machine learning engineers.
58
00:05:45.040 --> 00:05:47.140
For us, you know, we've done a lot of work
59
00:05:47.695 --> 00:05:51.715
on figuring out where these users and teams sit. And for us, it's usually,
60
00:05:52.255 --> 00:05:54.995
you know, they work at companies or at teams
61
00:05:55.300 --> 00:05:58.280
where they don't have support of machine learning platform team.
62
00:05:58.740 --> 00:06:17.130
For us, that makes it super easy because there's only, you know, like, 10 or 15 companies in the world with proper machine learning platform teams. Or, like, the way I would kinda categorize that is, you know, you're part of a scrappy team. You have a machine learnable problem. Do you know what that first version of our model is gonna look like? You know, maybe you have somewhere between 1 and 10 data scientists
63
00:06:17.509 --> 00:06:23.130
on your team, but you don't necessarily have, you know, a complete platform team built out to support that data science function.
64
00:06:23.525 --> 00:06:24.265
In terms
65
00:06:24.645 --> 00:06:28.185
of, you know, like, where they are from,
66
00:06:28.565 --> 00:06:32.025
like, a sophistication perspective, I think that's a good question. I think,
67
00:06:32.490 --> 00:06:54.500
you know, for us, it's kinda what I said. Like, they need to have a machine learning problem. Like, what's a really bad target for us is that if a data engineer picks up base 10 because, you know, what we find is that, you know, you're still focused on getting that data in the right form, which is a big problem in itself. You need to kind of be past that stage and more in the I have a model. In terms of, like, the climates from those users,
68
00:06:55.040 --> 00:06:58.500
we make 1 assumption of our user, which is, you know, Python,
69
00:06:58.935 --> 00:07:08.315
and we lean very, very heavily into that assumption. You know, we find Python to be very, very powerful, but what we try to abstract away is all the infrastructure
70
00:07:09.160 --> 00:07:10.780
required to work with Python
71
00:07:11.240 --> 00:07:18.699
and to give you a set of other tools that allow you to leverage Python to solve real business problems. So, you know, I'm just gonna,
72
00:07:19.065 --> 00:07:25.005
maybe this is not the right time for it, but I can just jump into, like, how we do that if that's helpful. You know, firstly,
73
00:07:25.625 --> 00:07:37.370
we have kind of, like, 3 pillars to base 10. First 1 is around model deployment. So, you know, you have a model sitting in your notebook somewhere. Base 10 has a little SDK. You know, you can call from your Python notebook
74
00:07:38.045 --> 00:07:45.985
or your Python shell that wraps most types of models. So that's like a learn, TensorFlow, Keras, and so on and so forth. And, you know, within
75
00:07:46.540 --> 00:07:49.680
really, like, a few minutes, you can have a model deployed behind
76
00:07:50.060 --> 00:08:18.845
an API and ready to go. But that's really where the value of base then starts to come. You know, we think deployment's actually a commodity. We're not super interested in being machine learning deployment company and that's integration cost for us. We just happen to have an added benefit there. The next step though, is that you need to build some sort of API that sits around that model. So, you know, the inputs and outputs sort of model don't really map to the business requirements. You need to do some preprocessing and post processing. You need to write that data somewhere. You need to combine it with some other data. And so we kinda give you this thing that looks like AWS land or GCP,
77
00:08:19.169 --> 00:08:19.990
where you can,
78
00:08:20.290 --> 00:08:32.795
you know, write Python code that interacts with that model in base 10. And all of a sudden, you know, you've gone from a model in your notebook to a model behind an API to a model with some business logic around it behind an API.
79
00:08:33.175 --> 00:08:42.610
And then the 3rd pillar is kind of like that more front end application building part of it, which is, you know, you have a model let's go back to that fraud example, is that your model says,
80
00:08:43.324 --> 00:08:50.704
hey. I am 80, 90% sure that this is fraud. Great. But when your model says 40% sure, 50% sure it's fraud, you want a human
81
00:08:51.100 --> 00:09:01.834
to be able to review that. And so base end kind of gives you the low code UI builder to be able to interact with that business logic that I described earlier, but also put together these UIs quite quickly.
82
00:09:02.295 --> 00:09:03.834
As far as the
83
00:09:04.214 --> 00:09:22.225
overall process for being able to build these full stack applications with base 10, as you said, it gives you, you know, a lot of useful tools that are all tightly integrated to be able to manage that end to end flow of, I've got a model. Now I need to build the app around it. In the absence of base 10, what are some of the strategies
84
00:09:22.605 --> 00:09:23.345
and utilities
85
00:09:23.645 --> 00:09:26.865
and kind of development patterns that teams have
86
00:09:27.209 --> 00:09:31.470
built up to be able to solve that problem and some of the pain points that they're experiencing
87
00:09:31.850 --> 00:09:34.750
as far as trying to integrate all of those components on their own?
88
00:09:35.205 --> 00:09:40.105
What folks have come up with is kinda, like, 2 solutions. 1 is to hire consulting teams,
89
00:09:40.405 --> 00:09:42.105
especially when you go to larger companies.
90
00:09:42.430 --> 00:09:52.335
You know, they just hire application building teams to sit on top of these ML models. We think that's really bad. I understand the need for it, but the fact that these machine learning teams can be so far removed
91
00:09:52.975 --> 00:10:08.890
from the products that they're powering, I think, actually leads to worse outcomes overall. I hit that's approach 1. Approach 2 is just to stitch together a bunch of different solutions. So, you know, like, what we've seen is, you know, you would deploy your model with, like, SageMaker or something on GCP's vertex
92
00:10:09.435 --> 00:10:12.735
or Seldon. You then go and spin up a Flask application
93
00:10:13.275 --> 00:10:14.655
and run that in AWS,
94
00:10:15.035 --> 00:10:20.290
or you use AWS Lambda or GCP Cloud functions to interact with that model.
95
00:10:20.670 --> 00:10:23.890
And then, you know, you pipe that pipe that to some database,
96
00:10:24.350 --> 00:10:34.275
and then you'll, again, either rely on a consulting team or a different product engineering team to build with that data, or you will use something like Streamlit or retool to sit on top of that data. Now
97
00:10:34.735 --> 00:10:36.835
and that is probably the scrappiest,
98
00:10:37.470 --> 00:10:42.930
you know, most productive teams that are able to do that. Most teams just get stuck. Data scientists don't really know infrastructure
99
00:10:43.310 --> 00:11:08.165
that well. They know infrastructure around models. They shouldn't need to know infrastructure. This is not what their core skill set is. And so as a result, what happens is that, you know, these models just end up somewhere running on local notebooks and and don't really get really beyond that. I think the other approach, which I think the most successful companies have taken, is to really start to work with machine learning platform team. But as I said, that's really a champagne,
100
00:11:08.705 --> 00:11:11.445
like, problem where you're doing really well when you have the resources
101
00:11:11.904 --> 00:11:14.839
to be able to put together a machine learning platform team.
102
00:11:15.459 --> 00:11:16.200
In terms
103
00:11:16.660 --> 00:11:17.240
of the
104
00:11:18.420 --> 00:11:19.800
actual process of
105
00:11:20.375 --> 00:11:28.555
running a model in the context of an application beyond just being able to wire together the UI or build the API, what are some of the
106
00:11:29.190 --> 00:11:32.890
sort of core technical requirements that are needed to be able to actually
107
00:11:33.270 --> 00:11:40.595
support that model as it's operating and ensure that you're able to scale it as usage grows or ensure that you're able to
108
00:11:41.135 --> 00:12:01.774
monitor it or manage the integration of the API endpoints into the actual model execution and any sort of, you know, supporting storage or the other sort of technical components that are required just to be able to say, I have a model, I have an application, and everything is running and happy. I feel like you just outlined everything yourself there. But
109
00:12:02.555 --> 00:12:03.535
in terms of,
110
00:12:04.080 --> 00:12:10.500
like, without base 10, you know, the truth is you need, like, a DevOps here. Right? You need folks who know how to configure
111
00:12:11.200 --> 00:12:25.760
configure servers, how to manage storage. You know, oftentimes models can be quite big. So even unpicking them in can, you know, take up too much memory. And so I think without base 10, you end up requiring to do a lot of the same sort of DevOps engineering
112
00:12:26.220 --> 00:12:33.185
that you provide with a traditional web app at scale or traditional API at scale. But you have to do it a bit earlier because
113
00:12:33.565 --> 00:12:38.705
you run into the memory requirements a bit earlier than you traditionally would. I think,
114
00:12:39.170 --> 00:12:39.750
you know,
115
00:12:40.770 --> 00:12:56.295
what's interesting is the machine learning models kind of also bring in, like, a second set of considerations around performance of that model. I'd say, like, that performance of that model is probabilistic and not deterministic, which is interesting, and, you know, that just brings a whole new set of monitoring constraints
116
00:12:56.889 --> 00:13:02.110
around that model. It's like, okay. Is this model running? Great. How fast is it running? Fantastic.
117
00:13:02.730 --> 00:13:03.230
Now,
118
00:13:03.610 --> 00:13:11.515
you know, the harder questions to answer is, like, is this model doing the thing that we want it to do? And the answer to that is probabilistic, you know, bring up a whole new set of challenges.
119
00:13:12.020 --> 00:13:23.005
With base 10, you know, what we try to do is try to abstract all that stuff away. So, you know, our goal is to make, you know, the easy thing super easy, yet make the hard thing still possible.
120
00:13:23.464 --> 00:13:51.190
And so for us, what that means is that machine learning teams and data scientists can, you know, deploy a model with a few lines of code, And the default is sensible. You don't need to think about scaling stuff up because we have a auto scaling strategy for your model. Our models don't go down. And when they do, we have code to take care of that for you, and we provide you monitoring dashboards and health dashboards to be able to look at that. That being said, you know, as an engineer myself and someone who's struggled over the years with, you you know, dealing with stuff like Heroku,
121
00:13:51.490 --> 00:14:09.270
you know, it can get really frustrating when a lot of these platforms just abstracts so much away that you actually can't configure anything that you want at all. So we actually provide the knobs necessary for you to be able to change things underneath you if you need more compute if you need a GPU behind it based on, like, gives you those knobs. But default is sensible
122
00:14:09.650 --> 00:14:21.805
and good enough. And, you know, we've thought about having stuff like auto scaling and load balancing, but you don't need to think about that as a data science and machine learning team. You mentioned a couple of other projects that are in sort of a
123
00:14:22.270 --> 00:14:40.260
neighboring space of making it easier for a machine learning engineer or a data science team to be able to go from, I have a hypothesis. I will build a model, and now I just want to be able to wire this up to, you know, prototype something. So you mentioned Streamlit. I know that there's also the HEX platform. There are a few other
124
00:14:40.640 --> 00:14:44.180
projects and platforms and systems that are available in the ecosystem
125
00:14:44.964 --> 00:14:59.149
to reduce the barrier to entry for somebody who's very heavy in the sort of statistical and machine learning capacity to say, I just want to put this in front of somebody to do something with it. And I'm wondering if you can just give your kind of characterization
126
00:14:59.450 --> 00:15:02.505
of the space and maybe some broad categorization
127
00:15:02.964 --> 00:15:08.904
of how these tools might be used and applied and where base 10 fits in that overall spectrum.
128
00:15:09.379 --> 00:15:35.320
From my perspective, at least, you know, the emergence of all these tools has been, you know, truly fantastic. It is amazing that we are creating these tools to make this thing that's actually very difficult and a lot easier. I'd say that, you know, I am a big fan of Streamland and I'm a big fan of HEX. I feel like, you know, just by design, they're more suited to, like, BI use cases as opposed to operation machine learning use cases. And so, you know, what I mean by that is that
129
00:15:35.715 --> 00:15:38.055
what we're going after is these real human
130
00:15:38.675 --> 00:15:39.335
look workflows
131
00:15:39.875 --> 00:15:54.165
where, you know, we're trying to build the tooling that allows you to combine humans with machine learning models and make decisions. You know, that is, you know, based on the bread and butter, like fraud detection, content moderation, where there's a model making a decision and you need a human to work with that model
132
00:15:55.045 --> 00:15:57.305
to kinda make a better decision. I'd say that,
133
00:15:57.845 --> 00:15:58.505
you know,
134
00:15:59.045 --> 00:16:04.160
even beyond streamlining and hacks, I think products like retail have just been fantastic and really
135
00:16:04.940 --> 00:16:06.639
more than anything, just destigmatizing
136
00:16:07.180 --> 00:16:11.519
this idea of we're at a point now with software learning that we can
137
00:16:12.135 --> 00:16:20.154
abstract away a lot of these things, especially if you condition on, like, a certain set of use cases. You know, I guess, like, retail is big,
138
00:16:20.550 --> 00:16:23.370
maybe realization was that, hey. All internal tools actually
139
00:16:23.750 --> 00:16:25.690
have, like, 7 or 8 primitives.
140
00:16:26.230 --> 00:16:27.210
In other words, you
141
00:16:27.555 --> 00:16:43.720
know, they have a button, they have a form, they have maybe some BI to them. And so I think, like, you know, I'm really excited by all these UI builders that come up and, you know, whether they come in the form of, you know, streamlet, which is very much like write Python, get a visual app, or hex, which is, you know, kinda streamlet plus,
142
00:16:44.095 --> 00:16:56.899
you know, the drag and drop ability to make into a narrative and make it really easy to a narrative. Or retool, which is like, hey. You can just build internal tools, you know, very internal. Great. I'd say, you know, base 10 definitely fits into,
143
00:16:57.360 --> 00:17:00.100
you know, 1 side of that, which is, you know, very much
144
00:17:00.480 --> 00:17:03.925
that, you know, we make it easy for you to build these user facing applications.
145
00:17:04.465 --> 00:17:20.605
But I think we're also focused on the back end, which I'd say some of these other projects or companies aren't to focus on today. And then maybe they will probably go there at some point, but it's like, you know, with the retool, you still need to set up your own back end or set up your own database that you can query against, but it very much is the front end. Like with base 10, we like to build APIs.
146
00:17:20.985 --> 00:17:43.095
I think that, you know, I don't know if there's that many faster ways to execute a blob of Python code behind an API than MACE 10. It's literally pasting it into something like building an orchestration graph in a point and click manner, so no Yammer required, and you have an API ready to go. But really what that allows us to do and the intuition with the model site allows us to do is be a lot more focused on workflows
147
00:17:43.555 --> 00:17:47.169
as opposed to maybe kind of single use applications or single use dashboards.
148
00:17:47.630 --> 00:17:53.010
Digging into the base 10 platform itself, can you talk through some of the implementation and
149
00:17:53.415 --> 00:17:58.075
architecture and custom engineering that you've had to build to be able to support this workflow of
150
00:17:58.695 --> 00:18:01.995
take a model, build an application around it, and put it into production?
151
00:18:02.630 --> 00:18:05.370
I think a few things. So the first thing I'll start with the model
152
00:18:05.750 --> 00:18:10.010
building side model. And so, like, the first thing we did was, like, you know, built this
153
00:18:10.390 --> 00:18:11.450
cool way to,
154
00:18:11.965 --> 00:18:19.985
like, SDK in Python that you call with your Python client. With 1 line, you can deploy a model. And what we're doing there was actually inspecting your environment,
155
00:18:20.340 --> 00:18:31.385
looking kind of like what are the requirements you need and spinning up a Kubernetes cluster somewhere to run that code and then give you an API to access that Kubernetes cluster. Our goal here was to make it so that the amount of
156
00:18:31.765 --> 00:18:46.645
custom code per se necessary to be able to build that for the user was as minimal as possible. The second part of part of base 10 is getting more interesting, right, where it's like very much like replit where we are running user provided code. So in some isolated environment, and that has all sorts of security concerns
157
00:18:47.025 --> 00:19:04.485
as you might imagine. But really, again, what we're doing here is that, you know, you provide us some blob of Python code. You know, we have some pretty intuitive way to assemble that. But, you know, again and you give us requirements to txt, which might be the requirements to run that code. And, again, we go and create a cluster
158
00:19:04.945 --> 00:19:05.845
somewhere with
159
00:19:06.145 --> 00:19:09.765
that isolated environment, run your code, and provide you the interface
160
00:19:10.269 --> 00:19:18.929
to do that. Like, you know, we have to go through a few rewrites of that because I think the actual core problem of running that code was difficult from an infrastructure perspective.
161
00:19:19.325 --> 00:19:42.664
But the harder problem was, like, what is the user experience for writing code on base 10, and what does that look like? And so, like, what we wanted to do was build a way that you could write code locally. You could push to base 10 as opposed to have to write your code in base 10. And I think while the infrastructure behind it is definitely very impressive, like, I think what's more impressive about what we build is kind of, like, then user interface to writing code so that, you know, you feel like it fits into your developer workflow.
162
00:19:42.965 --> 00:19:43.544
I think
163
00:19:44.059 --> 00:19:45.919
skipping over to the front end side of things,
164
00:19:46.220 --> 00:19:52.080
what's been really interesting is like, you know, how do you build the drag and drop tool so that, you know, your data scientists
165
00:19:52.380 --> 00:20:00.034
can build a UI without having to know JavaScript. And, you know, that's not purely reactive or display UI. It's stuff with event handlers.
166
00:20:00.335 --> 00:20:06.870
So what are the abstractions required? So you can, you know, bind the button to run some code without knowing any JavaScript.
167
00:20:07.170 --> 00:20:13.054
That was actually harder than I thought it'd be. I thought this was odd. This is, you know, sounds hard in practice.
168
00:20:13.434 --> 00:20:18.894
Like, we can probably, you know, put something out there pretty quickly. Turned out, took us 2 or 3 different rewrites
169
00:20:19.674 --> 00:20:32.345
to get it right. But, you know, like, our problems really have or, like, the solutions we've come up with have really ranged from deep infrastructure problems. So, like, how do you run, you know, deep models of these blobs of code somewhere
170
00:20:32.725 --> 00:20:43.760
and create the API in a performance way, to security, to how do you isolate users' codes from 1 another so they can't access it. So how do you protect users from users and how do you protect base 10 from users?
171
00:20:44.060 --> 00:21:12.835
I think these are hard security problems that, you know, spent way too many hours spatting ahead against a wall's fault, but, you know, I think we've come up with good solutions. And to the more, what are the attractions required or what are the framework required so a data scientist can build UI without knowing your JavaScript and complex UI. And I think, you know, the range of problems there is actually quite complex and tying them all together in a performing manner so it doesn't feel like 1 jump with Ness. You know, that's been even harder, which is like, you know, the UI and the user flow, if you may.
172
00:21:13.135 --> 00:21:30.875
And you mentioned that you went through a few different iterations of how to tackle this problem. I'm wondering if you can talk through some of the ways that the original design and goals of the project have changed and evolved since you first started working on it to bring you to where you are today? I'd say, like, when we started the company in the end of 2019,
173
00:21:31.735 --> 00:21:32.955
we weren't really sure
174
00:21:33.620 --> 00:21:41.560
where we sat in terms of what we required of our users, and this actually put us in a really bad spot. So, like, oh, let us astray for a second where,
175
00:21:41.865 --> 00:21:47.885
you know, for a long time, we were like, oh, you know, the user knows Python, but maybe they don't need to know Python or they need to know a little bit of Python.
176
00:21:48.185 --> 00:22:07.530
I think what we realized maybe, like, a year into the project is that, actually, code's amazing and, like, we shouldn't try to hide cut away. Like, we are building for a very technical audience who is pretty proficient with Python and we should lean really heavily into that. And I think that's probably when that was, like, a big almost like paradigm shift for us when we stopped trying to,
177
00:22:07.910 --> 00:22:09.930
you know, build for the lowest common denominator,
178
00:22:10.310 --> 00:22:24.330
if you may, and instead just for, like, how user knows Python really well. They could even think about infrastructure. Maybe they don't know the language of infrastructure, but they can't even think about these things quickly into that. So that changed even just, like, how you wrote code, how you orchestrated,
179
00:22:24.710 --> 00:22:27.690
you know, running code, you know, what the APIs look like.
180
00:22:27.990 --> 00:22:30.890
Even for the UI builder, like, what did we
181
00:22:31.195 --> 00:22:34.015
require from the user to be able to bind
182
00:22:34.475 --> 00:22:35.774
data to a table?
183
00:22:36.075 --> 00:22:54.345
You know? Is it okay if they have to write a snippet of code? And I think once we laid into that, a lot of those, you know, ideas became more clear. And, you know, I kinda, like, leaned pretty heavily on 1 of our developers, Saran, who's He does a lot of open source work and is the primary maintainer of the React Monaco library, which we use very heavily. But
184
00:22:54.650 --> 00:23:03.070
talking to him, I remember asking him, like, how do you decide what should be part of the project and what shouldn't? And he he talked about, you know, really early defining the philosophy
185
00:23:03.534 --> 00:23:18.679
and the user of your project and, you know, being really, really crystal clear around kind of what your philosophy you know, what your utility function is. You know, for us, that came a bit later than I would have hoped. But once we had that utility function in place, like, it became really, really easy to
186
00:23:18.980 --> 00:23:19.640
not only
187
00:23:20.035 --> 00:23:23.255
prioritize features, but, like, design the software and the underlying abstractions.
188
00:23:23.955 --> 00:23:29.015
Because of the fact that you do allow for users to submit arbitrary code to customize
189
00:23:29.370 --> 00:23:46.415
the behavior of their back end. That always brings in a lot of interesting challenges around security and performance and making sure that somebody doesn't try to either try to bring your platform down or do it inadvertently because they accidentally enter into an infinite loop. And I'm just curious how you handle some of those
190
00:23:46.720 --> 00:23:49.299
additional complexities of being able to appropriately
191
00:23:49.600 --> 00:23:52.020
sandbox the user's code and then maybe also
192
00:23:52.400 --> 00:23:54.340
ensure that you'd provide some limitations
193
00:23:54.640 --> 00:23:58.664
and to make sure that you don't end up in these infinite loops or accidental
194
00:23:58.965 --> 00:24:01.385
explosion of, performance consumption?
195
00:24:01.845 --> 00:24:11.080
I can't speak to a lot about Beyond my page, you're gonna have taken it far away from me. No. I can't say that, you know, it's kind of managed in 3 different stages. 1 was from a security perspective,
196
00:24:11.435 --> 00:24:17.535
which was that, you know, how do we protect users from other users? How do we protect users from base 10? And how do we protect base 10 from users?
197
00:24:17.835 --> 00:24:32.235
You know, we have a lot of customers who give us quite a lot of sensitive data, and, you know, it is very important for us to be able to solve these, and these are the existential problems for base 10 if we get them wrong, frankly. I'd say I think 1 again, a bit more interesting is
198
00:24:32.774 --> 00:24:35.755
the more usability side of it. It's like, how do we protect users
199
00:24:36.294 --> 00:24:37.115
from doing,
200
00:24:37.500 --> 00:24:42.720
you know, things that will make them end up in infinite, like, in bad states or in infinite loops.
201
00:24:43.180 --> 00:24:58.490
I think this all comes down to, like, you know, having, like, sensible time outs, knowing when to stop running code. I think, probably, most importantly, like, making it really easy to do the right thing as opposed to, you know and making it hard to do the wrong thing. And I think, you know, we spend a lot of time to ensure
202
00:24:58.950 --> 00:25:03.975
that, you know, if you do get into a bad state with things that get not looped, it's likely because,
203
00:25:04.275 --> 00:25:11.575
you know, you kinda did it on purpose. Like, I also got there by accident. So, again, just to reiterate, like, from, like, infrastructure perspective,
204
00:25:12.330 --> 00:25:22.815
spend a lot of time just because it's so important protecting users and making sure that our current sense scale and from a usability perspective, just making it really easy to do the right thing. As far as the
205
00:25:23.674 --> 00:25:24.894
overall design
206
00:25:25.514 --> 00:25:30.894
and interaction patterns for people who are building an application using Base 10,
207
00:25:31.260 --> 00:25:32.880
I'm wondering what the
208
00:25:33.260 --> 00:25:37.820
kind of discovery and design process looked like for figuring out this is the
209
00:25:38.635 --> 00:25:45.535
maybe not necessarily optimal workflow, but this is a workflow that is understandable and accessible for our target audience. And
210
00:25:45.915 --> 00:25:47.775
some of the maybe initial
211
00:25:48.400 --> 00:26:02.615
false starts will say that you ran into as you were starting to say, okay. This is what we think is the right way to go about it, but now we're actually going to put this in front of some of our early design partners, get some feedback, and then figure out, oh, actually, that was not the right way to do it. What led you to the current
212
00:26:02.915 --> 00:26:09.560
approach of breaking it into the different kind of core kind of concepts and base components that you ended up with now?
213
00:26:09.940 --> 00:26:10.600
I think
214
00:26:11.140 --> 00:26:34.775
we started from the user stories, and we kinda thought about, like, what are all the things that user needs to do. And, again, you know, it really helps being, you know, a perceived user of your own product because, you know, we can we could've we thought about it that way. Like, okay. We wanna deploy a model. We wanna build APIs, and we wanna build front ends. And then, you know, we kinda took a 1 step log. Like, okay. We wanna build APIs in Python. We don't wanna think about AWS. We don't wanna think about Docker.
215
00:26:35.075 --> 00:26:37.255
And I think we really decided to, like,
216
00:26:37.555 --> 00:26:42.135
start from that top level and kept breaking it down to, you know, more and more,
217
00:26:42.730 --> 00:26:46.029
like, lower level stories until it kinda matched into, okay,
218
00:26:46.330 --> 00:26:53.294
how would this work for a given product? So what we did for a long time was that we had these 2 or 3 different use cases. We'd basically
219
00:26:53.674 --> 00:26:55.774
every, like, week or 2, we'd have our abstractions,
220
00:26:56.075 --> 00:27:03.740
and then we'd basically say, how do we build this start to finish with base 10? And then, honestly, we test that against ourselves
221
00:27:04.200 --> 00:27:10.914
for a long time before it felt really right when we started building it. I'd say in terms of customers, you know, we started working with customers
222
00:27:11.455 --> 00:27:18.835
probably 4 or 5 months, if not, into building the product. You know, it should have been soon enough. For sure. Like, I think that's something
223
00:27:19.250 --> 00:27:27.909
1 of the things we've been too good before we started. But as soon as we started going to the customer, it became really clear what worked and what wouldn't work. And so, like, you know, as an example,
224
00:27:28.455 --> 00:27:30.075
and I alluded to this earlier,
225
00:27:30.455 --> 00:27:36.715
you know, 1 of the things that we didn't have before was that you were just writing code directly into this orchestration graph,
226
00:27:37.050 --> 00:27:38.910
and then that code would be executed.
227
00:27:39.290 --> 00:27:45.790
You know, 1, you know, the feedback we got was, hey. How does this fit into my developer workflow? Like, how does what fit into my local workflow?
228
00:27:46.105 --> 00:27:48.044
You know, how will this work with version control?
229
00:27:48.424 --> 00:27:57.500
How is this gonna scale? I think, you know, all these things ended up just, you know, changing how we thought about things and really mapping it back to the existing development workflow.
230
00:27:57.880 --> 00:28:02.540
Like, to reiterate, like, 1 of the things that helped us a lot as developers and data scientists ourselves,
231
00:28:03.065 --> 00:28:09.965
You know, it was really easy, at least, early on, for us to find our north star in terms of building things by just, you know,
232
00:28:10.320 --> 00:28:28.610
Engineers are pretty harsh critics of software, as you know. And, you know, we would just ask ourselves, does this pass the bar of something we would use? And we just kept iterating until we at least hit that, and then then we started going to the design process. And what we found was we've kinda gone through those couple of higher orders of thinking by ourselves. It just made those conversations a lot easier.
233
00:28:28.990 --> 00:28:30.210
In terms of the actual
234
00:28:30.510 --> 00:28:31.730
process of somebody
235
00:28:32.350 --> 00:28:43.395
discovering BaseTAD and saying, I wanna build an application. Can you just talk through the overall workflow of, you know, taking the model, building the application, wiring the components together, and some of the
236
00:28:43.700 --> 00:28:48.679
decision points and design questions that they'll need to answer as they go through that process?
237
00:28:49.220 --> 00:28:52.760
So to get started, it's super easy. Right? So you pip install base SAN.
238
00:28:53.235 --> 00:29:08.940
You configure your API key, and you start you deploy your model. And once your model is kind of in base 10, and you can start without a model, we also give you, like I said, pre trained models. We have, like, a lot of funky based models on base 10 that you can start to play with. But once you have that, just couple of quick way you could start creating files
239
00:29:09.445 --> 00:29:22.950
to orchestrate using that model. You know, we give you all our models, all the API endpoints you're building around those models. We give you a way to test everything in line before you even have to call it with an API. You know, we give you a way to look at, like, logging
240
00:29:23.330 --> 00:29:27.875
in line so that, you know, you can see exactly what's happening start to finish
241
00:29:28.175 --> 00:29:42.040
before you have to call it somewhere else. But, really, the idea is that you can go on to it from I have a model to deploy a model to I have an API endpoint with some, you know, preprocessing and post processing code with Python, and that's ready to call from an API.
242
00:29:42.514 --> 00:29:57.320
And, you know, you're off to the races. I think, you know, once you have that API endpoint configured, you know, really it's just going and thinking about what are the application on the front end you need to support that. You know, it's drag and drop. You can, like, pick a table. You can just pick a button. You can pick image gallery,
243
00:29:57.700 --> 00:30:05.015
a text input. You can wire it up to those API endpoints so you can take some input from the user, run them against the model, show the output.
244
00:30:05.475 --> 00:30:16.830
But really, it's a horizontal product with the 3 different pillars, and I think it's, like, worth saying that we have users starting at all different spots. So some people start without a model, you know. And 1 of the customers we're really proud of is Patreon.
245
00:30:17.174 --> 00:30:42.545
You know, they started with the data labeling app. So they started very much in the UI builder. But a lot of our customers don't even have UI, and they just deploy the models and start building APIs around it. So it really is kind of pick your own adventure. We have a guided way how I think about it and how I use it, you know, which makes sense, which is, you know, starting from your model and then building the workflow and then sorry, the API end point, then building kind of the front end applications that sit on top of the end points.
246
00:30:43.019 --> 00:31:07.210
And the UI aspect is always interesting when you throw some sort of, like, design capability in front of engineers because some of them are, you know, very design oriented, and they'll build something that makes sense. And some of them will just throw everything at the wall and say, it does what I want it to do, but then, you know, you throw put it in front of an end user, and they say, my goodness. What have you done? And I'm wondering if you can just talk through some of the guardrails that you've put in place to maybe
247
00:31:07.675 --> 00:31:19.450
prevent some of that experience of, you know, just throwing everything on a canvas and then saying, you know, good luck and just helping people think about that kind of end user experience for the application that they're putting together?
248
00:31:19.750 --> 00:31:30.435
There's nothing to stop you from creating a monstrosity in baseband. It's not even internally. We have some engineers who, you know, go to apps. You're like, that's beautiful. And other ones, they're just like,
249
00:31:30.815 --> 00:32:06.505
what is this? But I think what's more important to us is that we're just trying to make it easy to do the right thing as much as possible. So I think, like, right now, we have a very limited template, so that's a very important part of, you know, of our road map, which is, like, creating this template to the UI. If you need something to, you know, test the inputs and outputs of your model for a vision model, You know, we'll have a template for that. If you need something that uploads an audio file and transcribes a transcription model, we'll give you a template for that. If you need something for, you know, content moderation workflow where you need, like, an inbox type view so you can look at cases, we'll give you something that looks, you know, quite nice,
250
00:32:06.880 --> 00:32:27.570
know, at least from a design perspective. It's simple enough then someone can start to build with it as a template. And I think that is, like, that's a really good way to, like, kinda point people in the right direction. I think, you know, a little less technical, but I think Airtable has done a fantastic job with this. We love their software, which is around, you know, like, if you wanna use Airtable database. Right? And so if you wanna use it for a CRM, they give you a CRM.
251
00:32:28.029 --> 00:32:34.455
If you wanna use it for, like, a recruiting CRM, they give you a recruiting CRM that you could start to play with, and I think it makes it easier.
252
00:32:34.835 --> 00:32:44.190
It just takes some of that down burden of those design choice out of the hands of that user. In terms of the model specifically, I'm wondering if you can talk to some of the
253
00:32:44.650 --> 00:33:16.700
limitations or constraints that you've had to impose as far as the size or scale or complexity of the model or some of the types of models that work better where maybe you do well with a, you know, vision transformer or a, you know, natural language model, but it's more difficult to deploy a, you know, real time computer vision app model. Just some of the ways that you think about the categories of models that people are building and deploying and some of the limitations you've had to impose to make sure that you're able to actually provide a positive experience for your end users?
254
00:33:17.159 --> 00:33:24.684
Honestly, no. Like, there are obviously limitations. Like, if you told me that if you tried deploying DALL E to on base
255
00:33:25.144 --> 00:33:27.005
10, it'd be pretty pretty difficult.
256
00:33:27.544 --> 00:33:42.135
But, you know, it actually scales up pretty well, and we've seen people deploy all sorts of stuff from language models to computer visual models to simple linear regressions. Like, we have pretty needed support for all of that. Just as an example, there's a pretty big open source model that's GPTJ with 6 billing parameters,
257
00:33:42.595 --> 00:33:53.800
which is kind of like a open source version of GPT 3. We were able to get that deployed to be in, you know, in less than an hour. So, you know, like, we do scale up pretty well. I'd say that,
258
00:33:54.500 --> 00:34:04.215
like, from, like, a use cases perspective, like, the more real time stuff with things that are very, very large latency for these large models based on helping other great fit for that. But
259
00:34:04.595 --> 00:34:05.415
that aside,
260
00:34:05.820 --> 00:34:08.880
we really are quite flexible and can handle most types of money.
261
00:34:09.340 --> 00:34:23.420
The other aspect of using something like base 10 where it's very easy and quick to get something up and running is that a lot of people will rely on it as initial prototyping where you say to your machine learning team, you go ahead and do what you want and tell me when you've got something that's actually gonna
262
00:34:23.720 --> 00:34:27.420
provide value, and then we'll build around it. And for the case where,
263
00:34:27.720 --> 00:34:34.895
you know, you build an application, it proves some utility, and then you say, actually, I wanna invest in this further and, you know, build it into the core of our product.
264
00:34:35.275 --> 00:34:36.815
What are the either
265
00:34:37.115 --> 00:34:41.150
extension points for hooking into base 10 to be able to add additional customizations
266
00:34:41.690 --> 00:34:48.670
or the options for being able to take your base 10 application and then export it and, you know, customize it to fit into,
267
00:34:48.984 --> 00:34:49.724
you know, whatever frameworks
268
00:34:50.185 --> 00:34:52.845
and tool chains you're using for the product development?
269
00:34:53.385 --> 00:35:21.009
A truthful answer to this question. So the optimistic version of myself would say that, you know, we should be able to scale with our customers, and I think over time, we'll see more and more of that. That being said, you know, there's 3 pillars to base 10, which I've kinda said a few times now. All of them are kind of very modular. So you can kinda pick and choose which ones you want. Like, this is really important to us that hey. Like, maybe you already have a front end team or you wanna maybe use Retool when you're a big user of Retool at your company. Like, why do you have to use BaseSense? So
270
00:35:21.309 --> 00:35:29.815
the models have their own APIs. The API endpoints are obviously modular and have their own APIs. And the front end can be used with any back end as well. So all of those aspects,
271
00:35:30.115 --> 00:35:50.680
you can switch in and out as necessary. I think, you know, it's a necessity for us to be successful going forward, which is that there are it's very, very cheap to get started with base 10. And what I mean is that you don't need to use base 10 for everything to start with, but also there are escape patches out of base 10. So, you know, you can call the different parts of base 10 and benefit from them without
272
00:35:56.599 --> 00:36:03.035
continuing complexities that people experience as they put their models into production is the challenge of how to monitor it, how to understand
273
00:36:03.415 --> 00:36:33.079
what degree of concept drift it's dealing with, when I need to retrain and redeploy the models. And I'm wondering if you can talk through some of the ways that different model types or some of the different frameworks that somebody will use to build a model will influence the integration points that are available for pulling out some of those useful model specific metrics and then what the sort of life cycle management looks like for when somebody says, okay. This model has gone through enough drift that I actually need to retrain it and redeploy it and just being able to
274
00:36:33.435 --> 00:36:41.535
version the models in the base 10 environment and being able to push them up? Yeah. So we've tried monitoring out of the box. Like, frankly, it's something we haven't invested
275
00:36:41.930 --> 00:36:45.550
the most in right now, and we will continue to invest more in it as we go forward.
276
00:36:45.850 --> 00:36:46.750
You know, I think
277
00:36:47.050 --> 00:37:09.785
it's pretty tricky. I think you alluded to it, but, like, you really have to condition your monitoring on the type of model. It's very, very different to model, like, something that they're putting a simple probability as opposed to a complete computer vision model. As we invest more on that, we're gonna have to figure out which ones, like, we are best to do. Right now, we have really, really good request level monitoring, and, you know, you can browse your outputs over time to see how they are drifting.
278
00:37:10.325 --> 00:37:14.980
You know, as you go over to the next question, though, I think, you know,
279
00:37:15.520 --> 00:37:18.020
like, BaseNet has really, really good version management
280
00:37:18.640 --> 00:37:19.460
with models.
281
00:37:20.000 --> 00:37:21.460
So, you know, you have a
282
00:37:21.775 --> 00:37:31.990
model and you have a new version. It's very, very easy for you to deploy that over the top of it to kind of have some sort of strategy where you when you shadow it. Basically, you run it in the background
283
00:37:32.450 --> 00:37:36.869
for a while, and then when you're happy, it's very, very flexible so you can do these things.
284
00:37:37.329 --> 00:37:38.309
Again, like,
285
00:37:39.464 --> 00:37:56.030
this building a horizontal tool is very difficult because pick and choose your battles and that's it. Right? Like, with the market itself and the budget management itself, we are very much like, I think it's you know, we are still far ahead of what the industry average is, but, like, you know, we have a lot of work to do in terms of making these 2 things
286
00:37:56.595 --> 00:37:58.535
really tightly linked to 1 another.
287
00:37:58.994 --> 00:38:03.015
And so for people who are using Base 10 for building out applications
288
00:38:03.635 --> 00:38:04.535
and experimenting
289
00:38:04.835 --> 00:38:14.475
with how to put their models into production or maybe just using it as an on ramp to experiment with machine learning as a capability before they go down the process
290
00:38:16.955 --> 00:38:22.975
interesting or innovative or unexpected ways that you've seen it used? You know, we've always had a bunch of interest from
291
00:38:23.490 --> 00:38:35.765
people building crypto things on top of us. It's just the state of the market. We didn't expect that. It's not something that you know, it's not something that we are super privy on. It's cool seeing, like, base end being used
292
00:38:36.065 --> 00:38:47.240
in ways that the market is evolving. I think some of the more, like, exciting ways is, you know, people using it for user verification. So, you know, we have a customer. They use it. They have a platform for children
293
00:38:47.619 --> 00:38:51.655
to talk to each other, and they try and, like, make sure that only children participate. And
294
00:38:52.115 --> 00:38:55.575
so they use it to basically run their participants through a model
295
00:38:55.875 --> 00:39:04.600
and try to guess the age of the person, and if they think that this person's an adult, then they had, you know, someone verified. I think that's super cool. I think, you know, that
296
00:39:05.700 --> 00:39:12.585
a European company uses to figure out, you know, the optimal placement of offshore energy sources.
297
00:39:13.045 --> 00:39:21.780
And I think, like, to me, like, these are the more exciting places that, you know, while we hope from base standard that we're enabling all these, you know, kind of the long tail use cases
298
00:39:22.080 --> 00:39:24.660
of machine learning and by just lowering the cost
299
00:39:24.960 --> 00:39:40.840
to get things working end to end. In your experience of building this business and exploring the different ways that people are using machine learning and the types of applications that they're building around it? What are some of the most interesting or unexpected or challenging lessons that you've learned in the process?
300
00:39:41.220 --> 00:39:58.350
The expectations of software as a developer, this is an amazing thing because you have such great software to choose from. It feels like we're still so early innings there. But what it had also meant is that you truly have to build something that feels intuitive and solves a problem, and that just takes a long grind.
301
00:39:58.730 --> 00:40:01.165
You know, like, the reason why I think
302
00:40:01.465 --> 00:40:03.005
you see so many companies,
303
00:40:03.385 --> 00:40:08.180
you know, have to go and raise large amounts of venture money today is because of, you know, people's expectations
304
00:40:08.480 --> 00:40:11.380
of software higher than ever. It's something I underappreciated
305
00:40:12.080 --> 00:40:18.224
for sure, you know, a couple years ago, but, you know, I'm realizing more and more. I think what's the most interesting
306
00:40:18.525 --> 00:40:20.545
thing that we've learned working on base 10
307
00:40:21.005 --> 00:40:25.790
is how many ideas people have for machine learning can do for them, either right and wrong.
308
00:40:26.410 --> 00:40:32.350
And I think, you know, that's what makes it so exciting to work with Big Senses is that, you know, ideally, we can
309
00:40:32.665 --> 00:40:42.670
end up empowering the whole use of use cases that, you know, we didn't think about. I'm curious. What are some of the ways that you're using base 10 inside of base 10 to build base 10?
310
00:40:43.210 --> 00:41:09.385
1 thing which is rare in the machine learning software tooling community today, I think this kind of, like, open source products and there's some weights and biases for this tool. Not that meant that much software which is easily accessible by developers, sign up and use it, and that was really important to us. So, you know, at the same time, we're kind of running the business of reselling compute. Right? Like, you can run off great code. And so, you know, when a user signs up, when they we try to figure out, like, likelihood of this person doing
311
00:41:09.765 --> 00:41:25.464
malicious things as quickly as possible while trying not to, you know, ruin that person's parents. And that's a base 10 app that, the moderation queue, it's a post back to Slack, the error 6 in the model, and the actions are all deployed using base 10. That's pretty cool.
312
00:41:26.165 --> 00:41:42.495
And so for people who are interested in being able to just get started with using machine learning, either with 1 of your pretrained models and they just wanna build an app around it and see what's possible, or they have a model and they just wanna get an app up and running? What is the cases where base 10 might be the wrong choice?
313
00:41:42.895 --> 00:41:45.555
I think when you go to, like, super real time
314
00:41:45.935 --> 00:41:46.675
use cases,
315
00:41:47.055 --> 00:41:48.275
like, based on
316
00:41:48.575 --> 00:41:53.100
probably just in the right choice, an internal build today is better. We'll get there. We're just not there
317
00:41:53.640 --> 00:41:54.860
today. I'd say that,
318
00:41:55.240 --> 00:41:56.860
you know, when you have more optimization
319
00:41:57.240 --> 00:42:02.815
models as opposed to creation models, you know, base had not a great choice. And then I'd say
320
00:42:04.234 --> 00:42:24.635
if inside companies, if you care a lot about things being on prem, you know, base and support that, but it's, like, a it's more painful for us and more painful for the customer. You know? Like, it will be more painful than if you just use a cloud offering. So, like, so, yeah, there are 3 cases of web based, and it's probably not we haven't dealt with those things
321
00:42:25.049 --> 00:42:28.349
as our number 1 priority for where we are today. They're all possible,
322
00:42:28.890 --> 00:42:46.279
but higher order questions that you you need to answer before using base 10 for those things. Now that you have launched and your product is available for people to start onboarding and experimenting with, what are some of the things you have planned for the near to medium term or any areas of focus that you're excited to dig into?
323
00:42:46.819 --> 00:42:50.519
Yeah. I think the biggest 1 is, like, a tighter integration with developer workflow.
324
00:42:51.005 --> 00:43:03.770
So can you write it in your Versus code and there's, like, a little base hand to the extension that deploy that, you know, we're gonna be open sourcing a bunch of stuff we've worked on, which I'm super excited about. But right now, you know, like, I think over the next, like, 12 months,
325
00:43:04.070 --> 00:43:14.785
you know, we're just really focused on getting people value. And I think, you know, whatever that entails, whether that means more models, where we're really investing in that, whether that means, you know, investing in monitoring,
326
00:43:15.130 --> 00:43:23.790
We're really excited about that, but I think, you know, the thing that comes to mind straight away is, like, how do we get even more embedded into the developer workflow today?
327
00:43:24.494 --> 00:43:32.434
Well, for anybody who wants to get in touch with you 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,
328
00:43:32.740 --> 00:43:38.440
I'd like to get your perspective on what you see as being the biggest barrier to adoption for machine learning today.
329
00:43:38.740 --> 00:43:45.905
Really just getting buy in from other stakeholders. I think today, like, machine learning kinda has, like, this dual plus status
330
00:43:46.445 --> 00:43:52.190
of having a ton of hype around it and also having a lot of skepticism around it. And I think, you know, what's
331
00:43:53.130 --> 00:43:58.829
important to adoption today, I think, is just educating people about, you know, what's possible in the state of the art,
332
00:43:59.155 --> 00:44:03.575
where realistically most organizations are, and what it'll take for those things to converge
333
00:44:04.035 --> 00:44:13.860
over time. And I think, you know, that just will require, you know, more success stories, more failure stories, and just making it driving down the cost data rate, which I hope I contribute to in some way.
334
00:44:15.045 --> 00:44:23.230
Absolutely. Well, thank you very much for taking the time today to join me and share the work that you've been doing at Base 10. It's definitely a very interesting platform,
335
00:44:23.530 --> 00:44:24.030
definitely
336
00:44:24.490 --> 00:44:38.095
reduces the time and energy required to invest in getting an application up and running to prove out ideas. So I appreciate all of the time and energy that you and your team have put into that, and I hope you enjoy the rest of your day. Thank you so much. I appreciate you having me on the show.
337
00:44:40.315 --> 00:44:53.455
Thank you for listening. Don't forget to check out our other shows, the Data Engineering Podcast, which covers the latest on modern data management, and the Machine Learning Podcast, which helps you go from idea to production with machine learning. Visit the site at pythonpodcast.com
338
00:44:54.475 --> 00:45:02.210
to subscribe to the show, sign up for the mailing list, and read the show notes. And if you learned something or tried out a project from the show, then tell us about it. Email hostspythonpodcast.com
339
00:45:03.710 --> 00:45:09.785
with your story. And to help other people find the show, please leave a review on Apple Podcasts and tell your friends and coworkers.