DEV Community: Larry Barrow

The Fairness Metrics Your ML Model Needs -And Why Accuracy Isn't One of Them

Larry Barrow — Tue, 07 Apr 2026 15:00:55 +0000

Your fraud detection model hits 99.8% accuracy. Ship it?

Not so fast. That number means your model predicts "not fraud" for every single transaction — and it's right 99.8% of the time because only 0.2% of transactions are actually fraudulent. It catches exactly zero fraud cases. Accuracy told you everything was fine. It was lying.

This is the class imbalance trap, and it's the most common evaluation mistake I see teams make when deploying ML models into production. But it's just the beginning. Even when you move past accuracy to better metrics, there's a harder question most teams never ask: is my model fair?

The Four Metrics You Actually Need

Before we talk about fairness, let's fix the basics. For any classification problem — fraud detection, loan approval, medical screening, content moderation — you need to understand four numbers from the confusion matrix:

True Positives (TP): Model said yes, answer was yes.

True Negatives (TN): Model said no, answer was no.

False Positives (FP): Model said yes, answer was no. (Type I error)

False Negatives (FN): Model said no, answer was yes. (Type II error)

From these, three metrics matter far more than accuracy:

Precision = TP / (TP + FP) — "Of everything the model flagged, how much was real?"

High precision means fewer false alarms. Optimize for this when false positives are expensive. Example: spam filtering. Losing a legitimate email to the spam folder is worse than letting a spam message through.

Recall = TP / (TP + FN) — "Of everything that was actually positive, how much did the model catch?"

High recall means fewer missed cases. Optimize for this when false negatives are dangerous. Example: cancer screening. Missing a malignant tumor is far worse than a false alarm that leads to an additional test.

F1 Score = 2 × (Precision × Recall) / (Precision + Recall) — The harmonic mean that balances both.

The key insight: precision and recall are in tension. Lowering your classification threshold catches more positives (higher recall) but also flags more negatives incorrectly (lower precision). The right balance depends entirely on your business context and the cost of each error type.

The Threshold Decision That Changes Everything

Most models output a probability between 0 and 1. You choose a threshold (typically 0.5) above which you predict "positive." But 0.5 is arbitrary. The right threshold depends on the relative cost of errors:

Scenario	Priority	Threshold Strategy
Cancer screening	Recall	Lower threshold — don't miss cases
Email spam filter	Precision	Higher threshold — don't lose real email
Fraud detection	Balanced	Analyze cost matrix: cost of fraud vs. cost of investigation
Loan approval	Context-dependent	Regulatory requirements may dictate

This is where AUC-ROC becomes useful — it measures model performance across all thresholds, giving you a single number (0.5 = random, 1.0 = perfect) that captures discrimination ability independent of threshold choice.

Now the Hard Part: Is Your Model Fair?

Here's where most teams stop. They pick the right metric, tune the threshold, hit a good F1 score, and deploy. But they never ask: does the model perform equally well for everyone?

This isn't a hypothetical concern. A widely reported healthcare algorithm used by major US hospitals systematically deprioritized Black patients for additional care — not because it was explicitly designed to discriminate, but because it used healthcare spending as a proxy for illness severity. Since Black patients historically had less access to healthcare spending, the model learned that they were "healthier" and needed less care. The algorithm affected millions of patients.

The Proxy Variable Problem

The first instinct is to remove protected attributes (race, gender, age) from your feature set. This does not work. Proxy variables reintroduce bias indirectly:

ZIP code correlates with race due to residential segregation
Name patterns correlate with gender and ethnicity
Education level correlates with socioeconomic background
Purchase history correlates with income and access

You cannot engineer your way out of bias by removing columns. You have to measure it.

Fairness Metrics That Matter

Here are the metrics you should be computing across demographic groups in any high-stakes model:

Demographic Parity: Do all groups receive positive predictions at the same rate?

Check: Is P(ŷ=1 | Group A) ≈ P(ŷ=1 | Group B)?

Use when equal outcome rates are the goal (e.g., hiring).

Equalized Odds: Does the model have equal true positive rates AND equal false positive rates across groups?

Use when you need accuracy to be consistent for everyone (e.g., medical diagnosis).

Equal Opportunity: Does the model have equal true positive rates across groups? (Relaxed version of equalized odds.)

