Cows, Camels, and the Human Brain - ML 182

Hey, everybody, welcome back to Adventures and Machine Learning. I'm one of your two hosts, Ben Wilson. And Michael Burke. How's it going?

And today we're going to be talking about a white paper that Michael read a while ago, and we're going to talk about cows in fields and deserts. The most exciting topic out of all the topics. Cool. So I'll set up the problem statement and quickly discuss the method and then we'll get into the philosophy behind it as well as the nitty gritty of the algorithms and the solvers.

So this paper was developed for this method, I guess was developed I think in twenty nineteen or twenty twenty by Facebook's AI research team, and it's really cool. And the basis of it is they're looking to develop a causal learning algorithm that is better than all the other ones. So other standard causal learning algorithms are used DAGs or try to just get creative with the data essentially, and this model does the latter. And what it does is it creates environments and it looks to develop causal inference based on those environments.

So what does that mean. Let's take a little bit of a deeper dive. So, like Ben said, they use the example of cows and camels and both have fore legs and our animals. But the thing is, one thing that is specific to cows is they often have a green background, so pasture, grass, whatever it is.

And then camels, on the other hand, often have a sandy background. And so this is a classic example of a machine learning algorithm without any adjustments, would train on the background color. And that's actually what happened. They I forget the exact numbers, but they trained a bunch of images and to developed a classifier, and it turns out that when they change the background color for a cow or a camel, it just predict the opposite label.

So, as you can see, this is a problem for generalization, and instead what we're looking to do is develop a causal framework that says well if basically uses counterfactual logic, and we'll get into that in just a second. Good so far, Ben, Yeah, it's a good overview of the intro. And like what they're trying to do. And I think anybody who's listening in who's ever tried to build a CNN classifier, regardless of how sophisticated they're going we'll run into the same thing I have in the past, where you have images from the real world and.

People have looked at and said, Okay, I know what's in this image. I'm labeling it as X. This other one is labeled as why. And when you train the model, it's going to learn things that's dependent on what it sees in the data and whatever.

The simplest path is to differentiate between things. It's going to learn that pattern. Yeah, that's a really good point. Algorithms tend to, well, not tend to they're optimized to take the simplest path.

So if there's some correlation or some feature that in this case, in this sample of the data set is really powerful, then that feature will be very important. And when you exit that data space while the model and generalize at all. So basically what the method looks to do is it looks to develop environments based on the sampling schemas. So in the example of cows and camels, one could think about the country that they're sampled in and that might be indicative of the background.

One could also think of the time of day or just other pieces of information about how the data are collected. And then what you look to do is leverage a counterfactual framework, and so let's get into that in just a se For those of you that don't know, a counterfactual is essentially a data trend that we observe that we would or that we would have observed without a treatment. So you can think of it as the control group in an ab test. If we see a data trend and I don't know, we change the button from red to green, well, that's the treatment.

But in the control group, we want to see what the data would look like with a blue button. And so with that framework, we can look at average treatment effects and differences between those two groups and then use that to develop a causal framework. And they sort of borrow the same idea, but what they do is, instead of let's we create let's say ten environments, each of those are ten environments from different countries, so Tanzania, Ireland, the Sandiast, and the least sandy places.

So from that, what they do is they look to develop rules and if anytime those rules are broken, then the model is penalized heavily. So you can sort of think of it like a regularization term that's added into the loss function and that's actually what they exactly develop is they look to find instances where a rule is broken and therefore that rule cannot be true. So if a cow, ever appears in a sandy background, then sandy background cannot create camel, or it cannot cause camel, and vice versa.

If a camel appears in a grassy background, grassy background cannot cause cow And that's sort of how humans think. If there's ever a rule broken, then causality is broken. So instead of optimizing for correlation, we optimize for causality. And that's basically the high level framework.

And it has this very interesting effect when they implemented this in PyTorch and ran it through some of the tests that they did, where it showed something that most people who are familiar with training supervised learning, this is worse. Their training lost metric. It went down compared to a traditional optimization technique. I think in the paper was like with their colored mness data, it's like seventy six or seventy four percent accuracy on training, and then when they took that onto test it was like ten percent accurate, which is pretty bad.

