Natural Language Processing, or NLP, is a very popular subfield in Data Science at the moment because it allows computers to process and analyze human language. Siri and Alexa, spam filters, chatbots, auto-complete, and translate apps are all examples of everyday technology that use NLP.

As a Data Scientist, working with text data is a bit trickier than other types of data. Why? Because words are not numbers! This makes the Exploratory Data Analysis and the data cleaning and preprocessing steps a bit different in the Data Science workflow. Text data generally requires much more cleaning (removing stop words and punctuation, lowercasing, stemming or lemmatizing, etc). It also requires tokenizing or vectorizing the text (deriving meaningful numbers from words). As for exploring and analyzing the data, there are not as many ways to visualize text. However, text does open up one new kind of visualization technique that you have probably seen before — word clouds.

During my latest Data Science project, I got to delve into the world of NLP. Along the way, I learned all about creating word clouds in Python, and I wanted to write this piece to share my knowledge for anyone looking to create some beautiful visualizations for text data.

Creating a Basic Word Cloud

To create a basic word cloud (or any word cloud in Python), you will need the following libraries:

Method 1: generate_from_text

There are two main ways to build the word cloud. The first and simplest method is to create the word cloud from a corpus of text, such as an article, book, etc. This corpus should be in the form of a string.

In the example below, I have taken a list of attractions from TripAdvisor in the city of Rome. I will group them all into one body of text (a corpus), and then create a basic word cloud.

Before I grouped the attraction texts, I did a little cleaning by lowercasing, removing basic stop words (i.e. “a”, “the”, “is”, etc), and lemmatizing. I did the same for a list of 12 cities (specifically, 12 of their Top World Destinations for 2021). Rome’s grouped corpus is highlighted in the DataFrame below.

As I mentioned before, we will create the word cloud from the text corpus for Rome. To do that, we will isolate that one corpus by taking a slice of this grouped DataFrame:

From here, we can create the basic word cloud. We will start by instantiating the WordCloud object from the wordcloud library, and use the generate_from_text method to feed it our text corpus. Finally, we will use plt.imshow() to display the WordCloud object. Be sure to use plt.axis(‘off’) to make sure it only displays the word cloud, not axes and their values.

The resulting word cloud is below. We can see that by default, the word cloud uses bi-grams (pairs of words) instead of single words. If needed, we can turn this off when we instantiate the WordCloud object by changing the parameter ‘collocations=False’.

Method 2: generate_from_frequencies

The second method is to create a word cloud from a document term matrix. This is a commonly-used matrix for NLP, which has a separate column for each word in the corpus vocabulary, and the word frequency in each row. For example, below I have depicted the first columns of a document term matrix (dtm) for the 12 cities I showed before. Notice that the dimensions of the dtm 12 x 8676, indicating the 12 cities, and 8,676 words in the entire corpus vocabulary.

If you have a document term matrix, we can easily feed this data into the word cloud object using the .generate_from_frequencies() method. First we will need to isolate the data we want to use for Rome. We will need to transpose this matrix for it to be in the correct format for the word cloud. Wea also want to get the most frequent words, so we will sort the values in descending order. You can see an example of the data we want to use in the photo below.

To actually create the word cloud, we will use pretty much the same code as above, but use the generate_from_frequencies method instead.

The resulting word cloud is below. Notice that because we isolated single words (not bi-grams) in the data, we did not need to tell the WordCloud object to turn off the ‘collocations’ parameter. It automatically had the vectorized words as single words instead of bi-grams.

Finally, now that we understand how these word clouds are made, we can manipulate some of the parameters to create a nicer version of our basic word cloud. Let’s go back to our first example with the rome_corpus variable (generating a word cloud from text). Notice that words like ‘private tour’ and ‘skiptheline’ come up as some of the most frequent words. We can tell our word cloud a custom stop words list to get rid of these. I will also customize the dimensions of the word cloud, and make the entire figure bigger with a figsize parameter. We change the colormap, and add a title. See all these changes in the function below.

