CS231n Winter 2016: Lecture 15: Invited Talk by Jeff Dean

I'd like to point out that what I'll be presenting today is partly my work in collaboration with others, and sometimes I'm presenting work done by people in my group that I wasn't really involved in, but it's joint work with many, many people. You'll see lots of names throughout the talk, so take that with a grain of salt. So what I'm going to tell you about is kind of how Google got to where it is today in terms of using deep learning in a lot of different places. The project that I'm involved in actually Started in 2011 when Andrej Karpathy was spending one day a week at Google. And I happened to bump into him in the micro kitchen. And I said, oh, what are you doing? And he's like, I don't know, but I haven't figured it out yet, but big neural nets are interesting. I'm like, oh, that's cool. And it turns out I'd done an undergrad thesis on parallel training of neural nets ages ago. I won't even tell you how long ago, back in the first exciting period of neural nets. And I always kind of really liked the computational model they provided. But at that time, it was a little too early. We didn't have big enough data sets. We didn't have enough computation to really make them sing. And Andrew kind of said, oh, well, it'd be interesting to train big nets. So I'm like, OK, that sounds fun. So we kind of collaboratively started the Brain Project to push the size and scale of neural nets that we could train. And in particular, we were really interested in using big data sets and large amounts of computation to tackle perception problems and language problems. Andrej then went off and founded Coursera and kind of drifted away from Google. But since then, we've been doing a lot of interesting work in both kind of research areas in a lot of different domains. One of the nice things about neural nets is they're incredibly applicable to many, many different kinds of problems, as I'm sure you've seen in this class. And we've also deployed production systems using neural nets in a pretty wide variety of different products. So I'll kind of give you a sampling of some of the research, some of the production aspects, some of the systems that we have built underneath the covers, including kind of some of the implementation stuff that we do in TensorFlow to make these kinds of models run fast. And I'll focus on neural nets, but a lot of the techniques are more applicable than just neural nets. TensorFlow, you can train lots of different kinds of reinforcement algorithms or other kinds of machine learning models than just neural nets. OK, can everyone hear me? Excellent. Someone in the back gave a thumbs up, so. One of the things I really like about the team we've put together is that we have a really broad mix of different kinds of expertise. So we have people who are really experts at machine learning research, people like Geoffrey Hinton, other people like that. We have large-scale distributed systems builders. I kind of consider myself in that— more in that mold. And then we have people kind of with a mix of those skills. And often some of the projects we work on, you collectively put together people with these different kinds of expertise, and collectively you do something that none of you could do individually because often you need both kind of large-scale systems thinking and sort of clever machine learning ideas. So that's always fun. And you often kind of pick up and learn new things from other people, which is great. So rough outline— actually, this is from an old deck. So you can kind of see the progress of how Google has been applying deep learning across lots of different areas. Well, this is sort of when we started the project. And we started collaborating with the speech team a bit and started doing it with some kind of early computer vision kinds of problems. And as we had success in some of those domains, other teams at Google would say, hey, I have a problem too. And they would come to us, or we would go to them and say, hey, we think this could help with your particular problem. And over time, we've kind of gradually— or not so gradually— expanded the set of teams and areas that we've been applying these kinds of problems to. And you see the breadth of different kinds of areas. It's not like it's only computer vision problems. So that's kind of nice. We're continuing to grow, which is good. And part of the reason for that broad spectrum of things is that you can really think of neural nets as these nice, really universal systems that you can put lots of different kinds of inputs into. You can get lots of different kinds of outputs out of them with slight differences in the model you try. But in general— The same fundamental techniques work pretty well across all these different domains. And it gives state-of-the-art results, as I'm sure you've heard about in this class, in lots of different areas. Pretty much any computer vision problem, any speech problem these days, starting to be more the case in lots of language understanding areas. Lots of other areas of science, like drug discovery, are starting to have interesting neural net models that are better than alternatives. Yeah. I like them. They're good. Along the way, we've kind of built two different generations of our underlying system software for training and deploying neural nets. The first was called Disbelief. We published a paper about that in NIPS 2012. It had the advantage that it was really scalable, like the first— One of the first uses we put to it was doing some unsupervised training I'll tell you about in a minute, which used 16,000 cores to train a big neural net with a lot of parameters. It was good for production use, but it wasn't super flexible for research. It was kind of hard to express kind of weirder, more esoteric kinds of models. Reinforcement learning algorithms would be hard to express in it. It had this kind of much more layer-driven approach with up and down messages. And it worked well for what it did. But we kind of took a step back about a year and a little bit ago and started building our second-generation system, TensorFlow, which is based on what we learned with the first generation and what we learned from looking at other available open-source packages. And we think it's retained a lot of the good features of Disbelief but also made it pretty flexible for a wide variety of research uses. We've open-sourced it, which I gather you heard about. [Speaker:ANDREJ KARPATHY] So one of the really nice properties of neural nets— I grabbed this from a particular paper because it had graphs on both scaling the size of training data and how accuracy increases, and also scaling the size of the neural net and how accuracy increases. The exact details aren't important. You can find these kinds of trends in hundreds of papers. But one of the really nice properties is if you have more data and you can make your model bigger, generally, scaling both of those things is even better than scaling just one of them. You need a really big model in order to capture kind of the more subtle trends that appear in larger and larger data sets. Any neural net will capture kind of obvious trends or obvious kinds of patterns, but the more subtle ones are ones where you need a bigger model to capture kind of that extra sous-sens of subtlety. And that requires a lot more computation. So we focus a lot on— scaling the computation we need and being able to train big models on big data sets. Right. OK, so one of the first things we did in this project was we said, oh, unsupervised learning is going to be really important. And we had a big focus on that initially. Kwok Lee and others said, what would happen if we did unsupervised learning on random YouTube frames? So the idea is we're going to take 10 million random YouTube frames. Single frames from a bunch of random videos. And we're going to essentially train an autoencoder. Everyone knows what an autoencoder is? Yeah. So this is like a fancy multi-level autoencoder. In this one, we're just trying to reconstruct the image. In that one, we're trying to reconstruct the representation here from the representation there and so on. And we used 16,000 cores. We didn't have GPUs in the data center at the time, so we compensated with, like, throwing more CPUs at it. And we used async SGD, which I'll talk about in a minute, for optimization. It actually had a lot of parameters because it was not convolutional. This was prior to convolutions being all the rage. So we said, well, we'll have local receptive fields, but they won't be convolutional. And we'll learn separate representations for this part of the image and this part of the image, which is kind of an interesting twist. I think it'd be actually an interesting experiment to redo this work but with convolutional parameter sharing. That would be kind of cool. In any case, the representation we learned at the top after 9 layers of these non-convolutional local receptive fields had 60,000 neurons at the top level. And one of the things we thought might happen is it would learn kind of high-level feature detectors. So in particular, you're putting in pixels, but could it learn high-level concepts? So we had a data set that was half faces and half not faces. and we looked around for neurons that were good selectors of whether or not the test image contained a face. And we found several such neurons. The best one, those are some of the sample images that cause that neuron to get the most excited. And then if you look around for what stimulus will cause that neuron to get the most excited, there's creepy face guy. [LAUGHTER] And so that's kind of interesting. Like, we had no labels in the image in the data set at all that we were training. And a neuron in this model has picked up on the fact that faces are things— I'm going to get excited when I see kind of a Caucasian face from head-on. It's YouTube, so we also have a cat neuron. We had a data set that was half cats and half not cats. And this is average Tabby, I call him. And then you can take that unsupervised model and start a supervised training task. So in particular, at this time, we were training on the ImageNet 20,000-class task, which is not the one that most ImageNet results are reported on. That one's 1,000 classes. So this is trying to distinguish an image from one of 20,000 classes. A much harder task. And when we trained and then looked around at what kinds of images caused different top-level neurons to get excited, you see that they're picking up on very high-level concepts, yellow flowers only, or waterfowl, pizzas. I like pizza. And this pre-training actually increased the state-of-the-art accuracy on that particular task a fair amount at that time. Then we kind of lost our excitement about unsupervised learning because supervised learning works so darn well. And so we started working with a speech team who, at the time, had a non-neural net-based acoustic model. So you're essentially trying to go from a small segment of audio data, like 150 milliseconds, and you're trying to predict what sound is being uttered in the middle 10 milliseconds. And so we just decided to try an 8-layer fully connected neural net, and then predict 1 of 14,000 triphones at the top. And that worked phenomenally well. Basically, you could train it pretty quickly, and it gave a huge reduction in word error rate. Like, this is— one of the people on the speech team said that's like the biggest single improvement they've seen in their 20 years in speech research. And that launched— as part of the Android voice search system in 2012, I think. So one of the things we often do is find that we have a lot of data for some tasks but not very many— very much data for other tasks. And so for that, we often deploy systems that make use of multitask and transfer learning in various ways. So let's look at an example where we use this in speech. So obviously with English, we have a lot of data, and we get a really nice low word error rate. Lower is better. For Portuguese, on the other hand, at that time, we didn't have that much training data. We had 100 hours of Portuguese data, and so the word error rate is a lot worse, which is bad. So one of the first and most simple things you can do, which is kind of what you do when you take a model that's been pre-trained on ImageNet and apply it to some other problem where you don't have as much data, is you just start training with those weights rather than totally random weights. And that actually improves your word error rate for Portuguese a bit because there's enough similarities in the kinds of features you want for speech in general regardless of language. A more complicated thing you can do is actually jointly train models that share a bunch of parameters across all languages, or in this case all European languages. Languages, I think, is what we used. And so there you see we're jointly training on this data. And we actually got a pretty significant improvement even over the just copying the data to the Portuguese model. But surprisingly, we actually got a small improvement in English. Because in total, across all the other languages, we actually almost doubled the amount of training data we were able to use in this model compared to just English alone. So basically languages without much data at all improved a lot. Languages with a lot of data improved even a little bit. And then we had a language-specific top layer. We did a little bit of fiddling to figure out, does it make sense to have two language-specific top layers or one? Sadly, these are the kinds of human-guided choices you make in Golets. The production speech models have evolved a lot from those fairly simple feedforward models. They use now LSTMs to deal with time dimension. They use convolutions to make them invariant to different frequencies. So there was a paper published here. You don't necessarily need to understand all the details, but there's a lot of more complexity in the kinds of model. And it's using much more sophisticated recurrent models and convolutional models. A recent trend has been that you can use LSTMs completely end-to-end. So rather than having an acoustic model and then a language model that kind of takes the output of the acoustic model and then is trained somewhat separately, you can go directly from audio waveforms to producing transcripts a character at a time. And I think that's going to be a really big trend, both in speech and more generally in a lot of computing systems. You often have— today, a lot of systems are kind of composed of a bunch of subsystems, each perhaps with some machine-learned pieces and some kind of hand-coded pieces. And then usually a big pile of gooey code to glue it all together. And often all those separately developed pieces have impediments to optimization, right? Like you optimize your subsystem in the context of some metric, but that metric might not be the right thing for the final task you care about, which might be transcribing speech correctly. So having a much bigger— single system, like a single neural net that goes directly from audio waveform all the way to the end objective you care about, transcription, and that you can then optimize end-to-end through, and there's not sort of a lot of handwritten code in the middle of that is going to be a big trend. I think you'll see that here. You'll see that in machine translation, lots of other kinds of domains. So this class is all about convolutions. So we have tons of vision problems that we've been using various kinds of convolutional models for. The big excitement around convolutional neural nets— well, first it started with Yann LeCun's check-reading convolutional net. And then it kind of subsided for a while. And then Alex Kruszewski, Ilya Sutskever, and Geoffrey Hinton's paper in 2012, which blew the other competitors out of the water in the ImageNet 2012 challenge using a neural net, I think, put those things on everyone's map again as saying, wow, we really should be using these things for vision because they work really well. And the next year, there were something like 20 of the entries or something used neural nets, whereas previously it was just Alex. We've had a bunch of people at Google looking at various kinds of architectures for doing better and better ImageNet classification. So the Inception architecture has this complicated module of different size convolutions that are all concatenated together. And then you replicate those modules a bunch of times, and you end up with a very deep neural net that turns out to be quite good at recognition. There's been some slight additions to that and slight changes to make it even more accurate. Have you seen a slide like that in— Actually, I think we had a slide like this Inception v4 already. OK, yeah, so I was lazy and only took my slides from an older thing. Have you told the story about Andrej sitting down and hand labeling images? I think a little bit. OK, so anyway, Andrej decided since he was helping to administer the ImageNet contest, he would sit down and subject himself to 100 hours of training with a training test split. And like, is that an Australian shepherd dog? I don't know. And he also, I think, convinced one of his lab mates to do it, but they weren't as diligent. So he did about 120 hours of training on images. And his poor lab mate got tired after 12 hours or something. So he got 5.1% error, and the lab mate got, I think, 12% error. [Speaker:ANDREJ KARPATHY] Yeah, so a funny story about that. We originally tried to do an ensemble of our entire lab and had a group meeting where we all just tried to say sit down and evaluate human test error on ImageNet, but without training, we did really, really poorly. That's why Andrej Karpathy got fed up with how bad we all did and went home for the weekend and came back and was really good at ImageNet. Yeah, yeah. 112 hours later or whatever. Anyway, he has a great blog post about it. I encourage you to check it out. He has a lot of parameters though. Typical humans are like 80 trillion connections. I'm going to give him 100 One point about these models is that models with a small number of parameters fit well on mobile devices. So Andrej doesn't fit well on a mobile phone, but the general trend other than Andrej is smaller numbers of parameters compared to AlexNet. Mostly AlexNet had these two giant fully connected layers at the top— not that giant, but a lot of parameters. And later work just kind of did away with those. For the most part. And so they've used a smaller number of parameters but more floating point operations because they reuse convolutional parameters more, which is good for fitting them on phones. We released as part of the TensorFlow update a pretrained Inception model that you can use. There's a nice tutorial about it. There's Grace Hopper, although we think it's military uniform, which is Not terribly inaccurate. One of the nice things about these models is they're really good at doing very fine-grained classifications. I think one of the things that is in Andrej Karpathy's blog is that the computer models are actually much, much better than people at distinguishing exact breeds of dogs. But humans are better at often picking out a small— if the label is ping pong ball and it's like a giant scene of people playing ping pong, humans are better at that because the models tend to focus on things with more pixels. If you train models with the right kinds of data, it'll generalize well. These scenes look nothing alike, but they actually will both get labeled as meal if your training data is represented well. They make kind of sensible errors, which is kind of nice. It's not a snake, but you understand why it might have said that. And I know it's not a dog, but I actually had to think carefully if the front animal there is a donkey or a goat. I'm still not entirely sure. Any votes? Yeah, right. It's hard. So one of the production uses we've put these kinds of models to is Google Photo Search. So we launched Google Photo product, and you can search the photos that you've uploaded without tagging them at all. You just type ocean, and all of a sudden, all of your Ocean photos show up. So for example, this user posted publicly, hey, I— and they posted a screenshot. Hey, I didn't tag these, and I typed statue, and they just showed up. Or see, drawing Yoda. This is a tough Yoda, because it's got a lot of texture compared to most Yodas. So we're pretty pleased to retrieve macramé Yodas. We have a lot of other kinds of more specific visual tasks. Like essentially, one of the things we want to do in our Street View imagery— so we have these cars that drive around the world and take pictures of all the roads and street scenes. And then we want to be able to read all the text that we find. So first you have to find the text. And well, one of the first things you want to do is find all the addresses and then help improve the maps. And once you do that, you want to read all the other text. So you can see that we have a model that does a pretty good job of predicting at a pixel level which pixels contain text or not. And it does pretty well in that— well, first of all, it finds lots of text. And the training data had different kinds of character sets represented, so it has no problem recognizing Chinese characters, English characters, or Roman Latin characters. It does pretty well with different colors of text and different fonts and sizes. And some of them are very close to the camera. Some are very far away. And it does just fine. And this is data from just human-labeled drawn polygons around pieces of text. And then they transcribed it. And then we have an OCR model that we also trained. We've been kind of gradually releasing other kinds of products. So we just launched Cloud Vision set of APIs. You can do lots of things like label images. This is meant for people who don't necessarily want or have machine learning expertise. They just kind of want to do cool stuff with images. You want to be able to say, oh, that's a running scene. You want to do the OCR and find text in any image that you upload. So you just basically give it an image and say, I'd like to run OCR and label generation on this image. And off it goes. So people have been pretty happy with that. Internally, people have been thinking of more creative uses of how to use computer vision. So essentially now that computer vision sort of really actually works compared to 5 years ago, this is something that our Geo team that processes satellite imagery put together and released, which is basically a way of predicting the slope of roofs from multiple satellite views of that because we have— every few months, we get new satellite imagery. And so we have multiple views of the same location. And we can predict what the slope of the roof is given all those different views of the same location and how much sun exposure it'll get and then predict if you were to install solar panels on your house, how much energy could you generate, that kind of thing. Kind of cool. It's like a small random thing that you can do now that vision works. OK. So this class has been, I assume, mostly about vision. So I'm going to talk now about other kinds of problems, like language understanding. One of the most important problems is search, obviously. So we care a lot about search. And in particular, if I do the query "car parts for sale," I'd like to determine which of these two documents which is more relevant. And if you just look at the surface forms of the word, that first document looks pretty darn relevant because it has lots of the words occur and lots of red. But actually, the second document is much more relevant given that. And we'd like to be able to understand that. So how much have you talked about embeddings? They actually implemented an LSTM captioning model on the network. Oh, awesome. So you know about embeddings. Great. Embeddings are fantastic. So I will go quickly. But basically, you want to represent words or things in high-dimensional— things that are sparse, map them into a dense space, some 100-dimensional or 1,000-dimensional space, so that you can now have things that are near each other and have similar meanings will end up near each other. In these high-dimensional spaces. So for example, you'd like porpoise and dolphin to be very near each other in this high-dimensional space because they're quite similar words and have similar meanings. They share the same sense of porpoise? No? OK, maybe not. And SeaWorld should be kind of nearby, and camera and Paris should be pretty far away. And you can train embeddings in lots of different ways. One is to have it kind of as the first thing you do when you're feeding into an LSTM. An even simpler thing is a technique my former colleague Tomas Mikolov came up with that we published a paper about, where essentially— it's called the word2vec model. And essentially, you pick a window of words, maybe 20 words wide. You pick the center word, and then you pick another random word, and you try to use the embedding representation of that center word to predict the other word. And then you can train that whole thing with backprop. So essentially, you adjust the weights in the softmax classifier, and then in turn, through backpropagation, you make little adjustments to the embedding representation of that center word so that next time you'll be able to better predict the word parts from automobile. And it actually works. That's one of the really nice things about embeddings is given enough training data, you get really phenomenal representations of words. So these are the nearest neighbors for these three different words. We actually had short phrases as vocabulary items in this particular run. So tiger shark, you can think of as one embedding vector. And these are the nearest neighbors. So it got the sense of sharkness. Car is interesting, right? Like, you see why this is useful for search, because you have things that people often hand code in information retrieval systems like plurals and stemming and like some kind of simple synonyms. But here you just see like, oh, autocar, automobile, pickup truck, racing car, passenger car, dealership is kind of related. You just see that it has this right concept of a nice kind of smooth representation of car rather than explicitly only the letters C-A-R match that. And it turns out that if you train using the Word2Vec approach, the directions turn out to be meaningful in these high-dimensional spaces. So not only is proximity interesting, but directions are interesting. So it turns out if you look at capital and country pairs, you go roughly the same direction and distance to get from a country to its corresponding capital, or vice versa, for any country-capital pair. And you also kind of see some semblance of other structures. So this is the embeddings mapped down to 2 dimensions via principal components analysis. And you see kind of interesting structures around verb tenses, regardless of the verb, which means you can solve analogies like queen is to king as woman is to man by doing some simple vector arithmetic. So you're really literally just looking up the embedding vector and then adding the difference to get to that point, approximately that point. So we've been in collaboration with the search team. We launched kind of one of the biggest search ranking changes in the last few years. We called it RankBrain. It's essentially just a deep neural net that uses embeddings and a bunch of— of neural net layers to give you a score for how relevant this document is for this particular query. And it's the third most important search ranking signal now out of hundreds of such signals. So that's called— uh, Smart Reply was a little collaboration we did with the Gmail team where essentially replying to mail on your phone kind of sucks because Typing is hard. And so we wanted to have a system where often you can predict what would be a good reply just looking at the message. So we have a small network that predicts, is that likely to be something that I can have a short, terse response to? If yes, then we activate a much bigger LSTM-based model. And this is a message one of my colleagues received who was working on the project from his brother. He said, we wanted to invite you to join us for an early Thanksgiving. Blah, blah, blah, blah, blah, please bring your favorite dish, RSVP by next week. So then the model predicts count us in, we'll be there, or sorry, we won't be able to make it, which is great. If you get a lot of email, it's fantastic, although your replies will be somewhat terse. Although you can edit them, which is nice. You know, we can do interesting things like this is a mobile app that actually runs in airplane mode. So it's actually running the models on the phone. And it's actually got a lot of interesting things, some of which I didn't entirely realize. So you're essentially using the camera image. You're detecting text in it. You're finding what the words are, doing OCR on it. You're then running it through a translation model. You configure it in a particular mode. This is just cycling through different languages, but normally you'd set it on Spanish mode and it would only show you Spanish. But the thing I didn't realize is there's actually an interesting font selection problem in how to choose what font to show for the output. So anyway, it's kind of cool. Good if you're traveling to interesting places. I'm actually going to Korea on Saturday, so I'm looking forward to using I translate out because I don't speak Korean. So one of the things we do a bit of work on is reducing inference cost. There's nothing worse than this feeling that, wow, my model is so awesome. It's great. It's just sad that it drains my phone's battery in 2 minutes. Or I can't afford the computation to run it at high QPS in my data center even though I have gobs of machines. So there's lots of tricks you can use. In particular, the simplest one is inference is generally much more forgiving of even much lower precision computation than training. So for inference, we usually find we can quantize all the weights to 8 bits or even less. 8 bits is just a nice quantity that CPUs like to deal with. Really, you could do 6 bits probably, but that doesn't help you that much. So that gives you like a nice 4x memory reduction in storing the parameters and also gives you 4x computation efficiency because you can use CPU vector instructions to do 4 multiplies instead of one 32-bit floating point multiply. So that's really good. I'm going to tell you about kind of a cuter, more exotic way of getting more efficiency out of a a mobile phone. This is a technique called distillation that Jeffrey Hinton, Oriol Vinyals, and I worked on. So suppose you have a really, really giant model, the problem I just described, where you have this fantastic model you're really pleased with. Maybe you have an ensemble of those. And now you want a smaller, cheaper model with almost the same accuracy. So here it is, your giant expensive model. You feed this image in and it gives you fantastic predictions like 0.95 jaguar, I'm pretty sure. And I'm definitely sure that's not a car, 10 to the minus 6th for car. 0.04, you know, I'm hedging a bit, it could be a lion, right? So that's what a really accurate model will do. So the main idea— unfortunately, we later discovered that Rich Caruana Andrej Karpathy in 2006 had published a similar idea in a paper called Model Compression. So the ensemble, or your giant accurate model, implements this interesting function from input to output. So if you forget the fact that there's some structure there and you just try to use the information that's contained in that function, how can we transfer the knowledge in that really accurate function into a smaller representation of the function. So when you're training a model, typically what you do is you feed in an image like this, and then you give it targets to try to achieve. And you give it the target 1 jaguar and 0 for everything else. I'm going to call that a hard target. So that's kind of the ideal your model is striving to achieve. And you give it hundreds of thousands or millions of training images, and it tries to approximate all these one-hot vectors for all the different images. And in actual fact, it doesn't quite do that because it gives you this nice probability distribution over different images— over different classes for the same image. So let's take our giant expensive model, and one of the things we can do is we can actually soften that distribution a bit. and this is what Geoffrey Hinton calls dark knowledge. Sounds fancier. But if you soften this by essentially dividing all the logistic units by a temperature T that might be like 5 or 10 or something, you then get a softer representation of this probability distribution where you say, "Oh, okay, it's a jaguar, but also kind of hedge your bets a little and call it a bit of a lion." maybe even less of a cow, still call it definitely not a car. And that's something you can then use. And this full distribution conveys a lot more information about the image— about the function that's being implemented by this large ensemble, because the ensemble is trying to hedge its bets and do a really good job on giving you a probability distribution over that image. Then you can train the small model. So normally when you train, you just train on the hard targets. But instead, you can train on some combination of the hard targets plus the soft targets. And the training objective is going to try to match some function of those two things. So this works surprisingly well. So here's an experiment we did on a large speech model. So we started with a model that classified 58.9% of frames correctly. That's our big accurate model. And now we're going to use that model to provide soft targets for a smaller model that also gets to see the hard targets. And we're going to train it on only 3% of the data. So the new model with the soft targets gets almost that accuracy, 57%. And with just hard targets, it drastically overfits, and it gets to 44.5% accurate and then goes south. So soft targets are a really, really good regularizer. And the other thing is that because these soft targets have so much information in them compared to just a single 1 and a bunch of zeros, you train much, much faster. You get to that accuracy in phenomenally short amounts of time. So that's pretty nice. And you can do this approach with giant ensembles mapping into one size model of that ensemble. You can do from a large model into a smaller one. Somewhat underappreciated technique. OK. Let's see. So one of the things we did when we thought about building TensorFlow was we kind of took a step back from where we were, and we said, what do you really want in a research system? So you want a lot of different things, and it's kind of hard to balance all of those things. But really, one of the things you really care about if you're a researcher is ease of expression. I want to be able to take any old research idea and try it out. Yeah? [Speaker:AUDIENCE] I had a quick question about the last slide. So you said that you were able to train them a lot faster and get it up to 57. How much smaller was the model? [Speaker:ANDREJ KARPATHY] I don't remember the exact details. They're in this archive paper. It was considerably smaller. I think instead of 1,000-wide fully connected layers, it was like 600 or 500 wide, which is actually a big difference. But check in that paper for the details. I'm probably misremembering. And then you want to be able to take your research idea, scale it, and run experiments quickly. You want to be able to run it portably on both data centers and on phones. It's nice to be able to reproduce things. And you want to go from a good research idea to a production system without having to rewrite in some other system. So that's how we kind of— the main things we were considering when building TensorFlow. We opened open sourced it, as you're aware. I kind of already said that our first system wasn't as flexible. So the core bits of TensorFlow are we have a notion of different devices. It is portable, so it runs on a bunch of different operating systems. We have this core graph execution engine. And then on top of that, we have different front ends where you express the kinds of computations you're trying to do. We have a C++ C++ frontend, which most people don't use, and then we have the Python frontend, which most of you are probably more familiar with. But there's nothing preventing people from putting other languages on there. We want it to be fairly language-neutral. So there's some work going on to put a Go frontend on there, other kinds of languages. We think that'll be good. And you want to be able to take that model and run it on a pretty wide variety of different different platforms. The basic computational model is a graph. I don't know how much you talked about this in your overview of— a little bit. OK. So there's a graph. Things that flow along the edges are tensors, so arbitrary n-dimensional arrays with a primitive type like float or int. Unlike pure data flow models, there's actually state in this graph. So you have things like biases, which is a variable. And then you have operations that can update things that have persistent state. So you can go through the whole graph, compute some gradient, and then adjust the biases based on the gradient. The graph goes through a series of stages. One important stage is deciding, given a whole bunch of computational devices and the graph, where are we going to run each of the different nodes in the graph in terms of computation. So for example, here we might have a CPU in blue and a GPU card in green. And we might want to run the graph in such a way that all the expensive computation happens on the GPU. So actually, as an aside, these placement decisions are kind of tricky. We allow users to provide hints that guide this a bit. And then given the hints, which are not necessarily are not necessarily hard constraints on an exact device, but might be something like, you should really try to run this on a GPU, or place it on task 7, and I don't care what device. And then we want to basically minimize the time through the graph subject to all kinds of other constraints like the memory we have available on each GPU card or on CPUs. I think it'd be interesting to actually use a neural net with some reinforcement learning because you can actually measure an objective here of, you know, if I place this node and this node and this node in this way, how fast is my graph? And I think that would be a pretty interesting reinforcement learning problem. Once we've made decisions of where to place things, then we insert these send and receive nodes, which essentially encapsulate all the communication in the system. So basically, we're And when you want to move a tensor from one place to another, there's a send node that'll kind of just hold on to the tensor until the receive node checks in and says, hey, I'd really love that data for that tensor. And you do this for all the edges that cross device boundaries. And you have different implementations of send and receive pairs depending on the device. So you have, for example, if the GPUs are on the same machine, you can often do RDMA directly from one GPU's memory the other. If they're on different machines, then you do a cross-machine RPC. Your network might support RDMA across the network. In that case, you would just use— directly reach into this other GPU's memory on this other machine and grab it. You can define new operations and kernels pretty easily. The session interface is essentially how you run the graph. Typically you set up a graph once and then you run it a lot. That allows us to kind of have the system do a lot of optimization and decisions about essentially how it wants to place computation nodes and perhaps do some experiments on does it make more sense to put it here or here because it's going to amortize that over lots and lots of run calls. The single process configuration, everything runs in process and it's just sort of simple procedure calls. In a distributed setting, there's a client process, a master process, and then a bunch of workers that have devices. The client says, "I'd like to run this subgraph." The master says, "Oh, okay, that means I need to talk to process 1 and 2 and tell them to do stuff." You can feed and fetch data, and that means that I might sort of have a more complex graph, but I only need to run run little bits of it because I only need to run the parts of the computation that the outputs you asked for are needed based on what you asked for. We focus a lot on being able to scale this to distributed environment. We actually— one of the biggest things when we first open sourced TensorFlow, we hadn't quite carved apart an open open sourceable distributed implementation. So that was GitHub issue number 23, which got filed within like a day of our release. Said, hey, where's the distributed version? We did the initial release last Thursday. So that's good. It'll get better packaging, but at the moment you can kind of hand configure multiple processes with the names of the other processes involved, IP addresses, and ports. We're going to package that up better in the next couple of weeks. But that's there, which is good. And the whole reason to have that is that you want much better turnaround time for experiments. So if you're in the mode where your training and experiment iteration is kind of minutes or hours, that's really, really good. If you're in the mode of multiple weeks, that's kind of hopeless, right? Like more than a month, you generally won't even do it. Or if you do, you're like, oh, my experiment's done. Why did I do that again? So we really emphasize a lot in our group just being able to make it so people can do experiments as fast as reasonable. So the two main things we do are model parallelism and data parallelism. I'll talk about both. You've talked about this a little bit, or— A little bit, but not in too much detail. OK, great. So the best way you can decrease training time is decrease the step time. So one of the really nice properties most neural nets have is there's lots and lots of inherent parallelism, right? Like if you think about a convolutional model, there's lots of parallelism at each of the layers because all the spatial positions are mostly independent, and you can just run run them in parallel on different devices. The problem is figuring out how to communicate— how to distribute that computation in such a way that communication doesn't kill you. A few things help you. So one is local connectivity. Like, convolutional neural nets have this nice property that they're generally looking at like a 5x5 patch of data below them. And they don't need anything else. And the neuron next to it has a lot of overlap overlap with the data it needs for that first neuron. You can have towers with little or no connectivity between the towers. So every few layers, you might communicate a little bit, but mostly you don't. The original AlexNet paper did that. So it essentially had two separate towers that mostly ran independently on GPUs, two different GPUs, and occasionally exchanged some information. You can have specialized parts of the model that are active only for some examples. There's lots of ways to exploit parallelism. So when you're just naively compiling matrix multiply code with GCC or something, it'll probably already take advantage of instruction parallelism present on Intel CPUs. Across cores, you can use thread parallelism and spread things that way. Across devices, communicating between GPUs is is often pretty limited. So you have like a factor of 30 to 40 better bandwidth to the local GPU memory than you do to another GPU card's memory on the same machine. And across machine boundaries is generally even worse. So it's pretty important to kind of keep as much data local as you can and avoid needing too much communication bandwidth. But model parallelism, the basic idea is you're just going to partition the computation of the models somehow, maybe spatially like this, maybe layer by layer. And then in this case, for example, the only communication I need to do is at this boundary. You know, some of the data from partition 2 is needed for the input of that partition 1. But mostly all the data is local. The other technique you can use for for speeding up convergence is data parallelism. So in that case, you're going to use many different replicas of the same model structure, and they're all going to collaborate to update parameters in some shared set of servers that hold the parameter state. Speedups depend a lot on the kind of model. It could be 10 to 40x speedup for 50 replicas. Sparse models with really large embeddings for every vocabulary word on demand, generally you can support more parallelism because most updates only update a handful of the embedding entries. If you have a sentence that has like 10 unique words in it out of a million, and you can have millions and millions— or thousands of replicas doing lots of work. So the basic idea in data parallelism is you have these different model replicas. You're going to have this centralized system that keeps track of the parameters. that may not just be a single machine. It may be a lot of machines because you need a lot of network bandwidth sometimes to keep all these model replicas fed with parameters. So that might— in our big setups, that might be 127 machines at the top. And then you might have 500 replicas of the models down there. And before every model replica does a mini-batch, it's going to grab the parameters. So it says, OK. You 127 machines, give me the parameters. And then it does a computation of a random mini-batch and figures out what the gradient should be. It doesn't apply the gradient locally. It sends the gradient back to the parameter servers. Parameter servers then update the current parameter values. And then before the next step, we do the same thing. Fairly network intensive depending on your model. Things that help here are models that don't have very many parameters. Convolutions are really nice in that respect. LSTMs are nice in that respect because you're essentially then reusing every parameter lots and lots of times. So you already reuse it however big your batch size is on the model. So if your batch size is 128, you're going to bring a parameter over. You're going to use it 128 times for all the different elements in the batch. But if you have a convolutional model, —now you're going to get an additional factor of reuse of maybe like 10,000 different positions in a layer that you're going to reuse it. And in an LSTM, if you unroll 100 time steps, you're going to reuse it 100 times just for the unrolling. So those kinds of things that have models that have lots of computation and fewer parameters to drive that computation generally will work better in data parallelism. Environments. Now, there is an obvious issue depending on how you do this. So one way you can do this is completely asynchronously. Every model replica is just sitting in a loop and fetching the parameters, doing a mini-batch, computing gradients, sending it up there. And if you do that asynchronously, then the gradient it computes may be completely stale with respect to where the parameters are now, right? You've computed it with respect to this parameter value, but Meanwhile, 10 other replicas have caused the parameters to meander over to here, and now you apply the gradient that you thought was for here to this value. So it makes theoreticians incredibly uncomfortable. They're already uncomfortable because it's completely nonconvex problems. But the good news is it works up to a certain level. It would be really good to understand the conditions under under which this works in a more theoretical basis. But in practice, it does seem to work pretty well. The other thing you can do is do this completely synchronously. So you can have one driving loop that says, OK, everyone go. They all get the parameters. They all compute gradients. And then you wait for all the gradients to show up and do something with the gradients— average them or add them together. And that effectively just looks like a giant batch. So if you have r replicas, that looks like r times each individual one's batch size, which sometimes works. You kind of get diminishing returns from larger and larger batch sizes. But the more training examples you have, the more tolerant you are of a bigger batch size generally. If you have a trillion training examples, a batch size of 8,000 is sort of OK. If you have a million training examples, batch size of 8,000 is not so great. Right. I think I said this. There's even more complicated choices where you can have m asynchronous groups of n synchronous replicas. Right. I've said that. Convolutions and recurrent models are good because they reuse the parameters a lot. So data parallelism is actually really, really important for almost all of our models. That's how we get to the point of training models in like half a day or a day, generally. So you see some of the rough kinds of setup we use. And here's an example training graph of ImageNet model, 1 GPU, 10 GPUs, 50 GPUs. And there's the kind of speedups you yet, right? Like, sometimes these graphs are deceiving. Like, the difference between 10 and 50 doesn't seem that big because the lines are kind of close to each other, sort of. But in actual fact, the difference between 10 and 50 is like a factor of 4.1 or something. So that doesn't look like a factor of 4.1 difference, does it? But it is. Anyway, yeah, the way you do it is you like, see where that one crosses 0.6 and see where that one crosses 0.6. OK. So let me show you some of the slight tweaks you make to TensorFlow models to exploit these different kinds of parallelism. One of the things we wanted was for these kinds of parallelism notions to be pretty easy to express. So one of the things we like about TensorFlow is it maps pretty well to kind of the things you might see in a research paper. So it's not— you don't have to read all that, but it's not too different than what you would see in the research paper, which is kind of nice. So that's like a simple LSTM cell. This is the sequence-to-sequence model that Elias Sutskever, Oriol Vinyals, and Kwok-Lee published in NIPS 2014, where essentially you're trying to take an input sequence and and map it to an output sequence. This is a really big area of research. It turns out these kinds of models are applicable for lots and lots of kinds of problems. There's lots of different groups doing interesting and active work in this area. Um, yeah. So here's just some examples of recent work in the last year and a half. In this area from lots of different labs around the world. You've already talked about captioning, I guess. Cool. Yes. So instead of a sequence, you can put in pixels. Who knew? So you put in pixels. You run it through a CNN. That's your initial state. And then you can generate captions. It's pretty amazing. So if you'd asked me 5 years ago, can a computer do that? I would have said, I don't think so. Not for a while. Here we are. It can actually do— and the nice thing is it's a generative model, so you can generate different sentences by exploring the distribution. I think both of those are nice captions. It's not quite as sophisticated as the human one. You'll often see this. One of the things is— If you train the model a little bit— it's really important to train your models to convergence because that's not so good. But if you train that model longer, it's the same model. It just got a lot better. Same thing here, right? Train that is sitting on the tracks. Yes, that's true. But that one's— That one's better. But you still see the human has a lot more sophistication, right? Like, they know that they're across the tracks near a depot. And that's sort of a more subtle thing that the models don't pick up on. Another kind of cute use of LSTMs, you can actually use them to solve all kinds of cool graph problems. So Oriol Vinyals, Maira Fortunato, and Navdeep Jatley did this work, which you start with that set of points, and then you try to predict the traveling salesman tour for that that works best, or the convex hull, or Delaunay triangulation of graphs. It's kind of cool. It's just a sequence-to-sequence problem where you feed in the sequence of points, and then the output is the right set of points for whatever problem you care about. I already talked about smart reply. OK, so LSTMs. So once you have that LSTM cell code that I showed you on there, you can unroll it in time, 20 time steps. Let's say you wanted 4 layers per time step instead of 1. Well, you would make a little bit of change to your code, and you would do that. Now you have 4 layers. Computations instead of one, one of the things you might want to do is run each of those layers on a different GPU. So that's the change you would make to your TensorFlow code to do that. And that then allows you to have a model like this. So this is my sequence. These are the different deep LSTM layers I have per timestep. And after the first little bit, I can start getting more and more GPUs kind of involved. Involved in the process. And you essentially pipeline the entire thing. There's a giant softmax at the top, which you can split across GPUs pretty easily. So that's model parallelism, right? We've now got 6 GPUs in this picture. We actually use 8. We split the softmax across 4 GPUs. And then so every replica would be 8 GPU cards on the same machine, all kind of humming along, And then you might use data parallelism in addition to that to train a bunch of 8 GPU card replicas to train quickly. We have this notion of queues. So you can kind of have TensorFlow graphs that do a bunch of stuff and then stuff it in a queue. And then later you have another bit of TensorFlow graph that starts with dequeuing some stuff and then does some things. So one example is you might want to prefetch inputs. And then do the JPEG decoding to convert them into arrays and maybe do some whitening and cropping and random crop selection and then stuff them in a queue. And then you can then dequeue on, say, different GPU cards or something. We also can group similar examples. So for translation work, we actually bucket by length of sentence so that your batch has a bunch of examples that are all roughly the same sentence length, all 13 to 16-word sentences or something. That just means we then need to only execute exactly that many unrolled steps rather than arbitrary max sentence length. It's good for randomization and shuffling. So we have a shuffling queue. We can just stuff a whole bunch of examples and then get random ones out. Oh, yeah. I don't know what I'm saying. Data parallelism, right? So again, we want to be able to have many replicas of this thing. And so you make modest amounts of changes to your code. We're not quite as happy with this amount of change. But this is kind of what you would do. There's a supervisor that has a bunch of things. You now say there's parameter devices and then prepare the session, and then each one of these runs a local loop. And you now keep track of how many steps have been applied globally across all the different replicas. And as soon as the cumulative sum of all those is big enough, they all exit. So asynchronous training looks kind of like that. You have 3 separate client threads driving 3 separate replicas, all with parameter devices. So one of the big simplifications from distribution relief to TensorFlow is we don't have a separate parameter server notion anymore. We have tensors and variables, variables that contain tensors, and they're just other parts of the graph. And typically you map them onto a small set of devices that are going to hold your parameters, but it's all kind of unified in the same framework. Whether I'm sending a tensor that's parameters or activations or whatever, it doesn't matter. This is kind of a synchronous view. I have one client, and I just split my batch across 3 replicas and add the gradient and apply them. Neural nets turn out to be pretty tolerant of reduced precision. So you can convert to FP16. There's actually an IEEE standard for 16-bit floating point values now. Most CPUs don't quite support that. Don't quite support that yet, so we implemented our own 16-bit format, which is essentially we have a 32-bit float and we lop off 2 bytes of mantissa. And you should kind of do stochastic probabilistic rounding, but we don't. So it's sort of OK. It's just noise. And then you can convert it to 32 bits on the other side by filling in zeros. It's very CPU-friendly. Oh, typo. Well. So model and data parallelism combined really lets you train models quickly. And that's what this is all really about is being able to take a research idea, try it out on a large dataset that's representative of a problem you care about, figure out did that work, figure out what the next set of experiments is. It's pretty easy to express in TensorFlow. The data parallelism we're not so happy with for asynchronous parallelism, but in general it's not too bad. We've open sourced TensorFlow because we think that'll make it easier to share research ideas. We think having— Lots of people using the system outside of Google is a good thing. They'll improve it and bring ideas that we don't necessarily have. It makes it pretty easy to deploy machine learning systems into real products because you can go from a research idea into something running on a phone relatively easily. The community of TensorFlow users outside Google is growing, which is nice. They're doing all kinds of cool things. So I picked a few random examples of things people have done that are posted on GitHub. This is one that's like— Andrej Karpathy has this ConvNet.js, which runs neural nets in your browser using JavaScript. And one of the things he has is a little game that uses reinforcement learning where the yellow dot learns to— I think it learns to eat the— oh, yeah. It learns to eat the green dots and avoid the red dots. So someone reimplemented that in TensorFlow and actually added orange dots that are really bad. And someone implemented this really nice paper from University of Tübingen and the Max Planck Institute. I don't know if you've seen this work where you take an image, a picture, and typically a painting, and then it renders the picture in the style of that painter. And you end up with cool stuff like that. So someone implemented that. And then beyond that, there's a character RNN model. Keras is a popular sort of higher-level library to make it easier to express neural nets. Someone implemented the neural captioning model in TensorFlow. There's an effort underway to translate it into Mandarin. It's cool. It's great. [SPEAKING CHINESE] I wanted to talk about is the Brain Residency Program. So we've started this program. It's a bit of an experiment this year. So this is more as an FYI for next year because our applications are closed. We're actually selecting our final candidates this week. And then the idea is the people will spend a year in our group doing deep learning research. And the hope is they'll come out and have published a couple of papers on arXiv or submitted to conferences. Conferences and learn a lot about doing sort of interesting machine learning research. And we're looking for people for next year, obviously, that are strong in— anyone taking this class probably fits the bill. We'll reopen applications in the fall. So if you're graduating like next year, this could be a good opportunity. Andrej Karpathy. There you go. There's a bunch more reading there. Start here because I did a lot of work in the TensorFlow white paper to make the whole set of references clickable. And so you can click your way through to 50 other papers. OK. That's all I have. So I'm done early. 160 slides. [APPLAUSE] [FOREIGN LANGUAGE] [APPLAUSE] [FOREIGN LANGUAGE] Yes. So those kinds of things are actually tricky. And we have actually a pretty extensive detailed process for things that are talking about using a user's private data for these kinds of things. So for Smart Reply, essentially all the replies that it ever will generate are things that have been said by thousands of users. So the input to the model for training is an email which is typically not sent by thousands of people, but the only things we'll ever suggest are things that are generated in response by a sufficient number of unique users to protect the privacy of the users. So that's the kind of things you're thinking about when designing products like that. And there's actually a lot of care and thought going into, you know, we think this would be a great feature, But how can we do this in a way that ensures that people's privacy is protected? Yeah. I want to ask a question with respect to some of the work you did with Jeff Hinton on knowledge distillation. I remember from the paper that you guys were working on this massive GPT dataset, and you guys at some point decided, OK, we needed a lot of different specialist networks. In order to deal with some of the more difficult aspects of classification. And at some point in the paper, you guys mentioned that, you know, you're considering the possibility of then distilling all these different specialists into a single larger network. I think there's, you know, in ICLR, there's already some work done by Rustam's group on the use of multitask learning in such a format where they have multiple specialists for different games and distilling to a single thing. But that was still on a relatively small scale. And I was wondering, have you guys considered— has there been some further work done on really large-scale distillation of specialist networks into a single network? So we haven't pursued the distillation work as much as we probably should have— should. It's just kind of been one of the things on the back burner compared to all the other things we've been working on. The notion of specialists. So I didn't talk about that at all, but essentially we had a model that was sort of an arbitrary ImageNet classification model, or like JFT, which is like 17,000 classes or something. It's an internal dataset. So we trained a good general model that could deal with all those classes, and then we found interesting confusable classes that algorithmically, all the kinds of mushrooms in the world. And we would train specialists on datasets that were enriched with only mushroom data primarily, and then occasional random images. And we could train 50 such models that were each good at different kinds of things and get pretty significant accuracy increases. At the time, we were able to distill it into a single model pretty well. But we haven't really pursued that too much. Turns out just the mechanics of then training 50 separate models and then distilling them is a bit unwieldy. Yeah. I had a question about the part you explained with the big model teaching the little model. But isn't it a bit worrying to think that a small model, when we optimize it with classic techniques, we only get like 40% accuracy, and when we optimize it with other techniques, we get 60% accuracy. Because it— like you said, the capacity of the model is enough to solve the task, but we don't know how to optimize properly. So isn't it like— doesn't it mean that we fail at optimizing everything in some way? I will first say I think the area of optimization is a ripe one for for exploration and further research because, as you say, this clearly demonstrates that we're— I mean, it's a different objective we're telling the model to do, right? We're telling it to use this hard label or use this hard label and also get this incredibly rich gradient, which says, like, here's 100 other signals of information. So in some sense, it's an unfair comparison, right? You're telling it a lot more stuff. About every example in that case. So sometimes it's not so much an optimization failing, it's maybe we should be figuring out how to feed richer signals than just a single binary label to our models. I think that's probably an interesting area to pursue. We've thought about ideas of having a big ensemble of models all training collectively and sort of exchanging information in the form of their predictions rather than in their parameters, because that might be a much cheaper, more network-friendly way of collaboratively training on a really big dataset, where you each train on 1% of the data or something and swap predictions. Could you just do a simple thing where you take the captions, like, this is a woman holding a banana, and you convert that to a more rich, non-one-hot value? Classification label, so something like banana 50%, mango 50%, just convert the entire dataset, and then you could train on richer labels? Yeah. I mean, I think all these kinds of ideas are worth pursuing. The captioning work is interesting, but we tend to have many fewer labels with captions than we have images with sort of hard labels like cheetah or jaguar, at least that are prepared in a clean way. I think actually on the web, there's a lot of images with sentences written about them. The trick is identifying which sentence is about which image. Yeah. Yeah. To what extent do your models train online? And are there any particular challenges with that? Yeah, so it depends on the problem. Some problems times, you don't need to really train online. Like, speech recognition is a good example. It's not like human vocal cords change that often. The words you say change a little bit, so query distributions tend to be not very stationary. The words everyone collectively says tomorrow are pretty similar to the ones they say today, but subtly different. Like, Long Island Chocolate Festival might suddenly become more and more prominent over the next 2 weeks or something. And those kinds of things, you need to be cognizant of the fact that you want to capture those kinds of effects. And one of the ways to do it is to train your model in an online manner. Sometimes it doesn't need to be so online that you get an example and immediately update your model, but depending on the problem, every 5 minutes or 10 minutes or hour or day is sufficient. For most problems, but it is pretty important to do that for non-stationary problems like ads or search queries or things that change over time like that. Yeah? You mentioned that RankBrain was the third most important signal for search. What are 1 and 2, if you can tell us? I can't say. Yes. Yeah. You sort of touched on it before, but also how do you deal with the noise in your training datasets? Yeah, I mean, noise in training datasets actually happens all the time, right? Like, even if you look at the ImageNet examples, occasionally you'll come across one and you're like— actually, I was just sitting in a meeting with some people who are working on visualization techniques. And one of the things they were visualizing was CIFAR input data. And they had this kind of cool representation of all the CIFAR examples all mapped down to like 4 by 4 pixels each on their screen, so 60,000 images. And you could kind of pick things out and select and sort. And you're like, oh, here's one that the model predicted with high confidence, but it got wrong. And it said airplane as the label. The model said airplane, and you look at the image, and it's an airplane, and the label is not airplane, you're like, oh, I understand why I got it wrong. So it's— you want to make sure your dataset is as clean as possible because training on noisy data is generally not as good as clean data. But on the other hand, expending too much effort to clean the data is often more effort than it's worth. So you kind of do some filtering kinds of things to throw out the obvious bad stuff, and generally more noisy data is often better than less clean data. [Speaker:AUDIENCE] And so the only basic filtering is just kind of put it in the model and hope it comes out flush? [Speaker:ANDREJ KARPATHY] Depends on the problem, but certainly that's one thing to try. And then if you're unhappy with the results, then investigate why. Other questions? OK. Cool. Thank you.