And then with their approach their training was in the sixties on both training and test on the holdout validation. So this approach of making those restrictions within those environments and saying this penalization term is so strong that I'm going to deweight this cycle of optimization to say this is actually not this is not correlated because it's not causal based on that inference that's going on. Yeah, and that's a really good point. The purpose of most predictive models is to generalize past the data set.

I think that's pretty agreed upon. And if your data are not perfectly representative of future data, then you might have issues. Even if it is, you might have features in there that, for whatever reason, are very indicative of the why value, but in the real world are not. And so by ensuring that you're learning causal relationships instead of spurious correlations, for example, you generalize a lot better.

But as Ben said, that can kill your training accuracy because you're not picking up on random features. Yeah, definitely. And you can see this with even open source data sets that are very simple, where you're trying to predict something relatively simple, like oh, I want to do bike rentals in San Francisco, I want to use that data set, and you might throw in some data in there to say, well, I want I want a month of year in there, and I want adjacency to a holiday, and I want cloud cover percent.

It's going to pick up on whatever that strongest correlation might be. And maybe it's precipitation. You know, people don't write rent bikes when it's raining out because that's a terrible experience. But if in data, particularly in the typically spurious assumption that a lot of people happening and test being IID, so it's very challenging to get that, particularly if you're not if you don't have a truly ludicrous amount of data to train and validate on, if you're not very careful with that split that you're doing and making sure that these two samples are of the same distribution and are independent of one another, you're going to get some really weird results.

It's going to learn on something that you didn't wanted to learn on. And this happens all the time. So that this paper and what we're talking about is a means of a simplifying the process that you would otherwise have to do with building a causal model. I don't know if you ever had had to build one of those, but they're in the extreme to build, just due to the amount of time and effort and computation that you have to do.

Yeah, I have. I remember one of the first projects that I was working on was a modeling project, and I talked to our resident expert in causal inference causal modeling. It's like, which is harder, predictive modeling or causal modeling, And he's like, that's a dumb question. Causal modeling is Predictive modeling tends to be more towards optimization and causal modeling.

This was his argument. You have to actually know what's going on under the hood and make sure everything makes sense and then explain it. Predictive modeling can be a black box, and if accuracy is ninety five percent, we're happy. And it's interesting to see these two fields merge because black boxes are becoming at least over the last several years, black boxes have become less acceptable both from a model trust standpoint, so I for stakeholders don't trust it as much, and then also from a generalizability standpoint.

We tend to like you can backtest, obviously, but we want to know that future predictions will be not that bad. So having causal knowledge of what's going on is really effective. Yeah, having that causal relationship with rejecting potential features, whether we're talking about images or just data with new changes in data that are coming in for prediction, that this recording and measuring of the real world in order to generate predictions, the model would be aware. Of that penalization effect of spurience.

So if you have a. Very model can experience that there's going to be some foundational shift in your feature data at some point. When that happens, this approach can actually counteract that to a large degree, provided that it's the training data exactly. And Ben started to get into one of the more technical pieces, and I think we've we've sort of painted a high level picture so we can start descending into the weeds.

But he started talking about the assumptions of modeling and standard modeling. Basically, do you think of most machine learning training scenarios. It's called so that this method is called invariant risk minimization, and standard machine learning is called empirical risk minimization. Basically, you can think of risk as sort of like a loss function, and empirical means that the data that we observe invariant refers to the causal framework, so that it must invariantly minimize risk.

And for empirical risk minimization. There are three core assumptions that the paper sites. The first is that data are IID so independent and identically distributed, and as Ben said, especially within a train test split, that's often not the case. And then even well, if you can just think about it, when you sample from different environments and then you treat those environments as ID, that's invalid.

So with train test splits and then just other training, if we just look at training accuracy itself, that assumption is often invalid and that leads to problems. The second assumption is that as we gather more data, the ratio between our sample size and a number of significant features should decrease. So, as Ben was saying, if we have a bunch of random features that have very spurious correlations, then this assumption might not be true. But if we're truly learning causal relationships, then as we gather more high quality data, more correct data, those causal relationships should become more apparent and more clear.