Remember that you can always change the function above to use the generate_from_frequencies method instead! The resulting word cloud will look like this:

Wow! Looks much better. It’s still very basic though. Let’s turn it up a notch by changing the word cloud shapes with masks.

Change the Word Cloud Shape

One way to make your word cloud visually stunning is to add a mask. A mask is an image you can use to change the shape of your word cloud. We can manipulate the mask very easily with the mask parameter when we instantiate the WordCloud object.

Once you choose the perfect image to use for your mask and save it (more on that in a minute), we can use the Image function from the PIL library and numpy to get it into the correct format for the WordCloud object.

Now that our mask is in the correct format, we can write a similar function to generate the nicer word cloud. The function below is very similar to our final basic word cloud function with a few exceptions:

• Using the mask parameter makes the width and height parameters void, because it will take on the size of the image itself
• I am using a ‘scale’ of 3, which makes the computation faster for larger word cloud images
• I changed the ‘colormap’ to ‘RdYlGn’ because it felt more Italian (think Italian flag, and homemade pasta!)
• The ‘background_color’ is now ‘white’ for a nicer look against the colormap
• The collocations (bi-grams) will show up this time since we are using the generate_from_text method, with the collocations parameter set to ‘True’

Our final word cloud is below… isn’t it bellísima?!

Choosing the Perfect Mask

The trickiest part of using a mask is that the image you choose must have the following requirements:

