Andrew Ng walks through a performance audit before deploying ML models: brainstorm failure modes (accuracy gaps across demographics, rare classes, error types), define metrics, evaluate on data slices, and use tools like TensorFlow Model Analysis. A speech-recognition system might fail on gender, ethnicity, accent, or device differences, or mistranscribe words like "gun" vs "GAN".
Chapters
Even when your learning algorithm is doing well on accuracy or F1 score or some appropriate metric, it's often worth one last performance audit before you push it to production. And this can sometimes save you from significant post deployment problems. Let's take a look. You've seen this diagram before. After you've gone around this loop multiple times to develop a good learning algorithm is worthwhile auditing its performance one last time. Here's a framework for how you can double check your system for accuracy, for fairness of bias, and for other possible problems. Step one is brainstorm the different ways the system might go wrong. For example, does the algorithm perform sufficiently well on different subsets of the data, such as individuals of a certain ethnicity or individuals of different genders? Or does the algorithm make certain errors such as false positives or false negatives, which you might worry about in skewed data sets? Or how does it perform on certain rare and important classes? So the types of issues we talked about in the Key Challenges video earlier this week include any of them that concern you. You might include them in this list of brainstormed ways that the system might go wrong. For all the ways that you're worried about the system going wrong, you might then establish metrics to assess the performance of your algorithm against these issues. One very common design pattern you see is that you often be evaluating performance on slices of the data. So rather than evaluating performance on your entire dev set, you may be taking out all of the individuals of a certain ethnicity or all the individuals of a certain gender, or all of the examples where there is a scratch defect on the smartphone. But to take a subset of the data, also called a slice of the data, to analyze performance on those slices in order to check a single against these things that may be problems after establishing appropriate metrics. MLOps tools can also help trigger an automatic evaluation for each model to audit its performance. For instance, TensorFlow has a package for TensorFlow model analysis or TFMA that computes detailed metrics on new machine learning models on different slices of data. You learn more about this tool in the next course and as part of this process I would also advise you to get buy in from the business or the product owner that these are the most appropriate set of problems to worry about and a reasonable set of metrics to assess against these possible problems. And if you do find a problem then then it is great that you discovered this problem before pushing your system to production and you can then go back to update the system to address it before deploying a system that may cause Problems downstream. Let's walk through this framework with an example. I'm going to use speech recognition again. If you built a speech recognition system, you might then brainstorm the ways the system might go wrong. So one thing I've looked at before for systems I worked on was accuracy on different genders and different ethnicities. For example, a speech system that does poorly on certain genders may be problematic or also ethnicities. One type of analysis I've done before is to carry out analysis of our accuracy depending on the perceived accent of the speaker, because we want to understand if the speech system's performance was a huge function of the accent of the speaker. Or you might worry about the accuracy on different devices because different devices may have different microphones. And so if you do much worse on one brand of cell phone so that if there is a problem you can proactively fix it. Or finally, this might not be an example you would have thought of, but prevalence of root mistranscriptions. Here's one example of something that actually happens somet to some of DeepLearning AI's causes. One of our instructors, Lawrence Moroney, was talking about GANS generative adversarial networks. But because the transcription system was mistranscribing Gans because this unfortunately is not a common word in English language. And so the subtitles had a lot of references to gun and gang, which were mistranscriptions of what the instructor actually said, which is gang. So it made it look like there was a lot of gun violence in that deeplearning AI course and we actually had to go in to fix it because we didn't want that much gun gang violence in the subtitles. It turns out more generally that mistranscribing someone's speech into a rude word or a swear word that's perceived much more negatively than a more neutral mistranscription. And so I've built speech systems as well where we pay special attention to avoiding mistranscriptions that resulted in the speech system thinking someone said a swear word when maybe they didn't actually say that swear word. Based on this list of brainstorm ways that a speech system might go wrong, you can then establish metrics to assess performance against these issues on the appropriate slices of data. For example, you can measure the mean accuracy of the speech system for different genders and for different accents represented in the dataset and also check for accuracy on different devices and check for offensive or rude words in the output. I find that the ways a system might go wrong turns out to be very problem dependent. Different industries, different tasks will have very different standards. And in fact today our standards in AI for what to consider an unacceptable level of bias or what is fair and what is not fair. Those standards are still continuing to evolve in AI and in many specific industries. So I would advise you to do a search for your industry to see what is acceptable and to keep current with standards of fairness and all of our growing awareness for how to make our systems more fair and less biased. One last tip. I find that rather than just one person trying to brainstorm what could go wrong for high stakes applications, if you can have a team or sometimes even external advisors help you brainstorm things that you want to watch out for, that can reduce the risk of you or your team being caught later by something that you hadn't thought of. I know that standards are still evolving from what we consider fair and sufficiently unbiased in many industries, but this is one of the topics that I think it'd be good for us to get ahead of and to proactively try to identify, measure gains and solve problems, rather than deploy a system to be surprised much later by some unexpected consequences. So that's it for performance auditing. With this, I hope you have higher confidence in your learning algorithm when you go out to push it to production.