And then the final assumption sort of is we have to assume is that we have a model that can explain the relationship between our features and our and you can't do that, then that's a problem. But often we just have to assume that. So what the paper basically said is one and two are not valid, and then. Three we just assume because we have to, yeah, and assumption that assumption particularly, I mean the first assumption.

That is, as they cited in the second half of the paper in their coffee shop transcription, which is really amazing, the big lie of mL is IID and that holds true just as you said with the trained test split. But it all I think it holds even more true when we're talking about utilizing an mL model on data that's never it's never been seen. So when we're doing daily scheduled predictions, there's no guarantee unless you're looking at a fixed, closed system that you find everything about it, and then you've really pared down your feature set to things that are observable.

You're you're looking at machinery operating and you're you're measuring the vibration analysis and the RPM and it's a fixed set of look at the entire environment of that of all the latent factors that are associated with that so even in those cases, you're you're still not guaranteed ID over time, even though we all say that yeah it is. It's we're taking sample from the population of training at this time. That's what we're using, and then we're predicting in real time or in back over the next and number of weeks and months and years.

It's going to be the same distribution. Well generally not things change, Entropy happens, and things fall apart, and that's true of pretty much any model. Your third point, the assumption that actually it's prediction. Yeah, those are really good points.

You sort of hinted at one thing that I wanted to highlight, which is causal learning isn't always the best option. Maybe could you give some examples of data generating environments where straight up optimization might be the best option. Oh, that's a good one, and I. Think you hinted at it.

It's a knowledge of the data generation mechanism and knowledge of future data generating mechanisms. So if it's a physics based system or a machine, we might be able to assume that prior data will look exactly like future data. But in most product applications and most big tech applications, that might not be the case, So I was wondering if you had any ideas on that. Yeah, definitely, was just trying to think of some of the use cases I've been involved with over the last couple of years.

They're very few and far between where we can say, hey, for training and everything that we're predicting on, and we can validate this, as you said, through back testing. We look at random samples of the data over a period of years and we see, yeah, there are some variations, but the variance within each of the features being collected is it follows like over extremely long. Periods of time. Because we're tightly controlling the data that we're collecting.

It's censored data. It's measuring Newtonian properties of things. So in the respective use cases like that we're measuring equipment or properties of something, those are that data being collected is bound by an environment law, which they kind of get to in the paper as well. When we're talking about environment, if we're constraining what we're measuring and what we're predicting within the con boundaries, you have fixed limits on when you're measuring physical systems.

We're talking about measuring predicting whether a rotating piece of machinery is going to fail. We know that we're not able to measure below zero kelvin, or we're not going to have a temperature value that is going to be hotter than the core. Of the sun. So you have these constraints.

You know over time that you're going to be in this range of what is the temperature of this piece of equipment at this place on Earth, because there's a melting point to any piece of equipment, And then that environment constrains itself to the point where you can say, yeah, I have ID because in training tests hold out and prediction data sets, but an infinitesimally small subset of mL application that I've seen, and a lot of those aren't even handled with supervised learning.

They're handled with physics models. You know that relationship, you already have that causal understanding, so you just programmatically write that and say, hey, if I have these conditions, this is a problem. Otherwise, continue not sending me alarms about something. Supervised learning isn't used for some because it can be easier to implement than writing a physics model, and it can also allow you to do a lot of them in parallel without having to write a bunch of custom code for monitoring systems.

What you alluded to production use cases in industry that people are applying machine learning to, a lot of them have to deal with humans, like how is this person going to interact with my company's products? Or what is going on with this geoplin? What is the risk of this thing? And is this person trying to do something to attack my company?

All of these sorts of things have so many latent variables that you can't so isolating the data that you are collecting to getting a causal relationship is the big gain that this paper talks about. Yeah, exactly. And I think you made a really interesting point in that most physics based models use physics models, which makes a lot of sense. And for that to work it I mean, well, first of all, that's the goal of modeling is to predict the future, right, And if you have a really good understanding of the system, then you probably don't need machine modeling or machine learning, like ben or hinted at.

