Performing Root Cause Analysis with DoWhy, a Causal Machine-Learning Library
"Much like machine learning libraries have done for prediction, DoWhy is a Python library that aims to spark causal thinking and analysis. DoWhy provides a wide variety of algorithms for effect estimation, causal structure learning, diagnosis of causal structures, root cause analysis, interventions and counterfactuals."
The field of causal machine-learning (ML) is not as well-known as typical machine-learning problems and libraries. DoWhy is one of the more popular open-source libraries for causal ML. And not for nothing: DoWhy is based on the two major scientific frameworks, Potential Outcome and Graphical Causal Models and offers a large variety of features.
Problems where causal ML can be applied, come from any imaginable domain, be that distributed computer systems, supply chain, workflow management, manufacturing, etc. As long as a complex system can be represented as a causal graph, one can also apply causal ML.
In the talk, we will specifically dive into a microservice architecture, as this is an example which an audience like the one at PyCon can most likely relate to. We will present some data and then inject outliers (or anomalies) into that data, see how those propagate through the system, and then use DoWhy's algorithms to show us the root cause.
By the end of the talk, the audience should have a good understanding of typical problem domains for causal ML and a good sense of how to use DoWhy to solve such problems.
This session took place in track Machine Learning & Stats and was classified suitable for intermediate domain / novice python by the speaker.
Transcript (auto)
Auto-generated from the recording utilizing Open-Source AI. Speaker labels (Speaker 1, Speaker 2) reflect diarization, not identity. Timestamps refer to the recording.
Speaker 1 [00:02]
Hi everyone. Yeah, thanks for the introduction. Yeah, as announced, I'm talking about root cause analysis with Dewey. Dewey is an open source library for causal inference tasks in Python, of course. And, yeah, today I want to talk about this particular set of features that we introduced there last year. So the talk has roughly four sections. First, I will talk about DeWi, what is it, what can you do with it. Then I will talk about some hypothetical examples you could solve with it. And then I will dive deeper into a particular example. So I will go through a notebook and show you step by step how you could solve a particular root cause problem. And then at the end, I want to zoom out a bit and talk about PyY. PyY is an independent ecosystem for causal learn packages on GitHub. And I hope to make some advertisement for that. So first of all, what can you do with DeWi? So DeWi was initially developed by Microsoft with the main focus on effect estimation tasks. And, yeah, in the meantime, we also developed a causal library at AWS using so-called graphical causal models, which nicely complement the feature set of DUI. And so, accordingly, we started a collaboration with Microsoft to open source our library in DUI and extend that feature set accordingly. That was roughly last year in May. And since then, DUI is also now an independent package, so it doesn't belong to Microsoft or AWS, it's independent now. And in this talk I want to mostly focus on the graphical causal model part, and what you can do with this. But before, here's a rough overview of what you can do with DUI. So on the left side you see some causal questions you have. So you see effect estimation tasks, you can do what-if analysis, you can do root cause analysis and explanations. and explanations, the main part of this talk, and what you also see is what kind of model types you need. So you need, for most of them you need a causal graph that models your causal directions, and for some other tasks you need also to model so-called causal mechanisms, which I will also introduce later. But let's first look at a typical effect estimation example. So here you see an online shop, and I guess you know which online shop I'm using here. So it's an Amazon shop where you have a product. And yeah, I guess it's a bit small here. But you see two buttons here on the right, the add to basket and the buy now button. And now the question is, what happens if we change the color of the buy now button? Would more people click on it? So basically what we want to do ultimately is we want to increase revenue by people clicking on the Buy Now button. And by the way, for people who don't know what the Buy Now button does, it skips all the checkout process and goes straight to the... You just confirm it and the article is already sent to you. And now the question is, okay, if we would change it from this kind of orange to this more red colour, would more people click on it? And ultimately the question is, would the revenue increase? What you would typically do in practice is you do an A-B testing, right? you show like 50% of customers the orange button, 50% the more red button, and in the end you compare the revenue. But that takes time. You might lose money if the button, for instance, is white. Maybe no one even sees it. So can you do that maybe statistically using something like doY? And of course that's possible. So basically all you need to do is you, so here's a small example. So you define your causal graph, which basically models the relationships you believe between your variables and your data. You define your treatment variable, in this case, button color, which you want to change. And then you can plug this in into an estimator. And here, for instance, we use EconML, which is another third-party library, which is focusing on effect estimation tasks. So this already should show you we support third party packages and heavily want to utilize that. Then you fit that estimate and you estimate your effect. And then fully data driven you can estimate the impact of changing the color without actually performing experiments in real life. Of course under strong assumptions. So that is the effect estimation part. Now the next part I want to mainly focus on is this part down here. So when you look at this graphic, you see that there are two components to this one. First, you need your causal graph, and secondly, you also need the causal mechanisms. And if you have both together, this is what we call graphical causal models, and this allows you to do a lot of fancy things. So first of all, what are graphical causal models? So, yeah, as I said, there are two parts. The first one is the graph structure where you believe, or what you believe are the causal relationships in your data, and the interpretation, I think it's fairly easy. So like this node is the parent node, for instance, of this one, and this just means this is the cause and this is the effect, and this is how you define it. And since I already know this question will come up, so this graph, you can, for instance, derive it from data if you don't know how to construct the graph in the first place. Also, it's not that robust if you do it from data. Or you can use domain knowledge. So for instance, there are many ways to actually know the relationships of certain components in your system. And the second part of this is modeling the so-called causal mechanisms. So when you look at this graph, you can model it as a causal Bayesian network. And this basically composes into, you model the joint distribution of the data here, and the nice property of Bayesian networks is you can decompose it into conditionals of a node given its parents. And here we are particularly interested in causal Bayesian networks, not just Bayesian networks. So the difference here is the causal Bayesian networks basically has one ground truth, the true causal directions, while Bayesian networks you are actually happy with anything coming from an equivalence class, so there are multiple solutions, but not all of them are causal. What we are particularly doing in DUI is we use so-called functional causal models, which you can simply think of each node can be described by a function, which takes as an input its parents and some noise. The noise is assumed to be not observed and is the most crucial part here because by having this functional form here, you can do all kinds of things like estimating point-wise counterfactuals for certain outcomes that you observe, which, for instance, are not possible if you just have a Bayesian network where the notion of noise in that form doesn't even exist. So I guess the takeaway is the goal of the graphical causal model is to model the data generation process. Okay, so when you have these graphical causal models, what can you do with it? you can do things like root cause analysis in complex systems, you can do attribution of distribution change to upstream nodes, you can quantify causal influences, so when you have these graphs you can quantify how strong are the causal connections directly but also indirectly, and you can of course do things like pointwise counterfactuals for particular observations. And for all these things, you will see some more concrete examples. So you can apply all these things with a few line of codes with Dewey. So here what we are doing is we basically just import the GCM module from Dewey. We define a so-called structural causal model here. And then the way how you define the graph is fairly simple. use, for instance, network X. I guess network X is like the biggest graph library in Python, where you just say, for instance, here X is the cause of Y, and Y is the cause of Z. And this just defines your chain, for instance. So this is already the step up here where you find the graph. And then the next step is you have to define the functional causal models here. And you can either do that manually when you have domain knowledge or you know you want to use particular models, or you can ask the Y to do this automatically. So you just say, you just use the auto module, you assign all the mechanisms, plug in your model and the data, and then use a semi-heuristic to assign these models automatically, basically the step here. And then afterwards you fit the model on the data, so under the hood it just goes over all the mechanisms, fits it, and then you're ready to use it. And as you see here, we are mostly following a functional approach. So instead of saying SCM.fit, we say fit and then put the SCM object in there. There are some reasons to it. But yeah, it probably takes too much time to explain. But I guess the message is after you fit the model, you're ready to use it. And afterwards, it will not be modified anymore. So you can always reuse the same object for different causal tasks. OK, so here's a more concrete example of what we can do. So imagine you have an on-hand inventory planning system, and that consists of many steps. So for instance, you have a demand forecast, like how will my demand be next week? You have some simulation, maybe how will be the economic situation over the next week? And this together defines your planning, then there's the bidding on your product, and all these things together then finally defines the amount of inventory you have at the end. And let's say we have the following situation. We see here on the right that in 2019, we have an online inventory about roughly 0% or above 0%. This is what we want, right? We don't want too much inventory, and we don't want too few inventory. But now suddenly in 2020, what we observe is that there is a sudden drop. So over these weeks, it dropped by 20%. And now we wonder, why did it drop? What in our planning system changed that it suddenly dropped? Why is it not accurate anymore? And you can figure this out with an easy function call from Dubai, where you just plug in your causal model, you define your target node, some other parameters, and then it gives you a contribution to all the upstream nodes, how much it contributed to this change in your data. Another example, the main example, we'll go through the notebook as well, is root cause analysis in cloud services. So here we have Amazon CloudFront. Just think of it as a front end for the users. And in the background, there's a lot of different processes happening. So there's a gateway, there's AWS Lambda function, which accesses DynamoDB and so on. And now what happens is we might observe some peak in latency in our front end. So here, for instance, OK, it's super small, but maybe you see some peaks here. And we want to explain why we have these peaks. Where do they come from? And you can imagine the DynamoDB maybe has some high latency, which causes a high latency in the lambda, which causes a high latency in the gateway, and so on. So there's a chain effect of these anomalies. And basically, automatically, one identify, OK, which of these components is responsible for this peak? And here, in particular, we're interested in the P99 latency, for instance, which is this small thing down here. And again, you can do this easily with a function called to do y. You just plug in your causal model. You specify your target node. Here, this would be the CloudFront. And you put also in the concrete sample here that you're interested in. And it gives you the attribution to all the upstream nodes here in the graph. And what you can do in addition, you can also simulate interventions. So now you identified maybe the root cause, you can ask the question, OK, what if I would reduce the latency, would this fix my issue? And you can simulate this by doing a so-called intervention and sample new latencies from a hypothetical distribution where you fixed your issue and see if that actually helped you in reducing the latency. OK, now we'll switch over to a notebook to take a look at this a bit more in detail. I hope that's OK in the back to read. OK, so the example we have here is an root cause and error example in microservices. So here we are particularly modeling the checkout process of a website. So when you go to an online store, you place an order. Then it takes some time until the order is confirmed or something went wrong and got rejected or something. And basically, what happens is as soon as you click on the button, when you click on the Place Order button, a lot of stuff happens in the background. So here's an overview of a dependency graph. So you have this website node, which is the website you are interacting with. When you click on Place Order, it acts as a web service, which acts as an API, which acts as a product service, and so on. There's a whole bunch of stuff happening in the background. And now imagine there is one anomaly happening somewhere and the user suddenly faces a high latency. Then you want to identify which of these nodes is responsible for this. By the way, this graph is artificially generated and also the data I'm using. So it's based on real architectures, of course, we saw. And also the data is tried to mimic real data. But just as a disclaimer, these are all artificial data. things here. So the first thing we would do is we load in some data. And here, for instance, we just use pandas, load in a CSV, but where the data comes from it doesn't matter as long as it's a data frame in the end. And the format is, I think, quite normal. So you have your tabular data format where the columns correspond to certain nodes in your graph. So these are just the node names. values, and each of these values here represents some latency in seconds. So like pretty normal format here, and the first thing we do when we want to model this is we take a look at the data, how does the data look like. So here's some scatter plot, and it's I guess again too small, but yeah. So here's some scatter plots, and by the way, the step is also optional, so if you don't one look at scatter plots, you don't necessarily need to do that. So what you see is on the diagonal, you see like the so-called marginal distributions of the nodes. So like if you just take a look at the data of each node individually, you would get this kind of distribution. And what you already see here is, first of all, you don't have negative latencies, which is I think quite clear. And you also see that you have these rather half normal distributions. So you have like a lot of latencies which are quite fast. And then you also have some latencies that take a bit longer. So you have like a long tail distribution here. And this is already some good information we could use later for modeling this graph. Then when you take a look at these pairwise plots, you also get some useful information. So many of these plots can be described by a simple linear function. So I guess the most obvious one is down here, the web service and the website. You see this is like a very linear function with some noise. So linear function would probably already be a good description of this, and similar for the other one as well, although it's quite large noise, of course. But you also have some more complicated things, like here the caching service and product be where like a normal linear function would not be a good fit or you probably couldn't even model this accurate at all okay so this these are already some some helpful information so now the first thing we will do is we will set up the the causal graph the causal dynamic directions and here we're using as i mentioned earlier network x and we import the gcm module and simply define the graph now one thing when we think about the causal relationships of latencies when we take a look at this late at the dependency graph then it's quite clear that a high latency for instance in the product DB would cause a high latency in the caching service and not the other way around so the caching service would need to wait for the product DB and not the product DB needs to wait for the caching service at least in this simplified setting of course there are more complicated ones therefore when you think of the causal directions we actually need to flip the edges here so the dependency graph just flip the edges and this is exactly how we define it here so the web service is cause of website and the authentication service is the cause of the web service and so on and when we do this and plot it then we get exactly the dependency graph just with the flipped flipped arrows okay so this was already the part of defining the causal causal graph now we need to define the causal mechanisms and here we We can now make use of the knowledge we got from the scatter plots. So the first thing we do is we define our causal model here as a structural causal model. Then we iterate over the nodes. And then as soon as we have a root node, we basically assign a distribution. So here in this case, we use psi pi, for instance. And in particular, we use a psi pi half normal distribution, because we saw earlier in the scatter plots, half normal distribution seems to be a good fit. And as you also see, here we use SciPy, right, so you can plug in any SciPy distribution, you don't need to be dependent on whatever DUI has implemented. Of course we have some wrapper function to make sure it works with the rest of the library, but in theory you can just plug in any SciPy distribution. And then in the else part here, this is when we don't have a root node, we need to define these functional causal models. And what we are particularly doing here is we use so-called additive noise models. The additive noise models you see here on the right is basically something like this. You have Y equals F of X plus N, and the X here are the parents. And the F here is some kind of function that can be arbitrary. And in our case, we particularly use a linear regression function. And again, here we use scikit-learn. So you can plug in any scikit-learn regression model, random forest, neural network, whatever you want. And yeah, that's all. That's all you need to do. So you defined your causal mechanisms. And now you might think, OK, I don't want to iterate over this. I don't want to think about all these models. You can alternatively also just call the auto module and ask the why to do this automatically. So you just say assign causal mechanisms, put in your model, put in the data which it should be based on, And then it will go over your data and assign these models completely automatic, so you don't have to think too much about it. But if you have some knowledge, it's probably better to do it manually. Then afterwards, you are ready to fit the models. So you just call fit. Then the model gets fitted, and then it's good to go. And the first scenario we are looking at is, so let's say you're an on-call operator, and suddenly a customer complains, hey, the checkout process takes so long. What is going on there? So what happens, what we do now is we take a look at this particular trace for the customer, which we load in here. So you see it's really just one line of a Pandas data frame with one particular set of observation for each node. And of course, the first thing we do is, is it really slower than what we normally expect from the data? And here we see, OK, indeed, it's two seconds slower than on average. OK, it's maybe not super much slower, but it's a bit slower. And now we want to identify, OK, why is it slower? Which of these parts are responsible for that? And for this, we can now use the GCM attribute anomalies function. So we just plug in our causal model. We say, OK, we're interested in the website node. And then we also specify the sample we want to analyze. So in this case, our outlier data that we just loaded. And this gives us a dictionary with all the attributions. And to make the plot or to make the interpretation be easier, we can plot it. Let me zoom in, where we now get a nice overview of all the attributions. So you see, for instance, that the caching service has a quite large attribution to the contribution to the outliers that we observed or the order service also has some slight attribution score and also the product service. On the other hand, what we also see is we have a negative attribution score here, which can be interpreted that this, in this case, the customer DB, for instance, was particularly fast. So it reduces the likelihood of having an anomaly here, which is also some valuable information. But since we're interested in root causing the anomaly, we will probably only look at the positive ones. And regarding the interpretation of these scores, it's a bit more complex. If you're interested in it, we can maybe talk about this afterwards. But just think of it the higher, the more severe. And maybe also a small spoiler alert, since we generated this data artificially, the caching services here, the true root cause. So this behaves a bit slower than usual. So what we did know is we plugged in a single observation based on our trained model. And it told us exactly how much each of the upstream nodes contributed to this anomaly, which I think is already some super good information to debug your system. OK, so now this was a single operation that we did. We trained one model. We did one run of this attribute anomaly score function. But we maybe want some confidence interval of this. So it could be that every time you fit the models, they slightly get different parameters. Also, the attribute anomalies is not deterministic. It's a stochastic function. So you might get slightly different results every time. So what you can also do is you can estimate a confidence interval, where we have a simple wrapper for that. You just say confidence interval. You also specify that you want to fit and recompute the graph every time. And then you just plug in your parameters here at this point. And you want to repeat that whole thing 10 times. And then what we get is we get this overview with the confidence bars, which are very similar to the previous one. But now you see, for instance, that this product service has bit higher uncertainty, although it's still quite small. So this is for analyzing a single anomaly event that we had. Now let's say this issue with the high latency is persistent, and we still don't know what is actually going on. So to check that a bit further, we can now say, OK, let's collect a bit more data. Let's collect 1,000 additional requests. So we load this in again. Simple pandas data frame with 1,000 rows in this case. And we're interested in the website latency. And again, the sanity check, we see, OK, indeed, this outlier data on average for the website is two seconds slower. Now what is going on? Which part of our system is actually causing this issue here? And now we can make use of the so-called distribution change method, which takes the causal model. It takes the data, how it looked when the system would behave normal, and it takes the data how the system would behave if it's not normal. So in our case, the slower data. We specify the target node we're interested in. It's the website. And then we can also say the quantity we want to attribute. So here we are interested in the difference of the means. So we can simply define the C as the difference between the two means. But if you, for instance, are interested in the difference of the variance, like you experience higher variance in your latencies, then you just change this to var. And then you would do the attribution with respect to the variance. So after this, you get, again, a dictionary with all your attributions. And when you plot this, now you get a very clear picture that the caching service here is indeed the one that is actually causing your issue in this case. And you also see that there are some super small attributions for the other nodes, which in this case is, for instance, just some noise from the approximations. And to get rid of this, you can, again, do a confidence interval where you run it 10 times in total, and then you see these small contributions go away. So now what we know is we collected more data, we plugged it in the distribution change method, and it pinpointed us exactly to the service that caused this issue. And when you take a look at this graph, this is not obvious at all. So here is the caching service, which cause this high latency in the website, and all we need to do is collect the data, throw it in, and we already know, OK, it's a caching service. Let's try to fix it. And the last scenario I want to get at is simulating the simulation of interventions. So let's say we know it's a caching service. That is the issue. But we maybe are not able to directly fix it. But maybe what we can do is we can mitigate the high latency in the meantime. And what we can do here, for instance, is we can shift some computing services from the shipping cost service over to the caching service. But this comes with some costs. So by moving these compute resources over, we basically make the shipping cost service slower, but we would speed up the caching service. Now the question is, does it actually help us if we would do this? And in this particular example, we assume that by removing computing resources from the shipping cost service, we make the shipping cost service two seconds slower, but speed up the caching service by one second. So again, two seconds slower shipping cost service, one second faster caching service, does it actually help us? And we can simulate this now. So we would fit our model on the outlier data, and then we perform and we get some so-called interventional samples here. And here, we basically simply specify, OK, the caching service is now one second slower, and the shipping cost service is one second faster, and the shipping cost service is two seconds slower. So we add two seconds to the shipping cost server and remove one second from the caching service. Now, how would the overall latency of our website look like? And when we plot this here and compare it, we see that before, the latency were roughly 5.5 seconds. And afterwards, it's 4.5 seconds. So we, overall, were able to reduce the latency by one second. And we simulated this completely based on the data. We didn't do this in practice yet, at least. But now we know, OK, if we would do it, we would reduce the latency. So we can go ahead and do this until we mitigate the issue. OK, so this was the example I wanted to show you. Now, at the end, I want to briefly zoom out. and talk about PyY. So PyY is an open source ecosystem for machine learning libraries. It's an independent organization. It's a GitHub organization. You can also go to the pyy.org website. The mission statement, maybe I won't read it out, but the mission statement basically says that we try to have a collection of open source causal inference libraries that are interoperable, are practical for users, and also improve the state of the art for causal inference. We just founded it last year, around May, so it's still in a very rough shape. There are a few libraries, but the interoperable part is not there yet, at least. Here's a rough overview of different projects that we have in there. So we have DUI, the largest package. We have Do Discover and Causal Learn, which are focusing on causal inference based on data, for instance. We have also EconML. EconML is for effect estimation. And you see these are all people from different places, Microsoft, postdocs from universities, and so on. And also recently, we have a new package started called PyYStats, where we focus on a bunch of statistical methods that you might not find in SciPy or stats models, like condition independence tests that are a bit more state of the art, or stuff like Kyle divergence estimations for continuous data, which are also not in SciPy, for instance. And of course, that could be your project. If you work on anything related to causal inference, you might consider to add your project there. Or if it's like a single algorithm where you think, OK, it doesn't need a whole package, then maybe one of these other ones might be a good fit for it. So yeah, join our community. There's the website, the documentation of why you can find here. This is the GitHub organization and the Discord. I don't think you will type in the Discord link, But if you Google it, you will find it. Every Monday, we have a public meeting where you can just join, listen in. You can ask questions. Or if you have a concrete problem, just bring it up. We're always there to help. Yeah, that's all then.
Speaker 2 [31:52]
Thank you very much, Patrick. It's time for some Q&A. We have quite many questions on the Slido, so I start from them. And I also encourage you to vote on them if you find it interesting, and then maybe we can have some questions from the audience if there are any. So the first question is, how does auto-assignment in causal relationships work?
Speaker 1 [32:14]
yeah so the currently we it's a bit more heuristic so when we take a look at at this graph for instance what we do is we first of all have like a default model for all the for all the root nodes so the root nodes the best or like like a good good good choice of distribution if you is if you just take like the empirical distribution so you would just take the data itself and use this as your distribution and for the child nodes we typically assume they follow so-called additive noise models which means this this functional form here is basically just F of the parents plus noise and the F if this assumption holds you can find by for instance taking a regression model that minimizes the mean squared error so it's like a classic typical machine learning problem and and by this we just iterate over all the nodes and for each node we try to take the optimal regression model to describe the node.
Speaker 2 [33:13]
I hope that whoever asked the question got the answer. There's a quick question about the availability of the notebook. Is there, or will it be shared?
Speaker 1 [33:23]
Yeah, the notebook is, you can find a modified version of the notebook on the documentation website, so I just modified it a bit for the talk, but otherwise you can find this also on the documentation.
Speaker 2 [33:37]
I think documentation is linked in your, like,
Speaker 1 [33:39]
I like talk to people.
Speaker 2 [33:40]
talk description
Speaker 1 [33:41]
description. Yeah. Right.
Speaker 2 [33:44]
So there's another question about what kind of input data is supported, numerical, categorical, temporal.
Speaker 1 [33:52]
So the currently supported is your continuous and categorical data. So, yeah, there are some tricks to also support time series data. Okay, it's not here. So you could, for instance, so generally we assume that it's IAD, so we don't allow temporal connections. But what you could do is you could introduce artificial lag variables and put this into your graph to at least have some workaround for now. But time series support is definitely one of the most important features that we hopefully can add in the future, but it's not there yet.
Speaker 2 [34:33]
Another popular question is which readings would you recommend to like catch up with main knowledge assumptions and to know which model to use how to interpret it?
Speaker 1 [34:45]
guess general for causality okay so that this talk was heavily focused on so called graphical causal models which is like from pearls framework I don't know who's familiar with it but they are like like two two frameworks potential outcome and and graphical causal models for graphical causal models I guess books like book of why from pearl there's another book which is a bit more modern elements of causal inference which we should be more based on the work we are doing yeah I guess these these two books and for the model selection part I don't think there's a proper literature it's just yeah it's also not not that well developed yet in the in the literature as well
Speaker 2 [35:33]
there's another question and basically causal inference is not discipline so why was pi y only founded last year
Speaker 1 [35:43]
Yeah, that's a good question. I mean, the reason why we founded it last year is because we open sourced our library and at the same time when we talked with Microsoft we thought it's a good chance to maybe go beyond just that one Dubai library and have a whole ecosystem of it because there's nothing like this in the causal inference space yet. There are a lot of separate packages here and there, but nothing that tries to combine everything. So at least that's the reason why we only did it last year, but I don't know why no one did it before.
Speaker 2 [36:22]
I may also mention that I have my own answer to that question and yeah, which you can hear tomorrow in the talk. And I'm saying that's because the Slido got broken, so I need to wait for it to load. Okay, there's another question. So can this kind of causal inference be used interchangeably for explainability of predictions or forecasting models.
Speaker 1 [36:55]
What chain? Okay, I guess you cannot ask contact questions. Okay, so I the way I'll interpret the question is so You can use it for explainability definitely so when you when you look at okay, the main point between or the main difference between let's say you use a Regression model and you just use Shapley values or something to have like a typical way of explainability then in regression tasks or in prediction tasks you don't care about the causal structure you just throw in all your variables, you define your target and you want to have good accurate predictions and then you want to explain the model with respect to that but these explanations are not necessarily causal so when you think of this graph here for instance for this red node up here, the best prediction model would take this node here would take this node basically the so-called Markov blanket So you would take all these nodes, which are the best nodes to predict this one. But you would also get some contribution, for instance, of this node here, which is, strictly speaking, independent of this node. So if you are interested in causal explanations, you definitely need to model these causal graphs carefully and use the underlying models to explain it. and what you can also do is you can so this attribution analysis here for instance or the anomaly detection that you saw earlier is some kind of an explanation because it analyzes what would happen in a hypothetical world where this anomaly did not happen so if your dynamoDB for instance has an anomaly you would ask a counterfactual question if it would not have an anomaly would I still observe this high latency and by this you also have some kind of explanation in the causal graph of certain nodes.
Speaker 2 [38:47]
There are some more questions, but maybe there's somebody want to ask here
Speaker 3 [38:52]
Yeah. Thank you for your presentation. So I have two questions. The first one, so about the session points. So what is the main, let's say difference between this framework and a sharp ratio because I can do the same sharp, sharp, sharp, so I can do, let's say approximately the same in terms of outcome you have or using sharp library so I can build the model and just analyze as outcome for each feature. And the second question, so I got about the model selection, but is it a way to after build this causal graph or do I need to satisfy? I mean, uh, create it manually and if there is was a way to build it automatically, how just short story how do we do it thanks
Speaker 1 [39:48]
sense. Okay, so the first one regarding, you mean Shep, right? Yeah. So this is a point I mentioned earlier. So you can use Shep, for instance, to describe each model individually here, but it doesn't make sense if you, I mean, Shep is just focusing on explaining whatever model you trained there. And this model that you put in there doesn't necessarily need to be causal. But if it's causal, then it could make sense to use SHEP there as well. So, for instance, if you just use a model that uses these two nodes to predict your red node here, then it's a causal model. And then if you use SHEP, then you get also a good causal explanation for your target values. But if you just care about predictions, you might would also include this yellow node here. And then the SHEP explanation would not make sense with respect to the causal explanation. think of it, if you would change the yellow node here, it would not impact your parent node. The causal direction only goes in the other way. So whatever statements you get from Shep there would not make sense with respect to the causal directions. And the second thing was, was it about building this graph in the first place? Yeah. Yeah, this is, of course, the hardest problem. And so there are ways to infer this from data using, for instance, independence tests. So for instance, you know that these two nodes have to be statistically independent. So you know there's no connection. You know that this node needs to be dependent with its parents. And these two nodes become conditionally dependent if you condition on this. So OK, long story short, there are some statistical methods to also infer this graph. And this is one way how you could do it. But at least in practice, they don't work that well. So it's better if you have domain knowledge that builds this for you. Yeah, thank you for your talk, first of all. I have one question. Can you interface this already with libraries like Torch or the deep learning stuff, so to say? Yeah, so we try to have it very modular. So the, let me switch over here. So, we have some certain interface that needs to be fulfilled. So, for instance, if you use an additive noise model, then you have your typical scikit-learn interface. You have a fit and predict method, and you could implement a deep neural network, whatever fancy structure you have there that just implements fit and predict, and then you can just plug it in as possible. And, of course, everything that scikit-learn supports is already possible out of the box. And we also have some experimental features where we replace that whole thing with a stable diffusion model, which is a bit more modern way of modeling stuff. So yeah. Okay. Thank you. It's modular. You can plug it in, yeah.
Speaker 2 [42:59]
One more question.
Speaker 1 [43:01]
Yeah, thanks for the talk. How much data do you need to actually build a useful graph? Yeah, I mean, that's... Like order of magnitude. Yeah, I mean, the classical machine learning question, how much data you need, I guess it depends. So if you have, like, in this case, for instance, we know it's very nicely linear, right? So a few data points, like 20, 30, is probably enough to learn a linear model. but as soon as it becomes more complex you need more data and in particular, here in this case we not only have the regression problem, we also have the problem of modeling the causal mechanisms which means we also have this noise part in here so you need actually a bit more data than you would need in typical regression tasks to also have a good approximation of this noise but yeah, I would say roughly the same as if you have any kind of regression problem, same amount of data. Although here you have multiple regression problems, for each node there's a separate one. So yeah, I cannot give, I guess, a good amount there, but I would say 50 when it's linear, and probably 1,000 if it's nonlinear. Thanks.
Speaker 2 [44:20]
I think we should wrap up now, unless there's somebody who would like to ask a question now. So thank you very much, Patrick. Please give another round of applause to our speaker. Thank you.