Predictive AI becomes much easier to understand when you stop treating machine learning as a black box and start treating it like an engineering process.

That is the purpose of this ML.NET exercise.

In this lab, we use C#, .NET, ML.NET, AutoML, and the Ames Housing dataset to predict house sale prices. But the real goal is not simply to produce a number.

The goal is to demonstrate how a developer can work through a predictive AI problem systematically:

Profile → Baseline → Hypothesis → Experiment → Compare → Improve

This is the second application in the AInDotNet Predictive AI Lab Series.

The first application predicted taxi fares. This second lab builds on that foundation by introducing a richer dataset, correlation analysis, categorical features, controlled experiments, AutoML, and segmented error analysis.

The source code is available here:

GitHub Repository:
https://github.com/AI-n-DotNet/AInDotNet.MLNET.HousePrices

The Business Question

The problem is simple to state:

Given what we know about a house, what is it likely to sell for?

Because the value we want to predict is numeric and continuous, this is a regression problem.

The target is:

SalePrice

That sounds straightforward, but the real work begins before we train the model.

Start by Understanding the Data

The Ames Housing dataset contains:

• 2,930 houses
• 82 columns
• numeric features
• categorical features
• missing values
• neighborhood information
• quality ratings
• structural characteristics
• garage and basement information
• historical sale prices

Before training anything, the application profiles the dataset.

For numeric features, it calculates:

• minimum
• maximum
• average
• median
• missing values

For categorical features, it reports:

• number of unique values
• missing values
• most common values

This is important because raw columns do not automatically have meaning.

A machine-learning model may see a value of 8, but the developer needs to know whether that means:

• eight bedrooms
• quality rating 8 out of 10
• eight years old
• eight garages

Data profiling gives context to the model inputs before those values become features.

Why Correlation Matters

One of the most useful parts of this exercise is the numeric correlation analysis.

The application calculates Pearson correlation between each numeric candidate feature and SalePrice.

Some of the strongest relationships were:

Overall Qual           0.799
Gr Liv Area            0.707
Garage Cars            0.648
Garage Area            0.640
Total Bsmt SF          0.632
1st Flr SF             0.622

Other features were much weaker:

Bedroom AbvGr          0.144
Overall Cond          -0.102

This gives us an early clue about which numeric features appear to contain predictive signal.

For example:

• overall quality is strongly associated with sale price
• above-ground living area is strongly associated with sale price
• number of bedrooms by itself is much less informative

But there is an important caveat.

Correlation is not the same as feature importance.

A feature with weak linear correlation can still be useful if it interacts with other variables or contributes through nonlinear relationships.

And categorical features such as Neighborhood cannot be evaluated using this numeric Pearson-correlation calculation.

That becomes very important later.

Missing Data Does Not Automatically Mean Bad Data

The dataset contains some columns with large amounts of missing data.

Examples include:

• Pool QC
• Misc Feature
• Alley
• Fence
• Fireplace Qu

At first glance, this may look like a major cleaning problem.

But predictive AI requires business context.

In housing data, an NA value may sometimes mean:

• no pool
• no alley access
• no fireplace
• no garage

That is different from:

The value should exist, but we do not know what it is.

The important lesson is:

Missing data deserves investigation, but it does not automatically require deleting rows or filling every missing value with an average.

In this lab, many of the heavily incomplete columns are not used as model features.

That is a legitimate engineering decision.

Sometimes the right form of data cleaning is simply:

Do not use a field that adds complexity without adding enough value.

Run A: Establish a Baseline

The first experiment intentionally uses a simple model.

Run A — Basic Numeric Features

Trainer:

SDCA Regression

The model uses 10 obvious numeric features such as:

• Overall Quality
• Living Area
• Garage Cars
• Garage Area
• Basement Area
• First Floor Area
• Full Bathrooms
• Bedrooms
• Year Built
• Year Remodeled

Results:

R²:    0.825
RMSE:  $34,675
MAE:   $23,463

The purpose of the baseline is not to build the best model.

The baseline gives us a known starting point.

Without a baseline, later improvements are hard to evaluate objectively.

Run B: Add More Numeric Features

The next experiment asks a specific question:

Do five additional numeric features improve prediction accuracy?

The model expands from 10 numeric features to 15.

Results:

R²:    0.850
RMSE:  $32,055
MAE:   $21,248

Compared with Run A:

R²:    0.825 -> 0.850
RMSE:  $34,675 -> $32,055
MAE:   $23,463 -> $21,248

The model improved.

But the improvement was modest.

That is an important lesson:

More features do not automatically mean dramatically better predictions.

A larger feature set is useful only when the additional variables contribute meaningful information.

Run C: Add Categorical Business Context

The third experiment introduces a more important change.

The model now includes categorical features such as:

• Neighborhood
• MS Zoning
• House Style
• Building Type
• Exterior Quality
• Kitchen Quality
• Basement Quality
• Garage Quality
• Foundation

These fields represent context that raw measurements do not fully capture.

Results:

R²:    0.892
RMSE:  $27,165
MAE:   $17,852

Compared with Run B:

R²:    0.850 -> 0.892
RMSE:  $32,055 -> $27,165
MAE:   $21,248 -> $17,852

This improvement was much larger than the gain from simply adding more numeric values.