And in that case, you can just develop some mathematical model that creates the relationship between X and y. But for machine learning, we're looking to develop an estimate of that relationship, and so causal learning. Basically, if you can't write out a mathematical relationship between X and Y, causal learning is probably a really good option for you. If you don't have perfect understanding of the data generating mechanisms, then causal learning can improve any generalization to new data sets.

So that was basically the gist. Yeah, I couldn't agree more. And as you mentioned earlier, when you asked your colleague before of like, hey, which one's more challenging, I kind of chuckled with that because causal learning, when you're building those those sorts of models, you need to understand the problem space. You don't need to understandship.

That's the point of the modeling is to say, hey, what actually impacts what? But you have to understand the problem space to such a degree that you can actually build the relationships that you're going to be testing with empirical data. And that involves creating bags of saying if this changes, then it changes this, and this has a relationship here and these don't have a really relationship, And you have to design all of that and then run a bunch of experiments saying, hey, start varying things for me and selecting vectors of data and tell me what the relationship is.

It's very complex, it requires domain expertise, whereas as we've been saying, you know, traditional mL, you don't need to have all of that. It helps if you do, and it's really beneficial if you work with somebody who really understands in fact you should be doing that, but you don't have to understand it to the degree that you would for causal modeling. Completely agree, and even with puzzle modeling, there's another layer of whether you need statistical significance of the causal relationships.

That's often pretty easy to add in, But just another note there. And then I also wanted to quickly before we redescend into the weeds and talk about optimizations and well, I just wanted to touch on the philosophy behind this because I think it's super, super interesting and I don't know, there's something interesting about it. So a long time ago, people studied the brain and said, hey, we have neurons. That's a cool framework.

And then in the eighties or nineties or whatever it was, neural networks were proposed as a method for solving problems with computers essentially, but back then we didn't have the infrastructure, the computing power or anything like that, and so we were unable to run large scale neural networks. But with the rise of computing, we started using neural networks for basic things and we were able to sort of approximate the brain. Causation is not a real thing. You can't go touch causation, you can't go grab causation, you can't look at causation.

Causation is a construct by the human brain, and it's made through the relationship with neurons. And so what we're looking to do is take neural networks a step further and just black boxes in general, but take them a step further and the more like the human brain. And essentially what we're looking to do is approximate what humans do. As a child, So a child sees a pan on the stove and is like, m going to touch that.

They get burnt and they say, oh, things that are on the stove are hot. Well, a year later they come back and they touch the stove, but the stove is off. Well, the stove can't be the cause of burning my finger. Maybe there's some other relationships.

So they go out and test different things and what essentially this paper is looking to do is build in that trial and error learning framework into the loss function. And what they do is they create test environments of different scenarios of touching the pan when the stove is on, touching the pan when the stove is off, and they ensure that the same cause occurs in each environment. If it doesn't, well, then it can't be a cause. It might be a strong predictor or a strong correlation, but it can't be a cause.

So I just thought that was freaking awesome, and it's cool to see how algorithms are starting to become more like humans and borrow the best parts of humans. So we'll see. That's an awesome analogy actually with traditional mL that we're looking at for that use case of touching the stove and getting burned by a hot pan, a traditional supervisor if it doesn't have all of those those combinations of when was the last time something was cooked in that pan on the stove, what is the state of the knob for the.

Burner of that stove, what type of pan is it? You know, there's a lot of data that you could collect about that, But if you don't have all of those permutations in here and you don't have enough samples testing like, hey, is it hot? Yes or no? Based on this data of the state at that moment, you run the risk of it doing what the child did at phase one is just saying pan on stove hot burn Yes, it's ease that the pan is on the stove, versus the pan is in the cupboard saying it's burning hot, even though in reality we know from our experience and our brains can understand and we can put our hand above the stove and say do I feel heat coming off of this?

So the model, if you're not careful with your training data, is going to learn a sperienced correlation that you. Don't really want it to learn. Yeah, that's where we all are, and as data science practitioners, that's where we all are. Whenever we're building a model, we're fighting against that.

