ML project structure in ML Python - Model Metrics & Evaluation

Metrics & Evaluation - ML project structure

Which metric matters for ML project structure and WHY

In ML project structure, the key metrics are related to model performance and workflow efficiency. Metrics like accuracy, precision, recall, and F1 score help us know if the model works well. Metrics on code quality, test coverage, and runtime show if the project is easy to maintain and run. Good structure helps track and improve these metrics easily.

Confusion matrix or equivalent visualization

While ML project structure itself does not have a confusion matrix, the models inside the project do. For example, a confusion matrix looks like this:

      | Predicted Positive | Predicted Negative |
      |--------------------|--------------------|
      | True Positive (TP)  | False Positive (FP) |
      | False Negative (FN) | True Negative (TN)  |
    

This matrix helps measure precision, recall, and accuracy, which are key to evaluating model quality within the project.

Precision vs Recall tradeoff with concrete examples

In an ML project, choosing which metric to focus on depends on the problem. For example:

• Spam filter: High precision is important to avoid marking good emails as spam.
• Medical diagnosis: High recall is critical to catch all sick patients, even if some healthy ones are flagged.

A well-structured project makes it easy to test and compare these metrics to find the best balance.

What "good" vs "bad" metric values look like for ML project structure

Good:

• Model metrics: Accuracy, precision, recall, and F1 score are high and balanced.
• Project metrics: Clear folder organization, modular code, automated tests, and reproducible results.

Bad:

• Model metrics: High accuracy but low recall or precision, indicating poor real-world use.
• Project metrics: Messy code, no tests, hard to reproduce results, and unclear data flow.

Metrics pitfalls in ML project structure

• Accuracy paradox: High accuracy can be misleading if data is imbalanced.
• Data leakage: When test data leaks into training, metrics look better but model fails in real use.
• Overfitting indicators: Training metrics are great but test metrics are poor, showing the model memorizes instead of learning.
• Poor project structure: Makes it hard to track metrics, reproduce results, or improve models.

Self-check question

Your model has 98% accuracy but only 12% recall on fraud cases. Is it good for production? Why or why not?

Answer: No, it is not good. The model misses most fraud cases (low recall), which is dangerous. High accuracy is misleading because fraud is rare. You need to improve recall to catch more fraud.

Key Result

Good ML project structure supports clear tracking and improvement of key model metrics like precision, recall, and accuracy.

Practice

1. Which folder in an ML project should you use to store the original, untouched data files?

easy

A. Raw data folder

B. Processed data folder

C. Models folder

D. Scripts folder

Solution

1. Step 1: Understand the purpose of raw data folder

   The raw data folder is meant to keep the original data safe and unchanged.

2. Step 2: Differentiate from processed data folder

   The processed data folder contains cleaned or transformed data, not the original files.

3. Final Answer:

   Raw data folder -> Option A

4. Quick Check:

   Original data = Raw data folder [OK]

Hint: Original files go to raw data folder to keep them safe [OK]

Common Mistakes:

• Putting original data in processed folder
• Mixing models with data files
• Saving scripts in data folders

2. Which of the following is the correct way to organize code in an ML project?

easy

A. Put all code, notebooks, and models in one folder

B. Keep processed data and scripts mixed in one folder

C. Separate notebooks for exploration and scripts for training

D. Save models inside the raw data folder

Solution

1. Step 1: Identify the role of notebooks and scripts

   Notebooks are for exploring data and ideas; scripts are for running training and processing tasks.

2. Step 2: Understand folder separation

   Keeping notebooks and scripts separate helps keep the project organized and clear.

3. Final Answer:

   Separate notebooks for exploration and scripts for training -> Option C

4. Quick Check:

   Notebooks ≠ scripts folder [OK]

Hint: Use notebooks for exploring, scripts for running training [OK]

Common Mistakes:

• Mixing notebooks and scripts in one folder
• Saving models in data folders
• Putting all files in one folder

3. Given this ML project folder structure:

project/
├── data/
│   ├── raw/
│   └── processed/
├── notebooks/
├── scripts/
└── models/

Where should you save a trained model file after training?

medium

A. data/raw/

B. scripts/

C. notebooks/

D. models/

Solution

1. Step 1: Understand folder purposes

   The models folder is designed to store trained model files for reuse and deployment.

2. Step 2: Exclude other folders

   Data folders are for data files, notebooks for exploration, scripts for code execution, so models belong in models/.

3. Final Answer:

   models/ -> Option D

4. Quick Check:

   Trained model files go to models folder [OK]

Hint: Save trained models in the models folder [OK]

Common Mistakes:

• Saving models in data folders
• Putting models inside notebooks folder
• Confusing scripts folder with models

4. You find that your ML project has raw data and processed data mixed in the same folder. What is the best fix?

medium

A. Rename all files to indicate if they are raw or processed

B. Move raw data to a separate 'raw' folder and processed data to 'processed' folder

C. Delete the processed data and keep only raw data

D. Keep all data in one folder but add a README explaining the files

Solution

1. Step 1: Identify the problem

   Mixing raw and processed data risks overwriting or confusion about data versions.

2. Step 2: Organize data properly

   Separating raw and processed data into different folders keeps original data safe and processed data clear.

3. Final Answer:

   Move raw data to a separate 'raw' folder and processed data to 'processed' folder -> Option B

4. Quick Check:

   Separate raw and processed data folders [OK]

Hint: Keep raw and processed data in separate folders [OK]

Common Mistakes:

• Deleting processed data unnecessarily
• Only renaming files without moving
• Relying on README without folder separation

5. You want to share your ML project with a teammate. Which folder should you exclude to keep the project size small and avoid sharing large temporary files?

hard

A. outputs/

B. data/raw/

C. models/

D. notebooks/

Solution

1. Step 1: Identify large temporary files

   The outputs folder usually contains temporary results like logs, plots, or intermediate files that can be large and rebuilt.

2. Step 2: Decide what to share

   Models, raw data, and notebooks are important for reproducing work, so outputs can be excluded to save space.

3. Final Answer:

   outputs/ -> Option A

4. Quick Check:

   Exclude outputs folder to reduce project size [OK]

Hint: Exclude outputs folder to avoid sharing large temp files [OK]

Common Mistakes:

• Excluding raw data which is needed
• Removing models folder by mistake
• Not excluding any folder and sharing everything