Use when catching positives equally is the priority (e.g., loan default detection — don't miss defaults more often for one group).

Predictive Parity: When the model predicts positive, is it equally likely to be correct across groups?

Use when positive predictions must be equally trustworthy regardless of group.

The Impossibility Theorem You Need to Know

Here's the uncomfortable truth: you cannot satisfy all fairness metrics simultaneously. This is mathematically proven (Chouldechova, 2017; Kleinberg et al., 2016). If base rates differ across groups — which they almost always do in real-world data — demographic parity, equalized odds, and predictive parity are mutually exclusive.

This means fairness is not a technical problem you solve once. It's a design decision you make explicitly, document clearly, and revisit regularly. Which fairness definition matters most for your use case? Who decides? What are the tradeoffs? These questions require human judgment, not just code.

A Practical Starting Point

If you're deploying a model that affects people's lives — and most production models do, whether you realize it or not — here's a minimum viable fairness workflow:

1. Define your groups. Identify the demographic segments relevant to your application. Don't assume you know — consult domain experts and affected communities.

2. Compute disaggregated metrics. Don't just report overall F1. Break it down by group. A model with 0.85 F1 overall might have 0.92 for one group and 0.71 for another.

3. Apply the four-fifths rule as a starting heuristic. If any group's selection rate falls below 80% of the highest group's rate, you have a disparity worth investigating.

4. Choose your fairness definition. Based on your application context, decide which metric to optimize and document why.

5. Monitor in production. Fairness isn't a one-time check. Data distributions shift, user populations change, and new biases can emerge after deployment. Build fairness metrics into your monitoring pipeline alongside performance metrics.

The tools exist: Microsoft's Fairlearn, Google's What-If Tool, AWS SageMaker Clarify, and IBM's AI Fairness 360 all provide production-ready fairness measurement and mitigation capabilities.

Going Deeper

Model evaluation and responsible AI are interconnected disciplines — you can't do one well without the other. I've written a more in-depth treatment covering the full evaluation lifecycle, fairness auditing frameworks, calibration analysis, and cross-vendor tooling in my Responsible AI and Ethics guide, which is part of a broader AI/ML training series I maintain.

If this topic resonates, I'd love to hear how your team handles fairness in practice. What fairness definition do you use? Have you hit the impossibility tradeoff in a real project? Drop your experience in the comments.

This article was created with AI assistance for drafting and editing. All technical content reflects my professional experience in ML engineering and has been verified for accuracy.

Developer and Machine Learning

Larry Barrow — Sun, 15 Mar 2026 22:57:16 +0000

What Developers Should Understand About Machine Learning (Before Touching a Model)

Most developers don’t struggle with machine learning because the math is hard. They struggle because the explanations are disconnected from real engineering work. After years of helping people ramp up on ML, I’ve learned that the most effective way to teach it is to anchor everything in scenarios, workflows, and constraints — the things developers deal with every day.

I’m Larry Dale, founder of PowerKram (https://powerkram.com), where I build scenario‑based learning systems for people who want to understand how ML actually works in practice, not just in theory.

This post is a distilled version of the fundamentals I teach developers who are new to ML or integrating ML into their systems.

Why Developers Should Care About ML Fundamentals
Even if you’re not training models full‑time, ML concepts show up everywhere:

data pipelines
API integrations
cloud services that quietly rely on ML
systems that adapt to user behavior
automation workflows
analytics and forecasting features

Understanding ML fundamentals helps developers:

design better architectures
reason about model behavior
debug data‑driven systems
evaluate vendor ML services
avoid common pitfalls around drift, bias, and overfitting

You don’t need to be a data scientist to benefit from ML literacy.

The Mental Model Shift: Rules → Patterns Traditional programming is explicit:

Input + Rules → Output
Machine learning flips that:
Input + Output → Learned Rules

This shift is the foundation of ML thinking. Once developers internalize it, the rest of the ecosystem becomes far less mysterious.

The Three Learning Styles That Cover 90% of Real Work I frame ML for developers using three practical categories:

Supervised Learning
Learn from labeled examples.
Used for: classification, regression, forecasting, scoring.

Unsupervised Learning
Find structure in unlabeled data.
Used for: clustering, anomaly detection, dimensionality reduction.

Reinforcement Learning
Learn by trial and error.
Used for: optimization, robotics, sequential decision‑making.

This framing helps developers map problems to ML approaches quickly.

Classification vs. Regression (Developer Edition) I explain it this way:

Classification → choose a category
Regression → predict a number

Examples developers immediately recognize:

“Is this request suspicious?” → classification
“How long will this job run?” → regression
“Which product should we recommend?” → classification
“What will traffic look like next hour?” → regression

Simple distinctions, huge clarity.

The ML Workflow Mirrors Real Engineering Work Every ML project — whether you’re using Python notebooks, cloud ML services, or custom pipelines — follows the same lifecycle:

Define the problem
Prepare the data (the longest step by far)
Train the model
Evaluate the model
Deploy the model
Monitor and maintain

Developers immediately see the parallels with:

CI/CD
API lifecycle
observability
versioning
performance tuning

ML isn’t magic — it’s engineering with statistical components.

The Bias‑Variance Tradeoff Explained for Engineers I use this analogy:

High bias = underfitting = too few parameters
High variance = overfitting = too many parameters
It’s like tuning a system:
too simple → can’t capture behavior
too complex → memorizes noise

Finding the balance is part science, part intuition, part iteration.

Feature Engineering: The Part Developers Excel At Developers are naturally good at feature engineering because it’s basically:

data modeling
transformation
normalization
encoding
domain‑driven design

Good features often outperform fancy algorithms.
I’ve seen simple models beat deep models purely because the data was well‑prepared.

What I’ll Be Writing About Next
I’ll be publishing more posts on:

ML fundamentals explained clearly
real‑world ML workflows
scenario‑based learning
cross‑vendor cloud AI concepts
how developers can integrate ML responsibly

If you’re learning ML or building systems that rely on it, I’d love to hear what topics you want broken down next. Meanwhile, consider reading more on neural networks, and _machine learning.

— Larry Dale