Yeah, And just think about what would happen if you got all of your data about the stove from the kitchen in your house versus a kitchen in a restaurant versus a kitchen in a restaurant that is at peak hours between seven and nine pm. There, it's like the data generation is so so important. And again, what this framework looks that does to do is overcome crappy data generation mechanisms or biased sampling, because you can't have perfectly unbiased sampling almost ever. Too many we just came up with a handful of them, and there's an infinite number of latent.

Variables that could affect that. We could spend the next several hours just whiteboarding a bunch of ideas of like what other data could we collect that could explain whether a pan is too hot to touch or not. And that's the reflection of the reality of any project that you work on, is you're never going to collect all the data. It's impossible.

You're never going to have true causal understanding of a problem due to the fact that you can't collect the empirical evidence to explain a causal relationship that would be able to be accurately represented in traditional machine learning. So this approach of saying I'm going to sample things and I'm going to say holding this one element constant and I change these other things, what does that actually do to the prediction my optimization that I'm doing, and how does that impact how I should deweight this one particular feature.

And it's a brilliant approach reading through the paper times this week after you send it to me. This is so cool, and it's it's actually not too dissimilar from how mL explainability algorithms work. So like the Shap algorithm, nations is using something a somewhat similar technique where we're holding certain indexes in our feature vector invariant and synthetically varying other features to determine what is the actual importance of these factors, how much do they impact this trained model and what it's actually predicting, and saying, oh, this is the directional magnitude of this one feature, this is how it actually impacts this paper that we're talking about.

It's sort of taking that idea and saying, let's just put that into the training process. Hold elements, hold. Vector indexes invariant, change other things around it based on our sampling, and say, do we detect conditions where if we change this one thing, the model the prediction and is completely wrong. And those really big switches dramatically impacting the prediction.

Those need to be weighted very differently than the ones that are just oh there's maybe a weak correlation here. Yeah, I have a positive correlation, but it's the ones that hey, if I just switched this one thing, it completely nullifies this prediction. That's the big improvement here. My curiosity, and we talked about it before we started recording today, is what is the computational complexity of doing this where we have to build these environments and these synthetic elements.

Whether it be a convolution over a matrix or we're doing vector processing, this is a lot more iterations that we would have to do in order to determine that relationship. So it'll be really interesting if this does take off. What is the value to people in industry comparing these two things, because it's going to be added cost, but there's maybe added accuracy. So I'm curious to see what that where people's cost benefit analysis.

Will fall out on this. Yeah, yeah, that's a good I have no idea. And just another note on industry adapting to this method. This paper only covers classification and they're working on regression topics, but that was left for future work because it's apparently a lot more challenging from that meetical standpoint, and I can see why.

But yeah, right now, at least as of the date that this paper was written, they only have it for classification. I imagine this would be This would be non trivial to do for a continuous predictor, because you would have to estimate the magnitude change and how much is that deviation, and you'd have to run a whole lot more iterations in order to determine that. It's like that in the SHAT packages. That's the difference between like your tree solver versus your the tree solver.

If you're running with a tree based algorithm, I think, executes pretty quickly, even on a relatively enormous data set. And then if you if you can't support that and you have a model type that isn't tree based, you have to use like a kernel solver. Or there's also linear solvers, but they're they're restricted, and but that kernel solver is brute force. It is I have this black box that I'm throwing a vector of information at and it's going to provide a prediction.

And I'm just going to mutate a bunch of stuff and throw it at that and see what the differences are, what is between these And it takes a long time to run, like a very long time to run. It's on the order of. Like one hundred to one thousand x longer than it took to train the model in the first place, just. To be able to explain it.

Yeah, that makes sense, but goddamn yeah. Yeah, it's a pretty beefy hardware. Some of our customers at data Ricks who are needing model explainability because of legal requirements, Sometimes they don't want to or they've tried to use certain types of they're like, yeah, that's cool, we know everybody's using that, but we don't want to use it because it's not a really good fit for our use case. So but we need explainability.

And then they get down the road of like all right, we're gonna use SHAP and they're like, wow, why does this take so long? And like this costs thousands of dollars? Yep, sorry, Like we're working on it. When we figure it out, you'll be the first to know.