That leads to one of the most important lessons in predictive AI:

Business context can matter more than adding additional raw measurements.

A 2,000-square-foot house in one neighborhood may not have the same value as a similar house in another neighborhood.

A house with the same square footage may be valued differently depending on:

• exterior quality
• kitchen quality
• zoning
• construction style
• foundation type

The model cannot use that information unless we provide it.

Run D: Let AutoML Improve the Algorithm

Only after improving the data and features do we change the modeling approach.

The fourth experiment asks:

After improving the feature set, can AutoML find a better regression algorithm and hyperparameters?

ML.NET AutoML evaluates regression alternatives and, in one representative run, selected:

LightGbmRegression

Results:

R²:    0.917
RMSE:  $23,935
MAE:   $16,275

Compared with Run C:

R²:    0.892 -> 0.917
RMSE:  $27,165 -> $23,935
MAE:   $17,852 -> $16,275

AutoML improved the model further.

But notice the sequence.

We did not begin by asking:

Which algorithm is best?

We first asked:

• Do we understand the data?
• Which features appear useful?
• Does more numeric context help?
• Does categorical business context help?

Only then did we optimize the algorithm.

That order matters.

Final Experiment Comparison

The complete experiment progression looks like this:

Run  Description                               R²          RMSE           MAE
-----------------------------------------------------------------------------
A    Basic numeric features                 0.825       $34,675       $23,463
B    Expanded numeric features              0.850       $32,055       $21,248
C    Numeric + categorical features         0.892       $27,165       $17,852
D    Full features + AutoML                 0.917       $23,935       $16,275

Baseline to best model:

R² improvement:   +0.092
RMSE reduction:   $10,740
MAE reduction:    $7,188

That is a substantial improvement.

But the most important result is not that LightGBM won.

The most important result is that the model improved significantly before AutoML was introduced.

Feature Engineering Mattered Before Algorithm Selection

This lab provides a very practical demonstration of a principle that is easy to overlook:

Better features often matter more than simply switching algorithms.

Run A to Run B:

R²: 0.825 -> 0.850

Run B to Run C:

R²: 0.850 -> 0.892

Run C to Run D:

R²: 0.892 -> 0.917

The categorical business context created a major improvement.

AutoML then improved the model further.

That is exactly the kind of progression we want to see in a real predictive AI project.

Aggregate Metrics Can Hide Model Problems

R², RMSE, and MAE are useful.

But they do not tell the entire story.

The application also evaluates individual predictions and groups errors by sale-price range.

For example, the baseline model performed much worse on very expensive houses than on more typical houses.

In Run A, the houses priced above $500,000 had a much larger error than houses in the middle price ranges.

By Run D, performance improved substantially.

But another detail matters:

There were only three houses in that highest price band in the test set.

That means we should be careful about drawing broad conclusions from that segment.

This is a useful real-world lesson:

Model evaluation requires both metrics and judgment.

A single aggregate score can hide:

• poor performance on expensive cases
• poor performance on rare classes
• systematic overprediction
• systematic underprediction
• weak performance on specific business segments

Predicting a Hypothetical House

After training the winning model, the application saves it and uses it to predict the value of a hypothetical house.

Example inputs:

Living Area:      2,200 sq ft
Bedrooms:         3
Bathrooms:        2
Garage:           2 cars
Year Built:       2005
Overall Quality:  8/10
Neighborhood:     CollgCr

One example prediction was approximately:

$269,000

The exact value can vary slightly depending on the AutoML run.

This final step demonstrates how the trained model becomes something an application can actually use.

What This Lab Teaches C# Developers

The most important lesson is not how to call an ML.NET API.

It is how to think through a predictive AI problem.

A repeatable workflow looks like this:

Profile
  ↓
Baseline
  ↓
Hypothesis
  ↓
Experiment
  ↓
Compare
  ↓
Improve

That workflow applies far beyond house prices.

The same approach can be used for:

• customer churn
• fraud detection
• demand forecasting
• equipment failure
• staffing prediction
• project cost prediction
• delivery-time estimation
• credit risk
• inventory forecasting

The algorithm changes.

The engineering process does not.

Try the Exercise Yourself

The full C# and ML.NET source code is available on GitHub:

AInDotNet.MLNET.HousePrices
https://github.com/AI-n-DotNet/AInDotNet.MLNET.HousePrices

Once you have the project running, try changing one major variable at a time.

Examples:

• remove OverallQual
• remove Neighborhood
• add another categorical feature
• add another numeric feature
• increase AutoML training time
• change the train/test ratio
• try another regression trainer
• inspect the worst predictions
• analyze a different price range

The important rule is:

Change one major variable at a time so you can understand what caused the result.

That is how experimentation becomes learning.

The Bigger Predictive AI Lesson

Predictive AI is not:

Load data → train model → get prediction.

A more realistic process is:

Understand the business problem → understand the data → establish a baseline → test hypotheses → add context → compare results → improve the model → analyze failures.

That is what this lab is designed to teach.

And it reinforces a broader point:

The best predictive AI systems usually combine good data, useful features, domain knowledge, appropriate algorithms, and disciplined engineering.

The model is only one part of the solution.

Want More?

Learn more about Predictive AI & Forecasting for Business

Frequently Asked Questions