Traditionally, when we've depended upon software to make a decision with real-world implications,
that software was deterministic.
It had some inputs, a few if statements, and we could point to the exact line of code where
the decision was made, and the same inputs would lead to the same decisions.
Nowadays, with the rise of machine learning and neural networks, this is much more blurry.
How did the model decide?
Has the model inputs drifted apart so the decisions are outside what it was designed for?
These are just some of the questions discussed with our guest, Andrew Clark, on this,
episode 261 of Talk Python to Me, recorded April 17th, 2020.
Welcome to Talk Python to Me, a weekly podcast on Python, the language, the libraries, the
ecosystem, and the personalities.
This is your host, Michael Kennedy.
Follow me on Twitter, where I'm @mkennedy.
Keep up with the show and listen to past episodes at talkpython.fm, and follow the show on Twitter
via at Talk Python.
This episode is sponsored by Linode and Reuven Lerner.
Please check out what they're both offering during their segments.
It really helps support the show.
Andrew Clark, welcome to Talk Python to Me.
Hi, Michael.
Glad to be here.
It's always a pleasure listening to your podcast.
I'm really excited to get to talk to you today.
Well, thank you so much.
And I'm excited to talk to you as well.
It's going to be really fun to talk about machine learning.
And I think of all of the programming type of stuff out there, more than most, machine
learning is truly a black box for a lot of people.
The decisions it makes is sort of unclear.
It's sort of statistical.
To me, it feels a little bit like quantum mechanics over Newtonian physics or whatever.
It's like, well, I know there's rules that guide it, but it's kind of just it does its
thing and you can't really know for sure.
But at the same time, the world is beginning to rely more and more on machine learning, right?
Yes, definitely.
And there's definitely different levels of the complexity of it on how much is deterministic
and how much of it really is quantum mechanics.
Nice.
All right.
Now, before we get into that, though, of course, let's start with your story.
How did you get into programming and into Python?
Yeah, definitely.
In my undergrad, I was actually an accounting major.
And then about halfway through, I realized accounting is a great career, but it's really boring for
me.
So I started trying to just get into programming and stuff.
Big data was like the craze when I was in college.
Everybody was talking about big data and Hadoop and all that kind of thing.
So I really started wanting to learn more about it and work through Code Academy and learn
Python the hard way and some of those other books that are around.
Tried a bunch of different things to see what worked for me and learn Python the hard way
is what really seemed to stick.
And then really started just trying to find little side projects of little things to do
to actually build the programming.
So I tried doing the top down, like here's the theory, more computer science-y approach.
Didn't really work for me.
It's more the bottom up of like, I'm trying to solve a problem.
I want to move this file to this location.
And I want to like orient this image in my Excel file.
There's like different things like that to help learning how to program.
Do you think that programming is often taught in like in reverse in the wrong way?
Right.
It's like very high level.
And then we're going to work our way down and down.
And like, here's the concepts.
And then here's the theory.
And instead of just like, here's a couple of problems and a few things you need to know
and a whole bunch of stuff that we're not going to even tell you exists about.
Right.
Like you don't even know what a heap is.
I don't care.
We're going to just make this work until you like eventually care what like, you know,
memory allocation is.
Right.
At least I found, especially in the academic world, I felt sort of flipped on its head.
I definitely think so.
A lot of careers are built that way.
It's like you need to have some sort of a concrete of why does this matter?
Why do I care?
And like being able to do get your hands dirty and then go into the theory.
So you really want to do both in tandem.
But really starting with the hands on is really helped me with that approach.
I know some people can do it the top down theory way, but I definitely think computer science
could have a lot better programmers faster if they did it from the bottom up.
Yeah, I agree.
And computer science or programming in general is nice in that it has that possibility.
Right.
Like it's harder.
You know, we joked about quantum mechanics.
It's harder to just like, well, let's get your hands dirty with some quantum mechanics.
And then we'll talk about like wave particle duality, like whatever.
Like it just doesn't lend itself to that kind of presentation or that kind of like analysis,
I don't think.
But programming does, right?
You could say, we're going to take this little API.
I'm going to build a graph.
And how cool is that?
Now let's figure out what the heck we did.
Exactly.
So that's one of the beauties about programming, especially Python with its ease of starting
up and just getting something running on your computer.
You can really start dealing with problems you wouldn't be able to do in some of these fields
until you had a postdoc.
You can't even start talking about quantum.
Exactly.
So back to your story, you were talking about like, this was the way that you found worked
for you to get rolling.
Yeah.
And it really worked well with the different internships I was doing at the time.
So I was working in financial audit.
And during that time was really when auditors were starting to think about using data and
using more than just normally in auditing, you do random sampling.
So you'll look at a bunch of transactions from like accounts payable for like, these are bills
the company paid.
And being able to find that there's a lot of times there's duplicates.
Some people are paying invoices twice and things like that.
So being able to use programming to start solving just audit problems to speed up the process for
my company and just make my life easier, honestly.
It was really how I started getting very excited about Python besides just like very small little
utils on my computer.
So like seeing what can we really do with this and how can we make solve business problems
with it?
So I really came out of that pragmatic way.
That's cool.
Did you find that your co-workers, other people trying to solve the same problems, were trying
to solve it with Excel and you just had like this power that they didn't have?
Definitely.
Excel and some like specific analytics tools.
Like there's a couple out there for auditors that like Caseware Idea and ACL and things.
And they're just not as easy to use.
They trump Excel, but they have a massive learning curve themselves.
So it's like being able to do something like Python.
I can both camps of different types of auditors, either Excel or ACL auditors were able to
just run circles around them with testing.
That's pretty cool.
Well, that's a really interesting and practical way to get into it.
I've recently realized or come to learn that so many people seem to be coming into Python
and especially the data science side of Python from economics.
Yeah, there's a big move these days from people traditionally in economics would be using
like Matplotlib and no, sorry, Matlab.
Python's on the brain here.
Matlab and moving in to do more quantitative analysis.
And now really Python has kind of taken over in economics.
And there's like this a ton of people that are just coming over to the data science from
you do those types of modeling for econometrics and stuff.
So there's definitely a big surge of economists turned data scientists these days.
Yeah, cool.
What are you doing day to day now?
Like you started out doing auditing and getting into Python that way.
Now what?
Well, it's been a really crazy ride, but I'm now doing a startup called Monitor that works on
machine learning assurance.
Like how do we provide assurance around machine learning models?
So I'm the co-founder and CTO with them.
So my day to day right now, we're currently in the midst of Techstars Boston's is very much
just like meeting with different investors, meeting with their startup founders, meeting with
client potential clients and running as different parts of business.
So wearing a lot of hats right now.
And then I run all the R&Ds type side and figuring out like, what are the things we want to build?
And then I can start working with the engineering team to execute.
Do you find that you're doing all these things that sort of a tech background wholly unprepared
you for?
There's definitely some of that.
Some of it, like my accounting degree is definitely coming in handy.
Yeah.
A lot of the business side things, but there's definitely a lot of moving pieces.
And it's more than just strictly like being a good Python programmer.
So it's a little more than I was expecting on that side.
Well, I do feel like a lot of people, and this is like my former self included, is like,
if you build it, they will come.
All we need is like really good tech and like a compelling project or technology or product.
And then we'll figure out the rest of the stuff.
We'll figure out the accounting, the marketing, the user growth, like all that stuff.
And it's like, no, no, no, no.
Like the product and the programming is table stakes.
All this other stuff is what it actually takes to make it work, right?
Definitely.
You need to have innovative tech, but that's only a component of it.
Like that's like one fourth of the problem.
And, you know, for I think a lot of myself and I think a lot of first time startup individuals
as well, you come into that thinking like, hey, tech is going to be king when there's
actually so many other moving pieces like you're mentioning.
So it's actually an eye opening experience, but I really respect founders more.
Yeah, same.
Well, I do find it really interesting and almost disheartening when you realize like I have
all this amazing programming skill and I know I can build this.
If I had two months and I'm really focused, we can build this thing.
And you realize like, actually, that's just a small part of like having to build it.
Like this is where it starts.
This is not like basically it's ready to roll.
So I don't know.
It's something I've been thinking about over the last few years.
And it's not the way I think a lot of people perceive it starting something like this.
If you have like, we're going to get a cool programming team together.
We're going to build this thing and it'd be great.
It's like, okay, well, that gets you started.
But then what?
Right?
Exactly.
And the other problem you have with a startup is like you can't even do, okay, we'll give
me two months and we'll can build it.
Like with all the other competing business things and stuff, you can't even get that straight
two months of just building because you have all the investor obligations and things.
So it's definitely a lot of things to juggle.
So you get really good at time management and priority juggling.
But it's exciting, right?
It's a lot of fun.
Yeah.
Oh, it's fantastic.
And being part of Techstars is really wonderful.
It's wouldn't trade it for anything.
It's just definitely eye opening and a great learning experience.
Yeah, I've had some people on the show a while back who had gone through Techstars, but maybe
folks haven't listened to that show or whatever.
So probably the most popular, well-known something like that is probably Y Combinator, though I
don't know that it's exactly the same thing.
But tell folks about what Techstar is a little bit just so they have a sense of what you're
working on or what you're doing.
So Techstars is an accelerator.
There's like accelerators and incubators.
I didn't really know there was much of a difference, but being part of Techstars, the
accelerators are really very mentor heavy.
Like the first couple of weeks of Techstars, you have a ton of different mentors that you
meet with, like five a day or more, and trying to find who's going to help guide the vision
of your company.
How do you get to write people around the table?
What's your company vision?
Your mission statement?
How are you going to do fundraising?
What's your marketing strategy?
What's your go-to-market?
How do you get your first few customers?
How do you keep those customers?
It's very focused on the execution and how do you make a successful business that will last?
So it's a lot of very business-y things.
For a tech-run startup company thing, it's very, very focused on the non-tech aspects,
the business aspects, the how do we differentiate ourselves from the crowd and things.
So there's seminars, mentor meetings, there's just lots of moving pieces with that.
But it's a very, very good thing.
And it helps in about three months to take your company from a cool idea and you have a product
to really being able to execute your vision and have better staying power.
Yeah, well, it sounds like it's a lot of the stuff to sort of build that structure and support
of what we were just talking about, of like what you don't get if you know how to write
code and create a product.
Right.
It's exactly right.
Because like Techstars, 10 companies are accepted out of over 2,000 applicants.
So it's like you already have a product.
You already have good tech to make it across the bar.
They're like, okay, everybody knows what they're doing, how to build tech.
Now we've got to teach you guys how to actually run a company.
So it's a very good way of approaching it.
It's not like you all sit in a room with a bunch of group think and programmers making
it more geeky.
You think like, okay, you might even need to scale back the complexity of this a little
bit so we can actually market this to the user.
It's very, very good program for small companies to go through.
This portion of Talk Python to Me is brought to you by Linode.
Whether you're working on a personal project or managing your enterprise's infrastructure,
Linode has the pricing, support, and scale that you need to take your project to the next
level.
With 11 data centers worldwide, including their newest data center in Sydney, Australia, enterprise
grade hardware, S3 compatible storage, and the next generation network, Linode delivers
the performance that you expect at a price that you don't.
Get started on Linode today with a $20 credit and you get access to the next generation
to native SSD storage, a 40 gigabit network, industry leading processors, their revamped
cloud manager, cloud.linode.com, root access to your server, along with their newest API and
a Python CLI.
Just visit talkpython.fm/Linode when creating a new Linode account and you'll automatically
get $20 credit for your next project.
Oh, and one last thing, they're hiring.
Go to linode.com slash careers to find out more.
Let them know that we sent you.
Well, I want to talk a little bit more about that at the end and how it's probably changed
as the world has changed with COVID-19 and all that.
But let's talk about machine learning and stuff like that first.
Yeah, definitely.
We talked a little bit about machine learning and I joke that like, at least to my very limited
experience, it feels a little bit quantum mechanics-y in that same sense.
But let's tell people, I guess, what is machine learning?
Obviously, we have a bit of a sense, but like, let's try to make it a little bit more concrete
for people who maybe it's still like a buzzword and what makes up machine learning, I guess.
Definitely.
So I'll start by saying there's a lot of terminology where people kind of interchange
together, like AI, machine learning, deep learning.
So if you think of three big circles, AI is just a broad range of trying to make machines
to copy human tasks.
So AI doesn't have to exactly be modeling.
It can also be rule-based systems and things that try and mimic human intelligence.
So it's like a broad field of trying to do something that copies human behavior.
Right.
Computers making decisions, kind of.
Right.
Exactly.
Trying to make decisions like a human.
So there's a lot of different components in that.
And it's been a field that people have been talking about for a long time and you've had
movies about it for a long time.
So it's just a broad field.
There's very many components, a part of it, because you have some things like expert systems
and some sort of rule-based engines that actually do a pretty good job of mimicking that when
there's not actually any modeling.
So they have a limited use because like self-driving cars, if you think about that, you can't build
enough rules to specify every time a car should turn, there's too much going on.
You have to use something more complex than that.
By itself doesn't mean modeling.
Machine learning is types of statistical models that learn from data to make decisions.
So that is just a broad field of modeling that is what most people think about when you
think about machine learning.
And it's just the modeling aspect.
And we can go into the classes of models you have, like class supervised, which is basically
you can have a model, look at a bunch of data that has a decision.
So like if you look at a bunch of pictures of cake and it says it will be cake, and then
you look at another picture that's a bunch of raw ingredients and it'll say it's not cake.
You know, you can train an algorithm to look at those two pictures and make the correct
decision by optimizing a function.
Right.
Where you have, you already know the answer and you kind of tell it like a kid.
That's right.
No, that's wrong.
Right.
Oh, good job.
That was right.
You know, and so on.
Yeah.
And it takes that feedback sort of iteratively and like evolves itself.
Exactly.
And it's extremely, extremely dumb.
So you have to just have a lot of training data that is balanced and meaning you have
the same amount of pi not pi type scenarios.
So it knows how to learn from that and have very catered data sets that don't generalize
very well.
On the far other extreme side of things, you have completely unsupervised learning, which
is basically let's throw some data at this algorithm and see what patterns emerge, see
what groups happen.
So it's very good to use like for very early on exploratory analysis of like I have a bunch
of data.
I have no idea what to do with this.
Let's see if there's anything interesting here.
But in between the supervised and unsupervised, you'll have like supervised learning or semi
supervised learning and reinforcement learning, which basically what they do is it's a combination
of those two where you have not quite explicit labels on everything, but it's not completely
just sending an algorithm out in the unknown to figure out what's happening.
And that's where you've seen like a lot of AlphaGo and a lot of really cool problems
have been done with reinforcement learning and semi supervised.
Okay.
And there's a lot going on in that space as well.
Yeah.
Well, I think that's a pretty good overview and unsupervised side.
That's probably the realm of where people start to think, you know, computers are just learning
on their own.
And what if they get too smart and they just, you know, take over or whatever.
But that's kind of, I would say that's probably the almost the science fiction side of things,
but it's also real.
Obviously people are doing it, but that's probably what people think of when they think
of AI is like there's data, the computer looked at it and then it understood it and learned
it and found things that humans maybe wouldn't have known about.
Definitely.
Some of the continuous learning stuff, which is a part of subset of that.
Yeah.
And then the very minor part of deep learning was basically as a subset of machine learning,
which is looking at trying to copy how your brain synapses work.
And it's just a type of machine learning where you think of the convolutional neural networks
and things like that.
So there's like the three big tiers and the different parts that fit in between those.
Yeah.
And when I was talking about quantum mechanics analogies, I was thinking of deep learning.
Exactly.
And like deep learning is extremely valuable.
A lot of the really cool research problems you're seeing people develop, open AI and all
of these people are using that for doing reinforcement learning with deep learning and things
like that is not what a lot of companies are using today in regulated industries or even
in most of most of America.
You know, a lot of companies are using more traditional supervised and just even getting
past linear regression in a lot of instances.
The deep learning stuff that science fiction people are using, but it's not very widely deployed
yet because there's a lot of problems with the deployments.
Yeah.
And probably even just knowing with certainty that it's right and that it's reproducible.
Completely.
Yeah.
I think that the, you know, it's such a buzzword machine learning and AI that, right.
If a lot of people seem to think, well, even if just an if statement is in there, like,
well, the computer decided, so that's AI.
It's like, well, that's not really what that term means, but that's okay.
I guess the computer decided, yes, you're right.
But that's just code.
I mean, code's been having if statements for a super long time.
I was thinking back to something in the British parliament where they were upset that there
was some airline, which is bad, that some airline was looking when people would book tickets.
If the people had the same last name, they would put them in different seats away from
each other and then charge them a fee to put them back next to each other.
And they were saying that this, this AI system that is causing this, that they're abused.
This is not AI.
This is just an if statement.
If the names are the same.
Exactly.
They're going to come apart and offer them the upgrade to get it back together.
Exactly.
Yeah.
So I think it's interesting to think about how companies can apply machine learning and maybe
the hesitancy to do so.
Right.
Like if if I'm applying for a mortgage and the company is using, you know, some deep learning
algorithm to decide whether I'm a good fit to provide a mortgage to.
Right.
Some states in the United States have like walkaway laws, right?
You just decide like, I don't want to pay anymore.
And you can have the house even if it's like in crappy condition and not worth what it was.
Right.
So it's a big risk.
So they want to get that answer right.
Yeah.
Exactly.
But at the same time, I'm sure there's regulations and stuff saying you can't just randomly assign
or not assign or have some super biased algorithm just making this decision and say, well,
it's not our fault the computer did this, you know, unjust thing or whatever.
Right.
Exactly.
And that's what a lot of insurance companies, for instance, are struggling with right now
is there are laws in the US on like fairness and you can't do gender discrimination or those
sorts of different protected classes discrimination.
But there's not a very hierarchical full regulation around machine learning right now.
So a lot of companies are kind of in the dark on like regulators don't really like machine
learning.
They don't understand it.
They don't like the non deterministic aspects or like it's a they like rule sets.
Right.
So if this happens, we'll do this.
They're very comfortable with having those sorts of rules, but having this kind of nebulous
modeling.
Exactly.
It's easy to do a code audit and say, OK, this is the part where they tested like their income
to credit card debt ratio.
And it was above the threshold you all have said.
And so you said no.
And so it's because they have too much debt.
And in fact, I can set a break point and I can step down and look at the code, like making
those decisions and comparing those values.
And then here's what it does.
Right.
And as far as I know, like break points and deep learning don't really mean a lot.
Yeah.
Because a lot of times if you use like a support vector machine algorithm, you won't have a
linear decision boundary, meaning that sometimes if you have income over this amount and this
other thing will give you a loan.
And other times we won't.
It depends on what some of the other inputs are.
So that's where regulators get very nervous because you can't have that strict rule based
system.
Yeah.
But at the same time, this is an amazing technology that could make, you know, make those decisions
more accurate.
And it could be better.
Right.
It could actually understand like, yeah, OK, so you do have a lot of credit card debt, but
you're doing this other thing that's really shows that you are a good borrower.
Right.
Exactly.
Their code would have completely ignored.
But the machine learning is like, no, no, that actually those type of people are good.
You want to loan to them.
Right.
You want to lend to them.
Exactly.
Because it could be good to have this.
Right.
It's not just a negative.
It's just you just don't know.
That's a part of the challenge.
Exactly.
Because you could have be able to do more targeted rates for consumers so then they can
have lower rates.
The custom, the insurance company will have lower default rates.
Basically, everybody wins.
The problem is for for executives and regulators is how do you know that this how do you have assurance
and trust the system is doing what you want to do and you're not going to end up
on the front page soon like the Apple credit card thing a few months ago with, oh, you were
really discriminatory or you messed this up.
So the problem is we're being able to provide that assurance and trust over algorithms to allow
them to be deployed.
And that's kind of where the industry is struggling with right now because no one really knows quite
how to have that with these deterministic qualities.
Like how do you get that assurance around the model doing what it's supposed to be doing?
So that's where there's a lot of work right now on the different machine learning monitoring
you can doing.
Do you need a third party to monitor those sorts of things so you can provide that trust
and risk mitigation to be able to deploy the algorithms that are beneficial for both the
company and the consumer?
Sure.
And, you know, we're talking about America because we both live here and whatnot.
But I think actually Europe probably has even stricter rules around accountability and traceability.
Definitely.
That's a good stuff for my cursory experience of both.
Definitely.
And Europe's actually doing a better job of first regulating it right now and also providing
guidance around the regulations.
So GDPR has several, that's the General Data Privacy Act in Europe, has some regulations
around like if a consumer's decision has been made fully automated, such as the example you
just gave, the consumer needs to know and they can request the logic on how that decision
was made.
So there's a lot of user consumer protections around machine learning algorithm use in Europe.
And there's also a lot more guidance.
Europe is now a little behind on, they're creating now a white paper on guidance around how would
you make sure the algorithms are doing what they should be doing to help the companies.
But Britain, the UK has, Information Commissioner's Office has released two different white paper
drafts on how you do explainable AI.
How do you make sure you have the assurance around your algorithms and actually doing some prescriptive
recommendations on how to do that correctly.
So like Europe is really ahead of the US right now on first regulating AI and then also helping
companies and consumers understand it and find ways so they can still use it.
US hasn't really addressed those yet.
Yeah.
And it was exactly that situation that you were talking about.
If a computer has made a completely automated decision, the consumer can request why, right?
Exactly.
And that was like thinking around this entire conversation, like that is the core thing that I think is at
the crux of the problem here that made me like interested in this because the deep learning stuff
and the ability to get a computer to understand the nuances that we don't even know exist out there and make
better decisions.
I think that that's, that's really powerful.
And as a company, you would definitely want to employ that.
If it's required that you say, well, it's because your credit to debt ratio was too far out of bounds.
Like, how are you going to get a deep learning, like poorest sort of thing going on and go, well, it said this.
It's like, well, the weights of the nodes were this.
And so it said, no, that's not satisfying or even meaningful.
Right.
Like, I don't even know how, how do we get there?
Maybe we get, maybe ultimately people would be willing to accept, like, I don't even know.
Maybe there's something like, okay, it, it's made these decisions and it, we had these false positives and we had these false negatives.
Like, almost like an AB testing or clinical trial type of thing.
Like, we're going to let 10% of the people through on our old analysis anyway.
And then compared to how the machine learning did on both like the positive and negative.
I don't know.
But like, how do you see that there's a possible way to get that answer?
Yeah.
There's a couple approaches.
One of the main ones has been a lot of my research the past couple of years, which is you can provide assurance around the implementations because like a lot of the points that you just mentioned, we don't have that ability with a human.
And you usually understand why did a loan officer give that loan either?
Like, there's the type of understanding some people are asking from algorithms doesn't really exist with humans either.
If you ask a human two weeks later why you made that exact decision, they're not going to say the same thing that they were thinking at that time.
So you want to provide a trust and an audit trail and then transparency around an algorithm.
Basically give it a history and show that it's been making reliable decisions and it's operating within the acceptable bounds for the inputs and the outputs.
So being able to provide this holistic business understanding and process understanding is very huge.
It's very it's not really as much of a tech problem as it is a business problem and a process problem.
But also be able to provide the ability of this is what the algorithm saw when it made this decision.
So for even a deep learning algorithm, say you are taking in FICO score and you're taking an age and you're taking in zip code and things like that to make this decision.
Some of those are protected glasses, but you're taking in information by a consumer to understand.
You don't need to see like what neural network layer said something.
It's like based on these features, because your your FICO score is above 600 and because your zip code was in this high income area, we're going to approve this loan or not approve this loan.
So that you can see with some research.
Anchors is a great library that was open sourced a few years ago.
It's a there's Python implementation and Selden Alibi has a library that's really, really good that has a production grade implementation.
Can help you see what did the algorithm see when it made this decision?
So you can start addressing that inside the whole bigger process of providing business and process understanding.
I see.
So there's all these different facets or features that come in and you can say you can't exactly say, you know, here's how the flow went through the code and here's the if statement.
But you can say it keyed off of these three things.
It keyed off the fact that you have three cars leased and you have this credit card or whatever.
Right.
Like it said, those are the things that like sort of helped it decide.
Made a decision.
Exactly.
So when you put that in tandem with understanding the whole process, providing the ability to go back and verify, you can start getting more assurance around the implementation and start getting comfortable with it.
Because that's the other problem.
A lot of times with these algorithms is like it makes a decision.
And as a company, like how in the world if a customer asks, why did you make this decision about me six months ago?
How are they going to go back and get the exact log file, make sure you have the exact model version, be able to rerun that specific model version and see all these types of information?
It's not strictly just a tech problem of let me see which neural network layer was activated and which neuron.
Like it's more process based and there's a lot of components to it.
So that's where a lot of times we see right now in the data science community, people trying to solve this problem by building better explainability, by understanding that neural network better.
But that's not really addressing the consumers ask on like, why did this make decision happen?
How do I know that you just didn't arbitrarily make this?
How do we know it's not biased?
Those sorts of more fundamental issues aren't something you can just address by better neural network explainability tool.
Yeah. Do you think there's somewhere out in the future, the possibility of like a meta network in the sense that like there is a neural network that looks at how the neural network is working and then tries to explain how it works?
Like use AI to like get it, get it to sort of answer what the other AI did.
There's definitely some things like that currently in research.
There's a whole bunch of different good explainability libraries out there and people that are addressing specifically those types of problems.
And that's Monotar is doing that as well, except for more of the business process side and the basic understanding about the model.
It's really to get the consumers comfortable.
It's going to be understanding and being able to prove why something was done, which is more than just specific deep learning interpretability.
Because a lot of times these loan models and stuff are still like we're moving from a loan officer to trying to do a very basic machine learning model.
Like they haven't even gotten to complexity of deep learning.
So it's like incremental improvements.
Right.
You talked about your origins being in the big data era and all that.
Is there some sort of statistical way that people might become, you think, comfortable with things like deep learning, making these decisions?
Like, so for example, you've got all of the records of the mortgages in the US.
If you were able to take your algorithm and run it across those as if it was trying to make the decision and then you have the actual data, kind of like the supervised learning you talked about going through and saying, OK, we're going to apply it to all of this.
Maybe we don't share that data back with the company, but they give us the model.
We run it through all of it.
And it's within bounds of what we've deemed to be fair to the community or to the country.
Definitely.
So that's those are some definitely tests we can do.
And ideally, if you're building a loan algorithm, you're going to want to see what those historical statistics are to make sure that our our model is doing, say, classification percentages to be in line with what's expected for the general population.
So, for instance, if you're you're doing an algorithm, if you have basically this at certain FICO bands, FICO score bands, you're going to have X amount of acceptance.
So if you start seeing your model starts really not accepting people that are in a certain range, like we can definitely start raising a flag.
There's concept drift going on.
So there's definitely tests you can do around there.
There's a Fisher exact test that lets you check.
Say if you have age, you don't really want to be using age as a indication or gender, for instance.
But in some instances, you have to.
So you can run a test to see if it's ever statistically significant that that one variable is negatively influencing the outcome.
There are definitely ways you can make sure that the algorithm, based on the example you said with the loans, this is the amount of normally acceptance, not acceptance that we've had over the past X amount of years in America for loans.
And that's kind of what we think is OK.
There are definitely tests you can do, such as the Fisher exact test.
It's a statistical test and others that you can do around making sure an algorithm isn't biased and it's going within the percentage that you're wanting it to do for acceptance.
So there's a lot of tests that companies can do there, some that we're implementing, some that other people are implementing and a lot of things that people can do.
But really, for the public to really start accepting that machine learning is OK, I think there really needs to be some sort of more government regulation that's at least even like rubber stamping that this is OK.
And that we've looked at this algorithm.
There needs to be like third party assurance and third party audits of algorithms or not even you don't have to share your code if it's like it's a proprietary thing.
But just the understanding that this is doing what it should be doing and it's not discriminatory can be very important for people to be able to trust AI systems.
I think it's going to be super important.
And when I threw that idea out there, what I was thinking of was the XPRIZE stuff done around health care and breast cancer, where instead of you getting all the data, you submitted a Docker image with your algorithm that was then run and it couldn't communicate out.
It was run against the data and then you got just the trained model out of it and then you could basically go from there.
So like there was this sort of arbitrage of your model meets the data, but you don't ever see the data and no one else sees your model kind of thing.
Definitely.
It's just somebody needs to facilitate that.
That's a trusted party.
So like some sort of government regulation to enable that kind of thing.
But those sorts of processes will definitely start allowing people to trust the system and allow state regulators and things to be able to be signing off on systems and being comfortable to let the public enjoy better insurance policies.
Right.
But we need to have some sort of assurance to get there.
This episode of Talk Python to Me is brought to you by me, Reuven Lerner, and Weekly Python Exercise.
You want to do more with less code or just write more idiomatic Python?
It won't happen on its own or even from a course.
Practice is the only way.
Now in its fourth year, Weekly Python Exercise makes you a more fluent developer.
Between pytest tests, our private forum, and live office hours, your Python will improve one week at a time.
Developers of all levels rave about Weekly Python Exercise.
Get free samples and see our schedule at talkpython.fm/exercise.
So you talked a little bit about some of the Python libraries that are out there to help people understand how these models are making decisions and understand a little bit better.
Some other things that are probably, like we could talk about some of the other things you're doing and, you know, some things that might matter.
It's like you talked about the company that if I asked them six months later, why did you decide this thing, right?
They probably still have all of my form fields I filled out.
Like my credit history is X.
My average income is whatever.
I've been in the job for this long.
But how would they go back and run that against the same code, right?
So maybe what they would do is they would go and say, well, let me just ask the system again.
What would the answer be now and why?
But they may have completely rolled out a new version of code, right?
It might not even do the same thing.
And I'm sure they don't have like retroactive versions of like the entire infrastructure of the insurance company around to go back and run it exactly.
Maybe they do, but probably not in a lot of companies.
Like the ability to almost a version control, but like production, right?
So knowing how the model changes over time, like what else do you guys need to look at or keep track of to be able to like give that kind of, you know, why did this happen?
Answer.
Definitely.
And that's the key part is summarizing all information and being able to replay that exact algorithm with the decision.
So to be able to do that, you really have to have exact feature inputs.
Like what exactly did the user say, the exact model version, you need to know the, so like the model object file, the pickle file, something like that, the exact production Python code.
Then you have to have the actual version of the library used in the same environment.
So there's a lot of things going on there and the amount of logging and that you have to have in place there and have it very easily to be accessible and non tampered with and be able to recreate that environment.
That's a hard technical problem.
A lot of companies don't have in addition to just having like the, how do I understand that the exact, some sort of interpretability for the decision and then the metrics and monitoring around it.
That's a big ask.
And that's where a lot of companies are struggling when they start hitting these regulatory audits.
Sure.
Well, I can imagine it's really tricky to say, all right, well, when our app started up back then and we went back and we looked in the logs and it said this version and this version, this version of the library, but maybe somebody forgot the log.
Oh yeah, there's a dependency library that actually matters.
And it was that version where we were running on this version of Python and its implementation of, you know, floating points slightly, slightly changed.
And it had some effect or I, you know, I don't know.
Right.
Like there's just all these things.
And it seems like there's probably some analogies here to the reproducibility challenges and solutions that science even has.
Exactly.
It's along the exact same lines, but it's even more exacerbated and more difficult to solve.
Because if you think about science, it's like you're trying to reproduce the results of one paper.
You know, if it's a biological experiment, it might be a little harder to recreate those conditions.
But in computer science, like you should be able to save the seed, send a Docker file with everything and rerun your algorithm results.
Right.
But people are even having a hard time to do that because the amount of process and forethought into how you're going to be packaging things, how you're going to be setting things up, it's a lot to deal with.
But like reproducibility is just a major crisis in science right now, too.
But it's really hitting the corporate environment really hard to be able to provide that kind of ability around the algorithms to be able to answer questions.
Because if like you want to implement these things, people are going to want to have audits and they're going to want to understand why something was done.
So exactly what's happening in the scientific community, except even on a larger scale.
Now, two things you talk about when you look at Monitar's website, talking about what you all do there.
One is counterfactuals.
And the other is detecting when model and feature drift occur.
Do you want to address those problems a little?
Yeah, definitely.
So counterfactuals is basically what we've just described is the re-performance of an exact transaction.
So we record all those things, the versioning of all the files.
So when you go back six months from now, six years from now, and go and select on a specific transaction, if it's a tabular transaction, we can actually hit a button and we will pull all that stuff up in a Docker container and rerun it.
So that's what we're calling counterfactuals is the ability to go back and re-perform a transaction and then perform what-if analysis.
Say like one of the variables said your income was $200,000.
And if you want to change it to $150,000, you can go do that and rerun the transaction as well off of that old version.
So it allows you to do the sensitivity analysis if a consumer is like, well, what if my income was slightly different?
But also re-perform for audit tracing that it's doing exactly what it said it was going to do.
Sure.
Okay.
And then model drift.
Yeah.
Model drift is exactly like what we were talking about a few minutes ago with you have loans.
Normally 60% of loans are rejected, 40% are accepted.
And that's kind of the average for this risk class.
Model drift will allow to see in a monitor platform when your model has started to drift out of those bounds.
If you say, I'm okay if the model's in between 75% classification and 50% classification of you don't get a loan of rejection.
And if we start slipping to 80% of loans are now being rejected, we're going to throw you alerts and say, hey, your model has drifted.
Something is wrong here.
I see.
Yeah.
So it's not necessarily detecting that the model is making some variation in its predictions, but it's saying you've set these bounds.
And if it's outside of these bounds, like something is wrong.
Let us know.
Exactly.
And that will be saying that the algorithm is making kind of a drift in what it's supposed to be predicting.
Same with features.
There's a lot of times, there's a great paper a couple of years ago by Google called the high debt or high credit card debt or something in machine learning implementations.
The name's not quite right there, but it's a very popular paper on technical debt, whereas basically a lot of times when you have an algorithm, a lot of the code around it is where your issues are going to happen.
So if you have a model that's used to having features between 1 and 10, and you start having a drift with a mean of 5, and you start having a drift up, that can be affecting the model's outputs, but you can't really detect it until it's too late.
So what Monotar does is we allow you to look at the feature drift and see, like, if I'm expecting this feature between 1 to 2 standard deviations of 5, a mean of 5, and you start getting higher numbers out of there, we'll know, like, hey, there's feature drift, which means your model is not performing in the same environment that it was built for.
So we'll be able to know that, hey, you need to go look at this, the situation your model's built for has changed.
Because a lot of times when these models start misbehaving, it's not because the model code has changed, quote unquote, it's because the environment that it was built for has changed.
You're no longer in that same environment.
I see. And that's one of the real challenges of the whole ML story, right?
Is the model's good at answering the question the model was intended to answer, but it may be completely inappropriate for something else, right?
Like, self-driving cars work great in Arizona, but you put them in the snow and they can't see the road anymore because they don't know to look at snowy roads or whatever, right?
Exactly. Because algorithms are extremely, extremely dumb.
Like, people are trying to make them better with this transfer learning and some of the semi-supervised learning and things.
But when it comes down to the root of it, there is no thinking going on here.
It doesn't matter how accurate it is at detecting cancer and radiology images.
There is no thinking. It's a dumb algorithm that's made for a specific set of circumstances.
It can be fantastic as long as those circumstances change.
But that's where the key problem happens in production is those circumstances no longer hold true, so your model starts performing badly.
Your model is doing the exact same thing it was trained to do, just the inputs are different.
I see. So one of the things that might be important is to keep track of the input range and document that in the early days and then keep checking in production that it still holds true.
Exactly.
And that's where we can start testing for bias and things like that as well.
Seeing with one specific variable, such as we mentioned, gender variable, if that starts being a key influencer for a decision, we also know something is up there.
So you can start doing proactive bias monitoring.
Interesting. So maybe you don't actually want to take gender into account, but it's somewhere in the algorithm or somewhere in the data.
And you can test whether or not it actually seems to be influencing.
Like you can detect bias in a sense.
Exactly. You choose whatever feature.
Like if you're building an algorithm, you should try and never have gender or something like that in there.
But occasionally, such as you think of cancer screening, you're going to have to include that because that's a key component.
I would argue you should never include gender if you're doing a credit card application.
But if you're doing something more fundamental, like cancer screening or something, you still need to be able to have those sorts of things.
Or like if it's a image recognition algorithm, you're going to have to include race just because it may may different skin tones may affect the results of the algorithm.
Doesn't mean we're trying to be any sort of bias.
But that's why you want to have these controls to make sure bias doesn't occur.
We've had a lot of radiology implementations that won't work as well on certain individuals.
So like there's all these things that machine learning can improve everybody's lives.
We just need to have the right safeguards in place because almost every single company is deployed machine learning.
None of them are trying to be discriminatory.
That's not the purpose.
They just there's these things that will happen and they're not aware of.
So it's just making sure you have a controlled environment to make sure that doesn't happen or being able to catch it when it does happen so you can fix it.
Yeah, that's pretty awesome.
What else should people be thinking about that they either need to be doing, logging, trying to use libraries to help with, especially in production with their models?
Definitely like the structure of how you do your models is very important.
I'm a huge advocate of using microservices and Docker containers and trying to do, especially for these complicated deployments, make as many of the services possible.
So it's just like sometimes you want to have your algorithm is strictly in a container and then it will interact with your logic in a different container.
Because when sometimes you have everything combined into one area is when you can start having like that technical debt and things build up.
And it's very hard to figure out what's broken and where is it broken.
So being able to keep things as separate as possible in complex deployments really helps to figure out the root cause.
Yeah, that's interesting.
Because if you have it kind of mixed in to your app, you probably deployed 10 versions of your app.
Did any of them actually affect the model or was that just like to change some other aspect of an API or some aspect of the website or something like that that is just,
well, we changed how users log in.
They can now log in with Google.
But that didn't affect the machine learning model that we're deploying.
But if you have it as a separate API endpoint that's its own thing, then you know.
Exactly.
It's the same thing from like science is how do you get rid of the confounding variables and do as much of a control test as possible.
So the more you can have those things that you know what's changing, you'll know what to fix when something breaks.
So having those sorts of architectures and really coming in with document, document, document and auditing because I'm an ex-auditor.
If it wasn't documented, it doesn't exist.
Not really true, but that's how auditors look at things.
But that's extremely important to do when you're working in regulated industries or you're working in areas when you're building these models.
You need to document all your assumptions.
Where's your data coming from?
All of this, the plain businessy things that, frankly, data scientists hate to do.
I hate to do it as well.
But you need to have that kind of thing for being able to show other people, different stakeholders, and also, frankly, even cover yourself if something comes back later.
Like, here's why we did something and helping you remember if you look at this code six months ago.
So just the documentation, having these sorts of planned way that you're building an algorithm instead of just agileing.
Agile is great, but you have to have an overarching plan for some of these things instead of just MVP it until it hits production.
Sure.
And while it also sounds like a little bit of the guidance is also just good computer science.
Right, exactly.
It's a very big problem in this space is data scientists are not normally good software engineers.
So a lot of the great software engineering practices haven't really translated into machine learning code.
There's becoming a big trend towards that with machine learning engineers and things.
So we're definitely trending in the right direction.
But still, there's a lot of models that get deployed that don't have the engineering rigor that is common in the Python community.
Like, there's certain ways we do things with CICD, with unit tests and stuff, and a lot of machine learning code doesn't have those things.
Sometimes you can't really, in a non-deterministic outcome, it's hard to unit test.
But there's a lot of the processes of good engineering that we can apply to help make everybody's lives easier and better AI deployments.
Sure.
I was thinking about that as well in testing.
And it just seems like that's one of the areas that is tricky to test.
Because it's not like, well, if I set the user to none, and then I ask to access this page, I want to make sure it does a redirect over to the login page.
If I set the user to be logged in, and I ask the same thing, I want them to go to their account page.
And so it's super easy to write that test.
User's none, call the test, check the outcome.
User's this, call the test.
What about testing these ML models?
It's definitely a challenge, and it's a developing art.
And it's more of a science at the moment than, more of an art than a science.
But one of the ways you could do it is kind of like how we talk about ranges, is you'll say, like, to unit test a machine learning algorithm, like, hey, we're expecting a range between this and this, and we're acceptable.
These are acceptable ranges.
And you just use it there.
You won't know if 100% is working, because you would have to look at over time to see if there's drift.
But you'll be able to say, like, hey, if it's a regression problem, meaning I have an output between 1 and 10, and it's supposed to be a 5, if I'm hitting an 8 or a 2, that means something's probably not quite right.
You can put some sort of ranges for your unit test.
So it can't be quite the deterministic, like, I know exactly this test is failing or not, but at least can give you some assurance and some heads up for your curve.
Sure.
So maybe it feels a lot like testing scientific things as well, right?
You can't say, if I call the, you know, estimate, whatever, right?
And I give it these inputs, all floating point numbers, I can't say it's going to be equal to 2, or it's going to be false.
It's probably some number that comes out.
And you're willing to allow a slight variation, because, like, the algorithm might evolve, and it might actually be more accurate if it's a little, you know, if it's slightly better.
But it's got to basically be within a hundredth of this other number, right?
So you've got to do, like, range.
Like, it's in this range, and it's not too far out.
I guess it's probably similar.
What do you think about, like, a hypothesis or other sort of, like, automatic property-based testing where you could say, give me some integers here in this range and give me one of these values and sort of give me a whole bunch of examples and let's test those.
That's definitely a very good, sensitivity analysis is a very good way to do that.
So, like, ideally, you'd want to do that kind of testing.
So it's better.
You can't really unit test as well.
Like, we talked about that.
But sensitivity analysis testing is fantastic to do, which is, like, here are the different scenarios, here are the different users we would get, and run a bunch of them with slight variations through your model and see if it performs as it should.
So that is definitely a very good way to test a model, and you should never deploy a model without doing that.
The other test you can kind of do is you can't really unit test machine learning code too accurately, but you can unit test data.
So there's a couple good libraries out there that will help you unit test data right now.
I think marbles might be one in Python, and I think there's great expectations that you see, like, is the schema right?
So that's really huge because, like, this is supposed to be an int, or is this supposed to be a float, or, like, a float between these numbers and things.
So you can really check the input data too.
So there are some tests you can do a little more accurately around your data in addition to the sensitivity analysis.
Yeah.
Great expectations.
It's cool.
It's got things like expect column values to be not null, or expect column values to be unique, or expect them to be, you know,
between such and such values.
That's pretty cool.
Yeah.
So it's a very cool library.
Very good to do that kind of testing.
Yeah.
I suppose if you have some sort of, you talked about unexpected situations as, like, it's, you know,
my analogy was it's built for dry, sunny roads, not snowy roads, and automatic car driving or automated driving.
But similarly, it's probably not built to take a null or none in a spot where it expected a number, right?
What's it going to do with that, right?
And that's, it's great to do the looking for the, using a Taleb example, black swans.
Like, it's good to test your model for when something bad is going to happen.
Like, even just to do the correct try accepts type statements around it.
For like, here is something crazy that should never happen, but let's see what happens anyway.
So we can handle that.
So we don't become the next news story with this company really screwed up type scenario.
So it's good to do those types of tests that are just like, we hopefully never have this, but what happens if?
So we can build the type of exceptions and logic around those sorts of crazy scenarios.
Sounds good.
Sounds like a lot of things that people can go figure out, you know, find some of these libraries, try to add some of these techniques.
I mean, you guys over at Monitor are doing this.
You're not quite out of Techstars yet.
You know, people can check you out.
What else would you recommend that folks maybe look into to make this practical in their environments?
So definitely those two great expectations is great for like unit testing your data.
Alibi is a library that has anchors implementation.
I was talking about anchors at explainability library.
It basically gives you if statements on why a transaction was done.
It's kind of a 2.0 from Lime, which is a very popular data explanation.
Those are some good ones.
Shapp is a great library as well.
It gives you, it's game theory based for giving you values of what's, how your algorithm is interpreting a decision.
That's cool.
Yeah.
So it's a very, very cool, cool library.
And then it's just really starting to apply.
So that's all of the like explainability type scenarios.
Py Metrics has a very cool library that does some bias detection.
That's something that's really cool to check out.
Quintus is as a bias and fairness audit toolkit that is really cool.
And that's out of the University of Chicago.
So those are some good ways to get started on how to provide more assurance around your models.
And then just really, you want to be doing Docker, you want to be doing best practices on your engineering.
Yeah.
So some of the good places to start.
Yeah, absolutely.
You know, something that came to mind while you're talking, there's this thing called missing no, missing N O, which is a Python library for visualizing missing numbers and data.
And so you can give it interesting.
I think Panda data frames or something like that.
And it gives you these graphs with like continuous lines if it's everything's good or like little marks where there's like bad data stuff.
It's a pretty cool library for like trying to just like throw your data set at it and visually quickly identify if something's busted.
Well, that's very cool.
I have not heard that one.
I'm going to go check that out.
Yeah, absolutely.
Absolutely.
Okay.
One final machine learning question, I guess.
Keep it positive.
Like what are the opportunities for this?
You talked about how many companies are kind of at the rudimentary stage of this modeling and predictability.
And there's obviously a lot more way to go with the challenges that the whole episode basically has been about.
But what do you see as the big opportunities?
You get this.
You get these key components, right?
You're going to be able to start having companies providing cheaper insurance, better medical screening.
I mean, self-driving cars.
These are all the types of things that are really going to help society and humanity when we get right.
There's just a few things like when we talked about to get ironed out.
But really, like the future is very bright.
Machine learning can do some great things.
And like together as a community, we'll be able to make that happen.
Yeah, awesome.
And, you know, so you talked also at the beginning about your Techstars experience and you guys are going through and launching Monotar through Techstars.
And that's awesome.
But I suspect that a bit of a change has happened.
Like Techstar, to me, these incubators and accelerators are all about like coming together.
It's almost like a hackathon, but for a company.
You come together with all these people and it's just like this intense period where you're all together and working with mentors.
And co-founders and creating.
And we've all been told to not do that.
So how's that work?
Well, Techstars did a very good job of switching to online.
So still all the same things happen.
They even started setting up some like water cooler sessions and stuff for people to kind of just chat informally.
And so they moved to online to Zoom very, very early on and did a very smooth transition.
So that was very good.
They did a great job of handling it.
We're having a virtual demo day in two weeks, end of April, which is not ideal.
But we're going to also have a live one in September as well, I believe.
So they're really going above and beyond to help with the transition for companies and doing a bunch of extra like extra classes around fundraising during COVID and things like that.
So Techstars has done a great job transitioning and they had all the technology in place to make it a pretty smooth transition.
So even though it's not the same, like the quality is still very much there and we're still getting a lot out of it.
Yeah, that's good.
I'm glad that it's still going.
I mean, it won't be rough.
How did you get into it?
You talked about, I don't remember the exact numbers, but it sounded like 101 applicant to acceptance ratio or something like that.
Like if people out there are listening, they're like, I would love to go through something like Techstars, maybe ideally in a year when it's back to its in-person one.
But even not, right?
I'm sure it'd be super helpful.
What was that experience like?
How do you decide to get going and how'd you get in there?
So we did some networking around from the Boston area, kind of like meeting some of the founders in the area, different VC firms, kind of like early socializing.
Like who we are, what we're about.
So we kind of got our name around.
So starting like the socialization with the, there's Techstars in different cities, kind of like getting kind of the community of founders and startups, kind of get yourself known.
And then it's the application process.
You just need to really rock that.
And then just being part of the community and doing a good application and have a compelling story.
But definitely the pre-networking before the application to kind of like start showing who you are, do as many meetups as you can, like get your name out there.
So if someone has heard of you when they, when the application comes across, it's definitely helpful.
Yeah, I'm sure they, oh, I've heard of them.
They actually were doing something pretty cool.
I talked to Andrew or something like that kind of stuff goes really far, farther than it seems like it should necessarily just like on the surface.
But yeah, absolutely.
There are definitely companies that got into this year's Techstars program that had, that were completely cold.
So it's not like, it's just based on the merit.
We happen to be in the area and had the ability to network with people before.
But honestly, like if you're in Techstars or not in Techstars, you should be doing what we were doing anyway, socializing your company.
So like they are very, very sure they're a fair company.
Several of our companies are female only led.
So it's like they're doing a great job of being a fair and inclusive place that's trying to be as non-biased as possible with acceptance.
Yeah, that's excellent.
I suspect that machine learning in particular and data science type of companies in general are probably pretty hot commodities at the moment.
And you have an above average chance of getting into these type of things, just looking in from the outside.
So even a lot of listeners who particularly care about this episode, maybe they've got a good chance.
Definitely.
And let me know.
I'd love to hear your idea as well.
Awesome.
Feel free to reach out.
I'm still connected in the space.
So let me know.
But definitely innovative AI ML companies are definitely big right now.
It's just making sure you have something fully baked and are solving a real business problem and not just a tech problem.
Yeah.
Very cool.
All right.
Well, I think we're just about out of time there, Andrew.
So I'll hit you with the final two questions.
Sounds good.
Yeah.
If you're going to write some Python code these days or editors, do you use?
Ah, yes.
The famous question.
When I'm writing real Python code, I'm using Visual Studio.
When I'm doing exploratory data analysis stuff, I can't be Jupyter.
Yeah.
Those are my two go-tos.
I used to be an Atom with Vim for my real coding stuff.
But the newer versions of Visual Studio are just so good, I can't pass it up anymore.
Even though I liked being a rebel and doing completely open source, like Vim type stuff.
Yeah.
Well, and then Atom and Visual Studio Code have such similar origins, right?
They're both Electron.
Atom came from GitHub.
Microsoft now overseeing GitHub.
I think there's a lot of zen between Visual Studio Code and Atom these days.
So it's not that wild, right?
It's not that different.
That's cool.
And then you already mentioned some really good Python packages and libraries out there.
But other notable ones maybe worth throwing out there?
Yeah.
NetworkX.
I really love NetworkX for doing graph theory and things like that.
And it's a very good connection with like Pandas and the Python dictionaries to be able to have different nodes and edges and things.
So if you're doing any type of network-based work, which I've done at some previous companies and PhD program, it's a very good library to have.
My favorite machine learning library has to be SkyKit Learn.
It's just so easy to use, intuitive.
The documentation, like I've never seen a Python library with such good documentation and so many good examples.
Yeah.
And then for Alibi, I really like as well for like that Anchors implementation I was talking about.
So those are probably my three at the moment.
But the change is weekly.
Yeah.
Those are great.
Awesome.
And then final call to action.
People want to put their machine learning models into production or they have them and they want them to be better.
Maybe what can they do in general?
And then also how do they learn about what you guys are up to?
Definitely.
Monitor.ai.
Come check us out.
If you're in a regulated industry and you're wanting to deploy a machine learning model, we offer services to help you do that.
And also the machine learning record platform that will allow you to have that audit trail and the counterfactuals and all the things we talked about in this episode to allow you to get past the auditors and regulators and being able to move those models to protection.
Yeah.
Cool.
All right.
Well, it's been really fun to talk about machine learning and watching how it goes, verifying what it does.
And, you know, I think these, like you said, these are the things that are going to need to be in place before it can really sort of serve the greater public or the greater companies out there that need to make use of it.
Right.
So great topic to cover.
Thanks.
Thank you so much.
Been great talking to you.
Yeah, you bet.
Bye bye.
Bye.
This has been another episode of Talk Python to Me.
Our guest on this episode was Andrew Clark, and it's been brought to you by Linode and Reuven Lerner's weekly Python exercise.
Start your next Python project on Linode's state-of-the-art cloud service.
Just visit talkpython.fm/Linode, L-I-N-O-D-E.
You'll automatically get a $20 credit when you create a new account.
Learn Python using deliberate practice every week with Reuven Lerner's weekly Python exercise.
Just visit talkpython.fm/exercise.
Want to level up your Python?
If you're just getting started, try my Python Jumpstart by Building 10 Apps course.
Or if you're looking for something more advanced, check out our new async course that digs into all the different types of async programming you can do in Python.
And of course, if you're interested in more than one of these, be sure to check out our Everything Bundle.
It's like a subscription that never expires.
Be sure to subscribe to the show.
Open your favorite podcatcher and search for Python.
We should be right at the top.
You can also find the iTunes feed at /itunes, the Google Play feed at /play, and the direct RSS feed at /rss on talkpython.fm.
This is your host, Michael Kennedy.
Thanks so much for listening.
I really appreciate it.
Now get out there and write some Python code.
Thank you.