But it's yeah, it's it's computationally intent. So it'll be interesting to see this taking off and eventually packages being written or pre trained classifiers that Facebook can offer to the world based on these papers saying hey, here's the way to do this, and here's the algorithm, and we created a structure that supports this to know if when you need basically a one hundred GPUs and you need a cluster of them in order to run this, even for relatively simple data. Yeah, one of the companies that so we have weekly speakers, either someone internally presents an mL paper or we have someone externally come in.

And one of the people that came in was a founder of a startup that was trying to just basically sell us his product unfortunately, but it was all about model explainability. And there's so many new companies that are working on model explainability. Obviously not all of them will succeed, but it's such a hot topic right now because of a generalizability b trust. Also with the general AI discussion, everybody's like, you tell an algorithm to make a bunch of paper clips and terminator happens.

Well, if we know what's going on internally, maybe that won't happen. So I think there's there's a bunch of different reasons for why it's such a hot topic. And data breaks is I'm sure going to put out some great products, but it is also challenging. Yeah, challenging, and it's expensive to do it.

And that's right, that brings me to another meta question not met at the company, met at the concept. At what point does mL become such a commodity because of the advances and the general acceptance that people have, Like algorithms such as what we've been talking about get to a point where hey, they're really good and they're really generalizable and people trust them. We can explain them pretty well. When M becomes a commodity, Anything that becomes a commodity becomes optimized for price and what is the performance considerations or need need to come up when this becomes something that just everybody does.

So the premise is machine learning algorithms become something you can buy. At the grocery store. Basically there you can like make them really quickly and they work really. Well, maybe not quickly, just they can.

They're they're reliable enough that people trust them, and they're sort of ubiquitous throughout industry. Every company has their their suite of mL models that are running every single day. And how much is that going to cost the company for things that are just expectations and what is that load going to be on cloud providers? I see it pretty much every day.

There's allocation problems on all of the three major clouds that we have where somebody's like, hey, in case I want to do modeling that you know, we were doing this one model, but we found that if we split it up based on region and we create you know, eighteen hundred different models, they're all more accurate than that one meta model. And it's like, yeah, that's sure, you're just removing one. You're creating different ecosystems, these different environments. Basically for each of these models, you're you're eliminating a bunch of latent factors that are influencing the performance of the one meta model.

But then they're like, WHOA, We've tried to run it asynchronously. We tried to kick off a job that did training all in parallel. But because we get a cloud provider limit, like do we need to go to a new region? Like no, you need to talk to the cloud provider to get more allocation.

But what's your budget for this? They're like, WHOA, we didn't know it was going to cost that much. Like yeah, but if everybody's doing stuff like that and everybody is going down that route, how bigger data center is going to be? How much silicon of you're going to be mining and forming into wafers.

It's an interesting thought to consider where these models become more powerful, more predictive, more reliable because they don't require a team of eight statisticians and four mL engineers to build a solution that's based a bunch of statistical analysis to determine spurious correlations before you even start feature engineering work. The model can just say. Yeah, you can throw some garbage data in here, relatively garbage data, and then we're going to find these spurious correlations and reject them from the model's influential weights.

That's what by commodity. But it becomes easier, then it becomes more expensive. Yeah, and even with this method, you could argue that you should throw in more data because it will only find cause of relationships theoretic. So let's throw in ESPN data, Let's throw in Twitter's most recent feed.

Why not? And so yeah, that that's a really good point that future cloud computing demand will no doubt increase just due to scaling of industry. But as we have more robust algorithms that can handle really crappy data, there's a lot more automization in this model fitting process. So people would just throw everything at the model and see what I can output.

So yeah, arguably people are already doing that. That was the big, the big promise of xt boost when it was released. It's like, hey, it'll it'll. Autonomously reject poor correlations.

You can throw whatever you want at it. It's only going to look at the most important features. And yeah, yeah, that is true. That's how that algorithm works.

