Machine Learning Bias Demonstration Project

Understanding Machine Learning Bias Demonstration Project

A useful project begins with a clear prediction task that has low stakes. For example, a classifier might sort flower photos by species or recognize handwritten digits. Avoid projects that predict a person's ability, safety, health, or future behavior.

Those topics carry real risks and need much more care. Build groups from a feature that could affect image quality or data coverage, such as lighting level, camera type, handwriting style, or background color. The groups need a sensible reason to compare them.

If one group has far fewer examples, record the counts before training. A model learns patterns that appear often, so rare patterns may be treated as noise instead of important evidence.

Keep a separate test set from the start. Do not repeatedly change the model after checking the same test results, because the test set then starts acting like training data. A better method is to use one validation set while making choices, then use a final untouched test set once.

For each group, make a small table with the number of correct and incorrect results. Look beyond one summary score. A confusion matrix can help show which classes get mixed up.

In a two-class task, note false positives and false negatives separately. These errors can have different meanings. A spam filter that lets through junk mail has a different failure from one that hides an important message.

Inspect individual mistakes rather than treating every error as a number. Look for repeated conditions. Perhaps dark images are mislabeled as one class, or blurry examples fail more often.

Check whether labels were made consistently. Human labelers can disagree, especially when categories are vague. Check for shortcuts in the data too.

If every training photo of one class has the same background, the model may learn the background instead of the object. This is called a spurious correlation.

It can produce impressive results in a narrow test set, then fail when the setting changes. A simple model is often best for a school project because its limits are easier to see and explain.

Try one change at a time and compare the result. You might add more examples from a weak group, remove misleading background clues, improve labels, or choose features that describe the actual task better. More data does not automatically solve the problem if the new data has the same gaps.

Report what improved, what became worse, and what remains uncertain. Include group sizes, data source, label rules, model settings, and examples of errors in your project write-up. State that results from a small classroom dataset may not apply to the real world.

The strongest conclusion is usually specific. It explains which conditions caused failures, why the training process may have created them, and what evidence would be needed before trusting the model more widely.