• a white background (it must be #ffffff, not off-white or transparent)
• a definitive shape that is NOT white

Here is an example of a mask that did not work so well. The issue here is that its shape is not definitive enough for you to tell what it is.

Therefore you want to choose something that has a very recognizable shape like the example below.

There may even be times where you find the perfect photo for your mask, but it has a few marks in the background that are throwing off the word cloud shape. In order to fix this, you can always open the photo in Photoshop and edit the marks out. If you don’t have Photoshop, a method you can use to hack this (from my Marketing days) is Canva. You can upload the mask image into Canva, place white squares on top of your marks, and then download the edited image. Voila! Your mask will be ready to go with that #ffffff background.

Additional Finishing Touches

The last step to making your word clouds beautiful is to use your own keen eye for those little aesthetic details. Changing the colors, using borders (AKA contour), and manipulating the font and plot size are just a few ways to customize your word clouds. Here are some ways to customize these parameters:

Change the Colormap

Changing the colors of the word is as easy as changing the ‘colormap’ parameter in the WordCloud object instantiation. See all the matplotlib colormap options HERE.

There is also a way to create a colormap of your own based on the colors in your mask image. To do this, use the ImageColorGenerator function in the wordcloud library, and use the colors generated in the color_func parameter when you instantiate the WordCloud object. The color_func parameter will overwrite the colormap parameter.

Here I used the colosseum again since the Italy map was all one color. Using this custom colormap is definitely a nice touch, even though we still can’t really tell its shape!

Use Contour

Not like the Kardashians… but kinda. Contour gives your word cloud mask an outline. You can customize it when you instantiate the WordCloud object with the contour_color and contour_width parameters. Contour colors can be indicated with strings (use a simple color word, or a color code).

Below is an example of our same function to generate the word cloud, but with a thin black contour (width of 1).

As you can see, the resulting word cloud is a more distinguishable shape due to the contour.

Looks pretty cool! The contour here is a bit squiggly because of the detailed shape of Italy. The contour line would be smoother with a more basic mask shape.

We can also try a colored contour to make this a bit nicer. Since there are dark red words in the word cloud, I found a nice wine red color code, #5d0f24, to replace the black contour, and increased the width to 3.

The resulting word cloud is below.

Even the colosseum mask from before looks better here with a little contour! Contour in this case helps us to see the actual shape of the mask.

Whether or not to put contour, and deciding on the color and width of the contour is up to you based on the aesthetic detail you want to include in your word clouds.

A Note on Word Cloud Size

One thing you should always do is to change the size of the word cloud with plt.figure(figsize=(10,8)). You can change it to whatever size you need, but I have found that changing the size of the overall plot works better than trying to resize the WordCloud object itself. I have included this in all the word cloud functions, and you can notice the difference in the word cloud sizes when we jumped from basic word clouds to the word clouds created with functions.

More Fun Customizations!

The possibilities are endless when it comes to customizing your word clouds. Here are some examples:

• Manipulate the font of your word cloud text with the font_path parameter
• Change the min and max font sizes (min_font_size, max_font_size parameters)
• Change the background_color of the word cloud
• Reduce the max_words parameter to show only the top 20 or 50 words, which sometimes makes the word cloud easier to read

All of these small details can impact your word cloud visualizations. Since each mask and each text corpus will look different, it’s ultimately up to you to play around with them to truly make your word clouds look beautiful!

Conclusion

Thanks for following along with me on this little journey to Roma! I hope this story taught you a thing or two about word clouds and creating beautiful NLP visualizations. If you have any more tips, I’d love to hear about them in the comments below!

Note: This was only a small piece of my Data Science capstone project, where I used NLP to classify text for different cities. You can see the full project repo on my Github account.

How to Create Beautiful Word Clouds in Python was originally published in TDS Archive on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is just one major issue when you’re building them at home — the training time for these models is very long!

Enter Google Colab.

Colab is great because it allows you to run your notebook on a hosted computer that is most-likely better/faster/stronger than your local machine. That means faster training for your CNN model.

Why use Google Colab?

In Colab, you can make use of GPUS! Normally your computer is running on a CPU (Central Processing Unit). The CPU is the brain of your computer, which will run your programs and, in this case, train your model. Even though you can split the work between multiple cores of your CPU, it won’t be as fast as a GPU for machine learning. A GPU (Graphics Processing Unit) is a processor made up of many smaller, specialized cores, which means that it can split the work between even more cores and therefore get your CNN training done faster. The GPU is designed for parallel processing and it will be much faster than a CPU in this use-case.

Make use of GPUs with High-Speed RAM with Colab Pro. For only $10 per month, Colab has an upgraded option that gives you access to even faster GPUs and longer runtimes (AKA your notebook won’t time-out/disconnect as often). It also gives you access to more RAM, thus you will have more memory for your data. I actually went with this option because I believe $10 is super cheap when you compare it to the time-savings you will experience (but I also know people who have had lots of success and speed just using normal Colab).

Therefore, use Colab to save time! When I compared my model’s training time using Colab to another students’ training time on their local machine, Colab could train a model in 3–4 minutes (approx. 7 seconds per epoch) vs 6 hours or so on the local machine (approx. 5 minutes per epoch). Now I know that everyone’s computer will be different, but that is a HUGE time-savings even with slight variations in your local machine’s speed.

How to Get Set Up on Colab

Prerequisites: A Google account

First things first, you want to go to https://colab.research.google.com/, sign in to your Google account, and open a new notebook. Alternatively, you can upload an existing jupyter notebook.

Very important: You should set your runtime before you do anything! If you forget to do this before you run anything, you will need to restart your kernel when you finally set it to the high-speed option. To do this, go to the top toolbar and go to Runtime > Change runtime type. You can then change your hardware accelerator to a GPU, and if you opted for the Colab Pro option, you can also set the runtime to High RAM.

Next, we will set up a way to get ahold of your data. Here’s the thing about Colab… unlike your local machine, you need to add your data to the machine you’re working on. Anything you upload to Colab will go to the content folder. However, you can also mount your Google Drive and use that to pull data and files into your notebook. There is a toolbar on the side that you can use to see what’s happening and where things are going.

The toolbar will default to show you the content folder. To navigate up a level, click the folder that has the arrow. You will then see a bunch of folders that are available on the local machine that Google is hooking you up with. These folders allow you to have access to all the Python packages you need and pip-install more if you want. For this specific project, I was using CNNs to predict the presence of pneumonia in chest x-rays. I was using the Mooney Pneumonia dataset available on Kaggle. Luckily this dataset is zipped and ready to go with all the train/test/validation data split into their own folders. I uploaded the zipped data to my Google Drive, but it can also be accessed with the Kaggle API.

After this step, mount your Google Drive to this local machine. When you do, you’ll be able to pull those files out and/or save your models back into your Drive for later use. When you run this cell, it will ask you to go to a link, authorize Colab’s use of your files, and copy and paste that authorization link back in the notebook.

To make sure this worked, check that folder toolbar again and look for a folder called gdrive on the same level as all the other folders. If you look in this folder, you should see everything that’s in your Google Drive. (the code for this is below).

Now it’s time to get your data! Either upload a zipped file to Google Drive in a new tab or pull the data from an API in the notebook you just created.

Find this zip file using the toolbar (you might need to press the little folder with the refresh button right under files if you can’t see it right away). Press the 3 dots to the right of the file, and copy the file path. This will go in the drive_path variable in the code snippet below (the local_path variable will stay the same). If you used the API, the file is probably under content > drive.

Finally, you’re going to unzip the file, but the trick to this is to copy it to the Google Colab machine before you unzip. The reason for this step is to avoid having to reach all the way into Google Drive every time you access this data because it slows down the process. In this way, everything will be unzipped and ready to go in the local machine that is using the GPU, high RAM, etc so you have the fastest setup available.

And voila! Your file should now be unzipped and in the content folder. You can double-check to make sure it’s there by navigating the side toolbar.

If you’re lucky, your data will already be split into these nice folders of images for your train/test/validation split, but otherwise, you can create those folders manually, or get your data into the notebook first and then do a train/test/val split using sklearn’s TrainTestSplit method.

Now we can move on to preprocessing the images and loading them into the notebook from Colab’s local machine!

Image Preprocessing in Colab

With our data in these folders on the local machine, we can use the ImageDataGenerator from Tensorflow’s Keras package. The beauty of going through the above process and getting our data into the Colab machine’s folders is that we can also use the flow_from_directory method to grab these images right out of the folders.

In the code below, I preprocessed the images with the ImageDataGenerator and then iterated through the generators with the next function to get my data into the X, y formats needed for modeling. The process and code are below:

• Scaling the data: ImageDataGenerator gives you the option to rescale the images with their rescale argument. Using 1./255 rescales the image pixels to a scale of 0–1 because the RGB pixel scale for images is from 1–255.
• flow_from_directory: the following arguments are used in the code below, but you can find more by referencing the full documentation

1. file_path — if you have train/test/val folders, you want to direct the file path there (use the 3 dots next to the folder in the side toolbar to copy the path if you’re not sure what it is)
2. target_size — how big you want the images to be (larger=longer train times, but that shouldn’t be a problem if you’re using Colab)
3. batch_size — the total number of images in the folder you’re directing to. Check the number of images with len(os.listdir(file_path)
4. class_mode — defaults to “categorical” for multi-class, but you can set it to “binary” if you’re only predicting 2 classes. There are other options here so check out the documentation if needed
5. seed — it is very important to note that when you’re using Colab it is very hard to snuff out randomization, and you will need to rerun the entire notebook every time you restart your runtime. Therefore, it is imperative to set random seeds whenever you can to best reproduce your results

• Iterate through to create X and y: Use the next function to iterate through the generators and put your data into the correct shape for modeling
• Check class indices: To ensure you’re referencing the correct classes, it is always a good idea to check the class indices to make sure the data is as you think. For example, make sure 0 refers to no pneumonia and 1 refers to pneumonia.

From here you can move on to building, training, and evaluating your Convolutional Neural Network! The speed from using the GPUs will allow you to experiment with building and tuning multiple models without having to wait for hours in between each one’s training.

Pros and Cons of Using Colab

Of course, Colab has both pros and cons, so you should consider both before getting set up.

Pros:

• Faster runtimes: the GPUs and High RAM will train models in a fraction of the time, so you can continue to tune and iterate without having to wait for hours and hours while each model trains
• Accessible from any computer: that’s the beauty of the G-Suite… you can access everything through your Google Drive!
• Connect directly to Github: another cool feature is the ability to push directly to Github from your notebook, next to where you would normally save it. It will prompt you to sign into your Github account, then ask which repo to add it to. Just a quick sidebar on this: you should probably push all your local changes before doing this, then pull down the change where you added the Colab notebook so you don’t run into any merge conflicts

Cons:

• Rerunning the notebook: one major annoyance with Google Colab is that you have to rerun the entire notebook every time you restart your runtime… that means doing the whole unzip, use data generators, preprocess, etc. However, in my opinion, this is a fair price to pay compared to waiting 6 hours for a model to train. You may notice that sometimes the runtime times out and then re-initializes, but you shouldn’t have to rerun stuff unless you completely close out of the notebook and restart the runtime the next time you open it.
• More randomness: Because you have to constantly rerun things, the opportunity for randomness is more prevalent. Make sure you set random seeds in every method that takes a random seed argument (especially if you use validation splits in the model)! I found it very difficult to get the exact same model results each time I reran my notebook because, at the time, I missed a couple of opportunities to set those random seeds to get rid of all the randomness.
• Colab Pro availability: Colab Pro is only currently available in the US and Canada

In conclusion, I would use Colab and Colab Pro for any major machine learning project to save time! I think it’s a great tool for Data Scientists, despite a few minor annoyances. These are just some of the things I learned about Colab during my latest project, so if you have any more tips, pros, cons, personal experiences, etc, please leave a comment below!

Setting Up Google Colab for CNN Modeling was originally published in The Startup on Medium, where people are continuing the conversation by highlighting and responding to this story.

Building a Basic Pipeline | Pipeline Basic Abilities

Building a pipeline is simple. Let’s say you need to do the following steps in building your model:

• Scale data to a standardized scale
• Fit a Random Forest Classifier

We can take these same steps and throw them in a pipeline. Essentially, the initial steps in the pipeline should be preprocessing steps, thus having a fit/transform method. The final step should be an estimator with a scoring method. In this case, our scaler is our preprocessing step, and our Random Forest is the estimator. You can add any number of preprocessing steps into your pipeline before the estimator, but for this example, I will keep it simple. Check out the code below to define the pipeline:

Notice that the steps in your pipeline should be defined as a list of tuples, with the name of the step as a string first, and the method second.

Now you can use this pipeline just like you would use an estimator object:

• First, you need to fit it to the training data
• Call the .score( ) method, .predict( ), etc.
• Access attributes and methods of the steps within your pipeline by indexing the step (this was something that I learned halfway through my project after lots of Googling… remember to go back to basics with indexing!)

Using Pipeline and GridSearchCV

Another amazing thing you can do with pipelines is to integrate a grid search! GridSearchCV is an exhaustive search of all combinations of parameters within a specific parameter grid for your model. It allows you to find the perfect tuning parameters in just a few lines of code. You can create pipelines that perform grid searches and even cross-validation as well.

In order to do this, you simply define the pipeline the same way as above, then define your parameter grid. The parameter grid is a dictionary with parameters as keys and lists of parameters to test as values. The names of the keys must have the following string format “PipelineStepName__ParameterName”. Finally, you run GridSearchCV with your pipeline as the estimator, and parameter grid as your parameter grid.

In the example above, you can see how you can see the best parameters and best score for the best performing model. You can even store that best estimator in another variable to reference later on. In this way, you can add another step to your pipeline streamline — model tuning. It is important to remember that GridSearchCV is an *exhaustive* search, meaning that it will try every single combination of parameters. This can get cumbersome very quickly as you add more parameters, and/or if you add cross-validation as well. The example above would fit 90 total models (3*2*3*5), each containing 100–200 decision trees, so be very careful about which parameters to try and their effect on Big O Notation.

Dealing with Class Imbalance in Your Pipeline

If you’ve worked with pipelines before, you may have run into issues when trying to deal with class imbalance. Class imbalance is when the target you are predicting is not seen as frequently as other classes (i.e. a rare disease). To deal with this imbalance, you can use class weights, oversample the minority class, or undersample the majority class. One popular oversampling technique is SMOTE (Synthetic Minority Oversampling Technique) from Python’s imblearn library.

When trying to add SMOTE to my pipeline in my project, I hit an error. The issue is that sklearn’s pipeline will try to oversample the training and validation sets, which is not what you want to do with SMOTE. To fix this, imblearn has a pipeline that is built on top of sklearn’s pipeline, meaning it functions almost exactly the same way. However, when you call the predict( ) method, the imblearn pipeline will skip the sampling step, solving this issue.

In this way, dealing with class imbalance can be a breeze, because you can just add that step to your pipeline, like the example below.

Customizing Classes to Add to Your Pipeline

One of the things I explored in my most recent machine-learning project is how to build a custom class for my pipeline. Why would you want to do this? Sometimes OneHotEncoder, or StandardScaler is not enough preprocessing to transform your raw data to be ready to feed into your estimator. Essentially to make pipelines work most efficiently, you want them to include all of the data preprocessing so all you need to do to make predictions on new data is to feed it right into your pipeline. For example, what if you want to transform text data in a specific way, or engineer new features that are more complicated? There are 2 ways to do customize these classes:

The first way is to use Object-Oriented Programming (OOP). Sklearn has base estimators for all of their models that you can use to inherit qualities. Remember that in order to be used in the pipeline, the class must have both .fit( ) and .transform( ) methods, and the final class must have a .score( ) method. Therefore, we can build custom classes that have these methods and our pipeline will recognize them as valid. Check out the example below to see a very simple example:

The first class will allow me to choose which columns I want to use. In this way, I can try a variety of features in my grid search (see below). The second class will transform two of the features in my dataset from ‘yes’ and ‘no’ to 1 and 0, respectively (this could be done with OneHotEncoder too, but I just wanted to show an easy example). Now I can go through a similar grid search and scoring as the previous examples, while completely preprocessing my data all in my pipeline.

The second way to do this is arguably easier, but less customizable. We can use sklearn’s FunctionTransformer. This amazing tool will transform any function (even a lambda function) into a class that the pipeline can understand and use.

In conclusion…

Pipelines are your best friend when you’re building machine learning models! They make it super easy for you to put all your preprocessing steps, your model, and even model tuning into an organized and streamlined workflow. If your goal is to work smarter, not harder, then pipelines can help you achieve that goal.

• Wow! I built something that can actually predict housing prices!
• Ok, but how good are these predictions?

I had learned to check all of the assumptions of a Linear Regression model (residuals should have a normal distribution, features are linearly correlated with the target, there’s no multi-collinearity, etc.). I learned to scale and sometimes even log-scale my features and target. I even learned about mean squared error (MSE) and root mean squared error (RMSE) to interpret the residuals of the model. The problem was, once I scaled my features and calculated the MSE, that number was scaled too! I wasn’t sure how to read it accurately.

As a refresher, Mean Squared Error is the average of the squared difference between each predicted point and the actual point. It is generally a very big number because we square each difference to get rid of negative numbers before taking the average. Therefore, we sometimes use Root Mean Squared Error to bring that number back down to scale (RMSE is the square root of MSE).

For example, if the target variable is in USD (i.e. Sale Price of a home), what does a root mean squared error of 0.3 really tell you? Is that big or small? Maybe if you scaled everything from 0 to 1 you could argue that it’s small, but what if you used a different scaling technique? Moreover, one of the most important skills as a Data Scientist is being able to connect these metrics back to real-world applications and interpret them through that lens.

Let’s say I created an app that could predict your home price. As a homeowner, you might see this predicted home price and feel inclined to sell. Now, what if I predicted that your home was going to sell for $350,000. Maybe you get excited and decide to sell your home. When you sell your home, you then realized that it would actually only sell for $250,000, which is less than you paid for the home. My model’s prediction was $100,000 off. For home prices, that is a lot but how would you know that if the RMSE was 0.3?

This is why it is so important to interpret your Mean Squared Error and Root Mean Squared Error correctly. Therefore, in my first Linear Regression project, I reversed my log and normalization scaling so that my MSE and RMSE were back in USD. In this way, I was able to correctly interpret the RMSE. Below I will show you how I did this in Python.

Here are the libraries you will need (this does not include the libraries needed to actually build a linear regression model).

Log Transformation & Normalization

In this example, I am building a Linear Regression model to predict housing prices. The target feature here is housing prices, which are typically in USD (or whatever currency you’re working with). In the process of building this model, I decided to log transform price (the target).

Why? In order to make the distribution of this feature more normal, and thus easier to work with. In this example, I will take the log base 10 of all of the continuous variables.

How?

Next, I will scale the target and the other continuous variables to a standard normal scale.

Why? If we do this to the target and our other continuous features, it will allow the beta coefficients of our model to be weighted in a similar way so we can interpret which features are having a greater impact on our target. I will create a function to standard normalize so that we can apply it to our entire log data frame.

How?

Awesome! Now we have a data frame of log-transformed, standard normalized continuous data. I can concatenate this with our categorical variables and run the model based on this. Next, I will fast-forward to the interpretation stage of the model to see how to change the target feature back to USD.

Transforming Mean Squared Error Back to USD

After building the model, I can validate it with a train-test split or k-fold cross-validation. Model validation is important to see if the model can predict a target using new data, instead of the just data it was trained on. We can analyze whether the model is overfitting (i.e. it predicts training data super well, but cannot generalize to new data) or underfitting (i.e. it is too generalized and thus produces predictions that are too far off). Many times during model validation, we analyze Mean Squared Error (MSE) or Root Mean Squared Error (RMSE) — AKA the average distance (squared to get rid of negative numbers) between the model’s predicted target value and the actual target value. In this example, I can use RMSE to see how far off the model’s predicted price generally is from the actual home price.

Remember that the RMSE will still reflect a price that has been log-transformed and standard-normal scaled. Here’s how I changed it back to USD.

Step 1: Build a function to undo the scale.

Step 2: Inverse the scale using this function.

Step 3: Inverse the log.

Step 4: Find the mean squared error and root mean squared error.

(I did steps 2–4 all in a few lines of code, but to break it down, you would inverse the normalization scale first, then to inverse the log, you would do 10 to the power of that inversed array, then find the mse)

Step 5: Interpret.

As you can see, the final RMSE for the training set was $130,614. For the testing set, the RMSE was $131, 683. This means that in general, the model’s predicted sale price is generally about $130,000 off. If I hadn’t changed that RMSE back to USD, it would have been 0.38 and 0.39 for the training and test RMSEs respectively, which is much harder to interpret. One thing to note is that since the training and test RMSE are very close, we did not overfit this model.

Now, is this a good model? Probably not… If I told you your house was going to sell for $330,000 and then it actually only sold for $200,000, you might be pretty mad. $130,000 is a big difference when you’re buying/selling a home. But what if I told you that I could predict GDP (Gross Domestic Product) of the US with only an average error of $130,000? Well, since the GDP is over $20 trillion, that difference wouldn’t be so big.

In conclusion…

If I could give you one takeaway from this article, it’s this:

Understanding the context of the real-world application of the data you’re working with is essential in order to properly interpret the model’s metrics (like MSE and RMSE).

Without knowing about housing prices, how would you know if your error is big or small? It is so important to think about how your model will be used in practice. Once you understand that, you can transform the target back to its original unit, and truly understand your model’s errors/residuals.