However, it's going to optimize for the greatest correlation that it has, and if you throw a bunch of junk into it, it's going to optimize pan on stove means hot. Then that's the only. Thing that's going to look at all those other features that you throw in there, it's just ignored to such a level that it's really only looking at one or two features. So that was an issue and it still continues to be an issue for that algorithm.

And then other companies have have fallen suit all xtra boosts and come big tech companies have released their own sort of versions of extreme gradient boosting. So you have light GBM, you have cat boosts. You know, these algorithms do similar things and trying to solve kind of the same sort of problem in slightly different ways. But people got the wrong message.

I think of like, shouldn't just be throwing garbage into a model and then it'll just magically do some stuff for you. But this paper could theoretically do that. It could say, hey, these things are pretty important. Instead of just saying I'm fine, and these two features that are of greatest correlation, it could be rejecting the things that have extreme correlation with your target and in favor of thirty other features that are actually less correlated but they have a better chip to that predictor, And you could get away with throwing in just tons of data, like, hey, I'm gonna throw a thousand features into this thing and ten million rows of data, and it probably on holdout validation, it probably will be any other approach that's out there.

Yeah, Just to be also perfectly clear, this isn't a exg boost equivalent because there's a lot of design in how we create our environments and there's lots of subject matter knowledge, and that's a pretty labor intensive process. So in the cow's camel example, we knew we first of all, knew that background was going to be a meaningful feature and a potentially correlation feature and not causal feature. Second we knew a ton about what different locations have in terms of their natural landscape.

So based on being just everyday people and having subject matter knowledge about different countries and where housing camels live, we're good to go. But think about more complex examples. I don't know that it will be that easy to develop those environments, and it's tough to come up with an example off the top of my head. But it assumes a lot of a subject matter knowledge, and then be it assumes that those environments are very good examples of the sampling schema.

So again we assume it's IID. It's not ID almost ever, But then we have to say, all right, it's not ID, what is the true scambling schema. And that's a really tough question in my opinion, and personally that's other than compute power and computational complexity. I think that's one of the biggest issues with this method.

So it's not a short term it can easy fix. It's for really complex, really important models where we do know the data generation schema a little bit. Yeah, I mean definitely you have to not only understand what data is being collected and what For our image example here about cows, we would have to understand what are the potential latent factors in that environment that we would have to collect data on to explain the cause of relationships. So if we're doing picture generation instead of just data augmentation that people normally do with CNN's were like, Oh, I'm gonna flip the image, I'm going to invert it, I'm gonna you know, I'm going to mess around with the color space.

I'm going to throw gray scale versions of this in there to try to counteract. That's traditionally what you would do with the CNN to get it to generalize better and hope that it doesn't learn the things you don't want to learn, like, oh, if it's green, then must be cow in the background. But what happens when you put a cow on a boat? That's an environment that a cow is not normally in.

They don't live in the ocean. But what happens if you're transporting a bunch of cows and somebody takes a picture of it. Do you want it to detect cows? And if it was only just looking at the background, what would that classifier do?

It would have probability membership being extremely low to anything that it had seen before, and it'd probably get pretty confused. It'll give you a prediction in most frameworks, but it won't be something that you can rely on. But with the correlation and building that environment saying okay, I need I need all of these different picture environments in order to define the ability for it to disambiguate between cow and camel? Do you also superimpose pictures of cows in space on the moon?

Like? Those are the things like that's examples. But any supervisor learning that we're doing, we should be thinking about that in the applications of an algorithm like this is understanding that problem space for predicting what a customer's next action is going to be interacting with our product. What are all the different possible avenues for saying probability to churn based on how frequently we're sending push notifications to their phone?

Well, what are all those latent factors that go into that? And there's a lot so Yeah, interesting philosophical thought path Yes, all right, man, this was fun, good discussion on a really cool paper. Next week to a pretty fun group of people, it's going to be the open source MLFLOW development team. Some colleagues of mind and it'll be a panel discussion.

Michael will be grilling all of us on all the questions he wants to know about developing one of the successful open source toolkits that's ever been made. That should be a fun one, so make sure to prep your questions. Yes, sir, cool? Right, So, I'll see you next week, and also thank you everyone for tuning in.

Have a good one.